idnits 2.17.1 draft-ietf-forces-requirements-06.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 == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 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.) 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 2002) is 7948 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 584, 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 Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft H. Khosravi, 2 Expiration: December 2002 T. Anderson (Editors) 3 File: draft-ietf-forces-requirements-06.txt Intel 4 Working Group: ForCES July 2002 6 Requirements for Separation of IP Control and Forwarding 8 draft-ietf-forces-requirements-06.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 2. Definitions 46 Addressable Entity (AE) - A physical device that is directly 47 addressable given some interconnect technology. For example, on 48 Ethernet, an AE is a device to which we can communicate using an 49 Ethernet MAC address; on IP networks, it is a device to which we can 50 communicate using an IP address; and on a switch fabric, it is a 51 device to which we can communicate using a switch fabric port 52 number. 54 Physical Forwarding Element (PFE) - An AE that includes hardware 55 used to provide per-packet processing and handling. This hardware 56 may consist of (but is not limited to) network processors, ASIC's, 57 line cards with multiple chips or stand alone box with general- 58 purpose processors. 60 PFE Partition - A logical partition of a PFE consisting of some 61 subset of each of the resources (e.g., ports, memory, forwarding 62 table entries) available on the PFE. This concept is analogous to 63 that of the resources assigned to a virtual router [REQ-PART]. 65 Physical Control Element (PCE) - An AE that includes hardware used 66 to provide control functionality. This hardware typically includes 67 a general-purpose processor. 69 PCE Partition - A logical partition of a PCE consisting of some 70 subset of each of the resources available on the PCE. 72 Forwarding Element (FE) - A logical entity that implements the 73 ForCES protocol. FEs use the underlying hardware to provide per- 74 packet processing and handling as directed by a CE via the ForCES 75 protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs. 77 Proxy FE - A name for a type of FE that cannot directly modify its 78 underlying hardware but instead manipulates that hardware using some 79 intermediate form of communication (e.g., a non-ForCES protocol or 80 DMA). A proxy FE will typically be used in the case where a PFE 81 cannot implement the ForCES protocol directly (e.g., due to the lack 82 of a general purpose CPU). 84 Control Element (CE) - A logical entity that implements the ForCES 85 protocol and uses it to instruct one or more FEs how to process 86 packets. CEs handle functionality such as the execution of control 87 and signaling protocols. CEs may consist of PCE partitions or whole 88 PCEs. 90 Pre-association Phase - The period of time during which a FE Manager 91 (see below) and a CE Manager (see below) are determining which FE 92 and CE should be part of the same network element. Any partitioning 93 of PFEs and PCEs occurs during this phase. 95 Post-association Phase - The period of time during which a FE does 96 know which CE is to control it and vice versa, including the time 97 during which the CE and FE are establishing communication with one 98 another. 100 ForCES Protocol - While there may be multiple protocols used within 101 the overall ForCES architecture, the term "ForCES protocol" refers 102 only to the ForCES post-association phase protocol (see below). 104 ForCES Post-Association Phase Protocol - The protocol used for post- 105 association phase communication between CEs and FEs. This protocol 106 does not apply to CE-to-CE communication, FE-to-FE communication, or 107 to communication between FE and CE managers. The ForCES protocol is 108 a master-slave protocol in which FEs are slaves and CEs are masters. 109 This protocol includes both the management of the communication 110 channel (e.g., connection establishment, heartbeats) and the control 111 messages themselves. This protocol could be a single protocol or 112 could consist of multiple protocols working together. 114 FE Model - A model that describes the logical processing functions 115 of a FE. 117 FE Manager - A logical entity that operates in the pre-association 118 phase and is responsible for determining to which CE(s) a FE should 119 communicate. This process is called CE discovery and may involve 120 the FE manager learning the capabilities of available CEs. A FE 121 manager may use anything from a static configuration to a pre- 122 association phase protocol (see below) to determine which CE(s) to 123 use. Being a logical entity, a FE manager might be physically 124 combined with any of the other logical entities mentioned in this 125 section. 127 CE Manager - A logical entity that operates in the pre-association 128 phase and is responsible for determining to which FE(s) a CE should 129 communicate. This process is called FE discovery and may involve 130 the CE manager learning the capabilities of available FEs. A CE 131 manager may use anything from a static configuration to a pre- 132 association phase protocol (see below) to determine which FE to use. 133 Being a logical entity, a CE manager might be physically combined 134 with any of the other logical entities mentioned in this section. 136 Pre-association Phase Protocol - A protocol between FE managers and 137 CE managers that is used to determine which CEs or FEs to use. A 138 pre-association phase protocol may include a CE and/or FE capability 139 discovery mechanism. Note that this capability discovery process is 140 wholly separate from (and does not replace) that used within the 141 ForCES protocol (see Section 7, requirement #1). However, the two 142 capability discovery mechanisms may utilize the same FE model (see 143 Section 6). Pre-association phase protocols are not discussed 144 further in this document. 146 ForCES Network Element (NE) - An entity composed of one or more CEs 147 and one or more FEs. To entities outside a NE, the NE represents a 148 single point of management. Similarly, a NE usually hides its 149 internal organization from external entities. 151 ForCES Protocol Element - A FE or CE. 153 High Touch Capability - This term will be used to apply to the 154 capabilities found in some forwarders to take action on the contents 155 or headers of a packet based on content other than what is found in 156 the IP header. Examples of these capabilities include NAT-PT, 157 firewall, and L7 content recognition. 159 3. Introduction 161 An IP network element is composed of numerous logically separate 162 entities that cooperate to provide a given functionality (such as a 163 routing or IP switching) and yet appear as a normal integrated 164 network element to external entities. Two primary types of network 165 element components exist: control-plane components and forwarding- 166 plane components. In general, forwarding-plane components are ASIC, 167 network-processor, or general-purpose processor-based devices that 168 handle all data path operations. Conversely, control-plane 169 components are typically based on general-purpose processors that 170 provide control functionality such as the processing of routing or 171 signaling protocols. A standard set of mechanisms for connecting 172 these components provides increased scalability and allows the 173 control and forwarding planes to evolve independently, thus 174 promoting faster innovation. 176 For the purpose of illustration, let us consider the architecture of 177 a router to illustrate the concept of separate control and 178 forwarding planes. The architecture of a router is composed of two 179 main parts. These components, while inter-related, perform 180 functions that are largely independent of each other. At the bottom 181 is the forwarding path that operates in the data-forwarding plane 182 and is responsible for per-packet processing and forwarding. Above 183 the forwarding plane is the network operating system that is 184 responsible for operations in the control plane. In the case of a 185 router or switch, the network operating system runs routing, 186 signaling and control protocols (e.g., RIP, OSPF and RSVP) and 187 dictates the forwarding behavior by manipulating forwarding tables, 188 per-flow QoS tables and access control lists. Typically, the 189 architecture of these devices combines all of this functionality 190 into a single functional whole with respect to external entities. 192 4. Architecture 194 The chief components of a NE architecture are the CE, the FE, and 195 the interconnect protocol. The CE is responsible for operations 196 such as signaling and control protocol processing and the 197 implementation of management protocols. Based on the information 198 acquired through control processing, the CE(s) dictates the packet- 199 forwarding behavior of the FE(s) via the interconnect protocol. For 200 example, the CE might control a FE by manipulating its forwarding 201 tables, the state of its interfaces, or by adding or removing a NAT 202 binding. 204 The FE operates in the forwarding plane and is responsible for per- 205 packet processing and handling. By allowing the control and 206 forwarding planes to evolve independently, different types of FEs 207 can be developed - some general purpose and others more specialized. 208 Some functions that FEs could perform include layer 3 forwarding, 209 metering, shaping, firewall, NAT, encapsulation (e.g., tunneling), 210 decapsulation, encryption, accounting, etc. Nearly all combinations 211 of these functions may be present in practical FEs. 213 Below is a diagram illustrating an example NE composed of a CE and 214 two FEs. Both FEs and CE require minimal configuration as part of 215 the pre-configuration process and this may be done by FE Manager and 216 CE Manager respectively. Apart from this, there is no defined role 217 for FE Manager and CE Manager. The Proxy FE has also been defined 218 for clarification purpose. These components are out of scope of the 219 architecture and requirements for ForCES protocol, which only 220 involves CEs and FEs. 222 -------------------------------- 223 | NE | 224 | ------------- | 225 | | CE | | 226 | ------------- | 227 | / \ | 228 | / \ | 229 | / \ | 230 | / \ | 231 | ----------- ----------- | 232 | | FE | | FE | | 233 | ----------- ----------- | 234 | | | | | | | | | | 235 | | | | | | | | | | 236 | | | | | | | | | | 237 | | | | | | | | | | 238 -------------------------------- 239 | | | | | | | | 240 | | | | | | | | 242 5. Architectural Requirements 244 The following are the architectural requirements: 246 1) CEs and FEs MUST be able to connect by a variety of interconnect 247 technologies. Examples of interconnect technologies used in current 248 architectures include Ethernet,bus backplanes, and ATM (cell) 249 fabrics. FEs MAY be connected to each other via a different 250 technology than that used for CE/FE communication. 252 2) FEs MUST support a minimal set of capabilities necessary for 253 establishing network connectivity (e.g., interface discovery, port 254 up/down functions). Beyond this minimal set, the ForCES 255 architecture MUST NOT restrict the types or numbers of capabilities 256 that FEs may contain. 258 3) Packets MUST be able to arrive at the NE by one FE and leave the 259 NE via a different FE. 261 4) A NE MUST support the appearance of a single functional device. 262 For example, in a router, the TTL of the packet should be 263 decremented only once as it traverses the NE regardless of how many 264 FEs through which it passes. However, external entities (e.g., FE 265 managers and CE managers) MAY have direct access to individual 266 ForCES protocol elements for providing information to transition 267 them from the pre-association to post-association phase. 269 5) The architecture MUST provide a way to prevent unauthorized 270 ForCES protocol elements from joining a NE.(For more protocol 271 details, refer to section 7 requirement# 2) 273 6) A FE MUST be able to asynchronously inform the CE of a failure or 274 increase/decrease in available resources or capabilities on the FE. 275 Thus the FE MUST support error monitoring and reporting. (Since 276 there is not a strict 1-to-1 mapping between FEs and PFEs, it is 277 possible for the relationship between a FE and its physical 278 resources to change over time). For example, the number of physical 279 ports or the amount of memory allocated to a FE may vary over time. 280 The CE needs to be informed of such changes so that it can control 281 the FE in an accurate way. 283 7) The architecture MUST support mechanisms for CE redundancy or CE 284 failover. This includes the ability for CEs and FEs to determine 285 when there is a loss of association between them, ability to restore 286 association and efficient state (re)synchronization mechanisms. This 287 also includes the ability to preset the actions an FE will take in 288 reaction to loss of association to its CE e.g., whether the FE will 289 continue to forward packets or whether it will halt operations. 291 8) FEs MUST be able to redirect control packets (such as RIP, OSPF 292 messages) addressed to their interfaces to the CE. They MUST also 293 redirect other relevant packets (e.g., such as those with Router 294 Alert Option set) to their CE. The CEs MUST be able to configure the 295 packet redirection information/filters on the FEs. The CEs MUST also 296 be able to create packets and have its FEs deliver them. 298 9) Any proposed ForCES architectures MUST explain how that 299 architecture supports all of the router functions as defined in 300 [RFC1812]. 302 10) In a ForCES NE, the FEs MUST be able to provide their topology 303 information (topology by which the FEs in the NE are connected) to 304 the CE(s). 306 11) The ForCES NE architecture MUST be capable of supporting (i.e., 307 must scale to) at least hundreds of FEs and tens of thousands of 308 ports. 310 12) The ForCES architecture MUST allow FEs AND CEs to join and leave 311 NEs dynamically. 313 13) The ForCES NE architecture MUST support multiple CEs and FEs. 315 14) For pre-association phase setup, monitoring, configuration 316 issues, it MAY be useful to use standard management mechanisms for 317 CEs and FEs. The ForCES architecture and requirements do not 318 preclude this. In general, for post-association phase, most 319 management tasks SHOULD be done through interaction with the CE. In 320 certain conditions (e.g. CE/FE disconnection), it may be useful to 321 allow management tools (e.g. SNMP) to be used to diagnose and repair 322 problems. The following guidelines MUST be observed: 323 1. The ability for a management tool (e.g. SNMP) to be used to read 324 (but not change) the state of FE SHOULD NOT be precluded. 325 2. It MUST NOT be possible for management tools (e.g. SNMP, etc) to 326 change the state of a FE in a manner that affects overall NE 327 behavior without the CE being notified. 329 6. FE Model Requirements 331 The variety of FE functionality that the ForCES architecture allows 332 poses a potential problem for CEs. In order for a CE to effectively 333 control a FE, the CE must understand how the FE processes packets. 334 We therefore REQUIRE that a FE model be created that can express the 335 logical packet processing capabilities of a FE. This model will be 336 used in the ForCES protocol to describe FE capabilities (see Section 337 7, requirement #1). The FE model MUST define both a capability model 338 and a state model, which expresses the current configuration of the 339 device. The FE model MUST also support multiple FEs in the NE 340 architecture. 342 6.1. Types of Logical Functions 344 The FE model MUST express what logical functions can be applied to 345 packets as they pass through a FE. 346 Logical functions are the packet processing functions that are 347 applied to the packets as they are forwarded through a FE. Examples 348 of logical functions are layer 3 forwarding, firewall, NAT, shaping. 349 Section 6.5 defines the minimal set of logical functions that the FE 350 Model MUST support. 352 6.2. Variations of Logical Functions 353 The FE model MUST be capable of supporting/allowing variations in 354 the way logical functions are implemented on a FE. For example, on a 355 certain FE the forwarding logical function might have information 356 about both the next hop IP address and the next hop MAC address, 357 while on another FE these might be implemented as separate logical 358 functions. Another example would be NAT functionality that can have 359 several flavors such as Traditional/Outbound NAT, Bi-directional 360 NAT, Twice NAT, Multihomed NAT [RFC2663]. The model must be flexible 361 enough to allow such variations in functions. 363 6.3. Ordering of Logical Functions 364 The model MUST be capable of describing the order in which these 365 logical functions are applied in a FE. The ordering of logical 366 functions is important in many cases. For example, a NAT function 367 may change a packet's source or destination IP address. Any number 368 of other logical functions (e.g., layer 3 forwarding, ingress/egress 369 firewall, shaping, accounting) may make use of the source or 370 destination IP address when making decisions. The CE needs to know 371 whether to configure these logical functions with the pre-NAT or 372 post-NAT IP address. Furthermore, the model MUST be capable of 373 expressing multiple instances of the same logical function in a FE's 374 processing path. Using NAT again as an example, one NAT function is 375 typically performed before the forwarding decision (packets arriving 376 externally have their public addresses replaced with private 377 addresses) and one NAT function is performed after the forwarding 378 decision (for packets exiting the domain, their private addresses 379 are replaced by public ones). 381 6.4. Flexibility 383 Finally, the FE model SHOULD provide a flexible infrastructure in 384 which new logical functions and new classification, action, and 385 parameterization data can be easily added. Also, the FE model MUST 386 be capable of describing the types of statistics gathered by each 387 logical function. 389 6.5. Minimal Set of Logical Functions 391 The rest of this section defines a minimal set of logical functions 392 that any FE model MUST support. This minimal set DOES NOT imply 393 that all FEs must provide this functionality. Instead, these 394 requirements only specify that the model must be capable of 395 expressing the capabilities that FEs may choose to provide. 397 1)Port Functions 398 The FE model MUST be capable of expressing the number of ports on 399 the device, the static attributes of each port (e.g., port type, 400 link speed), and the configurable attributes of each port (e.g., IP 401 address, administrative status). 403 2)Forwarding Functions 404 The FE model MUST be capable of expressing the data that can be used 405 by the forwarding function to make a forwarding decision. Support 406 for IPv4 and IPv6 unicast and multicast forwarding functions MUST be 407 provided by the model. 409 3)QoS Functions 410 The FE model MUST allow a FE to express its QoS capabilities in 411 terms of, e.g., metering, policing, shaping, and queuing functions. 412 The FE model MUST be capable of expressing the use of these 413 functions to provide IntServ or DiffServ functionality as described 414 in [RFC2211], [RFC2212], [RFC2215], [RFC2475], and [RFC3290]. 416 4)Generic Filtering Functions 417 The FE model MUST be capable of expressing complex sets of filtering 418 functions. The model MUST be able to express the existence of these 419 functions at arbitrary points in the sequence of a FE's packet 420 processing functions. The FE model MUST be capable of expressing a 421 wide range of classification abilities from single fields (e.g., 422 destination address) to arbitrary n-tuples. Similarly, the FE model 423 MUST be capable of expressing what actions these filtering functions 424 can perform on packets that the classifier matches. 426 5)Vendor-Specific Functions 427 The FE model SHOULD be extensible so that vendor-specific FE 428 functionality can be expressed. 430 6)High-Touch Functions 431 The FE model MUST be capable of expressing the encapsulation and 432 tunneling capabilities of a FE. The FE model MUST support functions 433 that mark the class of service that a packet should receive (i.e. 434 IPv4 header TOS octet or the IPv6 Traffic Class octet). The FE 435 model MAY support other high touch functions (e.g., NAT, ALG). 437 7)Security Functions 438 The FE model MUST be capable of expressing the types of encryption 439 that may be applied to packets in the forwarding path. 441 8)Off-loaded Functions 442 Per-packet processing can leave state in the FE, so that logical 443 functions executed during packet processing can perform in a 444 consistent manner (for instance, each packet may update the state of 445 the token bucket occupancy of a give policer). In addition, FEs MUST 446 allow logical functions to execute asynchronously from packet 447 processing, according to a certain finite-state machine, in order to 448 perform functions that are, for instance, off-loaded from the CE to 449 the FE. The FE model MUST be capable of expressing these 450 asynchronous functions. Examples of such functions include the 451 finite-state machine execution required by TCP termination or OSPF 452 Hello processing, triggered not only by packet events, but by timer 453 events as well. 455 7. ForCES Protocol Requirements 457 This section specifies some of the requirements that the ForCES 458 protocol MUST meet. 460 1)Configuration of Modeled Elements 461 The ForCES protocol MUST allow the CEs to determine the capabilities 462 of each FE. These capabilities SHALL be expressed using the FE 463 model whose requirements are defined in Section 6. Furthermore, the 464 protocol MUST provide a means for the CEs to control all the FE 465 capabilities that are discovered through the FE model. The protocol 466 MUST be able to add/remove classification/action entries, set/delete 467 parameters, query statistics, and register for and receive events. 469 2)Support for Secure Communication 470 a) FE configuration will contain information critical to the 471 functioning of a network (e.g. IP Forwarding Tables). As such, it 472 MUST be possible to ensure the authentication and integrity of 473 ForCES protocol messages. 474 b) FE configuration information may also contain information derived 475 from business relationships (e.g. service level agreements). 476 Therefore, it MUST be possible to secure (make private) ForCES 477 protocol messages. 478 c) In order to provide authentication, integrity and privacy for a 479 proposed ForCES protocol, existing security mechanisms such as 480 IPSec/IKE, TLS, etc. MUST be used/leveraged if applicable. 482 3)Scalability 483 The ForCES protocol MUST be capable of supporting (i.e., must scale 484 to) at least hundreds of FEs and tens of thousands of ports. For 485 example, the ForCES protocol field sizes corresponding to FE or port 486 numbers SHALL be large enough to support the minimum required 487 numbers. This requirement does not relate to the performance of a 488 NE as the number of FEs or ports in the NE grows. 490 4)Multihop 491 When the CEs and FEs are separated beyond a single hop, the ForCES 492 protocol will make use of an existing RFC2914 compliant L4 protocol 493 with adequate reliability, security and congestion control (e.g. 494 TCP, SCTP) for transport purposes. 496 5)Message Priority 497 The ForCES protocol MUST provide a means to express the protocol 498 message priorities. 500 6)Reliability 501 The ForCES protocol SHALL assume that it runs on top of an 502 unreliable, datagram service. For IP networks, an encapsulation of 503 the ForCES protocol SHALL be defined that uses a [RFC2914]-compliant 504 transport protocol and provides a datagram service (that could be 505 unreliable). For non-IP networks, additional encapsulations MAY be 506 defined so long as they provide a datagram service to the ForCES 507 protocol. However, since some messages will need to be reliably 508 delivered to FEs, the ForCES protocol MUST provide internal support 509 for reliability mechanisms such as message acknowledgements and/or 510 state change confirmations. 512 7)Interconnect Independence 513 The ForCES protocol MUST support a variety of interconnect 514 technologies. (refer to section 5, requirement# 1) 516 8)CE redundancy or CE failover 517 The ForCES protocol MUST support mechanisms for CE redundancy or CE 518 failover. This includes the ability for CEs and FEs to determine 519 when there is a loss of association between them, ability to restore 520 association and efficient state (re)synchronization mechanisms. This 521 also includes the ability to preset the actions an FE will take in 522 reaction to loss of association to its CE e.g., whether the FE will 523 continue to forward packets or whether it will halt operations. 524 (refer to section 5, requirement# 7) 526 9)Packet Redirection 527 FEs MUST be able to redirect control packets (such as RIP, OSPF 528 messages) addressed to their interfaces to the CE. They MUST also 529 redirect other relevant packets (e.g., such as those with Router 530 Alert Option set) to their CE. The CEs MUST be able to configure the 531 packet redirection information/filters on the FEs. The CEs MUST also 532 be able to create packets and have its FEs deliver them. (refer to 533 section 5, requirement# 8) 535 10)Topology Exchange 536 The ForCES protocol MUST allow the FEs to provide their topology 537 information (topology by which the FEs in the NE are connected) to 538 the CE(s). (refer to section 5, requirement# 10) 540 11)Dynamic Association 541 The ForCES protocol MUST allow CEs and FEs to join and leave a NE 542 dynamically. (refer to section 5, requirement# 12) 544 12)Command Bundling 545 The ForCES protocol MUST be able to group an ordered set of commands 546 to a FE. Each such group of commands SHOULD be sent to the FE in as 547 few messages as possible. Furthermore, the protocol MUST support the 548 ability to specify if a command group MUST have all-or-nothing 549 semantics. 551 13)Asynchronous Event Notification 552 The ForCES protocol MUST be able to asynchronously notify the CE of 553 events on the FE such as failures or change in available resources 554 or capabilities. (refer to section 5, requirement# 6) 556 14)Query Statistics 557 The ForCES protocol MUST provide a means for the CE to be able to 558 query statistics (monitor performance) from the FE. 560 8. Security Considerations 561 See architecture requirement #5 and protocol requirement #2. 563 9. Normative References 565 [RFC3290] Y. Bernet, et. al., "An Informal Management Model for 566 DiffServ Routers", , May 2002. 568 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", 569 RFC1812, June 1995. 571 [RFC2211] J. Wroclawski, "Specification of the Controlled-Load 572 Network Element Service", RFC2211, September 1997. 574 [RFC2212] S. Shenker, C. Partridge, R. Guerin, "Specification of 575 Guaranteed Quality of Service", RFC2212, September 1997. 577 [RFC2215] S. Shenker, J. Wroclawski, "General Characterization 578 Parameters for Integrated Service Network Elements", RFC2215, 579 September 1997. 581 [RFC2475] S. Blake, et. Al., "An Architecture for Differentiated 582 Service", RFC2475, December 1998. 584 [RFC2914] S. Floyd, "Congestion Control Principles", RFC2914, 585 September 2000. 587 [RFC2663] P. Srisuresh & M. Holdrege, "IP Network Address 588 Translator (NAT) Terminology and Considerations", RFC2663, August 589 1999. 591 10. Informative References 593 [REQ-PART] T. Anderson, C. Wang, J. Buerkle, "Requirements for the 594 Dynamic Partitioning of Switching Elements", work in progress, June 595 2002, . 597 11. Authors' Addresses & Acknowledgments 599 This document was written by the ForCES Requirements design team: 601 Todd A. Anderson (Editor) 603 Ed Bowen 604 IBM Zurich Research Laboratory 605 Saumerstrasse 4 606 CH-8803 Rueschlikon Switzerland 607 Phone: +41 1 724 83 68 608 Email: edbowen@us.ibm.com 609 Ram Dantu 610 Netrake Corporation 611 3000 Technology Drive, #100, 612 Plano, Texas, 75074 613 Email: rdantu@netrake.com 614 Phone: 214 291 1111 616 Avri Doria 617 Institute for System Technology 618 Lulea University of Technology 619 SE-971 87, Lulea, Sweden 620 Phone: +46 (0)920 49 3030 621 Email: avri@sm.luth.se 623 Ram Gopal 624 Nokia Research Center 625 5, Wayside Road, 626 Burlington, MA 01803 627 Phone: 1-781-993-3685 628 Email: ram.gopal@nokia.com 630 Jamal Hadi Salim 631 Znyx Networks 632 Ottawa, Ontario 633 Canada 634 Email: hadi@znyx.com 636 Hormuzd Khosravi (Editor) 638 Muneyb Minhazuddin 639 Avaya Inc. 640 123, Epping road, 641 North Ryde, NSW 2113, Australia 642 Phone: +61 2 9352 8620 643 email: muneyb@avaya.com 645 Margaret Wasserman 646 Wind River 647 10 Tara Blvd., Suite 330 648 Nashua, NH 03062 649 Phone: +1 603 897 2067 650 Email: mrw@windriver.com 652 The authors would like to thank Vip Sharma and Lily Yang for their 653 valuable contributions. 655 12. Editors' Contact Information 656 Hormuzd Khosravi 657 Intel 658 2111 NE 25th Avenue 659 Hillsboro, OR 97124 USA 660 Phone: +1 503 264 0334 661 Email: hormuzd.m.khosravi@intel.com 663 Todd A. Anderson 664 Intel 665 2111 NE 25th Avenue 666 Hillsboro, OR 97124 USA 667 Phone: +1 503 712 1760 668 Email: todd.a.anderson@intel.com 670 1. Abstract........................................................1 671 2. Definitions.....................................................2 672 3. Introduction....................................................4 673 4. Architecture....................................................5 674 5. Architectural Requirements......................................6 675 6. FE Model Requirements...........................................8 676 6.1. Types of Logical Functions......................................8 677 6.2. Variations of Logical Functions.................................8 678 6.3. Ordering of Logical Functions...................................8 679 6.4. Flexibility.....................................................9 680 6.5. Minimal Set of Logical Functions................................9 681 7. ForCES Protocol Requirements...................................10 682 8. Security Considerations........................................12 683 9. Normative References...........................................13 684 10. Informative References........................................13 685 11. Authors' Addresses & Acknowledgments..........................13 686 12. Editors' Contact Information..................................14