draft-ietf-forces-model-06.txt   draft-ietf-forces-model-07.txt 
Internet Draft L. Yang Internet Draft J. Halpern
Expiration: September 2006 Intel Corp. Expiration: April 2007 Self
File: draft-ietf-forces-model-06.txt J. Halpern File: draft-ietf-forces-model-07.txt E. Deleganes
Working Group: ForCES Megisto Systems Working Group: ForCES Intel Corp.
R. Gopal October 2006
Nokia
A. DeKok
Infoblox, Inc.
Z. Haraszti
Clovis Solutions
E. Deleganes
Intel Corp.
ForCES Forwarding Element Model ForCES Forwarding Element Model
draft-ietf-forces-model-06.txt draft-ietf-forces-model-07.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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than a "work in progress." reference material or to cite them other than a "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.html. http://www.ietf.org/ietf/1id-abstracts.html.
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.
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).
Abstract Abstract
This document defines the forwarding element (FE) model used in the This document defines the forwarding element (FE) model used in the
Forwarding and Control Element Separation (ForCES) protocol. The Forwarding and Control Element Separation (ForCES) protocol. The
model represents the capabilities, state and configuration of model represents the capabilities, state and configuration of
forwarding elements within the context of the ForCES protocol, so forwarding elements within the context of the ForCES protocol, so
that control elements (CEs) can control the FEs accordingly. More that control elements (CEs) can control the FEs accordingly. More
specifically, the model describes the logical functions that are specifically, the model describes the logical functions that are
present in an FE, what capabilities these functions support, and how present in an FE, what capabilities these functions support, and how
these functions are or can be interconnected. This FE model is these functions are or can be interconnected. This FE model is
intended to satisfy the model requirements specified in the ForCES intended to satisfy the model requirements specified in the ForCES
requirements draft, RFC 3564 [1]. A list of the basic logical requirements draft, RFC 3564 [1].
functional blocks (LFBs) is also defined in the LFB class library to
aid the effort in defining individual LFBs.
Table of Contents Table of Contents
Abstract...........................................................1 Abstract...........................................................1
1. Definitions.....................................................4 1. Definitions.....................................................4
2. Introduction....................................................5 2. Introduction....................................................5
2.1. Requirements on the FE model...............................6 2.1. Requirements on the FE model...............................6
2.2. The FE Model in Relation to FE Implementations.............6 2.2. The FE Model in Relation to FE Implementations.............6
2.3. The FE Model in Relation to the ForCES Protocol............7 2.3. The FE Model in Relation to the ForCES Protocol............6
2.4. Modeling Language for the FE Model.........................7 2.4. Modeling Language for the FE Model.........................7
2.5. Document Structure.........................................8 2.5. Document Structure.........................................8
3. FE Model Concepts...............................................8 3. FE Model Concepts...............................................8
3.1. FE Capability Model and State Model........................8 3.1. FE Capability Model and State Model........................8
3.2. LFB (Logical Functional Block) Modeling...................11 3.2. LFB (Logical Functional Block) Modeling...................11
3.2.1. LFB Outputs..........................................13 3.2.1. LFB Outputs..........................................13
3.2.2. LFB Inputs...........................................16 3.2.2. LFB Inputs...........................................16
3.2.3. Packet Type..........................................19 3.2.3. Packet Type..........................................19
3.2.4. Metadata.............................................19 3.2.4. Metadata.............................................19
3.2.5. LFB Events...........................................26 3.2.5. LFB Events...........................................26
3.2.6. LFB Element Properties...............................27 3.2.6. LFB Element Properties...............................27
3.2.7. LFB Versioning.......................................27 3.2.7. LFB Versioning.......................................27
3.2.8. LFB Inheritance......................................27 3.2.8. LFB Inheritance......................................28
3.3. FE Datapath Modeling......................................28 3.3. FE Datapath Modeling......................................29
3.3.1. Alternative Approaches for Modeling FE Datapaths.....29 3.3.1. Alternative Approaches for Modeling FE Datapaths.....29
3.3.2. Configuring the LFB Topology.........................33 3.3.2. Configuring the LFB Topology.........................33
4. Model and Schema for LFB Classes...............................37 4. Model and Schema for LFB Classes...............................37
4.1. Namespace.................................................37 4.1. Namespace.................................................37
4.2. <LFBLibrary> Element......................................37 4.2. <LFBLibrary> Element......................................37
4.3. <load> Element............................................39 4.3. <load> Element............................................39
4.4. <frameDefs> Element for Frame Type Declarations...........39 4.4. <frameDefs> Element for Frame Type Declarations...........39
4.5. <dataTypeDefs> Element for Data Type Definitions..........40 4.5. <dataTypeDefs> Element for Data Type Definitions..........40
4.5.1. <typeRef> Element for Aliasing Existing Data Types...42 4.5.1. <typeRef> Element for Aliasing Existing Data Types...43
4.5.2. <atomic> Element for Deriving New Atomic Types.......42 4.5.2. <atomic> Element for Deriving New Atomic Types.......43
4.5.3. <array> Element to Define Arrays.....................43 4.5.3. <array> Element to Define Arrays.....................44
4.5.4. <struct> Element to Define Structures................47 4.5.4. <struct> Element to Define Structures................47
4.5.5. <union> Element to Define Union Types................48 4.5.5. <union> Element to Define Union Types................48
4.5.6. Augmentations........................................48 4.5.6. Augmentations........................................49
4.6. <metadataDefs> Element for Metadata Definitions...........49 4.6. <metadataDefs> Element for Metadata Definitions...........50
4.7. <LFBClassDefs> Element for LFB Class Definitions..........50 4.7. <LFBClassDefs> Element for LFB Class Definitions..........51
4.7.1. <derivedFrom> Element to Express LFB Inheritance.....52 4.7.1. <derivedFrom> Element to Express LFB Inheritance.....52
4.7.2. <inputPorts> Element to Define LFB Inputs............52 4.7.2. <inputPorts> Element to Define LFB Inputs............53
4.7.3. <outputPorts> Element to Define LFB Outputs..........55 4.7.3. <outputPorts> Element to Define LFB Outputs..........55
4.7.4. <attributes> Element to Define LFB Operational 4.7.4. <attributes> Element to Define LFB Operational
Attributes..................................................56 Attributes..................................................57
4.7.5. <capabilities> Element to Define LFB Capability 4.7.5. <capabilities> Element to Define LFB Capability
Attributes..................................................59 Attributes..................................................59
4.7.6. <events> Element for LFB Notification Generation.....60 4.7.6. <events> Element for LFB Notification Generation.....61
4.7.7. <description> Element for LFB Operational Specification 4.7.7. <description> Element for LFB Operational Specification
............................................................64 ............................................................64
4.8. Properties................................................64 4.8. Properties................................................64
4.9. XML Schema for LFB Class Library Documents................70 4.8.1. Basic Properties.....................................64
5. FE Attributes and Capabilities.................................81 4.8.2. Array Properties.....................................66
5.1. XML for FEObject Class definition.........................81 4.8.3. String Properties....................................66
5.2. FE Capabilities...........................................87 4.8.4. Octetstring Properties...............................67
5.2.1. ModifiableLFBTopology................................88 4.8.5. Event Properties.....................................67
5.2.2. SupportedLFBs and SupportedLFBType...................88 4.8.6. Alias Properties.....................................70
5.3. FEAttributes..............................................90 4.9. XML Schema for LFB Class Library Documents................71
5.3.1. FEStatus.............................................90 5. FE Attributes and Capabilities.................................82
5.3.2. LFBSelectors and LFBSelectorType.....................90 5.1. XML for FEObject Class definition.........................82
5.3.3. LFBTopology and LFBLinkType..........................91 5.2. FE Capabilities...........................................89
5.3.4. FENeighbors an FEConfiguredNeighborType..............91 5.2.1. ModifiableLFBTopology................................89
6. Satisfying the Requirements on FE Model........................92 5.2.2. SupportedLFBs and SupportedLFBType...................89
6.1. Port Functions............................................93 5.3. FEAttributes..............................................92
6.2. Forwarding Functions......................................93 5.3.1. FEStatus.............................................92
6.3. QoS Functions.............................................93 5.3.2. LFBSelectors and LFBSelectorType.....................92
6.4. Generic Filtering Functions...............................94 5.3.3. LFBTopology and LFBLinkType..........................92
6.5. Vendor Specific Functions.................................94 5.3.4. FENeighbors and FEConfiguredNeighborType.............93
6.6. High-Touch Functions......................................94 6. Satisfying the Requirements on FE Model........................93
6.7. Security Functions........................................94 7. Using the FE model in the ForCES Protocol......................94
6.8. Off-loaded Functions......................................94 7.1. FE Topology Query.........................................96
6.9. IPFLOW/PSAMP Functions....................................95 7.2. FE Capability Declarations................................97
7. Using the FE model in the ForCES Protocol......................95
7.1. FE Topology Query.........................................97
7.2. FE Capability Declarations................................98
7.3. LFB Topology and Topology Configurability Query...........98 7.3. LFB Topology and Topology Configurability Query...........98
7.4. LFB Capability Declarations...............................98 7.4. LFB Capability Declarations...............................98
7.5. State Query of LFB Attributes.............................99 7.5. State Query of LFB Attributes.............................99
7.6. LFB Attribute Manipulation...............................100 7.6. LFB Attribute Manipulation................................99
7.7. LFB Topology Re-configuration............................100 7.7. LFB Topology Re-configuration............................100
8. Example.......................................................100 8. Example.......................................................100
8.1. Data Handling............................................108 8.1. Data Handling............................................107
8.1.1. Setting up a DLCI...................................108 8.1.1. Setting up a DLCI...................................108
8.1.2. Error Handling......................................109 8.1.2. Error Handling......................................108
8.2. LFB Attributes...........................................109 8.2. LFB Attributes...........................................109
8.3. Capabilities.............................................110 8.3. Capabilities.............................................109
8.4. Events...................................................110 8.4. Events...................................................109
9. Acknowledgments...............................................111 9. IANA Considerations...........................................111
10. Security Considerations......................................112 10. Authors Emeritus.............................................111
11. Normative References.........................................112 11. Acknowledgments..............................................111
12. Informative References.......................................112 12. Security Considerations......................................112
13. Authors' Addresses...........................................113 13. Normative References.........................................112
14. Intellectual Property Right..................................114 14. Informative References.......................................112
15. IANA consideration...........................................114 15. Authors' Addresses...........................................113
16. Copyright Statement..........................................114 16. Intellectual Property Right..................................113
17. Copyright Statement..........................................113
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-2119]. document are to be interpreted as described in [RFC-2119].
1. Definitions 1. Definitions
Terminology associated with the ForCES requirements is defined in Terminology associated with the ForCES requirements is defined in
skipping to change at page 7, line 45 skipping to change at page 7, line 34
2.4. Modeling Language for the FE Model 2.4. Modeling Language for the FE Model
Even though not absolutely required, it is beneficial to use a Even though not absolutely required, it is beneficial to use a
formal data modeling language to represent the conceptual FE model formal data modeling language to represent the conceptual FE model
described in this document. Use of a formal language can help to described in this document. Use of a formal language can help to
enforce consistency and logical compatibility among LFBs. A full enforce consistency and logical compatibility among LFBs. A full
specification will be written using such a data modeling language. specification will be written using such a data modeling language.
The formal definition of the LFB classes may facilitate the eventual The formal definition of the LFB classes may facilitate the eventual
automation of some of the code generation process and the functional automation of some of the code generation process and the functional
validation of arbitrary LFB topologies. validation of arbitrary LFB topologies. These class definitions
form the LFB Library. Documents which describe LFB Classes are
therefore referred to as LFB Library documents.
Human readability was the most important factor considered when Human readability was the most important factor considered when
selecting the specification language, whereas encoding, decoding and selecting the specification language, whereas encoding, decoding and
transmission performance was not a selection factor. The encoding transmission performance was not a selection factor. The encoding
method for over the wire transport is not dependent on the method for over the wire transport is not dependent on the
specification language chosen and is outside the scope of this specification language chosen and is outside the scope of this
document and up to the ForCES protocol to define. document and up to the ForCES protocol to define.
XML was chosen as the specification language in this document, XML was chosen as the specification language in this document,
because XML has the advantage of being both human and machine because XML has the advantage of being both human and machine
readable with widely available tools support. readable with widely available tools support. This document uses XML
Schema to define the structure of the LFB Library documents, as
defined in [12] and [13]. While these LFB Class definitions are not
sent in the Forces protocol, these definitions comply with the
recommendations in RFC 3470 [11] 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 foundation for the more detailed discussion and specifications in
the sections that follow. Section 4 and 5 constitute the core of the sections that follow. Section 4 and 5 constitute the core of
the FE model, detailing the two major components in the FE model: the FE model, detailing the two major components in the FE model:
LFB model and FE level attributes including capability and LFB LFB model and FE level attributes including capability and LFB
topology. Section 6 directly addresses the model requirements topology. Section 6 directly addresses the model requirements
imposed by the ForCES requirement draft [1] while Section 7 explains imposed by the ForCES requirement draft [1] while Section 7 explains
skipping to change at page 27, line 43 skipping to change at page 27, line 43
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 an FE datapath model containing an LFB instance of a particular
class C also simultaneously contains an LFB instance of a class C' class C also simultaneously contains an LFB instance of a class C'
inherited from class C; C could have a different version than C'. inherited from class C; C could have a different version than C'.
LFB class versioning is supported by requiring a version string in LFB class versioning is supported by requiring a version string in
the class definition. CEs may support multiple versions of a the class definition. CEs may support multiple versions of a
particular LFB class to provide backward compatibility, but FEs MUST particular LFB class to provide backward compatibility, but FEs MUST
NOT support more than one version of a particular class. NOT support more than one version of a particular class.
Versioning is not restricted to making backwards compatible changes.
It is specifically expected to be used to make changes that cannot
be represented by inheritance. Often this will be to correct
errors, and hence may not be backwards compatible. It may also be
used to remove elements which are not considered useful
(particularly if they were previously mandatory, and hence were an
implementation impediment.)
3.2.8. LFB Inheritance 3.2.8. LFB Inheritance
LFB class inheritance is supported in the FE model as a method to LFB class inheritance is supported in the FE model as a method to
define new LFB classes. This also allows FE vendors to add vendor- define new LFB classes. This also allows FE vendors to add vendor-
specific extensions to standardized LFBs. An LFB class specific extensions to standardized LFBs. An LFB class
specification MUST specify the base class and version number it specification MUST specify the base class and version number it
inherits from (the default is the base LFB class). Multiple- inherits from (the default is the base LFB class). Multiple-
inheritance is not allowed, however, to avoid unnecessary inheritance is not allowed, however, to avoid unnecessary
complexity. complexity.
skipping to change at page 37, line 39 skipping to change at page 37, line 39
It is not expected that library documents will be exchanged between It is not expected that library documents will be exchanged between
FEs and CEs "over-the-wire". But the model will serve as an FEs and CEs "over-the-wire". But the model will serve as an
important reference for the design and development of the CEs important reference for the design and development of the CEs
(software) and FEs (mostly the software part). It will also serve (software) and FEs (mostly the software part). It will also serve
as a design input when specifying the ForCES protocol elements for as a design input when specifying the ForCES protocol elements for
CE-FE communication. CE-FE communication.
4.1. Namespace 4.1. Namespace
The LFBLibrary element and all of its sub-elements are defined in A namespace is needed to uniquely identify the LFB type in the LFB
the following namespace: class library. The reference to the namespace definition is
contained in Section 9, IANA Considerations.
http://ietf.org/forces/1.0/lfbmodel
4.2. <LFBLibrary> Element 4.2. <LFBLibrary> Element
The <LFBLibrary> element serves as a root element of all library The <LFBLibrary> element serves as a root element of all library
documents. It contains one or more of the following main blocks: documents. It contains one or more of the following main blocks:
. <frameTypeDefs> for the frame declarations; . <frameTypeDefs> for the frame declarations;
. <dataTypeDefs> for defining common data types; . <dataTypeDefs> for defining common data types;
. <metadataDefs> for defining metadata, and . <metadataDefs> for defining metadata, and
. <LFBClassDefs> for defining LFB classes. . <LFBClassDefs> for defining LFB classes.
skipping to change at page 39, line 4 skipping to change at page 38, line 49
</frameTypeDefs> </frameTypeDefs>
<!-- DATA TYPE DEFINITIONS (optional) --> <!-- DATA TYPE DEFINITIONS (optional) -->
<dataTypeDefs> <dataTypeDefs>
... ...
</dataTypeDefs> </dataTypeDefs>
<!-- METADATA DEFINITIONS (optional) --> <!-- METADATA DEFINITIONS (optional) -->
<metadataDefs> <metadataDefs>
... ...
</metadataDefs> </metadataDefs>
<!-- - - LFB CLASS DEFINITIONS (optional) -->
<!—LFB CLASS DEFINITIONS (optional) -->
<LFBCLassDefs> <LFBCLassDefs>
... ...
</LFBCLassDefs> </LFBCLassDefs>
</LFBLibrary> </LFBLibrary>
4.3. <load> Element 4.3. <load> Element
This element is used to refer to another LFB library document. This element is used to refer to another LFB library document.
Similar to the "#include" directive in C, this makes the objects Similar to the "#include" directive in C, this makes the objects
(metadata types, data types, etc.) defined in the referred library (metadata types, data types, etc.) defined in the referred library
skipping to change at page 41, line 6 skipping to change at page 41, line 6
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>ipv4addr</name> <name>ipv4addr</name>
<synopsis>IPv4 address</synopsis> <synopsis>IPv4 address</synopsis>
... type definition ... ... type definition ...
</dataTypeDef> </dataTypeDef>
... ...
</dataTypeDefs> </dataTypeDefs>
There are two kinds of data types: atomic and compound. Atomic data There are two kinds of data types: atomic and compound. Atomic data
types are appropriate for single-value variables (e.g. integer, types are appropriate for single-value variables (e.g. integer,
ASCII string, byte array). string, byte array).
The following built-in atomic data types are provided, but The following built-in atomic data types are provided, but
additional atomic data types can be defined with the <typeRef> and additional atomic data types can be defined with the <typeRef> and
<atomic> elements: <atomic> elements:
<name> Meaning <name> Meaning
---- ------- ---- -------
char 8-bit signed integer char 8-bit signed integer
uchar 8-bit unsigned integer uchar 8-bit unsigned integer
int16 16-bit signed integer int16 16-bit signed integer
uint16 16-bit unsigned integer uint16 16-bit unsigned integer
int32 32-bit signed integer int32 32-bit signed integer
uint32 32-bit unsigned integer uint32 32-bit unsigned integer
int64 64-bit signed integer int64 64-bit signed integer
uint64 64-bit unisgned integer uint64 64-bit unsigned integer
boolean A true / false value where boolean A true / false value where
0 = false, 1 = true 0 = false, 1 = true
string[N] ASCII null-terminated string with string[N] A UTF-8 string represented in at most
buffer of N characters (string max N Octets.
length is N-1) string A UTF-8 string without a configured
string ASCII null-terminated string without storage length limit.
length limitation
byte[N] A byte array of N bytes byte[N] A byte array of N bytes
octetstring[N] A buffer of N octets, which may octetstring[N] A buffer of N octets, which may
contain fewer than N octets. Hence contain fewer than N octets. Hence
the encoded value will always have the encoded value will always have
a length. a length.
float16 16-bit floating point number float16 16-bit floating point number
float32 32-bit IEEE floating point number float32 32-bit IEEE floating point number
float64 64-bit IEEE floating point number float64 64-bit IEEE floating point number
These built-in data types can be readily used to define metadata or These built-in data types can be readily used to define metadata or
skipping to change at page 42, line 13 skipping to change at page 42, line 12
elements of compound or atomic data types (ala C structures). They elements of compound or atomic data types (ala C structures). They
may be a union of named elements of compound or atomic data types may be a union of named elements of compound or atomic data types
(ala C unions). They may also be defined as augmentations (ala C unions). They may also be defined as augmentations
(explained below in 4.5.6) of existing compound data types. (explained below in 4.5.6) of existing compound data types.
Given that the FORCES protocol will be getting and setting attribute Given that the FORCES protocol will be getting and setting attribute
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 such representations are for the protocol document to define, not
the model document. the model document. Strings and octetstrings must be conveyed with
their length, as they are not delimited, and are variable length.
With regard to strings, this model defines a small set of
restrictions and definitions on how they are structured. String and
octetstring length limits can be specified in the LFB Class
definitions. The element properties for string and octetstring
elements also contain actual lengths and length limits. This
duplication of limits is to allow for implementations with smaller
limits than the maximum limits specified in the LFB Class
definition. In all cases, these lengths are specified in octets,
not in characters. In terms of protocol operation, as long as the
specified 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 when requested. No canonicalization,
transformations, or equivalences are performed by the FE. Elements
of type string (or string[n]) may be used to hold identifiers for
correlation with elements in other LFBs. In such cases, an exact
octet for octet match is used. No equivalences are used by the FE
or CE in performing that matching. The ForCES protocol does not
perform or require validation of the content of UTF-8 strings.
However, UTF-8 strings SHOULD be encoded in the shortest form to
avoid potential security issues described in [15]. Any entity
displaying such strings is expected to perform its own validation
(for example for correct multi-byte characters, and for ensuring
that the string does not end in the middle of a multi-byte
sequence.) Specific LFB class definitions may restrict the valid
contents of a string as suited to the particular usage (for example,
an element that holds a DNS name would be restricted to hold only
octets valid in such a name.) FEs should validate the contents of
SET requests for such restricted elements at the time the set is
performed, just as range checks for range limited elements are
performed. The ForCES 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 element of compound data types. It behaves like a structure, one element 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 48, line 38 skipping to change at page 49, line 19
permitted. permitted.
The target of an <alias> element is determined by its properties. The target of an <alias> element is determined by its properties.
Like all elements, the properties MUST include the support / read / Like all elements, the properties MUST include the support / read /
write permission for the alias. In addition, there are several write permission for the alias. In addition, there are several
fields in the properties which define the target of the alias. fields in the properties which define the target of the alias.
These fields are the ID of the LFB class of the target, the ID of These fields are the ID of the LFB class of the target, the ID of
the LFB instance of the target, and a sequence of integers the LFB instance of the target, and a sequence of integers
representing the path within the target LFB instance to the target representing the path within the target LFB instance to the target
element. The type of the target element must match the declared element. The type of the target element must match the declared
type of the alias. Details of the alias property structure in in type of the alias. Details of the alias property structure in the
the section of this document on properties. section of this document on properties.
Note that the read / write property of the alias refers to the Note that the read / write property of the alias refers to the
value. The CE can only determine if it can write the target value. The CE can only determine if it can write the target
selection properties of the alias by attempting such a write selection properties of the alias by attempting such a write
operation. (Property elements do not themselves have properties.) operation. (Property elements do not themselves have properties.)
4.5.6. Augmentations 4.5.6. Augmentations
Compound types can also be defined as augmentations of existing Compound types can also be defined as augmentations of existing
compound types. If the existing compound type is a structure, compound types. If the existing compound type is a structure,
skipping to change at page 51, line 10 skipping to change at page 51, line 38
. <inputPorts> lists the input ports and their specifications . <inputPorts> lists the input ports and their specifications
. <outputPorts> lists the output ports and their specifications . <outputPorts> lists the output ports and their specifications
. <attributes> defines the operational attributes of the LFB . <attributes> defines the operational attributes of the LFB
. <capabilities> defines the capability attributes of the LFB . <capabilities> defines the capability attributes of the LFB
. <description> contains the operational specification of the LFB . <description> contains the operational specification of the LFB
. The LFBClassID attribute of the LFBClassDef element defines the . The LFBClassID attribute of the LFBClassDef element defines the
ID for this class. These must be globally unique. ID for this class. These must be globally unique.
. <events> defines the events that can be generated by instances . <events> defines the events that can be generated by instances
of this LFB. of this LFB.
[EDITOR: LFB class names should be unique not only among classes LFB Class Names must be unique, in order to enable other documents
defined in this document and in all included documents, but also to reference the classes by name, and to enable human readers to
unique across a large collection of libraries. Obviously some global understand references to class names. While a complex naming
control is needed to ensure such uniqueness. This subject requires structure could be created, simplicity is preferred. As given in the
further study. The uniqueness of the class IDs also requires further IANA considerations section of this document, the IANA will maintain
study.] a registry of LFB Class names and Class identifiers, along with a
reference to the document defining the class.
Here is a skeleton of an example LFB class definition: Here is a skeleton of an example LFB class definition:
<LFBClassDefs> <LFBClassDefs>
<LFBClassDef LFBClassID="12345"> <LFBClassDef LFBClassID="12345">
<name>ipv4lpm</name> <name>ipv4lpm</name>
<synopsis>IPv4 Longest Prefix Match Lookup LFB</synopsis> <synopsis>IPv4 Longest Prefix Match Lookup LFB</synopsis>
<version>1.0</version> <version>1.0</version>
<derivedFrom>baseclass</derivedFrom> <derivedFrom>baseclass</derivedFrom>
skipping to change at page 52, line 21 skipping to change at page 52, line 50
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 referred LFB class MUST be defined in the same library document or
in one of the included library documents. in one of the included library documents.
[EDITOR: The <derivedFrom> element will likely need to specify the
version of the ancestor, which is not included in the schema yet.
The process and rules of class derivation are still being studied.]
It is assumed that the derived class is backwards compatible with It is assumed that the derived class is backwards compatible with
the base class. the base class.
4.7.2. <inputPorts> Element to Define LFB Inputs 4.7.2. <inputPorts> Element to Define LFB Inputs
The optional <inputPorts> element is used to define input ports. An The optional <inputPorts> element is used to define input ports. An
LFB class may have zero, one, or more inputs. If the LFB class has LFB class may have zero, one, or more inputs. If the LFB class has
no input ports, the <inputPorts> element MUST be omitted. The no input ports, the <inputPorts> element MUST be omitted. The
<inputPorts> element can contain one or more <inputPort> elements, <inputPorts> element can contain one or more <inputPort> elements,
one for each port or port-group. We assume that most LFBs will have one for each port or port-group. We assume that most LFBs will have
skipping to change at page 54, line 21 skipping to change at page 54, line 46
<ref> elements, each referring to a metadata. When multiple <ref> elements, each referring to a metadata. 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
of the corresponding <ref> element). For a metadata that is of the corresponding <ref> element). For a metadata 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").
[EDITOR: How to express default values for byte[N] atomic types is
yet to be defined.]
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:
<metadataExpected> <metadataExpected>
<one-of> <one-of>
<ref>prefixmask</ref> <ref>prefixmask</ref>
<ref>prefixlen</ref> <ref>prefixlen</ref>
</one-of> </one-of>
skipping to change at page 58, line 23 skipping to change at page 58, line 44
definition of the type. The former is provided by using the definition of the type. The former is provided by using the
<typeRef> element, which must refer to the unique name of an <typeRef> element, which must refer to the unique name of an
existing data type defined in the <dataTypeDefs> element in the existing data type defined in the <dataTypeDefs> element in the
same library document or in any of the included library same library document or in any of the included library
documents. When the data type is defined locally (unnamed documents. When the data type is defined locally (unnamed
type), one of the following elements can be used: <atomic>, type), one of the following elements can be used: <atomic>,
<array>, <struct>, and <union>. Their usage is identical to how <array>, <struct>, and <union>. Their usage is identical to how
they are used inside <dataTypeDef> elements (see Section 4.5). they are used inside <dataTypeDef> elements (see Section 4.5).
. The optional <defaultValue> element can specify a default value . The optional <defaultValue> element can specify a default value
for the attribute, which is applied when the LFB is initialized for the attribute, which is applied when the LFB is initialized
or reset. [EDITOR: A convention to define default values for or reset.
compound data types and byte[N] atomic types is yet to be
defined.]
The attribute element also MUST have an elementID attribute, which The attribute element also MUST have an elementID attribute, which
is a numeric value used by the ForCES protocol. is a numeric value used by the ForCES protocol.
In addition to the above elements, the <attribute> element includes In addition to the above elements, the <attribute> element includes
an optional "access" attribute, which can take any of the following an optional "access" attribute, which can take any of the following
values or even a list of these values: "read-only", "read-write", values or even a list of these values: "read-only", "read-write",
"write-only", "read-reset", and "trigger-only". The default access "write-only", "read-reset", and "trigger-only". The default access
mode is "read-write". mode is "read-write".
Whether optional elements are supported, and whether elements Whether optional elements are supported, and whether elements
defined as read-write can actually be written can be determined for defined as read-write can actually be written can be determined for
a given LFB instance by the CE by reading the property information a given LFB instance by the CE by reading the property information
of that element. of that element.
The following example defines two attributes for an LFB: The following example defines two attributes for an LFB:
<attributes> <attributes>
<attribute access="read-only" elementID=”1”> <attribute access="read-only" elementID=’’1’’>
<name>foo</name> <name>foo</name>
<synopsis>number of things</synopsis> <synopsis>number of things</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</attribute> </attribute>
<attribute access="read-write write-only" elementID=”2”> <attribute access="read-write write-only" elementID=’’2’’>
<name>bar</name> <name>bar</name>
<synopsis>number of this other thing</synopsis> <synopsis>number of this other thing</synopsis>
<atomic> <atomic>
<baseType>uint32</baseType> <baseType>uint32</baseType>
<rangeRestriction> <rangeRestriction>
<allowedRange min="10" max="2000"/> <allowedRange min="10" max="2000"/>
</rangeRestriction> </rangeRestriction>
</atomic> </atomic>
<defaultValue>10</defaultValue> <defaultValue>10</defaultValue>
</attribute> </attribute>
skipping to change at page 60, line 34 skipping to change at page 61, line 4
<typeRef>version</typeRef> <typeRef>version</typeRef>
</capability> </capability>
<capability elementID="4"> <capability elementID="4">
<name>limitBar</name> <name>limitBar</name>
<synopsis> <synopsis>
Maximum value of the "bar" attribute. Maximum value of the "bar" attribute.
</synopsis> </synopsis>
<typeRef>uint16</typeRef> <typeRef>uint16</typeRef>
</capability> </capability>
</capabilities> </capabilities>
4.7.6. <events> Element for LFB Notification Generation 4.7.6. <events> Element for LFB Notification Generation
The <events> element contains the information about the occurrences The <events> element contains the information about the occurrences
for which instances of this LFB class can generate notifications to for which instances of this LFB class can generate notifications to
the CE. the CE.
The <events> definition needs a baseID attributevalue, which is The <events> definition needs a baseID attributevalue, which is
normally <events baseID=”number”>. The value of the baseID is the normally <events baseID=’’number’’>. The value of the baseID is the
starting element for the path which identifies events. It must not starting element for the path which identifies events. It must not
be the same as the elementID of any top level attribute or be the same as the elementID of any top level attribute or
capability of the LFB class. In derived LFBs (i.e. ones with a capability of the LFB class. In derived LFBs (i.e. ones with a
<derivedFrom> element) where the parent LFB class has an events <derivedFrom> element) where the parent LFB class has an events
declaration, the baseID must not be present. Instead, the value declaration, the baseID must not be present. Instead, the value
from the parent class is used. from the parent class is used.
[editors note: There is an open issue with regard to how baseID is
used for an LFBclass and another class derived from it. Currently,
the derived class does not declare a baseID. It may make sense to
instead to require the baseID attribute and require that it have the
same value as the parent class events baseID. Both choices
(omission or inclusion of baseID in derived classes) leave room for
errors not covered by the XML Schema.]
The <events> element contains 0 or more <event> elements, each of The <events> element contains 0 or more <event> elements, each of
which declares a single event. The <event> element has an eventID which declares a single event. The <event> element has an eventID
attribute giving the unique ID of the event. The element will attribute giving the unique ID of the event. The element will
include: include:
. <eventTarget> element indicating which LFB field is tested to . <eventTarget> element indicating which LFB field is tested to
generate the event; generate the event;
. condition element indicating what condition on the field will . condition element indicating what condition on the field will
generate the event from a list of defined conditions; generate the event from a list of defined conditions;
. <eventReports> element indicating what values are to be . <eventReports> element indicating what values are to be
skipping to change at page 62, line 35 skipping to change at page 62, line 46
that case, one can subscribe to the event for the entire array by that case, one can subscribe to the event for the entire array by
referencing the properties of 7.8. One can also subscribe to a referencing the properties of 7.8. One can also subscribe to a
specific element, x, of the array by referencing the subscription specific element, x, of the array by referencing the subscription
property of 7.8.x and also access the threshold and filtering property of 7.8.x and also access the threshold and filtering
properties of 7.8.x. If the event is targeting an element of an properties of 7.8.x. If the event is targeting an element of an
array within an array, then there will be two (or conceivably more) array within an array, then there will be two (or conceivably more)
<eventSubscript> elements in the target. If so, for the case of two <eventSubscript> elements in the target. If so, for the case of two
elements, one would reference the properties of 7.8.x.y to get to elements, one would reference the properties of 7.8.x.y to get to
the threshold and filtering properties of an individual event. the threshold and filtering properties of an individual event.
[Editors note: As currently defined, threshold and filtering can Threshold and filtering conditions can only be applied to individual
only be applied to individual elements, not entire arrays. Should events. For events defined on elements of an array, this
this be changed to allow application to an array? If so, we would specification does not allow for defining a threshold or filtering
add the complication of having it potentially set differently on the condition on an event for all elements of an array.
element and the array as a whole.]
4.7.6.2 <events> Element Conditions 4.7.6.2 <events> Element Conditions
The condition element represents a condition that triggers a The condition element represents a condition that triggers a
notification. The list of conditions is: notification. The list of conditions is:
. <eventCreated/> the target must be an array, ending with a . <eventCreated/> the target must be an array, ending with a
subscript indication. The event is generated when an entry in subscript indication. The event is generated when an entry in
the array is created. This occurs even if the entry is created the array is created. This occurs even if the entry is created
by CE direction. by CE direction.
skipping to change at page 64, line 37 skipping to change at page 64, line 48
The model provides the definition of the structure of property The model provides the definition of the structure of property
information. There is a base class of property information. For information. There is a base class of property information. For
the array, alias, and event elements there are subclasses of the array, alias, and event elements there are subclasses of
property information providing additional fields. This information property information providing additional fields. This information
is accessed by the CE (and updated where applicable) via the PL is accessed by the CE (and updated where applicable) via the PL
protocol. While some property information is writeable, there is no protocol. While some property information is writeable, there is no
mechanism currently provided for checking the properties of a mechanism currently provided for checking the properties of a
property element. Writeability can only be checked by attempting to property element. Writeability can only be checked by attempting to
modify the value. modify the value.
4.8.1 Basic Properties 4.8.1. Basic Properties
The basic property definition, along with the scalar for The basic property definition, along with the scalar for
accessibility is below. Note that this access permission accessibility is below. Note that this access permission
information is generally read-only. information is generally read-only.
<dataTypeDef> <dataTypeDef>
<name>accessPermissionValues</name> <name>accessPermissionValues</name>
<synopsis> <synopsis>
The possible values of attribute access permission The possible values of attribute access permission
</synopsis> </synopsis>
skipping to change at page 65, line 40 skipping to change at page 66, line 4
<element elementID="1"> <element elementID="1">
<name>accessibility</name> <name>accessibility</name>
<synopsis> <synopsis>
does the element exist, and does the element exist, and
can it be read or written can it be read or written
</synopsis> </synopsis>
<typeRef>accessPermissionValues</typeRef> <typeRef>accessPermissionValues</typeRef>
</element> </element>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
4.8.2. Array Properties
4.8.2 Array Properties
The properties for an array add a number of important pieces of The properties for an array add a number of important pieces of
information. These properties are also read-only. information. These properties are also read-only.
<dataTypeDef> <dataTypeDef>
<name>arrayElementProperties</name> <name>arrayElementProperties</name>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<element elementID=”2”> <element elementID=’’2’’>
<name>entryCount</name> <name>entryCount</name>
<synopsis>the number of entries in the array</synopsis> <synopsis>the number of entries in the array</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID=”3”> <element elementID=’’3’’>
<name>highestUsedSubscript</name> <name>highestUsedSubscript</name>
<synopsis>the last used subscript in the array</synopsis> <synopsis>the last used subscript in the array</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID=”4”> <element elementID=’’4’’>
<name>firstUnusedSubscript</name> <name>firstUnusedSubscript</name>
<synopsis> <synopsis>
The subscript of the first unused array element The subscript of the first unused array element
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
4.8.3 Event Properties 4.8.3. String Properties
The properties of a string specify the actual octet length and the
maximum octet length for the element. The maximum length is
included because an FE implementation may limit a string to be
shorter than the limit in the LFB Class definition.
<dataTypeDef>
<name>stringElementProperties</name>
<struct>
<derivedFrom>baseElementProperties</derivedFrom>
<element elementID=’’2’’>
<name>stringLength</name>
<synopsis>the number of octets in the string</synopsis>
<typeRef>uint32</typeRef>
</element>
<element elementID=’’3’’>
<name>maxStringLength</name>
<synopsis>
the maximum number of octets in the string
</synopsis>
<typeRef>uint32</typeRef>
</element>
</struct>
</dataTypeDef>
4.8.4. Octetstring Properties
The properties of an octetstring specify the actual length and the
maximum length, since the FE implementation may limit an octetstring
to be shorter than the LFB Class definition.
<dataTypeDef>
<name>octetstringElementProperties</name>
<struct>
<derivedFrom>baseElementProperties</derivedFrom>
<element elementID=’’2’’>
<name>octetstringLength</name>
<synopsis>
the number of octets in the octetstring
</synopsis>
<typeRef>uint32</typeRef>
</element>
<element elementID=’’3’’>
<name>maxOctetstringLength</name>
<synopsis>
the maximum number of octets in the octetstring
</synopsis>
<typeRef>uint32</typeRef>
</element>
</struct>
</dataTypeDef>
4.8.5. Event Properties
The properties for an event add three (usually) writeable fields. The properties for an event add three (usually) writeable fields.
One is the subscription field. 0 means no notification is One is the subscription field. 0 means no notification is
generated. Any non-zero value (typically 1 is used) means that a generated. Any non-zero value (typically 1 is used) means that a
notification is generated. The hysteresis field is used to suppress notification is generated. The hysteresis field is used to suppress
generation of notifications for oscillations around a condition generation of notifications for oscillations around a condition
value, and is described in the text for events. The threshold field value, and is described in the text for events. The threshold field
is used for the <eventGreaterThan/> and <eventLessThan/> conditions. is used for the <eventGreaterThan/> and <eventLessThan/> conditions.
It indicates the value to compare the event target against. Using It indicates the value to compare the event target against. Using
the properties allows the CE to set the level of interest. FEs the properties allows the CE to set the level of interest. FEs
which do not supporting setting the threshold for events will make which do not supporting setting the threshold for events will make
this field read-only. this field read-only.
<dataTypeDef> <dataTypeDef>
<name>eventElementProperties</name> <name>eventElementProperties</name>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<element elementID=”2”> <element elementID=’’2’’>
<name>registration</name> <name>registration</name>
<synopsis> <synopsis>
has the CE registered to be notified of this event has the CE registered to be notified of this event
</synopsis> </synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID=”3”> <element elementID=’’3’’>
<name>threshold</name> <name>threshold</name>
<synopsis> comparison value for level crossing events <synopsis> comparison value for level crossing events
</synopsis> </synopsis>
</optional </optional
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID=”4”> <element elementID=’’4’’>
<name>eventHysteresis</name> <name>eventHysteresis</name>
<synopsis> region to suppress event recurrence notices <synopsis> region to suppress event recurrence notices
</synopsis> </synopsis>
</optional> </optional>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID=”5”> <element elementID=’’5’’>
<name>eventCount</name> <name>eventCount</name>
<synopsis> number of occurrences to suppress <synopsis> number of occurrences to suppress
</synopsis> </synopsis>
</optional> </optional>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID=”6”> <element elementID=’’6’’>
<name>eventHysteresis</name> <name>eventHysteresis</name>
<synopsis> time interval in ms between notifications <synopsis> time interval in ms between notifications
</synopsis> </synopsis>
</optional> </optional>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
</struct> </struct>
<dataTypeDef> <dataTypeDef>
4.8.3.1 Common Event Filtering 4.8.5.1. Common Event Filtering
The event properties have values for controlling several filter The event properties have values for controlling several filter
conditions. Support of these conditions is optional, but all conditions. Support of these conditions is optional, but all
conditions SHOULD be supported. Events which are reliably known not conditions SHOULD be supported. Events which are reliably known not
to be subject to rapid occurrence or other concerns may not support to be subject to rapid occurrence or other concerns may not support
all filter conditions. all filter conditions.
Currently, three different filter condition variables are defined. Currently, three different filter condition variables are defined.
These are eventCount, eventInterval, and eventHysteris. Setting the These are eventCount, eventInterval, and eventHysteresis. Setting
condition variables to 0 (their default value) means that the the condition variables to 0 (their default value) means that the
condition is not checked. condition is not checked.
Conceptually, when an event is triggered, all configured conditions Conceptually, when an event is triggered, all configured conditions
are checked. If no filter conditions are triggered, or if any are checked. If no filter conditions are triggered, or if any
trigger conditions are met, the event notification is generated. If trigger conditions are met, the event notification is generated. If
there are filter conditions, and no condition is met, then no event there are filter conditions, and no condition is met, then no event
notification is generated. Event filter conditions have reset notification is generated. Event filter conditions have reset
behavior when an event notification is generated. If any condition behavior when an event notification is generated. If any condition
is passed, and the notification is generated, the the notification is passed, and the notification is generated, the notification reset
reset behavior is performed on all conditions, even those which had behavior is performed on all conditions, even those which had not
not passed. This provides a clean definition of the interaction of passed. This provides a clean definition of the interaction of the
the various event conditions. various event conditions.
An example of the interaction of conditions is an event with an An example of the interaction of conditions is an event with an
eventCount property set to 5 and an eventInterval property set to eventCount property set to 5 and an eventInterval property set to
500 milliseconds. Suppose that a burst of occurrences of this event 500 milliseconds. Suppose that a burst of occurrences of this event
is detected by the FE. The first occurrence will cause a is detected by the FE. The first occurrence will cause a
notification to be sent to the CE. Then, if four more occurrences notification to be sent to the CE. Then, if four more occurrences
are detected rapidly (less than 0.5 seconds) they will not result in are detected rapidly (less than 0.5 seconds) they will not result in
notifications. If two more occurrences are detected, then the notifications. If two more occurrences are detected, then the
second of those will result in a notification. Alternatively, if second of those will result in a notification. Alternatively, if
more than 500 miliseconds has passed since the notification and an more than 500 milliseconds has passed since the notification and an
occurrence is detected, that will result in a notification. In occurrence is detected, that will result in a notification. In
either case, the count and time interval suppression is reset no either case, the count and time interval suppression is reset no
matter which condition actually caused the notification. matter which condition actually caused the notification.
4.8.3.2 Event Hysteresis Filtering 4.8.5.2. Event Hysteresis Filtering
Events with numeric conditions can have hysteresis filters applied Events with numeric conditions can have hysteresis filters applied
to them. The hystersis level is defined by a property of the event. to them. The hysteresis level is defined by a property of the
This allows the FE to notify the CE of the hysteresis applied, and event. This allows the FE to notify the CE of the hysteresis
if it chooses, the FE can allow the CE to modify the hysteresis. applied, and if it chooses, the FE can allow the CE to modify the
This applies to <eventChanged/> for a numeric field, and to hysteresis. This applies to <eventChanged/> for a numeric field,
<eventGreaterThan/> and <eventLessThan/>. The content of a and to <eventGreaterThan/> and <eventLessThan/>. The content of a
<variance> element is a numeric value. When supporting hysteresis, <variance> element is a numeric value. When supporting hysteresis,
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 condition has become untrue by at least the hysteresis from the
event property. To be specific, if the hysteresis is V, then event property. To be specific, if the hysteresis is V, then
. For a <eventChanged/> condition, if the last notification was . For a <eventChanged/> condition, if the last notification was
for value X, then the <changed/> notification MUST NOT be for value X, then the <changed/> notification MUST NOT be
generated until the value reaches X +/- V. generated until the value reaches X +/- V.
. For a <eventGreaterThan/> condition with threshold T, once the . 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 – again until the field first becomes less than or equal to T - -
V, and then exceeds T. V, and then exceeds T.
. For a <eventLessThan/> condition with threshold T, once the . For a <eventLessThan/> condition with threshold T, once the
event has been generate at least once it MUST NOT be generated event has been generate at least once it MUST NOT be generated
again until the field first becomes greater than or equal to T again until the field first becomes greater than or equal to T
+ V, and then becomes less than T. + V, and then becomes less than T.
4.8.3.3 Event Count Filtering 4.8.5.3. Event Count Filtering
Events may have a count filtering condition. This property, if set Events may have a count filtering condition. This property, if set
to a non-zero value, indicates the number of occurrences of the event to a non-zero value, indicates the number of occurrences of the event
that should be considered redundant and not result in a notification. that should be considered redundant and not result in a notification.
Thus, if this property is set to 1, and no other conditions apply, Thus, if this property is set to 1, and no other conditions apply,
then every other detected occurrence of the event will result in a then every other detected occurrence of the event will result in a
notification. This particular meaning is chosen so that the value 1 notification. This particular meaning is chosen so that the value 1
has a distinct meaning from the value 0. has a distinct meaning from the value 0.
A conceptual implementation (not required) for this might be an A conceptual implementation (not required) for this might be an
internal suppression counter. Whenever an event is triggered, the internal suppression counter. Whenever an event is triggered, the
counter is checked. If the counter is 0, a notification is counter is checked. If the counter is 0, a notification is
generated. Whether a notification is generated or not, the counter generated. Whether a notification is generated or not, the counter
is incremented. If the counter exceeds the configured value, it is is incremented. If the counter exceeds the configured value, it is
reset to 0. In this conceptual implementation the reset behavior reset to 0. In this conceptual implementation the reset behavior
when a notification is generated can be thought of as setting the when a notification is generated can be thought of as setting the
counter to 1. counter to 1.
[Editor’s note: a better description of the conceptual algorithm is 4.8.5.4. Event Time Filtering
sought.]
4.8.3.4 Event Time Filtering
Events may have a time filtering condition. This property Events may have a time filtering condition. This property
represents the minimum time interval (in the absence of some other represents the minimum time interval (in the absence of some other
filtering condition being passed) between generating notifications of filtering condition being passed) between generating notifications of
detected events. This condition MUST only be passed if the time detected events. This condition MUST only be passed if the time
since the last notification of the event is longer than the since the last notification of the event is longer than the
configured interval in milliseconds. configured interval in milliseconds.
Conceptually, this can be thought of as a stored timestamp which is Conceptually, this can be thought of as a stored timestamp which is
compared with the detection time, or as a timer that is running that compared with the detection time, or as a timer that is running that
resets a suppression flag. In either case, if a notification is resets a suppression flag. In either case, if a notification is
generated due to passing any condition then the time interval generated due to passing any condition then the time interval
detection MUST be restarted. detection MUST be restarted.
4.8.4 Alias Properties 4.8.6. Alias Properties
The properties for an alias add three (usually) writeable fields. The properties for an alias add three (usually) writeable fields.
These combine to identify the target element the subject alias These combine to identify the target element the subject alias
refers to. refers to.
<dataTypeDef> <dataTypeDef>
<name>aliasElementProperties</name> <name>aliasElementProperties</name>
<struct> <struct>
<derivedFrom>baseElementProperties</derivedFrom> <derivedFrom>baseElementProperties</derivedFrom>
<element elementID=”2”> <element elementID=’’2’’>
<name>targetLFBClass</name> <name>targetLFBClass</name>
<synopsis>the class ID of the alias target</synopsis> <synopsis>the class ID of the alias target</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID=”3”> <element elementID=’’3’’>
<name>targetLFBInstance</name> <name>targetLFBInstance</name>
<synopsis>the instand ID of the alias target</synopsis> <synopsis>the instance ID of the alias target</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID=”4”> <element elementID=’’4’’>
<name>targetElementPath</name> <name>targetElementPath</name>
<synopsis> <synopsis>
the path to the element target the path to the element 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.
</synopsis> </synopsis>
<typeRef>octetstring[128]</typeRef> <typeRef>octetstring[128]</typeRef>
</element> </element>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
skipping to change at page 71, line 52 skipping to change at page 73, line 19
<xsd:element ref="description" minOccurs="0"/> <xsd:element ref="description" minOccurs="0"/>
<xsd:group ref="typeDeclarationGroup"/> <xsd:group ref="typeDeclarationGroup"/>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
</xsd:element> </xsd:element>
</xsd:sequence> </xsd:sequence>
</xsd:complexType> </xsd:complexType>
<!-- <!--
Predefined (built-in) atomic data-types are: Predefined (built-in) atomic data-types are:
char, uchar, int16, uint16, int32, uint32, int64, uint64, char, uchar, int16, uint16, int32, uint32, int64, uint64,
string[N], string, byte[N], boolean, octetstring[N] string[N], string, byte[N], boolean, octetstring[N],
float16, float32, float64 float16, float32, float64
--> -->
<xsd:group name="typeDeclarationGroup"> <xsd:group name="typeDeclarationGroup">
<xsd:choice> <xsd:choice>
<xsd:element name="typeRef" type="typeRefNMTOKEN"/> <xsd:element name="typeRef" type="typeRefNMTOKEN"/>
<xsd:element name="atomic" type="atomicType"/> <xsd:element name="atomic" type="atomicType"/>
<xsd:element name="array" type="arrayType"/> <xsd:element name="array" type="arrayType"/>
<xsd:element name="struct" type="structType"/> <xsd:element name="struct" type="structType"/>
<xsd:element name="union" type="structType"/> <xsd:element name="union" type="structType"/>
<xsd:element name="alias" type="typeRefNMTOKEN"/> <xsd:element name="alias" type="typeRefNMTOKEN"/>
skipping to change at page 81, line 41 skipping to change at page 83, line 5
class as well. Details of that class are defined in the ForCES class as well. Details of that class are defined in the ForCES
protocol document. protocol 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="http://ietf.org/forces/1.0/lfbmodel"
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" xsi:schemaLocation="http://ietf.org/forces/1.0/lfbmodel.xsd"
provides="FEObject"> provides="FEObject">
<!—xmlns and schemaLocation need to be fixed --> <!-- - - 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>
<element elementID="1"> <element elementID="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>
</element> </element>
skipping to change at page 83, line 6 skipping to change at page 84, line 19
<synopsis> <synopsis>
The name of a supported LFB Class The name of a supported LFB Class
</synopsis> </synopsis>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</element> </element>
<element elementID="2"> <element elementID="2">
<name>LFBClassID</name> <name>LFBClassID</name>
<synopsis>the id of a supported LFB Class</synopsis> <synopsis>the id of a supported LFB Class</synopsis>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID="3"> <element elementID=’’3’’>
<name>LFBVersion</name>
<synopsis>
The version of the LFB Class used
by this FE.
</synopsis>
<typeRef>string</typeRef>
<element elementID="4">
<name>LFBOccurrenceLimit</name> <name>LFBOccurrenceLimit</name>
<synopsis> <synopsis>
the upper limit of instances of LFBs of this class the upper limit of instances of LFBs of this class
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<!-- For each port group, how many ports can exist <!-- For each port group, how many ports can exist
--> -->
<element elementID="4"> <element elementID="5">
<name>PortGroupLimits</name> <name>PortGroupLimits</name>
<synopsis>Table of Port Group Limits</synopsis> <synopsis>Table of Port Group Limits</synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>PortGroupLimitType</typeRef> <typeRef>PortGroupLimitType</typeRef>
</array> </array>
</element> </element>
<!-- for the named LFB Class, the LFB Classes it may follow --> <!-- for the named LFB Class, the LFB Classes it may follow -->
<element elementID="5"> <element elementID="6">
<name>CanOccurAfters</name> <name>CanOccurAfters</name>
<synopsis> <synopsis>
List of LFB Classes that this LFB class can follow List of LFB Classes that this LFB class can follow
</synopsis> </synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>LFBAdjacencyLimitType</typeRef> <typeRef>LFBAdjacencyLimitType</typeRef>
</array> </array>
</element> </element>
<!-- for the named LFB Class, the LFB Classes that may follow it <!-- for the named LFB Class, the LFB Classes that may follow it
--> -->
<element elementID="6"> <element elementID="7">
<name>CanOccurBefores</name> <name>CanOccurBefores</name>
<synopsis> <synopsis>
List of LFB Classes that can follow this LFB class List of LFB Classes that can follow this LFB class
</synopsis> </synopsis>
<optional/> <optional/>
<array type="variable-size"> <array type="variable-size">
<typeRef>LFBAdjacencyLimitType</typeRef> <typeRef>LFBAdjacencyLimitType</typeRef>
</array> </array>
</element> </element>
</struct> </struct>
skipping to change at page 84, line 40 skipping to change at page 86, line 11
<typeRef>uint32</typeRef> <typeRef>uint32</typeRef>
</element> </element>
<element elementID="2"> <element elementID="2">
<name>InterfaceToNeighbor</name> <name>InterfaceToNeighbor</name>
<synopsis> <synopsis>
FE's interface that connects to this neighbor FE's interface that connects to this neighbor
</synopsis> </synopsis>
<optional/> <optional/>
<typeRef>string</typeRef> <typeRef>string</typeRef>
</element> </element>
<element elementID="3"> <element elementID=’’3’’>
<name>NeighborNetworkAddress</name> <name>NeighborInterface</name>
<synopsis>
The network layer address of the neighbor.
Presumably, the network type can be
determined from the interface information.
</synopsis>
<typeRef>octetsting[16]</typeRef>
</element>
<element elementID="4">
<name>NeighborMACAddress</name>
<synopsis> <synopsis>
The media access control address of the neighbor. The name of the interface on the neighbor to
which this FE is adjacent. This is required
Again, it is presumed the type can be determined In case two FE’s are adjacent on more than
from the interface information. one interface.
</synopsis> </synopsis>
<typeRef>octetstring[8]</typeRef> <optional/>
<typeRef>string</typeRef>
</element> </element>
</struct> </struct>
</dataTypeDef> </dataTypeDef>
<dataTypeDef> <dataTypeDef>
<name>LFBSelectorType</name> <name>LFBSelectorType</name>
<synopsis> <synopsis>
Unique identification of an LFB class-instance Unique identification of an LFB class-instance
</synopsis> </synopsis>
<struct> <struct>
<element elementID="1"> <element elementID="1">
skipping to change at page 88, line 43 skipping to change at page 90, line 7
information about how LFBs of the specified class may be connected information about how LFBs of the specified class may be connected
to other LFBs. This information should describe which LFB classes to other LFBs. This information should describe which LFB classes
the specified LFB class may succeed or precede in the LFB topology. the specified LFB class may succeed or precede in the LFB topology.
The FE should include information as to which port groups may be The FE should include information as to which port groups may be
connected to the given adjacent LFB class. If port group connected to the given adjacent LFB class. If port group
information is omitted, it is assumed that all port groups may be information is omitted, it is assumed that all port groups may be
used. used.
5.2.2.1. LFBName 5.2.2.1. LFBName
This element has as its value the name of the LFB being described. This element has as its value the name of the LFB Class being
described.
5.2.2.2. LFBOccurrenceLimit 5.2.2.2. LFBClassID
The numeric ID of the LFB Class being described. While conceptually
redundant with the LFB Name, both are included for clarity and to
allow consistency checking.
5.2.2.3. LFBVersion
The version string specifying the LFB Class version supported by
this FE. As described above in versioning, an FE can support only a
single version of a given LFB Class.
5.2.2.4. LFBOccurrenceLimit
This element, if present, indicates the largest number of instances This element, if present, indicates the largest number of instances
of this LFB class the FE can support. For FEs that do not have the of this LFB class the FE can support. For FEs that do not have the
capability to create or destroy LFB instances, this can either be capability to create or destroy LFB instances, this can either be
omitted or be the same as the number of LFB instances of this class omitted or be the same as the number of LFB instances of this class
contained in the LFB list attribute. contained in the LFB list attribute.
5.2.2.3. PortGroupLimits and PortGroupLimitType 5.2.2.5. PortGroupLimits and PortGroupLimitType
The PortGroupLimits element is an array of information about the The PortGroupLimits element is an array of information about the
port groups supported by the LFB class. The structure of the port port groups supported by the LFB class. The structure of the port
group limit information is defined by the PortGroupLimitType group limit information is defined by the PortGroupLimitType
dataTypeDef. dataTypeDef.
Each PortGroupLimits array element contains information describing a Each PortGroupLimits array element contains information describing a
single port group of the LFB class. Each array element contains the single port group of the LFB class. Each array element contains the
name of the port group in the PortGroupName element, the fewest name of the port group in the PortGroupName element, the fewest
number of ports that can exist in the group in the MinPortCount number of ports that can exist in the group in the MinPortCount
element, and the largest number of ports that can exist in the group element, and the largest number of ports that can exist in the group
in the MaxPortCount element. in the MaxPortCount element.
5.2.2.4.CanOccurAfters and LFBAdjacencyLimitType 5.2.2.6.CanOccurAfters and LFBAdjacencyLimitType
The CanOccurAfters element is an array that contains the list of The CanOccurAfters element is an array that contains the list of
LFBs the described class can occur after. The array elements are LFBs the described class can occur after. The array elements are
defined in the LFBAdjacencyLimitType dataTypeDef. defined in the LFBAdjacencyLimitType dataTypeDef.
The array elements describe a permissible positioning of the The array elements describe a permissible positioning of the
described LFB class, referred to here as the SupportedLFB. described LFB class, referred to here as the SupportedLFB.
Specifically, each array element names an LFB that can topologically Specifically, each array element names an LFB that can topologically
precede that LFB class. That is, the SupportedLFB can have an input precede that LFB class. That is, the SupportedLFB can have an input
port connected to an output port of an LFB that appears in the port connected to an output port of an LFB that appears in the
skipping to change at page 89, line 44 skipping to change at page 91, line 20
element is included. This element occurs once for each input port element is included. This element occurs once for each input port
group of the SupportedLFB that can be connected to an output port of group of the SupportedLFB that can be connected to an output port of
the NeighborLFB. the NeighborLFB.
[e.g., Within a SupportedLFBs element, each array element of the [e.g., Within a SupportedLFBs element, each array element of the
CanOccurAfters array must have a unique NeighborLFB, and within each CanOccurAfters array must have a unique NeighborLFB, and within each
array element each viaPort must represent a distinct and valid input array element each viaPort must represent a distinct and valid input
port group of the SupportedLFB. The LFB Class definition schema port group of the SupportedLFB. The LFB Class definition schema
does not yet support uniqueness declarations] does not yet support uniqueness declarations]
5.2.2.5. CanOccurBefores and LFBAdjacencyLimitType 5.2.2.7. CanOccurBefores and LFBAdjacencyLimitType
The CanOccurBefores array holds the information about which LFB The CanOccurBefores array holds the information about which LFB
classes can follow the described class. Structurally this element classes can follow the described class. Structurally this element
parallels CanOccurAfters, and uses the same type definition for the parallels CanOccurAfters, and uses the same type definition for the
array element. array element.
The array elements list those LFB classes that the SupportedLFB may The array elements list those LFB classes that the SupportedLFB may
precede in the topology. In this element, the precede in the topology. In this element, the
viaPort element of the array value represents the output port group viaPort element of the array value represents the output port group
of the SupportedLFB that may be connected to the NeighborLFB. As of the SupportedLFB that may be connected to the NeighborLFB. As
with CanOccurAfters, viaPort may occur multiple times if multiple with CanOccurAfters, viaPort may occur multiple times if multiple
output ports may legitimately connect to the given NeighborLFB output ports may legitimately connect to the given NeighborLFB
class. class.
[And a similar set of uniqueness constraints apply to the [And a similar set of uniqueness constraints apply to the
CanOccurBefore clauses, even though an LFB may occur both in CanOccurBefore clauses, even though an LFB may occur both in
CanOccurAfter and CanOccurBefore.] CanOccurAfter and CanOccurBefore.]
5.2.2.6. LFBClassCapabilities 5.2.2.8. LFBClassCapabilities
This element contains capability information about the subject LFB
class whose structure and semantics are defined by the LFB class
definition.
[Note: Important Omissions] While it would be desirable to include class capability level
information, this is not included in the model. While such
information belongs in the FE Object in the supported class table,
the contents of that information would be class specific. The
currently expected encoding structures for transferring information
between the CE and FE are such that allowing completely unspecified
information would be likely to induce parse errors. We could
specify that the information is encoded in an octetstring, but then
we would have to define the internal format of that octet string.
However, this element does not appear in the definition, because the As there also are not currently any defined LFB Class level
author can not figure out how to write it. Capabilities that the FE needs to report, this information is not
present now, but may be added in a future version of the FE Protocol
Object. (This is an example of a case where versioning, rather than
inheritance, would be needed, since the FE Object must have class ID
1 and instance ID 1 so that the protocol behavior can start by
finding this object.)
5.3. FEAttributes 5.3. FEAttributes
The attributes element is included if the class definition contains The attributes element is included if the class definition contains
the attributes of the FE that are not considered "capabilities". the attributes of the FE that are not considered "capabilities".
Some of these attributes are writeable, and some are read-only, Some of these attributes are writeable, and some are read-only,
which should be indicated by the capability information. which should be indicated by the capability information.
[Editors note - At the moment, the set of attributes is woefully
incomplete.]
5.3.1. FEStatus 5.3.1. FEStatus
This attribute carries the overall state of the FE. For now, it is This attribute 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 element is an array of information about the LFBs The LFBSelectors element 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. information is defined by the LFBSelectorType.
skipping to change at page 91, line 22 skipping to change at page 93, line 5
of the link, and must reference LFBs in the LFB instance table. The of the link, and must reference LFBs in the LFB instance table. The
FromPortGroup and ToPortGroup must identify output and input port FromPortGroup and ToPortGroup must identify output and input port
groups defined in the LFB classes of the LFB instances identified by groups defined in the LFB classes of the LFB instances identified by
FromLFBID and ToLFBID. The FromPortIndex and ToPortIndex fields FromLFBID and ToLFBID. The FromPortIndex and ToPortIndex fields
select the elements from the port groups that this link connects. select the elements from the port groups that this link connects.
All links are uniquely identified by the FromLFBID, FromPortGroup, All links are uniquely identified by the FromLFBID, FromPortGroup,
and FromPortIndex fields. Multiple links may have the same ToLFBID, and FromPortIndex fields. Multiple links may have the same ToLFBID,
ToPortGroup, and ToPortIndex as this model supports fan in of inter- ToPortGroup, and ToPortIndex as this model supports fan in of inter-
LFB links but not fan out. LFB links but not fan out.
5.3.4. FENeighbors an FEConfiguredNeighborType 5.3.4. FENeighbors and FEConfiguredNeighborType
The FENeighbors element is an array of information about manually The FENeighbors element is an array of information about manually
configured adjacencies between this FE and other FEs. The content configured adjacencies between this FE and other FEs. The content
of the array is defined by the FEConfiguredNeighborType element. of the array is defined by the FEConfiguredNeighborType element.
This array is intended to capture information that may be configured This array is intended to capture information that may be configured
on the FE and is needed by the CE, where one array entry corresponds on the FE and is needed by the CE, where one array entry corresponds
to each configured neighbor. Note that this array is not intended to each configured neighbor. Note that this array is not intended
to represent the results of any discovery protocols, as those will to represent the results of any discovery protocols, as those will
have their own LFBs. have their own LFBs.
Similarly, the MAC address information in the table is intended to While there may be many ways to configure neighbors, the FE-ID is
be used in situations where neighbors are configured by MAC address. the best way for the CE to correlate entities. And the interface
Resolution of network layer to MAC address information should be identifier (name string) is the best correlator. The CE will be
captured in ARP LFBs and not duplicated in this table. Note that able to determine the IP address and media level information about
the same neighbor may be reached through multiple interfaces or at the neighbor from the neighbor directly. Omitting that information
multiple addresses. There is no uniqueness requirement of any sort from this table avoids the risk of incorrect double configuration.
on occurrences of the FENeighbors element.
Information about the intended forms of exchange with a given Information about the intended forms of exchange with a given
neighbor is not captured here, only the adjacency information is neighbor is not captured here, only the adjacency information is
included. included.
5.3.4.1.NeighborID 5.3.4.1.NeighborID
This is the ID in some space meaningful to the CE for the neighbor. This is the ID in some space meaningful to the CE for the neighbor.
If this table remains, we probably should add an FEID from the same If this table remains, we probably should add an FEID from the same
space as an attribute of the FE. space as an attribute of the FE.
5.3.4.2.NeighborInterface 5.3.4.2.InterfaceToNeighbor
This identifies the interface through which the neighbor is reached. This identifies the interface through which the neighbor is reached.
[Editors note: As the port structures become better defined, the 5.3.4.3.NeighborInterface
type for this should be filled in with the types necessary to
reference the various possible neighbor interfaces, include physical
interfaces, logical tunnels, virtual circuits, etc.]
5.3.4.3. NeighborNetworkAddress
Neighbor configuration is frequently done on the basis of a network
layer address. For neighbors configured in that fashion, this is
where that address is stored.
5.3.4.4.NeighborMacAddress
Neighbors are sometimes configured using MAC level addresses This identifies the interface on the neighbor through which the
(Ethernet MAC address, circuit identifiers, etc.) If such addresses neighbor is reached. The interface identification is needed when
are used to configure the adjacency, then that information is stored either only one side of the adjacency has configuration information,
here. Note that over some ports such as physical point to point or the two FEs are adjacent on more than one interface.
links or virtual circuits considered as individual interfaces, there
is no need for either form of address.
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 RFC 3654 [1]. The requirements outlined in Section 5 of RFC 3654 [1]. The
requirements can be separated into general requirements (Sections 5, requirements can be separated into general requirements (Sections 5,
5.1 - 5.4) and the specification of the minimal set of logical 5.1 - 5.4) and the specification of the minimal set of logical
functions that the FE model must support (Section 5.5). functions that the FE model must support (Section 5.5).
The general requirement on the FE model is that it be able to The general requirement on the FE model is that it be able to
skipping to change at page 93, line 18 skipping to change at page 94, line 36
Instantiated LFBs are interconnected in a directed graph that Instantiated LFBs are interconnected in a directed graph that
describes the ordering of the functions within an FE. This directed describes the ordering of the functions within an FE. This directed
graph is described by the topology model. The combination of the graph is described by the topology model. The combination of the
attributes of the instantiated LFBs and the topology describe the attributes of the instantiated LFBs and the topology describe the
packet processing functions available on the FE (current state). packet processing functions available on the FE (current state).
Another key component of the FE model is the FE attributes. The FE Another key component of the FE model is the FE attributes. The FE
attributes are used mainly to describe the capabilities of the FE, attributes are used mainly to describe the capabilities of the FE,
but they also convey information about the FE state. but they also convey information about the FE state.
The FE model also includes a definition of the minimal set of LFBs The FE model includes only the definition of the FE Object LFB
that is required by Section 5.5 of RFC 3564[1]. The sections that itself. Meeting the full set of working group requirements requires
follow provide more detail on the specifics of each of those LFBs. other LFBs. The class definitions for those LFBs will be provided
Note that the details of the LFBs are contained in a separate LFB in other documents.
Class Library document. [EDITOR - need to add a reference to that
document].
6.1. Port Functions
The FE model can be used to define a Port LFB class and its
technology-specific subclasses to map the physical port of the
device to the LFB model with both static and configurable
attributes. The static attributes model the type of port, link
speed, etc. The configurable attributes model the addressing,
administrative status, etc.
6.2. Forwarding Functions
Because forwarding function is one of the most common and important
functions in the forwarding plane, it requires special attention in
modeling to allow design flexibility, implementation efficiency,
modeling accuracy and configuration simplicity. Toward that end, it
is recommended that the core forwarding function being modeled by
the combination of two LFBs -- Longest Prefix Match (LPM) classifier
LFB and Next Hop LFB. Special header writer LFB is also needed to
take care of TTL decrement and checksum etc.
6.3. QoS Functions
The LFB class library includes descriptions of the Meter, Queue,
Scheduler, Counter and Dropper LFBs to support the QoS functions in
the forwarding path. The FE model can also be used to define other
useful QoS functions as needed. These LFBs allow the CE to
manipulate the attributes to model IntServ or DiffServ functions.
6.4. Generic Filtering Functions
Various combinations of Classifier, Redirector, Meter and Dropper
LFBs can be used to model a complex set of filtering functions.
6.5. Vendor Specific Functions
New LFB classes can be defined according to the LFB model as
described in Section 4 to support vendor specific functions. A new
LFB class can also be derived from an existing LFB class through
inheritance.
6.6.High-Touch Functions
High-touch functions are those that take action on the contents or
headers of a packet based on content other than what is found in the
IP header. Examples of such functions include NAT, ALG, firewall,
tunneling and L7 content recognition. It is not practical to
include all possible high-touch functions in the initial LFB library
due to the number and complexity. However, the flexibility of the
LFB model and the power of interconnection in LFB topology should
make it possible to model any high-touch functions.
6.7. Security Functions
Security functions are not included in the initial LFB class
library. However, the FE model is flexible and powerful enough to
model the types of encryption and/or decryption functions that an FE
supports and the associated attributes for such functions.
The IP Security Policy (IPSP) Working Group in the IETF has started
work in defining the IPSec Policy Information Base [8]. We will try
to reuse as much of the work as possible.
6.8. Off-loaded Functions
In addition to the packet processing functions typically found on
the FEs, some logical functions may also be executed asynchronously
by some FEs, as directed by a finite-state machine and triggered not
only by packet events, but by timer events as well. Examples of
such functions include; finite-state machine execution required by
TCP termination or OSPF Hello processing off-loaded from the CE. By
defining LFBs for such functions, the FE model is capable of
expressing these asynchronous functions to allow the CE to take
advantage of such off-loaded functions on the FEs.
6.9. IPFLOW/PSAMP Functions
RFC 3917 [9] defines an architecture for IP traffic flow monitoring,
measuring and exporting. The LFB model supports statistics
collection on the LFB by including statistical attributes (Section
4.7.4) in the LFB class definitions; in addition, special statistics
collection LFBs such as meter LFBs and counter LFBs can also be used
to support accounting functions in the FE.
[10] describes a framework to define a standard set of capabilities
for network elements to sample subsets of packets by statistical and
other methods. Time event generation, filter LFB, and counter/meter
LFB are the elements needed to support packet filtering and sampling
functions -- these elements can all be supported in the FE model.
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:
skipping to change at page 95, line 52 skipping to change at page 95, line 23
beginning of the PA phase, and often frequently during the PA phase beginning of the PA phase, and often frequently during the PA phase
(especially for the query of statistical counters). (especially for the query of statistical counters).
Items 6) and 7) are "command" types of exchanges, where the main 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) flow of information is from the CEs to the FEs. Messages in Item 6)
(the LFB re-configuration commands) are expected to be used (the LFB re-configuration commands) are expected to be used
frequently. Item 7) (LFB topology re-configuration) is needed only frequently. Item 7) (LFB topology re-configuration) is needed only
if dynamic LFB topologies are supported by the FEs and it is if dynamic LFB topologies are supported by the FEs and it is
expected to be used infrequently. expected to be used infrequently.
Among the seven types of payload information the ForCES protocol The inter-FE topology (item 1 above) can be determined by the CE in
carries between CEs and FEs, the FE model covers all of them except many ways. Neither this document nor the Forces protocol mandates a
item 1), which concerns the inter-FE topology. The FE model focuses specific mechanism. The LFB Class definition does include the
on the LFB and LFB topology within a single FE. Since the capability for an FE to be configured with, and provides to the CE
information related to item 1) requires global knowledge about all in response to a query, the identity of its neighbors. There may
of the FEs and their inter-connection with each other, this exchange also be defined specific LFB classes and protocols for neighbor
is part of the ForCES base protocol instead of the FE model. discovery. Routing protocols may be used by 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 9: messages are visualized in Figure 9:
+--------+ +--------+
..........-->| CE | ..........-->| CE |
/----\ . +--------+ /----\ . +--------+
\____/ FE Model . ^ | \____/ FE Model . ^ |
| |................ (1),2 | | 6, 7 | |................ (1),2 | | 6, 7
| | (off-line) . 3, 4, 5 | | | | (off-line) . 3, 4, 5 | |
skipping to change at page 100, line 22 skipping to change at page 99, line 46
a group of LFBs (or all) may be supported. a group of LFBs (or all) may be supported.
. Must support addressing of individual attribute of an LFB. . Must support addressing of individual attribute of an LFB.
. Must provide efficient encoding and decoding of the addressing . Must provide efficient encoding and decoding of the addressing
info and the configured data. info and the configured data.
. Must provide efficient data transmission of the attribute state . Must provide efficient data transmission of the attribute state
over the wire (to minimize communication load on the CE-FE over the wire (to minimize communication load on the CE-FE
link). link).
7.6. LFB Attribute Manipulation 7.6. LFB Attribute Manipulation
This is a place-holder for all operations that the CE will use to The FE Model provides for the definition of LFB Classes. Each class
populate, manipulate, and delete attributes of the LFB instances on has a globally unique identifier. Elements within the class are
the FEs. These operations allow the CE to configure an individual assigned identifiers within that scope. This model also specifies
LFB instance. that instances of LFB Classes have identifiers. The combination of
class identifiers, instance identifiers, and element identifiers are
The same set of requirements as described in Section 9.5 for used by the protocol to reference the LFB information in the
attribute query applies here for attribute manipulation as well. protocol operations.
Support for various levels of feedback from the FE to the CE (e.g.,
request received, configuration completed), as well as multi-
attribute configuration transactions with atomic commit and
rollback, may be necessary in some circumstances.
(Editor's note: It remains an open issue as to whether or not other
methods are needed in addition to "get attribute" and "set
attribute" (such as multi-attribute transactions). If the answer to
that question is yes, it is not clear whether such methods should be
supported by the FE model itself or the ForCES protocol.)
7.7. LFB Topology Re-configuration 7.7. LFB Topology Re-configuration
Operations that will be needed to reconfigure LFB topology: Operations that will be needed to reconfigure LFB topology:
. Create a new instance of a given LFB class on a given FE. . Create a new instance of a given LFB class on a given FE.
. Connect a given output of LFB x to the given input of LFB y. . Connect a given output of LFB x to the given input of LFB y.
. Disconnect: remove a link between a given output of an LFB and . Disconnect: remove a link between a given output of an LFB and
a given input of another LFB. a given input of another LFB.
. Delete a given LFB (automatically removing all interconnects . Delete a given LFB (automatically removing all interconnects
to/from the LFB). to/from the LFB).
skipping to change at page 103, line 34 skipping to change at page 102, line 46
<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"> <LFBClassDef LFBClassID="-255">
<name>FrameLaserLFB</name> <name>FrameLaserLFB</name>
<synopsis>Fictional LFB for Demonstartions</synopsis> <synopsis>Fictional LFB for Demonstrations</synopsis>
<version>1.0</version> <version>1.0</version>
<inputPorts> <inputPorts>
<inputPort group="yes"> <inputPort group="yes">
<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>
skipping to change at page 108, line 4 skipping to change at page 107, line 15
<eventField>FrameRelayCircuits</eventField> <eventField>FrameRelayCircuits</eventField>
<eventSubscript>FrameCircuitIndex</eventSubscript> <eventSubscript>FrameCircuitIndex</eventSubscript>
<eventField>DLCI</eventField> <eventField>DLCI</eventField>
</eventReport> </eventReport>
</eventReports> </eventReports>
</event> </event>
</events> </events>
</LFBClassDef> </LFBClassDef>
</LFBClassDefs> </LFBClassDefs>
</LFBLibrary> </LFBLibrary>
8.1.Data Handling
8.1.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 Packets arriving without error from the physical interface come in
on a Frame Relay DLCI on a laser channel. These two values are used on 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 by 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
skipping to change at page 108, line 29 skipping to change at page 107, line 41
Good packets that arrive and are not LMI and have a frame relay type Good packets that arrive and are not LMI and have a frame relay type
indicator of IP are sent as IP packets on the port in the DatatoFE indicator of IP are sent as IP packets on the port in the DatatoFE
port group, using the same index field from the table based on the port group, using the same index field from the table based on the
laser channel and DLCI. The channel and DLCI are attached as meta- laser channel and DLCI. The channel and DLCI are attached as meta-
data for other use (classifiers, for example.) data for other use (classifiers, for example.)
The current definition does not specify what to do if the Frame The current definition does not specify what to do if the Frame
Relay type information is not IP. Relay type information is not IP.
Packets arriving on input ports arrive with the Lasesr Channel and Packets arriving on input ports arrive with the Laser Channel and
Frame Relay DLCI as meta-data. As such, a single input port could Frame Relay DLCI as meta-data. As such, a single input port could
have been used. With the structure that is defined (which parallels have been used. With the structure that is defined (which parallels
the output structure), the selection of channel and DLCI could be the output structure), the selection of channel and DLCI could be
restricted by the arriving input port group (LMI vs data) and port restricted by the arriving input port group (LMI vs. data) and port
index. As an alternative LFB design, the structures could require a index. As an alternative LFB design, the structures could require a
1-1 relationship between DLCI and LFB port, in which case no meta- 1-1 relationship between DLCI and LFB port, in which case no meta-
data would be needed. This would however be quite complex and data would be needed. This would however be quite complex and
noisy. The intermediate level of structure here allows parallelism noisy. The intermediate level of structure here allows parallelism
between input and output, without requiring excessive ports. between input and output, without requiring excessive ports.
8.1.1. Setting up a DLCI 8.1.2. Setting up a DLCI
When a CE chooses to establish a DLCI on a specific laser channel, When a CE chooses to establish a DLCI on a specific laser channel,
it sends a SET request directed to this LFB. The request might look it sends a SET request directed to this LFB. The request might look
like like
T = SET-OPERATION T = SET-OPERATION
T = PATH-DATA T = PATH-DATA
Path: flags = first-avail, length = 4, path = 2, channel, 4 Path: flags = first-avail, length = 4, path = 2, channel, 4
DataRaw: DLCI, Enable(1), false, out-idx DataRaw: DLCI, Enable(1), false, out-idx
Which would esbalish the DLCI as enabled, with traffic going to a Which would establish the DLCI as enabled, with traffic going to a
specific element of the output port group DatatoFE. (The CE would specific element of the output port group DatatoFE. (The CE would
ensure that output port is connected to the right place before ensure that output port is connected to the right place before
issuing this request. issuing this request.
The response to the operation would include the actual index The response to the operation would include the actual index
assigned to this Frame Relay circuit. This table is structured to assigned to this Frame Relay circuit. This table is structured to
use separate internal indices and DLCIs. An alternative design use separate internal indices and DLCIs. An alternative design
could have used the DLCI as index, trading off complexities. could have used the DLCI as index, trading off complexities.
One could also imagine that the FE has an LMI LFB. Such an LFB One could also imagine that the FE has an LMI LFB. Such an LFB
would be connected to the LMItoFE and LMIfromFE port groups. It would be connected to the LMItoFE and LMIfromFE port groups. It
would process LMI information. It might be the LFBs job to set up would process LMI information. It might be the LFBs job to set up
the frame relay circuits. The LMI LFB would have an alias entry the frame relay circuits. The LMI LFB would have an alias entry
that points to the Frame Relay circuits table it manages, so that it that points to the Frame Relay circuits table it manages, so that it
can manipulate those entities. can manipulate those entities.
8.1.2. Error Handling 8.1.3. Error Handling
The LFB will receive invalid packets over the wire. Many of these The LFB will receive invalid packets over the wire. Many of these
will simply result in incrementing counters. The LFB designer might will simply result in incrementing counters. The LFB designer might
also specify some error rate measures. This puts more work on the also specify some error rate measures. This puts more work on the
FE, but allows for more meaningful alarms. FE, but allows for more meaningful alarms.
There may be some error conditions that should cause parts of the There may be some error conditions that should cause parts of the
packet to be sent to the CE. The error itself is not something that packet to be sent to the CE. The error itself is not something that
can cause an event in the LFB. There are two ways this can be can cause an event in the LFB. There are two ways this can be
handled. handled.
skipping to change at page 111, line 43 skipping to change at page 111, line 7
T = SET-Properties T = SET-Properties
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 Setting the hysteresis to 2 suppress a lot of spurious
notifications. When the level first falls below 10, a notification notifications. When the level first falls below 10, a notification
is generated. If the power level increases to 10 or 11, and then is generated. If the power level increases to 10 or 11, and then
falls back below 10, an event will not be generated. The power has falls back below 10, an event will not be generated. The power has
to recover to at least 12 and fall back below 10 to generate another to recover to at least 12 and fall back below 10 to generate another
event. Once common cause of this form of osciallation is when the event. Once common cause of this form of oscillation is when the
actual value is right near the border. If it is really 9.5, tiny actual value is right near the border. If it is really 9.5, tiny
changes might flip it back and forth between 9 and 10. A variance changes might flip it back and forth between 9 and 10. A variance
level of 1 will suppress this sort of condition. Many other events level of 1 will suppress this sort of condition. Many other events
have osciallations that are somewhat wider, so larger variance have oscillations that are somewhat wider, so larger variance
settings can be used with those. settings can be used with those.
9. Acknowledgments 9. IANA Considerations
This model creates the need for unique class names and numeric class
identifiers. To meet that goal, IANA will maintain a registry of
LFB Class names, corresponding class identifiers, and the document
which defines the LFB Class. The registry policy is simply first
come first served with regard to LFB Class names. With regard to
LFB Class identifiers, identifiers less than 65536 are reserved for
assignment by RFCs. Identifiers above 65536 are available for
assignment on a first come, first served basis. Registry entries
must be documented in a stable, publicly available form.
The LFBLibrary element and all of its sub-elements are defined in
the following namespace:
http://ietf.org/forces/1.0/lfbmodel
[Editor’s Note: A registry template registry name, and other parts
required for a new IANA registry are still needed here.]
10. Authors Emeritus
The following are the authors who were instrumental in the creation
of earlier releases of this document.
Lily Yang, Intel Corp.
Ram Gopal, Nokia Research Center
Alan DeKok, Infoblox, Inc.
Zsolt Haraszti, Clovis Solutions
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.
10. 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 attributes in the FEs. The ForCES framework document [2] sets and attributes 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.
11. Normative References 13. Normative References
[1] Khosravi, H. et al., "Requirements for Separation of IP Control [1] Khosravi, H. et al., "Requirements for Separation of IP Control
and Forwarding", RFC 3654, November 2003. and Forwarding", RFC 3654, November 2003.
[2] Yang, L. et al., "Forwarding and Control Element Separation [2] Yang, L. et al., "Forwarding and Control Element Separation
(ForCES) Framework", RFC 3746, April 2004. (ForCES) Framework", RFC 3746, April 2004.
12. Informative References 14. Informative References
[3] Bernet, Y. et al., "An Informal Management Model for Diffserv [3] Bernet, Y. et al., "An Informal Management Model for Diffserv
Routers", RFC 3290, May 2002. Routers", RFC 3290, May 2002.
[4] Chan, K. et al., "Differentiated Services Quality of Service [4] Chan, K. et al., "Differentiated Services Quality of Service
Policy Information Base", RFC 3317, March 2003. Policy Information Base", RFC 3317, March 2003.
[5] Sahita, R. et al., "Framework Policy Information Base", RFC [5] Sahita, R. et al., "Framework Policy Information Base", RFC
3318, March 2003. 3318, March 2003.
skipping to change at page 113, line 11 skipping to change at page 113, line 8
[9] Quittek, J. et Al., "Requirements for IP Flow Information [9] Quittek, J. et Al., "Requirements for IP Flow Information
Export", RFC 3917, October 2004. Export", RFC 3917, October 2004.
[10] Duffield, N., "A Framework for Packet Selection and Reporting", [10] Duffield, N., "A Framework for Packet Selection and Reporting",
work in progress, January 2005, <draft-ietf-psamp-framework-10.txt>. work in progress, January 2005, <draft-ietf-psamp-framework-10.txt>.
[11] Pras, A. and Schoenwaelder, J., RFC 3444 "On the Difference [11] Pras, A. and Schoenwaelder, J., RFC 3444 "On the Difference
between Information Models and Data Models", January 2003. between Information Models and Data Models", January 2003.
13. Authors' Addresses [12] Hollenbeck, S. et al., "Guidelines for the Use of Extensible
Markup Language (XML) within IETF Protocols", RFC 3470, January
2003.
L. Lily Yang [13] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Intel Corp. Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001,
Mail Stop: JF3-206 <http://www.w3.org/TR/xmlschema-1/>.
2111 NE 25th Avenue
Hillsboro, OR 97124, USA
Phone: +1 503 264 8813
Email: lily.l.yang@intel.com
Joel M. Halpern [14] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes", W3C
Megisto Systems, Inc. REC-xmlschema-2, May 2001, <http://www.w3.org/TR/xmlschema-2/>.
20251 Century Blvd.
Germantown, MD 20874-1162, USA
Phone: +1 301 444-1783
Email: jhalpern@megisto.com
Ram Gopal [15] Davis, M. and M. Suignard, "UNICODE Security Considerations",
Nokia Research Center July 2005,<http://www.unicode.org/reports/tr36/tr36-3.html>.
5, Wayside Road,
Burlington, MA 01803, USA
Phone: +1 781 993 3685
Email: ram.gopal@nokia.com
Alan DeKok 15. Authors' Addresses
Infoblox, Inc.
475 Potrero Ave, Joel M. Halpern
Sunnyvale CA 94085 Self
Phone: P.O. Box 6049
Email: alan.dekok@infoblox.com Leesburg, VA 20178
Phone: +1 703 371 3043
Email: jmh@joelhalpern.com
Zsolt Haraszti
Clovis Solutions
1310 Redwood Way, Suite B
Petaluma, CA 94954
Phone: 707-796-7110
Email: zsolt@clovissolutions.com
Ellen Deleganes Ellen Deleganes
Intel Corp. Intel Corp.
Mail Stop: CO5-156 Mail Stop: CO5-156
15400 NW Greenbrier Parkway 15400 NW Greenbrier Parkway
Beaverton, OR 97006 Beaverton, OR 97006
Phone: +1 503 677-4996 Phone: +1 503 677-4996
Email: ellen.m.deleganes@intel.com Email: ellen.m.deleganes@intel.com
14. Intellectual Property Right 16. Intellectual Property Right
The authors are not aware of any intellectual property right issues The authors are not aware of any intellectual property right issues
pertaining to this document. pertaining to this document.
15. IANA consideration 17. Copyright Statement
A namespace is needed to uniquely identify the LFB type in the LFB
class library.
Frame type supported on input and output of LFB must also be
uniquely identified.
A set of metadata supported by the LFB model must also be uniquely
identified with names or IDs.
16. Copyright Statement
"Copyright (C) The Internet Society (2006). This document is "Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in BCP subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their 78, and except as set forth therein, the authors retain all their
rights." rights."
"This document and the information contained herein are provided on "This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
 End of changes. 110 change blocks. 
402 lines changed or deleted 375 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/