draft-ietf-forces-requirements-10.txt   rfc3654.txt 
Internet Draft H. Khosravi, Network Working Group H. Khosravi, Ed.
Expiration: January 2004 T. Anderson (Editors) Request for Comments: 3654 T. Anderson, Ed.
File: draft-ietf-forces-requirements-10.txt Intel Category: Informational Intel
Working Group: ForCES July 2003 November 2003
Requirements for Separation of IP Control and Forwarding Requirements for Separation of IP Control and Forwarding
draft-ietf-forces-requirements-10.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. Internet-Drafts are not specify an Internet standard of any kind. Distribution of this
working documents of the Internet Engineering Task Force (IETF), memo is unlimited.
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 Copyright Notice
http://www.ietf.org/shadow.html.
Conventions used in this document Copyright (C) The Internet Society (2003). All Rights Reserved.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", Abstract
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in [RFC-2119].
1. Abstract This document introduces the Forwarding and Control Element
Separation (ForCES) architecture and defines a set of associated
terminology. This document also defines a set of architectural,
modeling, and protocol requirements to logically separate the control
and data forwarding planes of an IP (IPv4, IPv6, etc.) networking
device.
This document introduces the ForCES architecture and defines a set Table of Contents
of associated terminology. This document also defines a set of
architectural, modeling, and protocol requirements to logically
separate the control and data forwarding planes of an IP (IPv4,
IPv6, etc.) networking device.
1. Abstract........................................................1 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction....................................................2 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Definitions.....................................................3 3. Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture....................................................5 4. Architectural Requirements. . . . . . . . . . . . . . . . . . 5
5. Architectural Requirements......................................6 5. FE Model Requirements . . . . . . . . . . . . . . . . . . . . 7
6. FE Model Requirements...........................................8 5.1. Types of Logical Functions. . . . . . . . . . . . . . . 8
6.1. Types of Logical Functions......................................8 5.2. Variations of Logical Functions . . . . . . . . . . . . 8
6.2. Variations of Logical Functions.................................8 5.3. Ordering of Logical Functions . . . . . . . . . . . . . 8
6.3. Ordering of Logical Functions...................................8 5.4. Flexibility . . . . . . . . . . . . . . . . . . . . . . 8
6.4. Flexibility.....................................................9 5.5 Minimal Set of Logical Functions. . . . . . . . . . . . 9
6.5. Minimal Set of Logical Functions................................9 6. ForCES Protocol Requirements. . . . . . . . . . . . . . . . . 10
7. ForCES Protocol Requirements...................................10 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References.....................................................14 7.1. Normative References. . . . . . . . . . . . . . . . . . 14
8.1. Normative References...........................................14 7.2. Informative References. . . . . . . . . . . . . . . . . 15
8.2. Informative References.........................................14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations........................................15 9. Authors' Addresses & Acknowledgments. . . . . . . . . . . . . 15
10. Authors' Addresses & Acknowledgments..........................15 10. Editors' Contact Information. . . . . . . . . . . . . . . . . 17
11. Editors' Contact Information..................................16 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 18
2. Introduction 1. Introduction
An IP network element is composed of numerous logically separate 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 provides increased scalability and allows the these components provides increased scalability and allows the
control and forwarding planes to evolve independently, thus control and forwarding planes to evolve independently, thus promoting
promoting faster innovation. 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 of separate control and a router to illustrate the concept of separate control and forwarding
forwarding planes. The architecture of a router is composed of two planes. The architecture of a router is composed of two main parts.
main parts. These components, while inter-related, perform These components, while inter-related, perform functions that are
functions that are largely independent of each other. At the bottom largely independent of each other. At the bottom is the forwarding
is the forwarding path that operates in the data-forwarding plane path that operates in the data-forwarding plane and is responsible
and is responsible for per-packet processing and forwarding. Above for per-packet processing and forwarding. Above the forwarding plane
the forwarding plane is the network operating system that is is the network operating system that is responsible for operations in
responsible for operations in the control plane. In the case of a the control plane. In the case of a router or switch, the network
router or switch, the network operating system runs routing, operating system runs routing, signaling and control protocols (e.g.,
signaling and control protocols (e.g., RIP, OSPF and RSVP) and RIP, OSPF and RSVP) and dictates the forwarding behavior by
dictates the forwarding behavior by manipulating forwarding tables, manipulating forwarding tables, per-flow QoS tables and access
per-flow QoS tables and access control lists. Typically, the control lists. Typically, the architecture of these devices combines
architecture of these devices combines all of this functionality all of this functionality into a single functional whole with respect
into a single functional whole with respect to external entities. to external entities.
3. 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 IP addressable given some interconnect technology. For example, on IP
networks, it is a device to which we can communicate using an IP networks, it is a device to which we can communicate using an IP
address; and on a switch fabric, it is a device to which we can address; and on a switch fabric, it is a device to which we can
communicate using a switch fabric port number. communicate using a switch fabric port number.
Physical Forwarding Element (PFE) - An AE that includes hardware Physical Forwarding Element (PFE) - An AE that includes hardware used
used to provide per-packet processing and handling. This hardware to provide per-packet processing and handling. This hardware may
may consist of (but is not limited to) network processors, ASIC's, consist of (but is not limited to) network processors, ASIC's, line
line cards with multiple chips or stand alone box with general- cards with multiple chips or stand alone box with general-purpose
purpose processors. processors.
Physical Control Element (PCE) - An AE that includes hardware used Physical Control Element (PCE) - An AE that includes hardware used to
to provide control functionality. This hardware typically includes provide control functionality. This hardware typically includes a
a general-purpose processor. general-purpose processor.
Forwarding Element (FE) - A logical entity that implements the Forwarding Element (FE) - A logical entity that implements the ForCES
ForCES protocol. FEs use the underlying hardware to provide per- protocol. FEs use the underlying hardware to provide per-packet
packet processing and handling as directed/controlled by a CE via processing and handling as directed/controlled by a CE via the ForCES
the ForCES protocol. FEs may happen to be a single blade(or PFE), a protocol. FEs may happen to be a single blade(or PFE), a partition
partition of a PFE or multiple PFEs. of a PFE or multiple PFEs.
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 how to process protocol and uses it to instruct one or more FEs how to process
packets. CEs handle functionality such as the execution of control packets. CEs handle functionality such as the execution of control
and signaling protocols. CEs may consist of PCE partitions or whole and signaling protocols. CEs may consist of PCE 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 below) and a CE Manager (see below) are determining which FE (see below) and a CE Manager (see below) are determining which FE and
and CE should be part of the same network element. Any partitioning CE should be part of the same network element. Any partitioning of
of PFEs and PCEs occurs during this phase. PFEs and PCEs occurs during this phase.
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. 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 control channel (e.g., connection establishment, heartbeats) and the control
messages themselves. This protocol could be a single protocol or messages themselves. This protocol could be a single protocol or
could consist of multiple protocols working together. could consist of multiple protocols working together.
FE Model - A model that describes the logical processing functions FE Model - A model that describes the logical processing functions of
of a FE. 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 process is called CE discovery and may involve communicate. This process is called CE discovery and may involve the
the FE manager learning the capabilities of available CEs. A FE FE manager learning the capabilities of available CEs. A FE manager
manager may use anything from a static configuration to a pre- may use anything from a static configuration to a pre-association
association phase protocol (see below) to determine which CE(s) to phase protocol (see below) to determine which CE to use. However,
use, however this is currently out of scope. Being a logical this pre-association phase protocol is currently out of scope. Being
entity, a FE manager might be physically combined with any of the a logical entity, a FE manager might be physically combined with any
other logical entities mentioned in this section. of the other logical entities mentioned in this 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 process is called FE discovery and may involve communicate. This process is called FE discovery and may involve the
the CE manager learning the capabilities of available FEs. A CE CE manager learning the capabilities of available FEs. A CE manager
manager may use anything from a static configuration to a pre- may use anything from a static configuration to a pre-association
association phase protocol (see below) to determine which FE to use, phase protocol (see below) to determine which FE to use. Again, this
however this is currently out of scope. Being a logical entity, a pre-association phase protocol is currently out of scope. Being a
CE manager might be physically combined with any of the other logical entity, a CE manager might be physically combined with any of
logical entities mentioned in this section. the other logical entities mentioned in this section.
Pre-association Phase Protocol - A protocol between FE managers and Pre-association Phase Protocol - A protocol between FE managers and
CE managers that is used to determine which CEs or FEs to use. A CE managers that is used to determine which CEs or FEs to use. A
pre-association phase protocol may include a CE and/or FE capability pre-association phase protocol may include a CE and/or FE capability
discovery mechanism. Note that this capability discovery process is discovery mechanism. Note that this capability discovery process is
wholly separate from (and does not replace) that used within the wholly separate from (and does not replace) what is used within the
ForCES protocol (see Section 7, requirement #1). However, the two ForCES protocol (see Section 6, requirement #1). However, the two
capability discovery mechanisms may utilize the same FE model (see capability discovery mechanisms may utilize the same FE model (see
Section 6). Pre-association phase protocols are not discussed Section 5). Pre-association phase protocols are not discussed
further in this document. further in this 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.
4. Architecture 3. 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
the interconnect protocol. The CE is responsible for operations interconnect protocol. The CE is responsible for operations such as
such as signaling and control protocol processing and the signaling and control protocol processing and the implementation of
implementation of management protocols. Based on the information management protocols. Based on the information acquired through
acquired through control processing, the CE(s) dictates the packet- control processing, the CE(s) dictates the packet-forwarding behavior
forwarding behavior of the FE(s) via the interconnect protocol. For of the FE(s) via the interconnect protocol. For example, the CE
example, the CE might control a FE by manipulating its forwarding might control a FE by manipulating its forwarding tables, the state
tables, the state of its interfaces, or by adding or removing a NAT of its interfaces, or by adding or removing a NAT binding.
binding.
The FE operates in the forwarding plane and is responsible for per- The FE operates in the forwarding plane and is responsible 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, different types of FEs forwarding planes to evolve independently, different types of FEs can
can be developed - some general purpose and others more specialized. be developed - some general purpose and others more specialized.
Some functions that FEs could perform include layer 3 forwarding, Some functions that FEs could perform include layer 3 forwarding,
metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), metering, shaping, firewall, NAT, encapsulation (e.g., tunneling),
decapsulation, encryption, accounting, etc. Nearly all combinations decapsulation, encryption, accounting, etc. Nearly all 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. Both FEs and CE require minimal configuration as part of 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 the pre-configuration process and this may be done by FE Manager and
CE Manager respectively. Apart from this, there is no defined role CE Manager respectively. Apart from this, there is no defined role
for FE Manager and CE Manager. These components are out of scope of for FE Manager and CE Manager. These components are out of scope of
the architecture and requirements for the ForCES protocol, which the architecture and requirements for the ForCES protocol, which only
only involves CEs and FEs. involves CEs and FEs.
-------------------------------- --------------------------------
| NE | | NE |
| ------------- | | ------------- |
| | CE | | | | CE | |
| ------------- | | ------------- |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
skipping to change at page 6, line 11 skipping to change at page 5, line 42
| | FE | | FE | | | | FE | | FE | |
| ----------- ----------- | | ----------- ----------- |
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | |
-------------------------------- --------------------------------
| | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | |
5. Architectural Requirements 4. 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,bus backplanes, and ATM (cell) architectures include Ethernet,bus backplanes, and ATM (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
architecture MUST NOT restrict the types or numbers of capabilities MUST NOT restrict the types or numbers of capabilities that FEs may
that FEs may contain. 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
decremented only once as it traverses the NE regardless of how many only once as it traverses the NE regardless of how many FEs through
FEs through which it passes. However, external entities (e.g., FE which it passes. However, external entities (e.g., FE managers and
managers and CE managers) MAY have direct access to individual CE managers) MAY have direct access to individual ForCES protocol
ForCES protocol elements for providing information to transition elements for providing information to transition them from the pre-
them from the pre-association to post-association phase. 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
ForCES protocol elements from joining a NE.(For more protocol protocol elements from joining a NE. (For more protocol details,
details, refer to section 7 requirement# 2) refer to section 6 requirement #2)
6) A FE MUST be able to asynchronously inform the CE of a failure or 6) A FE MUST be able to asynchronously inform the CE of a failure or
increase/decrease in available resources or capabilities on the FE. increase/decrease in available resources or capabilities on the FE.
Thus the FE MUST support error monitoring and reporting. (Since Thus, the FE MUST support error monitoring and reporting. (Since
there is not a strict 1-to-1 mapping between FEs and PFEs, it is 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 possible for the relationship between a FE and its physical resources
resources to change over time). For example, the number of physical to change over time). For example, the number of physical ports or
ports or the amount of memory allocated to a FE may vary over time. the amount of memory allocated to a FE may vary over time. The CE
The CE needs to be informed of such changes so that it can control needs to be informed of such changes so that it can control the FE in
the FE in an accurate way. an accurate way.
7) The architecture MUST support mechanisms for CE redundancy or CE 7) The architecture MUST support mechanisms for CE redundancy or CE
failover. This includes the ability for CEs and FEs to determine failover. This includes the ability for CEs and FEs to determine
when there is a loss of association between them, ability to restore when there is a loss of association between them, ability to restore
association and efficient state (re)synchronization mechanisms. This association and efficient state (re)synchronization mechanisms. This
also includes the ability to preset the actions an FE will take in 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 reaction to loss of association to its CE e.g., whether the FE will
continue to forward packets or whether it will halt operations. continue to forward packets or whether it will halt operations.
8) FEs MUST be able to redirect control packets (such as RIP, OSPF 8) FEs MUST be able to redirect control packets (such as RIP, OSPF
skipping to change at page 7, line 27 skipping to change at page 7, line 12
packet redirection information/filters on the FEs. The CEs MUST also packet redirection information/filters on the FEs. The CEs MUST also
be able to create packets and have its FEs deliver them. be able to create packets and have its FEs deliver them.
9) Any proposed ForCES architectures MUST explain how that 9) Any proposed ForCES architectures MUST explain how that
architecture supports all of the router functions as defined in architecture supports all of the router functions as defined in
[RFC1812]. IPv4 Forwarding functions such IP header validation, [RFC1812]. IPv4 Forwarding functions such IP header validation,
performing longest prefix match algorithm, TTL decrement, Checksum performing longest prefix match algorithm, TTL decrement, Checksum
calculation, generation of ICMP error messages, etc defined in RFC calculation, generation of ICMP error messages, etc defined in RFC
1812 should be explained. 1812 should be explained.
10) In a ForCES NE, the FEs MUST be able to provide their topology 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by
information (topology by which the FEs in the NE are connected) to which the FEs in the NE are connected.
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) The ForCES architecture MUST allow FEs AND CEs to join and leave 12) The ForCES architecture MUST allow FEs AND CEs to join and leave
NEs dynamically. NEs dynamically.
13) The ForCES NE architecture MUST support multiple CEs and FEs. 13) The ForCES NE architecture MUST support multiple CEs and FEs.
However, coordination between CEs is out of scope of ForCES. However, coordination between CEs is out of scope of ForCES.
14) For pre-association phase setup, monitoring, configuration 14) For pre-association phase setup, monitoring, configuration
issues, it MAY be useful to use standard management mechanisms for issues, it MAY be useful to use standard management mechanisms for
CEs and FEs. The ForCES architecture and requirements do not CEs and FEs. The ForCES architecture and requirements do not
preclude this. In general, for post-association phase, most preclude this. In general, for post-association phase, most
management tasks SHOULD be done through interaction with the CE. In management tasks SHOULD be done through interaction with the CE. In
certain conditions (e.g. CE/FE disconnection), it may be useful to 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 allow management tools (e.g., SNMP) to be used to diagnose and repair
problems. The following guidelines MUST be observed: problems. The following guidelines MUST be observed:
1. The ability for a management tool (e.g. SNMP) to be used to read
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. (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 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 change the state of a FE in a manner that affects overall NE
behavior without the CE being notified. behavior without the CE being notified.
6. FE Model Requirements 5. 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 how the FE processes packets. control a FE, the CE must understand how the FE processes packets. We
We therefore REQUIRE that a FE model be created that can express the therefore REQUIRE that a FE model be created that can express the
logical packet processing capabilities of a FE. This model will be logical packet processing capabilities of a FE. This model will be
used in the ForCES protocol to describe FE capabilities (see Section used in the ForCES protocol to describe FE capabilities (see Section
7, requirement #1). The FE model MUST define both a capability model 6, requirement #1). The FE model MUST define both a capability model
and a state model, which expresses the current configuration of the and a state model, which expresses the current configuration of the
device. The FE model MUST also support multiple FEs in the NE device. The FE model MUST also support multiple FEs in the NE
architecture. architecture.
6.1. Types of Logical Functions 5.1. Types of Logical Functions
The FE model MUST express what logical functions can be applied to The FE model MUST express what logical functions can be applied to
packets as they pass through a FE. packets as they pass through a FE. Logical functions are the packet
Logical functions are the packet processing functions that are processing functions that are applied to the packets as they are
applied to the packets as they are forwarded through a FE. Examples forwarded through a FE. Examples of logical functions are layer 3
of logical functions are layer 3 forwarding, firewall, NAT, shaping. forwarding, firewall, NAT, and shaping. Section 5.5 defines the
Section 6.5 defines the minimal set of logical functions that the FE minimal set of logical functions that the FE Model MUST support.
Model MUST support.
6.2. Variations of Logical Functions 5.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 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 certain FE the forwarding logical function might have information
about both the next hop IP address and the next hop MAC address, about both the next hop IP address and the next hop MAC address,
while on another FE these might be implemented as separate logical while on another FE these might be implemented as separate logical
functions. Another example would be NAT functionality that can have functions. Another example would be NAT functionality that can have
several flavors such as Traditional/Outbound NAT, Bi-directional several flavors such as Traditional/Outbound NAT, Bi-directional NAT,
NAT, Twice NAT, Multihomed NAT [RFC2663]. The model must be flexible Twice NAT, and Multihomed NAT [RFC2663]. The model must be flexible
enough to allow such variations in functions. enough to allow such variations in functions.
6.3. Ordering of Logical Functions 5.3. Ordering of Logical Functions
The model MUST be capable of describing the order in which these The model MUST be capable of describing the order in which these
logical functions are applied in a FE. The ordering of logical logical functions are applied in a FE. The ordering of logical
functions is important in many cases. For example, a NAT function functions is important in many cases. For example, a NAT function
may change a packet's source or destination IP address. Any number may change a packet's source or destination IP address. Any number
of other logical functions (e.g., layer 3 forwarding, ingress/egress of other logical functions (e.g., layer 3 forwarding, ingress/egress
firewall, shaping, accounting) may make use of the source or firewall, shaping, and 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
are replaced by public ones). replaced by public ones).
6.4. Flexibility 5.4. 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. In addition, the FE parameterization data can be easily added. In addition, the FE model
model MUST be capable of describing the types of statistics gathered MUST be capable of describing the types of statistics gathered by
by each logical function. each logical function.
6.5. Minimal Set of Logical Functions 5.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. This minimal set DOES NOT imply that any FE model MUST support. This minimal set DOES NOT imply that
that all FEs must provide this functionality. Instead, these all FEs must provide this functionality. Instead, these requirements
requirements only specify that the model must be capable of only specify that the model must be capable of expressing the
expressing the capabilities that FEs may choose to provide. capabilities that FEs may choose to 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
the device, the static attributes of each port (e.g., port type, device, the static attributes of each port (e.g., port type, link
link speed), and the configurable attributes of each port (e.g., IP 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. Support by the forwarding function to make a forwarding decision. Support
for IPv4 and IPv6 unicast and multicast forwarding functions MUST be for IPv4 and IPv6 unicast and multicast forwarding functions MUST be
provided by the model. provided by the model.
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
terms of, e.g., metering, policing, shaping, and queuing functions. of, e.g., metering, policing, shaping, and queuing functions. The FE
The FE model MUST be capable of expressing the use of these model MUST be capable of expressing the use of these functions to
functions to provide IntServ or DiffServ functionality as described provide IntServ or DiffServ functionality as described in [RFC2211],
in [RFC2211], [RFC2212], [RFC2215], [RFC2475], and [RFC3290]. [RFC2212], [RFC2215], [RFC2475], and [RFC3290].
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 these functions. The model MUST be able to express the existence of these
functions at arbitrary points in the sequence of a FE's packet functions at arbitrary points in the sequence of a FE's packet
processing functions. The FE model MUST be capable of expressing a processing functions. The FE model MUST be capable of expressing a
wide 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 new, currently unknown FE The FE model SHOULD be extensible so that new, currently unknown FE
functionality can be expressed. The FE Model SHOULD NOT be extended functionality can be expressed. The FE Model SHOULD NOT be extended
to express standard/common functions in a proprietary manner. This to express standard/common functions in a proprietary manner. This
would NOT be ForCES compliant. would NOT be ForCES compliant.
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 class of service that a packet should receive (i.e. that mark the class of service that a packet should receive (i.e.,
IPv4 header TOS octet or the IPv6 Traffic Class octet). The FE IPv4 header TOS octet or the IPv6 Traffic Class octet). The FE model
model MAY support other high touch functions (e.g., NAT, ALG). MAY support other high touch functions (e.g., NAT, 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.
8)Off-loaded Functions 8)Off-loaded Functions
Per-packet processing can leave state in the FE, so that logical Per-packet processing can leave state in the FE, so that logical
functions executed during packet processing can perform in a functions executed during packet processing can perform in a
consistent manner (for instance, each packet may update the state of consistent manner (for instance, each packet may update the state of
the token bucket occupancy of a give policer). In addition, the FE the token bucket occupancy of a give policer). In addition, the FE
skipping to change at page 10, line 44 skipping to change at page 10, line 34
events as well. This Does NOT mean off-loading of any piece of code events as well. This Does NOT mean off-loading of any piece of code
to an FE, just that the FE Model should be able to express existing to an FE, just that the FE Model should be able to express existing
Off-loaded functions on an FE. Off-loaded functions on an FE.
9)IPFLOW/PSAMP Functions 9)IPFLOW/PSAMP Functions
Several applications such as, Usage-based Accounting, Traffic Several applications such as, Usage-based Accounting, Traffic
engineering, require flow-based IP traffic measurements from Network engineering, require flow-based IP traffic measurements from Network
Elements. [IPFLOW] defines architecture for IP traffic flow Elements. [IPFLOW] defines architecture for IP traffic flow
monitoring, measuring and exporting. The FE model SHOULD be able to monitoring, measuring and exporting. The FE model SHOULD be able to
express metering functions and flow accounting needed for exporting express metering functions and flow accounting needed for exporting
IP traffic flow information. IP traffic flow information. Similarly to support measurement-based
Similarly to support measurement-based applications, [PSAMP] applications, [PSAMP] describes a framework to define a standard set
describes a framework to define a standard set of capabilities for of capabilities for network elements to sample subsets of packets by
network elements to sample subsets of packets by statistical and statistical and other methods. The FE model SHOULD be able to
other methods. The FE model SHOULD be able to express statistical express statistical packet filtering functions and packet information
packet filtering functions and packet information needed for needed for supporting packet sampling applications.
supporting packet sampling applications.
6. ForCES Protocol Requirements
7. ForCES Protocol Requirements
This section specifies some of the requirements that the 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
model whose requirements are defined in Section 6. Furthermore, the whose requirements are defined in Section 5. 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. The protocol capabilities that are discovered through the FE model. The protocol
MUST be able to add/remove classification/action entries, set/delete MUST be able to add/remove classification/action entries, set/delete
parameters, query statistics, and register for and receive events. parameters, query statistics, and register for and receive events.
2)Support for Secure Communication 2)Support for Secure Communication
a) FE configuration will contain information critical to the a) FE configuration will contain information critical to the
functioning of a network (e.g. IP Forwarding Tables). As such, it functioning of a network (e.g., IP Forwarding Tables). As
MUST be possible to ensure the integrity of all ForCES protocol such, it MUST be possible to ensure the integrity of all ForCES
messages and protect against man-in-the-middle attacks. protocol messages and protect against man-in-the-middle
b) FE configuration information may also contain information derived attacks.
from business relationships (e.g. service level agreements). b) FE configuration information may also contain information
Because of the confidential nature of the information, it MUST be derived from business relationships (e.g., service level
possible to secure (make private) all ForCES protocol messages. agreements). Because of the confidential nature of the
c) In order to ensure that authorized CEs and FEs are participating information, it MUST be possible to secure (make private) all
in a NE and defend against CE or FE impersonation attacks, the ForCES protocol messages.
ForCES architecture MUST select a means of authentication for CEs c) In order to ensure that authorized CEs and FEs are
and FEs. participating in a NE and defend against CE or FE impersonation
d) In some deployments ForCES is expected to be deployed between CEs attacks, the ForCES architecture MUST select a means of
and FEs connected to each other inside a box over a backplane, authentication for CEs and FEs.
where physical security of the box ensures that man-in-the-middle, d) In some deployments ForCES is expected to be deployed between
snooping, and impersonation attacks are not possible. In such CEs and FEs connected to each other inside a box over a
scenarios the ForCES architecture MAY rely on the physical backplane, where physical security of the box ensures that
security of the box to defend against these attacks and protocol man-in-the-middle, snooping, and impersonation attacks are not
mechanisms May be turned off. possible. In such scenarios the ForCES architecture MAY rely
on the physical security of the box to defend against these
attacks and protocol mechanisms May be turned off.
e) In the case when CEs and FEs are connected over a network, e) In the case when CEs and FEs are connected over a network,
security mechanisms MUST be specified or selected that protect the security mechanisms MUST be specified or selected that protect
ForCES protocol against such attacks. Any security solution used the ForCES protocol against such attacks. Any security
for ForCES MUST specify how it deals with such attacks. solution used for ForCES MUST specify how it deals with such
attacks.
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 a numbers. This requirement does not relate to the performance of a NE
NE as the number of FEs or ports in the NE grows. 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 L3 routing hop,
protocol will make use of an existing RFC2914 compliant L4 protocol the ForCES protocol will make use of an existing RFC2914 compliant L4
with adequate reliability, security and congestion control (e.g. protocol with adequate reliability, security and congestion control
TCP, SCTP) for transport purposes. (e.g., TCP, SCTP) for transport purposes.
5)Message Priority 5)Message Priority
The ForCES protocol MUST provide a means to express the protocol The ForCES protocol MUST provide a means to express the protocol
message priorities. message priorities.
6)Reliability 6)Reliability
a) The ForCES protocol will be used to transport information that a) The ForCES protocol will be used to transport information that
requires varying levels of reliability. By strict or robust requires varying levels of reliability. By strict or robust
reliability in this requirement we mean, no losses, no corruption, reliability in this requirement we mean, no losses, no
no re-ordering of information being transported and delivery in a corruption, no re-ordering of information being transported and
timely fashion. delivery in a timely fashion.
b) Some information or payloads, such as redirected packets or packet b) Some information or payloads, such as redirected packets or
sampling, may not require robust reliability (can tolerate some packet sampling, may not require robust reliability (can
degree of losses). For information of this sort, ForCES MUST NOT tolerate some degree of losses). For information of this sort,
be restricted to strict reliability. ForCES MUST NOT be restricted to strict reliability.
c) Payloads such as configuration information, e.g. ACLs, FIB c) Payloads such as configuration information, e.g., ACLs, FIB
entries, or FE capability information (described in section 7, entries, or FE capability information (described in section 6,
(1)) are mission critical and must be delivered in a robust (1)) are mission critical and must be delivered in a robust
reliable fashion. Thus, for information of this sort, ForCES MUST reliable fashion. Thus, for information of this sort, ForCES
either provide built-in protocol mechanisms or use a reliable MUST either provide built-in protocol mechanisms or use a
transport protocol for achieving robust/strict reliability. reliable transport protocol for achieving robust/strict
d) Some information or payloads, such as heartbeat packets that may
be used to detect loss of association between CE and FEs (see
section 7, (8)), may prefer timeliness over reliable delivery. For
information of this sort, ForCES MUST NOT be restricted to strict
reliability. reliability.
d) Some information or payloads, such as heartbeat packets that
may be used to detect loss of association between CE and FEs
(see section 6, (8)), may prefer timeliness over reliable
delivery. For information of this sort, ForCES MUST NOT be
restricted to strict reliability.
e) When ForCES is carried over multi-hop IP networks, it is a e) When ForCES is carried over multi-hop IP networks, it is a
requirement that ForCES MUST use a [RFC2914]-compliant transport requirement that ForCES MUST use a [RFC2914]-compliant
protocol. transport protocol.
f) In cases where ForCES is not running over an IP network such as an f) In cases where ForCES is not running over an IP network such as
Ethernet or cell fabric between CE and FE, then reliability still an Ethernet or cell fabric between CE and FE, then reliability
MUST be provided when carrying critical information of the types still MUST be provided when carrying critical information of
specified in (c) above, either by the underlying link/network/ the types specified in (c) above, either by the underlying
transport layers or by built-in protocol mechanisms. link/network/transport layers or by built-in protocol
mechanisms.
7)Interconnect Independence 7)Interconnect Independence
The ForCES protocol MUST support a variety of interconnect The ForCES protocol MUST support a variety of interconnect
technologies. (refer to section 5, requirement# 1) technologies. (refer to section 4, requirement #1)
8)CE redundancy or CE failover 8)CE redundancy or CE failover
The ForCES protocol MUST support mechanisms for CE redundancy or CE The ForCES protocol MUST support mechanisms for CE redundancy or CE
failover. This includes the ability for CEs and FEs to determine failover. This includes the ability for CEs and FEs to determine
when there is a loss of association between them, ability to restore when there is a loss of association between them, ability to restore
association and efficient state (re)synchronization mechanisms. This association and efficient state (re)synchronization mechanisms. This
also includes the ability to preset the actions an FE will take in 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 reaction to loss of association to its CE, e.g., whether the FE will
continue to forward packets or whether it will halt operations. continue to forward packets or whether it will halt operations.
(refer to section 5, requirement# 7) (refer to section 4, requirement #7)
9)Packet Redirection/Mirroring 9)Packet Redirection/Mirroring
a) The ForCES protocol MUST define a way to redirect packets from the a) The ForCES protocol MUST define a way to redirect packets from
FE to the CE and vice-versa. Packet redirection terminates any the FE to the CE and vice-versa. Packet redirection terminates
further processing of the redirected packet at the FE. any further processing of the redirected packet at the FE.
b) The ForCES protocol MUST define a way to mirror packets from the b) The ForCES protocol MUST define a way to mirror packets from
FE to the CE. Mirroring allows the packet duplicated by the FE at the FE to the CE. Mirroring allows the packet duplicated by
the mirroring point to be sent to the CE while the original packet the FE at the mirroring point to be sent to the CE while the
continues to be processed by the FE. original packet continues to be processed by the FE.
Examples of packets that may be redirected or mirrored include Examples of packets that may be redirected or mirrored include
control packets (such as RIP, OSPF messages) addressed to the control packets (such as RIP, OSPF messages) addressed to the
interfaces or any other relevant packets (such as those with Router interfaces or any other relevant packets (such as those with Router
Alert Option set). The ForCES protocol MUST also define a way for the Alert Option set). The ForCES protocol MUST also define a way for
CE to configure the behavior of a) and b) (above), to specify which the CE to configure the behavior of a) and b) (above), to specify
packets are affected by each. which packets are affected by each.
10)Topology Exchange 10)Topology Exchange
The ForCES protocol MUST allow the FEs to provide their topology The ForCES protocol or information carried in the ForCES protocol
information (topology by which the FEs in the NE are connected) to MUST allow those FEs which have inter-FE topology information to
the CE(s). (refer to section 5, requirement# 10) provide that information to the CE(s).
11)Dynamic Association 11)Dynamic Association
The ForCES protocol MUST allow CEs and FEs to join and leave a NE The ForCES protocol MUST allow CEs and FEs to join and leave a NE
dynamically. (refer to section 5, requirement# 12) dynamically. (refer to section 4, requirement #12)
12)Command Bundling 12)Command Bundling
The ForCES protocol MUST be able to group an ordered set of commands 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 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 few messages as possible. Furthermore, the protocol MUST support the
ability to specify if a command group MUST have all-or-nothing ability to specify if a command group MUST have all-or-nothing
semantics. semantics.
13)Asynchronous Event Notification 13)Asynchronous Event Notification
The ForCES protocol MUST be able to asynchronously notify the CE of The ForCES protocol MUST be able to asynchronously notify the CE of
events on the FE such as failures or change in available resources events on the FE such as failures or change in available resources or
or capabilities. (refer to section 5, requirement# 6) capabilities. (refer to section 4, requirement #6)
14)Query Statistics 14)Query Statistics
The ForCES protocol MUST provide a means for the CE to be able to The ForCES protocol MUST provide a means for the CE to be able to
query statistics (monitor performance) from the FE. query statistics (monitor performance) from the FE.
15) Protection against Denial of Service Attacks (based on CPU 15) Protection against Denial of Service Attacks (based on CPU
overload or queue overflow) overload or queue overflow)
Systems utilizing the ForCES protocol can be attacked using denial Systems utilizing the ForCES protocol can be attacked using denial of
of service attacks based on CPU overload or queue overflow. service attacks based on CPU overload or queue overflow. The ForCES
The ForCES protocol could be exploited by such attacks to cause the protocol could be exploited by such attacks to cause the CE to become
CE to become unable to control the FE or appropriately communicate unable to control the FE or appropriately communicate with other
with other routers and systems. The ForCES protocol MUST therefore routers and systems. The ForCES protocol MUST therefore provide
provide mechanisms for controlling FE capabilities that can be used mechanisms for controlling FE capabilities that can be used to
to protect against such attacks. FE capabilities that MUST be protect against such attacks. FE capabilities that MUST be
manipulated via ForCES include the ability to install classifiers manipulated via ForCES include the ability to install classifiers and
and filters to detect and drop attack packets, as well as to be able filters to detect and drop attack packets, as well as to be able to
to install rate limiters that limit the rate of packets which appear install rate limiters that limit the rate of packets which appear to
to be valid but may be part of an attack (e.g. bogus BGP packets). be valid but may be part of an attack (e.g., bogus BGP packets).
8. References 7. References
8.1.Normative References
[RFC3290] Y. Bernet, et. al., "An Informal Management Model for 7.1. Normative References
DiffServ Routers", , May 2002.
[RFC1812] F. Baker, "Requirements for IP Version 4 Routers", [RFC3290] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
RFC1812, June 1995. Informal Management Model for DiffServ Routers", RFC 3290,
May 2002.
[RFC2211] J. Wroclawski, "Specification of the Controlled-Load [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2211] Wroclawski, J., "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] Shenker, S., Partridge, C. and R. Guerin, "Specification
Guaranteed Quality of Service", RFC2212, September 1997. of Guaranteed Quality of Service", RFC 2212, September
1997.
[RFC2215] S. Shenker, J. Wroclawski, "General Characterization [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
Parameters for Integrated Service Network Elements", RFC2215, Parameters for Integrated Service Network Elements", RFC
September 1997. 2215, September 1997.
[RFC2475] S. Blake, et. Al., "An Architecture for Differentiated [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weisss, "An Architecture for Differentiated
Service", RFC2475, December 1998. Service", RFC2475, December 1998.
[RFC2914] S. Floyd, "Congestion Control Principles", RFC2914, [RFC2914] Floyd, S., "Congestion Control Principles", BCP 14, RFC
September 2000. 2914, September 2000.
[RFC2663] P. Srisuresh & M. Holdrege, "IP Network Address [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC2663, August Translator (NAT) Terminology and Considerations", RFC
1999. 2663, August 1999.
8.2.Informative References 7.2. Informative References
[REQ-PART] T. Anderson, J. Buerkle, "Requirements for the Dynamic [RFC3532] Anderson, T. and J. Buerkle, "Requirements for the Dynamic
Partitioning of Switching Elements", work in progress, July 2002, Partitioning of Switching Elements", RFC 3532, May 2003.
<draft-ietf-gsmp-dyn-part-reqs-02.txt>.
[IPFLOW] Quittek, et. Al., "Requirements for IP Flow Information [IPFLOW] Quittek, et al., "Requirements for IP Flow Information
Export", work in progress, February 2003, <draft-ietf-ipfix-reqs- Export", Work in Progress, February 2003.
09.txt>.
[PSAMP] Duffield, et. Al., "A Framework for Passive Packet [PSAMP] Duffield, et al., "A Framework for Passive Packet
Measurement ", work in progress, March 2003, <draft-ietf-psamp- Measurement ", Work in Progress, March 2003.
framework-02.txt>.
9. Security Considerations 8. Security Considerations
See architecture requirement #5 and protocol requirement #2. See architecture requirement #5 and protocol requirement #2.
10. Authors' Addresses & Acknowledgments 9. Authors' Addresses & Acknowledgments
This document was written by the ForCES Requirements design team: This document was written by the ForCES Requirements design team:
Todd A. Anderson (Editor) Todd A. Anderson (Editor)
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
Department of Computer Science Department of Computer Science
University of North Texas, University of North Texas,
Denton, Texas, 76203 Denton, Texas, 76203
Email: rdantu@unt.edu
Phone: 940 565 2822 Phone: 940 565 2822
EMail: rdantu@unt.edu
Avri Doria Avri Doria
Institute for System Technology ETRI
Lulea University of Technology 161 Gajeong-dong, Yuseong-gu
SE-971 87, Lulea, Sweden Deajeon 305-350 Korea
Phone: +46 (0)920 49 3030
Email: avri@sm.luth.se
EMail: avri@acm.org
Ram Gopal Ram Gopal
Nokia Research Center Nokia Research Center
5, Wayside Road, 5, Wayside Road,
Burlington, MA 01803 Burlington, MA 01803
Phone: 1-781-993-3685 Phone: 1-781-993-3685
Email: ram.gopal@nokia.com 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 (Editor) Hormuzd Khosravi (Editor)
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 Nokia Research Center
10 Tara Blvd., Suite 330 5 Wayside Road
Nashua, NH 03062 Burlington, MA 01803
Phone: +1 603 897 2067 Phone: +1 781 993 3858
Email: mrw@windriver.com EMail: margaret.wasserman@nokia.com
The authors would like to thank Vip Sharma and Lily Yang for their The authors would like to thank Vip Sharma and Lily Yang for their
valuable contributions. valuable contributions.
11. Editors' Contact Information 10. Editors' Contact Information
Hormuzd Khosravi Hormuzd Khosravi
Intel 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
Todd A. Anderson Todd A. Anderson
Intel 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
11. Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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