Internet Draft Ram Gopal Expiration: August 2002 Nokia File: draft-gopal-forces-eemodel-00.txt February 2002 Working Group: ForCES Forwarding Element Model draft-gopal-forces-femodel-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. 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 [2]. Abstract This document describes a model for the Forwarding Element (FE) Forces protocol endpoint. This model represents all the logical components, which are responsible for providing per-hop behavior inside a network element. This document also describes the MIB for the FE model, which can be used to communicate between Forwarding and Control Elements. Gopal Expires August 2002 [Page 1]
Internet Draft Forwarding Element Model February 2002 Table of Content 1. Definitions.....................................................2 2. Introduction....................................................4 3. FE Model........................................................4 3.1.1. Functional aspects of Forwarding plane components...........5 3.2. Classification based on the treatment.........................5 3.3. Placement and ordering of logical components in FE............6 3.4. FE Model relationship.........................................8 3.5. Representation................................................9 3.5.1. Logical organization of Table..............................10 3.5.2. Example of Logical Component Description...................12 3.6. FE model MIB Definition (ASN.1)..............................13 4. References.....................................................13 5. Acknowledgments................................................14 6. Authors' Addresses.............................................14 1. Definitions FE endpoint - Termination of Forces protocol at a FE CE endpoint - Termination of Forces protocol at a CE The following definitions are taken from [3] Classifier - an entity which selects packets based on the content of packet headers according to defined rules. Dropper - a device that performs dropping. Dropping - the process of discarding packets based on specified rules; policing. Marker - a device that performs marking. Marking- the process of setting the DS codepoint in a packet based on defined rules; pre-marking, re-marking. Meter - a device that performs metering. Metering - the process of measuring the temporal properties (e.g., rate) of a traffic stream selected by a classifier. The instantaneous state of this process may be used to affect the operation of a marker, shaper, or dropper, and/or may be used for accounting and measurement purposes. The following definitions are taken from [4] Gopal Expires August 2002 [Page 2]
Internet Draft Forwarding Element Model February 2002 Forwarding Element (FE) - A logical entity that implements the ForCES protocol. FEs use the underlying hardware to provide per- packet processing and handling as directed by a CE via the ForCES protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs. Control Element (CE) - A logical entity that implements the ForCES protocol and uses it to instruct one or more FEs how to process packets. CEs handle functionality such as the execution of control and signaling protocols. CEs may consist of PCE partitions or whole PCEs. Pre-association Phase - The period of time during which a FE Manager (see below) and a CE Manager (see below) are determining which FE and CE should be part of the same network element. Post-association Phase - The period of time during which a FE does know which CE is to control it and vice versa, including the time during which the CE and FE are establishing communication with one another. ForCES Protocol - While there may be multiple protocols used within the overall ForCES architecture, the term "ForCES protocol" refers only to the ForCES post-association phase protocol (see below). ForCES Post-Association Phase Protocol - The protocol used for post- association phase communication between CEs and FEs. This protocol does not apply to CE-to-CE communication, FE-to-FE communication, or to communication between FE and CE managers. The ForCES protocol is a master-slave protocol in which FEs are slaves and CEs are masters. This protocol includes both the management of the communication channel (e.g., connection establishment, heartbeats) and the control messages themselves. FE Model - A model that describes the logical processing functions of a FE. FE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which CE(s) a FE should communicate. This process is called CE discovery and may involve the FE manager learning the capabilities of available CEs. A FE manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which CE(s) to use. Being a logical entity, a FE manager might be physically combined with any of the other logical entities mentioned in this section. CE Manager - A logical entity that operates in the pre-association phase and is responsible for determining to which FE(s) a CE should Gopal Expires August 2002 [Page 3]
Internet Draft Forwarding Element Model February 2002 communicate. This process is called FE discovery and may involve the CE manager learning the capabilities of available FEs. A CE manager may use anything from a static configuration to a pre- association phase protocol (see below) to determine which FE to use. Being a logical entity, a CE manager might be physically combined with any of the other logical entities mentioned in this section. Pre-association Phase Protocol - A protocol between FE managers and CE managers that is used to determine which CEs or FEs to use. A pre-association phase protocol may include a CE and/or FE capability discovery mechanism. Note that this capability discovery process is wholly separate from (and does not replace) that used within the ForCES protocol (see Section 7, requirement #1). However, the two capability discovery mechanisms may utilize the same FE model (see Section 6). Pre-association phase protocols are not discussed further in this document (see Section 11.3). ForCES Network Element (NE) - An entity composed of one or more CEs and one or more FEs. To entities outside a NE, the NE represents a single point of management. Similarly, a NE usually hides its internal organization from external entities. ForCES Protocol Element - A FE or CE. 2. Introduction Network elements such as routers play an important role in transporting IP packets in the Internet. QoS aware router, policy based routing and middle-box functions such as firewall, NAT, proxies put heavy requirements on per-hop behavior treatment for IP packets. This complicates network element. Routers have emerged from simple monolithic software to a distributed routing complex that interconnects different networks and distributes the routing and forwarding logic to line cards and control cards. A line card does basic forwarding function and a control card runs all the control and management functions. Forces [4] defines both architectural and protocol requirements for the communication between CE and FE. This document describes a FE model. The model comprises of logical components and the components are organized in sequence in the forwarding plane of a line card. 3. FE Model Before describing the organization of the model, let us look at the Gopal Expires August 2002 [Page 4]
Internet Draft Forwarding Element Model February 2002 functions and basic building blocks of the model. Forces [4] defines that FE resides in the forwarding data path and is responsible for communicating with CE. It represents all the logical components residing in the forwarding plane. The rest of this section describes how we identify the components and build FE model. 3.1.1. Functional aspects of Forwarding plane components When a packet is received by the forwarding blade inside ( say a line card), it may be modified, metered or unmodified and be directed towards its destination through the same/different line card egress port. The components that are responsible for altering, directing or metering IP packets may be hardware components (like queue buffer) or software components. These components are the essential building blocks of the FE. There may be one or more such components and they are arranged serial or parallel from input port to output port of the line card. A FE model represents logical components and their relations. It is important that each logical component is identified by its unique behavior. 3.2. Classification based on the treatment The classification of logical functions based on the capability is shown in Figure 1. The Horizontal scale describes the logical component organization based on how they treat IP packets. Even though this classification is not reflected in the FE model, it helps to understand the logical components in terms of what they do on receipt of an IP packet for treatment. The logical components are classified as follows: 1. Logical components that do not modify IP packets but perform some parsing or decision-making. Typical function may include a simple look-up. 2. Logical components that modify the content of the IP packet in the header or the payload, e.g., encryption or DSCP code points etc. These components may perform some logical operations or operations that are based on configured algorithms. Gopal Expires August 2002 [Page 5]
Internet Draft Forwarding Element Model February 2002 3. Logical components that do not modify but simply act as counter to compute some statistics. This is a subset of case 1. The only difference could be these components may generate external events to the management plane components or to CE itself. Treatment of IP packet --------------------------------------------------------> |Classification of logical components based on packet treatment |----------------------------------------------------------------- | IP packets | IP packets | IP not modified | Not modified | altered | but has some side effects |----------------+------------------------------------------------ | Classifier | Firewall | | Filter | Half-NAT | Meter | Shaper | Dropper | egress port | Forwarder | Encapsulation | ingress port | Queue | Decryption | | Scheduler | Figure 1 Classification of logical functions NOTE: 1. Meter also does not modify the IP packet. It is a special type of logical function where it can generate external events which can be either feedback to one of the logical functions or to be sent to outside the FE for management. 2. Similarly, egress and ingress port status is monitored by the FE and if a status change is detected by FE, it may generate an event. 3.3. Placement and ordering of logical components in FE The third aspect, which gives understanding of the FE model, is the organization of the logical components. There may be more than one parallel path in the forwarding plane between an egress port and an ingress port. The logical components are laid out in sequence in each parallel data path. When an IP packet passes through these logical components one after another, the IP packet experiences different treatments and these treatments are called stage operations [5]. The following summarizes the logical layout of the FE model. The logical layout is not contributing to the treatment of IP packet. Gopal Expires August 2002 [Page 6]
Internet Draft Forwarding Element Model February 2002 1. One or more parallel path to process the IP packets in a forwarding blade. 2. An IP packet passes through the series of logical components and gets different packet treatments in each stage of operation. This organization and placement of logical components may be different for different path between an ingress port and an egress port. 3. The treatments of packets in one direction may be different from the treatments of packets in the reverse direction of the path. Gopal Expires August 2002 [Page 7]
Internet Draft Forwarding Element Model February 2002 3.4. FE Model relationship After describing the concept of a logical function, its behavior and placement inside a FE, the object model is described in the Figure 2. +-----------------------+ | FE | +-----------------------+ | |1..n +-----------------------+ | Parallel Path | +-----------------------+ |1 | |1 .. n +-----------------------+ | Logical Component | (Abstract Element) +-----------------------+ ^ | | <------------------------------------------------> | | | | +-----------+ +-------+ +-------+ +-----------+ | Classifier| |Marker |. . .| Queue | . .| Forwarder | +-----------+ +-------+ +-------+ +-----------+ ^ ^ | | <---------------------> <-----------------> | | Specific Capabilities | | +-------------+ +------------+ +---------+ +--------+ | Multifield | | Free-Form | | RFC1812 | . . | Content| +-------------+ +------------+ +---------+ | Based | +--------+ Figure 2 Object model of FE Description of the Model: 1. The FE is the base object that can have one or more parallel paths to handle IP packets from ingress to egress ports. FE object describes the attributes and capabilities the FE supports. This includes whether it can participate 2 phase command operation, high availability operation etc. [4] Gopal Expires August 2002 [Page 8]
Internet Draft Forwarding Element Model February 2002 2. On each parallel path, there may be one or more logical components. The logical component names are unique and can be referenced uniquely inside a FE. Parallel path object is just a reference object. 3. Logical component is an abstract entity. Its basic characteristic is that it contributes to the per-hop behavior while treating IP packets. Multiple logical components that are derived from this abstract component. Examples are Forwarder, Filter, Classifier, etc. There may be further specialized logical components that are the classified logical components. Therefore, this model in principle has 3 levels as follows: (1) First level is the FE object level which describes the characteristic of FE , it contains list of CE in the CE -Table. (2) Second level is the Parallel path object that is used to assist the referencing of the FE logical elements (3) Third and final level is the Logical components themselves. Vendor specific logical functions can be added and their attributes can be either defined or extended from existing logical components. The next section describes the Table view to show how we can reference each logical element and how it can be configured and operated. 3.5. Representation To represent the FE model in and to provide access to different logical functions, CE can communicate to FE in one of the following ways 1. XML representation 2. TLV format 3. MIB (ASN.1) format XML takes up more bytes and requires parse functions in the CE and FE. XML is not widely deployed and used in network elements. ASN.1 format is human readable and most of the logical functions attributes can be found in other protocols like Diffserv, PIB, IPSec policy , etc. It will easier to use rather than redefining it Gopal Expires August 2002 [Page 9]
Internet Draft Forwarding Element Model February 2002 repeatedly. This notation itself serves as some unique identification to access all the logical components in a FE. TLV is another alternative to communicate. But it requires some external table structure to uniquely identifying the logical components inside the network element. 3.5.1.Logical organization of Table We provide the table views and describe each tables. Later part of this section describes the actual MIB itself. 1. Each logical components needs to be accessed from the FE. 2. There may be multiple logical components of the same type in one parallel path eg., classifier components Parallel path Table <--------different stage ------------> +-------------------+ +--------+ +-----------+ +-------+ |Parallel path 1 |o---->|ingress |->| IPFwd | . ->|egress | +-------------------+ | port | +-----------+ |port | |Parallel path 2 |o-- +--------+ +-------+ +-------------------+ | . | +----------+ +-----------+ . +->|ingress |-> |Vendor | . |port | |Specific | +----------+ +-----------+ | | | +-----V--+ +-------+ | Meter |. . ->|egress | +--------+ |port | +-------+ Figure 3 Organization of FE Table Figure 3 describes two parallel paths. The parallel path table contains index to the series of logical components. Logical components are organized similar to a link list. It preserves the order placement of logical components and is similar to [5][6]. On parallel path 1, an IP packet reaches the ingress port. It then moves on to the second stage and is processed by the Ipforwarder component. This process continues till the packet reaches the egress Gopal Expires August 2002 [Page 10]
Internet Draft Forwarding Element Model February 2002 port logical component. This linked list view of the stage reflects the actual layout of the logical components in the forwarding path. The following are the operations that can be performed on this model. (a) Flexibility Vendor specific components can be added and be used any where in the stage operation. This model is extensible and the uniqueness to identify a particular element in a FE is by an OID. For example, FE.ParallelPathTableEntry.LogicalComponent (b) Ordering of Logical Functions Order of Logical functions is easily mapped to the linked list organization of stage row entry. There may be cycles of operations that may lead to loops etc. However, the sequence in which a packet is treated is provided in a link list form (C) Port Functions As each logical component is identified by a unique number, it is easy for FE to provide and update the status of the ports. Either FE can automatically generate notification to the external CE or the external entity can make a query to get the status. (d) Logical component functions MIBÆs for filters, Classifiers, Queues are defined in other protocol the configurable attributes and their access privileges are described in detail. Gopal Expires August 2002 [Page 11]
Internet Draft Forwarding Element Model February 2002 3.5.2. Example of Logical Component Description Parallel path Table <--------STAGE -----------------------> +-------------------+ +--------+ +-----------+ +-------+ |Parallel path 1 |o---->|ingress |->| IPFwd | . ->|egress | +-------------------+ | port | +-----------+ |port | |Parallel path 2 |o-- +--------+ +-------+ +-------------------+ | . | | . | | +-----------------------+ | | +----------------------------------------------------------+ | | Meter Table | | +----------------------------------------------------------+ | |Id | SucceedNext|FailNext | MeterSpecific| Storage|Status | | +---+------------+---------+--------------+--------+-------+ | | | | | | | | | +---+------------+---------+--------------+--------+-------+ +->| | O | | | | | +--------|-------------------------------------------------+ | +-----------+ | +------------------------------------------------------+ | | Queue Table | | +------------------------------------------------------+ | |Id | ServQNext |MinRate | MaxRate | QStorage|QStatus | | +---+------------+---------+--------+---------+--------+ | | | | | | | | | +---+------------+---------+--------+---------+--------+ +->| | O | | | | | +---+----|-------+---------+--------+---------+--------+ | | | | | | | | +---+----|-------+---------+--------+---------+--------+ | | + -> Next logical component function In this example, we show how each logical component can be accessed using the data path pointer in the parallel path table. We have taken the Meter Table and Queue Table attributes as defined in the [6]. Gopal Expires August 2002 [Page 12]
Internet Draft Forwarding Element Model February 2002 First parallel path table is accessed and the index of the parallel path table points to the first logical component function. Each logical function is arranged in the form of a table. After indexing the parallel path table for the second parallel path the first logical functions is metering, the data path pointer points to the attributes that are configured for that logical function. After the metering process, the next pointer field points to the next logical component that is a Queue. Hence, the next pointer points to a row of that Queue table. Each logical component is organized in a table form. Table lookup is straightforward. This approach can support any number of parallel data paths. Indexing is based on the table value. The FE model needs to add some values like logical component ID , and some other additional attributes which are required for the identification of logical components. 3.6. FE model MIB Definition (ASN.1) TBW 4. References 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, October 1996. 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement Levels", RFC2119 (BCP), IETF, March 1997. 3. S. Blake, et. Al., "An Architecture for Differentiated Service", RFC2475, December 1998. 4. Anderson, et. al.,"Requirements for Separation of IP Control and Forwarding", work in progress, February 2002,<draft-ietf-forces- requirements-02.txt>,IETF. 5. Y. Bernet, et. al., "An Informal Management Model for DiffServ Routers", work in progress, September 2001, <draft-ietf-diffserv- model-06.txt>, IETF. 6. F.Baker, et. al., "Management Information Base for the Differentiated Services Architecture", work in progress, November 2001, <draft-ietf-diffserv-mib-16.txt>, IETF. Gopal Expires August 2002 [Page 13]
Internet Draft Forwarding Element Model February 2002 5. Acknowledgments I would like to thank Man Li and Sanjeev verma of Nokia Research Center for their valuable comments and suggestions. 6. Authors' Addresses Ram Gopal Nokia Research Center 5, Wayside Road, Burlington, MA 01803 Phone: 1-781-993-3685 Email: ram.gopal@nokia.com Gopal Expires August 2002 [Page 14]