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

Versions: 00 01 02

        Internet Draft                                 L. Yang
        Expiration: December 2002                           Intel Labs
        File: draft-yang-forces-model-00.txt           J. Halpern
        Working Group: ForCES
                                                       R. Gopal
                                                       R. Dantu
                                                       June 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
     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. Abstract
        This document defines a functional model for ForCES forwarding
        elements (FEs).  This model is used to describe the 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 function instances are present
        in the FEs and in what order these functions are performed. The
     Internet Draft         ForCES FE Functional Model          June 2002
        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
        functions can be expressed and configured. However, the definition
        of these components are not described and defined in this document.
        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 functions in the datapath. It is the building block of FE
        functionality. This concept abstracts away implementation details
        from the parameters of interest for configuration, control and
        management by CE. The general rule of thumb on the granularity of FE
        blocks is that FE blocks should be coarse grained, stateful and
        focus on a particular domain. For example, RFC1812 compliant IPv4
        forwarder, classifiers, meters, etc..
        Forwarding Element (FE) Stage -- Representation of a 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.
        There may be one or more combination of such instances  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 FE,
        with two NAT instances present in two different stages.
     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 state of their
        FEs.  [FORCES-REQ] mandates that this capability and state
        information be expressed in the form of a FE model, and this model
        will be used as the basis for CEs to control FEs' capabilities and
        manipulate FEs' state 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.
     Yang, et. al.      Expires December 2002                    [Page 2]

     Internet Draft         ForCES FE Functional Model          June 2002
          . The FE model MUST express what logical functions can be applied
             to packets as they pass through a FE.
          . The FE model MUST be capable of supporting/allowing variations
             in the way logical functions are implemented on a 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. .
          . 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, and vendor-specific
        Since the motivation of an FE model is to allow CEs later to control
        and configure FEs' behavior via ForCES protocol, it becomes
        essential to examine and understand what kind of control and
        configuration CEs might do to FEs. We believe that there are roughly
        three levels of control and configuration that CEs can do to FEs.
        The first level of control and configuration is the simplest of all.
        It assumes that each FE's capability is already given and remains
        static in its lifetime, and CEs can only control its behavior by
        manipulating its state. We call this "static FE" control and
        configuration. For example, Figure 2 and 3 each shows 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 2, or the token bucket
        parameters associated with meter1 in Figure 3. But CE cannot
        reconfigure the graph topology dynamically, such as adding another
        meter or queue onto the FE in Figure 3 on the fly. For this kind of
        static FE control and configuration purpose, the useful FE model is
        consisted of the state information that FEs allow CEs to manipulate
        and the statistics and events that FEs can collect and report back
        to CEs. Such a state model doesn't need to describe a lot of other
        information, like the packet formats supported between meter1 and
        counter1 in Figure 3, for example. Because such information is only
        useful when the graph is re-configured dynamically on the fly.
        The second level of control and configuration builds on top of the
        first that is just described. Using Figure 3 as an example, instead
        of presenting the static FE graph to CE, FE can convey its
        capabilities to CE by telling CE that "This FE can support one
        classifier with up to N filters. This FE can also support M meters,
        X queues, etc." We call this dynamic FE control and configuration.
        For such control and configuration, a more powerful and flexible FE
        capability model is required in addition to the FE state model. For
        example, it becomes necessary to model the capability of the
        building blocks like classifiers, filters, meters etc. it also needs
     Yang, et. al.      Expires December 2002                    [Page 3]

     Internet Draft         ForCES FE Functional Model          June 2002
        to describe the packet formats supported at each input and output of
        each block to allow correct reconfiguration of the graph by CE.
        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
        The FE model proposed in this document intends to fully support the
        static FE control and configuration. It is also our intention to
        allow extension later to support dynamic FE control and
        configuration. However, this FE model currently makes no attempt to
        address issues beyond the simple static FE control and
     3. Capability and configuration Model versus State Model
        FE Model describes both the static capabilities and the configured
        capabilities. At any time after initial configuration the logical
        functions associated with an FE model may exhibit different
        characteristics and may lead to change in state of FE.   The
        capability describes set of parameters or attributes of  one or more
        logical functions of a FE, which may be useful for configuring and
        managing a FE. The state model describes the instantaneous values or
        operational behaviour of a FE.
        Typical  capabilities model describes at the coarsest level such
        aspects as
        - this FE can handle IPv4 and IPv6
        - this FE can perform 6-tuple classification (or can only do DA
        based processing, ...)
        - this FE can perform metering
        - this FE can handle multiple queues with multiple priorities
        - this FE can add and remove encapsulating headers of types: IPSec,
        GRE, L2TP
        Where it gets more complicated is coping with the detailed limits.
        Issues such has how many classifiers can the FE handle?
        How many headers can the FE add and remove?  How many queues, and
        how many buffer pools can the FE support?  How many meters can the
        FE provide?  How flexibly can these various parts be interconnected?
        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
        A state model describes the current state of the FE.  It lists
        - on a given port the packets are classified using a given
        classification filter
        - a given classifier results in packets being metered in a certain
        way, and then marked in a certain way
     Yang, et. al.      Expires December 2002                    [Page 4]

     Internet Draft         ForCES FE Functional Model          June 2002
        - packets coming from specific markers are delivered into a shared
        queue for handling, while other packets are delivered to a different
        - a specific scheduler with specific behavior and parameters will
        service these collected queues.
        While the DiffServ and QDDIM models are not designed with the
        primary goal of direct machine implementation, we will start with
        that model as it is better than no starting point.  Alternative
        suggestions for a state model which can be implemented more
        generally without significant transformation are sought from the
     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 first define a set of well-known FE logical
        functions (FE blocks) as the basic building blocks, so that any FE
        can be modeled by describing the kind of FE blocks or variants of
        these blocks it contains, and how the instances of these blocks are
        interconnected together. This model also allows new logical
        functions be added to accommodate future innovation in forwarding
        plane. We believe this approach strikes a good balance between
        flexibility and extensibility of the model and ease of use by the
     4.1. FE Blocks
        FE blocks are the very basic building blocks from which FEs model
        its overall packet processing behavior. The concept of a FE block is
        akin to that of an abstract base class in object-oriented
        terminology. Different FEs can have different implementation of the
        same block, but the packet processing behavior looks the same to the
        CE. Sometimes it is difficult to decide the granularity of the FE
        blocks. The general rule of thumb is that FE blocks should be coarse
        grained, stateful and focus on a particular domain.  Basically, if a
        logical function doesnÆt have anything to configure, doesnÆt keep
        any kind of inter-packet state information (tables, etc), then it
        probably is not a FE block. For example, CRC check and IP checksum
        are not considered to be FE blocks by themselves, instead should be
        part of an FE block (i.e. RFC 1812 IP forwarder).
        A well-defined block has a well-defined packet processing behavior,
        and a well-defined set of state and parameters that CE can
        potentially configure or control via ForCES.
        Obviously, a namespace is needed to specify different blocks. The
        namespace assigns a unique ID or label to each distinct block type.
        For each block, it is necessary to specify the relevant information
        and parameters such as:
     Yang, et. al.      Expires December 2002                    [Page 5]

     Internet Draft         ForCES FE Functional Model          June 2002
        - 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 and;
        - 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.).
        CEs later use the information to decide how to configure the
        parameters, how to modify the relevant data structures (like
        tables), what kind of statistics it can query from FE, and what
        actions to take once a certain event happens.
        We use the classifier defined in [DS-MODEL] as an example.
        "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 attributes relevant for classification)." Figure 1
        illustrates an example classifier.
              Unclassified              classified
              traffic                   traffic
                      |            |--> match Filter1 --> OutputA
              ------->| classifier |--> match Filter2 --> OutputB
                      |            |--> no match      --> OutputC
              Figure 1. An Example Classifier
     4.2.FE Block Library
        We expect a small set of blocks to be defined initially, e.g.,
        ingress port, egress port, classifier, forwarder, meter, marker,
        shaper, scheduler, queue, encapsulator, decapsulator, encrypter,
        decrypter, NAT, mux, demux, header compressor, header decompressor,
        etc. 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. It is also expected that the FE
        model itself be decoupled from the ForCES protocol so that extension
     Yang, et. al.      Expires December 2002                    [Page 6]

     Internet Draft         ForCES FE Functional Model          June 2002
        to basic blocks or changes to the existing  blocks  should not
        impact the protocol itself.
        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 achieve that.
     4.3. FE Stage
        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. So an FE stage is simply an instance of
        a FE block within an FE's datapath. Each FE allocates a FE-unique
        stage ID or label to each of its stages and passes the stage ID or
        label along with the corresponding block name as part of the FE
        model description. This allows multiple instances of the same block
        present in a FE's datapath.
        For each stage, the following information must be defined:
        - its FE-unique stage ID or label to identify, configure and manage
        the logical block of each by CE.;
        - the corresponding block name (from the namespace) that this stage
        - all the information for this stage as described in Section 5.1;
        - the number of downstream stages to which this stage can send
        - for each downstream stage: its stage ID or label.
     4.4. Directed Graph of FE Blocks
        Once a library of well-understood FE blocks is defined, and a stage
        is represented as described in 5.3, any static FE can be modeled by
        a directed graph interconnecting all the stages present in the FE.
        The static FEs can be defined by identifying all the input stage(s)
        and specifying each stage as described in Section 5.3. Figure 2
        shows one simple example of such an FE with three stages.
        To model a static FE, the following information needs to be
         - number of stages in the FE;
         - for each stage: define the stage using the model in 5.3;
         - identify the input stages
        It is frequently necessary to share state between FE functional
        stages in the forwarding plane. Since this model uses blocks as the
        basic way of modeling forwarding plane packet processing stages, the
        state information is exposed as part of connecting stage. For
        example in Figure 2, stage #2 (IPv4 L3 LPM Forwarder) generates some
        meta data 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.
     Yang, et. al.      Expires December 2002                    [Page 7]

     Internet Draft         ForCES FE Functional Model          June 2002
                      +------------+   +------------+   +------------+
               input  | Ethernet   |   |            |   | Ethernet   |output
              ------->| Ingress    |-->| IPv4 L3 LPM|-->| Egress     |----->
                      | Port Mgr   |   | Forwarder  |   | Port Mgr   |
                      +------------+   +------------+   +------------+
                     {stage ID=1,     {stage ID=2,      {stage ID=3,
                      function=        function=         function=
                        Enet-Ing-port,   IPv4-L3-LPM-fwd,  Enet-Eg-port-Mgr,
                      #downstream=1,   #downstream=1,    #downstream=1,
                      downstream={2}   downstream={3}    downstream=none
                     }                }                 }
                     Figure 2. A very simple example of a static FE.
                             +---+                    +--+
                             |  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 3. An FE example with multiple datapath.
        There might be more than one datapath within an FE, typically due to
        blocks that are either 1:N or N:1. Figure 3 shows one such FE block
        example (based on an example in [MD-MODEL]). This FE implements QoS
        functions via combination of one or multiple instances of logical
        functions like classifier, meter, marker, queue, scheduler, etc.
     Yang, et. al.      Expires December 2002                    [Page 8]

     Internet Draft         ForCES FE Functional Model          June 2002
        Some of the functions are 1:N (fan-out_ functions. For example, the
        stage labeled "Classifier1" is 1:4 function with four downstream
        stages, namely, Meter1, Queue2, Meter2, Queue4. A packet entering
        this FE can potentially take one of the six distinct datapath.
        Note that our stage representation can encode largely arbitrary
        topologies of the stages. 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 nay
        downstream stages whereas no other stage may refer to an ingress
        port function as one of its downstream stages.
        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 4 shows two
        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. Figure 4 shows such an example.
           |  +---------+   +------------+   +---------+         |
         input|         |   |            |   |         | output  |
        ---+->| Ingress |-->|Header      |-->|IPv4     |---------+--->--+
           |  | port    |   |Decompressor|   |Forwarder| FE      |    |
           |  +---------+   +------------+   +---------+ Block #1|    |
           ------------------------------------------------------|    V
                |    |-----------------------------------------
                V    |  +------------+   +----------+         |
                | input |            |   |          |  output |
                +->--+->|Header      |-->| Egress   |---------+-->
                     |  |Compressor  |   | port     | FE      |
                     |  +------------+   +----------+ Block #2|
        Figure 4. An example of two different FE blocks connected together.
     5. Model Representation
        A formal data definition language is needed to represent the FE
        model described in this document. The following is a list of some
        potential candidates. A suitable candidate needs to be chosen as the
        representation of FE model. However, we intend to leave this as an
        open issue and much debate is needed in the ForCES WG before a
     Yang, et. al.      Expires December 2002                    [Page 9]

     Internet Draft         ForCES FE Functional Model          June 2002
        decision 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]
        - SMIng (Next Generation Structure of Management Information)
        - UML (Universal Modeling Language)
        XML has the advantage of being human readable with relatively little
        effort. However, it is less efficient and requires XML parsing
        functions in the CE and FE. Currently XML is not widely deployed and
        used in network elements.
        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.
        SMIng is currently being developed by SMIng working group at IETF
        and represents a superset of SMIv2 and SPPI. The objective of SMIng
        is to replace both SMIv2 and SPPI with a single, updated language as
        the data definition language for the monitoring, configuration, and
        provisioning of network devices.
     6. Security Considerations
        The FE model just describes the representation and organization of
        data sets and attributes in the forwarding plane. There is no
        communication protocol associated defined as part of the FE model
        therefore we do not see any security threats in this model.
     7. Intellectual Property Right
        The authors are not aware of any intellectual property right issues
        pertaining to this document.
     8. IANA consideration
        If we are going to identify and name a new logical components we may
        need to standardize those components and the attributes.
     9. Normative References
        [RFC1812]  F. Baker, "Requirements for IP Version 4 Routers",
                   RFC1812, June 1995.
        [RFC1155] M. Rose, et. al., "Structure and Identification of
                   Management Informationfor TCP/IP-based Internets", May
     Yang, et. al.      Expires December 2002                    [Page 10]

     Internet Draft         ForCES FE Functional Model          June 2002
        [RFC3159] K. McCloghrie, et. al., "Structure of Policy Provisioning
                   Information (SPPI)", August 2001.
     10. Informative References
        [FORCES-REQ] T. Anderson, et. al., "Requirements for Separation of
                   IP Control and Forwarding", work in progress, April 2002,
        [GOPAL-MODEL] R. Gopal, "Forwarding Element Model", work in
                   progress, February 2002, <draft-gopal-forces-femodel-
        [ANDERSON-MODEL] T. Anderson, "ForCES Architectural Framework and FE
                   Functional Model", work in progress, November 2001,
        [DS-MODEL] Y. Bernet, et. al., "An Informal Management Model for
                   Diffserv Routers", work in progress, February 2001,
     11. Acknowledgments
        This document draws heavily from the concepts presented in [GOPAL-
        MODEL], [ANDERSON-MODEL] and [DS-MODEL]. In addition to the authors
        of these documents, the authors would also like to thank the
        following individuals for their invaluable technical input: David
        Putzolu, Hormuzd Khosravi, Eric Johnson, David Durham, Andrzej
     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,
     Yang, et. al.      Expires December 2002                    [Page 11]

     Internet Draft         ForCES FE Functional Model          June 2002
        Burlington, MA 01803
        Phone: +1 781 993 3685
        Email: ram.gopal@nokia.com
        Ram Dantu
        Netrake Corporation
        3000 Technology Drive
        Plano, Texas 75074
        Phone: +1 214 291 1111
        Email: ramd@netrake.com
        1. Abstract........................................................1
        2. Motivation and Requirements of FE model.........................2
        3. Capability and configuration Model versus State Model...........4
        4. FE Model........................................................5
           4.1. FE Blocks..................................................5
           4.2. FE Block Library...........................................6
           4.3. FE Stage...................................................7
           4.4. Directed Graph of FE Blocks................................7
        5. Model Representation............................................9
        6. Security Considerations........................................10
        7. Intellectual Property Right....................................10
        8. IANA consideration.............................................10
        9. Normative References...........................................10
        10. Informative References........................................11
        11. Acknowledgments...............................................11
        12. Authors' Addresses............................................11
     Yang, et. al.      Expires December 2002                    [Page 12]

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