ForCES Applicability Statement
draft-ietf-forces-applicability-09

Abstract

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.

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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.”

This Internet-Draft will expire on December 29, 2010.

Copyright Notice

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Table of Contents

1.  Purpose
2.  Overview
3.  Terminology
4.  Applicability to IP Networks
    4.1.  Applicable Services
        4.1.1.  Association, Capability Discovery and Information Exchange
        4.1.2.  Topology Information Exchange
        4.1.3.  Configuration
        4.1.4.  Routing Exchange
        4.1.5.  QoS Capabilities Exchange and Configuration
        4.1.6.  Security Exchange
        4.1.7.  Filtering Exchange and Firewalls
        4.1.8.  Encapsulation, Tunneling Exchange
        4.1.9.  NAT and Application-level Gateways
        4.1.10.  Measurement and Accounting
        4.1.11.  Diagnostics
        4.1.12.  Redundancy and Failover
    4.2.  CE-FE Link Capability
    4.3.  CE/FE Locality
5.  Security Considerations
6.  ForCES Manageability
    6.1.  NE as an Atomic Element
    6.2.  NE as Composed of Manageable Elements
    6.3.  ForCES Protocol MIB
        6.3.1.  MIB Management of an FE
    6.4.  The FEM and CEM
7.  Contributors
8.  IANA Considerations
9.  Acknowledgments
10.  References
    10.1.  Normative References
    10.2.  Informative References
§  Authors' Addresses

1.  Purpose

The purpose of the ForCES Applicability Statement is to capture the intent of the ForCES protocol [RFC5810] (Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, “Forwarding and Control Element Separation (ForCES) Protocol Specification,” March 2010.) designers as to how the protocol could be used in conjunction with the ForCES model [RFC5812] (Halpern, J. and J. Hadi Salim, “Forwarding and Control Element Separation (ForCES) Forwarding Element Model,” March 2010.) and a Transport Mapping Layer [RFC5811] (Hadi Salim, J. and K. Ogawa, “SCTP-Based Transport Mapping Layer (TML) for the Forwarding and Control Element Separation (ForCES) Protocol,” March 2010.).

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 concepts associated with ForCES was introduced in Requirements for Separation of IP Control and Forwarding[RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.) and in Forwarding and Control Element Separation (ForCES) Framework[RFC3746] (Yang, L., Dantu, R., Anderson, T., and R. Gopal, “Forwarding and Control Element Separation (ForCES) Framework,” April 2004.). The terminology associated with these concepts and the protocol elements in ForCES is defined in the Forwarding and Control Element Separation (ForCES) Protocol Specification[RFC5810] (Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, “Forwarding and Control Element Separation (ForCES) Protocol Specification,” March 2010.).

The reader is directed to these documents for the conceptual introduction and the definitions including of the following acronyms:

• CE: Control Element
• CEM: Control element manager
• FE: Forwarding Element
• FEM: Forwarding element manager
• ForCES: Forwarding and Control Element Separation protocol
• LFB: Logical Function Block
• NE: ForCES network element
• TML: Transport Mapping Layer

4.  Applicability to IP Networks

This section lists the areas of ForCES applicability in IP network devices. Some relatively low-end routing systems may be implemented on simple hardware which performs both control and packet forwarding functionality. ForCES may not be useful for such devices.

Higher end routing systems typically distribute work amongst several interface processing elements, and these devices (FEs) therefore need to communicate with the control element(s) to perform their job. A higher end router may also distribute control processing amongst several processing elements (CEs). ForCES provides a standard way to do this communication. ForCES also provides support for High Availability configurations that include a primary CE and one or more secondary CEs.

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:

• Association, Capability discovery and Information Exchange
• Topology Information Exchange
• Configuration
• Routing Exchange
• QoS Exchange
• Security Exchange
• Filtering Exchange
• Encapsulation/Tunneling Exchange
• NAT and Application-level Gateways
• Measurement and Accounting
• Diagnostics
• CE Redundancy or CE Failover

4.1.1.  Association, Capability Discovery and Information Exchange

Association is the first step of the ForCES protocol exchange in which capability discovery and exchange happens between one or more CEs and the FEs. ForCES assumes that CEs and FEs already have sufficient information to begin communication in a secure manner. The ForCES protocol is only applicable after CEs and FEs have discovered each other. ForCES makes no assumption about whether discovery was performed using a dynamic protocol or merely static configuration. Some discussion about how this can occur can be found later in this document in Section 6.4.

During the association phase, CEs and FEs exchange capability information with each other. For example, the FEs 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 also exchange dynamic configuration changes using ForCES. For example, FEs asynchronously inform the CEs 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. Topology discovery is outside the scope of the ForCES protocol. An implementation can choose its own method of topology discovery (for example use a standard topology discovery protocol; or apply a static topology configuration policy). Once the topology is established, ForCES protocol may be used to transmit the resulting information to the CEs.

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 CEs in the event of a forwarding table miss. ForCES may also be used to configure ECMP capability.

4.1.5.  QoS Capabilities Exchange and Configuration

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 a CE and the FEs it controls. 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. The CEs would be responsible for the NE dynamic key exchanges and updates.

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. A further discussion of this capability is covered in Section 6 of this document.

4.1.11.  Diagnostics

