summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc3654.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc3654.txt')
-rw-r--r--doc/rfc/rfc3654.txt1011
1 files changed, 1011 insertions, 0 deletions
diff --git a/doc/rfc/rfc3654.txt b/doc/rfc/rfc3654.txt
new file mode 100644
index 0000000..4055dd9
--- /dev/null
+++ b/doc/rfc/rfc3654.txt
@@ -0,0 +1,1011 @@
+
+
+
+
+
+
+Network Working Group H. Khosravi, Ed.
+Request for Comments: 3654 T. Anderson, Ed.
+Category: Informational Intel
+ November 2003
+
+
+ Requirements for Separation of IP Control and Forwarding
+
+Status of this Memo
+
+ This memo provides information for the Internet community. It does
+ not specify an Internet standard of any kind. Distribution of this
+ memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2003). All Rights Reserved.
+
+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.
+
+Table of Contents
+
+ 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Architecture. . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. Architectural Requirements. . . . . . . . . . . . . . . . . . 5
+ 5. FE Model Requirements . . . . . . . . . . . . . . . . . . . . 7
+ 5.1. Types of Logical Functions. . . . . . . . . . . . . . . 8
+ 5.2. Variations of Logical Functions . . . . . . . . . . . . 8
+ 5.3. Ordering of Logical Functions . . . . . . . . . . . . . 8
+ 5.4. Flexibility . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.5 Minimal Set of Logical Functions. . . . . . . . . . . . 9
+ 6. ForCES Protocol Requirements. . . . . . . . . . . . . . . . . 10
+ 7. References. . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 7.1. Normative References. . . . . . . . . . . . . . . . . . 14
+ 7.2. Informative References. . . . . . . . . . . . . . . . . 15
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
+ 9. Authors' Addresses & Acknowledgments. . . . . . . . . . . . . 15
+ 10. Editors' Contact Information. . . . . . . . . . . . . . . . . 17
+ 11. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 18
+
+
+
+
+Khosravi & Anderson Informational [Page 1]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+1. Introduction
+
+ An IP network element is composed of numerous logically separate
+ entities that cooperate to provide a given functionality (such as a
+ routing or IP switching) and yet appear as a normal integrated
+ network element to external entities. Two primary types of network
+ element components exist: control-plane components and forwarding-
+ plane components. In general, forwarding-plane components are ASIC,
+ network-processor, or general-purpose processor-based devices that
+ handle all data path operations. Conversely, control-plane
+ components are typically based on general-purpose processors that
+ provide control functionality such as the processing of routing or
+ signaling protocols. A standard set of mechanisms for connecting
+ these components provides increased scalability and allows the
+ control and forwarding planes to evolve independently, thus promoting
+ faster innovation.
+
+ For the purpose of illustration, let us consider the architecture of
+ a router to illustrate the concept of separate control and forwarding
+ planes. The architecture of a router is composed of two main parts.
+ These components, while inter-related, perform functions that are
+ largely independent of each other. At the bottom is the forwarding
+ path that operates in the data-forwarding plane and is responsible
+ for per-packet processing and forwarding. Above the forwarding plane
+ is the network operating system that is responsible for operations in
+ the control plane. In the case of a router or switch, the network
+ operating system runs routing, signaling and control protocols (e.g.,
+ RIP, OSPF and RSVP) and dictates the forwarding behavior by
+ manipulating forwarding tables, per-flow QoS tables and access
+ control lists. Typically, the architecture of these devices combines
+ all of this functionality into a single functional whole with respect
+ to external entities.
+
+2. Definitions
+
+ Addressable Entity (AE) - A physical device that is directly
+ addressable given some interconnect technology. For example, on 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
+ communicate using a switch fabric port number.
+
+ Physical Forwarding Element (PFE) - An AE that includes hardware used
+ to provide per-packet processing and handling. This hardware may
+ consist of (but is not limited to) network processors, ASIC's, line
+ cards with multiple chips or stand alone box with general-purpose
+ processors.
+
+
+
+
+
+Khosravi & Anderson Informational [Page 2]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ Physical Control Element (PCE) - An AE that includes hardware used to
+ provide control functionality. This hardware typically includes a
+ general-purpose processor.
+
+ Forwarding Element (FE) - A logical entity that implements the ForCES
+ protocol. FEs use the underlying hardware to provide per-packet
+ processing and handling as directed/controlled by a CE via the ForCES
+ protocol. FEs may happen to be a single blade(or PFE), a partition
+ of a PFE or multiple PFEs.
+
+ Control Element (CE) - A logical entity that implements the ForCES
+ protocol and uses it to instruct one or more FEs how to process
+ packets. CEs handle functionality such as the execution of control
+ and signaling protocols. CEs may consist of PCE partitions or whole
+ PCEs.
+
+ Pre-association Phase - The period of time during which a FE Manager
+ (see below) and a CE Manager (see below) are determining which FE and
+ CE should be part of the same network element. Any partitioning of
+ PFEs and PCEs occurs during this phase.
+
+ 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
+ during which the CE and FE are establishing communication with one
+ another.
+
+ ForCES Protocol - While there may be multiple protocols used within
+ the overall ForCES architecture, the term "ForCES protocol" refers
+ only to the ForCES post-association phase protocol (see below).
+
+ ForCES Post-Association Phase Protocol - The protocol used for post-
+ association phase communication between CEs and FEs. This protocol
+ does not apply to CE-to-CE communication, FE-to-FE communication, or
+ to communication between FE and CE managers. The ForCES protocol is
+ a master-slave protocol in which FEs are slaves and CEs are masters.
+ This protocol includes both the management of the communication
+ channel (e.g., connection establishment, heartbeats) and the control
+ messages themselves. This protocol could be a single protocol or
+ could consist of multiple protocols working together.
+
+ FE Model - A model that describes the logical processing functions of
+ a FE.
+
+ FE Manager - A logical entity that operates in the pre-association
+ phase and is responsible for determining to which CE(s) a FE should
+ communicate. This process is called CE discovery and may involve the
+ FE manager learning the capabilities of available CEs. A FE manager
+ may use anything from a static configuration to a pre-association
+
+
+
+Khosravi & Anderson Informational [Page 3]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ phase protocol (see below) to determine which CE to use. However,
+ this pre-association phase protocol is currently out of scope. Being
+ a logical entity, a FE manager might be physically combined with any
+ of the other logical entities mentioned in this section.
+
+ CE Manager - A logical entity that operates in the pre-association
+ phase and is responsible for determining to which FE(s) a CE should
+ communicate. This process is called FE discovery and may involve the
+ CE manager learning the capabilities of available FEs. A CE manager
+ may use anything from a static configuration to a pre-association
+ phase protocol (see below) to determine which FE to use. Again, this
+ pre-association phase protocol is currently out of scope. Being a
+ logical entity, a CE manager might be physically combined with any of
+ the other logical entities mentioned in this section.
+
+ Pre-association Phase Protocol - A protocol between FE managers and
+ 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
+ discovery mechanism. Note that this capability discovery process is
+ wholly separate from (and does not replace) what is used within the
+ ForCES protocol (see Section 6, requirement #1). However, the two
+ capability discovery mechanisms may utilize the same FE model (see
+ Section 5). Pre-association phase protocols are not discussed
+ further in this document.
+
+ 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
+ single point of management. Similarly, a NE usually hides its
+ internal organization from external entities.
+
+ ForCES Protocol Element - A FE or CE.
+
+ High Touch Capability - This term will be used to apply to the
+ 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
+ the IP header. Examples of these capabilities include NAT-PT,
+ firewall, and L7 content recognition.
+
+3. Architecture
+
+ The chief components of a NE architecture are the CE, the FE, and the
+ interconnect protocol. The CE is responsible for operations such as
+ signaling and control protocol processing and the implementation of
+ management protocols. Based on the information acquired through
+ control processing, the CE(s) dictates the packet-forwarding behavior
+ of the FE(s) via the interconnect protocol. For example, the CE
+ might control a FE by manipulating its forwarding tables, the state
+ of its interfaces, or by adding or removing a NAT binding.
+
+
+
+Khosravi & Anderson Informational [Page 4]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ The FE operates in the forwarding plane and is responsible for per-
+ packet processing and handling. By allowing the control and
+ forwarding planes to evolve independently, different types of FEs can
+ be developed - some general purpose and others more specialized.
+ Some functions that FEs could perform include layer 3 forwarding,
+ metering, shaping, firewall, NAT, encapsulation (e.g., tunneling),
+ decapsulation, encryption, accounting, etc. Nearly all combinations
+ of these functions may be present in practical FEs.
+
+ 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
+ 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. These components are out of scope of
+ the architecture and requirements for the ForCES protocol, which only
+ involves CEs and FEs.
+
+ --------------------------------
+ | NE |
+ | ------------- |
+ | | CE | |
+ | ------------- |
+ | / \ |
+ | / \ |
+ | / \ |
+ | / \ |
+ | ----------- ----------- |
+ | | FE | | FE | |
+ | ----------- ----------- |
+ | | | | | | | | | |
+ | | | | | | | | | |
+ | | | | | | | | | |
+ | | | | | | | | | |
+ --------------------------------
+ | | | | | | | |
+ | | | | | | | |
+
+4. Architectural Requirements
+
+ The following are the architectural requirements:
+
+ 1) CEs and FEs MUST be able to connect by a variety of interconnect
+ technologies. Examples of interconnect technologies used in current
+ architectures include Ethernet, bus backplanes, and ATM (cell)
+ fabrics. FEs MAY be connected to each other via a different
+ technology than that used for CE/FE communication.
+
+
+
+
+
+Khosravi & Anderson Informational [Page 5]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ 2) FEs MUST support a minimal set of capabilities necessary for
+ establishing network connectivity (e.g., interface discovery, port
+ up/down functions). Beyond this minimal set, the ForCES architecture
+ MUST NOT restrict the types or numbers of capabilities that FEs may
+ contain.
+
+ 3) Packets MUST be able to arrive at the NE by one FE and leave the
+ NE via a different FE.
+
+ 4) A NE MUST support the appearance of a single functional device.
+ For example, in a router, the TTL of the packet should be decremented
+ only once as it traverses the NE regardless of how many FEs through
+ which it passes. However, external entities (e.g., FE managers and
+ CE managers) MAY have direct access to individual ForCES protocol
+ elements for providing information to transition them from the pre-
+ association to post-association phase.
+
+ 5) The architecture MUST provide a way to prevent unauthorized ForCES
+ protocol elements from joining a NE. (For more protocol details,
+ refer to section 6 requirement #2)
+
+ 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.
+ 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
+ possible for the relationship between a FE and its 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. The CE
+ needs to be informed of such changes so that it can control the FE in
+ an accurate way.
+
+ 7) The architecture MUST support mechanisms for CE redundancy or CE
+ failover. 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. This
+ 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 be able to redirect control packets (such as RIP, OSPF
+ messages) addressed to their interfaces to the CE. They MUST also
+ redirect other relevant packets (e.g., such as those with Router
+ Alert Option set) to their CE. The CEs MUST be able to configure the
+ packet redirection information/filters on the FEs. The CEs MUST also
+ be able to create packets and have its FEs deliver them.
+
+
+
+
+
+
+Khosravi & Anderson Informational [Page 6]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ 9) Any proposed ForCES architectures MUST explain how that
+ architecture supports all of the router functions as defined in
+ [RFC1812]. IPv4 Forwarding functions such IP header validation,
+ performing longest prefix match algorithm, TTL decrement, Checksum
+ calculation, generation of ICMP error messages, etc defined in RFC
+ 1812 should be explained.
+
+ 10) In a ForCES NE, the CE(s) MUST be able to learn the topology by
+ which the FEs in the NE are connected.
+
+ 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
+ ports.
+
+ 12) The ForCES architecture MUST allow FEs AND CEs to join and leave
+ NEs dynamically.
+
+ 13) The ForCES NE architecture MUST support multiple CEs and FEs.
+ However, coordination between CEs is out of scope of ForCES.
+
+ 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.
+
+5. FE Model Requirements
+
+ The variety of FE functionality that the ForCES architecture allows
+ 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. We
+ therefore REQUIRE that a FE model be created that can express the
+ logical packet processing capabilities of a FE. This model will be
+ used in the ForCES protocol to describe FE capabilities (see Section
+ 6, requirement #1). The FE model MUST define both a capability model
+ and a state model, which expresses the current configuration of the
+ device. The FE model MUST also support multiple FEs in the NE
+ architecture.
+
+
+
+
+Khosravi & Anderson Informational [Page 7]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+5.1. Types of Logical Functions
+
+ The FE model MUST express what logical functions can be applied to
+ packets as they pass through a FE. Logical functions are the packet
+ processing functions that are applied to the packets as they are
+ forwarded through a FE. Examples of logical functions are layer 3
+ forwarding, firewall, NAT, and shaping. Section 5.5 defines the
+ minimal set of logical functions that the FE Model MUST support.
+
+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
+ 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, and Multihomed NAT [RFC2663]. The model must be flexible
+ enough to allow such variations in functions.
+
+5.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, and accounting) may make use of the source or
+ destination IP address when making decisions. The CE needs to know
+ whether to configure these logical functions with the pre-NAT or
+ post-NAT IP address. Furthermore, the model MUST be capable of
+ expressing multiple instances of the same logical function in a FE's
+ processing path. Using NAT again as an example, one NAT function is
+ typically performed before the forwarding decision (packets arriving
+ externally have their public addresses replaced with private
+ addresses) and one NAT function is performed after the forwarding
+ decision (for packets exiting the domain, their private addresses are
+ replaced by public ones).
+
+5.4. Flexibility
+
+ Finally, the FE model SHOULD provide a flexible infrastructure in
+ which new logical functions and new classification, action, and
+ parameterization data can be easily added. In addition, the FE model
+ MUST be capable of describing the types of statistics gathered by
+ each logical function.
+
+
+
+
+Khosravi & Anderson Informational [Page 8]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+5.5. 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
+ all FEs must provide this functionality. Instead, these requirements
+ only specify that the model must be capable of expressing the
+ capabilities that FEs may choose to provide.
+
+ 1) Port Functions
+ 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, link
+ speed), and the configurable attributes of each port (e.g., IP
+ address, administrative status).
+
+ 2) Forwarding Functions
+ The FE model MUST be capable of expressing the data that can be used
+ by the forwarding function to make a forwarding decision. Support
+ for IPv4 and IPv6 unicast and multicast forwarding functions MUST be
+ provided by the model.
+
+ 3) QoS Functions
+ The FE model MUST allow a FE to express its QoS capabilities in terms
+ of, e.g., metering, policing, shaping, and queuing functions. The FE
+ model MUST be capable of expressing the use of these functions to
+ provide IntServ or DiffServ functionality as described in [RFC2211],
+ [RFC2212], [RFC2215], [RFC2475], and [RFC3290].
+
+ 4) Generic Filtering Functions
+ 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 at arbitrary points in the sequence of a FE's packet
+ processing functions. The FE model MUST be capable of expressing a
+ wide range of classification abilities from single fields (e.g.,
+ destination address) to arbitrary n-tuples. Similarly, the FE model
+ MUST be capable of expressing what actions these filtering functions
+ can perform on packets that the classifier matches.
+
+ 5) Vendor-Specific Functions
+ The FE model SHOULD be extensible so that new, currently unknown FE
+ functionality can be expressed. The FE Model SHOULD NOT be extended
+ to express standard/common functions in a proprietary manner. This
+ would NOT be ForCES compliant.
+
+ 6) High-Touch Functions
+ The FE model MUST be capable of expressing the encapsulation and
+ tunneling capabilities of a FE. The FE model MUST support functions
+
+
+
+
+
+Khosravi & Anderson Informational [Page 9]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ 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 model
+ MAY support other high touch functions (e.g., NAT, ALG).
+
+ 7) Security Functions
+ The FE model MUST be capable of expressing the types of encryption
+ that may be applied to packets in the forwarding path.
+
+ 8) Off-loaded Functions
+ Per-packet processing can leave state in the FE, so that logical
+ functions executed during packet processing can perform in a
+ consistent manner (for instance, each packet may update the state of
+ the token bucket occupancy of a give policer). In addition, the FE
+ Model MUST allow logical functions to execute asynchronously from
+ packet processing, according to a certain finite-state machine, in
+ order to perform functions that are, for instance, off-loaded from
+ the CE to the FE. The FE model MUST be capable of expressing these
+ asynchronous functions. Examples of such functions include the
+ finite-state machine execution required by TCP termination or OSPF
+ Hello processing, triggered not only by packet events, but by timer
+ 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
+ Off-loaded functions on an FE.
+
+ 9) IPFLOW/PSAMP Functions
+ Several applications such as, Usage-based Accounting, Traffic
+ engineering, require flow-based IP traffic measurements from Network
+ Elements. [IPFLOW] defines architecture for IP traffic flow
+ monitoring, measuring and exporting. The FE model SHOULD be able to
+ express metering functions and flow accounting needed for exporting
+ IP traffic flow information. Similarly to support measurement-based
+ applications, [PSAMP] describes a framework to define a standard set
+ of capabilities for network elements to sample subsets of packets by
+ statistical and other methods. The FE model SHOULD be able to
+ express statistical packet filtering functions and packet information
+ needed for supporting packet sampling applications.
+
+6. ForCES Protocol Requirements
+
+ This section specifies some of the requirements that the ForCES
+ protocol MUST meet.
+
+ 1) Configuration of Modeled Elements
+ The ForCES protocol MUST allow the CEs to determine the capabilities
+ of each FE. These capabilities SHALL be expressed using the FE model
+ whose requirements are defined in Section 5. Furthermore, the
+ protocol MUST provide a means for the CEs to control all the FE
+
+
+
+
+Khosravi & Anderson Informational [Page 10]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ capabilities that are discovered through the FE model. The protocol
+ MUST be able to add/remove classification/action entries, set/delete
+ parameters, query statistics, and register for and receive events.
+
+ 2) Support for Secure Communication
+ a) FE configuration will contain information critical to the
+ functioning of a network (e.g., IP Forwarding Tables). As
+ such, it MUST be possible to ensure the integrity of all ForCES
+ protocol messages and protect against man-in-the-middle
+ attacks.
+ b) FE configuration information may also contain information
+ derived from business relationships (e.g., service level
+ agreements). Because of the confidential nature of the
+ information, it MUST be possible to secure (make private) all
+ ForCES protocol messages.
+ c) In order to ensure that authorized CEs and FEs are
+ participating in a NE and defend against CE or FE impersonation
+ attacks, the ForCES architecture MUST select a means of
+ authentication for CEs and FEs.
+ d) In some deployments ForCES is expected to be deployed between
+ CEs and FEs connected to each other inside a box over a
+ backplane, where physical security of the box ensures that
+ man-in-the-middle, snooping, and impersonation attacks are not
+ 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,
+ security mechanisms MUST be specified or selected that protect
+ the ForCES protocol against such attacks. Any security
+ solution used for ForCES MUST specify how it deals with such
+ attacks.
+
+ 3) Scalability
+ 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
+ example, the ForCES protocol field sizes corresponding to FE or port
+ numbers SHALL be large enough to support the minimum required
+ numbers. This requirement does not relate to the performance of a NE
+ as the number of FEs or ports in the NE grows.
+
+ 4) Multihop
+ When the CEs and FEs are separated beyond a single L3 routing hop,
+ the ForCES protocol will make use of an existing RFC2914 compliant L4
+ protocol with adequate reliability, security and congestion control
+ (e.g., TCP, SCTP) for transport purposes.
+
+
+
+
+
+
+Khosravi & Anderson Informational [Page 11]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ 5) Message Priority
+ The ForCES protocol MUST provide a means to express the protocol
+ message priorities.
+
+ 6) Reliability
+ a) The ForCES protocol will be used to transport information that
+ requires varying levels of reliability. By strict or robust
+ reliability in this requirement we mean, no losses, no
+ corruption, no re-ordering of information being transported and
+ delivery in a timely fashion.
+ b) Some information or payloads, such as redirected packets or
+ packet sampling, may not require robust reliability (can
+ tolerate some degree of losses). For information of this sort,
+ ForCES MUST NOT be restricted to strict reliability.
+ c) Payloads such as configuration information, e.g., ACLs, FIB
+ entries, or FE capability information (described in section 6,
+ (1)) are mission critical and must be delivered in a robust
+ reliable fashion. Thus, for information of this sort, ForCES
+ MUST either provide built-in protocol mechanisms or use a
+ reliable transport protocol for achieving robust/strict
+ 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
+ requirement that ForCES MUST use a [RFC2914]-compliant
+ transport protocol.
+ f) In cases where ForCES is not running over an IP network such as
+ an Ethernet or cell fabric between CE and FE, then reliability
+ still MUST be provided when carrying critical information of
+ the types specified in (c) above, either by the underlying
+ link/network/transport layers or by built-in protocol
+ mechanisms.
+
+ 7) Interconnect Independence
+ The ForCES protocol MUST support a variety of interconnect
+ technologies. (refer to section 4, requirement #1)
+
+ 8) CE redundancy or CE failover
+ The ForCES protocol MUST support mechanisms for CE redundancy or CE
+ failover. 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. This
+ also includes the ability to preset the actions an FE will take in
+
+
+
+
+
+Khosravi & Anderson Informational [Page 12]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ 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 4, requirement #7)
+
+ 9) Packet Redirection/Mirroring
+ a) The ForCES protocol MUST define a way to redirect packets from
+ the FE to the CE and vice-versa. Packet redirection terminates
+ any further processing of the redirected packet at the FE.
+ b) The ForCES protocol MUST define a way to mirror packets from
+ the FE to the CE. Mirroring allows the packet duplicated by
+ the FE at the mirroring point to be sent to the CE while the
+ original packet continues to be processed by the FE.
+
+ Examples of packets that may be redirected or mirrored include
+ control packets (such as RIP, OSPF messages) addressed to the
+ interfaces or any other relevant packets (such as those with Router
+ Alert Option set). The ForCES protocol MUST also define a way for
+ the CE to configure the behavior of a) and b) (above), to specify
+ which packets are affected by each.
+
+ 10) Topology Exchange
+ The ForCES protocol or information carried in the ForCES protocol
+ MUST allow those FEs which have inter-FE topology information to
+ provide that information to the CE(s).
+
+ 11) Dynamic Association
+ The ForCES protocol MUST allow CEs and FEs to join and leave a NE
+ dynamically. (refer to section 4, 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 failures or change in available resources or
+ capabilities. (refer to section 4, requirement #6)
+
+ 14) Query Statistics
+ The ForCES protocol MUST provide a means for the CE to be able to
+ query statistics (monitor performance) from the FE.
+
+
+
+
+
+
+
+Khosravi & Anderson Informational [Page 13]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ 15) Protection against Denial of Service Attacks (based on CPU
+ overload or queue overflow)
+ Systems utilizing the ForCES protocol can be attacked using denial of
+ service attacks based on CPU overload or queue overflow. The ForCES
+ protocol could be exploited by such attacks to cause the CE to become
+ unable to control the FE or appropriately communicate with other
+ routers and systems. The ForCES protocol MUST therefore provide
+ mechanisms for controlling FE capabilities that can be used to
+ protect against such attacks. FE capabilities that MUST be
+ manipulated via ForCES include the ability to install classifiers and
+ filters to detect and drop attack packets, as well as to be able to
+ install rate limiters that limit the rate of packets which appear to
+ be valid but may be part of an attack (e.g., bogus BGP packets).
+
+7. References
+
+7.1. Normative References
+
+ [RFC3290] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An
+ Informal Management Model for DiffServ Routers", RFC 3290,
+ May 2002.
+
+ [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
+ 1812, June 1995.
+
+ [RFC2211] Wroclawski, J., "Specification of the Controlled-Load
+ Network Element Service", RFC 2211, September 1997.
+
+ [RFC2212] Shenker, S., Partridge, C. and R. Guerin, "Specification
+ of Guaranteed Quality of Service", RFC 2212, September
+ 1997.
+
+ [RFC2215] Shenker, S. and J. Wroclawski, "General Characterization
+ Parameters for Integrated Service Network Elements", RFC
+ 2215, September 1997.
+
+ [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
+ and W. Weisss, "An Architecture for Differentiated
+ Service", RFC 2475, December 1998.
+
+ [RFC2914] Floyd, S., "Congestion Control Principles", BCP 14, RFC
+ 2914, September 2000.
+
+ [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
+ Translator (NAT) Terminology and Considerations", RFC
+ 2663, August 1999.
+
+
+
+
+
+Khosravi & Anderson Informational [Page 14]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+7.2. Informative References
+
+ [RFC3532] Anderson, T. and J. Buerkle, "Requirements for the Dynamic
+ Partitioning of Switching Elements", RFC 3532, May 2003.
+
+ [IPFLOW] Quittek, et al., "Requirements for IP Flow Information
+ Export", Work in Progress, February 2003.
+
+ [PSAMP] Duffield, et al., "A Framework for Passive Packet
+ Measurement ", Work in Progress, March 2003.
+
+8. Security Considerations
+
+ See architecture requirement #5 and protocol requirement #2.
+
+9. Authors' Addresses & Acknowledgments
+
+ This document was written by the ForCES Requirements design team:
+
+ Todd A. Anderson (Editor)
+
+
+ Ed Bowen
+ IBM Zurich Research Laboratory
+ Saumerstrasse 4
+ CH-8803 Rueschlikon Switzerland
+
+ Phone: +41 1 724 83 68
+ EMail: edbowen@us.ibm.com
+
+
+ Ram Dantu
+ Department of Computer Science
+ University of North Texas,
+ Denton, Texas, 76203
+
+ Phone: 940 565 2822
+ EMail: rdantu@unt.edu
+
+
+ Avri Doria
+ ETRI
+ 161 Gajeong-dong, Yuseong-gu
+ Deajeon 305-350 Korea
+
+ EMail: avri@acm.org
+
+
+
+
+
+Khosravi & Anderson Informational [Page 15]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+ Ram Gopal
+ Nokia Research Center
+ 5, Wayside Road,
+ Burlington, MA 01803
+
+ Phone: 1-781-993-3685
+ EMail: ram.gopal@nokia.com
+
+
+ Jamal Hadi Salim
+ Znyx Networks
+ Ottawa, Ontario
+ Canada
+
+ EMail: hadi@znyx.com
+
+
+ Hormuzd Khosravi (Editor)
+
+
+ Muneyb Minhazuddin
+ Avaya Inc.
+ 123, Epping road,
+ North Ryde, NSW 2113, Australia
+ Phone: +61 2 9352 8620
+ EMail: muneyb@avaya.com
+
+
+ Margaret Wasserman
+ Nokia Research Center
+ 5 Wayside Road
+ Burlington, MA 01803
+ Phone: +1 781 993 3858
+ EMail: margaret.wasserman@nokia.com
+
+ The authors would like to thank Vip Sharma and Lily Yang for their
+ valuable contributions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Khosravi & Anderson Informational [Page 16]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+10. Editors' Contact Information
+
+ Hormuzd Khosravi
+ Intel
+ 2111 NE 25th Avenue
+ Hillsboro, OR 97124 USA
+
+ Phone: +1 503 264 0334
+ EMail: hormuzd.m.khosravi@intel.com
+
+
+ Todd A. Anderson
+ Intel
+ 2111 NE 25th Avenue
+ Hillsboro, OR 97124 USA
+
+ Phone: +1 503 712 1760
+ EMail: todd.a.anderson@intel.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Khosravi & Anderson Informational [Page 17]
+
+RFC 3654 ForCES Requirements November 2003
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Khosravi & Anderson Informational [Page 18]
+