draft-ietf-forces-model-10.txt   draft-ietf-forces-model-11.txt 
Working Group: ForCES J. Halpern Working Group: ForCES J. Halpern
Internet-Draft Self Internet-Draft Self
Expires: August 1, 2008 E. Deleganes Expires: August 28, 2008 E. Deleganes
Intel Corp. Intel Corp.
J. Hadi Salim J. Hadi Salim
Znyx Networks Znyx Networks
January 29, 2008 February 25, 2008
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-10.txt draft-ietf-forces-model-11.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 1, 2008. This Internet-Draft will expire on August 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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
that control elements (CEs) can control the FEs accordingly. More that control elements (CEs) can control the FEs accordingly. More
specifically, the model describes the logical functions that are specifically, the model describes the logical functions that are
present in an FE, what capabilities these functions support, and how present in an FE, what capabilities these functions support, and how
these functions are or can be interconnected. This FE model is these functions are or can be interconnected. This FE model is
intended to satisfy the model requirements specified in the ForCES intended to satisfy the model requirements specified in the ForCES
requirements document, RFC3654 [3]. requirements document, RFC3654 [4].
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Requirements on the FE model . . . . . . . . . . . . . . 7 2.1. Requirements on the FE model . . . . . . . . . . . . . . 7
2.2. The FE Model in Relation to FE Implementations . . . . . 8 2.2. The FE Model in Relation to FE Implementations . . . . . 8
2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8 2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8
2.4. Modeling Language for the FE Model . . . . . . . . . . . 9 2.4. Modeling Language for the FE Model . . . . . . . . . . . 9
2.5. Document Structure . . . . . . . . . . . . . . . . . . . 9 2.5. Document Structure . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 3, line 42 skipping to change at page 3, line 42
5.3.1. FEState . . . . . . . . . . . . . . . . . . . . . . . 104 5.3.1. FEState . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 105 5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 105
5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 105 5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 105
5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 105 5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 105
6. Satisfying the Requirements on FE Model . . . . . . . . . . . 106 6. Satisfying the Requirements on FE Model . . . . . . . . . . . 106
7. Using the FE model in the ForCES Protocol . . . . . . . . . . 107 7. Using the FE model in the ForCES Protocol . . . . . . . . . . 107
7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 109 7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 109
7.2. FE Capability Declarations . . . . . . . . . . . . . . . 110 7.2. FE Capability Declarations . . . . . . . . . . . . . . . 110
7.3. LFB Topology and Topology Configurability Query . . . . . 111 7.3. LFB Topology and Topology Configurability Query . . . . . 111
7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 111 7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 111
7.5. State Query of LFB Attributes . . . . . . . . . . . . . . 112 7.5. State Query of LFB Components . . . . . . . . . . . . . . 112
7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 113 7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 113
7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 113 7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 113
8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 113 8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 113
8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 120 8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 120
8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 121 8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 121
8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 122 8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 122
8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 122 8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 122
8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 123 8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 123
8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 123 8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 123
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 125 9.1. URN Namespace Registration . . . . . . . . . . . . . . . 124
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 125 9.2. LFB Class Names and LFB Class Identifiers . . . . . . . . 125
12. Security Considerations . . . . . . . . . . . . . . . . . . . 126 10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 126
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 126 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 126
13.1. Normative References . . . . . . . . . . . . . . . . . . 126 12. Security Considerations . . . . . . . . . . . . . . . . . . . 127
13.2. Informative References . . . . . . . . . . . . . . . . . 126 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 127
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127 13.1. Normative References . . . . . . . . . . . . . . . . . . 127
Intellectual Property and Copyright Statements . . . . . . . . . 128 13.2. Informative References . . . . . . . . . . . . . . . . . 127
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 128
Intellectual Property and Copyright Statements . . . . . . . . . 129
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
RFC3654 [3] and is not copied here. The following list of RFC3654 [4] and is not copied here. The following list of
terminology relevant to the FE model is defined in this section. terminology relevant to the FE model is defined in this section.
FE Model -- The FE model is designed to model the logical processing FE Model -- The FE model is designed to model the logical processing
functions of an FE. The FE model proposed in this document includes functions of an FE. The FE model proposed in this document includes
three components: the modeling of individual logical functional three components: the modeling of individual logical functional
blocks (LFB model), the logical interconnection between LFBs (LFB blocks (LFB model), the logical interconnection between LFBs (LFB
topology) and the FE level attributes, including FE capabilities. topology) and the FE level attributes, including FE capabilities.
The FE model provides the basis to define the information elements The FE model provides the basis to define the information elements
exchanged between the CE and the FE in the ForCES Protocol [2]. exchanged between the CE and the FE in the ForCES Protocol [2].
skipping to change at page 6, line 33 skipping to change at page 6, line 33
LFB Component -- A ForCES component that defines the Operational LFB Component -- A ForCES component that defines the Operational
parameters of the LFBs that must be visible to the CEs. parameters of the LFBs that must be visible to the CEs.
Structure Component -- A ForCES component that is part of a complex Structure Component -- A ForCES component that is part of a complex
data structure to be used in LFB data definitions. The individual data structure to be used in LFB data definitions. The individual
parts which make up a structured set of data are referred to as parts which make up a structured set of data are referred to as
Structure Components. These can themselves be of any valid data Structure Components. These can themselves be of any valid data
type, including tables and structures. type, including tables and structures.
Property -- ForCES components have properties associated with them,
such as readability. Other examples include lengths for variable
sized components. These properties are acessed by the CE for reading
(or, where appropriate, writing.) Details on the ForCES properties
are found in section 4.8.
LFB Topology -- A representation of the logical interconnection and LFB Topology -- A representation of the logical interconnection and
the placement of LFB instances along the datapath within one FE. the placement of LFB instances along the datapath within one FE.
Sometimes this representation is called intra-FE topology, to be Sometimes this representation is called intra-FE topology, to be
distinguished from inter-FE topology. LFB topology is outside of the distinguished from inter-FE topology. LFB topology is outside of the
LFB model, but is part of the FE model. LFB model, but is part of the FE model.
FE Topology -- A representation of how multiple FEs within a single FE Topology -- A representation of how multiple FEs within a single
NE are interconnected. Sometimes this is called inter-FE topology, NE are interconnected. Sometimes this is called inter-FE topology,
to be distinguished from intra-FE topology (i.e., LFB topology). An to be distinguished from intra-FE topology (i.e., LFB topology). An
individual FE might not have the global knowledge of the full FE individual FE might not have the global knowledge of the full FE
skipping to change at page 7, line 9 skipping to change at page 7, line 15
Inter-FE Topology -- See FE Topology. Inter-FE Topology -- See FE Topology.
Intra-FE Topology -- See LFB Topology. Intra-FE Topology -- See LFB Topology.
LFB class library -- A set of LFB classes that has been identified as LFB class library -- A set of LFB classes that has been identified as
the most common functions found in most FEs and hence should be the most common functions found in most FEs and hence should be
defined first by the ForCES Working Group. defined first by the ForCES Working Group.
2. Introduction 2. Introduction
RFC3746 [4] specifies a framework by which control elements (CEs) can RFC3746 [5] specifies a framework by which control elements (CEs) can
configure and manage one or more separate forwarding elements (FEs) configure and manage one or more separate forwarding elements (FEs)
within a networking element (NE) using the ForCES protocol. The within a networking element (NE) using the ForCES protocol. The
ForCES architecture allows Forwarding Elements of varying ForCES architecture allows Forwarding Elements of varying
functionality to participate in a ForCES network element. The functionality to participate in a ForCES network element. The
implication of this varying functionality is that CEs can make only implication of this varying functionality is that CEs can make only
minimal assumptions about the functionality provided by FEs in an NE. minimal assumptions about the functionality provided by FEs in an NE.
Before CEs can configure and control the forwarding behavior of FEs, Before CEs can configure and control the forwarding behavior of FEs,
CEs need to query and discover the capabilities and states of their CEs need to query and discover the capabilities and states of their
FEs. RFC3654 [3] mandates that the capabilities, states and FEs. RFC3654 [4] mandates that the capabilities, states and
configuration information be expressed in the form of an FE model. configuration information be expressed in the form of an FE model.
RFC3444 [7] observed that information models (IMs) and data models RFC3444 [8] observed that information models (IMs) and data models
(DMs) are different because they serve different purposes. "The main (DMs) are different because they serve different purposes. "The main
purpose of an IM is to model managed objects at a conceptual level, purpose of an IM is to model managed objects at a conceptual level,
independent of any specific implementations or protocols used". independent of any specific implementations or protocols used".
"DMs, conversely, are defined at a lower level of abstraction and "DMs, conversely, are defined at a lower level of abstraction and
include many details. They are intended for implementors and include include many details. They are intended for implementors and include
protocol-specific constructs." Sometimes it is difficult to draw a protocol-specific constructs." Sometimes it is difficult to draw a
clear line between the two. The FE model described in this document clear line between the two. The FE model described in this document
is primarily an information model, but also includes some aspects of is primarily an information model, but also includes some aspects of
a data model, such as explicit definitions of the LFB class schema a data model, such as explicit definitions of the LFB class schema
and FE schema. It is expected that this FE model will be used as the and FE schema. It is expected that this FE model will be used as the
basis to define the payload for information exchange between the CE basis to define the payload for information exchange between the CE
and FE in the ForCES protocol. and FE in the ForCES protocol.
2.1. Requirements on the FE model 2.1. Requirements on the FE model
RFC3654 [3]defines requirements that must be satisfied by a ForCES FE RFC3654 [4]defines requirements that must be satisfied by a ForCES FE
model. To summarize, an FE model must define: model. To summarize, an FE model must define:
o Logically separable and distinct packet forwarding operations in o Logically separable and distinct packet forwarding operations in
an FE datapath (logical functional blocks or LFBs); an FE datapath (logical functional blocks or LFBs);
o The possible topological relationships (and hence the sequence of o The possible topological relationships (and hence the sequence of
packet forwarding operations) between the various LFBs; packet forwarding operations) between the various LFBs;
o The possible operational capabilities (e.g., capacity limits, o The possible operational capabilities (e.g., capacity limits,
constraints, optional features, granularity of configuration) of constraints, optional features, granularity of configuration) of
each type of LFB; each type of LFB;
o The possible configurable parameters (i.e., attributes) of each
o The possible configurable parameters (e.g., components) of each
type of LFB; type of LFB;
o Metadata that may be exchanged between LFBs. o Metadata that may be exchanged between LFBs.
2.2. The FE Model in Relation to FE Implementations 2.2. The FE Model in Relation to FE Implementations
The FE model proposed here is based on an abstraction using distinct The FE model proposed here is based on an abstraction using distinct
logical functional blocks (LFBs), which are interconnected in a logical functional blocks (LFBs), which are interconnected in a
directed graph, and receive, process, modify, and transmit packets directed graph, and receive, process, modify, and transmit packets
along with metadata. The FE model is designed, and any defined LFB along with metadata. The FE model is designed, and any defined LFB
skipping to change at page 9, line 36 skipping to change at page 9, line 39
Human readability was the most important factor considered when Human readability was the most important factor considered when
selecting the specification language, whereas encoding, decoding and selecting the specification language, whereas encoding, decoding and
transmission performance was not a selection factor. The encoding transmission performance was not a selection factor. The encoding
method for over the wire transport is not dependent on the method for over the wire transport is not dependent on the
specification language chosen and is outside the scope of this specification language chosen and is outside the scope of this
document and up to the ForCES protocol to define. document and up to the ForCES protocol to define.
XML is chosen as the specification language in this document, because XML is chosen as the specification language in this document, because
XML has the advantage of being both human and machine readable with XML has the advantage of being both human and machine readable with
widely available tools support. This document uses XML Schema to widely available tools support. This document uses XML Schema to
define the structure of the LFB Library documents, as defined in [8] define the structure of the LFB Library documents, as defined in [9]
and [9] and [10]. While these LFB Class definitions are not sent in and [10] and [11]. While these LFB Class definitions are not sent in
the ForCES protocol, these definitions comply with the the ForCES protocol, these definitions comply with the
recommendations in RFC3470 [8] on the use of XML in IETF protocols. recommendations in RFC3470 [9] on the use of XML in IETF protocols.
2.5. Document Structure 2.5. Document Structure
Section 3 provides a conceptual overview of the FE model, laying the Section 3 provides a conceptual overview of the FE model, laying the
foundation for the more detailed discussion and specifications in the foundation for the more detailed discussion and specifications in the
sections that follow. Section 4 and Section 5 constitute the core of sections that follow. Section 4 and Section 5 constitute the core of
the FE model, detailing the two major aspects of the FE model: a the FE model, detailing the two major aspects of the FE model: a
general LFB model and a definition of the FE Object LFB, with its general LFB model and a definition of the FE Object LFB, with its
components, including FE capabilities and LFB topology information. components, including FE capabilities and LFB topology information.
Section 6 directly addresses the model requirements imposed by the Section 6 directly addresses the model requirements imposed by the
ForCES requirements defined in RFC3654 [3] while Section 7 explains ForCES requirements defined in RFC3654 [4] while Section 7 explains
how the FE model should be used in the ForCES protocol. how the FE model should be used in the ForCES protocol.
3. ForCES Model Concepts 3. ForCES Model Concepts
Some of the important ForCES concepts used throughout this document Some of the important ForCES concepts used throughout this document
are introduced in this section. These include the capability and are introduced in this section. These include the capability and
state abstraction, the FE and LFB model construction, and the unique state abstraction, the FE and LFB model construction, and the unique
addressing of the different model structures. Details of these addressing of the different model structures. Details of these
aspects are described in Section 4 and Section 5. The intent of this aspects are described in Section 4 and Section 5. The intent of this
section is to discuss these concepts at the high level and lay the section is to discuss these concepts at the high level and lay the
skipping to change at page 11, line 27 skipping to change at page 11, line 32
get to a fine-grained entity being referenced by the CE. The get to a fine-grained entity being referenced by the CE. The
addressing hierarchy is broken into the following: addressing hierarchy is broken into the following:
o An FE is uniqueuely identified by a 32 bit FEID. o An FE is uniqueuely identified by a 32 bit FEID.
o Each Class of LFB is uniquely identified by a 32 bit LFB ClassID. o Each Class of LFB is uniquely identified by a 32 bit LFB ClassID.
The LFB ClassIDs are global within the Network Element and may be The LFB ClassIDs are global within the Network Element and may be
issued by IANA. issued by IANA.
o Within an FE, there can be multiple instances of each LFB class. o Within an FE, there can be multiple instances of each LFB class.
Each LFB Class instance is identified by a 32 bit identities which Each LFB Class instance is identified by a 32 bit identifier which
are 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 where we go into 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
skipping to change at page 13, line 7 skipping to change at page 13, line 7
While one could try to build an object model to fully represent the While one could try to build an object model to fully represent the
FE capabilities, other efforts found this approach to be a FE capabilities, other efforts found this approach to be a
significant undertaking. The main difficulty arises in describing significant undertaking. The main difficulty arises in describing
detailed limits, such as the maximum number of classifiers, queues, detailed limits, such as the maximum number of classifiers, queues,
buffer pools, and meters that the FE can provide. We believe that a buffer pools, and meters that the FE can provide. We believe that a
good balance between simplicity and flexibility can be achieved for good balance between simplicity and flexibility can be achieved for
the FE model by combining coarse level capability reporting with an the FE model by combining coarse level capability reporting with an
error reporting mechanism. That is, if the CE attempts to instruct error reporting mechanism. That is, if the CE attempts to instruct
the FE to set up some specific behavior it cannot support, the FE the FE to set up some specific behavior it cannot support, the FE
will return an error indicating the problem. Examples of similar will return an error indicating the problem. Examples of similar
approaches include DiffServ PIB RFC3317 [5] and Framework PIB RFC3318 approaches include DiffServ PIB RFC3317 [6] and Framework PIB RFC3318
[6]. [7].
3.1.1.2. FE State Model 3.1.1.2. FE State Model
The FE state model presents the snapshot view of the FE to the CE. The FE state model presents the snapshot view of the FE to the CE.
For example, using an FE state model, an FE may be described to its For example, using an FE state model, an FE may be described to its
corresponding CE as the following: corresponding CE as the following:
o on a given port, the packets are classified using a given o on a given port, the packets are classified using a given
classification filter; classification filter;
skipping to change at page 15, line 44 skipping to change at page 15, line 44
| (P,M) | |Components| |(P',M') | |Components| |(P",M") | | (P,M) | |Components| |(P',M') | |Components| |(P",M") |
| | +----------+ | | +----------+ | | | | +----------+ | | +----------+ | |
| +--------------+ +--------------+ | | +--------------+ +--------------+ |
| | | |
+--------------------------------------------------------------+ +--------------------------------------------------------------+
Figure 2: Generic LFB Diagram Figure 2: Generic LFB Diagram
An LFB, as shown in Figure 2, may have inputs, outputs and components An LFB, as shown in Figure 2, may have inputs, outputs and components
that can be queried and manipulated by the CE via an Fp reference that can be queried and manipulated by the CE via an Fp reference
point (defined in RFC3746 [4]) and the ForCES protocol termination point (defined in RFC3746 [5]) and the ForCES protocol termination
point. The horizontal axis is in the forwarding plane for connecting point. The horizontal axis is in the forwarding plane for connecting
the inputs and outputs of LFBs within the same FE. The vertical axis the inputs and outputs of LFBs within the same FE. The vertical axis
between the CE and the FE denotes the Fp reference point where between the CE and the FE denotes the Fp reference point where
bidirectional communication between the CE and FE occurs: the CE to bidirectional communication between the CE and FE occurs: the CE to
FE communication is for configuration, control, and packet injection, FE communication is for configuration, control, and packet injection,
while FE to CE communication is used for packet 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.
A namespace is used to associate a unique name or 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
skipping to change at page 19, line 21 skipping to change at page 19, line 21
outputs, called the output instances of the group, where all output outputs, called the output instances of the group, where all output
instances share the same frame and metadata emission definitions (see instances share the same frame and metadata emission definitions (see
Figure 3.c). Each output instance can connect to a different Figure 3.c). Each output instance can connect to a different
downstream LFB, just as if they were separate singleton outputs, but downstream LFB, just as if they were separate singleton outputs, but
the number of output instances can differ between LFB instances of the number of output instances can differ between LFB instances of
the same LFB class. The class definition may include a lower and/or the same LFB class. The class definition may include a lower and/or
an upper limit on the number of outputs. In addition, for an upper limit on the number of outputs. In addition, for
configurable FEs, the FE capability information may define further configurable FEs, the FE capability information may define further
limits on the number of instances in specific output groups for limits on the number of instances in specific output groups for
certain LFBs. The actual number of output instances in a group is an certain LFBs. The actual number of output instances in a group is an
attribute of the LFB instance, which is read-only for static 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. The LFB has a built-in
mechanism to select one specific output instance for each packet. mechanism to select one specific output instance for each packet.
This mechanism is described in the textual definition of the class This mechanism is described in the textual definition of the class
and is typically configurable via some attributes of the LFB. and is typically configurable via some attributes of the LFB.
For example, consider a 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
skipping to change at page 41, line 4 skipping to change at page 41, line 4
4. Model and Schema for LFB Classes 4. Model and Schema for LFB Classes
The main goal of the FE model is to provide an abstract, generic, The main goal of the FE model is to provide an abstract, generic,
modular, implementation-independent representation of the FEs. This modular, implementation-independent representation of the FEs. This
is facilitated using the concept of LFBs, which are instantiated from is facilitated using the concept of LFBs, which are instantiated from
LFB classes. LFB classes and associated definitions will be provided LFB classes. LFB classes and associated definitions will be provided
in a collection of XML documents. The collection of these XML in a collection of XML documents. The collection of these XML
documents is called a LFB class library, and each document is called documents is called a LFB class library, and each document is called
an LFB class library document (or library document, for short). Each an LFB class library document (or library document, for short). Each
of the library documents will conform to the schema presented in this of the library documents MUST conform to the schema presented in this
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.
skipping to change at page 44, line 14 skipping to change at page 44, line 14
4.5. <dataTypeDefs> Element for Data Type Definitions 4.5. <dataTypeDefs> Element for Data Type Definitions
The (optional) <dataTypeDefs> element can be used to define commonly The (optional) <dataTypeDefs> element can be used to define commonly
used data types. It contains one or more <dataTypeDef> elements, used data types. It contains one or more <dataTypeDef> elements,
each defining a data type with a unique name. Such data types can be each defining a data type with a unique name. Such data types can be
used in several places in the library documents, including: used in several places in the library documents, including:
o Defining other data types o Defining other data types
o Defining attributes 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, an optional longer description, and a type definition
element. The name MUST be unique among all data types defined in the element. The name MUST be unique among all data types defined in the
same library document and in any directly or indirectly included same library document and in any directly or indirectly included
library documents. For example: library documents. For example:
skipping to change at page 46, line 24 skipping to change at page 46, line 24
length is within the FE's supported capabilities, the FE stores the length is within the FE's supported capabilities, the FE stores the
contents of a string exactly as provided by the CE, and returns those contents of a string exactly as provided by the CE, and returns those
contents when requested. No canonicalization, transformations, or contents when requested. No canonicalization, transformations, or
equivalences are performed by the FE. components of type string (or equivalences are performed by the FE. components of type string (or
string[n]) may be used to hold identifiers for correlation with string[n]) may be used to hold identifiers for correlation with
components in other LFBs. In such cases, an exact octet for octet components in other LFBs. In such cases, an exact octet for octet
match is used. No equivalences are used by the FE or CE in match is used. No equivalences are used by the FE or CE in
performing that matching. The ForCES Protocol [2] does not perform performing that matching. The ForCES Protocol [2] does not perform
or require validation of the content of UTF-8 strings. However, or require validation of the content of UTF-8 strings. However,
UTF-8 strings SHOULD be encoded in the shortest form to avoid UTF-8 strings SHOULD be encoded in the shortest form to avoid
potential security issues described in [11]. Any entity displaying potential security issues described in [12]. Any entity displaying
such strings is expected to perform its own validation (for example such strings is expected to perform its own validation (for example
for correct multi-byte characters, and for ensuring that the string for correct multi-byte characters, and for ensuring that the string
does not end in the middle of a multi-byte sequence.) Specific LFB does not end in the middle of a multi-byte sequence.) Specific LFB
class definitions may restrict the valid contents of a string as class definitions may restrict the valid contents of a string as
suited to the particular usage (for example, a component that holds a suited to the particular usage (for example, a component that holds a
DNS name would be restricted to hold only octets valid in such a DNS name would be restricted to hold only octets valid in such a
name.) FEs should validate the contents of SET requests for such name.) FEs should validate the contents of SET requests for such
restricted components at the time the set is performed, just as range restricted components at the time the set is performed, just as range
checks for range limited components are performed. The ForCES checks for range limited components are performed. The ForCES
protocol behavior defines the normative processing for requests using protocol behavior defines the normative processing for requests using
skipping to change at page 48, line 15 skipping to change at page 48, line 15
The type of the array entry can be specified either by referring to The type of the array entry can be specified either by referring to
an existing type (using the <typeRef> element) or defining an unnamed an existing type (using the <typeRef> element) or defining an unnamed
type inside the <array> element using any of the <atomic>, <array>, type inside the <array> element using any of the <atomic>, <array>,
<struct>, or <union> elements. <struct>, or <union> elements.
The array can be "fixed-size" or "variable-size", which is specified The array can be "fixed-size" or "variable-size", which is specified
by the "type" attribute of the <array> element. The default is by the "type" attribute of the <array> element. The default is
"variable-size". For variable size arrays, an optional "max-length" "variable-size". For variable size arrays, an optional "max-length"
attribute specifies the maximum allowed length. This attribute attribute specifies the maximum allowed length. This attribute
should be used to encode semantic limitations, not implementation should be used to encode semantic limitations, not implementation
limitations. The latter should be handled by capability attributes limitations. The latter should be handled by capability components
of LFB classes, and should never be included in data type array is of LFB classes, and should never be included in a data type array
regarded as of unlimited-size. which is regarded as of unlimited-size.
For fixed-size arrays, a "length" attribute MUST be provided that For fixed-size arrays, a "length" attribute MUST be provided that
specifies the constant size of the array. specifies the constant size of the array.
The result of this construct MUST always be a compound type, even if The result of this construct MUST always be a compound type, even if
the array has a fixed size of 1. the array has a fixed size of 1.
Arrays MUST only be subscripted by integers, and will be presumed to Arrays MUST only be subscripted by integers, and will be presumed to
start with index 0. start with index 0.
skipping to change at page 66, line 5 skipping to change at page 66, line 5
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
defined as read-write can actually be written can be determined for a defined as read-write can actually be written can be determined for a
given LFB instance by the CE by reading the property information of given LFB instance by the CE by reading the property information of
that component. An access control setting of "trigger-only" means that component. An access control setting of "trigger-only" means
that this component is included only for use in event detection. that this component is included only for use in event detection.
The following example defines two attributes for an LFB: The following example defines two components for an LFB:
<components> <components>
<component access="read-only" componentID=1> <component access="read-only" componentID=1>
<name>foo</name> <name>foo</name>
<synopsis>number of things</synopsis> <synopsis>number of things</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component access="read-write" componentID=2> <component access="read-write" componentID=2>
<name>bar</name> <name>bar</name>
<synopsis>number of this other thing</synopsis> <synopsis>number of this other thing</synopsis>
skipping to change at page 66, line 38 skipping to change at page 66, line 38
second component ("bar") is also an integer, but uses the <atomic> second component ("bar") is also an integer, but uses the <atomic>
element to provide additional range restrictions. This component has element to provide additional range restrictions. This component has
access mode of read-write allowing it to be both read and written. A access mode of read-write allowing it to be both read and written. A
default value of 10 is provided for bar. although the access for bar default value of 10 is provided for bar. although the access for bar
is read-write, some implementations may offer only more restrictive is read-write, some implementations may offer only more restrictive
access, and this would be reported in the component properties. access, and this would be reported in the component properties.
Note that not all components are likely to exist at all times in a Note that not all components are likely to exist at all times in a
particular implementation. While the capabilities will frequently particular implementation. While the capabilities will frequently
indicate this non-existence, CEs may attempt to reference non- indicate this non-existence, CEs may attempt to reference non-
existent or non-permitted attributes anyway. The FORCES protocol existent or non-permitted components anyway. The FORCES protocol
mechanisms should include appropriate error indicators for this case. mechanisms should include appropriate error indicators for this case.
The mechanism defined above for non-supported component can also The mechanism defined above for non-supported component can also
apply to attempts to reference non-existent array elements or to set apply to attempts to reference non-existent array elements or to set
read-only components. read-only components.
4.7.5. <capabilities> Element to Define LFB Capability Components 4.7.5. <capabilities> Element to Define LFB Capability Components
The LFB class specification provides some flexibility for the FE The LFB class specification provides some flexibility for the FE
implementation regarding how the LFB class is implemented. For implementation regarding how the LFB class is implemented. For
skipping to change at page 75, line 45 skipping to change at page 75, line 45
array, alias, and event components there are subclasses of property array, alias, and event components there are subclasses of property
information providing additional fields. This information is information providing additional fields. This information is
accessed by the CE (and updated where applicable) via the PL accessed by the CE (and updated where applicable) via the PL
protocol. While some property information is writeable, there is no protocol. While some property information is writeable, there is no
mechanism currently provided for checking the properties of a mechanism currently provided for checking the properties of a
property element. Writeability can only be checked by attempting to property element. Writeability can only be checked by attempting to
modify the value. modify the value.
4.8.1. Basic Properties 4.8.1. Basic Properties
The basic property definition, along with the scalar for The basic property definition, along with the scalar dataTypeDef for
accessibility is below. Note that this access permission information accessibility is below. Note that this access permission information
is generally read-only. is generally read-only.
<dataTypeDef> <dataTypeDef>
<name>accessPermissionValues</name> <name>accessPermissionValues</name>
<synopsis> <synopsis>
The possible values of attribute access permission The possible values of component access permission
</synopsis> </synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>None</name> <name>None</name>
<synopsis>Access is prohibited</synopsis> <synopsis>Access is prohibited</synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name> Read-Only </name> <name> Read-Only </name>
<synopsis>Access is read only</synopsis> <synopsis>
Access to the component is read only
</synopsis>
</specialValue> </specialValue>
<specialValue value="2"> <specialValue value="2">
<name>Write-Only</name> <name>Write-Only</name>
<synopsis> <synopsis>
The attribute may be written, but not read The component may be written, but not read
</synopsis> </synopsis>
</specialValue> </specialValue>
<specialValue value="3"> <specialValue value="3">
<name>Read-Write</name> <name>Read-Write</name>
<synopsis> <synopsis>
The attribute may be read or written The component may be read or written
</synopsis> </synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>baseElementProperties</name> <name>baseElementProperties</name>
<synopsis>basic properties, accessibility</synopsis> <synopsis>basic properties, accessibility</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>accessibility</name> <name>accessibility</name>
<synopsis> <synopsis>
does the element exist, and does the component exist, and
can it be read or written can it be read or written
</synopsis> </synopsis>
<typeRef>accessPermissionValues</typeRef> <typeRef>accessPermissionValues</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
4.8.2. Array Properties 4.8.2. Array Properties
The properties for an array add a number of important pieces of The properties for an array add a number of important pieces of
skipping to change at page 100, line 49 skipping to change at page 100, line 49
<synopsis>vendor of this FE</synopsis> <synopsis>vendor of this FE</synopsis>
<typeRef>string[40]</typeRef> <typeRef>string[40]</typeRef>
</component> </component>
<component access="read-only" componentID="6"> <component access="read-only" componentID="6">
<name>FEModel</name> <name>FEModel</name>
<synopsis>model of this FE</synopsis> <synopsis>model of this FE</synopsis>
<typeRef>string[40]</typeRef> <typeRef>string[40]</typeRef>
</component> </component>
<component access="read-only" componentID="7"> <component access="read-only" componentID="7">
<name>FEState</name> <name>FEState</name>
<synopsis>model of this FE</synopsis> <synopsis>State of this FE</synopsis>
<typeRef>FEStateValues</typeRef> <typeRef>FEStateValues</typeRef>
</component> </component>
<component access="read-write" componentID="8"> <component access="read-write" componentID="8">
<name>FENeighbors</name> <name>FENeighbors</name>
<synopsis>table of known neighbors</synopsis> <synopsis>table of known neighbors</synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>FEConfiguredNeighborType</typeRef> <typeRef>FEConfiguredNeighborType</typeRef>
</array> </array>
</component> </component>
skipping to change at page 102, line 5 skipping to change at page 102, line 5
LFB are supported is accessed by the properties information for those LFB are supported is accessed by the properties information for those
components. components.
5.2.1. ModifiableLFBTopology 5.2.1. ModifiableLFBTopology
This component has a boolean value that indicates whether the LFB This component has a boolean value that indicates whether the LFB
topology of the FE may be changed by the CE. If the component is topology of the FE may be changed by the CE. If the component is
absent, the default value is assumed to be true, and the CE presumes absent, the default value is assumed to be true, and the CE presumes
the LFB topology may be changed. If the value is present and set to the LFB topology may be changed. If the value is present and set to
false, the LFB topology of the FE is fixed. If the topology is false, the LFB topology of the FE is fixed. If the topology is
fixed, the LFBs supported clause may be omitted, and the list of fixed, the SupportedLFBs element may be omitted, and the list of
supported LFBs is inferred by the CE from the LFB topology supported LFBs is inferred by the CE from the LFB topology
information. If the list of supported LFBs is provided when information. If the list of supported LFBs is provided when
ModifiableLFBTopology is false, the CanOccurBefore and CanOccurAfter ModifiableLFBTopology is false, the CanOccurBefore and CanOccurAfter
information should be omitted. information should be omitted.
5.2.2. SupportedLFBs and SupportedLFBType 5.2.2. SupportedLFBs and SupportedLFBType
One capability that the FE should include is the list of supported One capability that the FE should include is the list of supported
LFB classes. The SupportedLFBs component, is an array that contains LFB classes. The SupportedLFBs component, is an array that contains
the information about each supported LFB Class. The array structure the information about each supported LFB Class. The array structure
skipping to change at page 106, line 24 skipping to change at page 106, line 24
5.3.4.3. NeighborInterface 5.3.4.3. NeighborInterface
This identifies the interface on the neighbor through which the This identifies the interface on the neighbor through which the
neighbor is reached. The interface identification is needed when neighbor is reached. The interface identification is needed when
either only one side of the adjacency has configuration information, either only one side of the adjacency has configuration information,
or the two FEs are adjacent on more than one interface. or the two FEs are adjacent on more than one interface.
6. Satisfying the Requirements on FE Model 6. Satisfying the Requirements on FE Model
This section describes how the proposed FE model meets the This section describes how the proposed FE model meets the
requirements outlined in Section 5 of RFC3654 [3]. The requirements requirements outlined in Section 5 of RFC3654 [4]. The requirements
can be separated into general requirements (Section 5, 5.1 - 5.4) and can be separated into general requirements (Section 5, 5.1 - 5.4) and
the specification of the minimal set of logical functions that the FE the specification of the minimal set of logical functions that the FE
model must support (Section 5.5). model must support (Section 5.5).
The general requirement on the FE model is that it be able to express The general requirement on the FE model is that it be able to express
the logical packet processing capability of the FE, through both a the logical packet processing capability of the FE, through both a
capability and a state model. In addition, the FE model is expected capability and a state model. In addition, the FE model is expected
to allow flexible implementations and be extensible to allow defining to allow flexible implementations and be extensible to allow defining
new logical functions. new logical functions.
A major component of the proposed FE model is the Logical Function A major component of the proposed FE model is the Logical Function
Block (LFB) model. Each distinct logical function in an FE is Block (LFB) model. Each distinct logical function in an FE is
modeled as an LFB. Operational parameters of the LFB that must be modeled as an LFB. Operational parameters of the LFB that must be
visible to the CE are conceptualized as LFB attributes. These visible to the CE are conceptualized as LFB components. These
attributes express the capability of the FE and support flexible components express the capability of the FE and support flexible
implementations by allowing an FE to specify which optional features implementations by allowing an FE to specify which optional features
are supported. The attributes also indicate whether they are are supported. The components also indicate whether they are
configurable by the CE for an LFB class. Configurable attributes configurable by the CE for an LFB class. Configurable components
provide the CE some flexibility in specifying the behavior of an LFB. provide the CE some flexibility in specifying the behavior of an LFB.
When multiple LFBs belonging to the same LFB class are instantiated When multiple LFBs belonging to the same LFB class are instantiated
on an FE, each of those LFBs could be configured with different on an FE, each of those LFBs could be configured with different
attribute settings. By querying the settings of the attributes for component settings. By querying the settings of the components for
an instantiated LFB, the CE can determine the state of that LFB. an instantiated LFB, the CE can determine the state of that LFB.
Instantiated LFBs are interconnected in a directed graph that Instantiated LFBs are interconnected in a directed graph that
describes the ordering of the functions within an FE. This directed describes the ordering of the functions within an FE. This directed
graph is described by the topology model. The combination of the graph is described by the topology model. The combination of the
attributes of the instantiated LFBs and the topology describe the components of the instantiated LFBs and the topology describe the
packet processing functions available on the FE (current state). packet processing functions available on the FE (current state).
Another key component of the FE model is the FE attributes. The FE Another key component of the FE model is the FE components. The FE
attributes are used mainly to describe the capabilities of the FE, components are used mainly to describe the capabilities of the FE,
but they also convey information about the FE state. but they also convey information about the FE state.
The FE model includes only the definition of the FE Object LFB The FE model includes only the definition of the FE Object LFB
itself. Meeting the full set of working group requirements requires itself. Meeting the full set of working group requirements requires
other LFBs. The class definitions for those LFBs will be provided in other LFBs. The class definitions for those LFBs will be provided in
other documents. other documents.
7. Using the FE model in the ForCES Protocol 7. Using the FE model in the ForCES Protocol
The actual model of the forwarding plane in a given NE is something The actual model of the forwarding plane in a given NE is something
skipping to change at page 107, line 34 skipping to change at page 107, line 34
Protocol [2]: Protocol [2]:
1. FE topology query; 1. FE topology query;
2. FE capability declaration; 2. FE capability declaration;
3. LFB topology (per FE) and configuration capabilities query; 3. LFB topology (per FE) and configuration capabilities query;
4. LFB capability declaration; 4. LFB capability declaration;
5. State query of LFB attributes; 5. State query of LFB components;
6. Manipulation of LFB attributes; 6. Manipulation of LFB components;
7. LFB topology reconfiguration. 7. LFB topology reconfiguration.
Items 1) through 5) are query exchanges, where the main flow of Items 1) through 5) are query exchanges, where the main flow of
information is from the FEs to the CEs. Items 1) through 4) are information is from the FEs to the CEs. Items 1) through 4) are
typically queried by the CE(s) in the beginning of the post- typically queried by the CE(s) in the beginning of the post-
association (PA) phase, though they may be repeatedly queried at any association (PA) phase, though they may be repeatedly queried at any
time in the PA phase. Item 5) (state query) will be used at the time in the PA phase. Item 5) (state query) will be used at the
beginning of the PA phase, and often frequently during the PA phase beginning of the PA phase, and often frequently during the PA phase
(especially for the query of statistical counters). (especially for the query of statistical counters).
skipping to change at page 108, line 43 skipping to change at page 108, line 43
Figure 12: Relationship between the FE model and the ForCES protocol Figure 12: Relationship between the FE model and the ForCES protocol
messages, where (1) is part of the ForCES base protocol, and the messages, where (1) is part of the ForCES base protocol, and the
rest are defined by the FE model. rest are defined by the FE model.
The actual encoding of these messages is defined by the ForCES The actual encoding of these messages is defined by the ForCES
Protocol [2] document and is beyond the scope of the FE model. Their Protocol [2] document and is beyond the scope of the FE model. Their
discussion is nevertheless important here for the following reasons: discussion is nevertheless important here for the following reasons:
o These PA model components have considerable impact on the FE o These PA model components have considerable impact on the FE
model. For example, some of the above information can be model. For example, some of the above information can be
represented as attributes of the LFBs, in which case such represented as components of the LFBs, in which case such
attributes must be defined in the LFB classes. components must be defined in the LFB classes.
o The understanding of the type of information that must be o The understanding of the type of information that must be
exchanged between the FEs and CEs can help to select the exchanged between the FEs and CEs can help to select the
appropriate protocol format and the actual encoding method (such appropriate protocol format and the actual encoding method (such
as XML, TLVs). as XML, TLVs).
o Understanding the frequency of these types of messages should o Understanding the frequency of these types of messages should
influence the selection of the protocol format (efficiency influence the selection of the protocol format (efficiency
considerations). considerations).
skipping to change at page 111, line 45 skipping to change at page 111, line 45
LFB instances in the model of a particular FE implementation will LFB instances in the model of a particular FE implementation will
possess limitations on the capabilities defined in the corresponding possess limitations on the capabilities defined in the corresponding
LFB class. The LFB class specifications must define a set of LFB class. The LFB class specifications must define a set of
capability arguments, and the CE must be able to query the actual capability arguments, and the CE must be able to query the actual
capabilities of the LFB instance via querying the value of such capabilities of the LFB instance via querying the value of such
arguments. The capability query will typically happen when the LFB arguments. The capability query will typically happen when the LFB
is first detected by the CE. Capabilities need not be re-queried in is first detected by the CE. Capabilities need not be re-queried in
case of static limitations. In some cases, however, some case of static limitations. In some cases, however, some
capabilities may change in time (e.g., as a result of adding/removing capabilities may change in time (e.g., as a result of adding/removing
other LFBs, or configuring certain attributes of some other LFB when other LFBs, or configuring certain components of some other LFB when
the LFBs share physical resources), in which case additional the LFBs share physical resources), in which case additional
mechanisms must be implemented to inform the CE about the changes. mechanisms must be implemented to inform the CE about the changes.
The following two broad types of limitations will exist: The following two broad types of limitations will exist:
o Qualitative restrictions. For example, a standardized multi- o Qualitative restrictions. For example, a standardized multi-
field classifier LFB class may define a large number of field classifier LFB class may define a large number of
classification fields, but a given FE may support only a subset of classification fields, but a given FE may support only a subset of
those fields. those fields.
o Quantitative restrictions, such as the maximum size of tables, o Quantitative restrictions, such as the maximum size of tables,
etc. etc.
The capability parameters that can be queried on a given LFB class The capability parameters that can be queried on a given LFB class
will be part of the LFB class specification. The capability will be part of the LFB class specification. The capability
parameters should be regarded as special attributes of the LFB. The parameters should be regarded as special components of the LFB. The
actual values of these arguments may be, therefore, obtained using actual values of these components may be, therefore, obtained using
the same attribute query mechanisms as used for other LFB attributes. the same component query mechanisms as used for other LFB components.
Capability attributes will typically be read-only arguments, but in Capability components are read-only arguments. In cases where some
certain cases they may be configurable. For example, the size of a implementations may allow CE modification of the value, the
lookup table may be limited by the hardware (read-only), in other information must be represented as an operational component, not a
cases it may be configurable (read-write, within some hard limits). capability component.
Assuming that capabilities will not change frequently, the efficiency Assuming that capabilities will not change frequently, the efficiency
of the protocol/schema/encoding is of secondary concern. of the protocol/schema/encoding is of secondary concern.
Much of this restrictive information is captured by the component Much of this restrictive information is captured by the component
property information, and so can be access uniformly for all property information, and so can be access uniformly for all
information within the model. information within the model.
7.5. State Query of LFB Attributes 7.5. State Query of LFB Components
This feature must be provided by all FEs. The ForCES protocol and This feature must be provided by all FEs. The ForCES protocol and
the data schema/encoding conveyed by the protocol must together the data schema/encoding conveyed by the protocol must together
satisfy the following requirements to facilitate state query of the satisfy the following requirements to facilitate state query of the
LFB attributes: LFB components:
o Must permit FE selection. This is primarily to refer to a single o Must permit FE selection. This is primarily to refer to a single
FE, but referring to a group of (or all) FEs may optionally be FE, but referring to a group of (or all) FEs may optionally be
supported. supported.
o Must permit LFB instance selection. This is primarily to refer to o Must permit LFB instance selection. This is primarily to refer to
a single LFB instance of an FE, but optionally addressing of a a single LFB instance of an FE, but optionally addressing of a
group of LFBs (or all) may be supported. group of LFBs (or all) may be supported.
o Must support addressing of individual attribute of an LFB. o Must support addressing of individual components of an LFB.
o Must provide efficient encoding and decoding of the addressing o Must provide efficient encoding and decoding of the addressing
info and the configured data. info and the configured data.
o Must provide efficient data transmission of the attribute state o Must provide efficient data transmission of the component state
over the wire (to minimize communication load on the CE-FE link). over the wire (to minimize communication load on the CE-FE link).
7.6. LFB Component Manipulation 7.6. LFB Component Manipulation
The FE Model provides for the definition of LFB Classes. Each class The FE Model provides for the definition of LFB Classes. Each class
has a globally unique identifier. Information within the class is has a globally unique identifier. Information within the class is
represented as components and assigned identifiers with the scope of represented as components and assigned identifiers within the scope
that class. This model also specifies that instances of LFB Classes of that class. This model also specifies that instances of LFB
have identifiers. The combination of class identifiers, instance Classes have identifiers. The combination of class identifiers,
identifiers, and component identifiers are used by the protocol to instance identifiers, and component identifiers are used by the
reference the LFB information in the protocol operations. protocol to reference the LFB information in the protocol operations.
7.7. LFB Topology Re-configuration 7.7. LFB Topology Re-configuration
Operations that will be needed to reconfigure LFB topology: Operations that will be needed to reconfigure LFB topology:
o Create a new instance of a given LFB class on a given FE. o Create a new instance of a given LFB class on a given FE.
o Connect a given output of LFB x to the given input of LFB y. o Connect a given output of LFB x to the given input of LFB y.
o Disconnect: remove a link between a given output of an LFB and a o Disconnect: remove a link between a given output of an LFB and a
skipping to change at page 121, line 4 skipping to change at page 121, line 4
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.
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 too 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.
Good packets that arrive and are not LMI and have a frame relay type Good packets that arrive and are not LMI and have a frame relay type
indicator of IP are sent as IP packets on the port in the DatatoFE indicator of IP are sent as IP packets on the port in the DatatoFE
port group, using the same index field from the table based on the port group, using the same index field from the table based on the
laser channel and DLCI. The channel and DLCI are attached as meta- laser channel and DLCI. The channel and DLCI are attached as meta-
skipping to change at page 121, line 40 skipping to change at page 121, line 40
8.1.1. Setting up a DLCI 8.1.1. Setting up a DLCI
When a CE chooses to establish a DLCI on a specific laser channel, it When a CE chooses to establish a DLCI on a specific laser channel, it
sends a SET request directed to this LFB. The request might look sends a SET request directed to this LFB. The request might look
like like
T = SET T = SET
T = PATH-DATA T = PATH-DATA
Path: flags = none, length = 4, path = 2, channel, 4, entryIdx Path: flags = none, length = 4, path = 2, channel, 4, entryIdx
DataRaw: DLCI, Enable(1), false, out-idx DataRaw: DLCI, Enabled(1), false, out-idx
Which would establish the DLCI as enabled, with traffic going to a Which would establish the DLCI as enabled, with traffic going to a
specific entry of the output port group DatatoFE. (The CE would specific entry of the output port group DatatoFE. (The CE would
ensure that output port is connected to the right place before ensure that output port is connected to the right place before
issuing this request.) issuing this request.)
The response would confirm the creation of the specified entry. This The response would confirm the creation of the specified entry. This
table is structured to use separate internal indices and DLCIs. An table is structured to use separate internal indices and DLCIs. An
alternative design could have used the DLCI as index, trading off alternative design could have used the DLCI as index, trading off
complexities. complexities.
skipping to change at page 122, line 46 skipping to change at page 122, line 46
the error indication as meta-data, and ship the packet to the CE. the error indication as meta-data, and ship the packet to the CE.
Other aspects of error handling are discussed under events below. Other aspects of error handling are discussed under events below.
8.2. LFB Components 8.2. LFB Components
This LFB is defined to have two top level components. One reflects This LFB is defined to have two top level components. One reflects
the administrative state of the LFB. This allows the CE to disable the administrative state of the LFB. This allows the CE to disable
the LFB completely. the LFB completely.
The other attribute is the table of information about the laser The other component is the table of information about the laser
channels. It is a variable sized array. Each array entry contains channels. It is a variable sized array. Each array entry contains
an identifier for what laser frequency this entry is associated with, an identifier for what laser frequency this entry is associated with,
whether that frequency is operational, the power of the laser at that whether that frequency is operational, the power of the laser at that
frequency, and a table of information about frame relay circuits on frequency, and a table of information about frame relay circuits on
this frequency. There is no administrative status since a CE can this frequency. There is no administrative status since a CE can
disable an entry simply by removing it. (Frequency and laser power disable an entry simply by removing it. (Frequency and laser power
of a non-operational channel are not particularly useful. Knowledge of a non-operational channel are not particularly useful. Knowledge
about what frequencies can be supported would be a table in the about what frequencies can be supported would be a table in the
capabilities section.) capabilities section.)
skipping to change at page 124, line 43 skipping to change at page 124, line 43
an event will not be generated. The power has to recover to at least an event will not be generated. The power has to recover to at least
12 and fall back below 10 to generate another event. One common 12 and fall back below 10 to generate another event. One common
cause of this form of oscillation is when the actual value is right cause of this form of oscillation is when the actual value is right
near the border. If it is really 9.5, tiny changes might flip it near the border. If it is really 9.5, tiny changes might flip it
back and forth between 9 and 10. A variance level of 1 will suppress back and forth between 9 and 10. A variance level of 1 will suppress
this sort of condition. Many other events have oscillations that are this sort of condition. Many other events have oscillations that are
somewhat wider, so larger variance settings can be used with those. somewhat wider, so larger variance settings can be used with those.
9. IANA Considerations 9. IANA Considerations
The Forces model creates the need for unique class names and numeric The ForCES model creates the need for a unique XML namespace for
class identifiers. To meet that goal, IANA will maintain a registry ForCES library definition usage, and unique class names and numeric
of LFB Class names, corresponding class identifiers, and the document class identifiers.
which defines the LFB Class. The registry policy is simply first
come first served(FCFS) with regard to LFB Class names. With regard 9.1. URN Namespace Registration
to LFB Class identifiers, identifiers less than 65536 are reserved
for assignment by IETF RFCs. Identifiers above 65536 are available IANA is requested to register a new XML namespace, as per the
for assignment on a first come, first served basis. Registry entries guidelines in RFC3688 [3].
must be documented in a stable, publicly available form.
URI: The URI for this namespace is
urn:ietf:params:xml:ns:forces:lfbmodel:1.0
Registrant Contact: IESG
XML: none, this is an XML namespace
9.2. LFB Class Names and LFB Class Identifiers
In order to have well defined ForCES LFB Classes, and well defined
identifiers for those classes, a registry of LFB Class names,
corresponding class identifiers, and the document which defines the
LFB Class is needed. The registry policy is simply first come first
served(FCFS) with regard to LFB Class names. With regard to LFB
Class identifiers, identifiers less than 65536 are reserved for
assignment by IETF Standards Track RFCs. Identifiers above 65536 are
available for assignment on a first come, first served basis. All
Registry entries must be documented in a stable, publicly available
form.
Since this registry provides for FCFS allocation of a portion of the Since this registry provides for FCFS allocation of a portion of the
class identifier space, it is necessary to define rules for naming class identifier space, it is necessary to define rules for naming
classes that are using that space. As these can be defined by classes that are using that space. As these can be defined by
anyone, the needed rule is to keep the FCFS class names from anyone, the needed rule is to keep the FCFS class names from
colliding with IETF defined class names. Therefore, all FCFS class colliding with IETF defined class names. Therefore, all FCFS class
names MUST start with the string "Ext-". names MUST start with the string "Ext-".
The LFBLibrary element and all of its sub-elements are defined in the
following namespace:
<urn:ietf:params:xml:ns:forces:lfbmodel:1.0>
Table 1 tabulates the above information. Table 1 tabulates the above information.
+------------+-------------+----------+-----------------------------+ IANA is requested to create a register of ForCES LFB Class Names and
| LFB Class | LFB Class | Place | Description | the corresponding ForCES LFB Class Identifiers, with the location of
| Name | Identifier | Defined | | the definition of the ForCES LFB Class, in accordance with the rules
+------------+-------------+----------+-----------------------------+ in the following table.
| Reserved | 0 | This | Reserved |
| | | document | | +----------------+------------+---------------+---------------------+
| FE Object | 1 | This | Defines ForCES Forwarding | | LFB Class Name | LFB Class | Place Defined | Description |
| | | document | Element information | | | Identifier | | |
| FE | 2 | [2] | Defines parameters for the | +----------------+------------+---------------+---------------------+
| Protocol | | | ForCES protocol operation | | Reserved | 0 | RFCxxxx | Reserved |
| Object | | | | | | | | -------- |
+------------+-------------+----------+-----------------------------+ | FE Object | 1 | RFXxxxx | Defines ForCES |
| | | | Forwarding Element |
| | | | information |
| FE Protocol | 2 | [2] | Defines parameters |
| Object | | | for the ForCES |
| | | | protocol operation |
| | | | -------- |
| IETF defined | 3-65535 | Standards | Reserved for IETF |
| LFBs | | Track RFCs | defined RFCs |
| | | | -------- |
| Forces LFB | >65535 | Any Publicly | First Come, First |
| Class names | | Available | Served for any use |
| beginning EXT- | | Document | |
+----------------+------------+---------------+---------------------+
Table 1 Table 1
[Note to RFC Editor, RFCxxxx above is to be changed to the RFC number
assigned to this document for publication.]
10. Authors Emeritus 10. Authors Emeritus
The following are the authors who were instrumental in the creation The following are the authors who were instrumental in the creation
of earlier releases of this document. of earlier releases of this document.
Lily Yang, Intel Corp. Lily Yang, Intel Corp.
Ram Gopal, Nokia Research Center Ram Gopal, Nokia Research Center
Alan DeKok, Infoblox, Inc. Alan DeKok, Infoblox, Inc.
Zsolt Haraszti, Clovis Solutions Zsolt Haraszti, Clovis Solutions
skipping to change at page 126, line 28 skipping to change at page 127, line 28
13.1. Normative References 13.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Doria, A., Haas, R., Hadi Salim, J., Khosravi, H., and W. Wang, [2] Doria, A., Haas, R., Hadi Salim, J., Khosravi, H., and W. Wang,
"ForCES Protocol Specification", work in progress, draft-ietf - "ForCES Protocol Specification", work in progress, draft-ietf -
forces-protocol-11.txt, December 2007. forces-protocol-11.txt, December 2007.
[3] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
13.2. Informative References 13.2. Informative References
[3] Khosravi, H. and T. Anderson, "Requirements for Separation of [4] Khosravi, H. and T. Anderson, "Requirements for Separation of
IP Control and Forwarding", RFC 3654, November 2003. IP Control and Forwarding", RFC 3654, November 2003.
[4] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding [5] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding
and Control Element Separation (ForCES) Framework", RFC 3746, and Control Element Separation (ForCES) Framework", RFC 3746,
April 2004. April 2004.
[5] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, [6] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie,
"Differentiated Services Quality of Service Policy Information "Differentiated Services Quality of Service Policy Information
Base", RFC 3317, March 2003. Base", RFC 3317, March 2003.
[6] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework [7] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework
Policy Information Base", RFC 3318, March 2003. Policy Information Base", RFC 3318, March 2003.
[7] Pras, A. and J. Schoenwaelder, "On the Difference between [8] Pras, A. and J. Schoenwaelder, "On the Difference between
Information Models and Data Models", RFC 3444, January 2003. Information Models and Data Models", RFC 3444, January 2003.
[8] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the [9] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the
Use of Extensible Markup Language (XML) within IETF Protocols", Use of Extensible Markup Language (XML) within IETF Protocols",
BCP 70, RFC 3470, January 2003. BCP 70, RFC 3470, January 2003.
[9] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML [10] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C REC-xmlschema-1, Schema Part 1: Structures", W3C REC-xmlschema-1,
http://www.w3.org/TR/ xmlschema-1/, May 2001. http://www.w3.org/TR/ xmlschema-1/, May 2001.
[10] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", [11] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes",
W3C REC-xmlschema-2, http://www.w3.org/TR /xmlschema-2/, W3C REC-xmlschema-2, http://www.w3.org/TR /xmlschema-2/,
May 2001. May 2001.
[11] Davis, M. and M. Suignard, "UNICODE Security Considerations", [12] Davis, M. and M. Suignard, "UNICODE Security Considerations",
http://www.unicode.org/ reports/tr36/tr36-3.html, July 2005. http://www.unicode.org/ reports/tr36/tr36-3.html, July 2005.
Authors' Addresses Authors' Addresses
Joel Halpern Joel Halpern
Self Self
P.O. Box 6049 P.O. Box 6049
Leesburg,, VA 20178 Leesburg,, VA 20178
Phone: +1 703 371 3043 Phone: +1 703 371 3043
 End of changes. 72 change blocks. 
116 lines changed or deleted 160 lines changed or added

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