ForCES Working Group Z. Haraszti
Internet-Draft S. Blake
Expires: December 30, 2003 Ericsson
July 1, 2003
ForCES FE Functional Model Elements
draft-haraszti-forces-model-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 30, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This memo identifies requirements and issues associated with the
ForCES Forwarding Element Functional Model. It attempts to:
o Build on the concepts introduced in [MODEL].
o Serve as a collection/list of requirements for the FE functional
model
o State some open issues that must be resolved before the actual
formal model can be designed.
o Address some of the issues raised here and in [MODEL].
Haraszti & Blake Expires December 30, 2003 [Page 1]
Internet-Draft ForCES FE Functional Model Elements July 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. The ForCES Model in Relation to a Real Forwarding
Datapath Implementation . . . . . . . . . . . . . . . . . . 4
4. The ForCES Model in Relation to the ForCES Protocol . . . . 5
5. Open Issues and Working Assumptions . . . . . . . . . . . . 5
5.1 Data modeling language . . . . . . . . . . . . . . . . . . . 5
5.2 Level of Detail in LFB Class Operational Specifications . . 6
5.3 Detailed Packet Format Definitions . . . . . . . . . . . . . 7
5.4 Detailed Metadata Definitions . . . . . . . . . . . . . . . 7
5.5 Topological vs. Encoded State Representation . . . . . . . . 8
5.6 More than One LFB Input . . . . . . . . . . . . . . . . . . 8
5.7 More than One LFB Output in General LFBs . . . . . . . . . . 9
5.8 How to Define FE Topology Configuration Capabilities? . . . 9
5.9 How to Define LFB Topology Configuration Capabilities? . . . 9
5.10 Should LFBs Propagate Metadata? . . . . . . . . . . . . . . 10
5.11 Metadata Pass-Through . . . . . . . . . . . . . . . . . . . 11
5.12 Inheritance as a Means of Defining New LFB Classes . . . . . 11
5.13 Version Handling . . . . . . . . . . . . . . . . . . . . . . 12
6. The FE Functional Model Library . . . . . . . . . . . . . . 13
6.1 General Data Type Definitions . . . . . . . . . . . . . . . 14
6.2 Metadata Definitions . . . . . . . . . . . . . . . . . . . . 15
6.3 Frame Format Definitions . . . . . . . . . . . . . . . . . . 15
6.4 Logical Function Block (LFB) Class Definitions . . . . . . . 16
6.4.1 LFB Inheritance . . . . . . . . . . . . . . . . . . . . . . 16
6.4.2 LFB Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4.3 LFB Outputs . . . . . . . . . . . . . . . . . . . . . . . . 17
6.4.4 LFB Resources . . . . . . . . . . . . . . . . . . . . . . . 19
6.4.5 LFB Exceptions . . . . . . . . . . . . . . . . . . . . . . . 21
6.4.6 LFB Operational Specification . . . . . . . . . . . . . . . 22
7. The Post-Association Components of the FE Functional
Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.1 FE Topology and Configuration Capabilities . . . . . . . . . 23
7.2 FE Capability Declarations . . . . . . . . . . . . . . . . . 24
7.3 LFB Topology and Topology Configurability . . . . . . . . . 24
7.4 LFB Capability Declaration . . . . . . . . . . . . . . . . . 24
7.5 LFB Resource State (Query) . . . . . . . . . . . . . . . . . 25
7.6 LFB Resource Manipulation . . . . . . . . . . . . . . . . . 26
7.7 LFB Topology Re-configuration . . . . . . . . . . . . . . . 27
7.8 FE Topology Re-configuration . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . 27
References . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . 29
Haraszti & Blake Expires December 30, 2003 [Page 2]
Internet-Draft ForCES FE Functional Model Elements July 2003
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
1 Introduction
[FWK] specifies a framework by which control elements (CEs) can
configure and manage one or more separate forwarding elements (FEs)
within a networking element (NE) using a standardized protocol
(referred to as "the ForCES protocol"). [REQS] defines requirements
which must be satisfied by a ForCES FE functional model. [MODEL]
discusses the rationale for a FE functional model, along with some of
the issues associated with defining it.
To summarize, a FE functional model is necessary:
o To define logically separable and distinct packet forwarding
operations in a FE datapath (logical forwarding blocks or LFBs).
o To define the possible topological relationships (and hence the
sequence of packet forwarding operations) between the various
LFBs.
o To define the possible operational capabilities (e.g., resources,
granularity of configuration) of each type of LFB.
o To define the possible configurable parameters of each type of
LFB.
o To define metadata that may be exchanged between LFBs.
o To define the possible topological relationships between multiple
FEs within a NE.
o To define metadata that may be exchanged between LFBs on separate,
interconnected FEs (i.e., the Fi reference point [FWK]), along
with possible metadata encodings.
Definition of the various payloads of ForCES messages (irrespective
of the transport protocol ultimately selected) cannot proceed in a
systematic fashion until a formal definition of the objects being
configured and managed (the FE and the LFBs within) is undertaken.
This document attempts to summarize the open issues which must be
solved before undertaking the design of a formal FE functional model.
As there is overlap in intent between this document and [MODEL], we
have tried not to dwell on topics already covered in the other
Haraszti & Blake Expires December 30, 2003 [Page 3]
Internet-Draft ForCES FE Functional Model Elements July 2003
document. Further, this document offers possible answers to some of
the the open issues, and offers possible solutions to the stated
requirements.
2 Terminology
We have tried to adhere to the terminology introduced in existing
ForCES documents. Here we mention only terms that are new, or used
in a clarified way.
The term "FE topology" is not used consistently in previous ForCES
documents. In the rest of this memo we will use the following
terminology: "FE topology" refers to the graph where nodes are FEs
and edges represent datapath interconnects between FEs (this is
consistent with the term "inter-FE topology" in [FWK]). The CE must
learn the FE topology in addition to the LFB topology within each FE
in order to determine the overall capabilities of the NE.
"LFB" or "LFB instance" is a logical functional block performing a
well-defined forwarding operation, executed by the FE as part of the
datapath. The data plane is defined as a directed graph of LFBs,
where each LFB is an instance of a "LFB class". In [MODEL] LFB
instances are referred to as "FE stages".
"LFB Class" or "LFB Type" is a generic LFB template representing a
given type of packet forwarding operation. An LFB instance is
instantiated from one of the existing LFB classes. (This is similar
to the concept of a Class definition in OOP). LFB classes are also
referred to as "FE Components" (FECs) in [NETLINK2], while [MODEL]
uses the term "FE Blocks".
"LFB Topology" refers to the graph that describes all LFB instances
within a FE (this is consistent with the term "intra-FE topology" in
[FWK]). The nodes in the graph are the LFB instances, and edges are
the datapath segments interconnecting the LFB instances.
3 The ForCES Model in Relation to a Real Forwarding Datapath
Implementation
The FE function model assumed in [MODEL] and here is based on an
abstraction of distinct logical functional blocks, interconnected in
a directed graph, and receiving, processing, modifying, and
transmitting packets along with accumulated metadata. Note that a
real forwarding datapath implementation is not constrained to behave
in this way. For instance, the functions associated with LFBs may be
executed as nested sub-routines on a microprocessor or network
processor, with no packet data copying between the sub-routines, and
with the metadata values stored in common shared memory and/or
Haraszti & Blake Expires December 30, 2003 [Page 4]
Internet-Draft ForCES FE Functional Model Elements July 2003
registers. On the other hand, a FE implementation could consist of
two or more physical devices (or autonomous processors on an
integrated circuit) connected in series, which each handling a subset
of the LFB functions, and with inter-device metadata conveyed in
in-band packet preamble.
The LFB topology for a particular datapath implementation MUST
correctly capture the sequence of operations on the packet. Metadata
generation (by certain LFBs) must always precede any use of that
metadata (by subsequent LFBs in the topology graph); this is required
for logically consistent operation. Further, modifications of packet
fields that are subsequently used as inputs for further processing
must occur in the order specified in the model for that particular
implementation to ensure correctness.
4 The ForCES Model in Relation to the ForCES Protocol
The details of a particular datapath implementation, namely the FE
and LFB topology, along with the resource and operational
capabilities of each individual FE and LFB, must be conveyed to the
CE within information elements in the ForCES protocol. The
functional model of a LFB class should define all of the information
that would need to be exchanged between a FE and a CE for the proper
operation and management of that LFB.
We envision that the document defining the FE functional model schema
will include schemas for a LFB base class, and schemas for expressing
LFB and FE topology and capabilities. We also envision that the
individual LFB classes will be defined in separate documents. For
consistency, we believe that the ForCES protocol commands and
information elements (i.e., protocol TLVs) used to configure and
manage LFBs should be included in the same document as the LFB class
model.
5 Open Issues and Working Assumptions
Below is a list of major open issues that need to be resolved by the
working group before a model can be completed:
5.1 Data modeling language
[MODEL] mentions the following possible modeling languages: XML,
ASN.1, SMI, SPPI, and UML.
Working assumption: The rest of the document is written without
assuming a particular formal modeling language. The authors assume
that, at least for the post-association phase of the protocol, that
protocol commands and information elements will be explicitly defined
Haraszti & Blake Expires December 30, 2003 [Page 5]
Internet-Draft ForCES FE Functional Model Elements July 2003
in the "standard IETF way", as binary encoded data structures (the
pre-association phase encoding is not assumed to be
performance-sensitive). An alternative protocol encoding may also be
defined based on the standard on-the-wire representation of the
selected modeling language, where the protocol commands and
information elements are defined via that language.
5.2 Level of Detail in LFB Class Operational Specifications
LFB operation must be specified in the functional model to allow the
CE to understand the behavior of the forwarding datapath. For
instance, the CE must understand at what point in the datapath the
IPv4 header TTL is decremented (i.e., it needs to know if a control
packet could be delivered to the CE either before or after this point
in the datapath). Also, the CE must understand where and what type
of header modifications (e.g., tunnel header append/strip) are
performed by the FEs. Further, the CE must verify that the
forwarding functions performed by various FEs (e.g., an ingress and
egress FE) are compatible.
There is value to vendors if the operation of LFB classes can be
expressed in sufficient detail so that physical devices implementing
different LFB functions can be integrated easily into a FE design.
Working assumption: Semi-formal specification is needed; that is, a
text description of the LFB operation (human readable), but
sufficiently specific and unambiguous to allow conformance testing
and efficient design (i.e., eliminate guess-work), so that
interoperability between different CEs and FEs can be achieved. The
LFB class model MUST specify:
o metadata read/consumed
o metadata produced
o packet encapsulation modifications
o packet content modifications
o packet routing criteria (when multiple outputs on a LFB are
present)
o packet timing modifications
o packet flow ordering modifications
Haraszti & Blake Expires December 30, 2003 [Page 6]
Internet-Draft ForCES FE Functional Model Elements July 2003
5.3 Detailed Packet Format Definitions
When LFB classes are defined, the input and output packet formats
(e.g., IPv4, IPv6, Ethernet, etc.) must be specified (these are the
types of packets a given LFB input is capable of receiving and
processing, or a given LFB output is capable of producing). This
type of definition requires that distinct frame types be uniquely
labeled with a symbolic name and/or ID.
In addition, if the operational specification is to be a precise
definition of how the LFB modifies packets, then it may be necessary
to refer to the various fields within packets, as well as to specific
values of these fields. For example, assume that the following text
will be part of the operational specification section of an IPv4 LFB
class definition:
"If (FRAME_IPV4[FIELD_IPV4_IHL] != FIELD_IPV4_IHL_STD),
then the IPv4 frame is emitted via output SPECIAL_CASE. All
metadata that were received with the frame are also emitted."
This approach allows a rather formal specification of the operations
of a LFB, but requires that frame formats be specified in great
detail. A set of symbolic references to frame types, their fields,
and field values must be defined in order to formalize the
operational specification.
Working assumption: Needed.
Note that some LFB instances may have to be capable of processing
packets with encoded, in-band metadata; specifically, those LFBs
which receive the input of a physical device (such as the first LFB
in the datapath of a FE performing egress functions and receiving
packets across the Fi interface, or LFBs on one of two or more
physical devices within a FE). This issue is discussed in the next
section.
5.4 Detailed Metadata Definitions
Metadata is used to communicate per-packet state from one LFB to
another. To ensure inter-operability among LFBs, the LFB class
specification must define what metadata the LFB class "reads" or
"consumes" on its input(s) and what metadata it "produces" on its
output(s). For that purpose, metadata types must be identified. For
example, an META_IFID, passed from a port LFB to an IPv4 processing
LFB (with the IP packet) can be one of the defined metadata types.
Symbolic names can be assigned for common metadata types.
Working assumption: Symbolic names should be defined for each
Haraszti & Blake Expires December 30, 2003 [Page 7]
Internet-Draft ForCES FE Functional Model Elements July 2003
metadata type. In addition, additional information such as numeric
data type, maximum and minimum accepted values, and special values
(see Section 6.2 for more information) should be defined for each
metadata value. Some of these constraints will be defined in the LFB
class model, and some of them may be specific capabilities of a
particular LFB instance.
As mentioned previously, it may be necessary to encode metadata in
in-band headers when transmitting packets between physical devices. A
standardized metadata encoding protocol should be defined.
5.5 Topological vs. Encoded State Representation
The concept of topological versus encoded state representation is
introduced in Section 4.2.1 in [MODEL]. Will the model be limited to
one or the other, or both will be allowed? In case both are allowed,
which approach will be preferred?
Working assumption: Both will be allowed, but designers of LFB
classes must use the topological approach in a limited fashion. The
topological approach should only be used when the packet datapath
forks into areas with distinct LFBs (not just distinct
parameterizations of the same LFB classes).
In addition, a general design guideline should be to use the
topological approach only for fan-outs that do not require changes
(adding/removing LFB outputs) at all or require only very infrequent
changes. Configuration information that needs to change frequently
should not be encoded using the LFB topology, but rather should be
expressed by the internal resources of one or more LFBs.
Note that LFB-internal resources can be designed in any way,
including objects that are linked to each other to form graphs.
5.6 More than One LFB Input
Should LFB classes be allowed to have more than one input "port"?
Working assumption: It is inevitable that there will be LFB instances
that will receive packets from more than one other LFB instances
(fan-in). If these fan-in links all carry the same type of
information (packet type and set of metadata) and require the same
processing within the LFB, then one input should be sufficient. Note
that we assume that the model allows for connecting more than one LFB
output to a single LFB input.
If, however, the LFB class can receive two or more very different
types of input, and the processing of these inputs are also very
Haraszti & Blake Expires December 30, 2003 [Page 8]
Internet-Draft ForCES FE Functional Model Elements July 2003
distinct, then that may justify the definition of multiple inputs.
But in these cases splitting the LFB class into two LFB classes
should always be considered as an alternative.
In intermediate cases, e.g., where the inputs are somewhat different
but they require very similar processing, the shared input solution
should be preferred. For example, if an Ethernet framer LFB is
capable of receiving IPv4 and IPv6 packets, these can be served by
the same LFB input.
5.7 More than One LFB Output in General LFBs
Should LFB classes be allowed to have more than one output?
Working assumption: We assume that a single LFB output can be
connected to only one LFB input (this is required to make the packet
flow through the LFB topology unambiguous). Therefore, to allow any
non-trivial topology, a LFB class must be able to have more than one
output. However, using multiple outputs for topological encoding
should be avoided (see discussion in Section 5.5).
5.8 How to Define FE Topology Configuration Capabilities?
Will the FE topology (interconnection of FEs) ever be configurable by
the CE(s)? Shall the connection between two FEs that are otherwise
capable of communicating (i.e., interconnected in the hardware) be
configurable by the CEs such that the CEs may be able to disable or
enable such links?
Working assumption: We assume that FEs cannot be created or deleted
by the CEs (hence the nodes of the FE topology graph are "read-only"
information to the CEs). We also assume that the interconnections
between FEs are limited by the NE hardware implementation, in the
sense that if the hardware does not allow sending packets from FE[i]
to FE[j], then these FEs will never be interconnected in the FE
topology. The usefulness of allowing the CE to enable and disable FE
interconnections supported by the NE hardware requires further
research.
In case FE topology configurations are to be supported (in the above
sense), a model is needed to define data that can represent the
actual interconnection capabilities of the FEs to the CEs.
5.9 How to Define LFB Topology Configuration Capabilities?
[REQS] states that the ForCES protocol must allow configurable LFB
topologies; that is, the CE(s) should be capable of creating/deleting
LFBs and setting up/deleting interconnections between LFBs within an
Haraszti & Blake Expires December 30, 2003 [Page 9]
Internet-Draft ForCES FE Functional Model Elements July 2003
FE. Even if a FE supports configurable LFB topologies, it is
expected that there will be FE-specific limitations on what can
actually be configured. Performance-optimized network processors may
have zero or very limited configurability, while FE implementations
running on generic purpose processors may provide a great level of
configurability. In either case, the CE(s) must be able to learn the
FE's configuration capabilities.
Working assumption: The functional model must provide mechanisms for
describing the LFB topology configuration capabilities of a FE.
These capabilities may include:
o What LFB classes can the FE instantiate?
o How many instances of the same LFB class can be created?
o What are the topological limitations? For example:
* How many instances of the same class or any class can be
created on any given branch of the graph?
* Ordering restrictions on LFBs (e.g., any instance of LFB class
A must be always downstream of any instance of LFB class B).
o Other limitations
5.10 Should LFBs Propagate Metadata?
A given LFB may require a certain metadata at its input for its
internal processing. What should happen with the metadata after it
is read by the LFB? In particular, should the metadata be propagated
along with the packet when the packet is forwarded from the LFB to
the next LFB, or should it be removed (consumed) by the LFB?
In certain cases passing the metadata along is desirable. For
example, a META_CLASSID metadata may denote the result of a
classification LFB and used in more than one downstream LFBs to
trigger the proper operation on the packet. In this case the first
LFB that uses the META_CLASSID should also allow the META_CLASSID to
be passed with the packet to the next LFB, and so on.
On the other hand, it is easy to see that if metadata is never
consumed by LFBs, then as the packet trickles through the datapath, a
large number of metadata will potentially be accumulated by the
packet. This does not seem to be a sustainable solution, either in
implementations where metadata is stored in registers or shared
memory, or implementations where metadata is encoded in-band with the
Haraszti & Blake Expires December 30, 2003 [Page 10]
Internet-Draft ForCES FE Functional Model Elements July 2003
packet as it propagates through the datapath.
Working assumption: For each element of metadata utilized by a LFB
class, the propagation mode MUST be specified. Metadata elements
which are not propagated are specified with the CONSUME mode, while
elements which are propagated are specified with the LOOK_AT mode.
However, whether a metadata is useful beyond a LFB may depend on the
actual LFB topology, i.e., what other LFBs are placed downstream. So
it seems more appropriate that the removal of metadata is somehow
configurable.
5.11 Metadata Pass-Through
A packet may arrive to a LFB with metadata that is not meaningful to
that LFB, but may be important to some other downstream LFBs.
Working assumption: To cater for such cases it should be the assumed
(default) behavior of all LFB classes that they transparently forward
any (and all) metadata elements that they do not utilize internally.
Actual implementations of LFBs in hardware may have limitations on
how much metadata they can pass through. The limitation may be
expressed in terms of total framesize (packet + metadata), metadata
total size, number of metadata elements, or a combination of each of
these. Also, the limitation may be on the FE level or may be
specific to LFBs within a FE. The pass- through capabilities of LFB
instances and FEs should be detectable as part of the capability
discovery process.
5.12 Inheritance as a Means of Defining New LFB Classes
Deriving a new LFB class from another existing LFB class may prove to
be an efficient way of evolving LFBs. This approach can also allow
FE vendors to add vendor-specific extensions to standardized LFBs.
Working assumption: LFB class inheritance will be supported. An LFB
class specification MUST specify the base class it inherits from
(with the default being the base LFB class). Support for multiple
inheritance requires further investigation.
An interesting issue related to class inheritance is backward
compatibility (between an descendant and an ancestor class). To
illustrate the problem, consider the following hypothetical scenario:
There exists a standardized LFB class "L1". Vendor A builds a FE
that implements LFB "L1" and vendors B and C both build CEs that can
recognize and operate on LFB "L1". In this case vendor B's and C's CE
both are interoperable with vendor A's FE. Suppose that a new LFB
Haraszti & Blake Expires December 30, 2003 [Page 11]
Internet-Draft ForCES FE Functional Model Elements July 2003
class, "L2", is defined based on the existing "L1" class (for
example, extending its capabilities in some incremental way).
Suppose, furthermore, that vendors A and B upgrade their FE and CE,
respectively, to support the new LFB class, but vendor C's CE is not
changed. Obviously, vendor A and B are interoperable, but will
vendor C's CE work with the new FE? No, unless some special
mechanisms are put in place to support backward compatibility.
A much less problematic case is the reverse scenario, i.e., when a CE
vendor upgrades to the new LFB class, but the FE is not upgraded.
Note that as long as the CE is capable of working with older LFB
classes, this problem does not influence the modeling requirements,
hence we will use the term "backward compatibility" to refer to the
first scenario.
Inheritance can be designed into the model with or without supporting
backward compatibility. Without backward compatibility, the derived
LFB class MUST simply refer to the base class (immediate parent node
in the inheritance tree). In addition, the model must provide a
clean and efficient way to define the changes, i.e., the differences
between the base class and the derived class.
The issue becomes more complex if backward compatibility is a desired
feature. In that case the following mechanisms are required:
1. When detecting a LFB instance of a LFB type that is unknown to
the CE, the CE MUST be able to query the base class of such a
LFB.
2. The LFB instance SHOULD support a backward compatibility mode,
and the CE SHOULD be able to configure the LFB to run in such
mode.
In case of multiple inheritance (e.g., LFB class "L3" is derived from
"L2", and "L2" is derived from "L1"), to support backward
compatibility across non-adjacent generations, the derived LFB
instance must support multiple backward compatibility modes, and the
CE should be able to query the base classes in an iterative way.
5.13 Version Handling
Similarly to LFB class inheritance, LFB class versioning is a
potential method to enable incremental evolution of LFB classes.
Unlike inheritance, where it assumed that a FE datapath model
containing a LFB instance of a particular class "C" could also
simultaneously contain a LFB instance of a class "C'" inherited from
"C", with versioning, a FE would not be allowed to contain a LFB
instance for more than one version of a particular class.
Haraszti & Blake Expires December 30, 2003 [Page 12]
Internet-Draft ForCES FE Functional Model Elements July 2003
Working assumption: LFB class versioning will be supported, for
example by requiring a version string in the class definition. CEs
may support backwards compatibility between multiple versions of a
particular LFB class, but FEs are not allowed to support more than a
single version of a particular class.
6 The FE Functional Model Library
A main goal of the FE functional model is to provide an abstract,
generic, modular, implementation independent representation of the
forwarding plane (FEs). This is facilitated using the concept of LFBs
which are instantiated from LFB classes. The LFB classes will be
defined in a model library which is the subject of this section.
The core part of the model library is the definition of LFB classes.
Section 6.4 provides more discussion on what will be part of a LFB
class definition.
Operational parameters of the LFBs that must be visible to the CEs
are conceptualized in the model as the "resources" of the LFB. These
will include, for example, flags, single parameter arguments, complex
arguments, and tables. The definition of the resources of a LFB MUST
be part of the LFB class definition. To promote consistent and terse
definitions of the resources of LFB classes, commonly used resource
types SHOULD BE defined in the model library outside of the LFB class
definitions, so that LFB class definitions can "share" these type
definitions by simply referring to the types. What will comprise a
data type definition is further discussed in Section 6.1.
In the model LFBs form a directed graph and communicate with each
other by sending and receiving packets and associated metadata. To
provide consistency and logical inter-operability among LFB classes,
packet types (generic frame types) and metadata types MUST BE
specified outside of the LFB class definitions (but part of the model
library), so that the LFB class definitions can simply refer to these
types. These blocks are further discussed in Section 6.3 and Section
6.2, respectively.
In summary, the FE functional model library will consist of the
following four building blocks:
1. Common data type definitions
2. Frame format definitions
3. Metadata definitions
4. LFB class definitions
Haraszti & Blake Expires December 30, 2003 [Page 13]
Internet-Draft ForCES FE Functional Model Elements July 2003
It is not expected that the above information is exchanged between
FEs and CEs "over-the-wire". But the model library will serve an
important reference for the design and development of the CEs
(software) and FEs (mostly the software part). These definitions will
most likely be provided in internet drafts or RFCs.
To serve the above purpose, it would not be absolutely required that
the model library itself is defined using some formal description
language (since software encoding will be done by humans).
Nevertheless, using a formal language can help in enforcing
consistency and logical compatibility among LFBs. In addition, formal
definition of the LFB classes has the potential to facilitate:
o The eventual automation of some part of the code generation
process.
o The functional validation of arbitrary LFB topologies.
When selecting the formal language, it should be considered that the
model library MUST be human readable. There are no real-time
requirements (encoding, decoding, transmission) on the language,
however. The authors of this memo view XML as a very good candidate
for the model library language.
6.1 General Data Type Definitions
Data types will be used to describe the resources of LFBs (see
Section 6.4.4). This is similar to the concept of having a common
header file for shared data types. Data types will include atomic
data types (e.g. integer, ASCII string), as well as compound/derived
data types (such as arrays, sets, structures, etc.).
Compound data types can build on atomic data types and other compound
data types.
For each data type the following information MUST be provided:
o Symbolic name of data type. Example: "T_IPV4ADDRESS".
o Actual type declaration.
In addition, a data type definition MAY include the following:
o Range restrictions.
o A set of symbolic abbreviations for special values. Example:
"IPV4ADDR_LOOPBACK".
Haraszti & Blake Expires December 30, 2003 [Page 14]
Internet-Draft ForCES FE Functional Model Elements July 2003
6.2 Metadata Definitions
This block of the model library will list metadata type definitions.
For each metadata type, the following MUST be specified:
o Metadata symbolic name. Used to refer to the metadata type in LFB
type specifications. Example: META_CLASSID.
o Metadata type ID. This is a numeric type code that can be used to
encode metadata type when passed between LFBs.
o Brief synopsis of the metadata. Example: "Result of classification
(0 means no match)".
o Data type and valid range.
In addition, the following information MAY BE part of the metadata
definition:
o Symbolic definitions for frequently used or special values of the
metadata.
6.3 Frame Format Definitions
This block of the model library will list packet types (frame types
in general) that LFB classes can receive at their inputs and/or emit
at their outputs.
For each distinct frame type, the following MUST be provided:
o Symbolic name of frame type. Example: FRAME_IPV4.
o Frame type ID. This is a numeric code that should be used to refer
to the frame format in encapsulation frames used between FEs. This
ID could potentially reuse the payload/protocol type codes used in
other Internet protocols.
o Brief synopsis of the frame type. Example: "IPv4 packet".
In addition, the following information MAY BE part of the frame type
definition to facilitate formal operational descriptions of LFB
classes:
o Symbolic names for frequently referred header fields.
o Field position and size information.
Haraszti & Blake Expires December 30, 2003 [Page 15]
Internet-Draft ForCES FE Functional Model Elements July 2003
o Symbolic names for special or frequently referred values of
fields.
6.4 Logical Function Block (LFB) Class Definitions
Each LFB Class definition must provide the following information:
o Symbolic name of LFB class. Example: "LFB_IPV4_LPM"
o Numeric ID of LFB class. Example: "12"
o Short synopsis of LFB class. Example: "IPv4 LPM Lookup LFB"
o Version indicator
o Inheritance indicator (see discussion in Section 6.4.1)
o Inputs (see discussion in Section 6.4.2)
o Outputs (see discussion in Section 6.4.3)
o Resources (see discussion in Section 6.4.4)
o Exceptions (see discussion in Section 6.4.5)
o Operational specification (see discussion in Section 6.4.6)
6.4.1 LFB Inheritance
Deriving a new LFB class from another existing LFB class may prove to
be an efficient way of evolving LFBs. This approach can, for
example, allow a FE vendor to add vendor-specific extensions to
standardized LFBs. To support LFB class inheritance, the LFB
specification must have a place holder for indicating the base
class(es).
In addition to the reference of the base class, the model should
support an efficient way of describing the relative differences of
the derived class from the base class. This issue requires further
study.
6.4.2 LFB Inputs
An LFB input is a conceptual port of the LFB where the LFB can
receive "information" from other LFBs. The information is typically a
packet (or frame in general) and associated metadata, but some
Haraszti & Blake Expires December 30, 2003 [Page 16]
Internet-Draft ForCES FE Functional Model Elements July 2003
special inputs may be able to receive only metadata, i.e., with a
Null-packet.
An LFB class may have zero, one, or more inputs. We assume that most
LFBs will have exactly one input, but there should be no restrictions
on the number of up-stream LFBs connecting their outputs to the same
input of a LFB.
More than one input should be avoided if possible (see discussion in
Section 5.6).
Some special LFBs will have no inputs at all. For example, a packet
generator LFB does not need an input.
The number of inputs is fixed for a LFB class; that is, it is not
configurable (as opposed to the number of outputs); see Section
6.4.3.
The LFB Class definition MUST specify the number of inputs of the
LFB. For each LFB input, the following MUST be specified:
o Symbolic name of input. Example: "PKT_IN". Note that this
symbolic name must be unique only within the scope of the LFB
class.
o Brief synopsis of the input. Example: "Normal packet input".
o List of allowed frame formats. Example: "{FRAME_IPV4, FRAME_IPV6}"
Note that this list should refer to symbols specified in the frame
definition of the model library (see Section 6.3). In addition to
the list of frame types, additional information MAY BE provided on
what fields of the frames the LFB may read and/or modify.
o List of required metadata. Example: {META_CLASSID, META_IFID}.
This list should refer to symbols specified in the metadata
definition of the model library (see Section 6.2). For each
metadata it should be specified whether the metadata is required
or optional. For each optional metadata a default value MAY BE
specified, which is used by the LFB if the metadata is not
provided at the input.
6.4.3 LFB Outputs
An LFB output is a conceptual port of the LFB where it can send
"information" to some other LFBs. The information is typically a
packet (or frame in general) and associated metadata, but some
special outputs may emit only metadata, i.e., with a Null-packet.
Haraszti & Blake Expires December 30, 2003 [Page 17]
Internet-Draft ForCES FE Functional Model Elements July 2003
An LFB class may have zero, one, or more outputs. Multiple outputs
should mainly be used for functional separation, that is when the
outputs are connected to very different types of LFBs. For example,
an IPv4 LPM LFB may have one "default" output to send those packets
for which look-up was successful (passing a META_ROUTEID as
metadata); and have another output for sending packets for which the
look-up failed. The former output may be connected to a route
handler LFB, while the latter can be connected to an ICMP response
generator LFB or to a packet handler LFB that passes the packet up to
the CE.
The use of multiple outputs for topological encoding should be
avoided. In case topological encoding is used, we model this as if
the same output type is instantiated more than once. Multiple
instances of the same output type are referred to as an "output
group".
Some special LFBs may have no outputs at all (e.g., Dropper).
The LFB Class definition MUST specify the number of outputs (or
output types) of the LFB. In case topological encoding is used, the
output group should count as one entry in the output specification,
but the entry should indicate that instantiation of the output is
allowed. For illustration, consider the following hypothetical LFB.
+------------------+
| UNPROC +-->
| |
| PKTOUT_1 +--> \
--> PKTIN PKTOUT_2 +--> |
| . + . | Output group
| . + . |
| PKTOUT_N +--> /
+------------------+
Example LFB
The LFB above has two types of outputs, one of which can be
instantiated to form an output group.
For each LFB output (group) the following MUST be specified:
o Symbolic name of the output. Example: "UNPROC". In case of an
output group, the symbolic name is the prefix used to construct
unique symbols for each output instance. Example: "PKTOUT_". Note
that the symbolic name must be unique only within the scope of the
LFB class.
Haraszti & Blake Expires December 30, 2003 [Page 18]
Internet-Draft ForCES FE Functional Model Elements July 2003
o Brief synopsis of the output. Example: "Normal packet output".
o Indication of whether this output is an output group (i.e., if it
is allowed to be instantiated).
o List of allowed frame formats. Example: "{FRAME_IPV4, FRAME_IPV6}"
Note that this list should refer to symbols specified in the frame
definition of the model library (see Section 6.3). In addition to
the list of frame types, additional information MAY BE provided on
what fields of the frames the LFB may have modified.
o List of emitted (generated) metadata. Example: {META_CLASSID,
META_IFID}. This list should refer to symbols specified in the
metadata definition of the model library (see Section 6.2). For
each generated metadata it should be specified whether the
metadata is always generated or generated only in certain
conditions. This information is important when assessing
compatibility between LFBs.
6.4.4 LFB Resources
The operational state of the LFB is modeled by the variables of the
LFB, collectively called resources.
Resource types will include the following four categories:
1. Capability resources (see Section 7.4 for more on LFB
capabilities). Examples:
* Supported optional features of the LFB class
* Maximum number of configurable outputs for an output group
* Metadata pass-through limitations of the LFB
* Maximum size of configurable resource tables
* Supported access modes of certain resources (see below)
2. Configured operational resources. Examples:
* Configurable flags and switches selecting between operational
modes of the LFB
* Lookup tables
* Number of outputs in an output group
Haraszti & Blake Expires December 30, 2003 [Page 19]
Internet-Draft ForCES FE Functional Model Elements July 2003
* Metadata CONSUME vs. LOOK_AT mode selector
3. Statistical resources (collected by the FE, provided for reading
to the CE). Examples:
* Packet and byte counters
* Other event counters
4. Internally maintained state. Examples:
* Internal state of a protocol machine
* Content of a protocol table (such as content of an ARP table
maintained by the ARP protocol LFB).
Some of the resources will be generically available in all LFBs while
others will be specific to the LFB class. Examples of generic LFB
resources are:
o LFB enable/disable/by-pass switch
o LFB class ID (in case the LFB is self-descriptive)
o LFB class inheritance information (see Section 5.12)
o Number and type of inputs (in case the LFB is self-descriptive)
o Number and type of outputs (in case the LFB is self-descriptive)
o Number of current outputs for each output group
o Metadata CONSUME/LOOK_AT mode selector
There may be various restrictions on what the CE can do with an LFB
resource (access permission). The following categories may be
supported:
o Read-only resources
o Read-write resources
o Write-only resources. This could be any configurable data for
which reading capability is not provided to the CEs.
o Read-reset resources. The CE can read and reset this resource, but
cannot set it to an arbitrary value. Example: Counters.
Haraszti & Blake Expires December 30, 2003 [Page 20]
Internet-Draft ForCES FE Functional Model Elements July 2003
o Firing-only resource. A write attempt to this resource will
trigger some specific actions in the LFB, but the actual value
written is ignored.
The LFB class may define more than one possible mode for a given
resource (for example, write-only and read-write), in which case it
is left to the actual implementation to pick one of the modes. In
this case a corresponding capability parameter must inform the CE of
which mode the actual LFB instance supports.
The resources of the LFB class must be defined as a list. For each
resource the following information MUST be provided:
o Reference to the data type (e.g., specified in the generic data
type block of the model library or in an LFB specific data type
block).
o Access right (or rights in case more than one mode is allowed).
o Additional range restrictions (i.e., beyond what is specified by
the data type definition).
o Default value. Applied when the LFB is initialized or reset.
The actual structuring of LFB resources requires further study.
6.4.5 LFB Exceptions
"Throwing an exception" refers to a FE sending an asynchronous ForCES
protocol message to the CE(s) upon encountering a special condition.
The message payload may or may not contain the packet that was being
processed when the condition was encountered.
An LFB class specification MUST define what types of exceptions the
LFB is capable of throwing. Hence this information should be part of
the model.
Some exception types may be optional. The CE should be able to detect
(query) what exception types from the LFB class list are actually
supported by the LFB instance on a given FE. This information MAY BE
encoded as a special type of capability parameter (see Section 7.4
more on LFB capabilities) or MAY BE embedded in the generic ForCES
protocol.
The CE must be able to selectively subscribe to an arbitrary subset
of the exceptions supported by the LFB instance. The selection may be
controlled by setting/clearing some flags regarded as special
resources of the LFB, or this feature may be embedded in the generic
Haraszti & Blake Expires December 30, 2003 [Page 21]
Internet-Draft ForCES FE Functional Model Elements July 2003
ForCES protocol.
6.4.6 LFB Operational Specification
This section of the model should verbally describe what the LFB does.
This will most likely be embedded in an (unstructured) text field in
the model.
7 The Post-Association Components of the FE Functional Model
The actual model of the forwarding plane in a given NE is something
the CE must learn and control via communicating with the FEs. Most of
this communication will happen in the post-association phase using
the ForCES protocol. The following types of information must be
exchanged between CEs and FEs:
1. FE topology and configuration capabilities
2. FE capability declaration
3. LFB topology (per FE) and configuration capabilities
4. LFB capability declaration
5. LFB resource state
6. LFB resource manipulation
7. LFB topology reconfiguration
8. FE topology reconfiguration
Items 1 through 5 are query exchanges, the main flow of information
being from the FEs to the CEs. Items 1 through 4 are typically
queried by the CE(s) in the beginning of the post-association (PA)
phase, though they may be repeatedly queried at any time in the PA
phase. Item 5 (state query) will be used at the beginning of the PA
phase, and often frequently during the PA phase (especially for the
query of statistical counters).
Items 6, 7, and 8 are "command" type of exchanges, the main flow of
information being from the CEs to the FEs. From these three, only 6
(the LFB re-configuration commands) are expected to be used
frequently.
LFB topology re-configuration is needed only if dynamic LFB
topologies are supported by ForCES, and it is expected to be used
Haraszti & Blake Expires December 30, 2003 [Page 22]
Internet-Draft ForCES FE Functional Model Elements July 2003
infrequently.
FE topology re-configuration is needed only if dynamic FE topologies
are supported by ForCES, and it will be a very infrequent operation.
The relationship between the model library and the eight
post-association messages are visualized in the following figure:
+--------+
..........-->| CE |
/----\ . +--------+
\____/ Model library . ^ |
| |................ 1, 2 | | 6, 7, 8
| | (off-line) . 3, 4, 5 | |
\____/ . | v
. +--------+
e.g. RFCs ..........-->| FE |
+--------+
The actual encoding of these messages is beyond the scope of the
model. Their discussion is nevertheless important here for the
following reasons:
o These PA model components have considerable impact on the model
library. For example, some of the above information can be
represented as resources of the LFBs, in which case such resources
must be defined in the library.
o The understanding of the type of information that must be
exchanged between the FEs and CEs can help to select the
appropriate protocol format (such as XML, TLVs, or SNMP?) and the
actual encoding.
o Understanding the frequency of these types of messages should
influence the selection of the protocol format (efficiency
considerations).
The remaining sub-sections of this section address each of the above
components.
7.1 FE Topology and Configuration Capabilities
The "nodes" of the FE topology will be discovered by the CEs in the
pre-association phase, but the actual reachability information
("edges") will most likely come during the PA phase. Since this
information is not LFB specific, this exchange can be made part of
the ForCES base protocol. Alternatively, a generic set of ForCES
payload commands can be defined for this purpose.
Haraszti & Blake Expires December 30, 2003 [Page 23]
Internet-Draft ForCES FE Functional Model Elements July 2003
In case support for configurable FE interconnects is a desirable
feature, a proper model must be found to describe the grade of
configurability (i.e., the reachability of one FE from another FE).
This issue is currently considered an open issue (and was discussed
in Section 5.8).
7.2 FE Capability Declarations
FEs will have many types of limitations. Some of the limitations must
be expressed to the CEs as part of the model. The CEs must be able to
query these capabilities on a per-FE basis. Examples:
o Metadata passing capabilities of the FE. Understanding such
capabilities will help the CE to evaluate the feasibility of LFB
topologies, and hence to determine the availability of certain
services.
o Global resource query limitations (applicable to all LFBs of the
FE).
o Any other "global" limitations.
7.3 LFB Topology and Topology Configurability
The ForCES protocol must provide the means for the CEs to discover
the current set of LFB instances in a FE and the interconnections
between the LFBs within the FE.
In addition, there should be sufficient information provided on
whether the FE supports any CE-initiated (dynamic) changes to the LFB
topology, and if so, what are the allowed topologies. This issue has
been discussed already in Section 5.9 as an open issue.
7.4 LFB Capability Declaration
LFB class specification will define a generic set of capabilities.
When a LFB instance is implemented (instantiated) on a vendor's FE,
some additional limitations may be introduced. Note that we discuss
here only limitations that are within the flexibility of the LFB
class specification, that is, the LFB instance will remain compliant
with the LFB class specification despite these limitations.
For example, certain features of a LFB class may be optional, in
which case it must be possible for the CE to determine if an optional
feature is supported by a given LFB instance or not.
Also, the LFB classes definitions will probably contain very few
Haraszti & Blake Expires December 30, 2003 [Page 24]
Internet-Draft ForCES FE Functional Model Elements July 2003
quantitative limits (e.g., size of tables), since these limits are
typically imposed by the implementation. Therefore, quantitative
limitations should always be expressed by capability arguments.
To facilitate the flexibility of LFB instances to impose limitations
on the generic LFB class model, the LFB class specifications must
have a set of capability arguments, and the CE must be able to query
the actual capabilities of the LFB via querying the value of such
arguments. The capability query will typically happen when the LFB is
first detected by the CE. Capabilities need not be re-queried in case
of static limitations. In some cases, however, some capabilities may
change in time (e.g., as a result of adding/removing other LFBs, or
configuring certain resources of some other LFB when the LFBs share
physical resources), in which case additional mechanisms must be
implemented to inform the CE about the changes.
The following two broad types of limitations will exist:
o Qualitative restrictions. For example, a standardized multi-field
classifier LFB class may define a large number of classification
fields, but a given FE may support only a subset of those fields.
o Quantitative restrictions, such as the maximum size of tables,
etc.
The capability parameters that can be queried on a given LFB class
will be part of the LFB specification. The capability parameters
should be regarded as special resources of the LFB. The actual values
of these arguments may be, therefore, obtained using the same
resource query mechanisms as used for other LFB resources.
Capability resources will typically be read-only arguments, but in
certain cases they may be configurable. For example, the size of a
lookup table may be limited by the hardware (read-only), in other
cases it may be configurable (read-write, within some hard limits).
Assuming that capabilities will not change frequently, the efficiency
of the protocol/schema/encoding is of secondary concern.
7.5 LFB Resource State (Query)
Note that this feature may not be provided by all FEs (or all LFBs of
a FE). Some of the possible levels of support are:
o FE and/or LFB cannot serve any query request
o FE and/or LFB can only serve query requests for statistical
information
Haraszti & Blake Expires December 30, 2003 [Page 25]
Internet-Draft ForCES FE Functional Model Elements July 2003
o FE and/or LFB is capable to serve query requests for a restricted
set of resources
o FE and/or LFB can serve query requests for any resources
configured
The query capabilities of the FE and the LFB must be expressed in the
FE capability and LFB capability sections of the model, respectively.
The ForCES protocol and the data schema/encoding conveyed by the
protocol must together satisfy the following requirements:
o FE selection. This is primarily to refer to a single FE, but
referring to a group or all FEs may optional be supported.
o LFB instance selection. This is primarily to refer to a single LFB
instance of an FE, but optionally addressing of a group of LFBs
may be supported.
o Addressing individual resource components of the LFB
o Efficient encoding and decoding of the addressing info and the
configured data.
o Efficient data transmission of the resource state over the wire
(to minimize communication load on the CE-FE link).
7.6 LFB Resource Manipulation
This is a place-holder for all operations that the CE will use to
populate, manipulate, and delete resources of the LFB instances on
the FEs.
The ForCES protocol and the data schema/encoding conveyed by the
protocol must together provide the following features of LFB resource
manipulation:
o FE selection. This is primarily to refer to a single FE, but
referring to a group or all FEs may optionally be supported.
o LFB instance selection. This is primarily to refer to a single LFB
instance of a FE, but optional addressing of a group of LFBs may
be supported.
o Addressing individual resource components of the LFB.
o Efficient encoding and decoding of the addressing info and the
Haraszti & Blake Expires December 30, 2003 [Page 26]
Internet-Draft ForCES FE Functional Model Elements July 2003
configured data.
o Efficient data transmission of the above info on the wire (to
minimize communication load on the CE-FE link).
Support for various levels of feedback from the FE to the CE (e.g.,
request received, configuration completed), as well as multi-resource
configuration transactions with atomic commit and rollback, may be
necessary in some circumstances, but are left for further study.
7.7 LFB Topology Re-configuration
This feature is needed only if the LFB topology is configurable on a
given FE.
Operations that will be needed:
o Create a new instance of a given LFB class on a given FE.
o Connect a given output of LFB x to the given input of LFB y.
o Disconnect: remove a link between a given output of a LFB and a
given input of another LFB.
o Delete a given LFB (automatically removing all interconnects to/
from the LFB).
7.8 FE Topology Re-configuration
The need for this feature is probably debatable, so this area
requires more study.
At any rate, FEs cannot be created or deleted on the fly, only the
interconnects between FEs may be configurable. The CE may be able to
enable/disable individual inter-FE datapath interconnects.
8 Security Considerations
None.
Haraszti & Blake Expires December 30, 2003 [Page 27]
Internet-Draft ForCES FE Functional Model Elements July 2003
References
[FWK] Yang, L., Dantu, R. and T. Anderson, "Forwarding and
Control Element Separation (ForCES) Framework", December
2002, <http://www.ietf.org/internet-drafts/
draft-ietf-forces-framework-04.txt>.
[MODEL] Yang, L., Halpern, J., Gopal, R. and R. Dantu, "ForCES
Forwarding Element Functional Model 02", March 2003,
<http://www.sstanamera.com/~forces/Old/
draft-yang-forces-model-02.txt>.
[NETLINK2]
Salim, J. and R. Haas, "Netlink2 as ForCES protocol",
December 2002, <http://www.ietf.org/internet-drafts/
draft-jhsrha-forces-netlink2-00.txt>.
[REQS] Khosravi, H. and T. Anderson, "Requirements for Separation
of IP Control and Forwarding", May 2003, <http://
www.ietf.org/internet-drafts/
draft-ietf-forces-requirements-09.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Zsolt Haraszti
Ericsson
920 Main Campus Dr, St. 500
Raleigh, NC 27606
US
Phone: +1 919 472 9949
EMail: zsolt.haraszti@ericsson.com
Steven Blake
Ericsson
920 Main Campus Dr, St. 500
Raleigh, NC 27606
US
Phone: +1 919 472 9913
EMail: steven.blake@ericsson.com
Haraszti & Blake Expires December 30, 2003 [Page 28]
Internet-Draft ForCES FE Functional Model Elements July 2003
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Haraszti & Blake Expires December 30, 2003 [Page 29]
Internet-Draft ForCES FE Functional Model Elements July 2003
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Haraszti & Blake Expires December 30, 2003 [Page 30]