Internet Draft                                    L. Yang
    Expiration: February 2004                          Intel R&D
    File: draft-ietf-forces-model-00.txt              J. Halpern
    Working Group: ForCES                              Megisto Systems
                                                      R. Gopal
                                                      A. DeKok
                                                       IDT Inc.
                                                      August 2003
                 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,
    capacities, state and configuration 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 how these functions are
    or can be interconnected. The forwarding element model defined
    herein is intended to satisfy the requirements specified in the
 Internet Draft         ForCES FE Functional Model          August 2003
    ForCES requirements draft [FORCES-REQ].  Using this model,
    predefined or vendor specific logical functions can be expressed
    and configured. However, the definition of these individual
    functions are not described and defined in this document.
 Table of Contents
    1. Definitions...................................................3
    2. Motivation and Requirements of FE model.......................4
    3. State Model versus Capability Model...........................4
    4. FE Model Concepts: FE Block and FE Block Topology.............7
       4.1. FE Blocks................................................7
       4.2. FE Block Topology........................................9
          4.2.1. Configuring FE Block Topology......................11
          4.2.2. Modeling FE Block Topology.........................16
    5. Logical FE Block Library.....................................21
       5.1. FE Input/Output Block Characterization..................21
          5.1.1. Source Block.......................................21
          5.1.2. Sink Block.........................................22
          5.1.3. Port Block.........................................22
          5.1.4. Dropper Block......................................22
          5.1.5. MUX Block..........................................23
          5.1.6. Redirector (de-MUX) Block..........................23
          5.1.7. Shaper Block.......................................23
       5.2. FE Processing Blocks....................................23
          5.2.1. Counter Block......................................24
          5.2.2. Meter Block........................................24
          5.2.3. Filter Block.......................................24
          5.2.4. Classifier Block...................................24
          5.2.5. Redirecting Classifier Block.......................25
          5.2.6. Modifier Block.....................................25
          5.2.7. Packet Header Rewriter Block.......................26
          5.2.8. Packet Compression/Decompression Block.............26
          5.2.9. Packet Encryption/Decryption Block.................26
          5.2.10. Packet Encapsulation/Decapsulation Block..........26
    6. Minimal Set of Logical Functions Required for FE Model.......27
       6.1. QoS Functions...........................................27
          6.1.1. Classifier.........................................27
          6.1.2. Meter..............................................28
          6.1.3. Marker.............................................28
          6.1.4. Dropper............................................28
          6.1.5. Counter............................................28
          6.1.6. Queue and Scheduler (?)............................28
          6.1.7. Shaper.............................................28
       6.2. Generic Filtering Functions.............................28
       6.3. Vendor Specific Functions...............................29
 Yang, et al.      Expires February 2004                      [Page 2]

 Internet Draft         ForCES FE Functional Model          August 2003
       6.4. Port Functions..........................................29
       6.5. Forwarding Functions....................................29
       6.6. High-Touch Functions....................................30
       6.7. Security Functions......................................31
       6.8. Off-loaded Functions....................................31
    7. Cascading Multiple FEs.......................................31
    8. Data Modeling and Representation.............................32
    9. Security Considerations......................................33
    10. Intellectual Property Right.................................33
    11. IANA consideration..........................................34
    12. Normative References........................................34
    13. Informative References......................................34
    14. Acknowledgments.............................................35
    15. Authors' Addresses..........................................35
 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
    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
    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.
 Yang, et al.      Expires February 2004                      [Page 3]

 Internet Draft         ForCES FE Functional Model          August 2003
    FE Topology -- Representation of how the multiple FEs in a single
    NE are interconnected.  Sometimes it is called inter-FE topology,
    to be distinguished from intra-FE (block) topology.
    FE Block Topology -- Representation of how the FE stages are
    interconnected and placed along the datapath within one FE.
    Sometimes it is also called intra-FE topology, to be distinguished
    from inter-FE topology.
    Inter-FE Topology û See FE Topology.
    Intra-FE Topology û See FE Block Topology.
 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.     State Model versus Capability 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
 Yang, et al.      Expires February 2004                      [Page 4]

 Internet Draft         ForCES FE Functional Model          August 2003
    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 û an FE state model and FE
    capability model.
    An 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. For
    example, using an 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 FE capability model describes the
    configurable capabilities and capacities 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 with capacity information indicating certain
    quantitative limits or constraints.  For example, an FE capability
    model may describe the FE at a coarse 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 (capacity);
    - this FE can add and remove encapsulating headers of types
    including IPSec, GRE, L2TP.
    The information on the capabilities and capacities of the FE helps
    the CE understand the flexibility of the FE functions.  Where it
    gets more complicated is for the capability model to cope with the
    detailed limits, issues such as how many classifiers the FE can
    handle, how many queues, and how many buffer pools the FE can
    support, how many meters the FE can provide.
 Yang, et al.      Expires February 2004                      [Page 5]

 Internet Draft         ForCES FE Functional Model          August 2003
    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
    problem.  Such an approach is taken by RFC3318 in defining a set of
    Provisioning Classes (PRCs) for Framework Policy Information Base
    (PIB). For example, in Section 4.1 of RFC3318, a ôComponent
    Limitations Tableö is described so that ôthe PEP can report some
    limitations of attribute values and/or classes and possibly
    guidance values for the attributeö. Similar approach is also taken
    in Differentiated Services QoS Policy Information Base [RFC3317].
    The DiffServ QoS PIB includes capability reporting classes for
    individual devices, like classification capabilities, metering
    capabilities, etc. Two additional classes are also defined to allow
    specification of the element linkage capabilities of the PEP:  the
    dsIfElmDepthCaps PRC indicates the maximum number of functional
    datapath elements that can be linked consecutively in a datapath;
    while the dsIfElmLinkCaps PRC indicates what functional datapath
    elements may follow a specific type of element in a datapath.  Such
    capability reporting classes in the DiffServ and Framework PIB are
    all meant to allow the PEP to indicate some general guidelines
    about what the device can do.  They are intended to be an aid to
    the PDP when it constructs policy for the PEP.  These classes do
    not necessarily allow the PEP to indicate every possible
    configuration that it can or cannot support.  If a PEP receives a
    policy that it cannot implement, it must notify the PDP with a
    failure report.
    Figure 1 shows the concepts of FE state, capabilities, capacities
    and configuration in the context of CE-FE communication via ForCES
    It is clear to us that in the context of ForCES, a state model is
    definitely necessary but not sufficient.  A simple state model
    without any capability flavor will severely limit ForCESÆs ability
    to take advantage of the flexibility offered by programmable FEs.
    The question is how much of the capability model is needed in
    addition to the state model.  As we discussed previously, a
    detailed capability model is difficult to develop and may impose
    unnecessary overhead for those FEs that donÆt have much flexibility
    in their capability.  We believe that a good balance between
    simplicity and flexibility can be achieved for ForCES FE model by
    taking the similar approach as demonstrated by DiffServ
    PIB[RFC3317] and Framework PIB[RFC3318] û that is, by combining the
    coarse level capability reporting mechanism for both the individual
 Yang, et al.      Expires February 2004                      [Page 6]

 Internet Draft         ForCES FE Functional Model          August 2003
    FE functions and linkage constraints with the error reporting
         +-------+                                          +-------+
         |       | FE capabilities/capacity: what it can be.|       |
         |       |<-------------------------------------- --|       |
         |       |                                          |       |
         |   CE  | FE state: what it is now.                |  FE   |
         |       |<-----------------------------------------|       |
         |       |                                          |       |
         |       | FE configuration: what it should be.     |       |
         |       |----------------------------------------->|       |
         +-------+                                          +-------+
      Figure 1. Illustration of FE state, capabilities, capacities and
      configuration in the context of CE-FE communication via ForCES.
 4.     FE Model Concepts: FE Block and FE Block Topology
    Conceptually, the FE model presents two levels of information about
    the FE.  At the first level are the individual FE functions.  We
    call these individual FE functions FE blocks.  The second level of
    information that the FE model should present is about how these
    individual function are ordered and placed along the datapath to
    deliver a complete forwarding plane service.  The interconnection
    of the FE functions is called ôFE block topologyö.
 4.1. FE Blocks
    A new terminology ôFE Functional Blockö is used to refer to the
    individual FE functions that constitute the very basic units for FE
    models.  Each FE functional block performs a well-defined action or
    computation on the packets passing through it.  Upon completion of
    such function, either the packets are modified in certain ways
    (like decapsulator, marker), or some results are generated and
    stored, probably in the form of meta-data (like classifier).  Each
    FE Block typically does one thing and one thing only.  Classifiers,
    shapers, meters are all examples of FE blocks.  Modeling FE blocks
    at such fine granularity allows us to use a small number of FE
    blocks to create the higher-order FE functions (like Ipv4
    forwarder) precisely, which in turn can describe more complex
    networking functions and vendor implementations of software and
                                 |    CE    |
 Yang, et al.      Expires February 2004                      [Page 7]

 Internet Draft         ForCES FE Functional Model          August 2003
                                    |    ^
                                    |    |
                                    v    |
                     Inputs ---> | FE Block | ---> Outputs
                         (P,M)   |          |         (PÆ,MÆ)
                                 |    S     |
                      Figure 2. Generic FE Block Layout
    An FE Block has inputs, outputs, and a connection to and from the
    CE, as shown in Figure 2.  The horizontal axis is in the forwarding
    plane, and the vertical axis denotes interaction between the
    forwarding and control planes.  An FE block contains internal state
    S, composed of one or both CE->FE configuration; and data created
    and managed by the FE itself.  An FE Block also has one or more
    inputs, each of which takes a packet P, and optionally metadata M;
    and produces one or more outputs, each of which carries a packet
    PÆ, and optionally metadata MÆ.
    Meta-data is data which is associated with the packet in the
    network processing device (router, switch, etc), but which is not
    sent across the network.  CE to FE communication is for
    configuration, control and packet injection while FE to CE is for
    packet re-direction to the control plane, rmon, accounting
    information, errors, etc.
    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. A namespace is used to associate a unique name or
    ID with each type of FE block. The namespace must be extensible so
    that new logical functions can also be added later to accommodate
    future innovation in the forwarding plane.
    Based on this generic FE block, each FE logical function is defined
    with additional state and capability information pertinent to each
    specific function.  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;
 Yang, et al.      Expires February 2004                      [Page 8]

 Internet Draft         ForCES FE Functional Model          August 2003
    - 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.).
    These parameters are further described in Section 5, below.
 4.2. FE Block Topology
    Packets coming into the FE from ingress ports generally flow
    through multiple functional blocks before leaving out of the egress
    ports. Different packets (or packets from different flows) may take
    different datapath inside the same FE and hence perform different
    sequences of FE blocks. Such interconnection of the FE blocks as
    traversed by the packets is referred to as FE block topology.
    It is important to point out that the FE block topology here is the
    logical topology that the packets flow through, not the physical
    topology as determined by how the FE hardware is laid out. Figure
    3(a) shows part of the block topology of one simple FE example.
    Three ingress ports are present in the FE and these ports may be of
    different type with different characteristics.  If we model a
    single ingress port function as an FE block, clearly we need a way
    to model multiple instances of one FE block with each instance
    having separate set of parameters allowed for independent
                          |                                           |
         +-----------+    |     +-----------+            +--------+   |
         |           |    v     |           |if IP-in-IP |        |   |
    ---->| ingress   |--------->|classifier |----------->|Decap.  |-->+
         | ports     |          |           |----+       |        |
         +-----------+          +-----------+    |others +--------+
         (a)  The FE block topology example with a logical loop
     instance tables
           ingress port         classifier                Decapsulator
    +---+--------+--+   +---+--------+--+         +---+-----------+
    |id |IP Addr |à |   |id |#filters|à |         |id | à         |
    +---+--------+--+   +---+--------+--+         +---+-----------+
    |1  |x.x.x.x |à |   |1  |10      |à |         |1  | à         |
    +---+--------+--+   +---+--------+--+         +---+-----------+
 Yang, et al.      Expires February 2004                      [Page 9]

 Internet Draft         ForCES FE Functional Model          August 2003
    |2  |x.x.x.x |à |   |2  |10      |à |
    +---+--------+--+   +---+--------+--+
    |3  |x.x.x.x |à |
         (b)  The block instance tables used for such an FE block
        +-------+   +-----------+            +------+   +-----------+
        |       |   |           |if IP-in-IP |      |   |           |
        | ports |   |           |----+       |      |   |           |
        +-------+   +-----------+    |others +------+   +-----------+
         (c)  The FE block topology equivalent of (a) without the loop
         Figure 3. An FE block topology example with block instance
    Figure 3(a) also shows that it is possible for a packet to flow
    through a certain function more than once and hence create a
    logical loop in the FE block topology. For example, an IP-in-IP
    packet from an IPSec application like VPN may go to the classifier
    first and have the classification done based on the outer IP
    header; upon being classified as an IP-in-IP packet, the packet is
    then sent to a decapsulator to strip off the outer IP header,
    followed by the classifier again to perform classification on the
    inner IP header. It is clear from Figure 3(a) that such a logical
    loop is sometimes necessary and must be properly modeled in the FE
    block topology.
    To represent the FE block instances, we define an ôFE block
    instance tableö associated with each FE block û each row of the
    table corresponds to one instance of the block. An instance ID is
    needed to distinguish different instances of one block. Multiple
    instances of the same block can be configured independently with
    different parameters. Figure 3(b) shows the FE block instance
    tables for the FE block topology in (a). The instance table of the
    ingress ports has 3 rows because there are 3 ingress ports. The
    classifier block has two rows, one corresponding to the classifier
    instance after the ingress port, while the other row corresponding
    to the instance after the decapsulator. The decapsulator has only
    one row in its instance table since only one instance of
 Yang, et al.      Expires February 2004                      [Page 10]

 Internet Draft         ForCES FE Functional Model          August 2003
    decapsulator is used.  Each row in the instance table has its own
    parameters and so each instance can be configured independently.
    A way to model the logical loop to the classifier in Figure 3(a) is
    to treat it as if there are two different instances of classifier,
    as shown in Figure 3(c).
    While there is little doubt that the individual FE blocks must be
    configurable, the configurability question becomes complicated and
    controversial for FE block topology.  To discuss the issue further,
    we need to answer the following questions:
    1) Is the FE block topology configurable at all?  Is that feasible
       with todayÆs forwarding plane technology?  Even if the CE can
       dynamically configure an FE block topology, how can the CE
       interpret an arbitrary FE block topology and know what to do
       with it?
    2) If the FE block topology can be configured by the CE, how do we
       model the FE block topology?
    LetÆs discuss these questions in the rest of the section.
 4.2.1. Configuring FE Block Topology
    We believe that the FE block topology should be configurable with
    ForCES model because even todayÆs forwarding plane technology can
    potentially allow that. As network processors are being used
    increasingly in the forwarding plane, much of the packet processing
    functions on the FE is implemented in software.  As such, the FE
    can afford much flexibility and programmability of its
    functionality by configuring the software either at runtime or
    compile time.  It is conceivably feasible for the FE to change its
    FE block topology by recompiling the set of the software components
    and their chaining order along the datapath.  It might be possible
    to achieve some of the reconfiguration at runtime.  Therefore, we
    argue that it is necessary for ForCES to allow FE block topology
    configurable in its FE model since it is technically feasible.
    For example, a NAT-enabled router may have several line cards (FEs)
    that are capable of both NAT (Network Address Translator) functions
    and IPv4 Forwarding. Such an FE contain two FE blocks in it: NAT
    and IPv4 Forwarder.  Depends on where on the network this router is
    deployed, the network administrator may decide on different
    configuration for the CE to configure the FEs. If the router sits
    on the edge of a private address domain, the CE may want to
    configure the FEs to perform NAT first and IPv4 Forwarder later so
    that the forwarding is done with the correct address space. On the
    other hand, if the router sits inside the private address domain,
    the CE may want to configure the FEs to perform only the IPv4
 Yang, et al.      Expires February 2004                      [Page 11]

 Internet Draft         ForCES FE Functional Model          August 2003
    forwarding function and bypass the NAT because the address space is
    already translated by the edge router.  Therefore, the FEs might be
    asked to configure the NAT block as an optional stage in the FE
    topologies to accommodate the two deployment scenarios. This is a
    very simple example and the switch between these two topologies
    could be easily done with a runtime flag in the FE software.
    However simple as it is, it does demonstrate the need to allow for
    FE block topology configuration.
                 +-------------+         +--------------+
                 |             |         |              |
         ------->|    NAT      |-------->|IPv4 Forwarder|------>
                 |             |         |              |
                 +-------------+         +--------------+
         (a)  NAT followed by IPv4 Forwarder
                 +-------------+         +--------------+
                 |             |         |              |
         --->-+  |    NAT      |   +---->|IPv4 Forwarder|------>
              |  |             |   |     |              |
              |  +-------------+   |     +--------------+
              |                    |
         (b)  NAT is skipped and only the forwarder is used
              Figure 4. A simple example to configure different FE
    We want to point out that allowing configurable FE block topology
    in FE model does not mandate that all FEs must have such
    capability.  Even if the FE elects to support block topology
    reconfiguration, it is entirely up to the FE designers to decide
    how the FE actually implements such reconfiguration.  Whether it is
    only a simple runtime switch to allow a few choices like in Figure
    4, or a much more elaborate reconfiguration as shown later in
    Figure 5 possibly supported by recompilation is all implementation
    details internal to the FE but outside the scope of FE model.  The
    purpose of this discussion is to justify the motivation and
    necessity of supporting FE block topology configuration in the FE
    model, but not to dictate how this should be done inside the FEs.
    WeÆve just answered the questions of ôIs it possible to configure
    the FE block topology with todayÆs forwarding plane technologyö.
    Now it is time to look at the other related question: ôEven if it
    is feasible to configure an FE block topology, how can the CE
 Yang, et al.      Expires February 2004                      [Page 12]

 Internet Draft         ForCES FE Functional Model          August 2003
    interpret an arbitrary FE block topology (presented to it by the
    FE) and know what to do with it?  Alternatively, how does the CE
    know what kind of FE block topology it should use to implement a
    particular NE service or application?ö
    The example in Figure 4 is too trivial to require much intelligence
    at the CE.  Figure 5 shows a more comlex example where a QoS-
    enabled router has several line cards that have a few ingress ports
    and egress ports, a specialized classification chip, a network
    processor containing codes for FE blocks like meter, marker,
    dropper, counter, mux, queue, scheduler and Ipv4 forwarder. Some of
    the FE block topology is already fixed and has to remain static due
    to the physical layout of the line cards. For example, all the
    ingress ports might be already hard wired into the classification
    chip and so all packets must follow from the ingress port into the
    classification engine. On the other hand, the blocks on the network
    processor are programmable and the order of these blocks can be
    changed by recompilation of the codes. There might exist certain
    capacity limits and linkage constraints between these blocks.
    Examples of the capacity limits might be: there can be no more than
    8 meters; there can be no more than 16 queues in one FE; the
    scheduler can handle at most up to 16 queues; etc. The linkage
    constraints might dictate that classification engine may be
    followed by meter, marker, dropper, counter, queue or Ipv4
    forwarder, but not scheduler; queues can only be followed by
    scheduler; scheduler must be followed by the Ipv4 forwarder; the
    last block in the datapath before going into the egress ports must
    be the Ipv4 forwarder, etc.
    Once the FE reports such capability and capacity to the CE, it is
    now up to the CE to translate the QoS policy into the desirable
    configuration for the FE.  Now the question arises as to whether or
    not the CE has the ultimate intelligence to translate high level
    QoS policy into the configuration data for the FEs. We argue that
    this question is outside of the scope of FE model itself.  It is
    possible that some human intervention is still necessary.  For
    example, the network administrator might be called upon to
    translate the high level QoS policy into the configurable FE data
    (including the block topology) that the CE uses to configure the
    line cards.  It is also conceivable that within a given network
    service domain (like DiffServ), certain amount of intelligence can
    be programmed into the CE such that the CE has a general
    understanding of the FE blocks involved and so the translation from
    high level QoS policy to the low level FE configuration can be done
    automatically.  In any event, this is considered implementation
    issue internal to the control plane only and outside the scope of
 Yang, et al.      Expires February 2004                      [Page 13]

 Internet Draft         ForCES FE Functional Model          August 2003
    the FE model. Therefore, it is not discussed any further in this
    Figure 5(a) depicts the FE capability while 4(b) and 4(c) depict
    two different topologies that the FE might be asked to configure
    into. Note that both ingress and egress are omitted in (b) and (c)
    for simplicity in the figures. The topology in (b) is considerably
    more complex than (c) but both are feasible with the FE
    capabilities, and so the FE should accept either configuration
    request from the CE.
    As demonstrated in the example shown in Figure 5, many variants of
    the FE block topology come directly from the configuration of the
    individual FE blocks.  For example, the number of datapath branches
    from the classifier is determined by the number of filters used by
    the classifier. Figure 5(b) uses four filters so there are four
    main datapath branches fan out from the classifier while 4(c) uses
    only two filters resulting two datapath fan-out. Each datapath is
    further configured by configuring the FE blocks along the path.
         +----------+     +-----------+
         |          |     |           |
    ---->| Ingress  |---->|classifier |--------------+
         |          |     |chip       |              |
         +----------+     +-----------+              |
                         |   Network Processor                       |
           +--------+    |                                           |
      <----| Egress |    |   +------+    +------+   +-------+  +---+ |
           +--------+    |   |Meter |    |Marker|   |Dropper|  |Mux| |
                 ^       |   +------+    +------+   +-------+  +---+ |
                 |       |                                           |
      +----------+-------+                                           |
      |          |                                                   |
      |    +---------+       +---------+   +------+    +---------+   |
      |    |Forwarder|<------|Scheduler|<--|Queue |    |Counter  |   |
      |    +---------+       +---------+   +------+    +---------+   |
      |                                                              |
                 (a)  The Capability of the FE, reported to the CE
                       +---+                    +--+
                       |  A|------------------->|  |--+
 Yang, et al.      Expires February 2004                      [Page 14]

 Internet Draft         ForCES FE Functional Model          August 2003
                    +->|   |                    |  |  |
                    |  |  B|--+  +--+   +--+    +--+  |
                    |  +---+  |  |  |   |  |          |
                    | Meter1  +->|  |-->|  |          |
                    |            |  |   |  |          |
                    |            +--+   +--+          |          Ipv4
                    |         Counter1 Dropper1 Queue2|    +--+  Fwd.
            +---+   |                           +--+  +--->|A |  +-+
            |  A|---+                           |  |------>|B |  | |
     ------>|  B|------------------------------>|  |  +--->|C |->| |->
            |  C|---+                           +--+  | +->|D |  | |
            |  D|-+ |                                 | |  +--+  +-+
            +---+ | |    +---+             +---+  Queue3| | Scheduler
        Classifier1 | |  |  A|------------>|A  |  +--+  | |
                    | +->|   |             |   |->|  |--+ |
                    |    |  B|--+  +--+ +->|B  |  |  |    |
                    |    +---+  |  |  | |  +---+  +--+    |
                    |  Meter2   +->|  |-+  Mux1           |
                    |              |  |                   |
                    |              +--+           Queue4  |
                    |            Marker1          +--+    |
                    +---------------------------->|  |----+
                                                  |  |
                 (b)  One FE block topology as configured by the CE and
                      accepted by the FE
           +-----+    +-------+                      +---+
           |    A|--->|Queue1 |--------------------->|   |
    ------>|     |    +-------+                      |   |  +---+
           |     |                                   |   |  |   |
           |     |    +-------+      +-------+       |   |  |   |
           |    B|--->|Meter1 |----->|Queue2 |------>|   |->|   |
           |     |    |       |      +-------+       |   |  |   |
           |     |    |       |--+                   |   |  |   |
           +-----+    +-------+  |   +-------+       |   |  +---+
         classifier              +-->|Dropper|       |   |  IPv4
                                     +-------+       +---+  Fwd.
                 (c)  Another FE block topology as configured by the CE
                      and accepted by the FE
         Figure 5. Another example of configuring FE block topology.
 Yang, et al.      Expires February 2004                      [Page 15]

 Internet Draft         ForCES FE Functional Model          August 2003
 4.2.2. Modeling FE Block Topology
    Now that weÆve seen some examples of how FE block topology can be
    configured, we need to focus on the question as how to model the FE
    block topology traversed by the packets.  As discussed below, there
    exist two different approaches in modeling the FE block topology.
    . Directed Graph Topological Approach
    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.  So an FE stage is
    simply a row in the ôFE block instance tablesö corresponding to the
    block type of the stage.  Each FE allocates an FE-unique stage ID
    to each of its stages.  One way to assign the stage ID is to
    combine both the block-type namespace and the instance ID in the
    instance table.
    The FE block topology can then be modeled by a directed graph
    interconnecting all the FE stages present in the FE, with each node
    in the graph corresponding to an FE stage, and the direction
    between two nodes coinciding with the packet flow direction. In
    order to represent the directed interconnection between two
    consecutive nodes along a datapath, each stage contains a field
    called ônumber of downstream stagesö and an array of ôdownstream
    stage IDsö that point to the set of downstream nodes following this
    stage.  Such a modeling approach directly models the datapath
    topological graph of the FE stages and so we refer to it as the
    directed graph topological approach.
    For such a directed graph topological approach, the following
    information needs to be specified for each FE stage in the graph:
    - stage identifier which uniquely identifies the node within this
    FE graph;
    - 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.
    Such information can be combined into the rows of the ôFE block
    instance tableö for each FE block type present on the FE.  With
 Yang, et al.      Expires February 2004                      [Page 16]

 Internet Draft         ForCES FE Functional Model          August 2003
    such information defined for each row in the instance table, it is
    now possible to traverse the whole graph in a node-by-node fashion
    following the linked list, as long as the initial stage(s) are
    known.  For example, the topology model for Figure 5(c) is shown in
    Figure 6.  It is assumed that the FE has four ingress ports and two
    egress ports.  The stage id is assigned to have the format of
    ôxx.yyö where xx being the block type name while yy being the
    instance id of that stage in the instance table of type xx.  The
    following shorthand are used for FE block type namespace:
    IG=Ingress-port; CL=classifier; EG=egress-port; QU=queue; MT=meter;
    DR=dropper; SC=scheduler; and FW=Forwarder.
    In Figure 6, by starting from the initial stages of {IG.1; IG.2;
    IG.3; IG.4} and using the instance tables, all the datapath in the
    FE block topology can be easily traversed. From this example, it is
    clear that directed graph topological approach is straightforward
    and graphical, and hence easy to understand and implement. DiffServ
    [RFC3317] uses this approach in modeling its QoS functions and
    their interconnection.  However, such approach has certain
    limitations. One of the limitations is that there exists an
    implicit assumption within such a model that each node affects the
    datapath branching only for the next immediate stage. For example,
    in Figure 5(c), the classifier directs packets into either queue1
    or meter1, but once the packets enter meter1, the classification
    results have no impact on which of the two branches leaving meter1
    (i.e., queue2 or dropper) is being taken. While this limitation
    might be perfectly reasonable for many FE designs, some find it
    insufficient. For example, some of the classification engine uses
    the classification results to determine the full datapath, i.e.,
    not just the immediate stage following the classifier, but
    including all the following FE stages the packets should perform.
    It is difficult to represent such FE design using the pure directed
    graph topological approach.  An alternative approach, encoded state
    approach, is more suitable in this case because it carries meta-
    data between the stages.
    Instance tables:
     IG                 CL                      QU
    +---+-----+----+   +---+-----+---------+   +---+-----+----+
    |id |#next|next|   |id |#next|next     |   |id |#next|next|
    +---+-----+----+   +---+-----+---------+   +---+-----+----+
    |1  | 1   |CL.1|   |1  |2    |QU.1;MT.1|   |1  |1    |SC.1|
    +---+-----+----+   +---+-----+---------+   +---+-----+----+
    |2  | 1   |CL.1|                           |2  |1    |SC.1|
    +---+-----+----+                           +---+-----+----+
    |3  | 1   |CL.1|
 Yang, et al.      Expires February 2004                      [Page 17]

 Internet Draft         ForCES FE Functional Model          August 2003
    |4  | 1   |CL.1|
     DR                  MT                      EG
    +---+-----+----+   +---+-----+---------+   +---+-----+----+
    |id |#next|next|   |id |#next|next     |   |id |#next|next|
    +---+-----+----+   +---+-----+---------+   +---+-----+----+
    |1  | 0   |    |   |1  |2    |QU.2;DR.1|   |1  |0    |    |
    +---+-----+----+   +---+-----+---------+   +---+-----+----+
                                               |2  |0    |    |
     SC                  FW
    +---+-----+----+   +---+-----+---------+
    |id |#next|next|   |id |#next|next     |
    +---+-----+----+   +---+-----+---------+
    |1  | 1   |FW.1|   |1  |2    |EG.1;EG.2|
    +---+-----+----+   +---+-----+---------+
    Directed Graph:
    Traverse the graph by starting from {IG.1;IG.2;IG.3;IG.4}.
    1) The fields shown in the instance tables are only the fields
       common to all: id (instance ID); #next (number of immediate next
       stages); next (the instance IDs of all the immediate next
       stages). The parameters pertinent to each block type are not
       shown in the instance tables because they do not affect the
       topology modeling.
    2) The stage id is assigned to have the format of ôxx.yyö where xx
       being the block type name while yy being the instance id of that
       stage in the instance table of type xx.
    3) The following shorthand are used for FE block type namespace:
       IG=Ingress-port; CL=classifier; EG=egress-port; QU=queue;
       MT=meter; DR=dropper; SC=scheduler; and FW=Forwarder.
         Figure 6. Using the directed graph approach to model the FE
    block topology in Figure 5(c).
    . Encoded State Approach
    In addition to the topological approach, the QDDIM model also
    adopts the encoded state approach so that information about the
 Yang, et al.      Expires February 2004                      [Page 18]

 Internet Draft         ForCES FE Functional Model          August 2003
    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.
             |     Meter-A    |
             |                |
       ----->|            In -|-----PM-1--->
             |                |
             |           Out -|-----PM-2--->
            Figure 7:  Meter Followed by Two Preamble Markers
    Figure 7 shows an example used in [QDDIM] (section 3.8.3) in which
    meter results are captured in a packet preamble. ôPreamberMarker
    PM-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.ö
    In the example of Figure 5(c), if the results from classifier are
    to impact all the following stages, even beyond the immediate next
    stage, encoded state approach should be used so that meta-data is
    inserted representing the results from classifier and is made
    available to all following stages.
               +------------+   +------------+   +------------+
        input  | Ethernet   |   |            |   | Ethernet   |output
       ------->| Ingress    |-->| IPv4 L3 LPM|-->| Egress     |---->
               | Port Mgr   |   | Forwarder  |   | Port Mgr   |
               +------------+   +------------+   +------------+
                      (a) using encoded state approach
         Input  +------------+   +------------+                 output
        ------->|Ingr-Port #1|-->|            |
                +------------+   |            |   +------------+
        ------->|Ingr-Port #2|-->|            |-->|EgressPort#1|----->
 Yang, et al.      Expires February 2004                      [Page 19]

 Internet Draft         ForCES FE Functional Model          August 2003
                +------------+   |            |   +------------+
        ------->|Ingr-Port #3|-->|IPv4 L3 LPM |-->|EgressPort#2|----->
                +------------+   |Forwarder   |   +------------+
        ------->|Ingr-Port #4|-->|            |-->|EgressPort#3|----->
                +------------+   |            |   +------------+
        ------->|Ingr-Port #5|-->|            |-->|EgressPort#4|----->
                +------------+   |            |   +------------+
        ------->|Ingr-Port #6|-->|            |
                +------------+   +------------+
               (b) using directed graph topological approach
         Figure 8. A simple example using two different approaches.
    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,
    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 8(a), 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
    8(b) shows how the FE graph looks like when using the pure
    topological approach instead, assuming six ingress and four egress
    ports. It is clear that (b) is unwieldy compared to (a).
    Note that the FE graph can represent largely arbitrary topologies
    of the stages, regardless which approach (topological or encoded
    state) is taken.  Clearly the two approaches are not exclusive.
    For complex topologies, a combination of the two is most useful and
    flexible. Therefore, we recommend that the ForCES FE model adopt
    both approaches.  More specifically, the directed graph topological
    approach should be used as the basic model, while the encoded state
    approach can be used as optional, when meta-data is needed between
    stages beyond the immediate next neighbors.
 Yang, et al.      Expires February 2004                      [Page 20]

 Internet Draft         ForCES FE Functional Model          August 2003
 5.     Logical FE Block Library
    A small set of fine-grained FE blocks can be identified as the very
    basic units from which all other FE functions can be built upon.
    Such a set of FE blocks can be viewed as a FE block library.  This
    section defines such a library.
    Several working groups in the IETF have already done some relevant
    work in modeling the provisioning policy data for some of the
    functions we are interested in, for example, DiffServ
    (Differentiated Services) PIB [RFC3317], IPSec PIB [IPSEC-PIB].
    Whenever possible, we should try to reuse the work done elsewhere
    instead of reinventing the wheel.
    FE blocks may be characterized into two general classes:
    input/output oriented blocks, and processing blocks.  Each class is
    composed of a number of sub-blocks, and the combination of classes
    and sub-blocks can completely characterize FE functions.
    The FE input/output blocks are characterized by their inputs and
    outputs, and they generally do not modify or further process the
    data that they handle.  The FE processing blocks are characterized
    by the manner in which they modify the packet, metadata, or
    internal state, independent of how that information is input into
    the block.
 5.1. FE Input/Output Block Characterization
    The FE input/output blocks are characterized by the following
            - number of inputs
            - number of outputs
    These blocks do not modify or examine the packet in any way.
 5.1.1. Source Block
    A source block has no inputs, and one output.  It ôsourcesö events
    from the external world into the FE model.
    The purpose of the source block is to allow the model to explicitly
    interact with objects that are outside of the model.  That is, an
    Ethernert port that injects packets into the FE may be modeled as a
    ôsourceö block, as from the point of view of the model, it creates
 Yang, et al.      Expires February 2004                      [Page 21]

 Internet Draft         ForCES FE Functional Model          August 2003
    packets out of the ôetherö, and outside of the scope of the model.
    See also the FE Port block below, in Section 5.1.3.
 5.1.2. Sink Block
    A sink block has one input, and no outputs.  It ôsinksö events from
    the FE model into the external world.
    The purpose of the sink block is to allow the model to explicitly
    interact with objects that are outside of the model.  That is, and
    Ethernet port that sends packets from an FE may be modeled as a
    ôsinkö block, as from the point of view of the model, it sends
    packets into the ôetherö, and outside of the scope of the model.
    See also the FE Port block below, in Section 5.1.3.
 5.1.3. Port Block
    An FE Port Block is used to describe specific sinks or sources.  An
    FE Source Block may source events other than packets, such as TCP
    timers.  An FE Source block may also not require complex
    configuration.  In addition, the model should be able to map both
    sources and sinks onto one logical block which models a port that
    implements those functions.  For these reasons, it is useful to
    define a Port Block separately from the previously defined Source
    and Sink blocks, even though there is some overlap between them.
    The FE Port Block contains a number of configurable parameters,
    which may include, but are not limited to, the following items:
    - 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).
 5.1.4. Dropper Block
    A dropper block has one input, and no outputs.  It discards all
    packets that it receives without any modification or examination of
    those packets.
 Yang, et al.      Expires February 2004                      [Page 22]

 Internet Draft         ForCES FE Functional Model          August 2003
    The purpose of a dropper block is to allow the description of
    ôsinksö within the model, where those sinks do not result in the
    packet being sent into any object external to the model.
 5.1.5. MUX Block
    A mux block has N inputs, and one output.  It multiplexes packets
    from the inputs onto its output.
 5.1.6. Redirector (de-MUX) Block
    A redirector block has one input, and N outputs.  It is the inverse
    a MUX block.
    The redirector block takes an input packet P, and uses the metadata
    M to redirect that packet to one or more of N outputs, e.g. Most
    commonly unicast forwarding, multicast, or broadcast.
 5.1.7. Shaper Block
    A shaper block has one input, and one output.  It takes input
    packets and metadata at some time t, and outputs the packet and
    (possibly updated) metadata at some other time, tÆ.  The packet is
    not examined or modified during this process.
    The meta-data is used to determine how to shape the outgoing
    traffic.  The packet and metadata are conceptually added to the
    internal state S of the block when the packet is received, and are
    removed from that internal state when the packet is output from the
 5.2. FE Processing Blocks
    An FE processing block may be characterized by four parameters:
         P û the packet that it is processing
         t û the time at which that packet is being processed
         M û the metadata that is associated with that packet
         S û the internal state of the block
            (including any CE->FE configuration, and any internal FE
 Yang, et al.      Expires February 2004                      [Page 23]

 Internet Draft         ForCES FE Functional Model          August 2003
    We do not model or describe how any of these parameters arrive at
    the block.  Instead, we characterize the blocks by how they process
    those parameters.
 5.2.1. Counter Block
    A counter block updates its internal state S, by counting packets,
    or metadata.  The packet is not modified, and the metadata may, or
    may not, be modified.
    A counter block is independent of time ætÆ, in that it does not
    perform any time-dependent counting.  The time at which a count is
    made may, however, be associated with that count.
 5.2.2. Meter Block
    A meter block is a counter block that is time dependent.  That is,
    it meters the rate over time at which packets or metadata flow
    through the block.
 5.2.3. Filter Block
    According to [DiffServ], "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
    That is, a filter block examines the packet without modifying it,
    and uses its internal state S to make decisions about the packet.
    The result of that examination is that the filter block creates new
    metadata ômatchö, or ôno matchö to associate with that packet,
    depending on whether the packet matched, or did not match, the
    conditions of the filter.
    A filter block may be viewed as a special case of a classifier
    block.  Alternately, a classifier block may be viewed as consisting
    of multiple filter blocks.
 5.2.4. Classifier Block
    A classifier block uses its internal state S to classify the packet
    into one of N different logical classes.  That is, it takes an
    input packet and meta-data, and produces the same packet with new
    or more meta-data.  A classifier is parameterized by filters.
    Classification is done by matching the contents of the incoming
    packets according to the filters, and the result of classification
    is produced in the form of metadata.  Note that this classifier is
 Yang, et al.      Expires February 2004                      [Page 24]

 Internet Draft         ForCES FE Functional Model          August 2003
    modeled solely based on its internal processing, and not on its
    inputs and outputs.  It is a single-exit classifier that does NOT
    physically redirect the packet.  In contrast, a DiffServ-like
    classifier is a 1:N (fan-out) device: It takes a single traffic
    stream as input and generate N logically separate traffic streams
    as output.  That kind of multi-exit classifier can be modeled by
    combining this classifier with a redirector (see Section 5.1.5).
    Note that other FE Blocks MAY perform simple classification on the
    packet or metadata.  The purpose of the FE Classifier Block is to
    model a block that ôdigestsö large amounts of input data (packet,
    metadata), to produce a ôsummaryö of the classification results, in
    the form of additional metadata. Other FE Blocks can then use this
    summary information to quickly and simply perform trivial
    The requirement for a unique and separate FE Classifier Block comes
    about because it would not make sense to model a classifier block
    inside each of every other block.  Such a model would be highly
    redundant.  We therefore specifically model a complex
    classification block, and explicitly state that other blocks may
    make decisions based on the parameters S, t, and M, but not on P.
 5.2.5. Redirecting Classifier Block
    This block is logically a combination of the FE Classifier Block in
    Section 5.2.4, and the FE Redirector Block in Section 5.1.6.  It
    uses its internal classification rules to redirect the input packet
    P to one or more outputs.
    Its purpose is to allow the ôatomicö modeling of classification
    with redirection.  If this block was described as two blocks, then
    the model would be required to describe the format and
    interpretation of the metadata.  As there is not yet consensus on
    the format and interpretation of metadata, it is preferable to
    define an additional block which allows us to avoid most of that
    It is expected that once there is experience with using the FE
    model and blocks defined here, that we may reach consensus on the
    format and interpretation of the metadata.  At that time, we may
    revisit the definition of this block, and may choose to remove it
    due to redundancy with previously defined blocks.
 5.2.6. Modifier Block
 Yang, et al.      Expires February 2004                      [Page 25]

 Internet Draft         ForCES FE Functional Model          August 2003
    A modifier block modifies incoming packets and sends them out. This
    is a generic ôcatch-allö block for packet processing which is not
    modeled in one of the other blocks.  Usually the meta-data is used
    to determine how to modify the packet.
    This block is defined in a generic manner, and we expect that
    specific examples of packet and/or metadata modification will be
    described as below, with named sub-classes of the modifier block.
 5.2.7. Packet Header Rewriter Block
    This block is a sub-class of the Modifier Block.  It is used to re-
    write fields on the packet header, such as Ipv4 TTL decrementing,
    checksum calculation, or TCP/IP NAT.
 5.2.8. Packet Compression/Decompression Block
    This block is a sub-class of the Modifier Block.  It is used to
    compress or decompress packet data, such as with Ipv4 Van Jacobson
    header compression.
    It may be useful to split this block into separate compression and
    decompression blocks.  This decision should be made after we have
    more experience with the model.
 5.2.9. Packet Encryption/Decryption Block
    This block is a sub-class of the Modifier Block.  It is used to
    encrypt or decrypt packet data, such as with TLS.
    It may be useful to split this block into separate encryption and
    decryption blocks.  This decision should be made after we have more
    experience with the model.
 5.2.10. Packet Encapsulation/Decapsulation Block
    This block is a sub-class of the Modifier Block.  It is used to
    encapsulate or decapsulate packet data, such as with IP in IP.
    It may be useful to split this block into separate encapsulation
    and decapsulation blocks.  This decision should be made after we
    have more experience with the model.
 Yang, et al.      Expires February 2004                      [Page 26]

 Internet Draft         ForCES FE Functional Model          August 2003
 6.     Minimal Set of Logical Functions Required for FE Model
    A minimum set of FE functions is defined in [FORCES-REQ] that must
    be supported by any proposed FE model.  In this section, we
    demonstrate how the small FE block library defined in Section 5 can
    be used to model all the logical functions required in [FORCES-
 6.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) [RFC3317] 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. 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.
    Here is a list of QoS functional blocks that should be supported
    directly in the library or indirectly via combination of the FE
    blocks in the library:
       . Classifier
       . Meter
       . Marker
       . Dropper
       . Counter
       . Queue and Scheduler
       . Shaper
 6.1.1. Classifier
    There are two ways to define a classifier block: single-exit
    classifier or multi-exit classifier.
 Yang, et al.      Expires February 2004                      [Page 27]

 Internet Draft         ForCES FE Functional Model          August 2003
    A single-exit classifier follows the QDDIM model. It takes an input
    packet and meta-data, and produces the same packet, with new/more
    meta-data.  Such a single-exit classifier does not physically
    redirect the packets.  It only decides which meta-data to associate
    with the packet and such meta-data can be used by later blocks to
    physically redirect the packets.
    A multi-exit classifier, on the other hand, follows the DiffServ
    model.  It is equivalent of a single-exit classifier followed by a
    redirector.  Such a classifier directs packets to different output
 6.1.2.  Meter
    Meter is directly defined in the FE Block library.
 6.1.3. Marker
    Marker can be modeled as a special kind of FE Modifier Block.
 6.1.4. Dropper
    Dropper is directly defined in the FE Block library.
 6.1.5. Counter
    Counter is directly defined in the FE Block library.
 6.1.6. Queue and Scheduler (?)
 6.1.7. Shaper
    Shaper is directly defined in the FE Block library.
 6.2. Generic Filtering Functions
    A combination of classifier, redirector, modifier etc. can model
    complex set of filtering functions. For example, Figure 9
    represents a filtering function that classifies packets into one of
    two logical classes: forward, and drop.  These logical classes are
    represented as meta data M1, and M2.  The re-director uses this
    meta data to re-direct the packet to one of two outputs.  The first
    sinks the packet back into the network.  The second silently drops
    the packets.
                 classifier -> redirector  ---M1---  sink
 Yang, et al.      Expires February 2004                      [Page 28]

 Internet Draft         ForCES FE Functional Model          August 2003
                                            \-M2---  dropper
                  Figure 9. A filtering function example.
 6.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.
 6.4. Port Functions
    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.  Same model
    should be used for both the inter-FE and intra-FE interfaces, but
    it is necessary to make the distinction between the two known to
    the CE so that the CE can do different configuration.
    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 6.6.
 6.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
 Yang, et al.      Expires February 2004                      [Page 29]

 Internet Draft         ForCES FE Functional Model          August 2003
    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.
    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 approach of using
    the fine-grained FE blocks to model the forwarding functions allow
    such flexibility.
    For example, a combination of a classifier, followed by a modifier
    and a redirector can model the forwarding function.
 6.6. High-Touch Functions
    High-touch functions are those that take action on the contents or
    headers of a packet based on content other than what is found in
    the IP header.  Examples of such functions include NAT, ALG,
    firewall, tunneling and L7 content recognition.
    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. Here is a list of
    candidate blocks:
       . NAT
       . Firewall
 Yang, et al.      Expires February 2004                      [Page 30]

 Internet Draft         ForCES FE Functional Model          August 2003
       . Encapsulator
       . Decapsulator
    NAT, Encapsulator, Decapsulator are all different examples of the
    modifier FE block; while firewall can be modeled as a filtering
    function (Section 6.2).
 6.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. In general, encyption and decryption
    can be modeled by modifier.
    IP Security Policy (IPSP) Working Group in the IETF has started
    work in defining the IPSec Policy Information Base [IPSEC-PIB].
    Further study on this is needed to determine whether it can be
    reused here and any other additional work is needed.
 6.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.
 7.     Cascading Multiple FEs
    An FE may contain zero, one or more external ingress ports.
    Similarly, an FE may contain zero, one or more external egress
    ports.  In another word, not every FE has to contain any external
    ingress or egress interfaces.  For example, Figure 10 shows two
    cascading FEs.  FE #1 contains one external ingress interface but
    no external egress interface, while FE #2 contains one external
    egress interface but no ingress interfce.  It is possible to
    connect these two FEs together via their internal interfaces to
    achieve the complete ingress-to-egress packet processing function.
 Yang, et al.      Expires February 2004                      [Page 31]

 Internet Draft         ForCES FE Functional Model          August 2003
    This provides the flexibility to spread the functions across
    multiple FEs and interconnect them together later for certain
       |  +---------+   +------------+   +---------+         |
     input|         |   |            |   |         | output  |
    ---+->| Ingress |-->|Header      |-->|IPv4     |---------+--->+
       |  | port    |   |Decompressor|   |Forwarder| FE      |    |
       |  +---------+   +------------+   +---------+ #1      |    |
       +-----------------------------------------------------+    V
            |    +----------------------------------------+
            V    |  +------------+   +----------+         |
            | input |            |   |          |  output |
            +->--+->|Header      |-->| Egress   |---------+-->
                 |  |Compressor  |   | port     | FE      |
                 |  +------------+   +----------+ #2      |
    Figure 10. An example of two different FEs connected together.
    While inter-FE communication protocol is out of scope for ForCES,
    it is up to the CE to query and understand the FE function and
    inter-FE topology for multiple FEs and cascade them together when
    necessary to perform a complete ingress-egress packet processing
    function, like described in Figure 10.
 8.     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
    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)
 Yang, et al.      Expires February 2004                      [Page 32]

 Internet Draft         ForCES FE Functional Model          August 2003
    - 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
    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 configuration.
    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
 9.     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
 10.      Intellectual Property Right
 Yang, et al.      Expires February 2004                      [Page 33]

 Internet Draft         ForCES FE Functional Model          August 2003
    The authors are not aware of any intellectual property right issues
    pertaining to this document.
 11.      IANA consideration
    A namespace is needed to uniquely identify the FE block type for
    each FE logical function.
 12.      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.
 [FORCES-REQ] H. Khosravi, et. al., ôRequirements for Separation of IP
 Control and Forwarding", work in progress, May 2003, <draft-ietf-
 13.      Informative References
    [RFC3317] K. Chan, et. al., ôDifferentiated Services Quality of
                Service Policy Information Baseö, March 2003.
    [RFC3318] R.Sahita, et. al., ôFramework Policy Information Baseö,
                RFC 3318, March 2003.
    [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-
 Yang, et al.      Expires February 2004                      [Page 34]

 Internet Draft         ForCES FE Functional Model          August 2003
    [QPIM] Y. Snir, et. al., ôPolicy Framework QoS Information Modelö,
                work in progress, Nov 2001, <draft-ietf-policy-qos-
    [IPSEC-PIB] Man. Li, et. al., öIPsec Policy Information Baseö, work
                in progress, January 2003, <draft-ietf-ipsp-ipsecpib-
    [IPSEC-MIB] C. Madson, et. al., ôIPsec Flow Monitoring MIBö, work
                in progress, March 2003, <draft-ietf-ipsec-flow-
 14.      Acknowledgments
    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, Jamal
    Hadi, Alex Audu.
 15.      Authors' Addresses
    Lily L. Yang
    Intel Labs
    2111 NE 25th Avenue
    Hillsboro, OR 97124, USA
    Phone: +1 503 264 8813
    Joel M. Halpern
    Megisto Systems, Inc.
    20251 Century Blvd.
    Germantown, MD 20874-1162, USA
    Phone: +1 301 444-1783
    Ram Gopal
    Nokia Research Center
    5, Wayside Road,
    Burlington, MA 01803, USA
    Phone: +1 781 993 3685
    Alan DeKok
    IDT Inc.
    1575 Carling Ave.
 Yang, et al.      Expires February 2004                      [Page 35]

 Internet Draft         ForCES FE Functional Model          August 2003
    Ottawa, ON K1G 0T3, Canada
    Phone: +1 613 724 6004 ext. 231
 Yang, et al.      Expires February 2004                      [Page 36]