Internet DRAFT - draft-haraszti-forces-model

draft-haraszti-forces-model





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]