draft-ietf-forces-requirements-01.txt   draft-ietf-forces-requirements-02.txt 
Internet Draft T. Anderson Internet Draft T. Anderson
Expiration: May 2002 Intel Labs Expiration: August 2002 Intel
File: draft-ietf-forces-requirements-01.txt E. Bowen File: draft-ietf-forces-requirements-02.txt E. Bowen
Working Group: ForCES IBM Working Group: ForCES IBM
R. Dantu R. Dantu
Netrake Inc. Netrake Inc.
A. Doria A. Doria
N/A LTU
R. Gopal
Nokia
J. Hadi Salim J. Hadi Salim
Znyx Networks Znyx Networks
H. Khosravi H. Khosravi
Intel Labs Intel
M. Minhazuddin M. Minhazuddin
Avaya Inc. Avaya Inc.
M. Wasserman M. Wasserman
Wind River Wind River
November 2001 February 2002
Requirements for Separation of IP Control and Forwarding Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-01.txt draft-ietf-forces-requirements-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are
working documents of the Internet Engineering Task Force (IETF), working documents of the Internet Engineering Task Force (IETF),
its areas, and its working groups. Note that other groups may its areas, and its working groups. Note that other groups may
also distribute working documents as Internet-Drafts. also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
skipping to change at page 1, line 46 skipping to change at page 2, line 4
as reference material or to cite them other than as ``work in as reference material or to cite them other than as ``work in
progress.'' progress.''
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119]. this document are to be interpreted as described in [RFC-2119].
1. Abstract 1. Abstract
This document presents an introduction to issues surrounding a This document introduces the ForCES architecture and defines a set
ForCES architecture and defines a set of associated terminology. of associated terminology. This document also defines a set of
Subsequently, this document defines a set of architectural, architectural, modeling, and protocol requirements to logically
modeling, and protocol requirements for mechanisms to logically separate the control and data forwarding planes of an IP networking
separate the control and data forwarding planes of an IP network
device. device.
2. Definitions 2. Definitions
Addressable Entity (AE) - A physical device that is directly Addressable Entity (AE) - A physical device that is directly
addressable given some interconnect technology. For example, on addressable given some interconnect technology. For example, on
Ethernet, an AE is a device to which we can communicate using an Ethernet, an AE is a device to which we can communicate using an
Ethernet MAC address; on IP networks, it is a device to which we can Ethernet MAC address; on IP networks, it is a device to which we can
communicate using an IP address; and on a switch fabric, it is a communicate using an IP address; and on a switch fabric, it is a
device to which we can communicate using a switch fabric port device to which we can communicate using a switch fabric port
number. number.
Physical Forwarding Element (PFE) - An AE that includes hardware Physical Forwarding Element (PFE) - An AE that includes hardware
used to provide per-packet processing and handling. This hardware used to provide per-packet processing and handling. This hardware
may consist of (but is not limited to) network processors, ASIC's, may consist of (but is not limited to) network processors, ASIC's,
or general-purpose processors. For example, line cards in a or general-purpose processors. For example, line cards in a
forwarding backplane are PFEs. backplane are PFEs.
PFE Partition - A logical partition of a PFE consisting of some PFE Partition - A logical partition of a PFE consisting of some
subset of each of the resources (e.g., ports, memory, forwarding subset of each of the resources (e.g., ports, memory, forwarding
table entries) available on the PFE. This concept is analogous to table entries) available on the PFE. This concept is analogous to
that of the resources assigned to a virtual router [REQ-PART]. that of the resources assigned to a virtual router [REQ-PART].
Physical Control Element (PCE) - An AE that includes hardware used Physical Control Element (PCE) - An AE that includes hardware used
to provide control functionality. This hardware typically includes to provide control functionality. This hardware typically includes
a general-purpose processor. a general-purpose processor.
skipping to change at page 3, line 4 skipping to change at page 3, line 5
Forwarding Element (FE) - A logical entity that implements the Forwarding Element (FE) - A logical entity that implements the
ForCES protocol. FEs use the underlying hardware to provide per- ForCES protocol. FEs use the underlying hardware to provide per-
packet processing and handling as directed by a CE via the ForCES packet processing and handling as directed by a CE via the ForCES
protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs. protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs.
Proxy FE - A name for a type of FE that cannot directly modify its Proxy FE - A name for a type of FE that cannot directly modify its
underlying hardware but instead manipulates that hardware using some underlying hardware but instead manipulates that hardware using some
intermediate form of communication (e.g., a non-ForCES protocol or intermediate form of communication (e.g., a non-ForCES protocol or
DMA). A proxy FE will typically be used in the case where a PFE DMA). A proxy FE will typically be used in the case where a PFE
cannot implement (e.g., due to the lack of a general purpose CPU) cannot implement the ForCES protocol directly (e.g., due to the lack
the ForCES protocol directly. of a general purpose CPU).
Control Element (CE) - A logical entity that implements the ForCES Control Element (CE) - A logical entity that implements the ForCES
protocol and uses it to instruct one or more FEs as to how they protocol and uses it to instruct one or more FEs how to process
should process packets. CEs handle functionality such as the packets. CEs handle functionality such as the execution of control
execution of control and signaling protocols. CEs may encompass PCE and signaling protocols. CEs may consist of PCE partitions or whole
partitions or whole PCEs. PCEs.
Pre-association Phase - The period of time during which a FE Manager Pre-association Phase - The period of time during which a FE Manager
(see definition below) and a CE Manager (see definition below) are (see below) and a CE Manager (see below) are determining which FE
deciding which FE and CE should be part of the same network element. and CE should be part of the same network element.
Post-association Phase - The period of time during which a FE does Post-association Phase - The period of time during which a FE does
know which CE is to control it and vice versa, including the time know which CE is to control it and vice versa, including the time
during which the CE and FE are establishing communication with one during which the CE and FE are establishing communication with one
another (after they have been associated to the same NE). another.
ForCES Protocol - While there may be multiple protocols used within ForCES Protocol - While there may be multiple protocols used within
the overall ForCES architecture, the term "ForCES protocol" refers the overall ForCES architecture, the term "ForCES protocol" refers
only to the ForCES post-association phase protocol (see below). only to the ForCES post-association phase protocol (see below).
ForCES Post-Association Phase Protocol - The protocol used for post- ForCES Post-Association Phase Protocol - The protocol used for post-
association phase communication between CEs and FEs. This protocol association phase communication between CEs and FEs. This protocol
does not apply to CE-to-CE communication, FE-to-FE communication, or does not apply to CE-to-CE communication, FE-to-FE communication, or
to communication between FE and CE managers. The ForCES protocol is to communication between FE and CE managers. The ForCES protocol is
a master-slave protocol in which FEs are slaves and CEs are masters. a master-slave protocol in which FEs are slaves and CEs are masters.
This protocol includes both the management of the communication This protocol includes both the management of the communication
channel (e.g., "connection" establishment, heartbeats) and the channel (e.g., connection establishment, heartbeats) and the control
control messages themselves. messages themselves.
FE Model - A model that describes the logical processing functions FE Model - A model that describes the logical processing functions
of a FE. of a FE.
FE Manager - A logical entity that operates in the pre-association FE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which CE(s) a FE should phase and is responsible for determining to which CE(s) a FE should
communicate. This determination process is called CE discovery and communicate. This process is called CE discovery and may involve
may involve the FE manager learning the capabilities of available the FE manager learning the capabilities of available CEs. A FE
CEs. A FE manager may use anything from a static configuration to a manager may use anything from a static configuration to a pre-
pre-association phase protocol (see below) to determine which CE(s) association phase protocol (see below) to determine which CE(s) to
to use. Being a logical entity, a FE manager might be physically use. Being a logical entity, a FE manager might be physically
combined with any of the other logical entities mentioned in this combined with any of the other logical entities mentioned in this
section. section.
CE Manager - A logical entity that operates in the pre-association CE Manager - A logical entity that operates in the pre-association
phase and is responsible for determining to which FE(s) a CE should phase and is responsible for determining to which FE(s) a CE should
communicate. This determination process is called FE discovery and communicate. This process is called FE discovery and may involve
may involve the CE manager learning the capabilities of available the CE manager learning the capabilities of available FEs. A CE
FEs. A CE manager may use anything from a static configuration to a manager may use anything from a static configuration to a pre-
pre-association phase protocol (see below) to determine which FE to association phase protocol (see below) to determine which FE to use.
use. Being a logical entity, a CE manager might be physically Being a logical entity, a CE manager might be physically combined
combined with any of the other logical entities mentioned in this with any of the other logical entities mentioned in this section.
section.
Pre-association Phase Protocol - A protocol between FE managers and Pre-association Phase Protocol - A protocol between FE managers and
CE managers that helps them determine which CEs or FEs are to be CE managers that is used to determine which CEs or FEs to use. A
associated to a NE. A pre-association phase protocol may include a pre-association phase protocol may include a CE and/or FE capability
CE and/or FE capability discovery mechanism. It is important to discovery mechanism. Note that this capability discovery process is
note that this capability discovery process is wholly separate from wholly separate from (and does not replace) that used within the
(and does not replace) that used within the ForCES protocol (see ForCES protocol (see Section 7, requirement #1). However, the two
Section 7, requirement #1). However, the two capability discovery capability discovery mechanisms may utilize the same FE model (see
mechanisms may utilize the same FE model (see Section 6). Pre- Section 6). Pre-association phase protocols are not discussed
association phase protocols are not discussed further in this further in this document (see Section 11.3).
document.
ForCES Network Element (NE) - An entity composed of one or more CEs ForCES Network Element (NE) - An entity composed of one or more CEs
and one or more FEs. To entities outside a NE, the NE represents a and one or more FEs. To entities outside a NE, the NE represents a
single point of management. Similarly, a NE usually hides its single point of management. Similarly, a NE usually hides its
internal organization from external entities. internal organization from external entities.
ForCES Protocol Element - A FE or CE. ForCES Protocol Element - A FE or CE.
High Touch Capability - This term will be used to apply to the High Touch Capability - This term will be used to apply to the
capabilities found in some forwarders to take action on the contents capabilities found in some forwarders to take action on the contents
or headers of a packet based on content other than what is found in or headers of a packet based on content other than what is found in
the IP header. Examples of these capabilities include NAT-PT, the IP header. Examples of these capabilities include NAT-PT,
firewall, and L7 content recognition. firewall, and L7 content recognition.
3. Introduction 3. Introduction
An IP network element is composed of numerous logically separated An IP network element is composed of numerous logically separate
entities that cooperate to provide a given functionality (such as a entities that cooperate to provide a given functionality (such as a
routing or IP switching) and yet appear as a normal integrated routing or IP switching) and yet appear as a normal integrated
network element to external entities. Two primary types of network network element to external entities. Two primary types of network
element components exist: control-plane components and forwarding- element components exist: control-plane components and forwarding-
plane components. In general, forwarding-plane components are ASIC, plane components. In general, forwarding-plane components are ASIC,
network-processor, or general-purpose processor-based devices that network-processor, or general-purpose processor-based devices that
handle all data path operations. Conversely, control-plane handle all data path operations. Conversely, control-plane
components are typically based on general-purpose processors that components are typically based on general-purpose processors that
provide control functionality such as the processing of routing or provide control functionality such as the processing of routing or
signaling protocols. A standard set of mechanisms for connecting signaling protocols. A standard set of mechanisms for connecting
these components would provide increased scalability and allow the these components provides increased scalability and allows the
control and forwarding planes to evolve independently thus promoting control and forwarding planes to evolve independently, thus
faster innovation. promoting faster innovation.
For the purpose of illustration, let us consider the architecture of For the purpose of illustration, let us consider the architecture of
a router to illustrate the concept and value of separate control and a router to illustrate the concept and value of separate control and
forwarding planes. The architecture of a router is composed of two forwarding planes. The architecture of a router is composed of two
main parts. These components, while inter-related, perform main parts. These components, while inter-related, perform
functions that are largely independent of each other. At the bottom functions that are largely independent of each other. At the bottom
is the forwarding path that operates in the data-forwarding plane is the forwarding path that operates in the data-forwarding plane
and is responsible for per-packet processing and forwarding. Above and is responsible for per-packet processing and forwarding. Above
the forwarding plane is the network operating system that is the forwarding plane is the network operating system that is
responsible for operations in the control plane. In the case of a responsible for operations in the control plane. In the case of a
router or switch, the network operating system runs routing, router or switch, the network operating system runs routing,
signaling and control protocols (e.g., RIP, OSPF and RSVP) and signaling and control protocols (e.g., RIP, OSPF and RSVP) and
dictates the forwarding behavior by manipulating forwarding tables, dictates the forwarding behavior by manipulating forwarding tables,
per-flow QoS tables and access control lists. Typically, the per-flow QoS tables and access control lists. Typically, the
architecture of these devices combines all of this functionality architecture of these devices combines all of this functionality
into a single functional whole with respect to external entities. into a single functional whole with respect to external entities.
4. Architecture 4. Architecture
The chief components of a NE architecture are the CE, the FE, and The chief components of a NE architecture are the CE, the FE, and
the interconnect protocol. The CE is mainly responsible for the interconnect protocol. The CE is responsible for operations
operations such as signaling and control protocol processing and the such as signaling and control protocol processing and the
implementation of management protocols. Based on the information implementation of management protocols. Based on the information
acquired through control processing, the CE(s) dictates the packet- acquired through control processing, the CE(s) dictates the packet-
forwarding behavior of its FE(s) via the interconnect protocol. For forwarding behavior of the FE(s) via the interconnect protocol. For
example, the CE might control a FE by manipulating its forwarding example, the CE might control a FE by manipulating its forwarding
tables, the state of its interfaces, or by adding or removing a NAT tables, the state of its interfaces, or by adding or removing a NAT
binding. binding.
The FE operates in the forwarding plane and is responsible chiefly The FE operates in the forwarding plane and is responsible for per-
for per-packet processing and handling. By allowing the control and packet processing and handling. By allowing the control and
forwarding planes to evolve independently, we expect different types forwarding planes to evolve independently, different types of FEs
of FEs to be developed - some general purpose and others more can be developed - some general purpose and others more specialized.
specialized. Some functions that FEs could perform include layer 3 Some functions that FEs could perform include layer 3 forwarding,
forwarding, metering, shaping, firewall, NAT, encapsulation (e.g., metering, shaping, firewall, NAT, encapsulation (e.g., tunneling),
tunneling), decapsulation, encryption, accounting, etc. Nearly all decapsulation, encryption, accounting, etc. Nearly all combinations
combinations of these functions may be present in practical FEs. of these functions may be present in practical FEs.
Below is a diagram illustrating an example NE composed of a CE and Below is a diagram illustrating an example NE composed of a CE and
two FEs. two FEs. Both FEs and CE require minimal configuration as part of
the pre-configuration process and this may be done by FE Manager and
CE Manager respectively. Apart from this, there is no defined role
for FE Manager and CE Manager. The Proxy FE has also been defined
for clarification purpose. These components are out of scope of the
architecture and requirements for ForCES protocol, which only
involves CEs and FEs.
-------------------------------- --------------------------------
| NE | | NE |
| ------------- | | ------------- |
| | CE | | | | CE | |
| ------------- | | ------------- |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
skipping to change at page 6, line 31 skipping to change at page 6, line 31
-------------------------------- --------------------------------
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
5. Architectural Requirements 5. Architectural Requirements
The following are the architectural requirements: The following are the architectural requirements:
1) CEs and FEs MUST be able to connect by a variety of interconnect 1) CEs and FEs MUST be able to connect by a variety of interconnect
technologies. Examples of interconnect technologies used in current technologies. Examples of interconnect technologies used in current
architectures include Ethernet connections, backplanes, and ATM architectures include Ethernet,bus backplanes, and ATM (cell)
(cell) fabrics. FEs MAY be connected to each other via a different fabrics. FEs MAY be connected to each other via a different
technology than that used for CE/FE communication. technology than that used for CE/FE communication.
2) FEs MUST support a minimal set of capabilities necessary for 2) FEs MUST support a minimal set of capabilities necessary for
establishing network connectivity (e.g., interface discovery, port establishing network connectivity (e.g., interface discovery, port
up/down functions). Beyond this minimal set, the ForCES up/down functions). Beyond this minimal set, the ForCES
architecture MUST NOT restrict the types or numbers of capabilities architecture MUST NOT restrict the types or numbers of capabilities
that FEs may contain. that FEs may contain.
3) Packets MUST be able to arrive at the NE by one FE and leave the 3) Packets MUST be able to arrive at the NE by one FE and leave the
NE via a different FE. NE via a different FE.
4) A NE MUST support the appearance of a single functional device. 4) A NE MUST support the appearance of a single functional device.
For example, in a router, the TTL of the packet should be For example, in a router, the TTL of the packet should be
decremented only once as it traverses the NE regardless of how many decremented only once as it traverses the NE regardless of how many
FEs through which it passes. However, external entities (e.g., FE FEs through which it passes. However, external entities (e.g., FE
managers and CE managers) MAY have direct access to individual managers and CE managers) MAY have direct access to individual
ForCES protocol elements for providing information to transition ForCES protocol elements for providing information to transition
them from the pre-association to post-association phase. them from the pre-association to post-association phase.
5) The architecture MUST provide a way to prevent unauthorized 5) The architecture MUST provide a way to prevent unauthorized
ForCES protocol elements from joining a NE. ForCES protocol elements from joining a NE.(For more protocol
details, refer to section 7 requirement# 2)
6) A FE MUST be able to asynchronously inform the CE of an 6) A FE MUST be able to asynchronously inform the CE of an
increase/decrease in available resources or capabilities on the FE. increase/decrease in available resources or capabilities on the FE.
(Since there is not a strict 1-to-1 mapping between FEs and PFEs, it (Since there is not a strict 1-to-1 mapping between FEs and PFEs, it
is possible for the relationship between a FE and its physical is possible for the relationship between a FE and its physical
resources to change over time. For example, the number of physical resources to change over time). For example, the number of physical
ports or the amount of memory allocated to a FE may vary over time. ports or the amount of memory allocated to a FE may vary over time.
The CE needs to be informed of such changes so that it can control The CE needs to be informed of such changes so that it can control
the FE in an accurate way.) the FE in an accurate way.
7) CEs and FEs MUST determine when a loss of connectivity between 7) The architecture MUST support mechanisms for high availability.
them has occurred. This includes the ability for CEs and FEs to determine when there is
a loss of association between them, ability to restore association
and efficient state (re)synchronization mechanisms. High
Availability also includes the ability to preset the actions an FE
will take in reaction to loss of association to its CE e.g., whether
the FE will continue to forward packets or whether it will halt
operations.
8) FEs MUST redirect packets addressed to their interfaces to their 8) FEs MUST redirect packets addressed to their interfaces to their
CE for further processing. Furthermore, FEs MUST redirect other CE for further processing. Furthermore, FEs MUST redirect other
required packets (e.g., such as those with the router alert option required packets (e.g., such as those with the router alert option
set) to their CE as well. (FEs MAY provide any other set) to their CE as well. (FEs MAY provide any other
classification/redirection capabilities that they desire as classification/redirection capabilities that they desire as
described in Section 6.4 requirement #4.) Similarly, CEs MUST be described in Section 6.5 requirement #4.) Similarly, CEs MUST be
able to create packets and have its FEs deliver them. able to create packets and have its FEs deliver them.
9) All proposed ForCES architectures MUST explain how that 9) Any proposed ForCES architectures MUST explain how that
architecture may be applied to support all of a router's functions architecture supports all of the router functions as defined in
as defined in [RFC1812]. [RFC1812].
10) In a ForCES NE, the CE(s) MUST be able to learn the topology by 10) In a ForCES NE, the FEs MUST be able to provide their topology
which the FEs in the NE are connected. information (topology by which the FEs in the NE are connected) to
the CE(s).
11) The ForCES NE architecture MUST be capable of supporting (i.e., 11) The ForCES NE architecture MUST be capable of supporting (i.e.,
must scale to) at least hundreds of FEs and tens of thousands of must scale to) at least hundreds of FEs and tens of thousands of
ports. ports.
12) FEs MUST be able to join and leave NEs dynamically. 12) The ForCES architecture MUST allow FEs AND CEs to join and leave
NEs dynamically.
13) CEs MUST be able to join and leave NEs dynamically. 13) The ForCES NE architecture MUST support multiple CEs and FEs.
14) The NE architecture MUST support multiple CEs and FEs. 14) For pre-association phase setup, monitoring, configuration
issues, it MAY be useful to use standard management mechanisms for
CEs and FEs. The ForCES architecture and requirements do not
preclude this. In general, for post-association phase, most
management tasks SHOULD be done through interaction with the CE. In
certain conditions (e.g. CE/FE disconnection), it may be useful to
allow management tools (e.g. SNMP) to be used to diagnose and repair
problems. The following guidelines MUST be observed:
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.
6. FE Model Requirements 6. FE Model Requirements
The variety of FE functionality that the ForCES architecture allows The variety of FE functionality that the ForCES architecture allows
poses a potential problem for CEs. In order for a CE to effectively poses a potential problem for CEs. In order for a CE to effectively
control a FE, the CE must understand at a logical level how the FE control a FE, the CE must understand how the FE processes packets.
processes packets. We therefore REQUIRE that a FE model be created We therefore REQUIRE that a FE model be created that can express the
that can express the logical packet processing capabilities of a FE. logical packet processing capabilities of a FE. This model will be
This model will be used in the ForCES protocol to describe FE used in the ForCES protocol to describe FE capabilities (see Section
capabilities (see Section 7, requirement #1). 7, requirement #1).
6.1. Higher-Level FE Model 6.1. Types of Logical Functions
At its higher level, the FE model MUST express what logical The FE model MUST express what logical functions can be applied to
functions can be applied to packets as they pass through a FE. packets as they pass through a FE.
Furthermore, the model MUST be capable of describing the order in Logical functions are the packet processing functions that are
which these logical functions are applied in a FE. This ordering is applied to the packets as they are forwarded through a FE. Examples
important in many cases. For example, a NAT function may change a of logical functions are layer 3 forwarding, firewall, NAT, shaping.
packet's source or destination IP address. Any number of other Section 6.5 defines the minimal set of logical functions that the FE
logical functions (e.g., layer 3 forwarding, ingress/egress Model MUST support.
6.2. Variations of Logical Functions
The FE model MUST be capable of supporting/allowing variations in
the way logical functions are implemented on a FE. For example, on a
certain FE the forwarding logical function might have information
about both the next hop IP address and the next hop MAC address,
while on another FE these might be implemented as separate logical
functions. Another example would be NAT functionality that can have
several flavors such as Traditional/Outbound NAT, Bi-directional
NAT, Twice NAT, Multihomed NAT [RFC2663]. The model must be flexible
enough to allow such variations in functions.
6.3. Ordering of Logical Functions
The model MUST be capable of describing the order in which these
logical functions are applied in a FE. The ordering of logical
functions is important in many cases. For example, a NAT function
may change a packet's source or destination IP address. Any number
of other logical functions (e.g., layer 3 forwarding, ingress/egress
firewall, shaping, accounting) may make use of the source or firewall, shaping, accounting) may make use of the source or
destination IP address when making decisions. The CE needs to know destination IP address when making decisions. The CE needs to know
whether to configure these logical functions with the pre-NAT or whether to configure these logical functions with the pre-NAT or
post-NAT IP address. Furthermore, the model MUST be capable of post-NAT IP address. Furthermore, the model MUST be capable of
expressing multiple instances of the same logical function in a FE's expressing multiple instances of the same logical function in a FE's
processing path. Using NAT again as an example, one NAT function is processing path. Using NAT again as an example, one NAT function is
typically performed before the forwarding decision (packets arriving typically performed before the forwarding decision (packets arriving
externally have their public addresses replaced with private externally have their public addresses replaced with private
addresses) and one NAT function is performed after the forwarding addresses) and one NAT function is performed after the forwarding
decision (for packets exiting the domain, their private addresses decision (for packets exiting the domain, their private addresses
are replaced by public ones). are replaced by public ones).
6.2. Lower-Level FE Model 6.4. Flexibility
At its lower level, the FE model MUST be able to express the
capabilities of each logical function. As the following examples
will illustrate, these lower-level capabilities come in five
varieties: classification, action, parameterization, statistic, and
events.
6.2.1. Classification
Classification data is used by a logical function to perform pattern
matching. For example, there may be two FEs, both of which provide
an ingress firewall function. However, the first FE may filter on
any subset of a (source IP, destination IP, IP protocol, source
port, destination port)-tuple whereas the second FE may perform only
a (destination IP, IP protocol)-tuple classification. In either
case, the action applied to matching packets may be the same, e.g.
drop.
6.2.2. Action
Action data is used by a logical function to manipulate the packet
because of a classification. For example, there may be two traffic-
shaping functions, both of which classify only on destination IP
address. However, one of the shaping functions may implement a
leaky bucket that requires two parameters whereas the other function
may implement a token bucket that requires three parameters.
6.2.3. Parameterization
Parameterization data can be viewed as parameters to the logical
function itself. This data does not affect individual packets but
affects how the function as a whole behaves. For example, there may
be a congestion function that implements two varieties of RED that
require different parameter sets. Parameterization data would be
used to select between the two varieties of RED and to provide the
necessary configuration to each variety.
6.2.4.Statistics
Some logical functions may maintain certain statistics (e.g., number
of packets processed) about their own operation. The FE model needs
to express which statistics a FEs logical functions maintain so
that CEs can later query those statistics to answer queries made by
higher level entities.
6.2.5.Event
Some logical functions may be able to generate asynchronous events
that can be sent to the control plane. Two examples of these events
include packet redirection events and port state change events
(e.g., up/down). The FE model must be able to express the events
that a FEs logical functions may generate so that CEs can register
to receive those events when they happen to occur.
6.3. Flexibility
Finally, the FE model SHOULD provide a flexible infrastructure in Finally, the FE model SHOULD provide a flexible infrastructure in
which new logical functions and new classification, action, and which new logical functions and new classification, action, and
parameterization data can be easily added. Also, the FE model MUST parameterization data can be easily added. Also, the FE model MUST
be capable of describing the types of statistics gathered by each be capable of describing the types of statistics gathered by each
logical function. logical function.
6.4. Minimal Set of Logical Functions 6.5. Minimal Set of Logical Functions
The rest of this section defines a minimal set of logical functions The rest of this section defines a minimal set of logical functions
that any FE model MUST support. However, this section shall not be that any FE model MUST support. This minimal set DOES NOT imply
construed as to define a set of functions that all FEs must provide. that all FEs must provide this functionality. Instead, these
On the contrary, FEs are not required to support any of the requirements only specify that the model must be capable of
following functions. These requirements only specify that the FE expressing the capabilities that FEs may choose to provide.
model must be capable of expressing the capabilities that FEs are
likely to initially provide.
1)Port Functions 1)Port Functions
The FE model MUST be capable of expressing the number of ports on The FE model MUST be capable of expressing the number of ports on
the device, the static attributes of each port (e.g., port type, the device, the static attributes of each port (e.g., port type,
link speed), and the configurable attributes of each port (e.g., IP link speed), and the configurable attributes of each port (e.g., IP
address, administrative status). address, administrative status).
2)Forwarding Functions 2)Forwarding Functions
The FE model MUST be capable of expressing the data that can be used The FE model MUST be capable of expressing the data that can be used
by the forwarding function to make a forwarding decision. by the forwarding function to make a forwarding decision.
3)QoS Functions 3)QoS Functions
The FE model MUST allow a FE to express its QoS capabilities in The FE model MUST allow a FE to express its QoS capabilities in
terms of, e.g., metering, policing, shaping, and queuing functions. terms of, e.g., metering, policing, shaping, and queuing functions.
The FE model MUST be capable of expressing the use of these The FE model MUST be capable of expressing the use of these
functions to provide IntServ or DiffServ functionality as described functions to provide IntServ or DiffServ functionality as described
in [RFC2211], [RFC2212], [RFC2215], and [DS-PIB]. in [RFC2211], [RFC2212], [RFC2215], [RFC2475], and [DS-MODEL].
4)Generic Filtering Functions 4)Generic Filtering Functions
The FE model MUST be capable of expressing complex sets of filtering The FE model MUST be capable of expressing complex sets of filtering
functions. The model MUST be able to express the existence of functions. The model MUST be able to express the existence of these
multiples of these functions at arbitrary points in a FE's packet functions at arbitrary points in the sequence of a FE's packet
processing path. The FE model MUST be capable of expressing a wide processing functions. The FE model MUST be capable of expressing a
range of classification abilities from single fields (e.g., wide range of classification abilities from single fields (e.g.,
destination address) to arbitrary n-tuples. Similarly, the FE model destination address) to arbitrary n-tuples. Similarly, the FE model
MUST be capable of expressing what actions these filtering functions MUST be capable of expressing what actions these filtering functions
can perform on packets that the classifier matches. can perform on packets that the classifier matches.
5)Vendor-Specific Functions 5)Vendor-Specific Functions
The FE model SHOULD be extensible so that vendor-specific The FE model SHOULD be extensible so that vendor-specific FE
functionality can be expressed. functionality can be expressed.
6)High-Touch Functions 6)High-Touch Functions
The FE model MUST be capable of expressing the encapsulation and The FE model MUST be capable of expressing the encapsulation and
tunneling capabilities of a FE. The FE model MUST support functions tunneling capabilities of a FE. The FE model MUST support functions
that mark the IPv4 header TOS octet or the IPv6 Traffic Class octet. that mark the IPv4 header TOS octet or the IPv6 Traffic Class octet.
The FE model MAY support other high touch functions (e.g., NAT, The FE model MAY support other high touch functions (e.g., NAT,
ALG). ALG).
7)Security Functions 7)Security Functions
The FE model MUST be capable of expressing the types of encryption The FE model MUST be capable of expressing the types of encryption
that may be applied to packets in the forwarding path. that may be applied to packets in the forwarding path.
7. ForCES Protocol Requirements 7. ForCES Protocol Requirements
This section specifies some of the requirements that a ForCES This section specifies some of the requirements that the ForCES
protocol MUST meet. protocol MUST meet.
1)Configuration of Modeled Elements 1)Configuration of Modeled Elements
The ForCES protocol MUST allow the CEs to determine the capabilities The ForCES protocol MUST allow the CEs to determine the capabilities
of each FE. These capabilities SHALL be expressed using the FE of each FE. These capabilities SHALL be expressed using the FE
model whose requirements are defined in Section 6. Furthermore, the model whose requirements are defined in Section 6. Furthermore, the
protocol MUST provide a means for the CEs to control all the FE protocol MUST provide a means for the CEs to control all the FE
capabilities that are discovered through the FE model. (For capabilities that are discovered through the FE model. The protocol
example, the protocol must be able to add/remove MUST be able to add/remove classification/action entries, set/delete
classification/action entries, set/delete parameters, query parameters, query statistics, and register for and receive events.
statistics, and register for and receive events.)
2)Support for Secure Communication 2)Support for Secure Communication
Since FE configuration will contain information critical to the a) FE configuration will contain information critical to the
functioning of a network (such as IP forwarding tables) and may functioning of a network (e.g. IP Forwarding Tables). As such, it
contain information derived from business relationships (e.g., MUST be possible to ensure the authentication and integrity of
SLAs), the ForCES protocol MUST support a method of securing ForCES protocol messages.
communication between FEs and CEs to ensure that information is b) FE configuration information may also contain information derived
delivered privately and in an unmodified form. from business relationships (e.g. service level agreements).
Therefore, it MUST be possible to secure (make private) ForCES
protocol messages.
c) In order to provide authentication, integrity and privacy for a
proposed ForCES protocol, existing security mechanisms such as
IPSec/IKE, TLS, etc. MUST be used/leveraged if applicable.
3)Scalability 3)Scalability
The ForCES protocol MUST be capable of supporting (i.e., must scale The ForCES protocol MUST be capable of supporting (i.e., must scale
to) at least hundreds of FEs and tens of thousands of ports. For to) at least hundreds of FEs and tens of thousands of ports. For
example, the ForCES protocol field sizes corresponding to FE or port example, the ForCES protocol field sizes corresponding to FE or port
numbers SHALL be large enough to support the minimum required numbers SHALL be large enough to support the minimum required
numbers. This requirement does not relate to the performance of the numbers. This requirement does not relate to the performance of a
protocol as the number of FEs or ports in the NE grows. NE as the number of FEs or ports in the NE grows.
4)Multihop 4)Multihop
When the CEs and FEs are separated beyond a single hop, the ForCES When the CEs and FEs are separated beyond a single hop, the ForCES
protocol will make use of an existing RFC2914 compliant L4 protocol protocol will make use of an existing RFC2914 compliant L4 protocol
with adequate reliability, security and congestion control (e.g. with adequate reliability, security and congestion control (e.g.
TCP, SCTP) for transport purposes. TCP, SCTP) for transport purposes.
5)Message Priority 5)Message Priority
The ForCES protocol MUST provide a means to express message The ForCES protocol MUST provide a means to express the protocol
priority. message priorities.
6)Reliability 6)Reliability
The ForCES protocol SHALL assume that it runs on top of an The ForCES protocol SHALL assume that it runs on top of an
unreliable, datagram service. For IP networks, an encapsulation of unreliable, datagram service. For IP networks, an encapsulation of
the ForCES protocol SHALL be defined that uses a [RFC2914]-compliant the ForCES protocol SHALL be defined that uses a [RFC2914]-compliant
transport protocol and provides a datagram service (that could be transport protocol and provides a datagram service (that could be
unreliable). For non-IP networks, additional encapsulations MAY be unreliable). For non-IP networks, additional encapsulations MAY be
defined so long as they provide a datagram service to the ForCES defined so long as they provide a datagram service to the ForCES
protocol. However, since some messages will need to be reliably protocol. However, since some messages will need to be reliably
delivered to FEs, the ForCES protocol MUST provide internal support delivered to FEs, the ForCES protocol MUST provide internal support
for reliability mechanisms such as message acknowledgements and/or for reliability mechanisms such as message acknowledgements and/or
state change confirmations. state change confirmations.
7)Interconnect Independence
The ForCES protocol MUST support a variety of interconnect
technologies. (refer to section 5, requirement# 1)
8)High Availability
The ForCES protocol MUST support mechanisms for high availability.
This includes the ability for CEs and FEs to determine when there is
a loss of association between them, ability to restore association
and efficient state (re)synchronization mechanisms. High
Availability also includes the ability to preset the actions an FE
will take in reaction to loss of association to its CE e.g., whether
the FE will continue to forward packets or whether it will halt
operations. (refer to section 5, requirement# 7)
9)Packet Redirection
The ForCES protocol MUST support the redirection of packets from FEs
to their CEs. It MUST also support CEs to send packets to FEs for
delivery.(refer to section 5, requirement# 8)
10)Topology Exchange
The ForCES protocol MUST allow the FEs to provide their topology
information (topology by which the FEs in the NE are connected) to
the CE(s). (refer to section 5, requirement# 10)
11)Dynamic Association
The ForCES protocol MUST allow CEs and FEs to join and leave a NE
dynamically. (refer to section 5, requirement# 12)
12)Command Bundling
The ForCES protocol MUST be able to group an ordered set of commands
to a FE. Each such group of commands SHOULD be sent to the FE in as
few messages as possible. Furthermore, the protocol MUST support the
ability to specify if a command group MUST have all-or-nothing
semantics.
13)Asynchronous Event Notification
The ForCES protocol MUST be able to asynchronously notify the CE of
events on the FE such as change in available resources or
capabilities. (refer to section 5, requirement# 6)
8. Security Considerations 8. Security Considerations
See architecture requirement #5 and protocol requirement #2. See architecture requirement #5 and protocol requirement #2.
9. References 9. Normative References
[DS-PIB] M. Fine, et. al., "Differentiated Services Quality of
Service Policy Information Base", work in progress, November 2001,
<draft-ietf-diffserv-pib-05.txt>.
[REQ-PART] T. Anderson, C. Wang, J. Buerkle, "Requirements for the [DS-MODEL] Y. Bernet, et. al., "An Informal Management Model for
Dynamic Partitioning of Network Elements", work in progress, August DiffServ Routers", work in progress, September 2001, <draft-ietf-
2001, <draft-ietf-gsmp-dyn-part-reqs-00.txt>. diffserv-model-06.txt>.
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers", [RFC1812] F. Baker, "Requirements for IP Version 4 Routers",
RFC1812, June 1995. RFC1812, June 1995.
[RFC2211] J. Wroclawski, "Specification of the Controlled-Load [RFC2211] J. Wroclawski, "Specification of the Controlled-Load
Network Element Service", RFC2211, September 1997. Network Element Service", RFC2211, September 1997.
[RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of
Guaranteed Quality of Service", RFC2212, September 1997. Guaranteed Quality of Service", RFC2212, September 1997.
[RFC2212] S. Shenker, J. Wroclawski, "General Characterization [RFC2212] S. Shenker, J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC2215, Parameters for Integrated Service Network Elements", RFC2215,
September 1997. September 1997.
[RFC2475] S. Blake, et. Al., "An Architecture for Differentiated
Service", RFC2475, December 1998.
[RFC2914] S. Floyd, "Congestion Control Principles", RFC2914, [RFC2914] S. Floyd, "Congestion Control Principles", RFC2914,
September 2000. September 2000.
10. Authors' Addresses [RFC2663] P. Srisuresh & M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC2663, August
1999.
10. Informative References
[REQ-PART] T. Anderson, C. Wang, J. Buerkle, "Requirements for the
Dynamic Partitioning of Network Elements", work in progress, August
2001, <draft-ietf-gsmp-dyn-part-reqs-00.txt>.
11. Acknowledgments
The authors would like to thank Vip Sharma and Lily Yang for their
valuable contributions.
12. Authors' Addresses
Todd A. Anderson Todd A. Anderson
Intel Labs Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 712 1760 Phone: +1 503 712 1760
Email: todd.a.anderson@intel.com Email: todd.a.anderson@intel.com
Ed Bowen Ed Bowen
IBM Zurich Research Laboratory IBM Zurich Research Laboratory
Saumerstrasse 4 Saumerstrasse 4
CH-8803 Rueschlikon Switzerland CH-8803 Rueschlikon Switzerland
Phone: +41 1 724 83 68 Phone: +41 1 724 83 68
Email: edbowen@us.ibm.com Email: edbowen@us.ibm.com
Ram Dantu Ram Dantu
Netrake Corporation Netrake Corporation
3000 Technology Drive, #100, 3000 Technology Drive, #100,
Plano, Texas, 75074 Plano, Texas, 75074
rdantu@netrake.com Email: rdantu@netrake.com
214 291 1111 Phone: 214 291 1111
Avri Doria Avri Doria
Phone: +1 401 663 5024 Institute for System Technology
Email: avri@acm.org Lulea University of Technology
SE-971 87, Lulea, Sweden
Phone: +46 (0)920 49 3030
Email: avri@sm.luth.se
Ram Gopal
Nokia Research Center
5, Wayside Road,
Burlington, MA 01803
Phone: 1-781-993-3685
Email: ram.gopal@nokia.com
Jamal Hadi Salim Jamal Hadi Salim
Znyx Networks Znyx Networks
Ottawa, Ontario Ottawa, Ontario
Canada Canada
Email: hadi@znyx.com Email: hadi@znyx.com
Hormuzd Khosravi Hormuzd Khosravi
Intel Labs Intel
2111 NE 25th Avenue 2111 NE 25th Avenue
Hillsboro, OR 97124 USA Hillsboro, OR 97124 USA
Phone: +1 503 264 0334 Phone: +1 503 264 0334
Email: hormuzd.m.khosravi@intel.com Email: hormuzd.m.khosravi@intel.com
Muneyb Minhazuddin Muneyb Minhazuddin
Avaya Inc. Avaya Inc.
123, Epping road, 123, Epping road,
North Ryde, NSW 2113, Australia North Ryde, NSW 2113, Australia
Phone: +61 2 9352 8620 Phone: +61 2 9352 8620
email: muneyb@avaya.com email: muneyb@avaya.com
Margaret Wasserman Margaret Wasserman
Wind River Wind River
10 Tara Blvd., Suite 330 10 Tara Blvd., Suite 330
Nashua, NH 03062 Nashua, NH 03062
Phone: +1 603 897 2067 Phone: +1 603 897 2067
Email: mrw@windriver.com Email: mrw@windriver.com
1. Abstract........................................................2
2. Definitions.....................................................2
3. Introduction....................................................4
4. Architecture....................................................5
5. Architectural Requirements......................................6
6. FE Model Requirements...........................................8
6.1. Types of Logical Functions......................................8
6.2. Variations of Logical Functions.................................8
6.3. Ordering of Logical Functions...................................8
6.4. Flexibility.....................................................9
6.5. Minimal Set of Logical Functions................................9
7. ForCES Protocol Requirements...................................10
8. Security Considerations........................................12
9. Normative References...........................................12
10. Informative References........................................13
11. Acknowledgments...............................................13
12. Authors' Addresses............................................13
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/