Internet Engineering Task Force ForCES WG INTERNET-DRAFT A. Crouch/Intel draft-crouch-forces-applicability-00.txt Mark Handley/ACIRI 5 November 2001 Expires: May 2002 ForCES Applicability Statement Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract The ForCES protocol defines a standard mechanism for the interconnection between Control Elements and Forwarding Engines in IP routers and similar devices. In this document we describe the applicability of the ForCES model and protocol. We provide example deployment scenarios and fucntionality, as well as document applications that would be inappropriate for ForCES. Crouch/Handley [Page 1]
INTERNET-DRAFT Expires: May 2002 November 2001 1. Overview The ForCES protocol defines a standard mechanism for the exchange of information between the logically separate functionality of the control and data forwarding planes of IP routers and similar devices. It focuses on the communication necessary for separation of control plane functionality such as routing protocols, signaling protocols, and admission control from data forwarding plane per-packet activities such as packet forwarding, queuing, and header editing. This document defines the applicability of the ForCES mechanisms. The document describes types of configurations and settings where ForCES is most appropriately applied. This document also describes scenarios and configurations where ForCES would not be appropriate for use. 2. Terminology CE: Control Element. The processor or processors providing the control plane functionality in an IP router and similar devices. The CE will normally run routing protocols, signalling protocols, admission control mechanisms, and similar functionality. FE: Forwarding Engine. A box, card, or processor that forwards IP packets. An FE will comprise one or more network interfaces, and typically provide route lookup, packet filtering, classification, queuing and other functionality associated with the forwarding or discard of packets. ForCES: As used in this document, ForCES refers to the specific protocol and associated conventions used for communication between the CE and a set of FEs. 3. Applicability to IP Networks The purpose of this section is to list the areas of ForCES applicability in IP network devices. Relatively low perforance devices may be implemented on a single processor which performs both control and packet forwarding functionality. ForCES could be used but is not mandated for such devices. Higher performance devices typically distribute work amongst interface processors, and these devices (FEs) therefore need to communicate with the control element(s) to perform their job. ForCES provides a standard way to do this communication. The remainder of this section lists the applicable services which ForCES may support, applicable FE functionality, applicable CE-FE link Crouch/Handley Section 3. [Page 2]
INTERNET-DRAFT Expires: May 2002 November 2001 scenarios, and applicable localities in which ForCES may be deployed. 3.1. Applicable Services In this section we describe the applicability of ForCES for the following control-forwarding plane services: o Discovery o Capability o Information Exchange o Topology Information Exchange o Port Configuration, o Routing Exchange o QoS Exchange o Security Exchange o Filtering Exchange o Encapsulation/Tunneling Exchange 3.1.1. Discovery Discovery is the process by which CEs and FEs learn of each other's existence. ForCES assumes that CEs and FEs already know sufficient information to begin communication in a secure manner. The ForCES protocol is only applicable after CEs and FEs have found each other. ForCES makes no assumption about whether discovery was performed using a dynamic protocol or merely static configuration. 3.1.2. Capability Information Exchange The ForCES protocol may be used for CEs and FEs to exchange their capability information with each other. For example, the FEs may express the number of interface ports they provide, as well as the static and configurable attributes of each port. In addition to initial configuration, the CEs and FEs may also exchange dynamic configuration changes. For example, FE's asynchronously inform the CE of an increase/decrease in available resources or capabilities on the FE. Crouch/Handley Section 3.1.2. [Page 3]
INTERNET-DRAFT Expires: May 2002 November 2001 3.1.3. Topology Information Exchange In this context, topology information relates to how the FEs are interconnected with each other with respect to packet forwarding. Whilst topology discovery is outside the scope of the ForCES protocol, a standard topology discovery protocol may be selected and used to "learn" the topology, and then the ForCES protocol may be used to transmit the resulting information to the CE. 3.1.4. Port Configuration ForCES is used to perform Port configuration. For example, CEs set configurable Port attributes such as IP addresses. 3.1.5. Routing Exchange ForCES may be used to deliver packet forwarding information resulting from routing calculations to CEs. For example, CEs may send forwarding table updates to the FEs, so that they can make forwarding decisions. FEs may inform the CE in the event of a forwarding table miss. 3.1.6. QoS Exchange ForCES may be used to exchange QoS capabilities between CEs and FEs. For example, a FE may express QoS capabilities to the CE. Such capabilities might include metering, policing, shaping, and queuing functions. The CE may use ForCES to configure these capabilities. 3.1.7. Security Exchange ForCES may be used to exchange Security information between CEs and FEs. For example, the FE may use ForCES to express the types of encryption that it is capable of using in an IPsec tunnel. The CE may use ForCES to configure such a tunnel. 3.1.8. Filtering Exchange and Firewalls ForCES may be used to exchange filtering information. For example, FEs may use ForCES to express the filtering functions such as classification and action that they can perform, and the CE may configure these capabilities. Crouch/Handley Section 3.1.8. [Page 4]
INTERNET-DRAFT Expires: May 2002 November 2001 3.1.9. Encapsulation, Tunneling Exchange ForCES may be used to exchange encapsulation capabilities of an FE, such as tunneling, and the configuration of such capabilities. 3.1.10. NAT and Application-level Gateways ForCES may be used to exchange configuration information for Network Address Translators. Whilst ForCES is not specifically designed for the configuration of application-level gateway functionality, this may be in scope for some types of application-level gateways. 3.1.11. Measurement and Accounting ForCES may be used to exchange configuration information regarding traffic measurement and accounting functionality. In this area, ForCES may overlap somewhat with functionality provided by alternative network management mechanisms such as SNMP. In some cases ForCES may be used to convey information to the CE to be reported externally using SNMP. 3.2. CE-FE Link Capacity When deploying ForCES, the bandwidth of the CE-FE link is a consideration, and cannot be ignored. For example, sending a full forwarding table of 110K routes is reasonable over a 100Mbit Ethernet interconnect, but is non-trivial over a T1 line (which could occur in a Close Locality (see 3.3.2). ForCES should be sufficiently future-proof to be applicable for deployment in scenarios where forwarding tables grow to several orders of magnitude greater than their current size (approximately 100K routes). However, we also note that not all IP routers need full forwarding tables. 3.3. CE/FE Locality We do not intend ForCES to be applicable in configurations where the CE and FE are located arbitrarily in the network. In particular, ForCES is intended for environments where one of the following applies: o The control interconnect is some form of local bus, switch, or LAN, where reliability is high, closely controlled, and not succeptable to external disruption that does not also affect the CEs and/or FEs. Crouch/Handley Section 3.3. [Page 5]
INTERNET-DRAFT Expires: May 2002 November 2001 o The control interconnect shares fate with the FE's forwarding function. Typically this is because the control connection is also the FE's primary packet forwarding connection, and so if that link goes down, the FE cannot forward packets anyway. The key guideline is that the reliablility of the device should not be significantly reduced by the separation of control and forwarding functionality. Taking this into account, ForCES is applicable in the following CE/FE localities in IP networks: o Very Close Localities. o Close Localities 3.3.1. Very Close Localities Very Close localities consist of control and forwarding elements which are either components in the same physical box, or are separated at most by one local network hop. An example of a Very Close locality is a network element with a single control blade, and one or more forwarding blades, all present in the same chassis and sharing an interconnect such as Ethernet or PCI. In Very Close localities, the data traffic being forwarded typically does not traverse the same links as the ForCES control traffic. 3.3.2. Close Localities Close localities consist of control and forwarding separation for IP forwarding devices where the control and forwarding elements are in close proximity. The definition of "close proximity" is deliberately ambiguous, but might include devices located in the same room, or devices separated by only a very small number of IP hops. Note that to satisfy the reliability requirements, if these is more than one IP hop between a CE and an FE, these hops will not normally be dynamically routed, as in the general case this would not satisfy the constraints above. A specific example of a Close locality is an FE that is located remotely as Customer Premise Equipment (CPE), and a CE located in their Internet Service Provider's facilties . This is an extreme example of the applicability of ForCES. Note that natural fate- sharing exists between the CE and FE. A potentially unreliable link connects the CE and the FE, but if that link were lost, the FE would stop forwarding to and from the ISP, irrespective of the location of the CE. However, if the FE Crouch/Handley Section 3.3.2. [Page 6]
INTERNET-DRAFT Expires: May 2002 November 2001 were also required to forward traffic between subnets at the customer premises, this would not satisfy the fate-sharing constraint, as local forwarding would also cease when the link to the ISP fails. Note that not all ForCES functionality may be possible in Close localities. In particular, if the scenario and traffic conditions call for a large amount of ForCES traffic, the network between the CE and FE may not have sufficient capacity to handle the control traffic. Designers considering using ForCES in Close Localities need to take this into account, and ensure that such eventualities do not arise. Also, as the control traffic may share network links with data traffic, ForCES traffic will need to be given priority access to that capacity. Typically this priority needs to be even higher priority than that of the CE's routing protocol traffic. 4. Limitations and Out-of-Scope Items ForCES was designed to enable logical separation of control and forwarding planes in IP network devices. However, ForCES is not intended to be applicable to all services or to all possible CE/FE localities. The purpose of this section is to list limitations and out-of-scope items for ForCES. 4.1. Out of Scope Services The following control-forwarding plane services are explicitly not addressed by ForCES: o Label Switching o Multimedia Gateway Control (MEGACO). 4.1.1. Label Switching Label Switching is the purview of the GSMP Working Group in the Sub- IP Area of the IETF. GSMP is a general purpose protocol to control a label switch. GSMP defines mechanisms to separate the label switch data plane from the control plane label protocols such as LDP [7]. For more information on GSMP, see [6]. Crouch/Handley Section 4.1.1. [Page 7]
INTERNET-DRAFT Expires: May 2002 November 2001 4.1.2. Separation of Control and Forwarding in Multimedia Gateways MEGACO defines a protocol used between elements of a physically decomposed multimedia gateway. Separation of call control channels from bearer channels is the purview of MEGACO. For more information on MEGACO, see [9]. 4.2. Localities Examples of network localities that are not appropriate for ForCES are: o Localities where there are a large number of hops between CE and FE. Typically three hops might be considered an upper bound. o Localities where the hops between the CE and FE are dynamically routing using IP routing protocols. o Localities where the loss of the CE-FE link is of non-negligable probability, and where if the CE were co-located with the FE, useful packet forwarding would have been able to continue despite the loss of the link. o Localities where two or more FEs controlled by the same CE cannot communicate, either directly, or indirectly via other FEs controlled by the same CE. 5. Security Considerations The security of ForCES protocol will be addressed in the Protocol Specification [5]. For security requirements, see architecture requirement #5 and protocol requirement #2 in the Requirements Draft [1] described in the Framework draft [3]. 6. References [1] Anderson, T et. al., "Requirements for Separation of IP Control and Forwarding", draft-anderson-forces-req-02.txt, Intel Corp, September 2001. [2] Hadi Salim, J et. al., "Netlink as an IP Services Protocol", draft- salim-netlink-jhsk-01.txt, Znyx Networks, September 2001. [3] ForCES Forwarding Element Functional Model (to- be-written: may be merged with an Architecture/Framework document) [4] Definition of Controlled Objects in ForCES Forwarding Element Crouch/Handley Section 6. [Page 8]
INTERNET-DRAFT Expires: May 2002 November 2001 Functional Model (to-be-written? Not clear we still need this - the charter refers to it) [5] ForCES Protocol Specification (to-be-written) [6] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General switch Management Protocol V3," Internet Draft draft-ietf-gsmp-06.txt, July 2000. work in progress [7] Andersson et al., "LDP Specification" RFC 3036, January 2001 [8] Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [9] F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November 2000 7. Author's Addresses Alan Crouch Intel Corp. 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 2196 Email: alan.crouch@intel.com Mark Handley ICSI 1947 Center Street, Suite 600 Berkeley, CA 94708, USA Email: mjh@icsi.berkeley.edu Crouch/Handley Section 9.1. [Page 10]
