idnits 2.17.1 draft-ietf-forces-requirements-10.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2003) is 7585 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 35, but not defined == Unused Reference: 'RFC2914' is defined on line 656, but no explicit reference was found in the text == Unused Reference: 'REQ-PART' is defined on line 665, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3290 ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Downref: Normative reference to an Informational RFC: RFC 2663 -- Possible downref: Non-RFC (?) normative reference: ref. 'REQ-PART' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPFLOW' -- Possible downref: Non-RFC (?) normative reference: ref. 'PSAMP' Summary: 9 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft H. Khosravi, 2 Expiration: January 2004 T. Anderson (Editors) 3 File: draft-ietf-forces-requirements-10.txt Intel 4 Working Group: ForCES July 2003 6 Requirements for Separation of IP Control and Forwarding 8 draft-ietf-forces-requirements-10.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), 15 its areas, and its working groups. Note that other groups may 16 also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as ``work in 22 progress.'' 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Conventions used in this document 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 34 this document are to be interpreted as described in [RFC-2119]. 36 1. Abstract 38 This document introduces the ForCES architecture and defines a set 39 of associated terminology. This document also defines a set of 40 architectural, modeling, and protocol requirements to logically 41 separate the control and data forwarding planes of an IP (IPv4, 42 IPv6, etc.) networking device. 44 1. Abstract........................................................1 45 2. Introduction....................................................2 46 3. Definitions.....................................................3 47 4. Architecture....................................................5 48 5. Architectural Requirements......................................6 49 6. FE Model Requirements...........................................8 50 6.1. Types of Logical Functions......................................8 51 6.2. Variations of Logical Functions.................................8 52 6.3. Ordering of Logical Functions...................................8 53 6.4. Flexibility.....................................................9 54 6.5. Minimal Set of Logical Functions................................9 55 7. ForCES Protocol Requirements...................................10 56 8. References.....................................................14 57 8.1. Normative References...........................................14 58 8.2. Informative References.........................................14 59 9. Security Considerations........................................15 60 10. Authors' Addresses & Acknowledgments..........................15 61 11. Editors' Contact Information..................................16 63 2. Introduction 65 An IP network element is composed of numerous logically separate 66 entities that cooperate to provide a given functionality (such as a 67 routing or IP switching) and yet appear as a normal integrated 68 network element to external entities. Two primary types of network 69 element components exist: control-plane components and forwarding- 70 plane components. In general, forwarding-plane components are ASIC, 71 network-processor, or general-purpose processor-based devices that 72 handle all data path operations. Conversely, control-plane 73 components are typically based on general-purpose processors that 74 provide control functionality such as the processing of routing or 75 signaling protocols. A standard set of mechanisms for connecting 76 these components provides increased scalability and allows the 77 control and forwarding planes to evolve independently, thus 78 promoting faster innovation. 80 For the purpose of illustration, let us consider the architecture of 81 a router to illustrate the concept of separate control and 82 forwarding planes. The architecture of a router is composed of two 83 main parts. These components, while inter-related, perform 84 functions that are largely independent of each other. At the bottom 85 is the forwarding path that operates in the data-forwarding plane 86 and is responsible for per-packet processing and forwarding. Above 87 the forwarding plane is the network operating system that is 88 responsible for operations in the control plane. In the case of a 89 router or switch, the network operating system runs routing, 90 signaling and control protocols (e.g., RIP, OSPF and RSVP) and 91 dictates the forwarding behavior by manipulating forwarding tables, 92 per-flow QoS tables and access control lists. Typically, the 93 architecture of these devices combines all of this functionality 94 into a single functional whole with respect to external entities. 96 3. Definitions 98 Addressable Entity (AE) - A physical device that is directly 99 addressable given some interconnect technology. For example, on IP 100 networks, it is a device to which we can communicate using an IP 101 address; and on a switch fabric, it is a device to which we can 102 communicate using a switch fabric port number. 104 Physical Forwarding Element (PFE) - An AE that includes hardware 105 used to provide per-packet processing and handling. This hardware 106 may consist of (but is not limited to) network processors, ASIC's, 107 line cards with multiple chips or stand alone box with general- 108 purpose processors. 110 Physical Control Element (PCE) - An AE that includes hardware used 111 to provide control functionality. This hardware typically includes 112 a general-purpose processor. 114 Forwarding Element (FE) - A logical entity that implements the 115 ForCES protocol. FEs use the underlying hardware to provide per- 116 packet processing and handling as directed/controlled by a CE via 117 the ForCES protocol. FEs may happen to be a single blade(or PFE), a 118 partition of a PFE or multiple PFEs. 120 Control Element (CE) - A logical entity that implements the ForCES 121 protocol and uses it to instruct one or more FEs how to process 122 packets. CEs handle functionality such as the execution of control 123 and signaling protocols. CEs may consist of PCE partitions or whole 124 PCEs. 126 Pre-association Phase - The period of time during which a FE Manager 127 (see below) and a CE Manager (see below) are determining which FE 128 and CE should be part of the same network element. Any partitioning 129 of PFEs and PCEs occurs during this phase. 131 Post-association Phase - The period of time during which a FE does 132 know which CE is to control it and vice versa, including the time 133 during which the CE and FE are establishing communication with one 134 another. 136 ForCES Protocol - While there may be multiple protocols used within 137 the overall ForCES architecture, the term "ForCES protocol" refers 138 only to the ForCES post-association phase protocol (see below). 140 ForCES Post-Association Phase Protocol - The protocol used for post- 141 association phase communication between CEs and FEs. This protocol 142 does not apply to CE-to-CE communication, FE-to-FE communication, or 143 to communication between FE and CE managers. The ForCES protocol is 144 a master-slave protocol in which FEs are slaves and CEs are masters. 145 This protocol includes both the management of the communication 146 channel (e.g., connection establishment, heartbeats) and the control 147 messages themselves. This protocol could be a single protocol or 148 could consist of multiple protocols working together. 150 FE Model - A model that describes the logical processing functions 151 of a FE. 153 FE Manager - A logical entity that operates in the pre-association 154 phase and is responsible for determining to which CE(s) a FE should 155 communicate. This process is called CE discovery and may involve 156 the FE manager learning the capabilities of available CEs. A FE 157 manager may use anything from a static configuration to a pre- 158 association phase protocol (see below) to determine which CE(s) to 159 use, however this is currently out of scope. Being a logical 160 entity, a FE manager might be physically combined with any of the 161 other logical entities mentioned in this section. 163 CE Manager - A logical entity that operates in the pre-association 164 phase and is responsible for determining to which FE(s) a CE should 165 communicate. This process is called FE discovery and may involve 166 the CE manager learning the capabilities of available FEs. A CE 167 manager may use anything from a static configuration to a pre- 168 association phase protocol (see below) to determine which FE to use, 169 however this is currently out of scope. Being a logical entity, a 170 CE manager might be physically combined with any of the other 171 logical entities mentioned in this section. 173 Pre-association Phase Protocol - A protocol between FE managers and 174 CE managers that is used to determine which CEs or FEs to use. A 175 pre-association phase protocol may include a CE and/or FE capability 176 discovery mechanism. Note that this capability discovery process is 177 wholly separate from (and does not replace) that used within the 178 ForCES protocol (see Section 7, requirement #1). However, the two 179 capability discovery mechanisms may utilize the same FE model (see 180 Section 6). Pre-association phase protocols are not discussed 181 further in this document. 183 ForCES Network Element (NE) - An entity composed of one or more CEs 184 and one or more FEs. To entities outside a NE, the NE represents a 185 single point of management. Similarly, a NE usually hides its 186 internal organization from external entities. 188 ForCES Protocol Element - A FE or CE. 190 High Touch Capability - This term will be used to apply to the 191 capabilities found in some forwarders to take action on the contents 192 or headers of a packet based on content other than what is found in 193 the IP header. Examples of these capabilities include NAT-PT, 194 firewall, and L7 content recognition. 196 4. Architecture 198 The chief components of a NE architecture are the CE, the FE, and 199 the interconnect protocol. The CE is responsible for operations 200 such as signaling and control protocol processing and the 201 implementation of management protocols. Based on the information 202 acquired through control processing, the CE(s) dictates the packet- 203 forwarding behavior of the FE(s) via the interconnect protocol. For 204 example, the CE might control a FE by manipulating its forwarding 205 tables, the state of its interfaces, or by adding or removing a NAT 206 binding. 208 The FE operates in the forwarding plane and is responsible for per- 209 packet processing and handling. By allowing the control and 210 forwarding planes to evolve independently, different types of FEs 211 can be developed - some general purpose and others more specialized. 212 Some functions that FEs could perform include layer 3 forwarding, 213 metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), 214 decapsulation, encryption, accounting, etc. Nearly all combinations 215 of these functions may be present in practical FEs. 217 Below is a diagram illustrating an example NE composed of a CE and 218 two FEs. Both FEs and CE require minimal configuration as part of 219 the pre-configuration process and this may be done by FE Manager and 220 CE Manager respectively. Apart from this, there is no defined role 221 for FE Manager and CE Manager. These components are out of scope of 222 the architecture and requirements for the ForCES protocol, which 223 only involves CEs and FEs. 225 -------------------------------- 226 | NE | 227 | ------------- | 228 | | CE | | 229 | ------------- | 230 | / \ | 231 | / \ | 232 | / \ | 233 | / \ | 234 | ----------- ----------- | 235 | | FE | | FE | | 236 | ----------- ----------- | 237 | | | | | | | | | | 238 | | | | | | | | | | 239 | | | | | | | | | | 240 | | | | | | | | | | 241 -------------------------------- 242 | | | | | | | | 243 | | | | | | | | 245 5. Architectural Requirements 247 The following are the architectural requirements: 249 1) CEs and FEs MUST be able to connect by a variety of interconnect 250 technologies. Examples of interconnect technologies used in current 251 architectures include Ethernet,bus backplanes, and ATM (cell) 252 fabrics. FEs MAY be connected to each other via a different 253 technology than that used for CE/FE communication. 255 2) FEs MUST support a minimal set of capabilities necessary for 256 establishing network connectivity (e.g., interface discovery, port 257 up/down functions). Beyond this minimal set, the ForCES 258 architecture MUST NOT restrict the types or numbers of capabilities 259 that FEs may contain. 261 3) Packets MUST be able to arrive at the NE by one FE and leave the 262 NE via a different FE. 264 4) A NE MUST support the appearance of a single functional device. 265 For example, in a router, the TTL of the packet should be 266 decremented only once as it traverses the NE regardless of how many 267 FEs through which it passes. However, external entities (e.g., FE 268 managers and CE managers) MAY have direct access to individual 269 ForCES protocol elements for providing information to transition 270 them from the pre-association to post-association phase. 272 5) The architecture MUST provide a way to prevent unauthorized 273 ForCES protocol elements from joining a NE.(For more protocol 274 details, refer to section 7 requirement# 2) 276 6) A FE MUST be able to asynchronously inform the CE of a failure or 277 increase/decrease in available resources or capabilities on the FE. 278 Thus the FE MUST support error monitoring and reporting. (Since 279 there is not a strict 1-to-1 mapping between FEs and PFEs, it is 280 possible for the relationship between a FE and its physical 281 resources to change over time). For example, the number of physical 282 ports or the amount of memory allocated to a FE may vary over time. 283 The CE needs to be informed of such changes so that it can control 284 the FE in an accurate way. 286 7) The architecture MUST support mechanisms for CE redundancy or CE 287 failover. This includes the ability for CEs and FEs to determine 288 when there is a loss of association between them, ability to restore 289 association and efficient state (re)synchronization mechanisms. This 290 also includes the ability to preset the actions an FE will take in 291 reaction to loss of association to its CE e.g., whether the FE will 292 continue to forward packets or whether it will halt operations. 294 8) FEs MUST be able to redirect control packets (such as RIP, OSPF 295 messages) addressed to their interfaces to the CE. They MUST also 296 redirect other relevant packets (e.g., such as those with Router 297 Alert Option set) to their CE. The CEs MUST be able to configure the 298 packet redirection information/filters on the FEs. The CEs MUST also 299 be able to create packets and have its FEs deliver them. 301 9) Any proposed ForCES architectures MUST explain how that 302 architecture supports all of the router functions as defined in 303 [RFC1812]. IPv4 Forwarding functions such IP header validation, 304 performing longest prefix match algorithm, TTL decrement, Checksum 305 calculation, generation of ICMP error messages, etc defined in RFC 306 1812 should be explained. 308 10) In a ForCES NE, the FEs MUST be able to provide their topology 309 information (topology by which the FEs in the NE are connected) to 310 the CE(s). 312 11) The ForCES NE architecture MUST be capable of supporting (i.e., 313 must scale to) at least hundreds of FEs and tens of thousands of 314 ports. 316 12) The ForCES architecture MUST allow FEs AND CEs to join and leave 317 NEs dynamically. 319 13) The ForCES NE architecture MUST support multiple CEs and FEs. 320 However, coordination between CEs is out of scope of ForCES. 322 14) For pre-association phase setup, monitoring, configuration 323 issues, it MAY be useful to use standard management mechanisms for 324 CEs and FEs. The ForCES architecture and requirements do not 325 preclude this. In general, for post-association phase, most 326 management tasks SHOULD be done through interaction with the CE. In 327 certain conditions (e.g. CE/FE disconnection), it may be useful to 328 allow management tools (e.g. SNMP) to be used to diagnose and repair 329 problems. The following guidelines MUST be observed: 330 1. The ability for a management tool (e.g. SNMP) to be used to read 331 (but not change) the state of FE SHOULD NOT be precluded. 332 2. It MUST NOT be possible for management tools (e.g. SNMP, etc) to 333 change the state of a FE in a manner that affects overall NE 334 behavior without the CE being notified. 336 6. FE Model Requirements 338 The variety of FE functionality that the ForCES architecture allows 339 poses a potential problem for CEs. In order for a CE to effectively 340 control a FE, the CE must understand how the FE processes packets. 341 We therefore REQUIRE that a FE model be created that can express the 342 logical packet processing capabilities of a FE. This model will be 343 used in the ForCES protocol to describe FE capabilities (see Section 344 7, requirement #1). The FE model MUST define both a capability model 345 and a state model, which expresses the current configuration of the 346 device. The FE model MUST also support multiple FEs in the NE 347 architecture. 349 6.1. Types of Logical Functions 351 The FE model MUST express what logical functions can be applied to 352 packets as they pass through a FE. 353 Logical functions are the packet processing functions that are 354 applied to the packets as they are forwarded through a FE. Examples 355 of logical functions are layer 3 forwarding, firewall, NAT, shaping. 356 Section 6.5 defines the minimal set of logical functions that the FE 357 Model MUST support. 359 6.2. Variations of Logical Functions 360 The FE model MUST be capable of supporting/allowing variations in 361 the way logical functions are implemented on a FE. For example, on a 362 certain FE the forwarding logical function might have information 363 about both the next hop IP address and the next hop MAC address, 364 while on another FE these might be implemented as separate logical 365 functions. Another example would be NAT functionality that can have 366 several flavors such as Traditional/Outbound NAT, Bi-directional 367 NAT, Twice NAT, Multihomed NAT [RFC2663]. The model must be flexible 368 enough to allow such variations in functions. 370 6.3. Ordering of Logical Functions 371 The model MUST be capable of describing the order in which these 372 logical functions are applied in a FE. The ordering of logical 373 functions is important in many cases. For example, a NAT function 374 may change a packet's source or destination IP address. Any number 375 of other logical functions (e.g., layer 3 forwarding, ingress/egress 376 firewall, shaping, accounting) may make use of the source or 377 destination IP address when making decisions. The CE needs to know 378 whether to configure these logical functions with the pre-NAT or 379 post-NAT IP address. Furthermore, the model MUST be capable of 380 expressing multiple instances of the same logical function in a FE's 381 processing path. Using NAT again as an example, one NAT function is 382 typically performed before the forwarding decision (packets arriving 383 externally have their public addresses replaced with private 384 addresses) and one NAT function is performed after the forwarding 385 decision (for packets exiting the domain, their private addresses 386 are replaced by public ones). 388 6.4. Flexibility 390 Finally, the FE model SHOULD provide a flexible infrastructure in 391 which new logical functions and new classification, action, and 392 parameterization data can be easily added. In addition, the FE 393 model MUST be capable of describing the types of statistics gathered 394 by each logical function. 396 6.5. Minimal Set of Logical Functions 398 The rest of this section defines a minimal set of logical functions 399 that any FE model MUST support. This minimal set DOES NOT imply 400 that all FEs must provide this functionality. Instead, these 401 requirements only specify that the model must be capable of 402 expressing the capabilities that FEs may choose to provide. 404 1)Port Functions 405 The FE model MUST be capable of expressing the number of ports on 406 the device, the static attributes of each port (e.g., port type, 407 link speed), and the configurable attributes of each port (e.g., IP 408 address, administrative status). 410 2)Forwarding Functions 411 The FE model MUST be capable of expressing the data that can be used 412 by the forwarding function to make a forwarding decision. Support 413 for IPv4 and IPv6 unicast and multicast forwarding functions MUST be 414 provided by the model. 416 3)QoS Functions 417 The FE model MUST allow a FE to express its QoS capabilities in 418 terms of, e.g., metering, policing, shaping, and queuing functions. 419 The FE model MUST be capable of expressing the use of these 420 functions to provide IntServ or DiffServ functionality as described 421 in [RFC2211], [RFC2212], [RFC2215], [RFC2475], and [RFC3290]. 423 4)Generic Filtering Functions 424 The FE model MUST be capable of expressing complex sets of filtering 425 functions. The model MUST be able to express the existence of these 426 functions at arbitrary points in the sequence of a FE's packet 427 processing functions. The FE model MUST be capable of expressing a 428 wide range of classification abilities from single fields (e.g., 429 destination address) to arbitrary n-tuples. Similarly, the FE model 430 MUST be capable of expressing what actions these filtering functions 431 can perform on packets that the classifier matches. 433 5)Vendor-Specific Functions 434 The FE model SHOULD be extensible so that new, currently unknown FE 435 functionality can be expressed. The FE Model SHOULD NOT be extended 436 to express standard/common functions in a proprietary manner. This 437 would NOT be ForCES compliant. 439 6)High-Touch Functions 440 The FE model MUST be capable of expressing the encapsulation and 441 tunneling capabilities of a FE. The FE model MUST support functions 442 that mark the class of service that a packet should receive (i.e. 443 IPv4 header TOS octet or the IPv6 Traffic Class octet). The FE 444 model MAY support other high touch functions (e.g., NAT, ALG). 446 7)Security Functions 447 The FE model MUST be capable of expressing the types of encryption 448 that may be applied to packets in the forwarding path. 450 8)Off-loaded Functions 451 Per-packet processing can leave state in the FE, so that logical 452 functions executed during packet processing can perform in a 453 consistent manner (for instance, each packet may update the state of 454 the token bucket occupancy of a give policer). In addition, the FE 455 Model MUST allow logical functions to execute asynchronously from 456 packet processing, according to a certain finite-state machine, in 457 order to perform functions that are, for instance, off-loaded from 458 the CE to the FE. The FE model MUST be capable of expressing these 459 asynchronous functions. Examples of such functions include the 460 finite-state machine execution required by TCP termination or OSPF 461 Hello processing, triggered not only by packet events, but by timer 462 events as well. This Does NOT mean off-loading of any piece of code 463 to an FE, just that the FE Model should be able to express existing 464 Off-loaded functions on an FE. 466 9)IPFLOW/PSAMP Functions 467 Several applications such as, Usage-based Accounting, Traffic 468 engineering, require flow-based IP traffic measurements from Network 469 Elements. [IPFLOW] defines architecture for IP traffic flow 470 monitoring, measuring and exporting. The FE model SHOULD be able to 471 express metering functions and flow accounting needed for exporting 472 IP traffic flow information. 473 Similarly to support measurement-based applications, [PSAMP] 474 describes a framework to define a standard set of capabilities for 475 network elements to sample subsets of packets by statistical and 476 other methods. The FE model SHOULD be able to express statistical 477 packet filtering functions and packet information needed for 478 supporting packet sampling applications. 480 7. ForCES Protocol Requirements 481 This section specifies some of the requirements that the ForCES 482 protocol MUST meet. 484 1)Configuration of Modeled Elements 485 The ForCES protocol MUST allow the CEs to determine the capabilities 486 of each FE. These capabilities SHALL be expressed using the FE 487 model whose requirements are defined in Section 6. Furthermore, the 488 protocol MUST provide a means for the CEs to control all the FE 489 capabilities that are discovered through the FE model. The protocol 490 MUST be able to add/remove classification/action entries, set/delete 491 parameters, query statistics, and register for and receive events. 493 2)Support for Secure Communication 494 a) FE configuration will contain information critical to the 495 functioning of a network (e.g. IP Forwarding Tables). As such, it 496 MUST be possible to ensure the integrity of all ForCES protocol 497 messages and protect against man-in-the-middle attacks. 498 b) FE configuration information may also contain information derived 499 from business relationships (e.g. service level agreements). 500 Because of the confidential nature of the information, it MUST be 501 possible to secure (make private) all ForCES protocol messages. 502 c) In order to ensure that authorized CEs and FEs are participating 503 in a NE and defend against CE or FE impersonation attacks, the 504 ForCES architecture MUST select a means of authentication for CEs 505 and FEs. 506 d) In some deployments ForCES is expected to be deployed between CEs 507 and FEs connected to each other inside a box over a backplane, 508 where physical security of the box ensures that man-in-the-middle, 509 snooping, and impersonation attacks are not possible. In such 510 scenarios the ForCES architecture MAY rely on the physical 511 security of the box to defend against these attacks and protocol 512 mechanisms May be turned off. 513 e) In the case when CEs and FEs are connected over a network, 514 security mechanisms MUST be specified or selected that protect the 515 ForCES protocol against such attacks. Any security solution used 516 for ForCES MUST specify how it deals with such attacks. 518 3)Scalability 519 The ForCES protocol MUST be capable of supporting (i.e., must scale 520 to) at least hundreds of FEs and tens of thousands of ports. For 521 example, the ForCES protocol field sizes corresponding to FE or port 522 numbers SHALL be large enough to support the minimum required 523 numbers. This requirement does not relate to the performance of a 524 NE as the number of FEs or ports in the NE grows. 526 4)Multihop 527 When the CEs and FEs are separated beyond a single hop, the ForCES 528 protocol will make use of an existing RFC2914 compliant L4 protocol 529 with adequate reliability, security and congestion control (e.g. 530 TCP, SCTP) for transport purposes. 532 5)Message Priority 533 The ForCES protocol MUST provide a means to express the protocol 534 message priorities. 536 6)Reliability 537 a) The ForCES protocol will be used to transport information that 538 requires varying levels of reliability. By strict or robust 539 reliability in this requirement we mean, no losses, no corruption, 540 no re-ordering of information being transported and delivery in a 541 timely fashion. 542 b) Some information or payloads, such as redirected packets or packet 543 sampling, may not require robust reliability (can tolerate some 544 degree of losses). For information of this sort, ForCES MUST NOT 545 be restricted to strict reliability. 546 c) Payloads such as configuration information, e.g. ACLs, FIB 547 entries, or FE capability information (described in section 7, 548 (1)) are mission critical and must be delivered in a robust 549 reliable fashion. Thus, for information of this sort, ForCES MUST 550 either provide built-in protocol mechanisms or use a reliable 551 transport protocol for achieving robust/strict reliability. 552 d) Some information or payloads, such as heartbeat packets that may 553 be used to detect loss of association between CE and FEs (see 554 section 7, (8)), may prefer timeliness over reliable delivery. For 555 information of this sort, ForCES MUST NOT be restricted to strict 556 reliability. 557 e) When ForCES is carried over multi-hop IP networks, it is a 558 requirement that ForCES MUST use a [RFC2914]-compliant transport 559 protocol. 560 f) In cases where ForCES is not running over an IP network such as an 561 Ethernet or cell fabric between CE and FE, then reliability still 562 MUST be provided when carrying critical information of the types 563 specified in (c) above, either by the underlying link/network/ 564 transport layers or by built-in protocol mechanisms. 566 7)Interconnect Independence 567 The ForCES protocol MUST support a variety of interconnect 568 technologies. (refer to section 5, requirement# 1) 570 8)CE redundancy or CE failover 571 The ForCES protocol MUST support mechanisms for CE redundancy or CE 572 failover. This includes the ability for CEs and FEs to determine 573 when there is a loss of association between them, ability to restore 574 association and efficient state (re)synchronization mechanisms. This 575 also includes the ability to preset the actions an FE will take in 576 reaction to loss of association to its CE e.g., whether the FE will 577 continue to forward packets or whether it will halt operations. 578 (refer to section 5, requirement# 7) 580 9)Packet Redirection/Mirroring 581 a) The ForCES protocol MUST define a way to redirect packets from the 582 FE to the CE and vice-versa. Packet redirection terminates any 583 further processing of the redirected packet at the FE. 584 b) The ForCES protocol MUST define a way to mirror packets from the 585 FE to the CE. Mirroring allows the packet duplicated by the FE at 586 the mirroring point to be sent to the CE while the original packet 587 continues to be processed by the FE. 588 Examples of packets that may be redirected or mirrored include 589 control packets (such as RIP, OSPF messages) addressed to the 590 interfaces or any other relevant packets (such as those with Router 591 Alert Option set). The ForCES protocol MUST also define a way for the 592 CE to configure the behavior of a) and b) (above), to specify which 593 packets are affected by each. 595 10)Topology Exchange 596 The ForCES protocol MUST allow the FEs to provide their topology 597 information (topology by which the FEs in the NE are connected) to 598 the CE(s). (refer to section 5, requirement# 10) 600 11)Dynamic Association 601 The ForCES protocol MUST allow CEs and FEs to join and leave a NE 602 dynamically. (refer to section 5, requirement# 12) 604 12)Command Bundling 605 The ForCES protocol MUST be able to group an ordered set of commands 606 to a FE. Each such group of commands SHOULD be sent to the FE in as 607 few messages as possible. Furthermore, the protocol MUST support the 608 ability to specify if a command group MUST have all-or-nothing 609 semantics. 611 13)Asynchronous Event Notification 612 The ForCES protocol MUST be able to asynchronously notify the CE of 613 events on the FE such as failures or change in available resources 614 or capabilities. (refer to section 5, requirement# 6) 616 14)Query Statistics 617 The ForCES protocol MUST provide a means for the CE to be able to 618 query statistics (monitor performance) from the FE. 620 15) Protection against Denial of Service Attacks (based on CPU 621 overload or queue overflow) 622 Systems utilizing the ForCES protocol can be attacked using denial 623 of service attacks based on CPU overload or queue overflow. 624 The ForCES protocol could be exploited by such attacks to cause the 625 CE to become unable to control the FE or appropriately communicate 626 with other routers and systems. The ForCES protocol MUST therefore 627 provide mechanisms for controlling FE capabilities that can be used 628 to protect against such attacks. FE capabilities that MUST be 629 manipulated via ForCES include the ability to install classifiers 630 and filters to detect and drop attack packets, as well as to be able 631 to install rate limiters that limit the rate of packets which appear 632 to be valid but may be part of an attack (e.g. bogus BGP packets). 634 8. References 635 8.1.Normative References 637 [RFC3290] Y. Bernet, et. al., "An Informal Management Model for 638 DiffServ Routers", , May 2002. 640 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", 641 RFC1812, June 1995. 643 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 644 Network Element Service", RFC2211, September 1997. 646 [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of 647 Guaranteed Quality of Service", RFC2212, September 1997. 649 [RFC2215] S. Shenker, J. Wroclawski, "General Characterization 650 Parameters for Integrated Service Network Elements", RFC2215, 651 September 1997. 653 [RFC2475] S. Blake, et. Al., "An Architecture for Differentiated 654 Service", RFC2475, December 1998. 656 [RFC2914] S. Floyd, "Congestion Control Principles", RFC2914, 657 September 2000. 659 [RFC2663] P. Srisuresh & M. Holdrege, "IP Network Address 660 Translator (NAT) Terminology and Considerations", RFC2663, August 661 1999. 663 8.2.Informative References 665 [REQ-PART] T. Anderson, J. Buerkle, "Requirements for the Dynamic 666 Partitioning of Switching Elements", work in progress, July 2002, 667 . 669 [IPFLOW] Quittek, et. Al., "Requirements for IP Flow Information 670 Export", work in progress, February 2003, . 673 [PSAMP] Duffield, et. Al., "A Framework for Passive Packet 674 Measurement ", work in progress, March 2003, . 677 9. Security Considerations 679 See architecture requirement #5 and protocol requirement #2. 681 10. Authors' Addresses & Acknowledgments 683 This document was written by the ForCES Requirements design team: 685 Todd A. Anderson (Editor) 687 Ed Bowen 688 IBM Zurich Research Laboratory 689 Saumerstrasse 4 690 CH-8803 Rueschlikon Switzerland 691 Phone: +41 1 724 83 68 692 Email: edbowen@us.ibm.com 694 Ram Dantu 695 Department of Computer Science 696 University of North Texas, 697 Denton, Texas, 76203 698 Email: rdantu@unt.edu 699 Phone: 940 565 2822 701 Avri Doria 702 Institute for System Technology 703 Lulea University of Technology 704 SE-971 87, Lulea, Sweden 705 Phone: +46 (0)920 49 3030 706 Email: avri@sm.luth.se 708 Ram Gopal 709 Nokia Research Center 710 5, Wayside Road, 711 Burlington, MA 01803 712 Phone: 1-781-993-3685 713 Email: ram.gopal@nokia.com 715 Jamal Hadi Salim 716 Znyx Networks 717 Ottawa, Ontario 718 Canada 719 Email: hadi@znyx.com 720 Hormuzd Khosravi (Editor) 722 Muneyb Minhazuddin 723 Avaya Inc. 724 123, Epping road, 725 North Ryde, NSW 2113, Australia 726 Phone: +61 2 9352 8620 727 email: muneyb@avaya.com 729 Margaret Wasserman 730 Wind River 731 10 Tara Blvd., Suite 330 732 Nashua, NH 03062 733 Phone: +1 603 897 2067 734 Email: mrw@windriver.com 736 The authors would like to thank Vip Sharma and Lily Yang for their 737 valuable contributions. 739 11. Editors' Contact Information 741 Hormuzd Khosravi 742 Intel 743 2111 NE 25th Avenue 744 Hillsboro, OR 97124 USA 745 Phone: +1 503 264 0334 746 Email: hormuzd.m.khosravi@intel.com 748 Todd A. Anderson 749 Intel 750 2111 NE 25th Avenue 751 Hillsboro, OR 97124 USA 752 Phone: +1 503 712 1760 753 Email: todd.a.anderson@intel.com