draft-ietf-forces-model-09.txt   draft-ietf-forces-model-10.txt 
Working Group: ForCES J. Halpern Working Group: ForCES J. Halpern
Internet-Draft Self Internet-Draft Self
Expires: June 23, 2008 E. Deleganes Expires: August 1, 2008 E. Deleganes
Intel Corp. Intel Corp.
J. Hadi Salim J. Hadi Salim
Znyx Networks Znyx Networks
December 21, 2007 January 29, 2008
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-09.txt draft-ietf-forces-model-10.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 June 23, 2008. This Internet-Draft will expire on August 1, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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. 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 [2]. requirements document, RFC3654 [3].
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Requirements on the FE model . . . . . . . . . . . . . . 7 2.1. Requirements on the FE model . . . . . . . . . . . . . . 7
2.2. The FE Model in Relation to FE Implementations . . . . . 8 2.2. The FE Model in Relation to FE Implementations . . . . . 8
2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8 2.3. The FE Model in Relation to the ForCES Protocol . . . . . 8
2.4. Modeling Language for the FE Model . . . . . . . . . . . 9 2.4. Modeling Language for the FE Model . . . . . . . . . . . 9
2.5. Document Structure . . . . . . . . . . . . . . . . . . . 9 2.5. Document Structure . . . . . . . . . . . . . . . . . . . 9
3. ForCES Model Concepts . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . 11 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 . . . . . . . . . 13 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 . . . . . . . . . . . . . . . . . . . . . 22 3.2.3. Packet Type . . . . . . . . . . . . . . . . . . . . . 23
3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 23 3.2.4. Metadata . . . . . . . . . . . . . . . . . . . . . . 24
3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 25 3.2.5. LFB Events . . . . . . . . . . . . . . . . . . . . . 26
3.2.6. LFB Component Properties . . . . . . . . . . . . . . 26 3.2.6. Component Properties . . . . . . . . . . . . . . . . 27
3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 27 3.2.7. LFB Versioning . . . . . . . . . . . . . . . . . . . 28
3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 27 3.2.8. LFB Inheritance . . . . . . . . . . . . . . . . . . . 28
3.3. ForCES Model Addressing . . . . . . . . . . . . . . . . . 28 3.3. ForCES Model Addressing . . . . . . . . . . . . . . . . . 29
3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 30 3.3.1. Addressing LFB Components: Paths and Keys . . . . . . 31
3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 31 3.4. FE Datapath Modeling . . . . . . . . . . . . . . . . . . 32
3.4.1. Alternative Approaches for Modeling FE Datapaths . . 31 3.4.1. Alternative Approaches for Modeling FE Datapaths . . 32
3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 35 3.4.2. Configuring the LFB Topology . . . . . . . . . . . . 36
4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 39 4. Model and Schema for LFB Classes . . . . . . . . . . . . . . 40
4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 40 4.1. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 40 4.2. <LFBLibrary> Element . . . . . . . . . . . . . . . . . . 41
4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 41 4.3. <load> Element . . . . . . . . . . . . . . . . . . . . . 42
4.4. <frameDefs> Element for Frame Type Declarations . . . . . 42 4.4. <frameDefs> Element for Frame Type Declarations . . . . . 43
4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 42 4.5. <dataTypeDefs> Element for Data Type Definitions . . . . 44
4.5.1. <typeRef> Element for Aliasing Existing Data Types . 45 4.5.1. <typeRef> Element for Aliasing Existing Data Types . 46
4.5.2. <atomic> Element for Deriving New Atomic Types . . . 46 4.5.2. <atomic> Element for Deriving New Atomic Types . . . 47
4.5.3. <array> Element to Define Arrays . . . . . . . . . . 46 4.5.3. <array> Element to Define Arrays . . . . . . . . . . 47
4.5.4. <struct> Element to Define Structures . . . . . . . . 50 4.5.4. <struct> Element to Define Structures . . . . . . . . 52
4.5.5. <union> Element to Define Union Types . . . . . . . . 51 4.5.5. <union> Element to Define Union Types . . . . . . . . 53
4.5.6. <alias> Element . . . . . . . . . . . . . . . . . . . 51 4.5.6. <alias> Element . . . . . . . . . . . . . . . . . . . 53
4.5.7. Augmentations . . . . . . . . . . . . . . . . . . . . 52 4.5.7. Augmentations . . . . . . . . . . . . . . . . . . . . 54
4.6. <metadataDefs> Element for Metadata Definitions . . . . . 53 4.6. <metadataDefs> Element for Metadata Definitions . . . . . 55
4.7. <LFBClassDefs> Element for LFB Class Definitions . . . . 54 4.7. <LFBClassDefs> Element for LFB Class Definitions . . . . 56
4.7.1. <derivedFrom> Element to Express LFB Inheritance . . 56 4.7.1. <derivedFrom> Element to Express LFB Inheritance . . 58
4.7.2. <inputPorts> Element to Define LFB Inputs . . . . . . 57 4.7.2. <inputPorts> Element to Define LFB Inputs . . . . . . 59
4.7.3. <outputPorts> Element to Define LFB Outputs . . . . . 59 4.7.3. <outputPorts> Element to Define LFB Outputs . . . . . 61
4.7.4. <components> Element to Define LFB Operational 4.7.4. <components> Element to Define LFB Operational
Components . . . . . . . . . . . . . . . . . . . . . 62
4.7.5. <capabilities> Element to Define LFB Capability
Components . . . . . . . . . . . . . . . . . . . . . 64 Components . . . . . . . . . . . . . . . . . . . . . 64
4.7.6. <events> Element for LFB Notification Generation . . 66 4.7.5. <capabilities> Element to Define LFB Capability
Components . . . . . . . . . . . . . . . . . . . . . 66
4.7.6. <events> Element for LFB Notification Generation . . 68
4.7.7. <description> Element for LFB Operational 4.7.7. <description> Element for LFB Operational
Specification . . . . . . . . . . . . . . . . . . . . 73 Specification . . . . . . . . . . . . . . . . . . . . 75
4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 73 4.8. Properties . . . . . . . . . . . . . . . . . . . . . . . 75
4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 73 4.8.1. Basic Properties . . . . . . . . . . . . . . . . . . 75
4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 75 4.8.2. Array Properties . . . . . . . . . . . . . . . . . . 77
4.8.3. String Properties . . . . . . . . . . . . . . . . . . 75 4.8.3. String Properties . . . . . . . . . . . . . . . . . . 77
4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 76 4.8.4. Octetstring Properties . . . . . . . . . . . . . . . 78
4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 77 4.8.5. Event Properties . . . . . . . . . . . . . . . . . . 79
4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 80 4.8.6. Alias Properties . . . . . . . . . . . . . . . . . . 82
4.9. XML Schema for LFB Class Library Documents . . . . . . . 81 4.9. XML Schema for LFB Class Library Documents . . . . . . . 83
5. FE Components and Capabilities . . . . . . . . . . . . . . . 92 5. FE Components and Capabilities . . . . . . . . . . . . . . . 94
5.1. XML for FEObject Class definition . . . . . . . . . . . . 93 5.1. XML for FEObject Class definition . . . . . . . . . . . . 95
5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 99 5.2. FE Capabilities . . . . . . . . . . . . . . . . . . . . . 101
5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 99 5.2.1. ModifiableLFBTopology . . . . . . . . . . . . . . . . 101
5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 100 5.2.2. SupportedLFBs and SupportedLFBType . . . . . . . . . 102
5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 102 5.3. FE Components . . . . . . . . . . . . . . . . . . . . . . 104
5.3.1. FEStatus . . . . . . . . . . . . . . . . . . . . . . 102 5.3.1. FEState . . . . . . . . . . . . . . . . . . . . . . . 104
5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 103 5.3.2. LFBSelectors and LFBSelectorType . . . . . . . . . . 105
5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 103 5.3.3. LFBTopology and LFBLinkType . . . . . . . . . . . . . 105
5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 103 5.3.4. FENeighbors and FEConfiguredNeighborType . . . . . . 105
6. Satisfying the Requirements on FE Model . . . . . . . . . . . 104 6. Satisfying the Requirements on FE Model . . . . . . . . . . . 106
7. Using the FE model in the ForCES Protocol . . . . . . . . . . 105 7. Using the FE model in the ForCES Protocol . . . . . . . . . . 107
7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 107 7.1. FE Topology Query . . . . . . . . . . . . . . . . . . . . 109
7.2. FE Capability Declarations . . . . . . . . . . . . . . . 108 7.2. FE Capability Declarations . . . . . . . . . . . . . . . 110
7.3. LFB Topology and Topology Configurability Query . . . . . 109 7.3. LFB Topology and Topology Configurability Query . . . . . 111
7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 109 7.4. LFB Capability Declarations . . . . . . . . . . . . . . . 111
7.5. State Query of LFB Attributes . . . . . . . . . . . . . . 110 7.5. State Query of LFB Attributes . . . . . . . . . . . . . . 112
7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 111 7.6. LFB Component Manipulation . . . . . . . . . . . . . . . 113
7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 111 7.7. LFB Topology Re-configuration . . . . . . . . . . . . . . 113
8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 111 8. Example LFB Definition . . . . . . . . . . . . . . . . . . . 113
8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 118 8.1. Data Handling . . . . . . . . . . . . . . . . . . . . . . 120
8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 119 8.1.1. Setting up a DLCI . . . . . . . . . . . . . . . . . . 121
8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 120 8.1.2. Error Handling . . . . . . . . . . . . . . . . . . . 122
8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 120 8.2. LFB Components . . . . . . . . . . . . . . . . . . . . . 122
8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 121 8.3. Capabilities . . . . . . . . . . . . . . . . . . . . . . 123
8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 121 8.4. Events . . . . . . . . . . . . . . . . . . . . . . . . . 123
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 122 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 124
10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 123 10. Authors Emeritus . . . . . . . . . . . . . . . . . . . . . . 125
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 123 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 125
12. Security Considerations . . . . . . . . . . . . . . . . . . . 124 12. Security Considerations . . . . . . . . . . . . . . . . . . . 126
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 124 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 126
13.1. Normative References . . . . . . . . . . . . . . . . . . 124 13.1. Normative References . . . . . . . . . . . . . . . . . . 126
13.2. Informative References . . . . . . . . . . . . . . . . . 124 13.2. Informative References . . . . . . . . . . . . . . . . . 126
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127
Intellectual Property and Copyright Statements . . . . . . . . . 126 Intellectual Property and Copyright Statements . . . . . . . . . 128
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 [2] and is not copied here. The following list of RFC3654 [3] and is not copied here. The following list of
terminology relevant to the FE model is defined in this section. terminology relevant to the FE model is defined in this section.
FE Model -- The FE model is designed to model the logical processing FE Model -- The FE model is designed to model the logical processing
functions of an FE. The FE model proposed in this document includes functions of an FE. The FE model proposed in this document includes
three components: the modeling of individual logical functional three components: the modeling of individual logical functional
blocks (LFB model), the logical interconnection between LFBs (LFB blocks (LFB model), the logical interconnection between LFBs (LFB
topology) and the FE level attributes, including FE capabilities. topology) and the FE level attributes, including FE capabilities.
The FE model provides the basis to define the information elements The FE model provides the basis to define the information elements
exchanged between the CE and the FE in the ForCES protocol. exchanged between the CE and the FE in the ForCES Protocol [2].
Datapath -- A conceptual path taken by packets within the forwarding Datapath -- A conceptual path taken by packets within the forwarding
plane inside an FE. Note that more than one datapath can exist plane inside an FE. Note that more than one datapath can exist
within an FE. within an FE.
LFB (Logical Functional Block) Class (or type) -- A template that LFB (Logical Functional Block) Class (or type) -- A template that
representing a fine-grained, logically separable aspect of FE representing a fine-grained, logically separable aspect of FE
processing. Most LFBs relate to packet processing in the data path. processing. Most LFBs relate to packet processing in the data path.
LFB classes are the basic building blocks of the FE model. LFB classes are the basic building blocks of the FE model.
LFB Instance -- As a packet flows through an FE along a datapath, it LFB Instance -- As a packet flows through an FE along a datapath, it
flows through one or multiple LFB instances, where each LFB is an flows through one or multiple LFB instances, where each LFB is an
instance of a specific LFB class. Multiple instances of the same LFB instance of a specific LFB class. Multiple instances of the same LFB
class can be present in an FE's datapath. Note that we often refer class can be present in an FE's datapath. Note that we often refer
to LFBs without distinguishing between an LFB class and LFB instance to LFBs without distinguishing between an LFB class and LFB instance
when we believe the implied reference is obvious for the given when we believe the implied reference is obvious for the given
context. context.
LFB Model -- The LFB model describes the content and structures in an LFB Model -- The LFB model describes the content and structures in an
LFB, plus the associated data definition. XML is used to provide a LFB, plus the associated data definition. XML is used to provide a
formal definition of the LFB model. Four types of information are formal definition of the necessary structures for the modeling. Four
defined in the LFB model. The core part of the LFB model is the LFB types of information are defined in the LFB model. The core part of
class definitions; the other three types define the associated data the LFB model is the LFB class definitions; the other three types of
including common data types, supported frame formats and metadata. information define constructs associated with and used by the class
definition. These are reusable data types, supported frame formats,
and metadata.
Element -- Element is generally used in this document in accordance Element -- Element is generally used in this document in accordance
with the XML usage of the term. It refers to an XML tagged part of with the XML usage of the term. It refers to an XML tagged part of
an XML document. For a precise definition, please see the full set an XML document. For a precise definition, please see the full set
of XML specifications from the W3C. This term is included in this of XML specifications from the W3C. This term is included in this
list for completeness because ForCES formal model uses XML. list for completeness because ForCES formal model uses XML.
Attribute -- Attribute is used in the ForCES formal modelling in Attribute -- Attribute is used in the ForCES formal modelling in
accordance with standard XML usage of the term. i.e to provide accordance with standard XML usage of the term. i.e to provide
attribute information include in an XML tag. attribute information include in an XML tag.
skipping to change at page 6, line 20 skipping to change at page 6, line 22
LFB Metadata -- Metadata is used to communicate per-packet state from LFB Metadata -- Metadata is used to communicate per-packet state from
one LFB to another, but is not sent across the network. The FE model one LFB to another, but is not sent across the network. The FE model
defines how such metadata is identified, produced and consumed by the defines how such metadata is identified, produced and consumed by the
LFBs, but not how the per-packet state is implemented within actual LFBs, but not how the per-packet state is implemented within actual
hardware. Metadata is sent between the FE and the CE on redirect hardware. Metadata is sent between the FE and the CE on redirect
packets. packets.
ForCES Component -- a ForCES Component is a well defined, uniquely ForCES Component -- a ForCES Component is a well defined, uniquely
identifiable and addressable ForCES model building block. A identifiable and addressable ForCES model building block. A
component has a 32-bit ID, name, type and an optional synopsis component has a 32-bit ID, name, type and an optional synopsis
description. description. These are often referred to simply as components.
LFB Component -- A ForCES component that defines the Operational LFB Component -- A ForCES component that defines the Operational
parameters of the LFBs that must be visible to the CEs. parameters of the LFBs that must be visible to the CEs.
Structure Component -- A ForCES component that defines complex data Structure Component -- A ForCES component that is part of a complex
structures to be used in LFB data definitions. Generally, these data structure to be used in LFB data definitions. The individual
include tables and Structures. The individual parts which make up a parts which make up a structured set of data are referred to as
structured set of data are referred to as Structure Components. Structure Components. These can themselves be of any valid data
These can themselves be of any valid data type, including tables and type, including tables and structures.
structures.
LFB Topology -- A representation of the logical interconnection and LFB Topology -- A representation of the logical interconnection and
the placement of LFB instances along the datapath within one FE. the placement of LFB instances along the datapath within one FE.
Sometimes this representation is called intra-FE topology, to be Sometimes this representation is called intra-FE topology, to be
distinguished from inter-FE topology. LFB topology is outside of the distinguished from inter-FE topology. LFB topology is outside of the
LFB model, but is part of the FE model. LFB model, but is part of the FE model.
FE Topology -- A representation of how multiple FEs within a single FE Topology -- A representation of how multiple FEs within a single
NE are interconnected. Sometimes this is called inter-FE topology, NE are interconnected. Sometimes this is called inter-FE topology,
to be distinguished from intra-FE topology (i.e., LFB topology). An to be distinguished from intra-FE topology (i.e., LFB topology). An
skipping to change at page 7, line 8 skipping to change at page 7, line 9
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 [3] specifies a framework by which control elements (CEs) can RFC3746 [4] 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 [2] mandates that the capabilities, states and FEs. RFC3654 [3] 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 [8] observed that information models (IMs) and data models RFC3444 [7] 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 [2]defines requirements that must be satisfied by a ForCES FE RFC3654 [3]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
skipping to change at page 7, line 48 skipping to change at page 8, line 4
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 (i.e., attributes) 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 of 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 should be designed such that along with metadata. The FE model is designed, and any defined LFB
different implementations of the forwarding datapath can be logically classes should be designed, such that different implementations of
mapped onto the model with the functionality and sequence of the forwarding datapath can be logically mapped onto the model with
operations correctly captured. However, the model is not intended to the functionality and sequence of operations correctly captured.
directly address how a particular implementation maps to an LFB However, the model is not intended to directly address how a
topology. It is left to the forwarding plane vendors to define how particular implementation maps to an LFB topology. It is left to the
the FE functionality is represented using the FE model. Our goal is forwarding plane vendors to define how the FE functionality is
to design the FE model such that it is flexible enough to accommodate represented using the FE model. Our goal is to design the FE model
most common implementations. such that it is flexible enough to accommodate most common
implementations.
The LFB topology model for a particular datapath implementation must The LFB topology model for a particular datapath implementation must
correctly capture the sequence of operations on the packet. Metadata correctly capture the sequence of operations on the packet. Metadata
generation by certain LFBs MUST always precede any use of that generation by certain LFBs MUST always precede any use of that
metadata by subsequent LFBs in the topology graph; this is required metadata by subsequent LFBs in the topology graph; this is required
for logically consistent operation. Further, modification of packet for logically consistent operation. Further, modification of packet
fields that are subsequently used as inputs for further processing fields that are subsequently used as inputs for further processing
MUST occur in the order specified in the model for that particular MUST occur in the order specified in the model for that particular
implementation to ensure correctness. implementation to ensure correctness.
2.3. The FE Model in Relation to the ForCES Protocol 2.3. The FE Model in Relation to the ForCES Protocol
The ForCES base protocol is used by the CEs and FEs to maintain the The ForCES base Protocol [2] is used by the CEs and FEs to maintain
communication channel between the CEs and FEs. The ForCES protocol the communication channel between the CEs and FEs. The ForCES
may be used to query and discover the inter-FE topology. The details protocol may be used to query and discover the inter-FE topology.
of a particular datapath implementation inside an FE, including the The details of a particular datapath implementation inside an FE,
LFB topology, along with the operational capabilities and attributes including the LFB topology, along with the operational capabilities
of each individual LFB, are conveyed to the CE within information and attributes of each individual LFB, are conveyed to the CE within
elements in the ForCES protocol. The model of an LFB class should information elements in the ForCES protocol. The model of an LFB
define all of the information that needs to be exchanged between an class should define all of the information that needs to be exchanged
FE and a CE for the proper configuration and management of that LFB. between an FE and a CE for the proper configuration and management of
that LFB.
Specifying the various payloads of the ForCES messages in a Specifying the various payloads of the ForCES messages in a
systematic fashion is difficult without a formal definition of the systematic fashion is difficult without a formal definition of the
objects being configured and managed (the FE and the LFBs within). objects being configured and managed (the FE and the LFBs within).
The FE Model document defines a set of classes and components for The FE Model document defines a set of classes and components for
describing and manipulating the state of the LFBs within an FE. describing and manipulating the state of the LFBs within an FE.
These class definitions themselves will generally not appear in the These class definitions themselves will generally not appear in the
ForCES protocol. Rather, ForCES protocol operations will reference ForCES protocol. Rather, ForCES protocol operations will reference
classes defined in this model, including relevant components and the classes defined in this model, including relevant components and the
defined operations. defined operations.
Section 7 provides more detailed discussion on how the FE model Section 7 provides more detailed discussion on how the FE model
should be used by the ForCES protocol. should be used by the ForCES protocol.
2.4. Modeling Language for the FE Model 2.4. Modeling Language for the FE Model
skipping to change at page 9, line 31 skipping to change at page 9, line 36
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 [9] define the structure of the LFB Library documents, as defined in [8]
and [10]. While these LFB Class definitions are not sent in the and [9] and [10]. While these LFB Class definitions are not sent in
ForCES protocol, these definitions comply with the recommendations in the ForCES protocol, these definitions comply with the
RFC3470 [9] on the use of XML in IETF protocols. recommendations in RFC3470 [8] 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 [2] while Section 7 explains ForCES requirements defined in RFC3654 [3] 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 10, line 26 skipping to change at page 10, line 31
specific components (example would be a table size limit). specific components (example would be a table size limit).
o The state model describes the current state of the FE/LFB, that o The state model describes the current state of the FE/LFB, that
is, the instantaneous values or operational behavior of the FE/ is, the instantaneous values or operational behavior of the FE/
LFB. LFB.
Section 3.1 explains the difference between a capability model and a Section 3.1 explains the difference between a capability model and a
state model, and describes how the two can be combined in the FE state model, and describes how the two can be combined in the FE
model. model.
The ForCES model construction proposed in this document has two major The ForCES model construction laid out in this document allows an FE
hierarchies. At the lower layer, an individual LFB class definition to provide information about its structure for operation. This can
models the distinct manageable feature of an FE. At a higher be thought of as FE level information and information about the
abstraction, the FE is laid out to constitute many LFB abstractions. individual instances of LFBs provided by the FE.
o The LFB model provides the content and data structures to define o The ForCES model includes the constructions for defining the class
each individual LFB class. Each LFB model class formally defines of logical function blocks (LFBS) that an FE may support. These
the operational LFB components, LFB capabilities, and LFB events. classes are defined in this and other documents. The definition
Essentially, Section 3.2 introduces the concept of LFBs as the of such a class provides the information content for monitoring
basic functional building blocks in the ForCES model. and controlling instances of the LFB class for ForCES purposes.
Each LFB model class formally defines the operational LFB
components, LFB capabilities, and LFB events. Essentially,
Section 3.2 introduces the concept of LFBs as the basic functional
building blocks in the ForCES model.
o The FE model provides a definition whose components include FE o The FE model also provides the construction necessary to monitor
capability information, the different LFBs and their topology and control the FE as a whole for ForCES purposes. For
information. For consistency, the FE Object class is defined consistency of operation and simplicity, this information is
using the LFB model. The FE Object class defines the components represented as an LFB, the FE Object LFB class and a singular LFB
to provide information at the FE level, particularly the instance of that class, defined using the LFB model. The FE
capabilities of the FE at a coarse level. Part of the FE level Object class defines the components to provide information at the
information is the LFB topology, which expresses the logical FE level, particularly the capabilities of the FE at a coarse
inter-connection between the LFB instances along the datapath(s) level, i.e. not all possible capabilities nor all details about
within the FE. Section 3.3 discusses the LFB topology. the capabilities of the FE. Part of the FE level information is
the LFB topology, which expresses the logical inter-connection
between the LFB instances along the datapath(s) within the FE.
Section 3.3 discusses the LFB topology. The FE Object also
includes information about what LFB classes the FE can support.
The ForCES model allows for unique addressing of the different The ForCES model allows for unique identification of the different
construct within its definition. constructs it defines. This includes identification of the LFB
classes, and of LFB instances within those classes, as well as
identification of components within those instances.
The ForCES protocol encapsulates target address(es) to eventually get The ForCES Protocol [2] encapsulates target address(es) to eventually
to a fine-grained entity being referenced by the CE. The addressing get to a fine-grained entity being referenced by the CE. The
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 identities which
are unique within a particular LFB class on that FE. are unique within a particular LFB class on that FE.
skipping to change at page 12, line 34 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 [4] and Framework PIB RFC3318 approaches include DiffServ PIB RFC3317 [5] and Framework PIB RFC3318
[5]. [6].
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 14, line 23 skipping to change at page 14, line 45
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 FEs will not have the packet oriented properties
described in this section. described in this section.
An LFB can have one or more inputs, each of which takes a packet P, An LFB can have one or more inputs. Each input takes a pair of a
and optionally metadata M; and produces one or more outputs, each of packet and its associated metadata. Depending upon the LFB input
which carries a packet P', and optionally metadata M'. Metadata is port definition, the packet or the metadata may be allowed to be
data associated with the packet in the network processing device empty (or equivalently to not be provided.) At least one of the two
(router, switch, etc.) and is passed from one LFB to the next, but is must be non-empty, or there is no input. The LFB processes the
not sent across the network. In general, multiple LFBs are contained input, and produces one or more outputs, each of which is a pair of a
in one FE, as shown in Figure 2, and all the LFBs share the same packet and its associated metadata. Again, depending upon the LFB
ForCES protocol termination point that implements the ForCES protocol output port definition, either the packet or the metadata may be
logic and maintains the communication channel to and from the CE. 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 15, line 35 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 [3]) and the ForCES protocol termination point (defined in RFC3746 [4]) 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
skipping to change at page 19, line 13 skipping to change at page 19, line 44
IPv4 and an IPv6 path based on a FRAMETYPE metadata (N=2), or to fork IPv4 and an IPv6 path based on a FRAMETYPE metadata (N=2), or to fork
into color specific paths after metering using the COLOR metadata into color specific paths after metering using the COLOR metadata
(red, yellow, green; N=3), etc. (red, yellow, green; N=3), etc.
Using an output group in the above LFB class provides the desired Using an output group in the above LFB class provides the desired
flexibility to adapt each instance of this class to the required flexibility to adapt each instance of this class to the required
operation. The metadata to be used as a selector for the output operation. The metadata to be used as a selector for the output
instance is a property of the LFB. For each packet, the value of the instance is a property of the LFB. For each packet, the value of the
specified metadata may be used as a direct index to the output specified metadata may be used as a direct index to the output
instance. Alternatively, the LFB may have a configurable selector instance. Alternatively, the LFB may have a configurable selector
table that maps a metadata value to output instance. table that maps a metadatum value to output instance.
Note that other LFBs may also use the output group concept to build Note that other LFBs may also use the output group concept to build
in similar adaptive forking capability. For example, a classifier in similar adaptive forking capability. For example, a classifier
LFB with one input and N outputs can be defined easily by using the LFB with one input and N outputs can be defined easily by using the
output group concept. Alternatively, a classifier LFB with one output group concept. Alternatively, a classifier LFB with one
singleton output in combination with an explicit N-output re- singleton output in combination with an explicit N-output re-
director LFB models the same processing behavior. The decision of director LFB models the same processing behavior. The decision of
whether to use the output group model for a certain LFB class is left whether to use the output group model for a certain LFB class is left
to the LFB class designers. to the LFB class designers.
skipping to change at page 24, line 6 skipping to change at page 25, line 6
maximum extensibility, this definition should neither specify which maximum extensibility, this definition should neither specify which
LFBs the metadata is expected to come from for a consumer LFB, nor LFBs the metadata is expected to come from for a consumer LFB, nor
which LFBs are expected to consume metadata for a given producer LFB. which LFBs are expected to consume metadata for a given producer LFB.
3.2.4.2. Metadata Production and Consumption 3.2.4.2. Metadata Production and Consumption
For a given metadata on a given packet path, there MUST be at least For a given metadata on a given packet path, there MUST be at least
one producer LFB that creates that metadata and SHOULD be at least one producer LFB that creates that metadata and SHOULD be at least
one consumer LFB that needs that metadata. one consumer LFB that needs that metadata.
In the ForCES model, the producer and consumer LFBs of a metadata are In the ForCES model, the producer and consumer LFBs of a metadatum
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. In the
case of conditional metadata, it should be possible to determine from case of conditional metadata, it should be possible to determine from
skipping to change at page 25, line 11 skipping to change at page 26, line 11
create new metadata) create new metadata)
* READ-AND-CONSUME: reads and consumes the metadata * READ-AND-CONSUME: reads and consumes the metadata
* CONSUME consumes metadata without reading * CONSUME consumes metadata without reading
The last two operations terminate the life-cycle of the metadata, The last two operations terminate the life-cycle of the metadata,
meaning that the metadata is not forwarded with the packet when the meaning that the metadata is not forwarded with the packet when the
packet is sent to the next LFB. packet is sent to the next LFB.
In the ForCES model, a new metadata is generated by an LFB when the In the ForCES model, a new metadata is generated by an LFB when the
LFB applies a WRITE operation to a metadata type that was not present LFB applies a WRITE operation to a metadatum type that was not
when the packet was received by the LFB. Such implicit creation may present when the packet was received by the LFB. Such implicit
be unintentional by the LFB, that is, the LFB may apply the WRITE creation may be unintentional by the LFB, that is, the LFB may apply
operation without knowing or caring if the given metadata existed or the WRITE operation without knowing or caring if the given metadata
not. If it existed, the metadata gets over-written; if it did not existed or not. If it existed, the metadata gets over-written; if it
exist, the metadata is created. did not exist, the metadata is created.
For LFBs that insert packets into the model, WRITE is the only For LFBs that insert packets into the model, WRITE is the only
meaningful metadata operation. meaningful metadata operation.
For LFBs that remove the packet from the model, they may either READ- For LFBs that remove the packet from the model, they may either READ-
AND-CONSUME (read) or CONSUME (ignore) each active metadata AND-CONSUME (read) or CONSUME (ignore) each active metadata
associated with the packet. associated with the packet.
3.2.5. LFB Events 3.2.5. LFB Events
skipping to change at page 26, line 44 skipping to change at page 27, line 44
the next step. the next step.
3. checking (runtime set) event filters if they exist to see if the 3. checking (runtime set) event filters if they exist to see if the
event should be reported or suppressed. If the event is to be event should be reported or suppressed. If the event is to be
reported proceed to the next step. reported proceed to the next step.
4. Submitting of the declared report to the CE. 4. Submitting of the declared report to the CE.
Section 4.7.6 discusses events in more details. Section 4.7.6 discusses events in more details.
3.2.6. LFB Component Properties 3.2.6. Component Properties
LFBs are made up of components, containing the information that the LFBs and structures are made up of components, containing the
CE needs to see and/or change about the functioning of the LFB. information that the CE needs to see and/or change about the
These components, as described in detail in Section 4.7, may be basic functioning of the LFB. These Components, as described in detail in
values, complex structures (containing multiple components Section 4.7, may be basic values, complex structures (containing
themselves, each of which can be values, structures, or tables), or multiple Components themselves, each of which can be values,
tables (which contain values, structures or tables). Some of these structures, or tables), or tables (which contain values, structures
components are optional. Components may be readable or writeable at or tables). Some of these Components are optional. Components may
the discretion of the FE implementation. The CE needs to know these be readable or writeable at the discretion of the FE implementation.
properties. Additionally, certain kinds of components (arrays / The CE needs to know these properties. Additionally, certain kinds
tables, aliases, and events as of this writing) have additional of Components (arrays / tables, aliases, and events as of this
property information that the CE may need to read or write. This writing) have additional property information that the CE may need to
model defines the structure of the property information for all read or write. This model defines the structure of the property
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.6) has special rules. If
an FE datapath model containing an LFB instance of a particular class an FE datapath model containing an LFB instance of a particular class
skipping to change at page 31, line 46 skipping to change at page 32, line 46
splitting the LFB topology into alternative paths. In other words, splitting the LFB topology into alternative paths. In other words,
if the result of an LFB operation controls how the packet is further if the result of an LFB operation controls how the packet is further
processed, then such an LFB will have separate output ports, one for processed, then such an LFB will have separate output ports, one for
each alternative treatment, connected to separate sub-graphs, each each alternative treatment, connected to separate sub-graphs, each
expressing the respective treatment downstream. expressing the respective treatment downstream.
o Encoded State Approach o Encoded State Approach
An alternate way of expressing differential treatment is by using An alternate way of expressing differential treatment is by using
metadata. The result of the operation of an LFB can be encoded in a metadata. The result of the operation of an LFB can be encoded in a
metadata, which is passed along with the packet to downstream LFBs. metadatum, which is passed along with the packet to downstream LFBs.
A downstream LFB, in turn, can use the metadata and its value (e.g., A downstream LFB, in turn, can use the metadata and its value (e.g.,
as an index into some table) to determine how to treat the packet. as an index into some table) to determine how to treat the packet.
Theoretically, either approach could substitute for the other, so one Theoretically, either approach could substitute for the other, so one
could consider using a single pure approach to describe all datapaths could consider using a single pure approach to describe all datapaths
in an FE. However, neither model by itself results in the best in an FE. However, neither model by itself results in the best
representation for all practically relevant cases. For a given FE representation for all practically relevant cases. For a given FE
with certain logical datapaths, applying the two different modeling with certain logical datapaths, applying the two different modeling
approaches will result in very different looking LFB topology graphs. approaches will result in very different looking LFB topology graphs.
A model using only the topological approach may require a very large A model using only the topological approach may require a very large
skipping to change at page 32, line 28 skipping to change at page 33, line 28
like when using the pure topological approach. Each output from the like when using the pure topological approach. Each output from the
classifier goes to one of the N LFBs where no metadata is needed. classifier goes to one of the N LFBs where no metadata is needed.
The topological approach is simple, straightforward and graphically The topological approach is simple, straightforward and graphically
intuitive. However, if N is large and the N nodes following the intuitive. However, if N is large and the N nodes following the
classifier (LFB#1, LFB#2, ..., LFB#N) all belong to the same LFB type classifier (LFB#1, LFB#2, ..., LFB#N) all belong to the same LFB type
(e.g., meter), but each has its own independent components, the (e.g., meter), but each has its own independent components, the
encoded state approach gives a much simpler topology representation, encoded state approach gives a much simpler topology representation,
as shown in Figure 7.b. The encoded state approach requires that a as shown in Figure 7.b. The encoded state approach requires that a
table of N rows of meter components is provided in the Meter node table of N rows of meter components is provided in the Meter node
itself, with each row representing the attributes for one meter itself, with each row representing the attributes for one meter
instance. A metadata M is also needed to pass along with the packet instance. A metadatum M is also needed to pass along with the packet
P from the classifier to the meter, so that the meter can use M as a P from the classifier to the meter, so that the meter can use M as a
look-up key (index) to find the corresponding row of the attributes look-up key (index) to find the corresponding row of the attributes
that should be used for any particular packet P. that should be used for any particular packet P.
What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same What if those N nodes (LFB#1, LFB#2, ..., LFB#N) are not of the same
type? For example, if LFB#1 is a queue while the rest are all type? For example, if LFB#1 is a queue while the rest are all
meters, what is the best way to represent such datapaths? While it meters, what is the best way to represent such datapaths? While it
is still possible to use either the pure topological approach or the is still possible to use either the pure topological approach or the
pure encoded state approach, the natural combination of the two pure encoded state approach, the natural combination of the two
appears to be the best option. Figure 7.c depicts two different appears to be the best option. Figure 7.c depicts two different
skipping to change at page 40, line 46 skipping to change at page 41, line 46
only metadata definitions, another may contain only LFB class only metadata definitions, another may contain only LFB class
definitions, yet another may contain all of the above. definitions, yet another may contain all of the above.
In addition to the above main elements, a library document can import In addition to the above main elements, a library document can import
other library documents if it needs to refer to definitions contained other library documents if it needs to refer to definitions contained
in the included document. This concept is similar to the "#include" in the included document. This concept is similar to the "#include"
directive in C. Importing is expressed by the use of <load> elements, directive in C. Importing is expressed by the use of <load> elements,
which must precede all the above elements in the document. For which must precede all the above elements in the document. For
unique referencing, each LFBLibrary instance document has a unique unique referencing, each LFBLibrary instance document has a unique
label defined in the "provide" attribute of the LFBLibrary element. 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> The <LFBLibrary> element also includes an optional <description>
element, which can be used to provide textual description about the element, which can be used to provide textual description about the
library document. library document.
The following is a skeleton of a library document: The following is a skeleton of a library document:
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel" <LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel"
provides="this_library"> provides="this_library">
skipping to change at page 44, line 49 skipping to change at page 45, line 49
atomic data type. They may be a structure of named components of atomic data type. They may be a structure of named components of
compound or atomic data types (ala C structures). They may be a compound or atomic data types (ala C structures). They may be a
union of named components of compound or atomic data types (ala C union of named components of compound or atomic data types (ala C
unions). They may also be defined as augmentations (explained 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 protocol document to define, not the such representations are for the ForCES Protocol [2] document to
model document. Strings and octetstrings must be conveyed with their define, not the model document. Strings and octetstrings must be
length, as they are not delimited, and are variable length. conveyed with their length, as they are not delimited, and are
variable length.
With regard to strings, this model defines a small set of With regard to strings, this model defines a small set of
restrictions and definitions on how they are structured. String and restrictions and definitions on how they are structured. String and
octetstring length limits can be specified in the LFB Class octetstring length limits can be specified in the LFB Class
definitions. The component properties for string and octetstring definitions. The component properties for string and octetstring
components also contain actual lengths and length limits. This components also contain actual lengths and length limits. This
duplication of limits is to allow for implementations with smaller duplication of limits is to allow for implementations with smaller
limits than the maximum limits specified in the LFB Class definition. limits than the maximum limits specified in the LFB Class definition.
In all cases, these lengths are specified in octets, not in In all cases, these lengths are specified in octets, not in
characters. In terms of protocol operation, as long as the specified characters. In terms of protocol operation, as long as the specified
length is within the FE's supported capabilities, the FE stores the length is within the FE's supported capabilities, the FE stores the
contents of a string exactly as provided by the CE, and returns those contents of a string exactly as provided by the CE, and returns those
contents when requested. No canonicalization, transformations, or contents when requested. No canonicalization, transformations, or
equivalences are performed by the FE. components of type string (or equivalences are performed by the FE. components of type string (or
string[n]) may be used to hold identifiers for correlation with string[n]) may be used to hold identifiers for correlation with
components in other LFBs. In such cases, an exact octet for octet components in other LFBs. In such cases, an exact octet for octet
match is used. No equivalences are used by the FE or CE in match is used. No equivalences are used by the FE or CE in
performing that matching. The ForCES protocol does not perform or performing that matching. The ForCES Protocol [2] does not perform
require validation of the content of UTF-8 strings. However, UTF-8 or require validation of the content of UTF-8 strings. However,
strings SHOULD be encoded in the shortest form to avoid potential UTF-8 strings SHOULD be encoded in the shortest form to avoid
security issues described in [12]. Any entity displaying such potential security issues described in [11]. Any entity displaying
strings is expected to perform its own validation (for example for such strings is expected to perform its own validation (for example
correct multi-byte characters, and for ensuring that the string does for correct multi-byte characters, and for ensuring that the string
not end in the middle of a multi-byte sequence.) Specific LFB class does not end in the middle of a multi-byte sequence.) Specific LFB
definitions may restrict the valid contents of a string as suited to class definitions may restrict the valid contents of a string as
the particular usage (for example, a component that holds a DNS name suited to the particular usage (for example, a component that holds a
would be restricted to hold only octets valid in such a name.) FEs DNS name would be restricted to hold only octets valid in such a
should validate the contents of SET requests for such restricted name.) FEs should validate the contents of SET requests for such
components at the time the set is performed, just as range checks for restricted components at the time the set is performed, just as range
range limited components are performed. The ForCES protocol behavior checks for range limited components are performed. The ForCES
defines the normative processing for requests using that protocol. protocol behavior defines the normative processing for requests using
that protocol.
For the definition of the actual type in the <dataTypeDef> element, For the definition of the actual type in the <dataTypeDef> element,
the following elements are available: <typeRef>, <atomic>, <array>, the following elements are available: <typeRef>, <atomic>, <array>,
<struct>, and <union>. <struct>, and <union>.
The predefined type alias is somewhere between the atomic and The predefined type alias is somewhere between the atomic and
compound data types. It behaves like a structure, one 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.
skipping to change at page 47, line 32 skipping to change at page 48, line 32
The result of this construct MUST always be a compound type, even if The result of this construct MUST always be a compound type, even if
the array has a fixed size of 1. the array has a fixed size of 1.
Arrays MUST only be subscripted by integers, and will be presumed to Arrays MUST only be subscripted by integers, and will be presumed to
start with index 0. start with index 0.
In addition to their subscripts, arrays may be declared to have In addition to their subscripts, arrays may be declared to have
content keys. Such a declaration has several effects: content keys. Such a declaration has several effects:
o Any declared key can be used in the ForCES protocol to select a o Any declared key can be used in the ForCES protocol to select a
component for operations (for details, see the protocol). component for operations (for details, see the ForCES Protocol
[2]).
o In any instance of the array, each declared key must be unique o In any instance of the array, each declared key must be unique
within that instance. No two components of an array may have the within that instance. No two components of an array may have the
same values on all the fields which make up a key. same values on all the fields which make up a key.
Each key is declared with a keyID for use in the protocol, where the Each key is declared with a keyID for use in the ForCES Protocol [2],
unique key is formed by combining one or more specified key fields. where the unique key is formed by combining one or more specified key
To support the case where an array of an atomic type with unique fields. To support the case where an array of an atomic type with
values can be referenced by those values, the key field identifier unique values can be referenced by those values, the key field
may be "*" (i.e., the array entry is the key). If the value type of identifier may be "*" (i.e., the array entry is the key). If the
the array is a structure or an array, then the key is one or more value type of the array is a structure or an array, then the key is
components of the value type, each identified by name. Since the one or more components of the value type, each identified by name.
field may be a component of the contained structure, a component of a Since the field may be a component of the contained structure, a
component of a structure, or further nested, the field name is component of a component of a structure, or further nested, the field
actually a concatenated sequence of component identifiers, separated name is actually a concatenated sequence of component identifiers,
by decimal points ("."). The syntax for key field identification is separated by decimal points ("."). The syntax for key field
given following the array examples. identification is given following the array examples.
The following example shows the definition of a fixed size array with The following example shows the definition of a fixed size array with
a pre-defined data type as the array content type: a pre-defined data type as the array content type:
<dataTypeDef> <dataTypeDef>
<name>dscp-mapping-table</name> <name>dscp-mapping-table</name>
<synopsis> <synopsis>
A table of 64 DSCP values, used to re-map code space. A table of 64 DSCP values, used to re-map code space.
</synopsis> </synopsis>
<array type="fixed-size" length="64"> <array type="fixed-size" length="64">
skipping to change at page 52, line 10 skipping to change at page 54, line 10
references (whcih is determined by the alias component properties, as references (whcih is determined by the alias component properties, as
described below) that component must be of the same type as that described below) that component must be of the same type as that
declared for the alias. Thus, when the CE or FE dereferences the declared for the alias. Thus, when the CE or FE dereferences the
alias component, the type of the information returned is known. 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 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 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 operation references the alias element, the value of the target is
returned or replaced. Write access to an alias element is permitted returned or replaced. Write access to an alias element is permitted
if write access to both the alias and the target are permitted. if write access to both the alias and the target are permitted.
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.
Details of the alias property structure are described in the section Details of the alias property structure are described in Section 4.8
of this document on properties. of this document on properties.
Note that the read / write property of the alias refers to the value. Note that the read / write property of the alias refers to the value.
The CE can only determine if it can write the target selection The CE can only determine if it can write the target selection
properties of the alias by attempting such a write operation. properties of the alias by attempting such a write operation.
(Property components do not themselves have properties.) (Property components do not themselves have properties.)
4.5.7. Augmentations 4.5.7. Augmentations
Compound types can also be defined as augmentations of existing Compound types can also be defined as augmentations of existing
skipping to change at page 53, line 14 skipping to change at page 55, line 14
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 within the augmentation
must not be the same as those in the structure type being augmented. must not be the same as those in the structure type being augmented.
4.6. <metadataDefs> Element for Metadata Definitions 4.6. <metadataDefs> Element for Metadata Definitions
The (optional) <metadataDefs> element in the library document The (optional) <metadataDefs> element in the library document
contains one or more <metadataDef> elements. Each <metadataDef> contains one or more <metadataDef> elements. Each <metadataDef>
element defines a metadata. element defines a 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 mandatory tag value to be used for this metadata, an
optional detailed description, and a mandatory type definition optional detailed description, and a mandatory type definition
information. Only atomic data types can be used as value types for information. Only atomic data types can be used as value types for
metadata. metadata.
skipping to change at page 56, line 45 skipping to change at page 58, line 45
</LFBClassDef> </LFBClassDef>
... ...
</LFBClassDefs> </LFBClassDefs>
The individual components and capabilities will have componentIDs for The individual components and capabilities will have componentIDs for
use by the ForCES protocol. These parallel the componentIDs used in use by the ForCES protocol. These parallel the componentIDs used in
structs, and are used the same way. Component and capability structs, and are used the same way. Component and capability
componentIDs must be unique within the LFB class definition. componentIDs must be unique within the LFB class definition.
Note that the <name>, <synopsis>, and < version> elements are Note that the <name>, <synopsis>, and < version> elements are
required, all other elements are optional in <LFBClassDef<. However, required, all other elements are optional in <LFBClassDef>. However,
when they are present, they must occur in the above order. when they are present, they must occur in the above order.
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.
skipping to change at page 58, line 7 skipping to change at page 60, line 7
provide a list of required metadata. Example: {"classid", provide a list of required metadata. Example: {"classid",
"vifid"}. This list should refer to names of metadata defined in "vifid"}. This list should refer to names of metadata defined in
the <metadataDefs> element in the same library document or in any the <metadataDefs> element in the same library document or in any
included library documents. For each metadata, it must be included library documents. For each metadata, it must be
specified whether the metadata is required or optional. For each specified whether the metadata is required or optional. For each
optional metadata, a default value must be specified, which is optional metadata, a default value must be specified, which is
used by the LFB if the metadata is not provided with a packet. used by the LFB if the metadata is not provided with a packet.
In addition, the optional "group" attribute of the <inputPort> In addition, the optional "group" attribute of the <inputPort>
element can specify if the port can behave as a port group, i.e., it element can specify if the port can behave as a port group, i.e., it
is allowed to be instantiated. This is indicated by a "yes" value is allowed to be instantiated. This is indicated by a "true" value
(the default value is "no"). (the default value is "false").
An example <inputPorts< element, defining two input ports, the second An example <inputPorts> element, defining two input ports, the second
one being an input port group: one being an input port group:
<inputPorts> <inputPorts>
<inputPort> <inputPort>
<name>in</name> <name>in</name>
<synopsis>Normal input</synopsis> <synopsis>Normal input</synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>ipv4</ref> <ref>ipv4</ref>
<ref>ipv6</ref> <ref>ipv6</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>classid</ref> <ref>classid</ref>
<ref>vifid</ref> <ref>vifid</ref>
<ref dependency="optional" defaultValue="0">vrfid</ref> <ref dependency="optional" defaultValue="0">vrfid</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
<inputPort group="yes"> <inputPort group="true">
... another input port ... ... another input port ...
</inputPort> </inputPort>
</inputPorts> </inputPorts>
For each <inputPort>, the frame type expectations are defined by the For each <inputPort>, the frame type expectations are defined by the
<frameExpected> element using one or more <ref> elements (see example <frameExpected> element using one or more <ref> elements (see example
above). When multiple frame types are listed, it means that "one of above). When multiple frame types are listed, it means that "one of
these" frame types is expected. A packet of any other frame type is these" frame types is expected. A packet of any other frame type is
regarded as incompatible with this input port of the LFB class. The regarded as incompatible with this input port of the LFB class. The
above example list two frames as expected frame types: "ipv4" and above example list two frames as expected frame types: "ipv4" and
"ipv6". "ipv6".
Metadata expectations are specified by the <metadataExpected> Metadata expectations are specified by the <metadataExpected>
element. In its simplest form, this element can contain a list of element. In its simplest form, this element can contain a list of
<ref> elements, each referring to a metadata. When multiple <ref> elements, each referring to a metadatum. When multiple
instances of metadata are listed by <ref> elements, it means that instances of metadata are listed by <ref> elements, it means that
"all of these" metadata must be received with each packet (except "all of these" metadata must be received with each packet (except
metadata that are marked as "optional" by the "dependency" attribute metadata that are marked as "optional" by the "dependency" attribute
ot the corresponding <ref> element). For a metadata that is of the corresponding <ref> element). For a metadatum that is
specified "optional", a default value MUST be provided using the specified "optional", a default value MUST be provided using the
"defaultValue" attribute. The above example lists three metadata as "defaultValue" attribute. The above example lists three metadata as
expected metadata, two of which are mandatory ("classid" and expected metadata, two of which are mandatory ("classid" and
"vifid"), and one being optional ("vrfid"). "vifid"), and one being optional ("vrfid").
The schema also allows for more complex definitions of metadata The schema also allows for more complex definitions of metadata
expectations. For example, using the <one-of> element, a list of expectations. For example, using the <one-of> element, a list of
metadata can be specified to express that at least one of the metadata can be specified to express that at least one of the
specified metadata must be present with any packet. For example: specified metadata must be present with any packet. For example:
skipping to change at page 60, line 27 skipping to change at page 62, line 27
{"classid", "color"}. This list should refer to names of metadata {"classid", "color"}. This list should refer to names of metadata
specified in the <metadataDefs> element in the same library specified in the <metadataDefs> element in the same library
document or in any included library documents. For each generated document or in any included library documents. For each generated
metadata, it should be specified whether the metadata is always metadata, it should be specified whether the metadata is always
generated or generated only in certain conditions. This generated or generated only in certain conditions. This
information is important when assessing compatibility between information is important when assessing compatibility between
LFBs. LFBs.
In addition, the optional "group" attribute of the <outputPort> In addition, the optional "group" attribute of the <outputPort>
element can specify if the port can behave as a port group, i.e., it element can specify if the port can behave as a port group, i.e., it
is allowed to be instantiated. This is indicated by a "yes" value is allowed to be instantiated. This is indicated by a "true" value
(the default value is "no"). (the default value is "false").
The following example specifies two output ports, the second being an The following example specifies two output ports, the second being an
output port group: output port group:
<outputPorts> <outputPorts>
<outputPort> <outputPort>
<name>out</name> <name>out</name>
<synopsis>Normal output</synopsis> <synopsis>Normal output</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>ipv4</ref> <ref>ipv4</ref>
<ref>ipv4bis</ref> <ref>ipv4bis</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>nhid</ref> <ref>nhid</ref>
<ref>nhtabid</ref> <ref>nhtabid</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="yes"> <outputPort group="true">
<name>exc</name> <name>exc</name>
<synopsis>Exception output port group</synopsis> <synopsis>Exception output port group</synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>ipv4</ref> <ref>ipv4</ref>
<ref>ipv4bis</ref> <ref>ipv4bis</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref availability="conditional">errorid</ref> <ref availability="conditional">errorid</ref>
</metadataProduced> </metadataProduced>
skipping to change at page 61, line 44 skipping to change at page 63, line 44
The types of frames and metadata the port produces are defined inside The types of frames and metadata the port produces are defined inside
the <product> element in each <outputPort>. Within the <product> the <product> element in each <outputPort>. Within the <product>
element, the list of frame types the port produces is listed in the element, the list of frame types the port produces is listed in the
<frameProduced> element. When more than one frame is listed, it <frameProduced> element. When more than one frame is listed, it
means that "one of" these frames will be produced. means that "one of" these frames will be produced.
The list of metadata that is produced with each packet is listed in The list of metadata that is produced with each packet is listed in
the optional <metadataProduced> element of the <product>. In its the optional <metadataProduced> element of the <product>. In its
simplest form, this element can contain a list of <ref> elements, simplest form, this element can contain a list of <ref> elements,
each referring to a metadata type. The meaning of such a list is each referring to a metadatum type. The meaning of such a list is
that "all of" these metadata are provided with each packet, except that "all of" these metadata are provided with each packet, except
those that are listed with the optional "availability" attribute set those that are listed with the optional "availability" attribute set
to "conditional". Similar to the <metadataExpected> element of the to "conditional". Similar to the <metadataExpected> element of the
<inputPort>, the <metadataProduced> element supports more complex <inputPort>, the <metadataProduced> element supports more complex
forms, which we do not discuss here further. forms, which we do not discuss here further.
4.7.4. <components> Element to Define LFB Operational Components 4.7.4. <components> Element to Define LFB Operational Components
Operational parameters of the LFBs that must be visible to the CEs Operational parameters of the LFBs that must be visible to the CEs
are conceptualized in the model as the LFB components. These are conceptualized in the model as the LFB components. These
skipping to change at page 69, line 31 skipping to change at page 71, line 31
If an <eventField> identifies a complex component then a further If an <eventField> identifies a complex component then a further
<eventField> may be used to refine the path to the target element. <eventField> may be used to refine the path to the target element.
Defined event Goof1changed demonstrates how a second <eventField> is Defined event Goof1changed demonstrates how a second <eventField> is
used to point to member f1 of the structure goo. used to point to member f1 of the structure goo.
If an <eventField> identifies an array then the following rules If an <eventField> identifies an array then the following rules
apply: apply:
o <eventSubscript> elements MUST be present as the next XML element o <eventSubscript> elements MUST be present as the next XML element
after an <eventField> which identifies an array component. after an <eventField> which identifies an array component.
<eventSubscript> MUST not occur other than after an array <eventSubscript> MUST NOT occur other than after an array
reference, as it is only meaningful in that context. reference, as it is only meaningful in that context.
o An <eventSubscript> may contain: o An <eventSubscript> may contain:
* A numeric value to indicate that the event applies to a * A numeric value to indicate that the event applies to a
specific entry (by index) of the array. As an example, event specific entry (by index) of the array. As an example, event
Gah11changed shows how table gah's index 11 is being targeted Gah11changed shows how table gah's index 11 is being targeted
for monitoring. for monitoring.
* It is expected that the more common usage is to have the event * It is expected that the more common usage is to have the event
skipping to change at page 70, line 7 skipping to change at page 72, line 7
for all indices). In that case, the value of the for all indices). In that case, the value of the
<eventSubscript> MUST be a name rather than a numeric value. <eventSubscript> MUST be a name rather than a numeric value.
That same name can then be used as the value of That same name can then be used as the value of
<eventSubscript> in <eventReport> elements as described below. <eventSubscript> in <eventReport> elements as described below.
An example of a wild card table index is shown in event An example of a wild card table index is shown in event
NewBarentry where the <eventSubscript> value is named NewBarentry where the <eventSubscript> value is named
_barIndex_ _barIndex_
o An <eventField> may follow an <eventSubscript> to further refine o An <eventField> may follow an <eventSubscript> to further refine
the path to the target element (Note: this is in the same spirit the path to the target element (Note: this is in the same spirit
as the case where <eventField> is used to further refine as the case where <eventField> is used to further refine
<eventField> in the ealier example of a complex structure example <eventField> in the earlier example of a complex structure example
of Goof1changed). The example event Gah10field1 illustrates the of Goof1changed). The example event Gah10field1 illustrates how
how the column field1 of table gah is monitored for changes. the column field1 of table gah is monitored for changes.
It should be emphasized that the name in an <eventSubscript> element It should be emphasized that the name in an <eventSubscript> element
in defined event NewbarEntry is not a component name. It is a in defined event NewbarEntry is not a component name. It is a
variable name for use in the <eventReport> elements (described in variable name for use in the <eventReport> elements (described in
Section 4.7.6.3) of the given LFB definition. This name MUST be Section 4.7.6.3) of the given LFB definition. This name MUST be
distinct from any component name that can validly occur in the distinct from any component name that can validly occur in the
<eventReport> clause. <eventReport> clause.
4.7.6.2. <eventCondition> Element 4.7.6.2. <eventCondition> Element
skipping to change at page 72, line 43 skipping to change at page 74, line 43
crossing, and filtering conditions that may reduce the set of event crossing, and filtering conditions that may reduce the set of event
notifications generated by the FE. Details of the filtering notifications generated by the FE. Details of the filtering
conditions that can be applied are given in that section. The conditions that can be applied are given in that section. The
filtering conditions allow the FE to suppress floods of events that filtering conditions allow the FE to suppress floods of events that
could result from oscillation around a condition value. For FEs that could result from oscillation around a condition value. For FEs that
do not wish to support filtering, the filter properties can either be do not wish to support filtering, the filter properties can either be
read only or not supported. read only or not supported.
In addition to identifying the event sources, the CE also uses the In addition to identifying the event sources, the CE also uses the
event path to activate runtime control of the event via the event event path to activate runtime control of the event via the event
properties (defined in Section 4.8.5) utilizing SET-PROP protocol properties (defined in Section 4.8.5) utilizing SET-PROP as defined
operation. in ForCES Protocol [2] operation.
To activate event generation on the FE, a SET-PROP message To activate event generation on the FE, a SET-PROP message
referencing the event and registration property of the event is referencing the event and registration property of the event is
issued to the FE by the CE with any prefix of the path of the event. issued to the FE by the CE with any prefix of the path of the event.
So, for an event defined on the example table bar, a SET-PROP with a So, for an event defined on the example table bar, a SET-PROP with a
path of 7.9 will subscribe the CE to all occurrences of that event on path of 7.9 will subscribe the CE to all occurrences of that event on
any entry of the table. This is particularly useful for the any entry of the table. This is particularly useful for the
<eventCreated/> and <eventDestroyed/> conditions on tables. Events <eventCreated/> and <eventDestroyed/> conditions on tables. Events
using those conditions will generally be defined with a field/ using those conditions will generally be defined with a field/
subscript sequence that identifies an array and ends with an subscript sequence that identifies an array and ends with an
skipping to change at page 80, line 7 skipping to change at page 82, line 7
the FE MUST track the value of the element and make sure that the the FE MUST track the value of the element and make sure that the
condition has become untrue by at least the hysteresis from the event condition has become untrue by at least the hysteresis from the event
property. To be specific, if the hysteresis is V, then property. To be specific, if the hysteresis is V, then
o For a <eventChanged/> condition, if the last notification was for o For a <eventChanged/> condition, if the last notification was for
value X, then the <changed/> notification MUST NOT be generated value X, then the <changed/> notification MUST NOT be generated
until the value reaches X +/- V. until the value reaches X +/- V.
o For a <eventGreaterThan/> condition with threshold T, once the o For a <eventGreaterThan/> condition with threshold T, once the
event has been generated at least once it MUST NOT be generated event has been generated at least once it MUST NOT be generated
again until the field first becomes less than or equal to T - -V, again until the field first becomes less than or equal to T - V,
and then exceeds T. and then exceeds T.
o For a <eventLessThan/> condition with threshold T, once the event o For a <eventLessThan/> condition with threshold T, once the event
has been generate at least once it MUST NOT be generated again has been generate at least once it MUST NOT be generated again
until the field first becomes greater than or equal to T + V, and until the field first becomes greater than or equal to T + V, and
then becomes less than T. then becomes less than T.
4.8.5.3. Event Count Filtering 4.8.5.3. Event Count Filtering
Events may have a count filtering condition. This property, if set Events may have a count filtering condition. This property, if set
skipping to change at page 81, line 25 skipping to change at page 83, line 25
<component componentID="3"> <component componentID="3">
<name>targetLFBInstance</name> <name>targetLFBInstance</name>
<synopsis>the instance ID of the alias target</synopsis> <synopsis>the instance ID of the alias target</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
<component componentID="4"> <component componentID="4">
<name>targetComponentPath</name> <name>targetComponentPath</name>
<synopsis> <synopsis>
the path to the component target the path to the component target
each 4 octets is read as one path element, each 4 octets is read as one path element,
using the path construction in the PL protocol. using the path construction in the PL protocol,
[2].
</synopsis> </synopsis>
<typeRef>octetstring[128]</typeRef> <typeRef>octetstring[128]</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
4.9. XML Schema for LFB Class Library Documents 4.9. XML Schema for LFB Class Library Documents
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://ietf.org/forces/1.0/lfbmodel" xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:lfb="http://ietf.org/forces/1.0/lfbmodel" xmlns:lfb="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
targetNamespace="http://ietf.org/forces/1.0/lfbmodel" targetNamespace="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
attributeFormDefault="unqualified" attributeFormDefault="unqualified"
elementFormDefault="qualified"> elementFormDefault="qualified">
<xsd:annotation> <xsd:annotation>
<xsd:documentation xml:lang="en"> <xsd:documentation xml:lang="en">
Schema for Defining LFB Classes and associated types (frames, Schema for Defining LFB Classes and associated types (frames,
data types for LFB attributes, and metadata). data types for LFB attributes, and metadata).
</xsd:documentation> </xsd:documentation>
</xsd:annotation> </xsd:annotation>
<xsd:element name="description" type="xsd:string"/> <xsd:element name="description" type="xsd:string"/>
<xsd:element name="synopsis" type="xsd:string"/> <xsd:element name="synopsis" type="xsd:string"/>
skipping to change at page 85, line 24 skipping to change at page 87, line 25
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="structType"> <xsd:complexType name="structType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="derivedFrom" type="typeRefNMTOKEN" <xsd:element name="derivedFrom" type="typeRefNMTOKEN"
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="component" maxOccurs="unbounded"> <xsd:element name="component" maxOccurs="unbounded">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element ref="description" minOccurs="0"/>
<xsd:element name="optional" minOccurs="0"/> <xsd:element name="optional" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="componentID" use="required" <xsd:attribute name="componentID" use="required"
type="xsd:integer"/> type="xsd:unsignedInt"/>
</xsd:complexType> </xsd:complexType>
<!-- key declaration to make componentIDs unique in a struct <!-- key declaration to make componentIDs unique in a struct
--> -->
<xsd:key name="structComponentID"> <xsd:key name="structComponentID">
<xsd:selector xpath="lfb:component"/> <xsd:selector xpath="lfb:component"/>
<xsd:field xpath="@componentID"/> <xsd:field xpath="@componentID"/>
</xsd:key> </xsd:key>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
skipping to change at page 86, line 32 skipping to change at page 88, line 34
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="components" type="LFBComponentsType" <xsd:element name="components" type="LFBComponentsType"
minOccurs="0"/> minOccurs="0"/>
<xsd:element name="capabilities" <xsd:element name="capabilities"
type="LFBCapabilitiesType" minOccurs="0"/> type="LFBCapabilitiesType" minOccurs="0"/>
<xsd:element name="events" <xsd:element name="events"
type="eventsType" minOccurs="0"/> type="eventsType" minOccurs="0"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="LFBClassID" use="required" <xsd:attribute name="LFBClassID" use="required"
type="xsd:integer"/> type="xsd:unsignedInt"/>
</xsd:complexType> </xsd:complexType>
<!-- Key constraint to ensure unique attribute names within <!-- Key constraint to ensure unique attribute names within
a class: a class:
--> -->
<xsd:key name="components"> <xsd:key name="components">
<xsd:selector xpath="lfb:components/lfb:component"/> <xsd:selector xpath="lfb:components/lfb:component"/>
<xsd:field xpath="lfb:name"/> <xsd:field xpath="lfb:name"/>
</xsd:key> </xsd:key>
<xsd:key name="capabilities"> <xsd:key name="capabilities">
<xsd:selector xpath="lfb:capabilities/lfb:capability"/> <xsd:selector xpath="lfb:capabilities/lfb:capability"/>
skipping to change at page 87, line 30 skipping to change at page 89, line 32
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="inputPortType"> <xsd:complexType name="inputPortType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="expectation" type="portExpectationType"/> <xsd:element name="expectation" type="portExpectationType"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="group" type="booleanType" use="optional" <xsd:attribute name="group" type="xsd:boolean" use="optional"
default="0"/> default="0"/>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="portExpectationType"> <xsd:complexType name="portExpectationType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="frameExpected" minOccurs="0"> <xsd:element name="frameExpected" minOccurs="0">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<!-- ref must refer to a name of a defined frame type --> <!-- ref must refer to a name of a defined frame type -->
<xsd:element name="ref" type="xsd:string" <xsd:element name="ref" type="xsd:string"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
skipping to change at page 89, line 5 skipping to change at page 91, line 7
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="outputPortType"> <xsd:complexType name="outputPortType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="name" type="xsd:NMTOKEN"/> <xsd:element name="name" type="xsd:NMTOKEN"/>
<xsd:element ref="synopsis"/> <xsd:element ref="synopsis"/>
<xsd:element name="product" type="portProductType"/> <xsd:element name="product" type="portProductType"/>
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="group" type="booleanType" use="optional" <xsd:attribute name="group" type="xsd:boolean" use="optional"
default="0"/> default="0"/>
</xsd:complexType> </xsd:complexType>
<xsd:complexType name="portProductType"> <xsd:complexType name="portProductType">
<xsd:sequence> <xsd:sequence>
<xsd:element name="frameProduced"> <xsd:element name="frameProduced">
<xsd:complexType> <xsd:complexType>
<xsd:sequence> <xsd:sequence>
<!-- ref must refer to a name of a defined frame type <!-- ref must refer to a name of a defined frame type
--> -->
<xsd:element name="ref" type="xsd:NMTOKEN" <xsd:element name="ref" type="xsd:NMTOKEN"
skipping to change at page 90, line 35 skipping to change at page 92, line 37
<xsd:element name="defaultValue" type="xsd:token" <xsd:element name="defaultValue" type="xsd:token"
minOccurs="0"/> minOccurs="0"/>
</xsd:sequence> </xsd:sequence>
<xsd:attribute name="access" use="optional" <xsd:attribute name="access" use="optional"
default="read-write"> default="read-write">
<xsd:simpleType> <xsd:simpleType>
<xsd:list itemType="accessModeType"/> <xsd:list itemType="accessModeType"/>
</xsd:simpleType> </xsd:simpleType>
</xsd:attribute> </xsd:attribute>
<xsd:attribute name="componentID" use="required" <xsd:attribute name="componentID" use="required"
type="xsd:integer"/> type="xsd:unsignedInt"/>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<xsd:simpleType name="accessModeType"> <xsd:simpleType name="accessModeType">
<xsd:restriction base="xsd:NMTOKEN"> <xsd:restriction base="xsd:NMTOKEN">
<xsd:enumeration value="read-only"/> <xsd:enumeration value="read-only"/>
<xsd:enumeration value="read-write"/> <xsd:enumeration value="read-write"/>
<xsd:enumeration value="write-only"/> <xsd:enumeration value="write-only"/>
<xsd:enumeration value="read-reset"/> <xsd:enumeration value="read-reset"/>
skipping to change at page 92, line 49 skipping to change at page 95, line 5
about an FE. about an FE.
In addition to its capabilities, an FE will have information that can In addition to its capabilities, an FE will have information that can
be used in understanding and controlling the forwarding operations. be used in understanding and controlling the forwarding operations.
Some of this information will be read only, while others parts may Some of this information will be read only, while others parts may
also be writeable. also be writeable.
In order to make the FE information easily accessible, the In order to make the FE information easily accessible, the
information is represented in an LFB. This LFB has a class, information is represented in an LFB. This LFB has a class,
FEObject. The LFBClassID for this class is 1. Only one instance of FEObject. The LFBClassID for this class is 1. Only one instance of
this class will ever be present, and the instance ID of that instance this class will ever be present in an FE, and the instance ID of that
in the protocol is 1. Thus, by referencing the components of instance in the protocol is 1. Thus, by referencing the components
class:1, instance:1 a CE can get the general information about the of class:1, instance:1 a CE can get the general information about the
FE. The FEObject LFB Class is described in this section. FE. The FEObject LFB Class is described in this section.
There will also be an FEProtocol LFB Class. LFBClassID 2 is reserved There will also be an FEProtocol LFB Class. LFBClassID 2 is reserved
for that class. There will be only one instance of that class as for that class. There will be only one instance of that class as
well. Details of that class are defined in the ForCES protocol well. Details of that class are defined in the ForCES Protocol [2]
document. document.
5.1. XML for FEObject Class definition 5.1. XML for FEObject Class definition
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<LFBLibrary xmlns="http://ietf.org/forces/1.0/lfbmodel" <LFBLibrary xmlns="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ietf.org/forces/1.0/lfbmodel.xsd"
provides="FEObject"> provides="FEObject">
<!-- xmlns and schemaLocation need to be fixed -->
<dataTypeDefs> <dataTypeDefs>
<dataTypeDef> <dataTypeDef>
<name>LFBAdjacencyLimitType</name> <name>LFBAdjacencyLimitType</name>
<synopsis>Describing the Adjacent LFB</synopsis> <synopsis>Describing the Adjacent LFB</synopsis>
<struct> <struct>
<component componentID="1"> <component componentID="1">
<name>NeighborLFB</name> <name>NeighborLFB</name>
<synopsis>ID for that LFB Class</synopsis> <synopsis>ID for that LFB Class</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
skipping to change at page 95, line 39 skipping to change at page 97, line 39
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>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>FEStatusValues</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>
<synopsis> <synopsis>
FE is administratively disabled FE is administratively disabled
</synopsis> </synopsis>
</specialValue> </specialValue>
skipping to change at page 98, line 50 skipping to change at page 100, line 50
<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>model of this FE</synopsis>
<typeRef>FEStatusValues</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>
</components> </components>
skipping to change at page 102, line 45 skipping to change at page 104, line 45
finding this object.) finding this object.)
5.3. FE Components 5.3. FE Components
The <components> element is included if the class definition contains The <components> element is included if the class definition contains
the definition of the components of the FE Object that are not the definition of the components of the FE Object that are not
considered "capabilities". Some of these components are writeable, considered "capabilities". Some of these components are writeable,
and some are read-only, which is determinable by examining the and some are read-only, which is determinable by examining the
property information of the components. property information of the components.
5.3.1. FEStatus 5.3.1. FEState
This component carries the overall state of the FE. For now, it is This component carries the overall state of the FE. For now, it is
restricted to the strings AdminDisable, OperDisable and OperEnable. restricted to the strings AdminDisable, OperDisable and OperEnable.
5.3.2. LFBSelectors and LFBSelectorType 5.3.2. LFBSelectors and LFBSelectorType
The LFBSelectors component is an array of information about the LFBs The LFBSelectors component is an array of information about the LFBs
currently accessible via ForCES in the FE. The structure of the LFB currently accessible via ForCES in the FE. The structure of the LFB
information is defined by the LFBSelectorType dataTypeDef. information is defined by the LFBSelectorType dataTypeDef.
skipping to change at page 104, 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 [2]. The requirements requirements outlined in Section 5 of RFC3654 [3]. 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.
skipping to change at page 105, line 24 skipping to change at page 107, line 24
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
the CE must learn and control by communicating with the FEs (or by the CE must learn and control by communicating with the FEs (or by
other means). Most of this communication will happen in the post- other means). Most of this communication will happen in the post-
association phase using the ForCES protocol. The following types of association phase using the ForCES protocol. The following types of
information must be exchanged between CEs and FEs via the ForCES information must be exchanged between CEs and FEs via the ForCES
protocol: 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 attributes;
skipping to change at page 106, line 10 skipping to change at page 108, line 10
Items 6) and 7) are "command" types of exchanges, where the main flow Items 6) and 7) are "command" types of exchanges, where the main flow
of information is from the CEs to the FEs. Messages in Item 6) (the of information is from the CEs to the FEs. Messages in Item 6) (the
LFB re-configuration commands) are expected to be used frequently. LFB re-configuration commands) are expected to be used frequently.
Item 7) (LFB topology re-configuration) is needed only if dynamic LFB Item 7) (LFB topology re-configuration) is needed only if dynamic LFB
topologies are supported by the FEs and it is expected to be used topologies are supported by the FEs and it is expected to be used
infrequently. infrequently.
The inter-FE topology (item 1 above) can be determined by the CE in The inter-FE topology (item 1 above) can be determined by the CE in
many ways. Neither this document nor the ForCES protocol mandates a many ways. Neither this document nor the ForCES Protocol [2]
specific mechanism. The LFB Class definition does include the document mandates a specific mechanism. The LFB Class definition
capability for an FE to be configured with, and provides to the CE in does include the capability for an FE to be configured with, and
response to a query, the identity of its neighbors. There may also provides to the CE in response to a query, the identity of its
be defined specific LFB classes and protocols for neighbor discovery. neighbors. There may also be defined specific LFB classes and
Routing protocols may be used by the CE for adjacency determination. protocols for neighbor discovery. Routing protocols may be used by
The CE may be configured with the relevant information. the CE for adjacency determination. The CE may be configured with
the relevant information.
The relationship between the FE model and the seven post-association The relationship between the FE model and the seven post-association
messages are visualized in Figure 12: messages are visualized in Figure 12:
+--------+ +--------+
..........-->| CE | ..........-->| CE |
/----\ . +--------+ /----\ . +--------+
\____/ FE Model . ^ | \____/ FE Model . ^ |
| |................ (1),2 | | 6, 7 | |................ (1),2 | | 6, 7
| | (off-line) . 3, 4, 5 | | | | (off-line) . 3, 4, 5 | |
\____/ . | v \____/ . | v
. +--------+ . +--------+
e.g. RFCs ..........-->| FE | e.g. RFCs ..........-->| FE |
+--------+ +--------+
Figure 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 and beyond the scope of the FE model. Their discussion is Protocol [2] document and is beyond the scope of the FE model. Their
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 attributes of the LFBs, in which case such
attributes must be defined in the LFB classes. attributes 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).
skipping to change at page 107, line 44 skipping to change at page 109, line 45
egress packet processing function. This provides the flexibility to egress packet processing function. This provides the flexibility to
spread the functions across multiple FEs and interconnect them spread the functions across multiple FEs and interconnect them
together later for certain applications. together later for certain applications.
While the inter-FE communication protocol is out of scope for ForCES, While the inter-FE communication protocol is out of scope for ForCES,
it is up to the CE to query and understand how multiple FEs are it is up to the CE to query and understand how multiple FEs are
inter-connected to perform a complete ingress-egress packet inter-connected to perform a complete ingress-egress packet
processing function, such as the one described in Figure 13. The processing function, such as the one described in Figure 13. The
inter-FE topology information may be provided by FEs, may be hard- inter-FE topology information may be provided by FEs, may be hard-
coded into CE, or may be provided by some other entity (e.g., a bus coded into CE, or may be provided by some other entity (e.g., a bus
manager) independent of the FEs. So while the ForCES protocol manager) independent of the FEs. So while the ForCES Protocol [2]
supports FE topology query from FEs, it is optional for the CE to use supports FE topology query from FEs, it is optional for the CE to use
it, assuming the CE has other means to gather such topology it, assuming the CE has other means to gather such topology
information. information.
+-----------------------------------------------------+ +-----------------------------------------------------+
| +---------+ +------------+ +---------+ | | +---------+ +------------+ +---------+ |
input| | | | | | output | input| | | | | | output |
---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+ ---+->| Ingress |-->|Header |-->|IPv4 |---------+--->+
| | port | |Decompressor| |Forwarder| FE | | | | port | |Decompressor| |Forwarder| FE | |
| +---------+ +------------+ +---------+ #1 | | | +---------+ +------------+ +---------+ #1 | |
skipping to change at page 110, line 36 skipping to change at page 112, line 36
information within the model. information within the model.
7.5. State Query of LFB Attributes 7.5. State Query of LFB Attributes
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 attributes:
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 optional 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 attribute 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.
skipping to change at page 111, line 33 skipping to change at page 113, line 33
o Disconnect: remove a link between a given output of an LFB and a o Disconnect: remove a link between a given output of an LFB and a
given input of another LFB. given input of another LFB.
o Delete a given LFB (automatically removing all interconnects to/ o Delete a given LFB (automatically removing all interconnects to/
from the LFB). from the LFB).
8. Example LFB Definition 8. Example LFB Definition
This section contains an example LFB definition. While some This section contains an example LFB definition. While some
properties of LFBs are shown by the FE Object LFB, this endeavors to properties of LFBs are shown by the FE Object LFB, this endeavors to
show how a data plain LFB might be build. This example is a show how a data plane LFB might be build. This example is a
fictional case of an interface supporting a coarse WDM optical fictional case of an interface supporting a coarse WDM optical
interface carry Frame Relay traffic. The statistical information interface that carries Frame Relay traffic. The statistical
(including error statistics) is omitted. information (including error statistics) is omitted.
Later portions of this example include references to protocol Later portions of this example include references to protocol
operations. The operations described are operations the protocol operations. The operations described are operations the protocol
needs to support. The exact format and fields are purely needs to support. The exact format and fields are purely
informational here, as the protocol document defines the precise informational here, as the ForCES Protocol [2] document defines the
syntax and symantics of its operations. precise syntax and symantics of its operations.
<?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="urn:ietf:params:xml:ns:forces:lfbmodel:1.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ietf.org/forces/1.0/lfbmodel"
provides="LaserFrameLFB"> provides="LaserFrameLFB">
<frameDefs> <frameDefs>
<frameDef> <frameDef>
<name>FRFrame</name> <name>FRFrame</name>
<synopsis> <synopsis>
A frame relay frame, with DLCI without A frame relay frame, with DLCI without
stuffing) stuffing)
</synopsis> </synopsis>
</frameDef> </frameDef>
<frameDef> <frameDef>
skipping to change at page 113, line 34 skipping to change at page 115, line 33
with this circuit with this circuit
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</component> </component>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>PortStatusValues</name> <name>PortStatusValues</name>
<synopsis> <synopsis>
The possible values of status. Used for both The possible values of status. Used for both
administrative and operation status administrative and operational status
</synopsis> </synopsis>
<atomic> <atomic>
<baseType>uchar</baseType> <baseType>uchar</baseType>
<specialValues> <specialValues>
<specialValue value="0"> <specialValue value="0">
<name>Disabled </name> <name>Disabled </name>
<synopsis>the component is disabled</synopsis> <synopsis>the component is disabled</synopsis>
</specialValue> </specialValue>
<specialValue value="1"> <specialValue value="1">
<name>Enable</name> <name>Enabled</name>
<synopsis>FE is operatively disabled</synopsis> <synopsis>FE is operatively enabled</synopsis>
</specialValue> </specialValue>
</specialValues> </specialValues>
</atomic> </atomic>
</dataTypeDef> </dataTypeDef>
</dataTypeDefs> </dataTypeDefs>
<metadataDefs> <metadataDefs>
<metadataDef> <metadataDef>
<name>DLCI</name> <name>DLCI</name>
<synopsis>The DLCI the frame arrived on</synopsis> <synopsis>The DLCI the frame arrived on</synopsis>
<metadataID>12</metadataID> <metadataID>12</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
<metadataDef> <metadataDef>
<name>LaserChannel</name> <name>LaserChannel</name>
<synopsis>The index of the laser channel</synopsis> <synopsis>The index of the laser channel</synopsis>
<metadataID>34</metadataID> <metadataID>34</metadataID>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</metadataDef> </metadataDef>
</metadataDefs> </metadataDefs>
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="-255"> <!-- dummy classid, but needs to be a valid value -->
<LFBClassDef LFBClassID="255">
<name>FrameLaserLFB</name> <name>FrameLaserLFB</name>
<synopsis>Fictional LFB for Demonstrations</synopsis> <synopsis>Fictional LFB for Demonstrations</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="yes"> <inputPort group="true">
<name>LMIfromFE</name> <name>LMIfromFE</name>
<synopsis> <synopsis>
Ports for LMI traffic, for transmission Ports for LMI traffic, for transmission
</synopsis> </synopsis>
<expectation> <expectation>
<frameExpected> <frameExpected>
<ref>FRFrame</ref> <ref>FRFrame</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>DLCI</ref> <ref>DLCI</ref>
skipping to change at page 115, line 7 skipping to change at page 117, line 7
<ref>IPFrame</ref> <ref>IPFrame</ref>
</frameExpected> </frameExpected>
<metadataExpected> <metadataExpected>
<ref>DLCI</ref> <ref>DLCI</ref>
<ref>LaserChannel</ref> <ref>LaserChannel</ref>
</metadataExpected> </metadataExpected>
</expectation> </expectation>
</inputPort> </inputPort>
</inputPorts> </inputPorts>
<outputPorts> <outputPorts>
<outputPort group="yes"> <outputPort group="true">
<name>LMItoFE</name> <name>LMItoFE</name>
<synopsis> <synopsis>
Ports for LMI traffic for processing Ports for LMI traffic for processing
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>FRFrame</ref> <ref>FRFrame</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>DLCI</ref> <ref>DLCI</ref>
<ref>LaserChannel</ref> <ref>LaserChannel</ref>
</metadataProduced> </metadataProduced>
</product> </product>
</outputPort> </outputPort>
<outputPort group="yes"> <outputPort group="true">
<name>DatatoFE</name> <name>DatatoFE</name>
<synopsis> <synopsis>
Ports for Data traffic for processing Ports for Data traffic for processing
</synopsis> </synopsis>
<product> <product>
<frameProduced> <frameProduced>
<ref>IPFrame</ref> <ref>IPFrame</ref>
</frameProduced> </frameProduced>
<metadataProduced> <metadataProduced>
<ref>DLCI</ref> <ref>DLCI</ref>
skipping to change at page 118, line 47 skipping to change at page 120, line 47
</event> </event>
</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.
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 too 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 122, line 19 skipping to change at page 124, line 19
Path-TLV: flags = property-field, length = 1, path = 3 Path-TLV: flags = property-field, length = 1, path = 3
Content = 15 (threshold) Content = 15 (threshold)
This would set the registration for the event on all entries in the This would set the registration for the event on all entries in the
table. It would also set the threshold for the event, causing table. It would also set the threshold for the event, causing
reporting if the power falls below 15. (Presumably, the CE knows reporting if the power falls below 15. (Presumably, the CE knows
what the scale is for power, and has chosen 15 as a meaningful what the scale is for power, and has chosen 15 as a meaningful
problem level.) problem level.)
If a laser oscillates in power near the 15 mark, one could get a lot If a laser oscillates in power near the 15 mark, one could get a lot
of notifications. (If it flips back and forth between 9 and 10, each of notifications. (If it flips back and forth between 14 and 15,
flip down will generate an event.) Suppose that the CE decides to each flip down will generate an event.) Suppose that the CE decides
suppress this oscillation somewhat on laser channel 5. It can do to suppress this oscillation somewhat on laser channel 5. It can do
this by setting the variance property on that event. The request this by setting the variance property on that event. The request
would look like: would look like:
T = SET-PROP T = SET-PROP
Path-TLV: flags=0, length = 3, path = 61.4.5 Path-TLV: flags=0, length = 3, path = 61.4.5
Path-TLV: flags = property-field, length = 1, path = 4 Path-TLV: flags = property-field, length = 1, path = 4
Content = 2 (hysteresis) Content = 2 (hysteresis)
Setting the hysteresis to 2 suppress a lot of spurious notifications. Setting the hysteresis to 2 suppress a lot of spurious notifications.
When the level first falls below 10, a notification is generated. If When the level first falls below 10, a notification is generated. If
the power level increases to 10 or 11, and then falls back below 10, the power level increases to 10 or 11, and then falls back below 10,
an event will not be generated. The power has to recover to at least an event will not be generated. The power has to recover to at least
12 and fall back below 10 to generate another event. Once 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 unique class names and numeric
class identifiers. To meet that goal, IANA will maintain a registry class identifiers. To meet that goal, IANA will maintain a registry
skipping to change at page 123, line 15 skipping to change at page 125, line 15
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 The LFBLibrary element and all of its sub-elements are defined in the
following namespace: following namespace:
<http://ietf.org/forces/1.0/lfbmodel> <urn:ietf:params:xml:ns:forces:lfbmodel:1.0>
Table 1 tabulates the above information. Table 1 tabulates the above information.
+----------+------------+---------------------+---------------------+ +------------+-------------+----------+-----------------------------+
| LFB | LFB Class | Place Defined | Description | | LFB Class | LFB Class | Place | Description |
| Class | Identifier | | | | Name | Identifier | Defined | |
| Name | | | | +------------+-------------+----------+-----------------------------+
+----------+------------+---------------------+---------------------+ | Reserved | 0 | This | Reserved |
| Reserved | 0 | This document | Reserved | | | | document | |
| FE | 1 | This document | Defines ForCES | | FE Object | 1 | This | Defines ForCES Forwarding |
| Object | | | Forwarding Element | | | | document | Element information |
| | | | information | | FE | 2 | [2] | Defines parameters for the |
| FE | 2 | Editors Note: | Defines parameters | | Protocol | | | ForCES protocol operation |
| Protocol | | Update with | for the ForCES | | Object | | | |
| Object | | protocol RFC ref | protocol operation | +------------+-------------+----------+-----------------------------+
| | | here .. | |
+----------+------------+---------------------+---------------------+
Table 1 Table 1
10. Authors Emeritus 10. Authors Emeritus
The following are the authors who were instrumental in the creation The following are the authors who were instrumental in the creation
of earlier releases of this document. of earlier releases of this document.
Lily Yang, Intel Corp. Lily Yang, Intel Corp.
Ram Gopal, Nokia Research Center Ram Gopal, Nokia Research Center
Alan DeKok, Infoblox, Inc. Alan DeKok, Infoblox, Inc.
Zsolt Haraszti, Clovis Solutions Zsolt Haraszti, Clovis Solutions
11. Acknowledgments 11. Acknowledgments
Many of the colleagues in our companies and participants in the Many of the colleagues in our companies and participants in the
ForCES mailing list have provided invaluable input into this work. ForCES mailing list have provided invaluable input into this work.
Particular thanks to Evangelos Haleplidis for held getting the XML
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
to the information contained in the FE model is accomplished via the to the information contained in the FE model is accomplished via the
ForCES protocol, which will be defined in separate documents, and ForCES protocol, which will be defined in separate documents, and
thus the security issues will be addressed there. thus the security issues will be addressed there.
13. References 13. References
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,
"ForCES Protocol Specification", work in progress, draft-ietf -
forces-protocol-11.txt, December 2007.
13.2. Informative References 13.2. Informative References
[2] Khosravi, H. and T. Anderson, "Requirements for Separation of [3] 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.
[3] Yang, L., Dantu, R., Anderson, T., and R. Gopal, "Forwarding [4] 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.
[4] Chan, K., Sahita, R., Hahn, S., and K. McCloghrie, [5] 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.
[5] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework [6] Sahita, R., Hahn, S., Chan, K., and K. McCloghrie, "Framework
Policy Information Base", RFC 3318, March 2003. Policy Information Base", RFC 3318, March 2003.
[6] Li, M., "IPsec Policy Information Base", work in progress, [7] Pras, A. and J. Schoenwaelder, "On the Difference between
draft-ietf -ipsp-spsecpib-10.txt, April 2004.
[7] Duffield, N., "A Framework for packet Selection and Reporting",
draft-ietf -psamp-framework-10.txt, January 2005.
[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.
[9] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the [8] 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.
[10] Thompson, H., Beech, D., Maloney, M., and Mendelsohn, N., "XML [9] 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.
[11] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", [10] 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.
[12] Davis, M. and M. Suignard, "UNICODE Security Considerations", [11] 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
skipping to change at page 126, line 7 skipping to change at page 128, line 7
Jamal Hadi Salim Jamal Hadi Salim
Znyx Networks Znyx Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@znyx.com Email: hadi@znyx.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 117 change blocks. 
321 lines changed or deleted 347 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/