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