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