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