idnits 2.17.1 draft-ietf-forces-requirements-00.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 10 longer pages, the longest (page 8) being 68 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 436 has weird spacing: '...contain infor...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2001) is 8228 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC-2119' is mentioned on line 49, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'REQ-PART' Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft T. Anderson 3 Expiration: April 2002 Intel 4 File: draft-ietf-forces-requirements-00.txt E. Bowen 5 Working Group: ForCES IBM 6 R. Dantu 7 Netrake Inc. 8 A. Doria 9 Nortel Networks 10 J. Hadi Salim 11 Znyx Networks 12 H. Khosravi 13 Intel 14 M. Minhazuddin 15 Avaya Inc. 16 M. Wasserman 17 Wind River 18 October 2001 20 Requirements for Separation of IP Control and Forwarding 22 draft-ietf-forces-requirements-00.txt 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026. Internet-Drafts are 28 working documents of the Internet Engineering Task Force (IETF), 29 its areas, and its working groups. Note that other groups may 30 also distribute working documents as Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other 34 documents at any time. It is inappropriate to use Internet-Drafts 35 as reference material or to cite them other than as ``work in 36 progress.'' 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 Conventions used in this document 46 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 47 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 48 this document are to be interpreted as described in [RFC-2119]. 50 1. Abstract 52 This document defines a set of requirements for mechanisms to 53 logically separate the control and data forwarding planes of an IP 54 network device. 56 2. Definitions 58 Addressable Entity (AE) - A physical device that is directly 59 addressable given some interconnect technology. For example, on 60 Ethernet, an AE is a device to which we can communicate using an 61 Ethernet MAC address; on IP networks, it is a device to which we can 62 communicate using an IP address; and on a switch fabric, it is a 63 device to which we can communicate using a switch fabric port 64 number. 66 Physical Forwarding Element (PFE) - An AE that includes hardware 67 used to provide per-packet processing and handling. This hardware 68 may consist of (but is not limited to) network processors, ASIC's, 69 or general-purpose processors. For example, line cards in a 70 forwarding backplane are PFEs. 72 PFE Partition - A logical partition of a PFE consisting of some 73 subset of each of the resources (e.g., ports, memory, forwarding 74 table entries) available on the PFE. This concept is analogous to 75 that of the resources assigned to a virtual router [REQ-PART]. 77 Physical Control Element (PCE) - An AE that includes hardware used 78 to provide control functionality. This hardware typically includes 79 a general-purpose processor. 81 PCE Partition - A logical partition of a PCE consisting of some 82 subset of each of the resources available on the PCE. 84 Forwarding Element (FE) - A logical entity that implements the 85 ForCES protocol. FEs use the underlying hardware to provide per- 86 packet processing and handling as directed by a CE via the ForCES 87 protocol. FEs may use PFE partitions, whole PFEs, or multiple PFEs. 89 Proxy FE - A name for a type of FE that cannot directly modify its 90 underlying hardware but instead manipulates that hardware using some 91 intermediate form of communication (e.g., a non-ForCES protocol or 92 DMA). A proxy FE will typically be used in the case where a PFE 93 cannot implement (e.g., due to the lack of a general purpose CPU) 94 the ForCES protocol directly. 96 Control Element (CE) - A logical entity that implements the ForCES 97 protocol and uses it to instruct one or more FEs as to how they 98 should process packets. CEs handle functionality such as the 99 execution of control and signaling protocols. CEs may encompass PCE 100 partitions or whole PCEs. (Whether CEs may encompass multiple PCEs 101 or not is an open issue discussed further in Section A.4.) 103 Pre-association Phase - The period of time during which a FE does 104 not know which CE is to control it and vice versa. 106 Post-association Phase - The period of time during which a FE does 107 know which CE is to control it and vice versa. 109 ForCES Protocol - While there may be multiple protocols used within 110 the overall ForCES architecture, the term "ForCES protocol" refers 111 only to the ForCES post-association phase protocol (see below). 113 ForCES Post-Association Phase Protocol - The protocol used for post- 114 association phase communication between CEs and FEs. This protocol 115 does not apply to CE-to-CE communication, FE-to-FE communication, or 116 to communication between FE and CE managers. The ForCES protocol is 117 a master-slave protocol in which FEs are slaves and CEs are masters. 119 FE Model - A model that describes the logical processing functions 120 of a FE. 122 FE Manager - A logical entity that operates in the pre-association 123 phase and is responsible for determining to which CE(s) a FE should 124 communicate. This determination process is called CE discovery and 125 may involve the FE manager learning the capabilities of available 126 CEs. A FE manager may use anything from a static configuration to a 127 pre-association phase protocol (see below) to determine which CE to 128 use. Being a logical entity, a FE manager might be physically 129 combined with any of the other logical entities mentioned in this 130 section. 132 CE Manager - A logical entity that operates in the pre-association 133 phase and is responsible for determining to which FE(s) a CE should 134 communicate. This determination process is called FE discovery and 135 may involve the CE manager learning the capabilities of available 136 FEs. A CE manager may use anything from a static configuration to a 137 pre-association phase protocol (see below) to determine which FE to 138 use. Being a logical entity, a CE manager might be physically 139 combined with any of the other logical entities mentioned in this 140 section. 142 Pre-association Phase Protocol - A protocol between FE managers and 143 CE managers that helps them determine which CEs or FEs to use. A 144 pre-association phase protocol may include a CE and/or FE capability 145 discovery mechanism. It is important to note that this capability 146 discovery process is wholly separate from (and does not replace) 147 that used within the ForCES protocol (see Section 7, requirement 148 #1). However, the two capability discovery mechanisms may utilize 149 the same FE model (see Section 6). Pre-association phase protocols 150 are not discussed further in this document (see Section 11.3). 152 ForCES Network Element (NE) - An entity composed of one or more CEs 153 and one or more FEs. To entities outside a NE, the NE represents a 154 single point of management. Similarly, a NE usually hides its 155 internal organization from external entities. However, one 156 exception to this rule is that CEs and FEs may be directly managed 157 to transition them from the pre-association phase to the post- 158 association phase. 160 ForCES Protocol Element - A FE or CE. 162 High Touch Capability - This term will be used to apply to the 163 capabilities found in some forwarders to take action on the contents 164 or headers of a packet based on content other than what is found in 165 the IP header. Examples of these capabilities include NAT-PT, 166 firewall, and L7 content recognition. 168 3. Introduction 170 An IP network element is composed of numerous logically separated 171 entities that cooperate to provide a given functionality (such as a 172 routing or IP switching) and yet appear as a normal integrated 173 network element to external entities. Two primary types of network 174 element components exist: control-plane components and forwarding- 175 plane components. In general, forwarding-plane components are ASIC, 176 network-processor, or general-purpose processor-based devices that 177 handle all data path operations. Conversely, control-plane 178 components are typically based on general-purpose processors that 179 provide control functionality such as the processing of routing or 180 signaling protocols. A standard set of mechanisms for connecting 181 these components would provide increased scalability and allow the 182 control and forwarding planes to evolve independently thus promoting 183 faster innovation. 185 For the purpose of illustration, let us consider the architecture of 186 a router to illustrate the concept and value of separate control and 187 forwarding planes. The architecture of a router is composed of two 188 main parts. These components, while inter-related, perform 189 functions that are largely independent of each other. At the bottom 190 is the forwarding path that operates in the data-forwarding plane 191 and is responsible for per-packet processing and forwarding. Above 192 the forwarding plane is the network operating system that is 193 responsible for operations in the control plane. In the case of a 194 router or switch, the network operating system runs routing, 195 signaling and control protocols (e.g., RIP, OSPF and RSVP) and 196 dictates the forwarding behavior by manipulating forwarding tables, 197 per-flow QoS tables and access control lists. Typically, the 198 architecture of these devices combines all of this functionality 199 into a single functional whole with respect to external entities. 201 4. Architecture 203 The chief components of a NE architecture are the CE, the FE, and 204 the interconnect protocol. The CE is mainly responsible for 205 operations such as signaling and control protocol processing and the 206 implementation of management protocols. Based on the information 207 acquired through control processing, the CE dictates the packet- 208 forwarding behavior of its FE(s) via the interconnect protocol. For 209 example, the CE might control a FE by manipulating its forwarding 210 tables, the state of its interfaces, or by adding or removing a NAT 211 binding. 213 The FE operates in the forwarding plane and is responsible chiefly 214 for per-packet processing and handling. By allowing the control and 215 forwarding planes to evolve independently, we expect different types 216 of FEs to be developed - some general purpose and others more 217 specialized. Some functions that FEs could perform include layer 3 218 forwarding, metering, shaping, firewall, NAT, encapsulation (e.g., 219 tunneling), decapsulation, encryption, accounting, etc. Nearly all 220 combinations of these functions may be present in practical FEs. 222 Below is a diagram illustrating an example NE composed of a CE and 223 two FEs. 225 -------------------------------- 226 | NE | 227 | ------------- | 228 | | CE | | 229 | ------------- | 230 | / \ | 231 | / \ | 232 | / \ | 233 | / \ | 234 | ----------- ----------- | 235 | | FE | | FE | | 236 | ----------- ----------- | 237 | | | | | | | | | | 238 | | | | | | | | | | 239 | | | | | | | | | | 240 | | | | | | | | | | 241 -------------------------------- 242 | | | | | | | | 243 | | | | | | | | 245 5. Architectural Requirements 247 The following are the architectural requirements: 249 1)CEs and FEs MUST be able to connect by a variety of interconnect 250 technologies. Examples of interconnect technologies used in 251 current architectures include Ethernet connections, backplanes, 252 and ATM (cell) fabrics. FEs MAY be connected to each other via 253 a different technology than that used for CE/FE communication. 255 2)FEs MUST support a minimal set of capabilities necessary for 256 establishing network connectivity (e.g., interface discovery, 257 port up/down functions). Beyond this minimal set, the ForCES 258 architecture MUST NOT restrict the types or numbers of 259 capabilities that FEs may contain. 261 3)Packets MUST be able to arrive at the NE by one FE and leave the 262 NE via a different FE. 264 4)A NE MUST support the appearance of a single functional device. 265 For example, in a router, the TTL of the packet should be 266 decremented only once as it traverses the NE regardless of how 267 many FEs through which it passes. However, external entities 268 (e.g., FE managers and CE managers) MAY have direct access to 269 individual ForCES protocol elements for providing information to 270 transition them from the pre-association to post-association 271 phase. 273 5)The architecture MUST provide a way to prevent unauthorized 274 ForCES protocol elements from joining a NE. 276 6)A FE MUST be able to asynchronously inform the CE of an 277 increase/decrease in available resources or capabilities on the 278 FE. (Since there is not a strict 1-to-1 mapping between FEs and 279 PFEs, it is possible for the relationship between a FE and its 280 physical resources to change over time. For example, the number 281 of physical ports or the amount of memory allocated to a FE may 282 vary over time. The CE needs to be informed of such changes so 283 that it can control the FE in an accurate way.) 285 7)CEs and FEs MUST determine when a loss of connectivity between 286 them has occurred. 288 8)FEs MUST redirect packets addressed to their interfaces to their 289 CE for further processing. Furthermore, FEs MUST redirect other 290 required packets (e.g., such as those with the router alert 291 option set) to their CE as well. (FEs MAY provide any other 292 classification/redirection capabilities that they desire as 293 described in Section 6.4 requirement #4.) Similarly, CEs MUST 294 be able to create packets and have its FEs deliver them. 296 9)All proposed ForCES architectures MUST explain how that 297 architecture may be applied to support all of a router's 298 functions as defined in [RFC1812]. 300 10)In a ForCES NE, the CE(s) MUST be able to learn the topology by 301 which the FEs in the NE are connected. 303 11)The ForCES NE architecture and protocols MUST be capable of 304 supporting at least hundreds of FEs and tens of thousands of 305 ports. 307 6. FE Model Requirements 309 The variety of FE functionality that the ForCES architecture allows 310 poses a potential problem for CEs. In order for a CE to effectively 311 control a FE, the CE must understand at a logical level how the FE 312 processes packets. We therefore REQUIRE that a FE model be created 313 that can express the logical packet processing capabilities of a FE. 314 This model will be used in the ForCES protocol to describe FE 315 capabilities (see Section 7, requirement #1). 317 6.1. Higher-Level FE Model 319 At its higher level, the FE model MUST express what logical 320 functions can be applied to packets as they pass through a FE. 322 Furthermore, the model MUST describe in which order these logical 323 functions may be applied. This ordering is important in many cases. 324 For example, a NAT function may change a packet's source or 325 destination IP address. Any number of other logical functions 326 (e.g., layer 3 forwarding, ingress/egress firewall, shaping, 327 accounting) may make use of the source or destination IP address 328 when making decisions. The CE needs to know whether to configure 329 these logical functions with the pre-NAT or post-NAT IP address. 331 6.2. Lower-Level FE Model 333 At its lower level, the FE model MUST be capable of expressing the 334 data required by each logical function. As the following examples 335 will illustrate, this lower-level data comes in three varieties: 336 classification, action, and parameterization. 338 6.2.1. Classification Data 340 Classification data is the data used by a logical function to 341 perform pattern matching. For example, there may be two FEs, both 342 of which provide an ingress firewall function. However, the first 343 FE may filter on any subset of a (source IP, destination IP, IP 344 protocol, source port, destination port)-tuple whereas the second FE 345 may perform only a (destination IP, IP protocol)-tuple 346 classification. In either case, the action applied to matching 347 packets may be the same, e.g. drop. 349 6.2.2. Action Data 351 Action data is the data needed by a logical function to manipulate 352 the packet as a result of a classification. For example, there may 353 be two traffic-shaping functions, both of which classify only on 354 destination IP address. However, one of the shaping functions may 355 implement a leaky bucket that requires two parameters whereas the 356 other function may implement a token bucket that requires three 357 parameters. 359 6.2.3. Parameterization Data 361 Parameterization data can be viewed as parameters to the logical 362 function itself. This data does not affect individual packets but 363 affects how the function as a whole behaves. For example, there may 364 be a congestion function that implements two varieties of RED that 365 require different parameter sets. Parameterization data would be 366 used to select between the two varieties of RED and to provide the 367 necessary configuration to each variety. 369 6.3. Flexibility 370 Finally, the FE model SHOULD provide a flexible infrastructure in 371 which new logical functions and new classification, action, and 372 parameterization data can be easily added. Also, the FE model MUST 373 be capable of describing the types of statistics gathered by each 374 logical function. 376 6.4. Minimal Set of Logical Functions 378 The rest of this section defines a minimal set of logical functions 379 that any FE model MUST support. This minimal set DOES NOT imply 380 that all FEs must provide this functionality. Instead, these 381 requirements only specify that the model must be capable of 382 expressing the capabilities that FEs may choose to provide. 384 1)Port Functions 385 The FE model MUST be capable of expressing the number of ports on 386 the device, the static attributes of each port (e.g., port type, 387 link speed), and the configurable attributes of each port (e.g., IP 388 address, administrative status). 390 2)Forwarding Functions 391 The FE model MUST be capable of expressing the data that can be used 392 by the forwarding function to make a forwarding decision. 394 3)QoS Functions 395 The FE model MUST allow a FE to express its QoS capabilities in 396 terms of, e.g., metering, policing, shaping, and queuing functions. 398 4)Generic Filtering Functions 399 The FE model MUST be capable of expressing filtering functions. The 400 FE model MUST be capable of expressing a wide range of 401 classification abilities from single fields (e.g., destination 402 address) to arbitrary n-tuples. Similarly, the FE model MUST be 403 capable of expressing what actions these filtering functions can 404 perform on packets that the classifier matches. 406 5)Vendor-Specific Functions 407 The FE model SHOULD be extensible so that vendor-specific 408 functionality can be expressed. 410 6)High-Touch Functions 411 The FE model MUST be capable of expressing the encapsulation and 412 tunneling capabilities of a FE. The FE model MUST support functions 413 that mark the IPv4 header TOS octet or the IPv6 Traffic Class octet. 414 The FE model MAY support other high touch functions (e.g., NAT, 415 ALG). 417 7)Security Functions 418 The FE model MUST be capable of expressing the types of encryption 419 that may be applied to packets in the forwarding path. 421 7. ForCES Protocol Requirements 423 This section specifies the requirements that a ForCES protocol MUST 424 meet. 426 1)Configuration of Modeled Elements 427 The ForCES protocol MUST allow the CE to determine the capabilities 428 of each FE. These capabilities SHALL be expressed using the FE 429 model whose requirements are defined in Section 6. Furthermore, the 430 protocol MUST provide a means for the CE to control all the FE 431 capabilities that are discovered through the FE model. 433 2)Support for Secure Communication 434 Since FE configuration will contain information critical to the 435 functioning of a network (such as IP forwarding tables) and may 436 contain information derived from business relationships (e.g., 437 SLA's), the ForCES protocol MUST support a method of securing 438 communication between FEs and CEs to ensure that information is 439 delivered privately and in an unmodified form. 441 3)Event Notification 442 The ForCES protocol MUST support the sending of asynchronous events 443 (e.g., link up/down, redirected packet, out of memory) from a FE to 444 a CE. 446 8. Security Considerations 448 See architecture requirement #5 and protocol requirement #2. 450 9. References 452 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers", 453 RFC1812, June 1995. 455 [REQ-PART] T. Anderson, C. Wang, J. Buerkle, "Requirements for the 456 Dynamic Partitioning of Network Elements", work in progress, August 457 2001, . 459 10. Authors' Addresses 461 Todd A. Anderson 462 Intel 463 2111 NE 25th Avenue 464 Hillsboro, OR 97124 USA 465 Phone: +1 503 712 1760 466 Email: todd.a.anderson@intel.com 467 Ed Bowen 468 IBM Zurich Research Laboratory 469 Saumerstrasse 4 470 CH-8803 Rueschlikon Switzerland 471 Phone: +41 1 724 83 68 472 Email: edbowen@us.ibm.com 474 Ram Dantu 475 Netrake Corporation 476 3000 Technology Drive, #100, 477 Plano, Texas, 75074 478 rdantu@netrake.com 479 214 291 1111 481 Avri Doria 482 Nortel Networks 483 600 Technology Park Drive 484 Billerica, MA 01821 485 Phone: +1 401 663 5024 486 Email: avri@nortelnetworks.com 488 Jamal Hadi Salim 489 Znyx Networks 490 Ottawa, Ontario 491 Canada 492 Email: hadi@znyx.com 494 Hormuzd Khosravi 495 Intel 496 2111 NE 25th Avenue 497 Hillsboro, OR 97124 USA 498 Phone: +1 503 264 0334 499 Email: hormuzd.m.khosravi@intel.com 501 Muneyb Minhazuddin 502 Avaya Inc. 503 123, Epping road, 504 North Ryde, NSW 2113, Australia 505 Phone: +61 2 9352 8620 506 email: muneyb@avaya.com 508 Margaret Wasserman 509 Wind River 510 10 Tara Blvd., Suite 330 511 Nashua, NH 03062 512 Phone: +1 603 897 2067 513 Email: mrw@windriver.com 515 11. Appendix A - Open Issues 517 This section contains a list of issues on which a requirements 518 consensus has not been reached. 520 11.1. Protocol Issues 522 Some issues surrounding the ForCES protocol include the following. 523 Should ForCES allow for only reliable delivery of messages or should 524 it also allow for unreliable delivery in cases where reliability is 525 not needed? Should the ForCES protocol operate over a variety of 526 transports or should a single transport protocol be used? (It has 527 been mandated that in a multihop environment either TCP or SCTP be 528 used. However, whether we should allow alternative transports for 529 single hops is an open issue.) 531 11.2. Modeling Filtering Functions 533 How arbitrary should we be in describing where filtering (i.e., 534 generic classification/action) may occur in the FE model? 536 11.3. Pre-Association Phase Protocol 538 We believe it is likely that a pre-association phase protocol will 539 be an integral and necessary part of the ForCES architecture but it 540 is not known what, if any, requirements should be placed on this 541 phase or protocol. Furthermore, it has not been resolved as to 542 whether this protocol should be merged with the post-association 543 phase protocol. 545 11.4. Multiple CEs 547 One of the open issues for discussion in the ForCES requirements has 548 to do with creating an NE that is composed of more than one CE or 549 PCE. There are several aspects to this discussion. 551 - There was acceptance of the possibility of an NE having several 552 CEs that provide redundancy. This option however, would be limited 553 to the use of similar CEs, i.e., CEs that provided the same 554 functional control capabilities, and would be used only in a 555 redundancy mode, disallowing load-sharing applications. In effect, 556 in this model there would be only one functioning CE at a time. 558 - There is a fair amount of disagreement over the use of multiple 559 CEs for tasks other than redundancy. Several members of the design 560 team have argued for scenarios where the following was possible: 561 -- Similar CEs used for load sharing 562 -- Dissimilar CEs that provide different capabilities to a set of 563 FEs. For example, one CE could be responsible for IP routing 564 while another was responsible for high-touch capabilities and 565 a third was responsible for VPN's. 567 In the discussions, several issues came up. Among the issues: 569 - If there are multiple CEs, whether similar or dissimilar, would 570 there need to be a master CE that maintained a single control 571 session with each FE. 572 - If there are several similar load sharing CEs, how does the FE 573 deal with multiple conflicting commands. 574 - If there are several similar load sharing CEs, how is the 575 representation of FE state in each of the CEs handled so that all 576 CEs have the same state representation. 577 - If there are several dissimilar CEs, how are cumulative effects 578 handled and how are these effects represented to the CEs. 580 There was some concern in the design team that adding multiple CEs 581 without a master CE would complicate the ForCES protocol 582 unnecessarily. There was also concern that leaving such a 583 capability out would limit the protocol unnecessarily. The design 584 team was not able to reach consensus on this issue. 586 11.5. FE Model Completeness 588 This requirements draft defines a set of logical functions that we 589 believe are necessary to allow basic types of FEs to be created. 590 Whether this set is sufficient to describe all the functionality of 591 any FE is an open issue. If it is not sufficient, the question of 592 what additional logical functions need to be standardized and which 593 functions should be left to individual vendors remains an open 594 issue. 596 11.6. Management 598 The current belief is that a NE is the primary management entity and 599 that direct management access to individual ForCES protocol elements 600 is permitted but only for the purpose of transitioning those 601 elements from the pre-association to the post-association phase. 602 However, there may be other management concerns that require direct 603 access to ForCES elements for other reasons. Thus, the ultimate 604 state of the management model is an open issue.