ForCES may be used for CEs and FEs to exchange diagnostic information. For example, an FE can send self-test results to a CE.

4.1.12.  Redundancy and Failover

The ForCES architecture includes mechanisms which allow for multiple redundant CEs and FEs in a ForCES NE. The ForCES model LFB definitions provide sufficient component details via component identifiers to be universally unique within an NE. The ForCES protocol includes mechanisms to facilitate transactions as well as atomicity across the NE.

Given the above it is possible to deploy redundant CEs and FEs which incorporate failover.

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 is reasonable over a high bandwidth link, 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. However, we also note that not all IP routers need full routing tables.

4.3.  CE/FE Locality

ForCES is intended for environments where one of the following applies:

• 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.
• 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.

Taking this into account, ForCES is applicable in the following CE/FE localities:

Single Box NE:

chassis with multiple CEs and FEs setup. ForCES is applicable in localities consisting of control and forwarding elements which are components in the same physical box.

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.

Multiple Box NE:

separated CE and FE where physical locality could be same rack, room, building, or long distance which could span across continents and oceans. ForCES is applicable in localities consisting of control and forwarding elements which are separated by a single hop or multiple hops in the network.

5.  Security Considerations

The ForCES protocol allows for a variety of security levels [RFC5810] (Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, “Forwarding and Control Element Separation (ForCES) Protocol Specification,” March 2010.). When operating under a secured physical environment, or for other operational concerns (in some cases performance issues) the operator may turn off all the security functions between CEs and FEs. When the operator makes a decision to secure the path between the FEs and CEs then the operator chooses from one of the options provided by the TML. Security choices provided by the TML take effect during the pre-association phase of the ForCES protocol. An operator may choose to use all, some or none of the security services provided by the TML in a CE-FE connection. A ForCES NE is required to provide CE/FE node authentication services, and may provide message integrity and confidentially services. The NE may provide these services by employing IPsec or TLS depending on the choice of TML used in the deployment of the NE.

6.  ForCES Manageability

From the architectural perspective, the ForCES NE is a single network element; as an example if the ForCES NE is specifically a router that needs to be managed, then it should be managed in essentially the same way any router should be managed. From another perspective element management could view the individual entities and interfaces that make up a ForCES NE but this may cause risk on the control relationship between the CEs and the FEs unless it has been accounted for in the model used by the NE.

6.1.  NE as an Atomic Element

From the ForCES requirements [RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.) 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 that are documented elsewhere. As an example, router would also have a configuration interface. When viewed in this manner, the NE is controlled as a single routing entity and no new management beyond what is already available for routers and routing protocols would be required for a ForCES NE. Management commands on a management interface to the NE will arrive at the CE and may require ForCES interactions between the CE and FEs to complete. This may impact the atomicity of such commands and may require careful implementation by the CE.

6.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. A MIB module is provided for the purpose of gaining management information on the operation of the protocol describe in Section 6.3 of this document.

Additionally the architecture makes provision for configuration control of the individual CEs and FEs. This is handled by elements named FE manager (FEM) and the CE manager (CEM). Specifically from the ForCES requirements RFC [RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.), 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.

6.3.  ForCES Protocol MIB

The ForCES MIB [RFC5813] (Haas, R., “Forwarding and Control Element Separation (ForCES) MIB,” March 2010.) defines a primarily read-only MIB module 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 MIB modules, such as packet counters for interfaces, etc.

More specifically, the information in the ForCES MIB module relative to associations includes:

• identifiers of the elements in the association
• state of the association
• configuration parameters of the association
• statistics of the association

6.3.1.  MIB Management of an FE

While it is possible to manage a FE from an element manager, several requirements relating to this have been included in the ForCES Requirements.

From the ForCES Requirements [RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.), 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 [RFC3654] (Khosravi, H. and T. Anderson, “Requirements for Separation of IP Control and Forwarding,” November 2003.), Section 5.7, goes further in discussing the manner in which FEs should handle management requests that are specifically directed to the FE:

For a ForCES NE that is an IP router, [RFC1812] (Baker, F., “Requirements for IP Version 4 Routers,” June 1995.) also dictates that "Routers must be manageable by SNMP". In general, for the post-association phase, most external 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 [RFC2741] (Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, “Agent Extensibility (AgentX) Protocol Version 1,” January 2000.)) 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 sub-agent to provide access to the MIB objects residing on FEs. AgentX protocol messages between the master agent (CE) and the sub-agent (FE) are encapsulated and transported via ForCES, just like data packets from any other application layer protocols.

6.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 [RFC5810] (Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., and J. Halpern, “Forwarding and Control Element Separation (ForCES) Protocol Specification,” March 2010.).

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.

7.  Contributors

Mark Handley was an initial author involved in the earlier versions of this document.

8.  IANA Considerations

This document has no IANA actions.

[RFC Editor: please remove this section prior to publication.]

9.  Acknowledgments

Many of the participants in the ForCES as well as fellow employees of the authors, have provided valuable input into this work. Particular thanks go to Jamal Hadi Salim, our WG chair and document shepherd and to Adrian Farrel the AD for the area for their review, comments and encouragement without whom this document might never have been completed.

10.  References

10.1. Normative References

10.2. Informative References

Authors' Addresses