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]