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