Alan Crouch Internet Draft Hormuzd Khosravi Document: draft-ietf-forces-applicability- Intel Corp. 04.txt Expires: July 2006 Mark Handley Working Group: ForCES ICIR Avri Doria ETRI Feb 2006 ForCES Applicability Statement Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. Copyright Notice Copyright (C) The Internet Society (2006). 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 Crouch/Handley Expires July 2006 [Page 1]
ForCES Applicability Statement Feb 2006 The ForCES protocol defines a standard framework and mechanism for the interconnection between Control Elements and Forwarding Elements 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 functionality, as well as document applications that would be inappropriate for ForCES. Table of Contents 1. Purpose.........................................................3 2. Overview........................................................3 3. Terminology.....................................................3 4. Applicability to IP Networks....................................3 4.1. Applicable Services...........................................4 4.1.1. Discovery, Capability Information Exchange..................4 4.1.2. Topology Information Exchange...............................5 4.1.3. Configuration...............................................5 4.1.4. Routing Exchange............................................5 4.1.5. QoS Exchange................................................5 4.1.6. Security Exchange...........................................5 4.1.7. Filtering Exchange and Firewalls............................6 4.1.8. Encapsulation, Tunneling Exchange...........................6 4.1.9. NAT and Application-level Gateways..........................6 4.1.10. Measurement and Accounting.................................6 4.1.11. Diagnostics................................................6 4.1.12. CE Redundancy or CE Failover...............................6 4.2. CE-FE Link Capability.........................................7 4.3. CE/FE Locality................................................7 5. Limitations and Out-of-Scope Items..............................7 5.1. Out of Scope Services.........................................8 5.1.1. Label Switching.............................................8 5.1.2. Separation of Control and Forwarding in Multimedia Gateways.8 5.2. Localities....................................................8 6. Security Considerations.........................................9 7. ForCES Manageability............................................9 7.1. NE as an atomic element.......................................9 7.2. NE as composed of manageable elements.........................9 7.3. ForCES Protocol MIB..........................................10 7.3.1. MIB Management of an FE....................................10 7.4. The FEM and CEM..............................................11 8. References.....................................................11 8.1. Normative References.........................................11 8.2. Informative References.......................................12 9. Acknowledgments................................................12 10. Authors' Addresses............................................12 Crouch/Handley Expires July 2006 [Page 2]
ForCES Applicability Statement Feb 2006 1. Purpose The purpose of the ForCES Applicability Statement is to capture the intent of the ForCES protocol designers as to how the protocol should be used. The Applicability Statement will evolve alongside the protocol, and will go to RFC as informational around the same time the as the protocol goes to RFC. 2. Overview The ForCES protocol defines a standard framework and 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. It 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. 3. Terminology A set of terminology associated with ForCES is defined in [3, 4]. That terminology is reused here and the reader is directed to [3, 4] for the following definitions: o CE: Control Element. o FE: Forwarding Element. o ForCES: ForCES protocol. 4. Applicability to IP Networks The purpose of this section is to list the areas of ForCES applicability in IP network devices. Relatively low performance devices may be implemented on a simple processor which performs both control and packet forwarding functionality. ForCES is not applicable for such devices. Crouch/Handley Expires July 2006 [Page 3]
ForCES Applicability Statement Feb 2006 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 scenarios, and applicable topologies in which ForCES may be deployed. 4.1. Applicable Services In this section we describe the applicability of ForCES for the following control-forwarding plane services: o Discovery, Capability Information Exchange o Topology Information Exchange o Configuration o Routing Exchange o QoS Exchange o Security Exchange o Filtering Exchange o Encapsulation/Tunneling Exchange o NAT and Application-level Gateways o Measurement and Accounting o Diagnostics o CE Redundancy or CE Failover 4.1.1.Discovery, Capability Information Exchange 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. Crouch/Handley Expires July 2006 [Page 4]
ForCES Applicability Statement Feb 2006 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. During the discovery phase, CEs and FEs may exchange 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 using ForCES. For example, FE's asynchronously inform the CE of an increase/decrease in available resources or capabilities on the FE. 4.1.2.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. 4.1.3.Configuration ForCES is used to perform FE configuration. For example, CEs set configurable FE attributes such as IP addresses, etc. for their interfaces. 4.1.4.Routing Exchange ForCES may be used to deliver packet forwarding information resulting from CE routing calculations. 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. 4.1.5.QoS Exchange ForCES may be used to exchange QoS capabilities between CEs and FEs. For example, an 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. 4.1.6.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 Crouch/Handley Expires July 2006 [Page 5]
ForCES Applicability Statement Feb 2006 encryption that it is capable of using in an IPsec tunnel. The CE may use ForCES to configure such a tunnel. 4.1.7.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. 4.1.8.Encapsulation, Tunneling Exchange ForCES may be used to exchange encapsulation capabilities of an FE, such as tunneling, and the configuration of such capabilities. 4.1.9.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. 4.1.10.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. However, in other cases it may make more sense for the FE to directly speak SNMP. 4.1.11.Diagnostics ForCES may be used for CE's and FE's to exchange diagnostic information. For example, an FE can send self-test results to the CE. 4.1.12.CE Redundancy or CE Failover ForCES is a master-slave protocol where FE's are slaves and CE's are masters. Basic mechanisms for CE redundancy/failover are provided in ForCES protocol. Broad concepts such as implementing CE Redundancy, CE Failover, and CE-CE communication, while not precluded by the ForCES architecture, are considered outside the scope of ForCES protocol. ForCES protocol is designed to handle CE- FE communication, and is not intended for CE-CE communication. Crouch/Handley Expires July 2006 [Page 6]
ForCES Applicability Statement Feb 2006 4.2.CE-FE Link Capability When using ForCES, the bandwidth of the CE-FE link is a consideration, and cannot be ignored. For example, sending a full routing table of 110K routes is reasonable over a 100Mbit Ethernet interconnect, but could be non-trivial over a lower-bandwidth link. ForCES should be sufficiently future-proof to be applicable in scenarios where routing 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 routing tables. 4.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 susceptible to external disruption that does not also affect the CEs and/or FEs. 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 reliability of the device should not be significantly reduced by the separation of control and forwarding functionality. ForCES is applicable in localities consisting of control and forwarding elements which are either components in the same physical box, or are separated at most by one local network hop (historically referred to as "Very Close" localities). Example: 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 this locality, the majority of the data traffic being forwarded typically does not traverse the same links as the ForCES control traffic. 5. 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 Crouch/Handley Expires July 2006 [Page 7]
ForCES Applicability Statement Feb 2006 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. 5.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). 5.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 [8]. For more information on GSMP, see [7]. 5.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]. 5.2.Localities ForCES protocol was intended to work within the localities described in the last section. Outside these boundaries, care must be taken or the protocol may not work right. Examples of localities where ForCES was not originally intended to be used: o Localities where there are multiple hops between CE and FE. o Localities where 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- negligible probability. 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. Crouch/Handley Expires July 2006 [Page 8]
ForCES Applicability Statement Feb 2006 6. Security Considerations The security of ForCES protocol will be addressed in the Protocol Specification [6]. For security requirements, see architecture requirement #5 and protocol requirement #2 in the Requirements Draft [3]. The ForCES protocol assumes that the CE and FE are in the same administration, and have shared secrets as a means of administration. Whilst it might be technically feasible to have the CE and FE administered independently, we strongly discourage such uses, because they would require a significantly different trust model from that ForCES assumes. 7. ForCES Manageability From the management perspective, an NE can be viewed in at least two ways. From one perspective, it is a single network element, specifically a router that needs to be managed in essentially the same way any router is managed. From another perspective element management can view the individual entities and interfaces that make of a ForCES NE. 7.1.NE as an atomic element From the ForCES requirements RFC [RFC 3654], Section 4, point 4: A NE MUST support the appearance of a single functional device. As a single functional device a ForCES NE runs protocols and each of the protocols has it own existing manageability aspects which are document elsewhere. As a router it would also have a configuration interface. When viewed in this manner, the NE is controlled as single routing entity and no new management beyond what is already available for routers and routing protocols would be required for a ForCES NE. 7.2.NE as composed of manageable elements When viewed as a decomposed set of elements from the management perspective, the ForCES NE is divided into a set of one of more Control Elements, Forwarding Elements and the interfaces between them. The interface functionality between the CE and the FE is provided by the ForCES protocol. As with all IETF protocols a MIB is provided for the purposes of managing the protocol. Additionally the architecture make provision for configuration control of the individual CEs and FEs. This is handled by elements names FE manager and the CE manager. Specifically from the ForCES requirements Crouch/Handley Expires July 2006 [Page 9]
ForCES Applicability Statement Feb 2006 RFC [RFC 3654], Section 4, point 4: However, external entities (e.g., FE managers and CE managers) MAY have direct access to individual ForCES protocol elements for providing information to transition them from the pre-association to post-association phase. 7.3.ForCES Protocol MIB From the ForCES MIB RFC [TBD], section X The ForCES MIB is a primarily read-only MIB that captures information related to the ForCES protocol. This includes state information about the associations between CE(s) and FE(s) in the NE. The ForCES MIB does not include information that is specified in other MIBs, such as packet counters for interfaces, etc. More specifically, the information in the ForCES MIB relative to associations includes: - identifiers of the elements in the association - state of the association - configuration parameters of the association - statistics of the association 7.3.1.MIB Management of an FE While it is possible to manage a FE from a element manager, several requirements relating to this have been included in the ForCES Requirements. From the ForCES Requirements [RFC 3654], Section 4, point 14: 1. The ability for a management tool (e.g., SNMP) to be used to read (but not change) the state of FE SHOULD NOT be precluded. 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to change the state of a FE in a manner that affects overall NE behavior without the CE being notified. The ForCES Requirements [RFC 3746], Section 5.7, goes further in discussing the manner in which FEs should handle management requests that are specifically directed to the FE: RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP". In general, for the post-association phase, most external Crouch/Handley Expires July 2006 [Page 10]
ForCES Applicability Statement Feb 2006 management tasks (including SNMP) should be done through interaction with the CE in order to support the appearance of a single functional device. Therefore, it is recommended that an SNMP agent be implemented by CEs and that the SNMP messages received by FEs be redirected to their CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here such that CEs act in the role of master agent to process SNMP protocol messages while FEs act in the role of subagent to provide access to the MIB objects residing on FEs. AgentX protocol messages between the master agent (CE) and the subagent (FE) are encapsulated and transported via ForCES, just like data packets from any other application layer protocols. 7.4.The FEM and CEM Though out of scope for the initial ForCES specification effort, the ForCES architecture include two entities, the CE Manager (CEM) and the FE Manager (FEM) From the ForCES Protocols Specification [RFCXXXX] CE Manager (CEM) - A logical entity responsible for generic CE management tasks. It is particularly used during the pre- association phase to determine with which FE(s) a CE should communicate. FE Manager (FEM) - A logical entity responsible for generic FE management tasks. It is used during pre-association phase to determine with which CE(s) an FE should communicate. 8. References 8.1.Normative 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. Khosravi, et al., Requirements for Separation of IP Control and Forwarding, RFC 3654, November 2003. 4. L. Yang, et al., ForCES Architectural Framework, RFC 3746, April 2004. Crouch/Handley Expires July 2006 [Page 11]
ForCES Applicability Statement Feb 2006 5. Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,and S. Blake, "ForCES Forwarding Element Model", Feb. 2005. 6. A. Doria, et al., ForCES Protocol Specification, draft-ietf- forces-protocol-06.txt, December 2005. 8.2.Informative References 7. A. Doria, F. Hellstrand, K. Sundell, T. Worster, General Switch Management Protocol (GSMP) V3, RFC 3292, June 2002. 8. Andersson et al., "LDP Specification" RFC 3036, January 2001 9. F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November 2000 9. Acknowledgments The authors wish to thank Jamal Hadi Salim, Vip Sharma, and many others for their invaluable contributions. 10. Authors' Addresses Alan Crouch Intel 2111 NE 25th Avenue Hillsboro, OR 97124 USA Phone: +1 503 264 2196 Email: alan.crouch@intel.com Hormuzd Khosravi Intel 2111 NE 25th Avenue Hillsboro, OR 97124 Phone: 1-503-264-0334 Email: hormuzd.m.khosravi@intel.com Mark Handley ICIR 1947 Center Street, Suite 600 Berkeley, CA 94708, USA Email: mjh@icsi.berkeley.edu Avri Doria ETRI Lulea University of Technology Lulea, Sweden Crouch/Handley Expires July 2006 [Page 12]
ForCES Applicability Statement Feb 2006 Phone: +46 73 277 1788 Email: avri@acm.org Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Crouch/Handley Expires July 2006 [Page 13]
