From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3654.txt | 1011 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1011 insertions(+) create mode 100644 doc/rfc/rfc3654.txt (limited to 'doc/rfc/rfc3654.txt') 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] + -- cgit v1.2.3