idnits 2.17.1 draft-ietf-forces-applicability-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 27, 2010) is 5046 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ForCES Working Group A. Crouch 3 Internet-Draft H. Khosravi 4 Intended status: Informational Intel 5 Expires: December 29, 2010 A. Doria (ed.) 6 LTU 7 X. Wang 8 Huawei 9 K. Ogawa 10 NTT Corporation 11 June 27, 2010 13 ForCES Applicability Statement 14 draft-ietf-forces-applicability-09 16 Abstract 18 The ForCES protocol defines a standard framework and mechanism for 19 the interconnection between Control Elements and Forwarding Elements 20 in IP routers and similar devices. In this document we describe the 21 applicability of the ForCES model and protocol. We provide example 22 deployment scenarios and functionality, as well as document 23 applications that would be inappropriate for ForCES. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 29, 2010. 42 Copyright Notice 44 Copyright (c) 2010 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 This document may contain material from IETF Documents or IETF 58 Contributions published or made publicly available before November 59 10, 2008. The person(s) controlling the copyright in some of this 60 material may not have granted the IETF Trust the right to allow 61 modifications of such material outside the IETF Standards Process. 62 Without obtaining an adequate license from the person(s) controlling 63 the copyright in such materials, this document may not be modified 64 outside the IETF Standards Process, and derivative works of it may 65 not be created outside the IETF Standards Process, except to format 66 it for publication as an RFC or to translate it into languages other 67 than English. 69 Table of Contents 71 1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Applicability to IP Networks . . . . . . . . . . . . . . . . . 5 75 4.1. Applicable Services . . . . . . . . . . . . . . . . . . . 5 76 4.1.1. Association, Capability Discovery and Information 77 Exchange . . . . . . . . . . . . . . . . . . . . . . . 5 78 4.1.2. Topology Information Exchange . . . . . . . . . . . . 6 79 4.1.3. Configuration . . . . . . . . . . . . . . . . . . . . 6 80 4.1.4. Routing Exchange . . . . . . . . . . . . . . . . . . . 6 81 4.1.5. QoS Capabilities Exchange and Configuration . . . . . 6 82 4.1.6. Security Exchange . . . . . . . . . . . . . . . . . . 7 83 4.1.7. Filtering Exchange and Firewalls . . . . . . . . . . . 7 84 4.1.8. Encapsulation, Tunneling Exchange . . . . . . . . . . 7 85 4.1.9. NAT and Application-level Gateways . . . . . . . . . . 7 86 4.1.10. Measurement and Accounting . . . . . . . . . . . . . . 7 87 4.1.11. Diagnostics . . . . . . . . . . . . . . . . . . . . . 7 88 4.1.12. Redundancy and Failover . . . . . . . . . . . . . . . 7 89 4.2. CE-FE Link Capability . . . . . . . . . . . . . . . . . . 8 90 4.3. CE/FE Locality . . . . . . . . . . . . . . . . . . . . . . 8 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 92 6. ForCES Manageability . . . . . . . . . . . . . . . . . . . . . 9 93 6.1. NE as an Atomic Element . . . . . . . . . . . . . . . . . 9 94 6.2. NE as Composed of Manageable Elements . . . . . . . . . . 10 95 6.3. ForCES Protocol MIB . . . . . . . . . . . . . . . . . . . 10 96 6.3.1. MIB Management of an FE . . . . . . . . . . . . . . . 10 97 6.4. The FEM and CEM . . . . . . . . . . . . . . . . . . . . . 11 98 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 99 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 100 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 102 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 103 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 106 1. Purpose 108 The purpose of the ForCES Applicability Statement is to capture the 109 intent of the ForCES protocol [RFC5810] designers as to how the 110 protocol could be used in conjunction with the ForCES model [RFC5812] 111 and a Transport Mapping Layer [RFC5811]. 113 2. Overview 115 The ForCES protocol defines a standard framework and mechanism for 116 the exchange of information between the logically separate 117 functionality of the control and data forwarding planes of IP routers 118 and similar devices. It focuses on the communication necessary for 119 separation of control plane functionality such as routing protocols, 120 signaling protocols, and admission control from data forwarding plane 121 per-packet activities such as packet forwarding, queuing, and header 122 editing. 124 This document defines the applicability of the ForCES mechanisms. It 125 describes types of configurations and settings where ForCES is most 126 appropriately applied. This document also describes scenarios and 127 configurations where ForCES would not be appropriate for use. 129 3. Terminology 131 A set of concepts associated with ForCES was introduced in 132 Requirements for Separation of IP Control and Forwarding[RFC3654] and 133 in Forwarding and Control Element Separation (ForCES) 134 Framework[RFC3746]. The terminology associated with these concepts 135 and the protocol elements in ForCES is defined in the Forwarding and 136 Control Element Separation (ForCES) Protocol Specification[RFC5810]. 138 The reader is directed to these documents for the conceptual 139 introduction and the definitions including of the following acronyms: 141 o CE: Control Element 142 o CEM: Control element manager 143 o FE: Forwarding Element 144 o FEM: Forwarding element manager 145 o ForCES: Forwarding and Control Element Separation protocol 146 o LFB: Logical Function Block 147 o NE: ForCES network element 148 o TML: Transport Mapping Layer 150 4. Applicability to IP Networks 152 This section lists the areas of ForCES applicability in IP network 153 devices. Some relatively low-end routing systems may be implemented 154 on simple hardware which performs both control and packet forwarding 155 functionality. ForCES may not be useful for such devices. 157 Higher end routing systems typically distribute work amongst several 158 interface processing elements, and these devices (FEs) therefore need 159 to communicate with the control element(s) to perform their job. A 160 higher end router may also distribute control processing amongst 161 several processing elements (CEs). ForCES provides a standard way to 162 do this communication. ForCES also provides support for High 163 Availability configurations that include a primary CE and one or more 164 secondary CEs. 166 The remainder of this section lists the applicable services which 167 ForCES may support, applicable FE functionality, applicable CE-FE 168 link scenarios, and applicable topologies in which ForCES may be 169 deployed. 171 4.1. Applicable Services 173 In this section we describe the applicability of ForCES for the 174 following control-forwarding plane services: 176 o Association, Capability discovery and Information Exchange 177 o Topology Information Exchange 178 o Configuration 179 o Routing Exchange 180 o QoS Exchange 181 o Security Exchange 182 o Filtering Exchange 183 o Encapsulation/Tunneling Exchange 184 o NAT and Application-level Gateways 185 o Measurement and Accounting 186 o Diagnostics 187 o CE Redundancy or CE Failover 189 4.1.1. Association, Capability Discovery and Information Exchange 191 Association is the first step of the ForCES protocol exchange in 192 which capability discovery and exchange happens between one or more 193 CEs and the FEs. ForCES assumes that CEs and FEs already have 194 sufficient information to begin communication in a secure manner. 195 The ForCES protocol is only applicable after CEs and FEs have 196 discovered each other. ForCES makes no assumption about whether 197 discovery was performed using a dynamic protocol or merely static 198 configuration. Some discussion about how this can occur can be found 199 later in this document in Section 6.4. 201 During the association phase, CEs and FEs exchange capability 202 information with each other. For example, the FEs express the number 203 of interface ports they provide, as well as the static and 204 configurable attributes of each port. 206 In addition to initial configuration, the CEs and FEs also exchange 207 dynamic configuration changes using ForCES. For example, FEs 208 asynchronously inform the CEs of an increase/decrease in available 209 resources or capabilities on the FE. 211 4.1.2. Topology Information Exchange 213 In this context, topology information relates to how the FEs are 214 interconnected with each other with respect to packet forwarding. 215 Topology discovery is outside the scope of the ForCES protocol. An 216 implementation can choose its own method of topology discovery (for 217 example use a standard topology discovery protocol; or apply a static 218 topology configuration policy). Once the topology is established, 219 ForCES protocol may be used to transmit the resulting information to 220 the CEs. 222 4.1.3. Configuration 224 ForCES is used to perform FE configuration. For example, CEs set 225 configurable FE attributes such as IP addresses, etc. for their 226 interfaces. 228 4.1.4. Routing Exchange 230 ForCES may be used to deliver packet forwarding information resulting 231 from CE routing calculations. For example, CEs may send forwarding 232 table updates to the FEs, so that they can make forwarding decisions. 233 FEs may inform the CEs in the event of a forwarding table miss. 234 ForCES may also be used to configure ECMP capability. 236 4.1.5. QoS Capabilities Exchange and Configuration 238 ForCES may be used to exchange QoS capabilities between CEs and FEs. 239 For example, an FE may express QoS capabilities to the CE. Such 240 capabilities might include metering, policing, shaping, and queuing 241 functions. The CE may use ForCES to configure these capabilities. 243 4.1.6. Security Exchange 245 ForCES may be used to exchange Security information between a CE and 246 the FEs it controls. For example, the FE may use ForCES to express 247 the types of encryption that it is capable of using in an IPsec 248 tunnel. The CE may use ForCES to configure such a tunnel. The CEs 249 would be responsible for the NE dynamic key exchanges and updates. 251 4.1.7. Filtering Exchange and Firewalls 253 ForCES may be used to exchange filtering information. For example, 254 FEs may use ForCES to express the filtering functions such as 255 classification and action that they can perform, and the CE may 256 configure these capabilities. 258 4.1.8. Encapsulation, Tunneling Exchange 260 ForCES may be used to exchange encapsulation capabilities of an FE, 261 such as tunneling, and the configuration of such capabilities. 263 4.1.9. NAT and Application-level Gateways 265 ForCES may be used to exchange configuration information for Network 266 Address Translators. Whilst ForCES is not specifically designed for 267 the configuration of application-level gateway functionality, this 268 may be in scope for some types of application-level gateways. 270 4.1.10. Measurement and Accounting 272 ForCES may be used to exchange configuration information regarding 273 traffic measurement and accounting functionality. In this area, 274 ForCES may overlap somewhat with functionality provided by 275 alternative network management mechanisms such as SNMP. In some 276 cases ForCES may be used to convey information to the CE to be 277 reported externally using SNMP. A further discussion of this 278 capability is covered in Section 6 of this document. 280 4.1.11. Diagnostics 282 ForCES may be used for CEs and FEs to exchange diagnostic 283 information. For example, an FE can send self-test results to a CE. 285 4.1.12. Redundancy and Failover 287 The ForCES architecture includes mechanisms which allow for multiple 288 redundant CEs and FEs in a ForCES NE. The ForCES model LFB 289 definitions provide sufficient component details via component 290 identifiers to be universally unique within an NE. The ForCES 291 protocol includes mechanisms to facilitate transactions as well as 292 atomicity across the NE. 294 Given the above it is possible to deploy redundant CEs and FEs which 295 incorporate failover. 297 4.2. CE-FE Link Capability 299 When using ForCES, the bandwidth of the CE-FE link is a 300 consideration, and cannot be ignored. For example, sending a full 301 routing table is reasonable over a high bandwidth link, but could be 302 non-trivial over a lower-bandwidth link. ForCES should be 303 sufficiently future-proof to be applicable in scenarios where routing 304 tables grow to several orders of magnitude greater than their current 305 size. However, we also note that not all IP routers need full 306 routing tables. 308 4.3. CE/FE Locality 310 ForCES is intended for environments where one of the following 311 applies: 313 o The control interconnect is some form of local bus, switch, or 314 LAN, where reliability is high, closely controlled, and not 315 susceptible to external disruption that does not also affect the 316 CEs and/or FEs. 317 o The control interconnect shares fate with the FE's forwarding 318 function. Typically this is because the control connection is 319 also the FE's primary packet forwarding connection, and so if that 320 link goes down, the FE cannot forward packets anyway. 322 The key guideline is that the reliability of the device should not be 323 significantly reduced by the separation of control and forwarding 324 functionality. 326 Taking this into account, ForCES is applicable in the following CE/FE 327 localities: 329 Single Box NE: chassis with multiple CEs and FEs setup. ForCES is 330 applicable in localities consisting of control and forwarding 331 elements which are components in the same physical box. 333 Example: a network element with a single control blade, and one or 334 more forwarding blades, all present in the same chassis and 335 sharing an interconnect such as Ethernet or PCI. In this 336 locality, the majority of the data traffic being forwarded 337 typically does not traverse the same links as the ForCES control 338 traffic. 340 Multiple Box NE: separated CE and FE where physical locality could 341 be same rack, room, building, or long distance which could span 342 across continents and oceans. ForCES is applicable in localities 343 consisting of control and forwarding elements which are separated 344 by a single hop or multiple hops in the network. 346 5. Security Considerations 348 The ForCES protocol allows for a variety of security levels 349 [RFC5810]. When operating under a secured physical environment, or 350 for other operational concerns (in some cases performance issues) the 351 operator may turn off all the security functions between CEs and FEs. 352 When the operator makes a decision to secure the path between the FEs 353 and CEs then the operator chooses from one of the options provided by 354 the TML. Security choices provided by the TML take effect during the 355 pre-association phase of the ForCES protocol. An operator may choose 356 to use all, some or none of the security services provided by the TML 357 in a CE-FE connection. A ForCES NE is required to provide CE/FE node 358 authentication services, and may provide message integrity and 359 confidentially services. The NE may provide these services by 360 employing IPsec or TLS depending on the choice of TML used in the 361 deployment of the NE. 363 6. ForCES Manageability 365 From the architectural perspective, the ForCES NE is a single network 366 element; as an example if the ForCES NE is specifically a router that 367 needs to be managed, then it should be managed in essentially the 368 same way any router should be managed. From another perspective 369 element management could view the individual entities and interfaces 370 that make up a ForCES NE but this may cause risk on the control 371 relationship between the CEs and the FEs unless it has been accounted 372 for in the model used by the NE. 374 6.1. NE as an Atomic Element 376 From the ForCES requirements [RFC3654] Section 4, point 4: 378 A NE must support the appearance of a single functional device. 380 As a single functional device a ForCES NE runs protocols and each of 381 the protocols has it own existing manageability aspects that are 382 documented elsewhere. As an example, router would also have a 383 configuration interface. When viewed in this manner, the NE is 384 controlled as a single routing entity and no new management beyond 385 what is already available for routers and routing protocols would be 386 required for a ForCES NE. Management commands on a management 387 interface to the NE will arrive at the CE and may require ForCES 388 interactions between the CE and FEs to complete. This may impact the 389 atomicity of such commands and may require careful implementation by 390 the CE. 392 6.2. NE as Composed of Manageable Elements 394 When viewed as a decomposed set of elements from the management 395 perspective, the ForCES NE is divided into a set of one of more 396 Control Elements, Forwarding Elements and the interfaces between 397 them. The interface functionality between the CE and the FE is 398 provided by the ForCES protocol. A MIB module is provided for the 399 purpose of gaining management information on the operation of the 400 protocol describe in Section 6.3 of this document. 402 Additionally the architecture makes provision for configuration 403 control of the individual CEs and FEs. This is handled by elements 404 named FE manager (FEM) and the CE manager (CEM). Specifically from 405 the ForCES requirements RFC [RFC3654], Section 4, point 4: 407 However, external entities (e.g., FE managers and CE managers) may 408 have direct access to individual ForCES protocol elements for 409 providing information to transition them from the pre-association to 410 post-association phase. 412 6.3. ForCES Protocol MIB 414 The ForCES MIB [RFC5813] defines a primarily read-only MIB module 415 that captures information related to the ForCES protocol. This 416 includes state information about the associations between CE(s) and 417 FE(s) in the NE. 419 The ForCES MIB does not include information that is specified in 420 other MIB modules, such as packet counters for interfaces, etc. 422 More specifically, the information in the ForCES MIB module relative 423 to associations includes: 425 o identifiers of the elements in the association 426 o state of the association 427 o configuration parameters of the association 428 o statistics of the association 430 6.3.1. MIB Management of an FE 432 While it is possible to manage a FE from an element manager, several 433 requirements relating to this have been included in the ForCES 434 Requirements. 436 From the ForCES Requirements [RFC3654], Section 4, point 14: 438 1. The ability for a management tool (e.g., SNMP) to be used to read 439 (but not change) the state of FE should not be precluded. 440 2. It must not be possible for management tools (e.g., SNMP, etc) to 441 change the state of a FE in a manner that affects overall NE 442 behavior without the CE being notified. 444 The ForCES Requirements [RFC3654], Section 5.7, goes further in 445 discussing the manner in which FEs should handle management requests 446 that are specifically directed to the FE: 448 For a ForCES NE that is an IP router, [RFC1812] also dictates that 449 "Routers must be manageable by SNMP". In general, for the post- 450 association phase, most external management tasks (including SNMP) 451 should be done through interaction with the CE in order to support 452 the appearance of a single functional device. Therefore, it is 453 recommended that an SNMP agent be implemented by CEs and that the 454 SNMP messages received by FEs be redirected to their CEs. AgentX 455 framework defined in [RFC2741]) may be applied here such that CEs act 456 in the role of master agent to process SNMP protocol messages while 457 FEs act in the role of sub-agent to provide access to the MIB objects 458 residing on FEs. AgentX protocol messages between the master agent 459 (CE) and the sub-agent (FE) are encapsulated and transported via 460 ForCES, just like data packets from any other application layer 461 protocols. 463 6.4. The FEM and CEM 465 Though out of scope for the initial ForCES specification effort, the 466 ForCES architecture include two entities, the CE Manager (CEM) and 467 the FE Manager (FEM). From the ForCES Protocols Specification 468 [RFC5810]. 470 CE Manager (CEM) - A logical entity responsible for generic CE 471 management tasks. It is particularly used during the pre- 472 association phase to determine with which FE(s) a CE should 473 communicate. 474 FE Manager (FEM) - A logical entity responsible for generic FE 475 management tasks. It is used during pre-association phase to 476 determine with which CE(s) an FE should communicate. 478 7. Contributors 480 Mark Handley was an initial author involved in the earlier versions 481 of this document. 483 8. IANA Considerations 485 This document has no IANA actions. 487 [RFC Editor: please remove this section prior to publication.] 489 9. Acknowledgments 491 Many of the participants in the ForCES as well as fellow employees of 492 the authors, have provided valuable input into this work. Particular 493 thanks go to Jamal Hadi Salim, our WG chair and document shepherd and 494 to Adrian Farrel the AD for the area for their review, comments and 495 encouragement without whom this document might never have been 496 completed. 498 10. References 500 10.1. Normative References 502 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 503 June 1995. 505 [RFC5810] Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, 506 W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and 507 Control Element Separation (ForCES) Protocol 508 Specification", RFC 5810, March 2010. 510 [RFC5811] Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport Mapping 511 Layer (TML) for the Forwarding and Control Element 512 Separation (ForCES) Protocol", March 2010. 514 [RFC5812] Halpern, J. and J. Hadi Salim, "Forwarding and Control 515 Element Separation (ForCES) Forwarding Element Model", 516 RFC 5812, March 2010. 518 [RFC5813] Haas, R., "Forwarding and Control Element Separation 519 (ForCES) MIB", RFC 5813, March 2010. 521 10.2. Informative References 523 [RFC2741] Daniele, M., Wijnen, B., Ellison, M., and D. Francisco, 524 "Agent Extensibility (AgentX) Protocol Version 1", 525 January 2000. 527 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 528 of IP Control and Forwarding", RFC 3654, November 2003. 530 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 531 "Forwarding and Control Element Separation (ForCES) 532 Framework", RFC 3746, April 2004. 534 Authors' Addresses 536 Alan Crouch 537 Intel 538 2111 NE 25th Avenue 539 Hillsboro, OR 97124 USA 540 USA 542 Phone: +1 503 264 2196 543 Email: alan.crouch@intel.com 545 Hormuzd Khosravi 546 Intel 547 2111 NE 25th Avenue 548 Hillsboro, OR 97124 USA 549 USA 551 Phone: 1-503-264-0334 552 Email: hormuzd.m.khosravi@intel.com 554 Avri Doria 555 LTU 556 Lulea University of Technology 557 Sweden 559 Phone: +46 73 277 1788 560 Email: avri@acm.org 562 Xin-ping Wang 563 Huawei 564 Beijing 565 China 567 Phone: +86 10 82836067 568 Email: carly.wang@huawei.com 569 Kentaro Ogawa 570 NTT Corporation 571 3-9-11 Midori-cho 572 Musashino-shi, Tokyo 180-8585 573 Japan 575 Email: ogawa.kentaro@lab.ntt.co.jp