Internet Draft T. Anderson Expiration: August 2001 Intel File: draft-anderson-forces-req-01.txt February 2001 Requirements for Separation of IP Control and Forwarding draft-anderson-forces-req-01.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 [RFC-2119]. 1. Abstract This document defines a set of requirements for mechanisms to logically separate the control and data forwarding planes of an IP network element (NE). 2. Introduction Anderson [Page 1]
Internet Draft ForCES Requirements October 2000 An IP NE is composed of numerous logically separated entities that cooperate to provide router or IP switch functionality and yet appear as a normal integrated network element to external entities. Two types of NE components exist: control-plane components and forwarding-plane components. In general, forwarding-plane components are ASIC and network-processor-based devices that handle all fast path operations while control-plane components handle slow path functionality such as routing protocols and signaling. A standard set of mechanisms for connecting these components provides increased scalability and allows the control and forwarding planes to evolve independently. A router can exemplify the concept and value of separate control and forwarding planes. The architecture of a router is composed of two main parts. These components, while inter-dependent, perform functions that are largely independent of each other. At the bottom is the forwarding hardware that operates in the data-forwarding plane and is responsible for per-packet processing and forwarding. This hardware is typically implemented in the form of a set of ASICs or network processors. Above the forwarding plane is the network operating system that is responsible for operations in the control plane. In the case of a router or switch, the network operating system runs routing, signaling and control protocols (e.g., RIP, OSPF and RSVP) and dictates the forwarding behavior of the underlying hardware by manipulating forwarding tables, per-flow QoS tables and access control lists for the forwarding hardware. Typically, the architecture of these devices combines all of this functionality into a single functional whole. 3. Architectural Requirements The chief components of a NE architecture are the Control Element (CE) and the Forwarding Element (FE). The CE is mainly responsible for operations such as routing protocol processing, signaling, and network control protocols. The CE dictates the behavior of the underlying FE(s) by manipulating forwarding tables, per-flow QoS tables, and access control lists for the forwarding interfaces. The FE operates in the forwarding plane and is responsible chiefly for per-packet processing and handling. Below is an ASCII diagram illustrating an example NE composed of one CE and two FEs connected by a switching fabric. Anderson Expires April 2001 [Page 2]
Internet Draft ForCES Requirements October 2000 ------------------------------- | NE | | ------------ | | | CE | | | ------------ | | | | | | | | ------------ | | | SWITCH | | | | FABRIC | | | ------------ | | / \ | | / \ | | ----------- ----------- | | | FE | | FE | | | ----------- ----------- | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------- | | | | | | | | | | | | | | | | The following are the architectural requirements: 1) CEs and FEs MUST be able to be connected by a variety of interconnect technologies. Examples of interconnect technologies used in current architectures include Ethernet connections, proprietary backplanes, and ATM (cell) fabrics. 2) Packets arriving at an ingress FE may eventually need to exit the NE from a port on a different FE. These packets MUST be forwarded between FEs until they reach the egress FE. 3) FEs SHOULD be designed to maintain the illusion that the NE is a single functional device. For example, the TTL of the packet must be decremented only once as traverses the NE regardless of how many FEs through which it passes. 4) A control plane that is physically separated from its forwarding planes MUST use one or more protocols to communicate with them. 5) There SHOULD be a mechanism that FEs and CEs can utilize to automatically find each other without any a priori configuration. 6) There MUST be a mechanism by which FEs can quickly determine when their connection with the CE has been severed. When the control connection is lost, the FE MUST transition to the down state and stop functioning until the control connection has been reestablished. Anderson Expires April 2001 [Page 3]
Internet Draft ForCES Requirements October 2000 4. Protocol Requirements This section specifies the requirements that a set of protocols MUST meet to connect a control element to forwarding elements. 1) NE Membership Discovery In order for the FE and CE components of a network element to act in concert, they will need to be aware of the existence of each other. For example, the CE MUST be aware of the existence of every FE in order to control them. Likewise, each FE MUST know the CE it should connect to for its configuration. To reduce the management burden, membership discovery SHOULD be an automatic process not requiring any a priori FE configuration. Membership discovery can be a static process run once at boot-up or it can be a continual process in which FEs and CEs can join and leave the NE at run-time. When a component joins or leaves, all the other components in the NE that need to be aware of this MUST be notified. An authentication mechanism SHOULD be used to determine whether a component has the authorization to join the NE. 2) Topology Discovery In order for the CE to make intelligent decisions about how to forward traffic that comes in one FE and exits through another, the CE MUST be aware of how the FEs in the NE are interconnected. We call this FE topology discovery. 3) Support for different types of FEs The protocol(s) MUST be able to support different types of FEs such as L2 and L3 switches. That is to say that the CE MUST be able to configure the available FEs regardless of their type. 4) Port Configuration The protocol(s) MUST support the ability to configure attributes of ports such as IP addresses and administrative status. 5) Packet Redirection A FE MUST redirect packets to the CE that contain control and signaling information, such as routing protocol updates, configuration management information, and QoS reservations. 6) Reliable transport Since the CE is in control of its FEs, the CE MUST be sure that its configuration changes are reliably delivered to FEs. Similarly, if the FE requests an item of configuration from the CE, the FE will in many cases REQUIRE a response to that request before it can process some flow of packets. Thus, a FEÆs request of its CE MUST also be reliable. 7) Support for QoS provisioning The CE/FE separation protocol(s) MUST allow the CE to determine the QoS capabilities (e.g., policing, shaping, queuing) of FEs. Furthermore, the separation protocol(s) MUST allow the CE to Anderson Expires April 2001 [Page 4]
Internet Draft ForCES Requirements October 2000 configure the provided QoS mechanisms such as IntServ [RFC1633] and DiffServ [RFC2475]. 8) Support for Filter Installation and Capability Discovery For FEs that support packet classification functionality, the CE MUST be able to install filters and actions to be performed when a packet matches. Rather than assume or mandate that each FE have the same filtering capabilities, FEs MUST be able to provide whatever filtering capabilities they desire (including no filtering capability). In order for the CE to know what types of filters it can install on each FE, the CE MUST be able to query the FEÆs filtering capabilities. This querying must be facilitated by a filter capability discovery mechanism. 9) Support for Congestion Management The CE/FE separation protocol(s) MUST support the ability for the CE to query which congestion management mechanisms a FE provides. Furthermore, the protocol(s) MUST allow the CE to configure the provided congestion management mechanisms. 10) Support for Installing IP Forwarding Tables The CE MUST be able to download IP forwarding tables to FEs. 11) Support for Secure Communication Since FE configuration contains information critical to the functioning of a network (such as IP forwarding tables) and may contain information related to SLAs, any protocols defined MUST support a method of securing communication between FEs and CEs to ensure that information is delivered securely in an unmodified form. Furthermore, to prevent unauthorized FEs from joining the NE and to prevent unauthorized configuration of FEs, FEs and CEs MUST be able to authenticate one another. 12) Support for Event Notification The CE MUST be notified of asynchronous events (e.g., link up or link down) and exceptions that occur in FEs (e.g., out of memory). 13) Support for Vendor-specific extensions The protocol(s) SHOULD be extensible so that vendor specific functionality can be added. 14) Scalability The protocol(s) MUST allow a CE to control from one to tens of FEs. 15) Support Network Management Requirements The protocol(s) MUST be able to support network management requirements for querying and monitoring statistics. 5. Security Considerations See protocol requirement #10. Anderson Expires April 2001 [Page 5]
Internet Draft ForCES Requirements October 2000 6. References [RFC1633] R. Braden, D. Clark, and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, ISI, MIT, and PARC, June 1994. [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC2475] M. Carlson, W. Weiss, S. Blake, Z. Wang, D. Black, and E. Davies, "An Architecture for Differentiated Services", RFC 2475, December 1998. 7. Authors' Addresses Todd A. Anderson Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 712 1760 Email: todd.a.anderson@intel.com Anderson Expires April 2001 [Page 6]