idnits 2.17.1 draft-ietf-forces-framework-04.txt: -(363): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(469): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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? == There are 7 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 434 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (December 2002) is 7796 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) -- Looks like a reference, but probably isn't: 'RFC-2119' on line 88 -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft L. Yang 3 Expiration: June 2003 Intel Corp. 4 File: draft-ietf-forces-framework-04.txt R. Dantu 5 Working Group: ForCES Univ. of Texas Dallas 6 T. Anderson 7 Intel Corp. 8 December 2002 10 Forwarding and Control Element Separation (ForCES) Framework 12 draft-ietf-forces-framework-04.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. Internet-Drafts are 18 working documents of the Internet Engineering Task Force (IETF), its 19 areas, and its working groups. Note that other groups may also 20 distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as 25 reference material or to cite them other than as ``work in 26 progress.'' 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document defines the architectural framework for the ForCES 41 (Forwarding and Control Element Separation) network elements, and 42 identifies the associated entities and the interaction among them. 44 Table of Contents 46 1. Definitions.....................................................2 47 2. Introduction to Forwarding and Control Element Separation 48 (ForCES)...........................................................4 49 3. Architecture....................................................7 50 3.1. Control Elements and Fr Reference Point....................8 51 3.2. Forwarding Elements and Fi reference point.................9 52 3.3. CE Managers...............................................11 53 3.4. FE Managers...............................................11 54 4. Operational Phases.............................................12 55 4.1. Pre-association Phase.....................................12 56 4.1.1. Fl Reference Point...................................12 57 4.1.2. Ff Reference Point...................................13 58 4.1.3. Fc Reference Point...................................14 59 4.2. Post-association Phase and Fp reference point.............14 60 4.2.1. Proximity and Interconnect between CEs and FEs.......14 61 4.2.2. Association Establishment............................14 62 4.2.3. Steady-state Communication...........................15 63 4.2.4. Data Packets across Fp reference point...............16 64 4.2.5. Proxy FE.............................................17 65 4.3. Association Re-establishment..............................17 66 5. Applicability to RFC1812.......................................18 67 5.1. General Router Requirements...............................19 68 5.2. Link Layer................................................20 69 5.3. Internet Layer Protocols..................................20 70 5.4. Internet Layer Forwarding.................................21 71 5.5. Transport Layer...........................................22 72 5.6. Application Layer -- Routing Protocols....................22 73 5.7. Application Layer -- Network Management Protocol..........22 74 6. Summary........................................................23 75 7. Normative References...........................................23 76 8. Informative References.........................................23 77 9. Security Considerations........................................24 78 10. Acknowledgments...............................................24 79 11. Authors' Addresses............................................24 80 12. Intellectual Property Right...................................24 81 13. Full Copyright Statement......................................24 83 Conventions used in this document 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 87 this document are to be interpreted as described in [RFC-2119]. 89 1. Definitions 91 A set of terminology associated with the ForCES requirements is 92 defined in [3] and we only include the ones that are most relevant 93 to this document here. 95 Forwarding Element (FE) - A logical entity that implements the 96 ForCES protocol. FEs use the underlying hardware to provide per- 97 packet processing and handling as directed by a CE via the ForCES 98 protocol. 100 Control Element (CE) - A logical entity that implements the ForCES 101 protocol and uses it to instruct one or more FEs how to process 102 packets. CEs handle functionality such as the execution of control 103 and signaling protocols. 105 ForCES Network Element (NE) - An entity composed of one or more CEs 106 and one or more FEs. To entities outside a NE, the NE represents a 107 single point of management. Similarly, a NE usually hides its 108 internal organization from external entities. 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. 114 Post-association Phase - The period of time during which a FE does 115 know which CE is to control it and vice versa, including the time 116 during which the CE and FE are establishing communication with one 117 another. 119 ForCES Protocol - While there may be multiple protocols used within 120 the overall ForCES architecture, the term "ForCES protocol" refers 121 only to the ForCES post-association phase protocol (see below). 123 ForCES Post-Association Phase Protocol - The protocol used for post- 124 association phase communication between CEs and FEs. This protocol 125 does not apply to CE-to-CE communication, FE-to-FE communication, or 126 to communication between FE and CE managers. The ForCES protocol is 127 a master-slave protocol in which FEs are slaves and CEs are masters. 128 This protocol includes both the management of the communication 129 channel (e.g., connection establishment, heartbeats) and the control 130 messages themselves. This protocol could be a single protocol or 131 could consist of multiple protocols working together. 133 FE Manager - A logical entity that operates in the pre-association 134 phase and is responsible for determining to which CE(s) a FE should 135 communicate. This process is called CE discovery and may involve 136 the FE manager learning the capabilities of available CEs. A FE 137 manager may use anything from a static configuration to a pre- 138 association phase protocol (see below) to determine which CE(s) to 139 use. Being a logical entity, a FE manager might be physically 140 combined with any of the other logical entities mentioned in this 141 section. 143 CE Manager - A logical entity that operates in the pre-association 144 phase and is responsible for determining to which FE(s) a CE should 145 communicate. This process is called FE discovery and may involve 146 the CE manager learning the capabilities of available FEs. A CE 147 manager may use anything from a static configuration to a pre- 148 association phase protocol (see below) to determine which FE to use. 149 Being a logical entity, a CE manager might be physically combined 150 with any of the other logical entities mentioned in this section. 152 Pre-association Phase Protocol - A protocol between FE managers and 153 CE managers that is used to determine which CEs or FEs to use. A 154 pre-association phase protocol may include a CE and/or FE capability 155 discovery mechanism. Note that this capability discovery process is 156 wholly separate from (and does not replace) that used within the 157 ForCES protocol. However, the two capability discovery mechanisms 158 may utilize the same FE model. 160 FE Model - A model that describes the logical processing functions 161 of a FE. 163 ForCES Protocol Element - A FE or CE. 165 2. Introduction to Forwarding and Control Element Separation (ForCES) 167 An IP network element (NE) appears to external entities as a 168 monolithic piece of network equipment, e.g., a router, NAT, 169 firewall, or load balancer. Internally, however, an IP network 170 element (NE) (such as a router) is composed of numerous logically 171 separated entities that cooperate to provide a given functionality 172 (such as routing). Two types of network element components exist: 173 control element (CE) in control plane and forwarding element (FE) in 174 forwarding plane (or data plane). Forwarding elements typically are 175 ASIC, network-processor, or general-purpose processor-based devices 176 that handle data path operations for each packet. Control elements 177 are typically based on general-purpose processors that provide 178 control functionality like routing and signaling protocols. 180 ForCES aims to define a framework and associated protocol(s) to 181 standardize information exchange between the control and forwarding 182 plane. Having standard mechanisms allows CEs and FEs to become 183 physically separated standard components. This physical separation 184 accrues several benefits to the ForCES architecture. Separate 185 components would allow component vendors to specialize in one 186 component without having to become experts in all components. 187 Standard protocol also allows the CEs and FEs from different 188 component vendors to interoperate with each other and hence it 189 becomes possible for system vendors to integrate together the CEs 190 and FEs from different component suppliers. This interoperability 191 translates into a lot more design choices and flexibility to the 192 system vendors. Overall, ForCES will enable rapid innovation in 193 both the control and forwarding planes while maintaining 194 interoperability. Scalability is also easily provided by this 195 architecture in that additional forwarding or control capacity can 196 be added to existing network elements without the need for forklift 197 upgrades. 199 One example of such physical separation is at the blade level. 200 Figure 1 shows such an example configuration of a router, with two 201 control blades and multiple router (forwarding) blades, all 202 interconnected into a switch fabric backplane. In such chassis 203 configuration, the control blades are the CEs while the router 204 blades are FEs, and the switch fabric backplane provides the 205 physical interconnect for all the blades. Control blade A may be 206 the primary CE while control blade B is the backup CE providing 207 redundancy. It is also possible to have a redundant switch fabric 208 for high availability support. Routers today with this kind of 209 configuration use proprietary interface for messaging between CEs 210 and FEs. The goal of ForCES is to replace such proprietary 211 interface with a standard protocol. With a standard protocol like 212 ForCES implemented on all blades, it becomes possible for control 213 blades from vendor X and routing blades from vendor Y to work 214 seamlessly together in one chassis. 216 ------------------------- ------------------------- 217 | Control Blade A | | Control Blade B | 218 | (CE) | | (CE) | 219 ------------------------- ------------------------- 220 ^ | ^ | 221 | | | | 222 | V | V 223 --------------------------------------------------------- 224 | Switch Fabric Backplane | 225 --------------------------------------------------------- 226 ^ | ^ | ^ | 227 | | | | � | | 228 | V | V | V 229 ------------ ------------ ------------ 230 |Router | |Router | |Router | 231 |Blade #1 | |Blade #2 | |Blade #N | 232 | (FE) | | (FE) | | (FE) | 233 ------------ ------------ ------------ 234 ^ | ^ | ^ | 235 | | | | � | | 236 | V | V | V 238 Figure 1. A router configuration example with separate blades. 240 ------- ------- 241 | CE1 | | CE2 | 242 ------- ------- 243 ^ ^ 244 | | 245 V V 246 ============================================ Ethernet 247 ^ ^ � ^ 248 | | | 249 V V V 250 ------- ------- -------- 251 | FE#1| | FE#2| | FE#n | 252 ------- ------- -------- 253 ^ | ^ | ^ | 254 | | | | | | 255 | V | V | V 256 Figure 2. A router configuration example with separate boxes. 258 Another level of physical separation between the CEs and FEs can be 259 at the box level. In such configuration, all the CEs and FEs are 260 physically separated boxes, interconnected with some kind of high 261 speed LAN connection (like Gigabit Ethernet). These separated CEs 262 and FEs are only one hop away from each other within a local area 263 network. The CEs and FEs communicate to each other by running 264 ForCES, and the collection of these CEs and FEs together become one 265 routing unit to the external world. Figure 2 shows such an example. 267 In both examples shown here, the same physical interconnect is used 268 for both CE-to-FE and FE-to-FE communication. However, that does 269 not have to be the case. One reason to use different interconnect 270 is that CE-to-FE interconnect does not have to be as fast as the FE- 271 to-FE interconnect, so the more expensive fast connections can be 272 saved for FE-to-FE only. The separate interconnects may also 273 provide reliability and redundancy benefits for the NE. 275 ------------------------------------------------- 276 | | | | | | | 277 |OSPF |RIP |BGP |RSVP |LDP |� | 278 | | | | | | | 279 ------------------------------------------------- 280 | ForCES Interface | 281 ------------------------------------------------- 282 ^ ^ 283 ForCES | |data 284 control | |packets 285 messages| |(e.g., routing packets) 286 v v 287 ------------------------------------------------- 288 | ForCES Interface | 289 ------------------------------------------------- 290 | | | | | | | 291 |LPM Fwd|Meter |Shaper |NAT |Classi-|� | 292 | | | | |fier | | 293 ------------------------------------------------- 294 | FE resources | 295 ------------------------------------------------- 297 Figure 3. Examples of CE and FE functions 299 Some examples of control functions that can be implemented in the CE 300 include routing protocols like RIP, OSPF and BGP, control and 301 signaling protocols like RSVP (Resource Reservation Protocol), LDP 302 (Label Distribution Protocol) for MPLS, etc. Examples of forwarding 303 functions in FE include LPM (longest prefix match) forwarder, 304 classifiers, traffic shaper, meter, NAT, etc. Figure 3 shows a 305 diagram with examples in both CE and FE. Any given NE may contain 306 one or many of these CE and FE functions in it. The diagram also 307 shows that ForCES protocol is used to transport both the control 308 messages for ForCES itself and the data packets that are 309 originated/destined from/to the control functions in CE (e.g., 310 routing packets). Section 4.2.4 provides more detail on this. 312 A set of requirements for control and forwarding separation is 313 identified in [3]. This document describes a ForCES architecture 314 that satisfies the architectural requirements of that document and 315 defines a framework for ForCES network elements and the associated 316 entities to facilitate protocol definition. Whenever necessary, 317 this document uses many examples to illustrate the issues and/or 318 possible solutions in ForCES. These examples are intended to be 319 just examples, and should not be taken as the only or definite ways 320 of doing certain things. It is expected that separate document will 321 be produced by the ForCES working group to specify the ForCES 322 protocol(s). 324 3. Architecture 326 This section defines the ForCES architectural framework and the 327 associated logical components. This ForCES framework defines 328 components of ForCES NEs including several ancillary components. 329 These components may be connected in different kinds of topologies 330 for flexible packet processing. 332 --------------------------------------- 333 | ForCES Network Element | 334 -------------- Fc | -------------- -------------- | 335 | CE Manager |---------+-| CE 1 |------| CE 2 | | 336 -------------- | | | Fr | | | 337 | | -------------- -------------- | 338 | Fl | | | Fp / | 339 | | Fp| |----------| / | 340 | | | |/ | 341 | | | | | 342 | | | Fp /|----| | 343 | | | /--------/ | | 344 -------------- Ff | -------------- -------------- | 345 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 346 -------------- | | |------| | | 347 | -------------- -------------- | 348 | | | | | | | | | | 349 ----+--+--+--+----------+--+--+--+----- 350 | | | | | | | | 351 | | | | | | | | 352 Fi/f Fi/f 354 Figure 4. ForCES Architectural Diagram 356 The diagram in Figure 4 shows the logical components of the ForCES 357 architecture and their relationships. There are two kinds of 358 components inside a ForCES network element: control element (CE) and 359 forwarding element (FE). The framework allows multiple instances of 360 CE and FE inside one NE. Each FE contains one or more physical 361 media interfaces for receiving and transmitting packets from/to the 362 external world. The aggregation of these FE interfaces becomes the 363 NE�s external interfaces. In addition to the external interfaces, 364 there must also exist some kind of interconnect within the NE so 365 that the CE and FE can communicate with each other, and one FE can 366 forward packets to another FE. The diagram also shows two entities 367 outside of the ForCES NE: CE Manager and FE Manager. These two 368 entities provide configuration to the corresponding CE or FE in the 369 pre-association phase (see Section 5.1). There is no defined role 370 for FE Manager and CE Manager in post-association phase, thus these 371 logical components are not considered part of the ForCES NE. 373 For convenience, the logical interactions between these components 374 are labeled by reference points Fp, Fc, Ff, Fr, Fl, and Fi, as shown 375 in Figure 4. The FE external interfaces are labeled as Fi/f. More 376 detail is provided in Section 4 and 5 for each of these reference 377 points. All these reference points are important in understanding 378 the ForCES architecture, however, the ForCES protocol is only 379 defined over one reference point -- Fp. 381 The interface between two ForCES NEs is identical to the interface 382 between two conventional routers and these two NEs exchange the 383 protocol packets through the external interfaces at Fi/f. ForCES 384 NEs connect to existing routers transparently. 386 3.1. Control Elements and Fr Reference Point 388 It is not necessary to define any protocols across the Fr reference 389 point to enable control and forwarding separation for simple 390 configurations like single CE and multiple FEs. However, this 391 architecture permits multiple CEs to be present in a network 392 element. In cases where an implementation uses multiple CEs, the 393 invariant that the CEs and FEs together appear as a single NE must 394 be maintained. 396 Multiple CEs may be used for redundancy, load sharing, distributed 397 control, or other purposes. Redundancy is the case where one or 398 more CEs are prepared to take over should an active CE fail. Load 399 sharing is the case where two or more CEs are concurrently active 400 and where any request that can be serviced by one of the CEs can 401 also be serviced by any of the other CEs. For both redundancy and 402 load sharing, the CEs involved are equivalently capable. The only 403 difference between these two cases is in terms of how many active 404 CEs there are. Distributed control is the case where two or more 405 CEs are concurrently active but where certain requests can only be 406 serviced by certain CEs. 408 When multiple CEs are employed in a ForCES NE, their internal 409 organization is considered an implementation issue that is beyond 410 the scope of ForCES. CEs are wholly responsible for coordinating 411 amongst themselves via the Fr reference point to provide consistency 412 and synchronization. However, ForCES does not define the 413 implementation or protocols used between CEs, nor does it define how 414 to distribute functionality among CEs. Nevertheless, ForCES will 415 support mechanisms for CE redundancy or fail over, and it is 416 expected that vendors will provide redundancy or fail over solutions 417 within this framework. 419 3.2. Forwarding Elements and Fi reference point 421 FEs perform per-packet processing and handling as directed by CEs. 422 FEs have no initiative of their own. Instead, FEs are slaves and 423 only do as they are told. FEs may communicate with one or more CEs 424 concurrently across reference point Fp. FEs have no notion of CE 425 redundancy, load sharing, or distributed control. Instead, FEs 426 accept commands from any CE authorized to control them, and it is up 427 to the CEs to coordinate among themselves to achieve redundancy, 428 load sharing or distributed control. The idea is to keep FEs as 429 simple and dumb as possible so that FEs can focus its resource on 430 the packet processing functions. 432 ------- Fr ------- 433 | CE1 | ------| CE2 | 434 ------- ------- 435 | \ / | 436 | \ / | 437 | \ / | 438 | \/Fp | 439 | /\ | 440 | / \ | 441 | / \ | 442 ------- Fi ------- 443 | FE1 |<----->| FE2 | 444 ------- ------- 446 Figure 5. CE redundancy example. 448 For example, in Figure 5, FE1 and FE2 can be configured to accept 449 commands from both the primary CE (CE1) and the backup CE (CE2). 450 Upon detection of CE1 failure, perhaps across the Fr or Fp reference 451 point, CE2 is configured to take over activities of CE1. This is 452 beyond the scope of ForCES and is not discussed further. 454 Distributed control can be achieved in the similar fashion, without 455 much intelligence on the part of FEs. For example, FEs can be 456 configured to detect RSVP and BGP protocol packets, and forward RSVP 457 packets to one CE and BGP packets to another CE. Hence, FEs may 458 need to do packet filtering for forwarding packets to specific CEs. 460 This architecture permits multiple FEs to be present in a NE. [3] 461 dictates that the ForCES protocol must be able to scale to at least 462 hundreds of FEs (see [3] Section 5, requirement #11). Each of these 463 FEs may potentially have a different set of packet processing 464 functions, with different media interfaces. FEs are responsible for 465 basic maintenance of layer-2 connectivity with other FEs and with 466 external entities. Many layer-2 media include sophisticated control 467 protocols. The FORCES protocol (over the Fp reference point) will 468 be able to carry messages for such protools so that, in keeping with 469 the "dumb FE�� model, the CE can provide appropriate intelligence and 470 control over these media. 472 When multiple FEs are present, ForCES requires that packets must be 473 able to arrive at the NE by one FE and leave the NE via a different 474 FE (See [3], Section 5, Requirement #3). Packets that enter the NE 475 via one FE and leave the NE via a different FE are transferred 476 between FEs across the Fi reference point. Fi reference point could 477 be used by FEs to discovery their (inter-FE) topology, perhaps 478 during pre-association phase. The Fi reference point is a separate 479 protocol from the Fp reference point and is not currently defined by 480 the ForCES architecture. 482 ----------------- 483 | CE | 484 ----------------- 485 ^ ^ ^ 486 / | \ 487 / v \ 488 / ------- \ 489 / +->| FE3 |<-+ \ 490 / | | | | \ 491 v | ------- | v 492 ------- | | ------- 493 | FE1 |<-+ +->| FE2 | 494 | |<--------------->| | 495 ------- ------- 496 ^ | ^ | 497 | | | | 498 | v | v 500 (a) Full mesh among FE1, FE2 and FE3. 502 ----------- 503 | CE | 504 ----------- 505 ^ ^ ^ ^ 506 / | | \ 507 /------ | | ------\ 508 v v v v 509 ------- ------- ------- ------- 510 | FE1 |<->| FE2 |<->| FE3 |<->| FE4 | 511 ------- ------- ------- ------- 512 ^ | ^ | ^ | ^ | 513 | | | | | | | | 514 | v | v | v | v 515 (b) Multiple FEs in a daisy chain 517 ^ | 518 | v 519 ----------- 520 | FE1 |<-----------------------| 521 ----------- | 522 ^ ^ | 523 / \ | 524 | ^ / \ ^ | V 525 v | v v | v ---------- 526 --------- --------- | | 527 | FE2 | | FE3 |<------------>| CE | 528 --------- --------- | | 529 ^ ^ ^ ---------- 530 | \ / ^ ^ 531 | \ / | | 532 | v v | | 533 | ----------- | | 534 | | FE4 |<----------------------| | 535 | ----------- | 536 | | ^ | 537 | v | | 538 | | 539 |----------------------------------------| 541 (c) Multiple FEs connected by a ring 543 Figure 6. Some examples of FE topology. 545 FEs could be connected in different kinds of topologies and packet 546 processing may spread across several FEs in the topology. Hence, 547 logical packet flow may be different from physical FE topology. 548 Figure 6 provides some topology examples. When it is necessary to 549 forward packets between FEs, the CE needs to understand the FE 550 topology. The FE topology can be queried from the FEs by CEs. 552 3.3. CE Managers 554 CE managers are responsible for determining which FEs a CE should 555 control. It is legitimate for CE managers to be hard-coded with the 556 knowledge of with which FEs its CEs should communicate. A CE 557 manager may also be physically embedded into a CE and be implemented 558 as a simple keypad or other direct configuration mechanism on the 559 CE. Finally, CE managers may be physically and logically separate 560 entities that configure the CE with FE information via such 561 mechanisms as COPS-PR [6] or SNMP [4]. 563 3.4. FE Managers 564 FE managers are responsible for determining to which CE any 565 particular FE should initially communicate. Like CE managers, no 566 restrictions are placed on how a FE manager decides to which CE its 567 FEs should communicate, nor are restrictions placed on how FE 568 managers are implemented. 570 4. Operational Phases 572 Both FEs and CEs require some configuration in place before they can 573 start information exchange and function as a coherent network 574 element. Two operational phases are identified in this framework -- 575 pre-association and post-association. 577 4.1.Pre-association Phase 579 Pre-association phase is the period of time during which a FE 580 Manager and a CE Manager are determining which FE and CE should be 581 part of the same network element. The protocols used during this 582 phase may include all or some of the message exchange over Fl, Ff 583 and Fc reference points. However, all these may be optional and 584 none of this is within the scope of ForCES protocol. 586 4.1.1. Fl Reference Point 588 FE Manager FE CE Manager CE 589 | | | | 590 | | | | 591 |(security exchange) | | 592 1|<------------------------------>| | 593 | | | | 594 |(a list of CEs and their attributes) | 595 2|<-------------------------------| | 596 | | | | 597 |(a list of FEs and their attributes) | 598 3|------------------------------->| | 599 | | | | 600 | | | | 601 |<----------------Fl------------>| | 603 Figure 7. An example of message exchange over Fl reference point 605 CE managers and FE managers may communicate across the Fl reference 606 point in the pre-association phase in order to determine which CEs 607 and FEs should communicate with each other. Communication across 608 the Fl reference point is optional in this architecture. No 609 requirements are placed on this reference point. 611 CE managers and FE managers may be operated by different entities. 612 The operator of the CE manager may not want to divulge, except to 613 specified FE managers, any characteristics of the CEs it manages. 614 Similarly, the operator of the FE manager may not want to divulge FE 615 characteristics, except to authorized entities. As such, CE 616 managers and FE managers may need to authenticate one another. 617 Subsequent communication between CE managers and FE managers may 618 require other security functions such as privacy, non-repudiation, 619 freshness, and integrity. 621 Once the necessary security functions have been performed, the CE 622 and FE managers communicate to determine which CEs and FEs should 623 communicate with each other. At the very minimum, the CE and FE 624 managers need to learn of the existence of available FEs and CEs 625 respectively. This discovery process may or may not entail one or 626 both managers learning the capabilities of the discovered ForCES 627 protocol elements. Figure 7 shows an example of possible message 628 exchange between CE manager and FE manager over Fl reference point. 630 4.1.2. Ff Reference Point 632 FE Manager FE CE Manager CE 633 | | | | 634 | | | | 635 |(security exchange) |(security exchange) 636 1|<------------>|authentication 1|<----------->|authentication 637 | | | | 638 |(FE ID, attributes) |(CE ID, attributes) 639 2|<-------------|request 2|<------------|request 640 | | | | 641 3|------------->|response 3|------------>|response 642 |(corresponding CE ID) |(corresponding FE ID) 643 | | | | 644 | | | | 645 |<-----Ff----->| |<-----Fc---->| 647 Figure 8. Examples of message exchange 648 over Ff and Fc reference points. 650 The Ff reference point is used to inform forwarding elements of the 651 association decisions made by the FE manager in pre-association 652 phase. Only authorized entities may instruct a FE with respect to 653 which CE should control it. Therefore, privacy, integrity, 654 freshness, and authentication are necessary between the FE manager 655 and FEs when the FE manager is remote to the FE. Once the 656 appropriate security has been established, the FE manager instructs 657 the FEs across this reference point to join a new NE or to 658 disconnect from an existing NE. The FE Manager could also assign 659 unique FE identifiers to the FEs using this reference point. The FE 660 identifiers are useful in post association phase to express FE 661 topology. Figure 8 shows example of message exchange over Ff 662 reference point. 664 Note that the FE manager function may be co-located with the FE 665 (such as by manual keypad entry of the CE IP address), in which case 666 this reference point is reduced to a built-in function. 668 4.1.3. Fc Reference Point 670 The Fc reference point is used to inform control elements of the 671 association decisions made by CE managers in pre-association phase. 672 When the CE manager is remote, only authorized entities may instruct 673 a CE to control certain FEs. Privacy, integrity, freshness and 674 authentication are also required across this reference point in such 675 a configuration. Once appropriate security has been established, 676 the CE manager instructs CEs as to which FEs they should control and 677 how they should control them. Figure 7 shows example of message 678 exchange over Fc reference point. 680 As with the FE manager and FEs, configurations are possible where 681 the CE manager and CE are co-located and no protocol is used for 682 this function. 684 4.2. Post-association Phase and Fp reference point 686 Post-association phase is the period of time during which a FE and 687 CE have been configured with information necessary to contact each 688 other and includes both association establishment and steady-state 689 communication. The communication between CE and FE is performed 690 across the Fp ("p" meaning protocol) reference point. ForCES 691 protocol is exclusively used for all communication across the Fp 692 reference point. 694 4.2.1. Proximity and Interconnect between CEs and FEs 696 The ForCES Working Group has made a conscious decision that the 697 first version of ForCES will not be designed to support 698 configurations where the CE and FE are located arbitrarily in the 699 network. In particular, ForCES is intended for "very close" CE/FE 700 localities in IP networks, as defined by ForCES Applicability 701 Statement ([7]). Very Close localities consist of control and 702 forwarding elements that either are components in the same physical 703 box, or are separated at most by one local network hop. 705 CEs and FEs can be connected by a variety of interconnect 706 technologies, including Ethernet connections, backplanes, ATM (cell) 707 fabrics, etc. ForCES should be able to support each of these 708 interconnects (see [3] Section 5, requirement #1). ForCES will make 709 use of an existing RFC2914 ([2]) compliant L4 protocol with adequate 710 reliability, security and congestion control (e.g. TCP, SCTP) for 711 transport purposes. 713 4.2.2. Association Establishment 715 As an example, figure 9 shows some of the message exchange that may 716 happen before the association between the CE and FE is fully 717 established. Either the CE or FE can initiate the connection. The 718 FE needs to inform the CE of its own capability and its topology in 719 relation to other FEs. The capability of the FE is represented by 720 the FE model, described in another separate document. The model 721 would allow a FE to describe what kind of packet processing 722 functions it contains, in what order the processing happens, what 723 kinds of configurable parameters it allows, what statistics it 724 collects and what events it might throw, etc. Once such information 725 is available to the CE, the CE sends all necessary configuration to 726 the FE so that the FE can start receiving and processing packets 727 correctly. For example, the CE might need to send a snapshot of the 728 current forwarding table to the FE so that the FE can start routing 729 packets correctly. Once FE starts accepting packets for processing, 730 we say the association of this FE with its CE is now established. 731 From then on, the CE and FE enter steady-state communication. 733 FE CE 734 | | 735 |(Hello, are you there?)| 736 1|<----------------------| 737 | | 738 |(Yes. let me join the NE please.) 739 2|---------------------->| 740 | | 741 |(What kind of FE are you? -- capability query) 742 3|<----------------------| 743 | | 744 |(Here is my FE functions/state: use model to describe) 745 4|---------------------->| 746 | | 747 |(How are you connected with others? -- topology query) 748 5|<----------------------| 749 | | 750 |(Here is the topology info) 751 6|---------------------->| 752 | | 753 |(Config for FE, e.g. forwarding table) 754 7|<----------------------| 755 | | 756 |(I am ready to go. Shall I?) 757 8|---------------------->| 758 | | 759 |(Go ahead!) | 760 9|<----------------------| 761 | | 763 Figure 9. Example of message exchange between CE and FE 764 over Fp to establish NE association 766 4.2.3. Steady-state Communication 767 Once an association is established between the CE and FE, the ForCES 768 protocol is used by the CE and FE over Fp reference point to 769 exchange information to facilitate packet processing. 771 FE CE 772 | | 773 |(Add these new routes.)| 774 1|<----------------------| 775 | | 776 |(Successful.) | 777 2|---------------------->| 778 | | 779 | | 780 |(Query some stats.) | 781 1|<----------------------| 782 | | 783 |(Reply with stats collected.) 784 2|---------------------->| 785 | | 786 | | 787 |(My port is down, with port #.) 788 1|---------------------->| 789 | | 790 |(Route to this port instead...) 791 2|<----------------------| 792 | | 793 | | 795 Figure 10. Examples of message exchange between CE and FE 796 over Fp during steady-state communication 798 Based on the information acquired through CEs' control processing, 799 CEs will frequently need to manipulate the packet-forwarding 800 behaviors of their FE(s) by sending instructions to FEs. For 801 example, Figure 10 shows message exchange examples in which the CE 802 sends new routes to the FE so that the FE can add them to its 803 forwarding table. The CE may query the FE for statistics collected 804 by the FE and the FE may notify the CE of important events such as 805 port failure. 807 4.2.4. Data Packets across Fp reference point 809 Control plane protocol packets (such as RIP, OSPF messages) 810 addressed to any of NE's interfaces are typically redirected by the 811 receiving FE to its CE, and CE may originate packets and have its FE 812 deliver them to other NEs. Therefore, ForCES protocol over Fp not 813 only transports the ForCES protocol messages between CEs and FEs, 814 but also encapsulates the data packets from control plane protocols. 815 Moreover, one FE may be controlled by multiple CEs for distributed 816 control. In this configuration, the control protocols supported by 817 the FORCES NEs may spread across multiple CEs. For example, one CE 818 may support routing protocols like OSPF and BGP, while signaling and 819 admission control protocol like RSVP is supported in another CE. 820 FEs are configured to recognize and filter these protocol packets 821 and forward them to the corresponding CE. 823 Figure 11 shows one example of how the BGP packets originated by 824 router A are passed to router B. In this example, the ForCES 825 protocol is used to transport the packets from the CE to the FE 826 inside router A, and then from the FE to the CE inside router B. In 827 light of the fact that the ForCES protocol is responsible to 828 transport both the control messages and the data packets between the 829 CE and FE over Fp reference point, it is possible to use either a 830 single protocol or multiple protocols to achieve that. 832 --------------------- ---------------------- 833 | | | | 834 | +--------+ | | +--------+ | 835 | |CE(BGP) | | | |CE(BGP) | | 836 | +--------+ | | +--------+ | 837 | | | | ^ | 838 | |Fp | | |Fp | 839 | v | | | | 840 | +--------+ | | +--------+ | 841 | | FE | | | | FE | | 842 | +--------+ | | +--------+ | 843 | | | | ^ | 844 | Router | | | Router | | 845 | A | | | B | | 846 ---------+----------- -----------+---------- 847 v ^ 848 | | 849 | | 850 ------------------->--------------- 852 Figure 11. Example to show data packet flow between two NEs. 854 4.2.5. Proxy FE 856 In the case where a physical FE cannot implement (e.g., due to the 857 lack of a general purpose CPU) the ForCES protocol directly, a proxy 858 FE can be used in the middle of Fp reference point. This allows the 859 CE communicate to the physical FE via the proxy by using ForCES, 860 while the proxy manipulates the physical FE using some intermediary 861 form of communication (e.g., a non-ForCES protocol or DMA). In such 862 an implementation, the combination of the proxy and the physical FE 863 becomes one logical FE entity. 865 4.3. Association Re-establishment 867 FEs and CEs may join and leave NEs dynamically (see [3] Section 5, 868 requirements #12). When a FE or CE leaves the NE, the association 869 with the NE is broken. If the leaving party rejoins a NE later, to 870 re-establish the association, it may or may not need to re-enter the 871 pre-association phase. Loss of association can also happen 872 unexpectedly due to loss of connection between the CE and the FE. 873 Therefore, the framework allows the bi-directional transition 874 between these two phases, but the ForCES protocol is only applicable 875 for the post-association phase. However, the protocol should 876 provide mechanisms to support association re-establishment (see [3] 877 Section 5, requirement #7). 879 The example in Figure 5 is used to illustrate what happens when the 880 association is broken and later re-established again. Section 3.2 881 already explains what happens if CE1 fails and how CE2 can take 882 over. If no CE redundancy is provided, at the association 883 establishment phase FEs need to be told what to do in the case of CE 884 failure. FEs may be told to stop packet processing all together if 885 its CE fails. Or, FEs may be told to continue forwarding packets 886 for a limited time even in the face of CE failure. No matter what 887 the instruction is, it needs to be part of the configuration when 888 the association is established. 890 In the same example in Figure 5, assuming CE1 is the working CE for 891 the moment, what would happen if one of the FEs, say FE1, leaves the 892 NE temporarily? FE1 may voluntarily decide to leave the 893 association. Or, FE1 may stop functioning simply due to unexpected 894 failure. In former case, CE1 receives a "leave-association request" 895 from FE1. In the latter, CE1 detects the failure of FE1 by some 896 other mean. In both cases, CE1 keeps a note of such event from FE1 897 while continue commanding FE2. When FE1 decides to rejoin again, or 898 when it is back up again from the failure, FE1 needs to re-discover 899 its master (CE). This can be achieved by several means. It may re- 900 enter the pre-association phase and get that information from its FE 901 manager. It may retrieve the previous CE information from its 902 cache, if it can validate the information freshness. Once it 903 discovers its CE, it starts message exchange with CE to re-establish 904 the association just as outlined in Figure 9, with the possible 905 exception that it might be able to bypass the transport of the 906 complete initialization information. Suppose that FE1 still has its 907 routing table and other state information from the last association, 908 instead of sending all the information again from scratch, it can 909 choose to use more efficient mechanism to re-sync up the state with 910 its CE. For example, a checksum of the state might give a quick 911 indication of whether or not the state is in-sync with its CE. By 912 comparing its state with CE first, it sends information update only 913 if it is needed. 915 5. Applicability to RFC1812 917 [3] Section 5, requirement #9 dictates that "All proposed ForCES 918 architecture must explain how that architecture supports all of the 919 router functions as defined in RFC1812." RFC1812 discusses many 920 important requirements for IPv4 routers from the link layer to the 921 application layer. This section addresses the relevant requirements 922 in RFC1812 for implementing IPv4 routers based on ForCES 923 architecture and explains how ForCES satisfies these requirements by 924 providing guidelines on how to separate the functionalities required 925 into forwarding plane and control plane. 927 In general, the forwarding plane carries out the bulk of the per- 928 packet processing that is required at line speed, while the control 929 plane carries most of the computationally complex operations that 930 are typical of the control and signaling protocols. However, it is 931 impossible to draw a rigid line to divide the processing into CEs 932 and FEs cleanly. Nor should the ForCES architecture limit the 933 innovative approaches in control and forwarding plane separation. 934 As more and more processing power is available in the FEs, some of 935 the control functions that traditionally are performed by CEs may 936 now be moved to FEs for better performance and scalability. Such 937 offloaded functions may include part of ICMP or TCP processing, or 938 part of routing protocols. Once off-loaded onto the forwarding 939 plane, such CE functions, even though logically belonging to the 940 control plane, now become part of the FE functions. Just like the 941 other logical functions performed by FEs, such off-loaded functions 942 must be expressed as part of the FE model so that the CEs can decide 943 how to best take advantage of these off-loaded functions when 944 present on the FEs. 946 5.1. General Router Requirements 948 Routers have at least two or more logical interfaces. When CEs and 949 FEs are separated by ForCES within a single NE, some additional 950 interfaces are needed for intra-NE communications. Figure 12 shows 951 an example to illustrate that. This NE contains one CE and two FEs. 952 Each FE has four interfaces; two of them are used for receiving and 953 transmitting packets to the external world, while the other two are 954 for intra-NE connections. CE has two logical interfaces #9 and #10, 955 connected to interfaces #3 and #6 from FE1 and FE2, respectively. 956 Interface #4 and #5 are connected for FE1-FE2 communication. 957 Therefore, this router NE provides four external interfaces (#1, 2, 958 7 and 8). 960 --------------------------------- 961 | router NE | 962 | ----------- ----------- | 963 | | FE1 | | FE2 | | 964 | ----------- ----------- | 965 | 1| 2| 3| 4| 5| 6| 7| 8| | 966 | | | | | | | | | | 967 | | | | +----+ | | | | 968 | | | | | | | | 969 | | | 9| 10| | | | 970 | | | -------------- | | | 971 | | | | CE | | | | 972 | | | -------------- | | | 973 | | | | | | 974 -----+--+----------------+--+---- 975 | | | | 976 | | | | 978 Figure 12. A router NE example with four interfaces. 980 IPv4 routers must implement IP to support its packet forwarding 981 function, which is driven by its FIB (Forwarding Information Base). 982 This Internet layer forwarding (see RFC1812 [1] Section 5) 983 functionality naturally belongs to FEs in the ForCES architecture. 985 A router may implement transport layer protocols (like TCP and UDP) 986 that are required to support application layer protocols (see 987 RFC1812 [1] Section 6). One important class of application 988 protocols is routing protocols (see RFC1812 [1] Section 7). In 989 ForCES architecture, routing protocols are naturally implemented by 990 CEs. Routing protocols require routers communicate with each other. 991 This communication between CEs in different routers is supported in 992 ForCES by FEs' ability to redirect data packets addressed to routers 993 (i.e., NEs) and CEs' ability to originate packets and have them 994 delivered by their FEs. This communication occurs across Fp 995 reference point inside each router and between neighboring routers' 996 external interfaces, as illustrated in Figure 11. 998 5.2.Link Layer 1000 Since FEs own all the external interfaces for the router, FEs need 1001 to conform to the link layer requirements in RFC1812. Arguably, ARP 1002 support may be implemented in either CEs or FEs. As we will see 1003 later, a number of behaviors that RFC1812 mandates fall into this 1004 category -- they may be performed by the FE and may be performed by 1005 the CE. A general guideline is needed to ensure interoperability 1006 between separated control and forwarding planes. The guideline we 1007 offer here is that in general CEs are required to be capable of 1008 these kind of operations while FEs may or may not choose to 1009 implement them. FE model should indicate its capabilities in this 1010 regard so that CEs can decide where these functions are implemented. 1012 Interface parameters, including MTU, IP address, etc., must be 1013 configurable by CEs via ForCES. CEs must be able to determine 1014 whether a physical interface in an FE is available to send packets 1015 or not. FEs must also inform CEs the status change of the 1016 interfaces (like link up/down) via ForCES. 1018 5.3.Internet Layer Protocols 1020 Both FEs and CEs must implement IP protocol and all mandatory 1021 extensions as RFC1812 specified. CEs should implement IP options 1022 like source route and record route while FEs may choose to implement 1023 those as well. Timestamp option should be implemented by FEs to 1024 insert the timestamp most accurately. FE must interpret the IP 1025 options that it understands and preserve the rest unchanged for use 1026 by CEs. Both FEs and CEs might choose to silently discard packets 1027 without sending ICMP errors, but such events should be logged and 1028 counted. FEs may report statistics for such events to CEs via 1029 ForCES. 1031 When multiple FEs are involved to process packets, the appearance of 1032 single NE must be strictly maintained. For example, Time-To-Live 1033 (TTL) must be decremented only once within a single NE. For 1034 example, it can be always decremented by the last FE with egress 1035 function. 1037 FEs must receive and process normally any packets with a broadcast 1038 destination address or a multicast destination address that the 1039 router has asked to receive. When IP multicast is supported in 1040 routers, IGMP is implemented in CEs. CEs are also required of ICMP 1041 support, while it is optional for FEs to support ICMP. Such an 1042 option can be communicated to CEs as part of the FE model. 1043 Therefore, FEs can always rely upon CEs to send out ICMP error 1044 messages, but FEs also have the option to generate ICMP error 1045 messages themselves. 1047 5.4.Internet Layer Forwarding 1049 IP forwarding is implemented by FEs. When the routing table is 1050 updated at CEs, ForCES is used to send the new route entries from 1051 CEs to FEs. Each FE has its own forwarding table and uses this 1052 table to direct packets to the next hop interface. 1054 Upon receiving IP packets, FE verifies the IP header and processes 1055 most of the IP options. Some options can't be processed until the 1056 routing decision has been made. Routing decision is made after 1057 examining the destination IP address. If the destination address 1058 belongs to the router itself, the packets are filtered and either 1059 processed locally or forwarded to CE, depending upon the 1060 instructions set-up by CE. Otherwise, FE determines the next hop IP 1061 address by looking up in its forwarding table. FE also determines 1062 the network interface it uses to send the packets. Sometimes FE may 1063 need to forward the packets to another FE before packets can be 1064 forwarded out to the next hop. Right before packets are forwarded 1065 out to the next hop, FE decrements TTL by 1 and processes any IP 1066 options that cannot be processed before. FE performs any IP 1067 fragmentation if necessary, determines link layer address (e.g., by 1068 ARP), and encapsulates the IP datagram (or each of the fragments 1069 thereof) in an appropriate link layer frame and queues it for output 1070 on the interface selected. 1072 Other options mentioned in RFC1812 for IP forwarding may also be 1073 implemented at FEs, for example, packet filtering. 1075 FEs typically forward packets destined locally to CEs. FEs may also 1076 forward exceptional packets (packets that FEs don't know how to 1077 handle) to CEs. CEs are required to handle packets forwarded by FEs 1078 for whatever different reasons. It might be necessary for ForCES to 1079 attach some meta-data with the packets to indicate the reasons of 1080 forwarding from FEs to CEs. Upon receiving packets with meta-data 1081 from FEs, CEs can decide to either process the packets themselves, 1082 or pass the packets to the upper layer protocols including routing 1083 and management protocols. If CEs are to process the packets by 1084 themselves, CEs may choose to discard the packets, or modify and re- 1085 send the packets. CEs may also originate new packets and deliver 1086 them to FEs for further forwarding. 1088 Any state change during router operation must also be handled 1089 correctly according to RFC1812. For example, when an FE ceases 1090 forwarding, the entire NE may continue forwarding packets, but it 1091 needs to stop advertising routes that are affected by the failed FE. 1093 5.5.Transport Layer 1095 Transport layer is typically implemented at CEs to support higher 1096 layer application protocols like routing protocols. In practice, 1097 this means that most CEs implement both the Transmission Control 1098 Protocol (TCP) and the User Datagram Protocol (UDP). 1100 Both CEs and FEs need to implement ForCES protocol. If some layer-4 1101 transport is used to support ForCES, then both CEs and FEs need to 1102 implement the L4 transport and ForCES protocols. It is possible 1103 that all FEs inside an NE implements only one such protocol entity. 1105 5.6. Application Layer -- Routing Protocols 1107 Interior and exterior routing protocols are implemented on CEs. The 1108 routing packets originated by CEs are forwarded to FEs for delivery. 1109 The results of such protocols (like forwarding table updates) are 1110 communicated to FEs via ForCES. 1112 For performance or scalability reasons, portions of the control 1113 plane functions that need faster response may be moved from the CEs 1114 and off-loaded onto the FEs. For example in OSPF, the Hello 1115 protocol packets are generated and processed periodically. When 1116 done at CEs, the inbound Hello packets have to traverse from the 1117 external interfaces at the FEs to the CEs via the internal CE-FE 1118 channel. Similarly, the outbound Hello packets have to go from the 1119 CEs to the FEs and to the external interfaces. Frequent Hello 1120 updates place heavy processing overhead on the CEs and can overwhelm 1121 the CE-FE channel as well. Since typically there are far more FEs 1122 than CEs in a router, the off-loaded Hello packets are processed in 1123 a much more distributed and scalable fashion. By expressing such 1124 off-loaded functions in the FE model, we can ensure 1125 interoperability. 1127 5.7. Application Layer -- Network Management Protocol 1129 RFC1812 also dictates "Routers MUST be manageable by SNMP." (see 1130 [4] Section 8) In general, for post-association phase, most external 1131 management tasks (including SNMP) should be done through interaction 1132 with the CE in order to support the appearance of a single 1133 functional device. Therefore, it is recommended that SNMP 1134 management agent be implemented by CEs and the SNMP messages 1135 received by FEs be redirected to their CEs. AgentX framework 1136 defined in RFC2741 ([5]) may be applied here such that CEs act in 1137 the role of master agent to process SNMP protocol messages while FEs 1138 act in the role of subagent to provide access to the MIB objects 1139 residing on FEs. AgentX protocol messages between the master agent 1140 (CE) and the subagent (FE) are encapsulated and transported via 1141 ForCES, just like data packets from any other application layer 1142 protocols. 1144 6. Summary 1146 This document defines an architectural framework for ForCES. It 1147 identifies the relevant components for a ForCES network element, 1148 including (one or more) FEs, (one or more) CEs, one optional FE 1149 manager, and one optional CE manager. It also identifies the 1150 interaction among these components and discusses all the major 1151 reference points. It is important to point out that, among all the 1152 reference points, only the interface between CEs and FEs is within 1153 the scope of ForCES. ForCES alone may not be enough to support all 1154 desirablet NE configurations. However, we believe that ForCES is 1155 the most important element in realizing physical separation and 1156 interoperability of CEs and FEs, and hence the first interface that 1157 ought to be standardized. Simple and useful configurations can 1158 still be implemented with only CE-FE interface being standardized, 1159 e.g., single CE with full-meshed FEs and static configuration 1160 without the need for CE/FE managers. 1162 7. Normative References 1164 [1] F. Baker, "Requirements for IP Version 4 Routers", RFC1812, June 1165 1995. 1167 [2] S. Floyd, "Congestion Control Principles", RFC2914, September 1168 2000. 1170 [3] H. Khosravi, et. al., "Requirements for Separation of IP Control 1171 and Forwarding", work in progress, Oct 2002, . 1174 8. Informative References 1176 [4] J. Case, et. al., "A Simple Network Management Protocol (SNMP)", 1177 RFC1157, May 1990. 1179 [5] M. Daniele, et. al., "Agent Extensibility (AgentX) Protocol 1180 Version 1", RFC2741, Jan 2000. 1182 [6] K. Chan, et. al., "COPS Usage for Policy Provisioning (COPS- 1183 PR)", RFC3084, March 2001. 1185 [7] A. Crouch, et. al., "ForCES Applicability Statement", work in 1186 progress, June 2002, . 1188 9. Security Considerations 1190 The security necessary across each reference point except Fp is 1191 discussed throughout the document. In general, the physical 1192 separation of two entities usually requires much stricter security 1193 measurement in place. For example, we pointed out in Section 5.1 1194 that authentication becomes necessary between CE manager and FE 1195 manager, between CE and CE manager, between FE and FE manager in 1196 some configuration. The physical separation of CE and FE also 1197 imposes serious security requirement for ForCES protocol. The 1198 security requirements for reference point Fp (i.e., ForCES protocol) 1199 are discussed in detail in [3] Section 8. 1201 10. Acknowledgments 1203 Joel M. Halpern gave us many insightful comments and suggestions and 1204 pointed out several major issues. T. Sridhar suggested that the 1205 AgentX protocol could be used with SNMP to manage the ForCES network 1206 elements. Many of our colleagues and people in the ForCES mailing 1207 list also provided valuable feedback. 1209 11. Authors' Addresses 1211 Lily L. Yang 1212 Intel Corp., MS JF3-206, 1213 2111 NE 25th Avenue 1214 Hillsboro, OR 97124 USA 1215 Phone: +1 503 264 8813 1216 Email: lily.l.yang@intel.com 1218 Ram Dantu 1219 University of Texas Dallas 1220 2601 North Flyod Road 1221 Richardson Texas 75082 1222 Phone: +1 972 883 4653 1223 Email: ram.dantu@utdallas.edu 1225 Todd A. Anderson 1226 Intel Corp. 1227 2111 NE 25th Avenue 1228 Hillsboro, OR 97124 USA 1229 Phone: +1 503 712 1760 1230 Email: todd.a.anderson@intel.com 1232 12. Intellectual Property Right 1234 The authors are not aware of any intellectual property right issues 1235 pertaining to this document. 1237 13. Full Copyright Statement 1238 Copyright (C) The Internet Society (2002). All Rights Reserved. 1240 This document and translations of it may be copied and furnished to 1241 others, and derivative works that comment on or otherwise explain it 1242 or assist in its implementation may be prepared, copied, published 1243 and distributed, in whole or in part, without restriction of any 1244 kind, provided that the above copyright notice and this paragraph 1245 are included on all such copies and derivative works. However, this 1246 document itself may not be modified in any way, such as by removing 1247 the copyright notice or references to the Internet Society or other 1248 Internet organizations, except as needed for the purpose of 1249 developing Internet standards in which case the procedures for 1250 copyrights defined in the Internet Standards process must be 1251 followed, or as required to translate it into languages other than 1252 English. 1254 The limited permissions granted above are perpetual and will not be 1255 revoked by the Internet Society or its successors or assigns. 1256 This document and the information contained herein is provided on an 1257 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1258 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1259 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1260 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1261 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."