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 Nokia A. DeKok IDT Inc. August 2003 ForCES Forwarding Element Functional Model draft-ietf-forces-model-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract 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 Abstract.........................................................1 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119]. 1. Definitions A set of terminology associated with the ForCES requirements is defined in [FORCES-REQ] and is not copied here. The following list of terminology is relevant to the FE model defined in this document. Datapath -- A conceptual path taken by packets within the forwarding plane, inside an FE. There might exist more than one datapath within an FE. Forwarding Element (FE) Block -- An abstraction of the basic packet processing logical functions in the datapath. It is the building 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 protocol. 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 mechanism. +-------+ +-------+ | | 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 hardware. +----------+ | 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 configurable; - what statistics it keeps (e.g., drop count, CRC error count, etc.); - 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 configuration. +-------------------------------------------+ | | +-----------+ | +-----------+ +--------+ | | | v | |if IP-in-IP | | | ---->| ingress |--------->|classifier |----------->|Decap. |-->+ | ports | | |----+ | | +-----------+ +-----------+ |others +--------+ | V (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 topology +-------+ +-----------+ +------+ +-----------+ | | | |if IP-in-IP | | | | --->|ingress|-->|classifier1|----------->|Decap.|-->+classifier2|-> | ports | | |----+ | | | | +-------+ +-----------+ |others +------+ +-----------+ | V (c) The FE block topology equivalent of (a) without the loop Figure 3. An FE block topology example with block instance tables. 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 topologies. 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 draft. 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 | | +----------+ +-----------+ | | v +-------------------------------------------+ | Network Processor | +--------+ | | <----| Egress | | +------+ +------+ +-------+ +---+ | +--------+ | |Meter | |Marker| |Dropper| |Mux| | ^ | +------+ +------+ +-------+ +---+ | | | | +----------+-------+ | | | | | +---------+ +---------+ +------+ +---------+ | | |Forwarder|<------|Scheduler|<--|Queue | |Counter | | | +---------+ +---------+ +------+ +---------+ | | | |--------------------------------------------------------------+ (a) The Capability of the FE, reported to the CE Queue1 +---+ +--+ | 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. scheduler (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}. *Notes: 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 elements: - 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 received); - 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 block. 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 data) 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 classification)ö. 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 ôclassificationsö. 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 contention. 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- REQ]. 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 paths. 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 applications. +-----------------------------------------------------+ | +---------+ +------------+ +---------+ | 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 implementations. XML has the advantage of being human and machine readable with widely available tools support. However, it is very verbose and hence less efficient for over-the-wire transport. It also requires XML parsing functions in both the CE and FE and hence may impose large footprint esp. for FEs. Currently XML is not yet widely deployed and used in network elements. XML for network configuration in general remains an open area that still requires substantial investigation and experiment in IETF. ASN.1 format is human readable and widely used in network protocols. SMI is based on a subset of ASN.1 and used to define Management Information Base (MIB) for SNMP. SPPI is the adapted subset of SMI used to define Policy Information Base (PIB) for COPS. Substantial investment has been made in SMI/MIBs/SNMP by IETF and the Internet community collectively has had many years of design and operation experience with SMI/MIBs/SNMP. However, it is also well recognized that SMI/MIBs/SNMP is not well suited for configuration and so SPPI/PIBs/COPS-PR attempts to optimize for network provisioning and 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 transport. 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 there. 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 1995. [RFC1155] M. Rose, et. al., ôStructure and Identification of Management Informationfor TCP/IP-based Internets", May 1990. [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, . 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, . 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, [IPSEC-MIB] C. Madson, et. al., ôIPsec Flow Monitoring MIBö, work in progress, March 2003, 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 Email: lily.l.yang@intel.com Joel M. Halpern Megisto Systems, Inc. 20251 Century Blvd. Germantown, MD 20874-1162, USA Phone: +1 301 444-1783 Email: jhalpern@megisto.com Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803, USA Phone: +1 781 993 3685 Email: ram.gopal@nokia.com 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 Email: alan.dekok@idt.com Yang, et al. Expires February 2004 [Page 36]