ForCES Working Group Z. Haraszti Internet-Draft S. Blake Expires: December 30, 2003 Ericsson July 1, 2003 ForCES FE Functional Model Elements draft-haraszti-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. This Internet-Draft will expire on December 30, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This memo identifies requirements and issues associated with the ForCES Forwarding Element Functional Model. It attempts to: o Build on the concepts introduced in [MODEL]. o Serve as a collection/list of requirements for the FE functional model o State some open issues that must be resolved before the actual formal model can be designed. o Address some of the issues raised here and in [MODEL]. Haraszti & Blake Expires December 30, 2003 [Page 1] Internet-Draft ForCES FE Functional Model Elements July 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 3. The ForCES Model in Relation to a Real Forwarding Datapath Implementation . . . . . . . . . . . . . . . . . . 4 4. The ForCES Model in Relation to the ForCES Protocol . . . . 5 5. Open Issues and Working Assumptions . . . . . . . . . . . . 5 5.1 Data modeling language . . . . . . . . . . . . . . . . . . . 5 5.2 Level of Detail in LFB Class Operational Specifications . . 6 5.3 Detailed Packet Format Definitions . . . . . . . . . . . . . 7 5.4 Detailed Metadata Definitions . . . . . . . . . . . . . . . 7 5.5 Topological vs. Encoded State Representation . . . . . . . . 8 5.6 More than One LFB Input . . . . . . . . . . . . . . . . . . 8 5.7 More than One LFB Output in General LFBs . . . . . . . . . . 9 5.8 How to Define FE Topology Configuration Capabilities? . . . 9 5.9 How to Define LFB Topology Configuration Capabilities? . . . 9 5.10 Should LFBs Propagate Metadata? . . . . . . . . . . . . . . 10 5.11 Metadata Pass-Through . . . . . . . . . . . . . . . . . . . 11 5.12 Inheritance as a Means of Defining New LFB Classes . . . . . 11 5.13 Version Handling . . . . . . . . . . . . . . . . . . . . . . 12 6. The FE Functional Model Library . . . . . . . . . . . . . . 13 6.1 General Data Type Definitions . . . . . . . . . . . . . . . 14 6.2 Metadata Definitions . . . . . . . . . . . . . . . . . . . . 15 6.3 Frame Format Definitions . . . . . . . . . . . . . . . . . . 15 6.4 Logical Function Block (LFB) Class Definitions . . . . . . . 16 6.4.1 LFB Inheritance . . . . . . . . . . . . . . . . . . . . . . 16 6.4.2 LFB Inputs . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.4.3 LFB Outputs . . . . . . . . . . . . . . . . . . . . . . . . 17 6.4.4 LFB Resources . . . . . . . . . . . . . . . . . . . . . . . 19 6.4.5 LFB Exceptions . . . . . . . . . . . . . . . . . . . . . . . 21 6.4.6 LFB Operational Specification . . . . . . . . . . . . . . . 22 7. The Post-Association Components of the FE Functional Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 7.1 FE Topology and Configuration Capabilities . . . . . . . . . 23 7.2 FE Capability Declarations . . . . . . . . . . . . . . . . . 24 7.3 LFB Topology and Topology Configurability . . . . . . . . . 24 7.4 LFB Capability Declaration . . . . . . . . . . . . . . . . . 24 7.5 LFB Resource State (Query) . . . . . . . . . . . . . . . . . 25 7.6 LFB Resource Manipulation . . . . . . . . . . . . . . . . . 26 7.7 LFB Topology Re-configuration . . . . . . . . . . . . . . . 27 7.8 FE Topology Re-configuration . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . 27 References . . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . 29 Haraszti & Blake Expires December 30, 2003 [Page 2] Internet-Draft ForCES FE Functional Model Elements July 2003 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 [RFC2119]. 1 Introduction [FWK] specifies a framework by which control elements (CEs) can configure and manage one or more separate forwarding elements (FEs) within a networking element (NE) using a standardized protocol (referred to as "the ForCES protocol"). [REQS] defines requirements which must be satisfied by a ForCES FE functional model. [MODEL] discusses the rationale for a FE functional model, along with some of the issues associated with defining it. To summarize, a FE functional model is necessary: o To define logically separable and distinct packet forwarding operations in a FE datapath (logical forwarding blocks or LFBs). o To define the possible topological relationships (and hence the sequence of packet forwarding operations) between the various LFBs. o To define the possible operational capabilities (e.g., resources, granularity of configuration) of each type of LFB. o To define the possible configurable parameters of each type of LFB. o To define metadata that may be exchanged between LFBs. o To define the possible topological relationships between multiple FEs within a NE. o To define metadata that may be exchanged between LFBs on separate, interconnected FEs (i.e., the Fi reference point [FWK]), along with possible metadata encodings. Definition of the various payloads of ForCES messages (irrespective of the transport protocol ultimately selected) cannot proceed in a systematic fashion until a formal definition of the objects being configured and managed (the FE and the LFBs within) is undertaken. This document attempts to summarize the open issues which must be solved before undertaking the design of a formal FE functional model. As there is overlap in intent between this document and [MODEL], we have tried not to dwell on topics already covered in the other Haraszti & Blake Expires December 30, 2003 [Page 3] Internet-Draft ForCES FE Functional Model Elements July 2003 document. Further, this document offers possible answers to some of the the open issues, and offers possible solutions to the stated requirements. 2 Terminology We have tried to adhere to the terminology introduced in existing ForCES documents. Here we mention only terms that are new, or used in a clarified way. The term "FE topology" is not used consistently in previous ForCES documents. In the rest of this memo we will use the following terminology: "FE topology" refers to the graph where nodes are FEs and edges represent datapath interconnects between FEs (this is consistent with the term "inter-FE topology" in [FWK]). The CE must learn the FE topology in addition to the LFB topology within each FE in order to determine the overall capabilities of the NE. "LFB" or "LFB instance" is a logical functional block performing a well-defined forwarding operation, executed by the FE as part of the datapath. The data plane is defined as a directed graph of LFBs, where each LFB is an instance of a "LFB class". In [MODEL] LFB instances are referred to as "FE stages". "LFB Class" or "LFB Type" is a generic LFB template representing a given type of packet forwarding operation. An LFB instance is instantiated from one of the existing LFB classes. (This is similar to the concept of a Class definition in OOP). LFB classes are also referred to as "FE Components" (FECs) in [NETLINK2], while [MODEL] uses the term "FE Blocks". "LFB Topology" refers to the graph that describes all LFB instances within a FE (this is consistent with the term "intra-FE topology" in [FWK]). The nodes in the graph are the LFB instances, and edges are the datapath segments interconnecting the LFB instances. 3 The ForCES Model in Relation to a Real Forwarding Datapath Implementation The FE function model assumed in [MODEL] and here is based on an abstraction of distinct logical functional blocks, interconnected in a directed graph, and receiving, processing, modifying, and transmitting packets along with accumulated metadata. Note that a real forwarding datapath implementation is not constrained to behave in this way. For instance, the functions associated with LFBs may be executed as nested sub-routines on a microprocessor or network processor, with no packet data copying between the sub-routines, and with the metadata values stored in common shared memory and/or Haraszti & Blake Expires December 30, 2003 [Page 4] Internet-Draft ForCES FE Functional Model Elements July 2003 registers. On the other hand, a FE implementation could consist of two or more physical devices (or autonomous processors on an integrated circuit) connected in series, which each handling a subset of the LFB functions, and with inter-device metadata conveyed in in-band packet preamble. The LFB topology for a particular datapath implementation MUST correctly capture the sequence of operations on the packet. Metadata generation (by certain LFBs) must always precede any use of that metadata (by subsequent LFBs in the topology graph); this is required for logically consistent operation. Further, modifications of packet fields that are subsequently used as inputs for further processing must occur in the order specified in the model for that particular implementation to ensure correctness. 4 The ForCES Model in Relation to the ForCES Protocol The details of a particular datapath implementation, namely the FE and LFB topology, along with the resource and operational capabilities of each individual FE and LFB, must be conveyed to the CE within information elements in the ForCES protocol. The functional model of a LFB class should define all of the information that would need to be exchanged between a FE and a CE for the proper operation and management of that LFB. We envision that the document defining the FE functional model schema will include schemas for a LFB base class, and schemas for expressing LFB and FE topology and capabilities. We also envision that the individual LFB classes will be defined in separate documents. For consistency, we believe that the ForCES protocol commands and information elements (i.e., protocol TLVs) used to configure and manage LFBs should be included in the same document as the LFB class model. 5 Open Issues and Working Assumptions Below is a list of major open issues that need to be resolved by the working group before a model can be completed: 5.1 Data modeling language [MODEL] mentions the following possible modeling languages: XML, ASN.1, SMI, SPPI, and UML. Working assumption: The rest of the document is written without assuming a particular formal modeling language. The authors assume that, at least for the post-association phase of the protocol, that protocol commands and information elements will be explicitly defined Haraszti & Blake Expires December 30, 2003 [Page 5] Internet-Draft ForCES FE Functional Model Elements July 2003 in the "standard IETF way", as binary encoded data structures (the pre-association phase encoding is not assumed to be performance-sensitive). An alternative protocol encoding may also be defined based on the standard on-the-wire representation of the selected modeling language, where the protocol commands and information elements are defined via that language. 5.2 Level of Detail in LFB Class Operational Specifications LFB operation must be specified in the functional model to allow the CE to understand the behavior of the forwarding datapath. For instance, the CE must understand at what point in the datapath the IPv4 header TTL is decremented (i.e., it needs to know if a control packet could be delivered to the CE either before or after this point in the datapath). Also, the CE must understand where and what type of header modifications (e.g., tunnel header append/strip) are performed by the FEs. Further, the CE must verify that the forwarding functions performed by various FEs (e.g., an ingress and egress FE) are compatible. There is value to vendors if the operation of LFB classes can be expressed in sufficient detail so that physical devices implementing different LFB functions can be integrated easily into a FE design. Working assumption: Semi-formal specification is needed; that is, a text description of the LFB operation (human readable), but sufficiently specific and unambiguous to allow conformance testing and efficient design (i.e., eliminate guess-work), so that interoperability between different CEs and FEs can be achieved. The LFB class model MUST specify: o metadata read/consumed o metadata produced o packet encapsulation modifications o packet content modifications o packet routing criteria (when multiple outputs on a LFB are present) o packet timing modifications o packet flow ordering modifications Haraszti & Blake Expires December 30, 2003 [Page 6] Internet-Draft ForCES FE Functional Model Elements July 2003 5.3 Detailed Packet Format Definitions When LFB classes are defined, the input and output packet formats (e.g., IPv4, IPv6, Ethernet, etc.) must be specified (these are the types of packets a given LFB input is capable of receiving and processing, or a given LFB output is capable of producing). This type of definition requires that distinct frame types be uniquely labeled with a symbolic name and/or ID. In addition, if the operational specification is to be a precise definition of how the LFB modifies packets, then it may be necessary to refer to the various fields within packets, as well as to specific values of these fields. For example, assume that the following text will be part of the operational specification section of an IPv4 LFB class definition: "If (FRAME_IPV4[FIELD_IPV4_IHL] != FIELD_IPV4_IHL_STD), then the IPv4 frame is emitted via output SPECIAL_CASE. All metadata that were received with the frame are also emitted." This approach allows a rather formal specification of the operations of a LFB, but requires that frame formats be specified in great detail. A set of symbolic references to frame types, their fields, and field values must be defined in order to formalize the operational specification. Working assumption: Needed. Note that some LFB instances may have to be capable of processing packets with encoded, in-band metadata; specifically, those LFBs which receive the input of a physical device (such as the first LFB in the datapath of a FE performing egress functions and receiving packets across the Fi interface, or LFBs on one of two or more physical devices within a FE). This issue is discussed in the next section. 5.4 Detailed Metadata Definitions Metadata is used to communicate per-packet state from one LFB to another. To ensure inter-operability among LFBs, the LFB class specification must define what metadata the LFB class "reads" or "consumes" on its input(s) and what metadata it "produces" on its output(s). For that purpose, metadata types must be identified. For example, an META_IFID, passed from a port LFB to an IPv4 processing LFB (with the IP packet) can be one of the defined metadata types. Symbolic names can be assigned for common metadata types. Working assumption: Symbolic names should be defined for each Haraszti & Blake Expires December 30, 2003 [Page 7] Internet-Draft ForCES FE Functional Model Elements July 2003 metadata type. In addition, additional information such as numeric data type, maximum and minimum accepted values, and special values (see Section 6.2 for more information) should be defined for each metadata value. Some of these constraints will be defined in the LFB class model, and some of them may be specific capabilities of a particular LFB instance. As mentioned previously, it may be necessary to encode metadata in in-band headers when transmitting packets between physical devices. A standardized metadata encoding protocol should be defined. 5.5 Topological vs. Encoded State Representation The concept of topological versus encoded state representation is introduced in Section 4.2.1 in [MODEL]. Will the model be limited to one or the other, or both will be allowed? In case both are allowed, which approach will be preferred? Working assumption: Both will be allowed, but designers of LFB classes must use the topological approach in a limited fashion. The topological approach should only be used when the packet datapath forks into areas with distinct LFBs (not just distinct parameterizations of the same LFB classes). In addition, a general design guideline should be to use the topological approach only for fan-outs that do not require changes (adding/removing LFB outputs) at all or require only very infrequent changes. Configuration information that needs to change frequently should not be encoded using the LFB topology, but rather should be expressed by the internal resources of one or more LFBs. Note that LFB-internal resources can be designed in any way, including objects that are linked to each other to form graphs. 5.6 More than One LFB Input Should LFB classes be allowed to have more than one input "port"? Working assumption: It is inevitable that there will be LFB instances that will receive packets from more than one other LFB instances (fan-in). If these fan-in links all carry the same type of information (packet type and set of metadata) and require the same processing within the LFB, then one input should be sufficient. Note that we assume that the model allows for connecting more than one LFB output to a single LFB input. If, however, the LFB class can receive two or more very different types of input, and the processing of these inputs are also very Haraszti & Blake Expires December 30, 2003 [Page 8] Internet-Draft ForCES FE Functional Model Elements July 2003 distinct, then that may justify the definition of multiple inputs. But in these cases splitting the LFB class into two LFB classes should always be considered as an alternative. In intermediate cases, e.g., where the inputs are somewhat different but they require very similar processing, the shared input solution should be preferred. For example, if an Ethernet framer LFB is capable of receiving IPv4 and IPv6 packets, these can be served by the same LFB input. 5.7 More than One LFB Output in General LFBs Should LFB classes be allowed to have more than one output? Working assumption: We assume that a single LFB output can be connected to only one LFB input (this is required to make the packet flow through the LFB topology unambiguous). Therefore, to allow any non-trivial topology, a LFB class must be able to have more than one output. However, using multiple outputs for topological encoding should be avoided (see discussion in Section 5.5). 5.8 How to Define FE Topology Configuration Capabilities? Will the FE topology (interconnection of FEs) ever be configurable by the CE(s)? Shall the connection between two FEs that are otherwise capable of communicating (i.e., interconnected in the hardware) be configurable by the CEs such that the CEs may be able to disable or enable such links? Working assumption: We assume that FEs cannot be created or deleted by the CEs (hence the nodes of the FE topology graph are "read-only" information to the CEs). We also assume that the interconnections between FEs are limited by the NE hardware implementation, in the sense that if the hardware does not allow sending packets from FE[i] to FE[j], then these FEs will never be interconnected in the FE topology. The usefulness of allowing the CE to enable and disable FE interconnections supported by the NE hardware requires further research. In case FE topology configurations are to be supported (in the above sense), a model is needed to define data that can represent the actual interconnection capabilities of the FEs to the CEs. 5.9 How to Define LFB Topology Configuration Capabilities? [REQS] states that the ForCES protocol must allow configurable LFB topologies; that is, the CE(s) should be capable of creating/deleting LFBs and setting up/deleting interconnections between LFBs within an Haraszti & Blake Expires December 30, 2003 [Page 9] Internet-Draft ForCES FE Functional Model Elements July 2003 FE. Even if a FE supports configurable LFB topologies, it is expected that there will be FE-specific limitations on what can actually be configured. Performance-optimized network processors may have zero or very limited configurability, while FE implementations running on generic purpose processors may provide a great level of configurability. In either case, the CE(s) must be able to learn the FE's configuration capabilities. Working assumption: The functional model must provide mechanisms for describing the LFB topology configuration capabilities of a FE. These capabilities may include: o What LFB classes can the FE instantiate? o How many instances of the same LFB class can be created? o What are the topological limitations? For example: * How many instances of the same class or any class can be created on any given branch of the graph? * Ordering restrictions on LFBs (e.g., any instance of LFB class A must be always downstream of any instance of LFB class B). o Other limitations 5.10 Should LFBs Propagate Metadata? A given LFB may require a certain metadata at its input for its internal processing. What should happen with the metadata after it is read by the LFB? In particular, should the metadata be propagated along with the packet when the packet is forwarded from the LFB to the next LFB, or should it be removed (consumed) by the LFB? In certain cases passing the metadata along is desirable. For example, a META_CLASSID metadata may denote the result of a classification LFB and used in more than one downstream LFBs to trigger the proper operation on the packet. In this case the first LFB that uses the META_CLASSID should also allow the META_CLASSID to be passed with the packet to the next LFB, and so on. On the other hand, it is easy to see that if metadata is never consumed by LFBs, then as the packet trickles through the datapath, a large number of metadata will potentially be accumulated by the packet. This does not seem to be a sustainable solution, either in implementations where metadata is stored in registers or shared memory, or implementations where metadata is encoded in-band with the Haraszti & Blake Expires December 30, 2003 [Page 10] Internet-Draft ForCES FE Functional Model Elements July 2003 packet as it propagates through the datapath. Working assumption: For each element of metadata utilized by a LFB class, the propagation mode MUST be specified. Metadata elements which are not propagated are specified with the CONSUME mode, while elements which are propagated are specified with the LOOK_AT mode. However, whether a metadata is useful beyond a LFB may depend on the actual LFB topology, i.e., what other LFBs are placed downstream. So it seems more appropriate that the removal of metadata is somehow configurable. 5.11 Metadata Pass-Through A packet may arrive to a LFB with metadata that is not meaningful to that LFB, but may be important to some other downstream LFBs. Working assumption: To cater for such cases it should be the assumed (default) behavior of all LFB classes that they transparently forward any (and all) metadata elements that they do not utilize internally. Actual implementations of LFBs in hardware may have limitations on how much metadata they can pass through. The limitation may be expressed in terms of total framesize (packet + metadata), metadata total size, number of metadata elements, or a combination of each of these. Also, the limitation may be on the FE level or may be specific to LFBs within a FE. The pass- through capabilities of LFB instances and FEs should be detectable as part of the capability discovery process. 5.12 Inheritance as a Means of Defining New LFB Classes Deriving a new LFB class from another existing LFB class may prove to be an efficient way of evolving LFBs. This approach can also allow FE vendors to add vendor-specific extensions to standardized LFBs. Working assumption: LFB class inheritance will be supported. An LFB class specification MUST specify the base class it inherits from (with the default being the base LFB class). Support for multiple inheritance requires further investigation. An interesting issue related to class inheritance is backward compatibility (between an descendant and an ancestor class). To illustrate the problem, consider the following hypothetical scenario: There exists a standardized LFB class "L1". Vendor A builds a FE that implements LFB "L1" and vendors B and C both build CEs that can recognize and operate on LFB "L1". In this case vendor B's and C's CE both are interoperable with vendor A's FE. Suppose that a new LFB Haraszti & Blake Expires December 30, 2003 [Page 11] Internet-Draft ForCES FE Functional Model Elements July 2003 class, "L2", is defined based on the existing "L1" class (for example, extending its capabilities in some incremental way). Suppose, furthermore, that vendors A and B upgrade their FE and CE, respectively, to support the new LFB class, but vendor C's CE is not changed. Obviously, vendor A and B are interoperable, but will vendor C's CE work with the new FE? No, unless some special mechanisms are put in place to support backward compatibility. A much less problematic case is the reverse scenario, i.e., when a CE vendor upgrades to the new LFB class, but the FE is not upgraded. Note that as long as the CE is capable of working with older LFB classes, this problem does not influence the modeling requirements, hence we will use the term "backward compatibility" to refer to the first scenario. Inheritance can be designed into the model with or without supporting backward compatibility. Without backward compatibility, the derived LFB class MUST simply refer to the base class (immediate parent node in the inheritance tree). In addition, the model must provide a clean and efficient way to define the changes, i.e., the differences between the base class and the derived class. The issue becomes more complex if backward compatibility is a desired feature. In that case the following mechanisms are required: 1. When detecting a LFB instance of a LFB type that is unknown to the CE, the CE MUST be able to query the base class of such a LFB. 2. The LFB instance SHOULD support a backward compatibility mode, and the CE SHOULD be able to configure the LFB to run in such mode. In case of multiple inheritance (e.g., LFB class "L3" is derived from "L2", and "L2" is derived from "L1"), to support backward compatibility across non-adjacent generations, the derived LFB instance must support multiple backward compatibility modes, and the CE should be able to query the base classes in an iterative way. 5.13 Version Handling Similarly to LFB class inheritance, LFB class versioning is a potential method to enable incremental evolution of LFB classes. Unlike inheritance, where it assumed that a FE datapath model containing a LFB instance of a particular class "C" could also simultaneously contain a LFB instance of a class "C'" inherited from "C", with versioning, a FE would not be allowed to contain a LFB instance for more than one version of a particular class. Haraszti & Blake Expires December 30, 2003 [Page 12] Internet-Draft ForCES FE Functional Model Elements July 2003 Working assumption: LFB class versioning will be supported, for example by requiring a version string in the class definition. CEs may support backwards compatibility between multiple versions of a particular LFB class, but FEs are not allowed to support more than a single version of a particular class. 6 The FE Functional Model Library A main goal of the FE functional model is to provide an abstract, generic, modular, implementation independent representation of the forwarding plane (FEs). This is facilitated using the concept of LFBs which are instantiated from LFB classes. The LFB classes will be defined in a model library which is the subject of this section. The core part of the model library is the definition of LFB classes. Section 6.4 provides more discussion on what will be part of a LFB class definition. Operational parameters of the LFBs that must be visible to the CEs are conceptualized in the model as the "resources" of the LFB. These will include, for example, flags, single parameter arguments, complex arguments, and tables. The definition of the resources of a LFB MUST be part of the LFB class definition. To promote consistent and terse definitions of the resources of LFB classes, commonly used resource types SHOULD BE defined in the model library outside of the LFB class definitions, so that LFB class definitions can "share" these type definitions by simply referring to the types. What will comprise a data type definition is further discussed in Section 6.1. In the model LFBs form a directed graph and communicate with each other by sending and receiving packets and associated metadata. To provide consistency and logical inter-operability among LFB classes, packet types (generic frame types) and metadata types MUST BE specified outside of the LFB class definitions (but part of the model library), so that the LFB class definitions can simply refer to these types. These blocks are further discussed in Section 6.3 and Section 6.2, respectively. In summary, the FE functional model library will consist of the following four building blocks: 1. Common data type definitions 2. Frame format definitions 3. Metadata definitions 4. LFB class definitions Haraszti & Blake Expires December 30, 2003 [Page 13] Internet-Draft ForCES FE Functional Model Elements July 2003 It is not expected that the above information is exchanged between FEs and CEs "over-the-wire". But the model library will serve an important reference for the design and development of the CEs (software) and FEs (mostly the software part). These definitions will most likely be provided in internet drafts or RFCs. To serve the above purpose, it would not be absolutely required that the model library itself is defined using some formal description language (since software encoding will be done by humans). Nevertheless, using a formal language can help in enforcing consistency and logical compatibility among LFBs. In addition, formal definition of the LFB classes has the potential to facilitate: o The eventual automation of some part of the code generation process. o The functional validation of arbitrary LFB topologies. When selecting the formal language, it should be considered that the model library MUST be human readable. There are no real-time requirements (encoding, decoding, transmission) on the language, however. The authors of this memo view XML as a very good candidate for the model library language. 6.1 General Data Type Definitions Data types will be used to describe the resources of LFBs (see Section 6.4.4). This is similar to the concept of having a common header file for shared data types. Data types will include atomic data types (e.g. integer, ASCII string), as well as compound/derived data types (such as arrays, sets, structures, etc.). Compound data types can build on atomic data types and other compound data types. For each data type the following information MUST be provided: o Symbolic name of data type. Example: "T_IPV4ADDRESS". o Actual type declaration. In addition, a data type definition MAY include the following: o Range restrictions. o A set of symbolic abbreviations for special values. Example: "IPV4ADDR_LOOPBACK". Haraszti & Blake Expires December 30, 2003 [Page 14] Internet-Draft ForCES FE Functional Model Elements July 2003 6.2 Metadata Definitions This block of the model library will list metadata type definitions. For each metadata type, the following MUST be specified: o Metadata symbolic name. Used to refer to the metadata type in LFB type specifications. Example: META_CLASSID. o Metadata type ID. This is a numeric type code that can be used to encode metadata type when passed between LFBs. o Brief synopsis of the metadata. Example: "Result of classification (0 means no match)". o Data type and valid range. In addition, the following information MAY BE part of the metadata definition: o Symbolic definitions for frequently used or special values of the metadata. 6.3 Frame Format Definitions This block of the model library will list packet types (frame types in general) that LFB classes can receive at their inputs and/or emit at their outputs. For each distinct frame type, the following MUST be provided: o Symbolic name of frame type. Example: FRAME_IPV4. o Frame type ID. This is a numeric code that should be used to refer to the frame format in encapsulation frames used between FEs. This ID could potentially reuse the payload/protocol type codes used in other Internet protocols. o Brief synopsis of the frame type. Example: "IPv4 packet". In addition, the following information MAY BE part of the frame type definition to facilitate formal operational descriptions of LFB classes: o Symbolic names for frequently referred header fields. o Field position and size information. Haraszti & Blake Expires December 30, 2003 [Page 15] Internet-Draft ForCES FE Functional Model Elements July 2003 o Symbolic names for special or frequently referred values of fields. 6.4 Logical Function Block (LFB) Class Definitions Each LFB Class definition must provide the following information: o Symbolic name of LFB class. Example: "LFB_IPV4_LPM" o Numeric ID of LFB class. Example: "12" o Short synopsis of LFB class. Example: "IPv4 LPM Lookup LFB" o Version indicator o Inheritance indicator (see discussion in Section 6.4.1) o Inputs (see discussion in Section 6.4.2) o Outputs (see discussion in Section 6.4.3) o Resources (see discussion in Section 6.4.4) o Exceptions (see discussion in Section 6.4.5) o Operational specification (see discussion in Section 6.4.6) 6.4.1 LFB Inheritance Deriving a new LFB class from another existing LFB class may prove to be an efficient way of evolving LFBs. This approach can, for example, allow a FE vendor to add vendor-specific extensions to standardized LFBs. To support LFB class inheritance, the LFB specification must have a place holder for indicating the base class(es). In addition to the reference of the base class, the model should support an efficient way of describing the relative differences of the derived class from the base class. This issue requires further study. 6.4.2 LFB Inputs An LFB input is a conceptual port of the LFB where the LFB can receive "information" from other LFBs. The information is typically a packet (or frame in general) and associated metadata, but some Haraszti & Blake Expires December 30, 2003 [Page 16] Internet-Draft ForCES FE Functional Model Elements July 2003 special inputs may be able to receive only metadata, i.e., with a Null-packet. An LFB class may have zero, one, or more inputs. We assume that most LFBs will have exactly one input, but there should be no restrictions on the number of up-stream LFBs connecting their outputs to the same input of a LFB. More than one input should be avoided if possible (see discussion in Section 5.6). Some special LFBs will have no inputs at all. For example, a packet generator LFB does not need an input. The number of inputs is fixed for a LFB class; that is, it is not configurable (as opposed to the number of outputs); see Section 6.4.3. The LFB Class definition MUST specify the number of inputs of the LFB. For each LFB input, the following MUST be specified: o Symbolic name of input. Example: "PKT_IN". Note that this symbolic name must be unique only within the scope of the LFB class. o Brief synopsis of the input. Example: "Normal packet input". o List of allowed frame formats. Example: "{FRAME_IPV4, FRAME_IPV6}" Note that this list should refer to symbols specified in the frame definition of the model library (see Section 6.3). In addition to the list of frame types, additional information MAY BE provided on what fields of the frames the LFB may read and/or modify. o List of required metadata. Example: {META_CLASSID, META_IFID}. This list should refer to symbols specified in the metadata definition of the model library (see Section 6.2). For each metadata it should be specified whether the metadata is required or optional. For each optional metadata a default value MAY BE specified, which is used by the LFB if the metadata is not provided at the input. 6.4.3 LFB Outputs An LFB output is a conceptual port of the LFB where it can send "information" to some other LFBs. The information is typically a packet (or frame in general) and associated metadata, but some special outputs may emit only metadata, i.e., with a Null-packet. Haraszti & Blake Expires December 30, 2003 [Page 17] Internet-Draft ForCES FE Functional Model Elements July 2003 An LFB class may have zero, one, or more outputs. Multiple outputs should mainly be used for functional separation, that is when the outputs are connected to very different types of LFBs. For example, an IPv4 LPM LFB may have one "default" output to send those packets for which look-up was successful (passing a META_ROUTEID as metadata); and have another output for sending packets for which the look-up failed. The former output may be connected to a route handler LFB, while the latter can be connected to an ICMP response generator LFB or to a packet handler LFB that passes the packet up to the CE. The use of multiple outputs for topological encoding should be avoided. In case topological encoding is used, we model this as if the same output type is instantiated more than once. Multiple instances of the same output type are referred to as an "output group". Some special LFBs may have no outputs at all (e.g., Dropper). The LFB Class definition MUST specify the number of outputs (or output types) of the LFB. In case topological encoding is used, the output group should count as one entry in the output specification, but the entry should indicate that instantiation of the output is allowed. For illustration, consider the following hypothetical LFB. +------------------+ | UNPROC +--> | | | PKTOUT_1 +--> \ --> PKTIN PKTOUT_2 +--> | | . + . | Output group | . + . | | PKTOUT_N +--> / +------------------+ Example LFB The LFB above has two types of outputs, one of which can be instantiated to form an output group. For each LFB output (group) the following MUST be specified: o Symbolic name of the output. Example: "UNPROC". In case of an output group, the symbolic name is the prefix used to construct unique symbols for each output instance. Example: "PKTOUT_". Note that the symbolic name must be unique only within the scope of the LFB class. Haraszti & Blake Expires December 30, 2003 [Page 18] Internet-Draft ForCES FE Functional Model Elements July 2003 o Brief synopsis of the output. Example: "Normal packet output". o Indication of whether this output is an output group (i.e., if it is allowed to be instantiated). o List of allowed frame formats. Example: "{FRAME_IPV4, FRAME_IPV6}" Note that this list should refer to symbols specified in the frame definition of the model library (see Section 6.3). In addition to the list of frame types, additional information MAY BE provided on what fields of the frames the LFB may have modified. o List of emitted (generated) metadata. Example: {META_CLASSID, META_IFID}. This list should refer to symbols specified in the metadata definition of the model library (see Section 6.2). For each generated metadata it should be specified whether the metadata is always generated or generated only in certain conditions. This information is important when assessing compatibility between LFBs. 6.4.4 LFB Resources The operational state of the LFB is modeled by the variables of the LFB, collectively called resources. Resource types will include the following four categories: 1. Capability resources (see Section 7.4 for more on LFB capabilities). Examples: * Supported optional features of the LFB class * Maximum number of configurable outputs for an output group * Metadata pass-through limitations of the LFB * Maximum size of configurable resource tables * Supported access modes of certain resources (see below) 2. Configured operational resources. Examples: * Configurable flags and switches selecting between operational modes of the LFB * Lookup tables * Number of outputs in an output group Haraszti & Blake Expires December 30, 2003 [Page 19] Internet-Draft ForCES FE Functional Model Elements July 2003 * Metadata CONSUME vs. LOOK_AT mode selector 3. Statistical resources (collected by the FE, provided for reading to the CE). Examples: * Packet and byte counters * Other event counters 4. Internally maintained state. Examples: * Internal state of a protocol machine * Content of a protocol table (such as content of an ARP table maintained by the ARP protocol LFB). Some of the resources will be generically available in all LFBs while others will be specific to the LFB class. Examples of generic LFB resources are: o LFB enable/disable/by-pass switch o LFB class ID (in case the LFB is self-descriptive) o LFB class inheritance information (see Section 5.12) o Number and type of inputs (in case the LFB is self-descriptive) o Number and type of outputs (in case the LFB is self-descriptive) o Number of current outputs for each output group o Metadata CONSUME/LOOK_AT mode selector There may be various restrictions on what the CE can do with an LFB resource (access permission). The following categories may be supported: o Read-only resources o Read-write resources o Write-only resources. This could be any configurable data for which reading capability is not provided to the CEs. o Read-reset resources. The CE can read and reset this resource, but cannot set it to an arbitrary value. Example: Counters. Haraszti & Blake Expires December 30, 2003 [Page 20] Internet-Draft ForCES FE Functional Model Elements July 2003 o Firing-only resource. A write attempt to this resource will trigger some specific actions in the LFB, but the actual value written is ignored. The LFB class may define more than one possible mode for a given resource (for example, write-only and read-write), in which case it is left to the actual implementation to pick one of the modes. In this case a corresponding capability parameter must inform the CE of which mode the actual LFB instance supports. The resources of the LFB class must be defined as a list. For each resource the following information MUST be provided: o Reference to the data type (e.g., specified in the generic data type block of the model library or in an LFB specific data type block). o Access right (or rights in case more than one mode is allowed). o Additional range restrictions (i.e., beyond what is specified by the data type definition). o Default value. Applied when the LFB is initialized or reset. The actual structuring of LFB resources requires further study. 6.4.5 LFB Exceptions "Throwing an exception" refers to a FE sending an asynchronous ForCES protocol message to the CE(s) upon encountering a special condition. The message payload may or may not contain the packet that was being processed when the condition was encountered. An LFB class specification MUST define what types of exceptions the LFB is capable of throwing. Hence this information should be part of the model. Some exception types may be optional. The CE should be able to detect (query) what exception types from the LFB class list are actually supported by the LFB instance on a given FE. This information MAY BE encoded as a special type of capability parameter (see Section 7.4 more on LFB capabilities) or MAY BE embedded in the generic ForCES protocol. The CE must be able to selectively subscribe to an arbitrary subset of the exceptions supported by the LFB instance. The selection may be controlled by setting/clearing some flags regarded as special resources of the LFB, or this feature may be embedded in the generic Haraszti & Blake Expires December 30, 2003 [Page 21] Internet-Draft ForCES FE Functional Model Elements July 2003 ForCES protocol. 6.4.6 LFB Operational Specification This section of the model should verbally describe what the LFB does. This will most likely be embedded in an (unstructured) text field in the model. 7 The Post-Association Components of the FE Functional Model The actual model of the forwarding plane in a given NE is something the CE must learn and control via communicating with the FEs. Most of this communication will happen in the post-association phase using the ForCES protocol. The following types of information must be exchanged between CEs and FEs: 1. FE topology and configuration capabilities 2. FE capability declaration 3. LFB topology (per FE) and configuration capabilities 4. LFB capability declaration 5. LFB resource state 6. LFB resource manipulation 7. LFB topology reconfiguration 8. FE topology reconfiguration Items 1 through 5 are query exchanges, the main flow of information being from the FEs to the CEs. Items 1 through 4 are typically queried by the CE(s) in the beginning of the post-association (PA) phase, though they may be repeatedly queried at any time in the PA phase. Item 5 (state query) will be used at the beginning of the PA phase, and often frequently during the PA phase (especially for the query of statistical counters). Items 6, 7, and 8 are "command" type of exchanges, the main flow of information being from the CEs to the FEs. From these three, only 6 (the LFB re-configuration commands) are expected to be used frequently. LFB topology re-configuration is needed only if dynamic LFB topologies are supported by ForCES, and it is expected to be used Haraszti & Blake Expires December 30, 2003 [Page 22] Internet-Draft ForCES FE Functional Model Elements July 2003 infrequently. FE topology re-configuration is needed only if dynamic FE topologies are supported by ForCES, and it will be a very infrequent operation. The relationship between the model library and the eight post-association messages are visualized in the following figure: +--------+ ..........-->| CE | /----\ . +--------+ \____/ Model library . ^ | | |................ 1, 2 | | 6, 7, 8 | | (off-line) . 3, 4, 5 | | \____/ . | v . +--------+ e.g. RFCs ..........-->| FE | +--------+ The actual encoding of these messages is beyond the scope of the model. Their discussion is nevertheless important here for the following reasons: o These PA model components have considerable impact on the model library. For example, some of the above information can be represented as resources of the LFBs, in which case such resources must be defined in the library. o The understanding of the type of information that must be exchanged between the FEs and CEs can help to select the appropriate protocol format (such as XML, TLVs, or SNMP?) and the actual encoding. o Understanding the frequency of these types of messages should influence the selection of the protocol format (efficiency considerations). The remaining sub-sections of this section address each of the above components. 7.1 FE Topology and Configuration Capabilities The "nodes" of the FE topology will be discovered by the CEs in the pre-association phase, but the actual reachability information ("edges") will most likely come during the PA phase. Since this information is not LFB specific, this exchange can be made part of the ForCES base protocol. Alternatively, a generic set of ForCES payload commands can be defined for this purpose. Haraszti & Blake Expires December 30, 2003 [Page 23] Internet-Draft ForCES FE Functional Model Elements July 2003 In case support for configurable FE interconnects is a desirable feature, a proper model must be found to describe the grade of configurability (i.e., the reachability of one FE from another FE). This issue is currently considered an open issue (and was discussed in Section 5.8). 7.2 FE Capability Declarations FEs will have many types of limitations. Some of the limitations must be expressed to the CEs as part of the model. The CEs must be able to query these capabilities on a per-FE basis. Examples: o Metadata passing capabilities of the FE. Understanding such capabilities will help the CE to evaluate the feasibility of LFB topologies, and hence to determine the availability of certain services. o Global resource query limitations (applicable to all LFBs of the FE). o Any other "global" limitations. 7.3 LFB Topology and Topology Configurability The ForCES protocol must provide the means for the CEs to discover the current set of LFB instances in a FE and the interconnections between the LFBs within the FE. In addition, there should be sufficient information provided on whether the FE supports any CE-initiated (dynamic) changes to the LFB topology, and if so, what are the allowed topologies. This issue has been discussed already in Section 5.9 as an open issue. 7.4 LFB Capability Declaration LFB class specification will define a generic set of capabilities. When a LFB instance is implemented (instantiated) on a vendor's FE, some additional limitations may be introduced. Note that we discuss here only limitations that are within the flexibility of the LFB class specification, that is, the LFB instance will remain compliant with the LFB class specification despite these limitations. For example, certain features of a LFB class may be optional, in which case it must be possible for the CE to determine if an optional feature is supported by a given LFB instance or not. Also, the LFB classes definitions will probably contain very few Haraszti & Blake Expires December 30, 2003 [Page 24] Internet-Draft ForCES FE Functional Model Elements July 2003 quantitative limits (e.g., size of tables), since these limits are typically imposed by the implementation. Therefore, quantitative limitations should always be expressed by capability arguments. To facilitate the flexibility of LFB instances to impose limitations on the generic LFB class model, the LFB class specifications must have a set of capability arguments, and the CE must be able to query the actual capabilities of the LFB via querying the value of such arguments. The capability query will typically happen when the LFB is first detected by the CE. Capabilities need not be re-queried in case of static limitations. In some cases, however, some capabilities may change in time (e.g., as a result of adding/removing other LFBs, or configuring certain resources of some other LFB when the LFBs share physical resources), in which case additional mechanisms must be implemented to inform the CE about the changes. The following two broad types of limitations will exist: o Qualitative restrictions. For example, a standardized multi-field classifier LFB class may define a large number of classification fields, but a given FE may support only a subset of those fields. o Quantitative restrictions, such as the maximum size of tables, etc. The capability parameters that can be queried on a given LFB class will be part of the LFB specification. The capability parameters should be regarded as special resources of the LFB. The actual values of these arguments may be, therefore, obtained using the same resource query mechanisms as used for other LFB resources. Capability resources will typically be read-only arguments, but in certain cases they may be configurable. For example, the size of a lookup table may be limited by the hardware (read-only), in other cases it may be configurable (read-write, within some hard limits). Assuming that capabilities will not change frequently, the efficiency of the protocol/schema/encoding is of secondary concern. 7.5 LFB Resource State (Query) Note that this feature may not be provided by all FEs (or all LFBs of a FE). Some of the possible levels of support are: o FE and/or LFB cannot serve any query request o FE and/or LFB can only serve query requests for statistical information Haraszti & Blake Expires December 30, 2003 [Page 25] Internet-Draft ForCES FE Functional Model Elements July 2003 o FE and/or LFB is capable to serve query requests for a restricted set of resources o FE and/or LFB can serve query requests for any resources configured The query capabilities of the FE and the LFB must be expressed in the FE capability and LFB capability sections of the model, respectively. The ForCES protocol and the data schema/encoding conveyed by the protocol must together satisfy the following requirements: o FE selection. This is primarily to refer to a single FE, but referring to a group or all FEs may optional be supported. o LFB instance selection. This is primarily to refer to a single LFB instance of an FE, but optionally addressing of a group of LFBs may be supported. o Addressing individual resource components of the LFB o Efficient encoding and decoding of the addressing info and the configured data. o Efficient data transmission of the resource state over the wire (to minimize communication load on the CE-FE link). 7.6 LFB Resource Manipulation This is a place-holder for all operations that the CE will use to populate, manipulate, and delete resources of the LFB instances on the FEs. The ForCES protocol and the data schema/encoding conveyed by the protocol must together provide the following features of LFB resource manipulation: o FE selection. This is primarily to refer to a single FE, but referring to a group or all FEs may optionally be supported. o LFB instance selection. This is primarily to refer to a single LFB instance of a FE, but optional addressing of a group of LFBs may be supported. o Addressing individual resource components of the LFB. o Efficient encoding and decoding of the addressing info and the Haraszti & Blake Expires December 30, 2003 [Page 26] Internet-Draft ForCES FE Functional Model Elements July 2003 configured data. o Efficient data transmission of the above info on the wire (to minimize communication load on the CE-FE link). Support for various levels of feedback from the FE to the CE (e.g., request received, configuration completed), as well as multi-resource configuration transactions with atomic commit and rollback, may be necessary in some circumstances, but are left for further study. 7.7 LFB Topology Re-configuration This feature is needed only if the LFB topology is configurable on a given FE. Operations that will be needed: o Create a new instance of a given LFB class on a given FE. o Connect a given output of LFB x to the given input of LFB y. o Disconnect: remove a link between a given output of a LFB and a given input of another LFB. o Delete a given LFB (automatically removing all interconnects to/ from the LFB). 7.8 FE Topology Re-configuration The need for this feature is probably debatable, so this area requires more study. At any rate, FEs cannot be created or deleted on the fly, only the interconnects between FEs may be configurable. The CE may be able to enable/disable individual inter-FE datapath interconnects. 8 Security Considerations None. Haraszti & Blake Expires December 30, 2003 [Page 27] Internet-Draft ForCES FE Functional Model Elements July 2003 References [FWK] Yang, L., Dantu, R. and T. Anderson, "Forwarding and Control Element Separation (ForCES) Framework", December 2002, . [MODEL] Yang, L., Halpern, J., Gopal, R. and R. Dantu, "ForCES Forwarding Element Functional Model 02", March 2003, . [NETLINK2] Salim, J. and R. Haas, "Netlink2 as ForCES protocol", December 2002, . [REQS] Khosravi, H. and T. Anderson, "Requirements for Separation of IP Control and Forwarding", May 2003, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Zsolt Haraszti Ericsson 920 Main Campus Dr, St. 500 Raleigh, NC 27606 US Phone: +1 919 472 9949 EMail: zsolt.haraszti@ericsson.com Steven Blake Ericsson 920 Main Campus Dr, St. 500 Raleigh, NC 27606 US Phone: +1 919 472 9913 EMail: steven.blake@ericsson.com Haraszti & Blake Expires December 30, 2003 [Page 28] Internet-Draft ForCES FE Functional Model Elements July 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Haraszti & Blake Expires December 30, 2003 [Page 29] Internet-Draft ForCES FE Functional Model Elements July 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Haraszti & Blake Expires December 30, 2003 [Page 30]