[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

        Internet Draft                                 L. Yang
        Expiration: May 2003                                Intel Labs
        File: draft-yang-forces-model-01.txt           J. Halpern
        Working Group: ForCES
                                                       R. Gopal
                                                       R. Dantu
                                                            Univ. of Texas
                                                       Nov 2002
                     ForCES Forwarding Element Functional Model
        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
        The list of current Internet-Drafts can be accessed at
        The list of Internet-Draft Shadow Directories can be accessed at
        This document defines a functional model for forwarding elements
        (FEs) used in the Forwarding and Control Plane Separation (ForCES)
        protocol.  This model is used to describe the capabilities and state
        of ForCES forwarding elements within the context of the ForCES
        protocol, so that ForCES control elements (CEs) can control the FEs
        accordingly. The model is to specify what logical functions are
        present in the FEs, what capabilities these functions support, and
        in what order these functions are or can be performed. The
        forwarding element model defined herein is intended to satisfy the
        requirements specified in the ForCES requirements draft [FORCES-
        REQ].  Using this model, predefined or vendor specific logical
     Internet Draft         ForCES FE Functional Model          Nov 2002
        functions can be expressed and configured. However, the definition
        of these individual functions are not described and defined in this
     Table of Contents
        1. Definitions.....................................................2
        2. Motivation and Requirements of FE model.........................3
        3. Capability Model versus State Model.............................3
        4. FE Model........................................................6
           4.1. FE Blocks..................................................7
           4.2. FE Block Library...........................................7
              4.2.1. QoS Functions.........................................8
              4.2.2. Generic Filtering Functions..........................10
              4.2.3. Vendor Specific Functions............................10
              4.2.4. Port Functions.......................................10
              4.2.5. Forwarding Functions.................................11
              4.2.6. High-Touch Functions.................................12
              4.2.7. Security Functions...................................12
              4.2.8. Off-loaded Functions.................................12
           4.3. FE Stage and Directed Graph of FE.........................13
              4.3.1. Basic Concepts.......................................13
              4.3.2. Topological versus Encoded State Approaches..........13
              4.3.3. Cascading FE Blocks..................................16
        5. Data Modeling and Representation...............................16
        6. Security Considerations........................................17
        7. Intellectual Property Right....................................17
        8. IANA consideration.............................................18
        9. Normative References...........................................18
        10. Informative References........................................18
        11. Acknowledgments...............................................18
        12. Authors' Addresses............................................19
     Conventions used in this document
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        this document are to be interpreted as described in [RFC-2119].
     1. Definitions
        A set of terminology associated with the ForCES requirements is
        defined in [FORCES-REQ] and is not copied here. The following list
        of terminology is relevant to the FE model defined in this document.
        Datapath -- A conceptual path taken by packets within the forwarding
        plane, inside an FE. There might exist more than one datapath within
        an FE.
        Forwarding Element (FE) Block -- An abstraction of the basic packet
        processing logical functions in the datapath. It is the building
     Yang, et. al.      Expires May 2003                      [Page 2]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        block of FE functionality. This concept abstracts away
        implementation details from the parameters of interest for
        configuration, control and management by CE.
        Forwarding Element (FE) Stage -- Representation of an FE block
        instance in a FE's datapath. As a packet flows through an FE along a
        datapath, it flows through one or multiple distinct stages, with
        each stage implementing an instance of a certain logical function
        block. There may be multiple instances of the same functional block
        in a FE's datapath.
     2. Motivation and Requirements of FE model
        The ForCES architecture allows Forwarding Elements (FEs) of varying
        functionality to participate in a ForCES network element (NE).  The
        implication of this varying functionality is that CEs can make only
        minimal assumptions about the functionality provided by its FEs.
        Before CEs can configure and control the forwarding behavior of FEs,
        CEs need to query and discover the capabilities and states of their
        FEs.  [FORCES-REQ] mandates that this capabilities and states
        information be expressed in the form of an FE model, and this model
        will be used as the basis for CEs to control and manipulate FEs'
        behavior via ForCES protocol.
        [FORCES-REQ] describes all the requirements placed on the FE model
        in detail. We provide a brief summary here to highlight some of the
        design issues we face.
          . The FE model MUST express what logical functions can be applied
             to packets as they pass through an FE.
          . The FE model MUST be capable of supporting/allowing variations
             in the way logical functions are implemented on an FE.
          . The model MUST be capable of describing the order in which
             these logical functions are applied in a FE.
          . The FE model SHOULD be extendable and should have provision to
             express new or vendor specific logical functions.
          . The FE model SHOULD be able to support minimal set of logical
             functions that are already identified, such as port functions,
             forwarding functions, QoS functions, filtering functions, high-
             touch functions, security functions, vendor-specific functions
             and off-loaded functions.
     3. Capability Model versus State Model
        Since the motivation of an FE model is to allow the CEs later to
        control and configure the FEs' behavior via ForCES protocol, it
        becomes essential to examine and understand what kind of control and
        configuration the CEs might do to the FEs. It is also equally
        essential to understand how configurable or programmable FEs are
        today and will be in the near future. To understand the issue
        better, it is helpful to make a distinction between two different
        kinds of FE models û the FE state model and FE capability model.
     Yang, et. al.      Expires May 2003                      [Page 3]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        The FE state model describes the current state of the FE, that is,
        the instantaneous values or operational behavior of the FE. The FE
        state model presents the snapshot view of the FE to the CE. On the
        other hand, the FE capability model describes the configurable
        capabilities of an FE in terms of variations of functions supported
        or limitations contained. Conceptually FE capability model presents
        the many possible states allowed on an FE. The information on the
        capabilities of the FE helps the CE to make more intelligent
        decision on the configuration it wants to send to the FE. So the
        configuration is the desirable state that the FE should be in.
        Figure 1 shows the concepts of FE state, capabilities and
        configuration in the context of CE-FE communication via ForCES
             +---------+                                     +---------+
             |         | FE state: what it is now.           |         |
             |         |<------------------------------------|         |
             |         |                                     |         |
             |   CE    | FE capabilities: what it can be.    |   FE    |
             |         |<------------------------------------|         |
             |         |                                     |         |
             |         | FE configuration: what it should be.|         |
             |         |------------------------------------>|         |
             +---------+                                     +---------+
         Figure 1. Illustration of FE state, capabilities and configuration
                  in the context of CE-FE communication via ForCES.
        For example, using the FE state model, an FE may be described to its
        CE as the following:
        - on a given port the packets are classified using a given
        classification filter;
        - the given classifier results in packets being metered in a certain
        way, and then marked in a certain way;
        - the packets coming from specific markers are delivered into a
        shared queue for handling, while other packets are delivered to a
        different queue;
        - a specific scheduler with specific behavior and parameters will
        service these collected queues.
        On the other hand, the capability model may describe the FE at the
        coarsest level such as:
        - this FE can handle IPv4 and IPv6 forwarding;
        - this FE can perform classification on the following fields: source
        IP address, destination IP address, source port number, destination
        port number, etc;
        - this FE can perform metering;
        - this FE can handle up to N queues;
        - this FE can add and remove encapsulating headers of types
        including IPSec, GRE, L2TP.
        Where it gets more complicated is for the capability model to cope
        with the detailed limits, issues such as how many classifiers the FE
     Yang, et. al.      Expires May 2003                      [Page 4]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        can handle, how many queues, and how many buffer pools the FE can
        support, how many meters the FE can provide. There is also the issue
        as how flexibly these various functions can be interconnected within
        the FE, in another word, how programmable the FE really can be and
        how the FE capability model can reflect that.
        While one could try to build an object model for representing
        capabilities in full, other efforts have found this to be a
        significant undertaking. A middle of the road approach is to define
        coarse-grained capabilities and simple capacity measures.  Then, if
        the CE attempts to instruct the FE to set up some specific behavior
        it is not capable of, the FE will return an error indicating the
        It is clear that in the context of ForCES, a state model is
        definitely necessary. The question is how much of the capability
        model is needed in addition to the state model. A simple state model
        without any capability flavor will severely limit ForCESÆs ability
        to take advantage of the flexibility offered by programmable FEs. On
        the other hand, an all too powerful capability model is difficult to
        develop and may impose unnecessary overhead for most of the FEs that
        only offer static functionalities.
        In order to strike a good balance, it is necessary to examine the
        kinds of control and configuration that the CEs may do to the FEs.
        The first kind of control and configuration is the simplest of all.
        It assumes that the logical functions that an FE supports are
        already given and the interconnection of these functions remains
        static in its lifetime. Therefore, the CE can only control FEÆs
        behavior by manipulating the parameters for each individual
        function, but it cannot change either the datapath or the functions
        along each datapath. We call this "static FE" control and
        configuration. For example, Figure 4 and 6 each show an FE
        configuration example by representing the processing steps in a
        directed graph interconnecting all the functional stages that
        packets can possibly traverse. If such a configuration remains
        static during FE's lifetime, then all CE can control is the
        parameters associated with each stage in the graph, for example, the
        routing table in the LPM forwarder in Figure 4, or the token bucket
        parameters associated with meter1 in Figure 6. However, the CE
        cannot reconfigure the graph topology dynamically, such as adding
        another meter or queue onto the FE in Figure 6 on the fly. For this
        kind of static control and configuration purpose, the useful FE
        model should describe how the graph is connected and what are the
        ôdials and knobsö (i.e., the parameters or attributes) each function
        allows CE to manipulate. It should also include the statistics and
        events that FEs can collect and report to CEs. Even for such a
        ôstatic FEö, some capability model at the individual functions level
        may be desirable to convey the flexibility of each function.
        However, a lot of other information may not be necessary, like the
        packet formats supported between meter1 and counter1 in Figure 6 as
     Yang, et. al.      Expires May 2003                      [Page 5]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        an example, because such information is only useful when the graph
        can be re-configured dynamically on the fly.
        The second kind of control and configuration builds on top of the
        first kind. Using Figure 6 as an example, instead of presenting the
        static FE graph to the CE, the FE can convey its capabilities to the
        CE by telling "this FE can support one classifier with up to N
        filters. This FE can also support up to M meters, X queues, etc." We
        call this dynamic FE control and configuration. For such dynamic
        control and configuration, a more powerful and flexible FE
        capability model is required. For example, it becomes necessary to
        model not only the capability of the building blocks like
        classifiers, filters, meters etc., but also the linkage flexibility
        and constraints between the blocks, so that CE can have the
        intelligence to build a dynamic FE graph that makes sense.
        The third level of control and configuration is even more powerful
        and future looking. In addition to dynamic configuration, CEs might
        even be allowed to download a given functionality onto FEs at run
        time. This is similar to the active network concept and so we call
        it active FE control and configuration. Like active network, this is
        still considered a research area and is not being considered here.
        The FE model proposed in this document intends to fully support the
        static FE control and configuration at the minimum. It is also our
        intention to allow dynamic FE control and configuration to a certain
        degree when it makes sense. This FE model currently makes no attempt
        to address issues beyond the first two kinds of control and
        configuration scenarios.
     4. FE Model
        This section proposes a ForCES FE model to satisfy all the
        requirements in [FORCES-REQ] for FE control and configuration. The
        approach taken is to model the FE datapath(s) and its packet
        treatment behavior via a directional graph where each node in the
        graph is an instance of a well-defined logical function block.
        The FE model defines a generic FE block akin to an abstract base
        class in object-oriented terminology. The generic FE block contains
        basic information like block type and textual description of the
        block function. Based on this generic FE block, a set of well-known
        FE logical functions are defined with additional state and
        capability information pertinent to each specific function. A name
        space is used to associate a unique name or ID with each type of FE
        block. New logical functions can also be added later to accommodate
        future innovation in the forwarding plane, as long as the new
        functions are modeled as an FE block.  With such a set of basic
        building blocks defined, any FE can be modeled by a directional
        graph where each node is an instance of an FE block, representing a
        processing stage in the packet datapath. Each node contains
        information like block name or ID (indicating the block type), stage
     Yang, et. al.      Expires May 2003                      [Page 6]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        ID (local to FE), number of downstream blocks and a list of the
        stage IDs of those downstream blocks.
        The rest of this section is devoted to describe the informal data
        model of FE. The description here is intended to be abstract and
        conceptual, and examples are used for illustration purpose only.
        Separate document(s) will serve as specifications by using a formal
        data modeling language and those specifications should be consistent
        with the conceptual model described here.
     4.1. FE Blocks
        The generic FE block is the basic building block of the FE model,
        like an abstract base class in object-oriented terminology. Actual
        FE logical functions like classifiers, IPv4 forwarders and meters
        are examples of real FE blocks derived from the generic FE block
        A well-defined block has a well-defined packet processing behavior
        and a well-defined set of state and capabilities that CE can
        potentially configure or control via ForCES. A namespace is needed
        to specify different types of blocks. The namespace assigns either a
        unique ID or label to each distinct block type. Such a namespace
        must be extensible so that new functions can be easily added later.
        Therefore, the following defines a generic FE Block:
        - block ID or label which uniquely identifies the block type;
        - textual description of block function.
     4.2. FE Block Library
        We expect a small set of well-understood FE functional blocks to be
        defined initially. Such a set of blocks can be viewed as a FE block
        library. The minimum set of FE functions required in [FORCES-REQ]
        must be part of this library. It is expected that new FE blocks
        would be defined and added into this library over time.
        The actual model for each functional block may differ and contains
        information pertinent to the semantics of the function itself.
        However, some general guideline is still useful. For example,
        typically it is important to specify information such as:
        - how many inputs it takes and what kinds of packets and meta data
        it takes for each input;
        - how many outputs it produces and what kind of packets and meta
        data it emits for each output;
        - the packet processing (such as modification) behavior;
        - what information is programmed into it (e.g., LPM list, next hop
        list, WRED parameters, etc.) and what parameters among them are
        - what statistics it keeps (e.g., drop count, CRC error count,
        - what events it can throw (e.g., table miss, port down, etc.).
     Yang, et. al.      Expires May 2003                      [Page 7]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        This document only intends to describe the conceptual FE model and
        illustrate it with some examples. However, it is not the intention
        of this document to define any specific block or the library itself.
        Separate document(s) would be written to do that. The minimum set of
        FE functions required in [FORCES-REQ] is listed and discussed
        briefly in the following subsections. The IETF DiffServ
        (Differentiated Services) and RAP (Resource Allocation Protocols)
        working groups have done some relevant work in modeling the
        provisioning policy data for QoS functions and filtering functions.
        Therefore, we will start our discussion from these related models.
     4.2.1. QoS Functions
        The IETF community has already done some work in modeling the QoS
        functions in the datapath. The IETF DiffServ working group has
        defined an informal data model [RFC3290] for QoS-related functions
        like classification, metering, marking, actions of marking,
        dropping, counting and multiplexing, queueing, etc. The latest work
        on DiffServ PIB (Policy Information Base) [DS-PIB] defines a set of
        provisioning classes to provide policy control of resources
        implementing the Diferentiated Services Architecture. DiffServ PIB
        also has an element of capability flavor in it that can potentially
        enable more dynamic and intelligent configuration of individual
        functions and the interconnection of the functions. The IETF Policy
        Framework working group is also defining an informational model
        [QDDIM] to describe the QoS mechanisms inherent in different network
        devices, including hosts. This model is intended to be used with the
        QoS Policy Information Model [QPIM] to model how policies can be
        defined to manage and configure the QoS mechanisms present in the
        datapath of devices.
              Unclassified              classified
              traffic                   traffic
                      |            |--> match Filter1 --> OutputA
              ------->| classifier |--> match Filter2 --> OutputB
                      |            |--> no match      --> OutputC
              Figure 2. An Example Classifier Using DiffServ Model
        We use the classifier defined in [RFC3290] as an example to
        illustrate the DiffServ model. "Classifiers are 1:N (fan-out)
        devices: they take a single traffic stream as input and generate N
        logically separate traffic streams as output.  Classifiers are
        parameterized by filters and output streams.  Packets from the input
        stream are sorted into various output streams by filters which match
        the contents of the packet or possibly match other attributes
        associated with the packet." To further define filters: "A filter
        consists of a set of conditions on the component values of a
        packet's classification key (the header values, contents, and
     Yang, et. al.      Expires May 2003                      [Page 8]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        attributes relevant for classification)." Figure 2 illustrates an
        example classifier.
        Based on this conceptual model, [DS-PIB] specifies a classifier of
        1:N by N classifier elements. Each classifier element specifies the
        - element ID which identifies the particular output out of N;
        - classifier instance ID which identifies the classifier instance
        (all the N classifier elements belong to the same classifier have
        the same classifier instance ID);
        - precedence which is an unsigned integer value to represent the
        relative order in which classifier elements are applied (the
        classifier element with the highest precedence will be matched
        - next datapath element which provides a pointer to the next
        function along this branch out of N fan-out;
        - filter ID which points to the filter used for this branch (Note
        that filter is defined independent of the classifier and used here
        as a parameter to the classifier).
        It is clear from the example above that DiffServ model uses a
        topological approach to capture the multiple datapath a packet can
        potentially take. Graphically, a classifier of 1:N has N output
        branches leading to the next N datapath elements. This has
        significant implication when we consider the interconnected graph of
        the functions on FE (see Section 4.3). The alternative is to use an
        encoded state approach where each packet gets some state information
        associated with it that indicates the datapath it takes next. For
        example, using the encoded state approach, a classifier of 1:N may
        be represented by just one output branch, if all N of the next
        datapath elements are of the same block function, say, shaper.
                 |     Meter-A    |
                 |                |
           ----->|            In -|-----PM-1--->
                 |                |
                 |           Out -|-----PM-2--->
                Figure 3:  Meter Followed by Two Preamble Markers
        The QDDIM model uses the alternative encoded state approach so that
        information about the treatment that a packet received on an ingress
        interface is allowed to be communicated along with the packet to the
        egress interface (see [QDDIM] Section 3.8.3). QDDIM model represents
        this information transfer in terms of a packet preamble. Figure 3
        shows the same example used in [QDDIM] (section 3.8.3) in which
        meter results are captured in a packet preamble. ôPreamberMarker PM-
     Yang, et. al.      Expires May 2003                      [Page 9]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        1 adds to the packet preamble an indication that the packet exited
        Meter A as conforming traffic. Similarly, PreambleMarker PM-2 adds
        to the preambles of packets that come through it indications that
        they exited Meter A as nonconforming traffic. A PreambleMarker
        appends its information to whatever is already present in a packet
        preamble, as opposed to overwriting what is already there.ö ôTo
        foster interoperability, the basic format of the information
        captured by a PreambleMarker is specified.ö ôOnce a meter result has
        been stored in a packet preamble, it is available for any subsequent
        Classifier to use.ö
        Section 4.3 has more discussion on the difference between the
        topological approach (as used by DiffServ model) and the encoded
        state approach (as used by QDDIM).
        [DS-PIB] also defines a capability model for classifiers by
        specifying a bit set to indicate the ability to classify based on IP
        source address, IP destination address, IP protocol numbers, IP DSCP
        field, layer 4 port number for UDP and TCP, and Ipv6 flow ID. The
        capability is thus made known by simply setting the bits
        accordingly. Similar technique is also used to indicate capabilities
        of other functions like meters, droppers, etc.
        While the DiffServ and QDDIM models are not designed with the
        primary goal of direct machine implementation, we can still use them
        as our starting point.
     4.2.2. Generic Filtering Functions
        The framework PIB ([FRMWK-PIB]) from the IETF RAP (Resource
        Allocation Protocol) working group defines four groups of PRCs
        (Provisioning Classes) that are expected to be common to all clients
        that provision policy using COPS-PR ([RFC3084]). One of the four PRC
        groups is classifier group, which contains the Base Filter Class and
        the other extended filters including the IP Filter, the IEEE 802
        Filter and the Internal Label Filter. Even if SPPI ([RFC3159]) is
        not the final chosen data model for our FE model, it may still be
        valuable to use the work done here as a starting point for the
        generic filter functions modeling.
     4.2.3. Vendor Specific Functions
        New and currently unknown FE functionality can be derived (i.e.,
        extended) based on the generic FE Block. The name space used to
        identify the FE block type must be extensible such that new logical
        functions can be defined and added later to accommodate future
        innovation in forwarding plane, as long as the new functions are
        modeled as an FE block.
     4.2.4. Port Functions
     Yang, et. al.      Expires May 2003                      [Page 10]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        Every FE contains a certain number of interfaces (ports), including
        both the inter-NE interfaces and intra-NE interfaces. The inter-NE
        interfaces are the external interfaces for the NE to receive/forward
        packets from/to the external world. The intra-NE interfaces are used
        for FE-FE or FE-CE communications.
        Certain types of physical ports have sub-interfaces (frame relay
        DLCIs, ATM VCs, Ethernet VLans, etc.) as virtual or logical
        interfaces. Some implementations treat tunnels (e.g., GRE, L2TP,
        IPSec, MPLS, etc.) as interfaces, while others do not. [FORCES-REQ]
        treats tunneling as high-touch functions and so FE model does not
        model tunneling as part of the port functions. Instead, tunneling is
        covered in Section 4.2.6.
        Port function expresses:
        - the number of ports on the FE;
        - the sub-interfaces if any;
        - the static attributes of each port (e.g., port type, direction,
        link speed);
        - the configurable attributes of each port (e.g., IP address,
        administrative status);
        - the statistics collected on each port (e.g., number of packets
        - the current status (up or down).
     4.2.5. Forwarding Functions
        Support for IPv4 and IPv6 unicast and multicast forwarding functions
        must be provided by the model.
        Typically, the control plane maintains the Routing Information Base
        (RIB), which contains all the routes discovered by all the routing
        protocols with all kinds of attributes relevant to the routes. The
        forwarding plane uses a different database, the Forwarding
        Information Base (FIB), which contains only the active subset of
        those routes (only the best routes chosen for forwarding) with
        attributes that are only relevant for forwarding. A component in the
        control plane, termed Route Table Manager (RTM), is responsible to
        manage the RIB in the CE and maintain the FIB used by the FEs.
        Therefore, the most important aspect in modeling the forwarding
        functions is the data model for the FIB. The model also needs to
        support the possibility of multiple paths.
        At the very minimum, each route in the FIB needs to contain the
        following layer-3 information:
        - the prefix of the destination IP address;
        - the length of the prefix;
        - the number of equal-cost multi-path;
        - the next hop IP address and the egress interface for each path.
     Yang, et. al.      Expires May 2003                      [Page 11]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        Another aspect of the forwarding functions is the method to resolve
        a next hop destination IP address into the associated media address.
        There are many ways to resolve Layer 3 to Layer 2 address mapping
        depending upon link layer. For example, in case of Ethernet links,
        the Address Resolution Protocol (ARP, defined in RFC 826) is used
        for IPv4 address resolution.
        Assuming a separate table is maintained in the FEs for address
        resolution, the following information is necessary for each address
        resolution entry:
        - the next hop IP address;
        - the media address.
        Different implementation may have different ways to maintain the FIB
        and the resolution table. For example, a FIB may consist of two
        separate tables, one to match the prefix to the next hop and the
        other to match the next hop to the egress interface. Another
        implementation may use one table instead. Our model of the
        forwarding functions should allow such flexibility.
     4.2.6. High-Touch Functions
        High-touch functions are those that take action on the contents or
        headers of a packet based on content other than what is found in the
        IP header.  Examples of such functions include NAT, ALG, firewall,
        tunneling and L7 content recognition.
        The ForCES working group first needs to agree upon a small set of
        common high-touch functions with well-defined behavior to be
        included in the initial FE block library.
     4.2.7. Security Functions
        The FE model must be able to describe the types of encryption and/or
        decryption functions that an FE supports and the associated
        attributes for such functions.
     4.2.8. Off-loaded Functions
        In addition to the packet processing functions that are typical to
        find on the FEs, some logical functions may also be executed
        asynchronously by some FEs, according to a certain finite-state
        machine, triggered not only by packet events, but by timer events as
        well. Examples of such functions include finite-state machine
        execution required by TCP termination or OSPF Hello processing off-
        loaded from the CE. The FE model must be capable of expressing these
        asynchronous functions, so that the CE may take advantage of such
        off-loaded functions on the FEs.
        The ForCES working group first needs to agree upon a small set of
        such off-loaded functions with well-understood behavior and
        interactions with the control plane.
     Yang, et. al.      Expires May 2003                      [Page 12]

     Internet Draft         ForCES FE Functional Model          Nov 2002
     4.3. FE Stage and Directed Graph of FE
        With a set of basic FE functions defined in the block library, we
        are ready to model any FEÆs packet processing behavior by a
        directional graph where each node is an instance of an FE block,
        representing a processing stage in the packet datapath. This section
        describes the details behind such a ôdirected graphö FE model.
     4.3.1. Basic Concepts
        An FE stage is simply an instance of an FE block within an FE's
        datapath. As a packet flows through an FE along a datapath, it flows
        through one or multiple distinct stages, with each stage
        instantiating a certain FE logical function. Each FE allocates an
        FE-unique stage ID to each of its stages and passes the stage ID
        along with the corresponding block type as part of the FE stage
        information. This allows multiple instances of the same block
        present in a FE's datapath. Using NAT as an example, one NAT
        function is typically performed before the forwarding stage (packets
        arriving externally have their public addresses replaced with
        private addresses) and one NAT function is performed after (for
        packets exiting the domain, their private addresses are replaced by
        public ones). So there are three stages (NAT, forwarding, and NAT
        again) in this example datapath, with two NAT instances present in
        two different stages.
        A static FE can be modeled by a directed graph interconnecting all
        the stages present in the FE. Each node in the graph corresponds to
        a stage. In order to represent the directed interconnection between
        two consecutive stages along a datapath, each stage contains a ônext
        stageö pointer that is simply the stage ID of its next stage in the
        graph. Therefore, the following defines an FE stage (i.e., a node in
        the FE gragh):
        - stage identifier which uniquely identifies the node within this FE
        - block type which identifies the block function that this stage is
        an instance of;
        - number of downstream stages which corresponds to the number of
        downstream nodes connected to this stage;
        - downstream stage identifiers which corresponds to the set of
        downstream nodes connected to this stage.
        With such information defined for each FE stage, it is now possible
        for CE to query the state of the static FE graph by querying for the
        initial (ingress) stages of the graph and then traversing the whole
        graph in a node-by-node fashion.
     4.3.2. Topological versus Encoded State Approaches
        As pointed out in Section 4.2.1, there are potentially two different
        approaches to model the nodes and the connections between the nodes
        in the FE graph, namely, the topological approach and the encoded
        state approach.
     Yang, et. al.      Expires May 2003                      [Page 13]

     Internet Draft         ForCES FE Functional Model          Nov 2002
                      +------------+   +------------+   +------------+
               input  | Ethernet   |   |            |   | Ethernet   |output
              ------->| Ingress    |-->| IPv4 L3 LPM|-->| Egress     |----->
                      | Port Mgr   |   | Forwarder  |   | Port Mgr   |
                      +------------+   +------------+   +------------+
                     {stage ID=1,     {stage ID=2,      {stage ID=3,
                      type=            type=             type=
                        Enet-IngP-Mgr,   IPv4-L3-LPM-fwd,  Enet-EgP-Mgr,
                      #downstream=1,   #downstream=1,    #downstream=1,
                      downstream={2}   downstream={3}    downstream=none
                     }                }                 }
            Figure 4. A simple example of an FE graph using encoded state
               Input  +------------+   +------------+               output
              ------->|Ingr-Port #1|-->|            |
                      +------------+   |            |   +------------+
              ------->|Ingr-Port #2|-->|            |-->|EgressPort#1|----->
                      +------------+   |            |   +------------+
              ------->|Ingr-Port #3|-->|IPv4 L3 LPM |-->|EgressPort#2|----->
                      +------------+   |Forwarder   |   +------------+
              ------->|Ingr-Port #4|-->|            |-->|EgressPort#3|----->
                      +------------+   |            |   +------------+
              ------->|Ingr-Port #5|-->|            |-->|EgressPort#4|----->
                      +------------+   |            |   +------------+
              ------->|Ingr-Port #6|-->|            |
                      +------------+   +------------+
                     {stage ID=1      {stage ID=7,      {stage ID=8,
                      type=            type=             type=
                        Enet-Ing-port,   IPv4-L3-LPM-fwd,  Enet-Eg-port,
                      #downstream=1,   #downstream=4,    #downstream=1,
                      downstream={7}   downstream=       downstream=none
                     }                  {8,9,10,11}     }
                     . . .            }                 . . .
                     {stage ID=6                        {stage ID=11,
                      type=                              type=
                        Enet-Ing-port,                    Enet-Eg-port-Mgr,
                      #downstream=1,                     #downstream=1,
                      downstream={7}                     downstream=none
                     }                                  }
             Figure 5. The same example as in Figure 4 using topological
        Using the topological approach as exemplified by DiffServ model,
        there are N connections between a fan-out node of 1:N (e.g., a
        classifier) and its next stages. Using the encoded state approach,
     Yang, et. al.      Expires May 2003                      [Page 14]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        fewer connections are typically needed between the same fan-out node
        and its next stages, because each packet carries some state
        information as metadata that the next stage nodes can interpret and
        invoke different packet treatment. Pure topological approaches can
        be overly complex to represent because they force on to build
        elaborate topologies with a lot more connections.  An encoded state
        approach is nicer in that it allows one to simplify the graph and
        represent the functional blocks with more clarity. But it does
        require extra metadata to be carried along with the packet, like the
        preamble in the QDDIM model.
        For example in Figure 4, stage #2 (IPv4 L3 LPM Forwarder) generates
        some metadata at its output to carry information on which port the
        packets should go to, and #3 (Enet-Egress-port-Manager) uses this
        meta data to direct the packets to the right egress port. Figure 5
        shows how the FE graph looks like when using the pure topological
        approach instead, assuming 6 ingress and 4 egress ports. It is clear
        that Figure 5 is unwieldy compared to Figure 4.
                             +---+                    +--+
                             |  A|------------------->|  |--+
                          +->|   |                    |  |  |
                          |  |  B|--+  +--+   +--+    +--+  |
                          |  +---+  |  |  |   |  |          |
                          | Meter1  +->|  |-->|  |          |
                          |            |  |   |  |          |
                          |            +--+   +--+          |
                          |         Counter1 Absolute Queue2|    +--+
                  +---+   |                  Dropper1 +--+  +--->|A |
                  |  A|---+                           |  |------>|B |
         -------->|  B|------------------------------>|  |  +--->|C |------>
                  |  C|---+                           +--+  | +->|D |
                  |  X|-+ |                                 | |  +--+
                  +---+ | |  +---+             +---+  Queue3| |  Scheduler
            Classifier1 | |  |  A|------------>|A  |  +--+  | |
                        | +->|   |             |   |->|  |--+ |
                        |    |  B|--+  +--+ +->|B  |  |  |    |
                        |    +---+  |  |  | |  +---+  +--+    |
                        |  Meter2   +->|  |-+  Mux1           |
                        |              |  |                   |
                        |              +--+           Queue4  |
                        |            Marker1          +--+    |
                        +---------------------------->|  |----+
                                                      |  |
             Figure 6. An FE example with multiple datapath.
        Note that the FE graph can represent largely arbitrary topologies of
        the stages, regardless which approach (topological or encoded state)
        is taken. For example, Figure 6 shows an FE implementing QoS
        functions via a combination of logical functions like classifier,
     Yang, et. al.      Expires May 2003                      [Page 15]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        meter, marker, queue, scheduler, etc. Both approaches are able to
        represent such an FE graph. The only restrictions on topology relate
        to the source and sink nature of ingress and egress port functions
        respectively. For example, egress port functions must not have any
        downstream stages whereas no other stage may refer to an ingress
        port function as one of its downstream stages.
     4.3.3. Cascading FE Blocks
        An FE block may contain zero, one or more ingress port stages.
        Similarly, an FE block may contain zero, one or more egress port
        stages. In another word, not every FE block has to contain any
        ingress port or egress port stages. For example, Figure 7 shows two
        cascading FE blocks. Block #1 contains one ingress port function but
        no egress port function, while block #2 contains one egress port
        function but no ingress port function. It is possible to connect
        these two FE blocks together to achieve the complete ingress-to-
        egress packet processing function. This provides the flexibility to
        spread the functions across multiple FEs and interconnect them
        together later for certain applications.
           |  +---------+   +------------+   +---------+         |
         input|         |   |            |   |         | output  |
        ---+->| Ingress |-->|Header      |-->|IPv4     |---------+--->+
           |  | port    |   |Decompressor|   |Forwarder| FE      |    |
           |  +---------+   +------------+   +---------+ Block #1|    |
           ------------------------------------------------------|    V
                |    |-----------------------------------------
                V    |  +------------+   +----------+         |
                | input |            |   |          |  output |
                +->--+->|Header      |-->| Egress   |---------+-->
                     |  |Compressor  |   | port     | FE      |
                     |  +------------+   +----------+ Block #2|
        Figure 7. An example of two different FE blocks connected together.
     5. Data Modeling and Representation
        A formal data modeling language is needed to represent the
        conceptual FE model described in this document and a full
        specification will be written using such a data modeling language.
        It is also necessary to identify a data representation method for
        over-the-wire transport of the FE model data.
        The following is a list of some potential candidates for
        consideration. For the moment, we intend to leave this as an open
        issue and much debate is needed in the ForCES WG before a decision
     Yang, et. al.      Expires May 2003                      [Page 16]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        can be made. Therefore, we only provide the candidate list and some
        initial discussion here without drawing a conclusion yet.
        - XML (Extensible Markup Language) Schema
        - ASN.1 (Abstract Syntax Notation One)
        - SMI (Structure of Management Information) [RFC1155]
        - SPPI (Structure of Policy Provisioning Information) [RFC3159]
        - UML (Universal Modeling Language)
        Most of the candidates here, with the notable exception of UML, are
        capable of representing the model in the document and over-the-wire.
        Of course, it is also possible to choose one data model language for
        specification in the document and later allow several over-the-wire
        representations to map the model into different implementations.
        XML has the advantage of being human and machine readable with
        widely available tools support. However, it is very verbose and
        hence less efficient for over-the-wire transport. It also requires
        XML parsing functions in both the CE and FE and hence may impose
        large footprint esp. for FEs. Currently XML is not yet widely
        deployed and used in network elements. XML for network configuration
        in general remains an open area that still requires substantial
        investigation and experiment in IETF.
        ASN.1 format is human readable and widely used in network protocols.
        SMI is based on a subset of ASN.1 and used to define Management
        Information Base (MIB) for SNMP. SPPI is the adapted subset of SMI
        used to define Policy Information Base (PIB) for COPS. Substantial
        investment has been made in SMI/MIBs/SNMP by IETF and the Internet
        community collectively has had many years of design and operation
        experience with SMI/MIBs/SNMP. However, it is also well recognized
        that SMI/MIBs/SNMP is not well suited for configuration and so
        SPPI/PIBs/COPS-PR attempts to optimize for network provisioning and
        UML is the software industryÆs standard language for specifying,
        visualizing, constructing and documenting the artifacts of software
        systems. It is a powerful tool for data modeling. However, it does
        not provide a data representation format for over-the-wire
     6. Security Considerations
        The FE model just describes the representation and organization of
        data sets and attributes in the forwarding plane. The associated
        communication protocol (i.e., ForCES protocol) will be defined in
        separate documents and so the security issues will be addressed
     7. Intellectual Property Right
        The authors are not aware of any intellectual property right issues
        pertaining to this document.
     Yang, et. al.      Expires May 2003                      [Page 17]

     Internet Draft         ForCES FE Functional Model          Nov 2002
     8. IANA consideration
        A namespace is needed to uniquely identify the FE block type for
        each FE logical function.
     9. Normative References
        [RFC1812]  F. Baker, ôRequirements for IP Version 4 Routers", June
        [RFC1155] M. Rose, et. al., ôStructure and Identification of
                   Management Informationfor TCP/IP-based Internets", May
        [RFC3084] K. Chan, et. al., ôCOPS Usage for Policy Provisioning,ö
                   March 2001.
        [RFC3159] K. McCloghrie, et. al., ôStructure of Policy Provisioning
                   Information (SPPI)", August 2001.
        [RFC3290] Y. Bernet, et. al., ôAn Informal Management Model for
                   Diffserv Routersö, May 2002.
     10. Informative References
        [FORCES-REQ] H. Khosravi, et. al., ôRequirements for Separation of
                   IP Control and Forwarding", work in progress, Oct 2002,
        [DS-PIB] M. Fine, et. al., ôDifferentiated Services Quality of
                   Service Policy Information Baseö, work in progress, June
                   2002, <draft-ietf-diffserv-pib-09.txt>.
        [FRMWK-PIB] M. Fine, et. al., ôFramework Policy Information Baseö,
                   work in progress, June 2002, <draft-ietf-rap-
        [QDDIM] B. Moore, et. al., ôInformation Model for Describing Network
                   Device QoS Datapath Mechanismsö, work in progress, May
                   2002, <draft-ietf-policy-qos-device-info-model-08.txt>.
        [QPIM] Y. Snir, et. al., ôPolicy Framework QoS Information Modelö,
                   work in progress, Nov 2001, <draft-ietf-policy-qos-info-
     11. Acknowledgments
     Yang, et. al.      Expires May 2003                      [Page 18]

     Internet Draft         ForCES FE Functional Model          Nov 2002
        The authors would also like to thank the following individuals for
        their invaluable technical input: David Putzolu, Hormuzd Khosravi,
        Eric Johnson, David Durham, Andrzej Matejko, T. Sridhar.
     12. Authors' Addresses
        Lily L. Yang
        Intel Labs
        2111 NE 25th Avenue
        Hillsboro, OR 97124 USA
        Phone: +1 503 264 8813
        Email: lily.l.yang@intel.com
        Joel Halpern
        P.O.Box 6049
        Leesburg, VA 20178
        Phone: +1 703 371 3043
        Email: jmh@joelhalpern.com
        Ram Gopal
        Nokia Research Center
        5, Wayside Road,
        Burlington, MA 01803
        Phone: +1 781 993 3685
        Email: ram.gopal@nokia.com
        Ram Dantu
        University of Texas Dallas
        2601 North Flyod Road
        Richardson Texas 75082
        Phone: +1 972 883 4653
        Email: ram.dantu@utdallas.edu
     Yang, et. al.      Expires May 2003                      [Page 19]

Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/