RFC 3654
Requirements for Separation of IP Control and Forwarding
RFC 3654: Requirements for Separation of IP Control and Forwarding 🦋
bestie, this is the RFC that asks: what if a router's brain and its muscles were separate? 🧠💪 Here's the title block so you know who wrote it:
- Authors: H. Khosravi, Ed. and T. Anderson, Ed., both from Intel 💜
- Category: Informational, so this is info, not a binding standard 🎀
- Date: November 2003 🍓
- Obsoletes and updates: the header doesn't list any RFCs it obsoletes or updates ✨
Status of this Memo ✨
okay so this memo is just giving info to the internet community 📚 It does not set any kind of Internet standard. Distribution is totally unlimited, so share it with everyone 💅
Copyright Notice 🌸
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract 🔮
this doc introduces ForCES (Forwarding and Control Element Separation) and gives you a set of terms to talk about it 🧚 It also lays out the architecture, modeling, and protocol requirements for logically splitting a networking device's control plane from its data forwarding plane. This works for IP devices (IPv4, IPv6, and so on) 🌈
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. . . . . . . . . . . . . . . . . . . 181. Introduction 🎀
okay so an IP network element is actually a bunch of logically separate parts that work together to do one job, like routing or IP switching 🔀 but from the outside it just looks like one normal box 📦 There are two main kinds of parts: control-plane parts and forwarding-plane parts 🧠💪 Forwarding-plane parts are usually ASICs, network processors, or general-purpose processor devices, and they handle all the data path stuff 🏎️ Control-plane parts are usually general-purpose processors that handle things like routing or signaling protocols 📡
Here's the tea ☕ If you have a standard set of ways for these parts to connect, you get better scalability, and the control and forwarding planes can evolve on their own. That means faster innovation for everyone 🚀✨
To make this concrete, let's look at a router 🖥️ A router has two main pieces that are mostly independent of each other. At the bottom is the forwarding path, which lives in the data-forwarding plane and handles per-packet processing and forwarding 📦 Above that is the network operating system, which runs the control plane 👑 For a router or switch, that OS runs routing, signaling, and control protocols (like RIP, OSPF, and RSVP) and decides how forwarding behaves by changing forwarding tables, per-flow QoS tables, and access control lists 💅 Usually all of this gets bundled into one single unit as far as the outside world is concerned 🎁
2. Definitions 📖
okay bestie, let's get the vocab down. These are the terms the rest of the doc relies on 🫶
- Addressable Entity (AE) - a physical device you can directly address, given some interconnect technology 📍 On IP networks, it's a device you talk to using an IP address. On a switch fabric, it's a device you talk to using a switch fabric port number 🔌
- Physical Forwarding Element (PFE) - an AE that has the hardware doing per-packet processing and handling ⚡ That hardware could include (but isn't limited to) network processors, ASICs, line cards with multiple chips, or a standalone box with general-purpose processors 🧩
- Physical Control Element (PCE) - an AE that has the hardware doing control functionality 🧠 That hardware usually includes a general-purpose processor 💻
- Forwarding Element (FE) - a logical entity that implements the ForCES protocol 🦋 FEs use the underlying hardware to do per-packet processing and handling, as directed and controlled by a CE over the ForCES protocol 🎯 An FE might 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 tell one or more FEs how to process packets 👑 CEs handle stuff like running control and signaling protocols 🧠 A CE might be made of PCE partitions or whole PCEs 🧩
- Pre-association Phase - the stretch of time when an FE Manager (see below) and a CE Manager (see below) are figuring out which FE and CE should belong to the same network element 🤝 Any partitioning of PFEs and PCEs happens during this phase 🍕
- Post-association Phase - the stretch of time when an FE does know which CE is controlling it (and vice versa), including the time they spend setting up communication with each other 📞
- ForCES Protocol - there might be several protocols in the overall ForCES architecture, but when this doc says "ForCES protocol," it only means the ForCES post-association phase protocol (see below) 🎯
- ForCES Post-Association Phase Protocol - the protocol used for communication between CEs and FEs after association 💬 It does not cover CE-to-CE talk, FE-to-FE talk, or talk between FE and CE managers 🚫 It's a master-slave protocol where FEs are the slaves and CEs are the masters 👑🫠 It covers both managing the communication channel (like connection setup and heartbeats) and the control messages themselves 💓 It could be one protocol or several working together 🧶
- FE Model - a model that describes the logical processing functions of an FE 📐
- FE Manager - a logical entity that works in the pre-association phase and decides which CE(s) an FE should talk to 🕵️♀️ This is called CE discovery, and it may involve the FE Manager learning what the available CEs can do 🔍 An FE Manager can use anything from static configuration to a pre-association phase protocol (see below) to pick a CE 🎀 Just note that this pre-association phase protocol is currently out of scope 🙈 Since it's a logical entity, an FE Manager might be physically combined with any of the other logical entities in this section 🫶
- CE Manager - a logical entity that works in the pre-association phase and decides which FE(s) a CE should talk to 🕵️ This is called FE discovery, and it may involve the CE Manager learning what the available FEs can do 🔎 A CE Manager can use anything from static configuration to a pre-association phase protocol (see below) to pick an FE 💫 Again, that pre-association phase protocol is currently out of scope 🙈 Since it's a logical entity, a CE Manager might be physically combined with any of the other logical entities in this section 🧸
- Pre-association Phase Protocol - a protocol between FE Managers and CE Managers that's used to decide which CEs or FEs to use 🤝 It may include a CE and/or FE capability discovery mechanism 🔍 Note that this capability discovery is totally separate from (and does not replace) what's used inside the ForCES protocol (see Section 6, requirement #1) 🚫 However, the two capability discovery mechanisms may use the same FE model (see Section 5) 📐 Pre-association phase protocols aren't discussed any further in this document 🙃
- ForCES Network Element (NE) - an entity made of one or more CEs and one or more FEs 🏠 To anything outside the NE, it looks like a single point of management 🎯 And an NE usually hides its internal organization from outside entities 🥷
- ForCES Protocol Element - an FE or a CE 🧩
- High Touch Capability - this term covers the capabilities some forwarders have for acting on the contents or headers of a packet based on something other than what's in the IP header 👀 Examples include NAT-PT, firewall, and L7 content recognition 🛡️
3. Architecture 🏗️
the main parts of an NE architecture are the CE, the FE, and the interconnect protocol 💖 The CE handles operations like signaling, control protocol processing, and implementing management protocols 🧠 Based on what it learns through control processing, the CE(s) decide how the FE(s) forward packets, and they do that through the interconnect protocol 🎮 For example, a CE might control an FE by changing its forwarding tables, the state of its interfaces, or by adding or removing a NAT binding 🌐
The FE lives in the forwarding plane and handles per-packet processing and handling 📦 Since the control and forwarding planes evolve independently, you can build different kinds of FEs, some general-purpose and some more specialized 🧁 FEs could do things like layer 3 forwarding, metering, shaping, firewall, NAT, encapsulation (like tunneling), decapsulation, encryption, accounting, and more 🎀 Almost any combo of these functions could show up in real FEs 🍭
Here's a diagram of an example NE with one CE and two FEs 🦋 Both the FEs and the CE need minimal configuration as part of pre-configuration, which an FE Manager and a CE Manager might handle, respectively 🧸 Other than that, FE Managers and CE Managers don't have any defined role here 🙅♀️ They're out of scope for the architecture and requirements of the ForCES protocol, which only involves CEs and FEs 💅
--------------------------------
| NE |
| ------------- |
| | CE | |
| ------------- |
| / \ |
| / \ |
| / \ |
| / \ |
| ----------- ----------- |
| | FE | | FE | |
| ----------- ----------- |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
--------------------------------
| | | | | | | |
| | | | | | | |Part 1 done, bestie! 🌈✨ More parts are coming, so stay tuned 💜🎀
4. Architectural Requirements ✨
okay so bestie, these are the architectural requirements, and they are a whole vibe 🎀
- 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.
- 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. the freedom is giving 💅
- Packets MUST be able to arrive at the NE by one FE and leave the NE via a different FE. 🦋
- 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.
- 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)
- 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.
- 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.
- 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. 📦
- 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.
- In a ForCES NE, the CE(s) MUST be able to learn the topology by which the FEs in the NE are connected. 🗺️
- 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. 📈
- The ForCES architecture MUST allow FEs AND CEs to join and leave NEs dynamically. 🔄
- The ForCES NE architecture MUST support multiple CEs and FEs. However, coordination between CEs is out of scope of ForCES. 🙅♀️
- 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: 🛠️
- 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.
- 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 🦋
okay the FE functionality variety is a whole mood, and it's kinda a problem for CEs 😭 The variety of FE functionality that the ForCES architecture allows poses a potential problem for CEs. To control a FE properly, the CE has to understand how the FE processes packets. So we 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.
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. 📊
5.5. Minimal Set of Logical Functions 🎀
okay bestie, the rest of this section lays out a minimal set of logical functions that any FE model MUST support 💅 this minimal set does not mean every FE has to provide all of this stuff 🙈 it's more like the model has to be able to describe the capabilities that FEs might choose to offer. the model needs the vocab, not the whole party 🎉
1) Port Functions 🔌
the FE model MUST be capable of expressing how many ports the device has, the static attributes of each port (like port type and link speed), and the configurable attributes of each port (like IP address and administrative status). basically, every port needs its own little profile card 🪪✨
2) Forwarding Functions 🚗
the FE model MUST be capable of expressing the data that the forwarding function can use to make a forwarding decision. IPv4 and IPv6 unicast and multicast forwarding functions MUST be provided by the model. no skipping any of these, they're all main character energy 👑
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 model MUST also be capable of expressing how these functions get used to provide IntServ or DiffServ functionality, as described in [RFC2211], [RFC2212], [RFC2215], [RFC2475], and [RFC3290]. the QoS glow-up is real 🦋
4) Generic Filtering Functions 🧹
the FE model MUST be capable of expressing complex sets of filtering functions. the model MUST be able to express where these functions exist at arbitrary points in the sequence of a FE's packet processing functions 📍 it also MUST be capable of expressing a wide range of classification abilities, from single fields (e.g., destination address) all the way up to arbitrary n-tuples 🧩 and similarly, the FE model MUST be capable of expressing what actions these filtering functions can perform on the packets that the classifier matches 🎯 the sorting hat is serving 🧙♀️
5) Vendor-Specific Functions 🏷️
the FE model SHOULD be extensible so that new, currently unknown FE functionality can be expressed 🌈 but the FE Model SHOULD NOT be extended to express standard or common functions in a proprietary manner. that would not be ForCES compliant 🙅♀️ no proprietary side quests for the basics, periodt 💀
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 that mark the class of service a packet should receive (i.e., the IPv4 header TOS octet or the IPv6 Traffic Class octet) 🏷️ the FE model MAY support other high-touch functions (e.g., NAT, ALG). those are optional extras, so totally your call 🍓
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. locking it down, fr fr 🔒
8) Off-loaded Functions 🧚
okay this one is kinda deep so stay with me 🫠 per-packet processing can leave state in the FE, so that logical functions executed during packet processing can behave in a consistent manner. for example, each packet may update the token bucket occupancy of a given policer, so the state stays accurate across the stream 🪣 in addition, the FE Model MUST allow logical functions to execute asynchronously from packet processing, according to a certain finite-state machine. this is how stuff gets off-loaded from the CE to the FE 🚚 the FE model MUST be capable of expressing these asynchronous functions. examples include the finite-state machine execution needed for TCP termination or OSPF Hello processing, which can be triggered not only by packet events but by timer events as well ⏰
this does not mean off-loading any piece of code to an FE. it just means the FE Model should be able to express existing Off-loaded functions on an FE 📝 the model describes it, it doesn't ship your code over 🙃
9) IPFLOW/PSAMP Functions 📈
several applications, such as usage-based accounting and traffic engineering, need flow-based IP traffic measurements from network elements 📡 [IPFLOW] defines an architecture for IP traffic flow monitoring, measuring, and exporting. the FE model SHOULD be able to express the metering functions and flow accounting needed for exporting IP traffic flow information 🧾 similarly, to support measurement-based applications, [PSAMP] describes a framework for defining a standard set of capabilities that let network elements sample subsets of packets by statistical and other methods 🎲 the FE model SHOULD be able to express statistical packet filtering functions and the packet information needed to support packet sampling applications. data girlies unite 💜
6. ForCES Protocol Requirements ✨
okay so this section lays out some of the requirements the ForCES protocol MUST meet 💅 think of them as the non-negotiables, bestie 🫶
- Configuration of Modeled Elements 🎀 The ForCES protocol MUST let the CEs figure out what each FE can do. Those capabilities SHALL be described using the FE model from Section 5. The protocol MUST also give the CEs a way to control every FE capability they discover through that model. The protocol MUST be able to add/remove classification/action entries, set/delete parameters, query statistics, and register for and receive events.
- Support for Secure Communication 🔐 this one is a whole vibe, so let's go through it
- a) FE configuration holds stuff the network literally can't run without, like IP Forwarding Tables 😭 So it MUST be possible to ensure the integrity of all ForCES protocol messages and protect against man-in-the-middle attacks.
- b) FE configuration can also include info from business deals, like service level agreements. Since that's confidential, it MUST be possible to secure (make private) all ForCES protocol messages.
- c) To make sure only authorized CEs and FEs are taking part in an NE, and to defend against CE or FE impersonation attacks, the ForCES architecture MUST select a means of authentication for CEs and FEs.
- d) In some deployments, CEs and FEs are connected inside a box over a backplane. The box's physical security makes man-in-the-middle, snooping, and impersonation attacks impossible, so the ForCES architecture MAY rely on that physical security to defend against these attacks, and protocol mechanisms may be turned off.
- e) 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.
- 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 an NE as the number of FEs or ports in the NE grows.
- Multihop 🛣️ When the CEs and FEs are separated beyond a single L3 routing hop, the ForCES protocol will use an existing RFC2914 compliant L4 protocol with adequate reliability, security and congestion control (e.g., TCP, SCTP) for transport.
- Message Priority 🚦 The ForCES protocol MUST provide a means to express the protocol message priorities.
- Reliability 💎 different payloads need different levels of reliability, so let's break it down
- a) ForCES will carry information that needs varying levels of reliability. By strict or robust reliability here, we mean no losses, no corruption, no re-ordering of the information being transported, and delivery in a timely fashion.
- b) Some payloads, like redirected packets or packet sampling, don't need robust reliability and can tolerate some losses. For information of this sort, ForCES MUST NOT be restricted to strict reliability.
- c) Payloads like configuration information (ACLs, FIB entries, or FE capability information described in section 6, (1)) are mission critical and must be delivered in a robust reliable fashion. So for this information, ForCES MUST either provide built-in protocol mechanisms or use a reliable transport protocol to achieve robust/strict reliability.
- d) Some payloads, like heartbeat packets 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) When ForCES isn't running over an IP network, like Ethernet or a cell fabric between CE and FE, reliability still MUST be provided when carrying critical information of the types in (c) above. That can come from the underlying link/network/transport layers or from built-in protocol mechanisms.
- Interconnect Independence 🔌 The ForCES protocol MUST support a variety of interconnect technologies. (refer to section 4, requirement #1)
- 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, the ability to restore association, and efficient state (re)synchronization mechanisms. It also includes the ability to preset the actions an FE will take in reaction to loss of association with its CE, e.g., whether the FE will continue to forward packets or whether it will halt operations. (refer to section 4, requirement #7)
- 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 lets the packet duplicated by the FE at the mirroring point be sent to the CE, while the original packet keeps being 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.
- 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).
- Dynamic Association 💃 The ForCES protocol MUST allow CEs and FEs to join and leave an NE dynamically. (refer to section 4, requirement #12)
- Command Bundling 📦 The ForCES protocol MUST be able to group an ordered set of commands to an 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 whether a command group MUST have all-or-nothing semantics.
- Asynchronous Event Notification 🔔 The ForCES protocol MUST be able to asynchronously notify the CE of events on the FE, such as failures or changes in available resources or capabilities. (refer to section 4, requirement #6)
- Query Statistics 📊 The ForCES protocol MUST provide a means for the CE to query statistics (monitor performance) from the FE.
- Protection against Denial of Service Attacks (based on CPU overload or queue overflow) 🛡️ Systems using the ForCES protocol can be attacked with denial of service attacks based on CPU overload or queue overflow. ForCES could be exploited by such attacks to leave the CE unable to control the FE or to communicate properly 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 the ability 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.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 🔒
this section is short, but it's SO important 💀 See architecture requirement #5 and protocol requirement #2 for the full tea 🫖
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
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.comThe authors would like to thank Vip Sharma and Lily Yang for their valuable contributions. 🫶
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.com11. Full Copyright Statement 🎀
Okay bestie, this part is the legal stuff, but it's actually pretty simple once you read it. 💅
Copyright (C) The Internet Society (2003). All Rights Reserved. 🌸
So basically, anyone is allowed to copy this document and share it with others. People can also write derivative works that comment on it, explain it, or help people implement it, and they can publish and distribute those too, in whole or in part, with no restrictions of any kind. 🦋 The one big condition is that the above copyright notice and this paragraph have to stay on every copy and every derivative work. 💜
Here's the catch: this document itself can't be modified in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. 🙈 The only exceptions are two. First, you can make changes needed for developing Internet standards, but then you have to follow the copyright procedures defined in the Internet Standards process. Second, you can translate it into languages other than English. 🌈
The permissions granted above are perpetual, which means they will not be revoked by the Internet Society or its successors or assignees. ⭐ That's a forever kind of promise. 🫶
This document and the information in it are 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. 💀 Translation: they're not promising it'll work perfectly or that it won't step on anyone's rights. Plan accordingly, babe. ✨
Acknowledgement 🧚
Funding for the RFC Editor function is currently provided by the Internet Society. 👑 So the people who keep the RFC library running get their paycheck from them right now. Iconic support. 🍓
That's the whole document, bestie! 🌈💖 Thanks for being the best study buddy, and go forth and implement ForCES like the networking queen you are. 👑🦋
📦 where this page comes from
- ietf: rfc3654 2003-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms