idnits 2.17.1 draft-ietf-forces-applicability-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 (February 22, 2010) is 5174 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 136 -- Looks like a reference, but probably isn't: '4' on line 136 -- Looks like a reference, but probably isn't: '6' on line 450 == Missing Reference: 'RFC 3654' is mentioned on line 439, but not defined -- Looks like a reference, but probably isn't: '2' on line 443 == Unused Reference: 'RFC2629' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 515, but no explicit reference was found in the text == Unused Reference: 'RFC3746' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC3015' is defined on line 524, but no explicit reference was found in the text == Unused Reference: 'RFC3292' is defined on line 528, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3015 (Obsoleted by RFC 3525) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 forces A. Crouch 3 Internet-Draft H. Khosravi 4 Intended status: Informational Intel 5 Expires: August 26, 2010 A. Doria 6 LTU 7 X. Wang 8 Huawei 9 K. Ogawa 10 NTT Corporation 11 February 22, 2010 13 ForCES Applicability Statement 14 draft-ietf-forces-applicability-08 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 to IETF 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), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 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 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on August 26, 2010. 48 Copyright Notice 49 Copyright (c) 2010 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 4. Applicability to IP Networks . . . . . . . . . . . . . . . . . 4 80 4.1. Applicable Services . . . . . . . . . . . . . . . . . . . 5 81 4.1.1. Discovery, Capability Information Exchange . . . . . . 5 82 4.1.2. Topology Information Exchange . . . . . . . . . . . . 6 83 4.1.3. Configuration . . . . . . . . . . . . . . . . . . . . 6 84 4.1.4. Routing Exchange . . . . . . . . . . . . . . . . . . . 6 85 4.1.5. QoS Exchange . . . . . . . . . . . . . . . . . . . . . 6 86 4.1.6. Security Exchange . . . . . . . . . . . . . . . . . . 6 87 4.1.7. Filtering Exchange and Firewalls . . . . . . . . . . . 7 88 4.1.8. Encapsulation, Tunneling Exchange . . . . . . . . . . 7 89 4.1.9. NAT and Application-level Gateways . . . . . . . . . . 7 90 4.1.10. Measurement and Accounting . . . . . . . . . . . . . . 7 91 4.1.11. Diagnostics . . . . . . . . . . . . . . . . . . . . . 7 92 4.1.12. Redundancy and Failover . . . . . . . . . . . . . . . 7 93 4.2. CE-FE Link Capability . . . . . . . . . . . . . . . . . . 8 94 4.3. CE/FE Locality . . . . . . . . . . . . . . . . . . . . . . 8 95 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 96 6. ForCES Manageability . . . . . . . . . . . . . . . . . . . . . 9 97 6.1. NE as an atomic element . . . . . . . . . . . . . . . . . 9 98 6.2. NE as composed of manageable elements . . . . . . . . . . 9 99 6.3. ForCES Protocol MIB . . . . . . . . . . . . . . . . . . . 10 100 6.3.1. MIB Management of an FE . . . . . . . . . . . . . . . 10 101 6.4. The FEM and CEM . . . . . . . . . . . . . . . . . . . . . 11 102 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 104 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 106 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 107 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 110 1. Purpose 112 The purpose of the ForCES Applicability Statement is to capture the 113 intent of the ForCES protocol [I-D.ietf-forces-protocol] designers as 114 to how the protocol could be used (in conjunction with the ForCES 115 model [I-D.ietf-forces-model]). 117 2. Overview 119 The ForCES protocol defines a standard framework and mechanism for 120 the exchange of information between the logically separate 121 functionality of the control and data forwarding planes of IP routers 122 and similar devices. It focuses on the communication necessary for 123 separation of control plane functionality such as routing protocols, 124 signaling protocols, and admission control from data forwarding plane 125 per-packet activities such as packet forwarding, queuing, and header 126 editing. 128 This document defines the applicability of the ForCES mechanisms. It 129 describes types of configurations and settings where ForCES is most 130 appropriately applied. This document also describes scenarios and 131 configurations where ForCES would not be appropriate for use. 133 3. Terminology 135 A set of terminology associated with ForCES is defined in [3, 4]. 136 That terminology is reused here and the reader is directed to [3, 4] 137 for the following definitions: 139 o CE: Control Element. 141 o FE: Forwarding Element. 143 o ForCES: ForCES protocol. 145 o TML: Transport Mapping Layer. 147 4. Applicability to IP Networks 149 The purpose of this section is to list the areas of ForCES 150 applicability in IP network devices. Relatively low end routing 151 systems may be implemented on simple hardware which performs both 152 control and packet forwarding functionality. ForCES may not make 153 sense for such devices. 155 Higher end routing systems typically distribute work amongst 156 interface processing elements, and these devices (FEs) therefore need 157 to communicate with the control element(s) to perform their job. 158 ForCES provides a standard way to do this communication. 160 The remainder of this section lists the applicable services which 161 ForCES may support, applicable FE functionality, applicable CE-FE 162 link scenarios, and applicable topologies in which ForCES may be 163 deployed. 165 4.1. Applicable Services 167 In this section we describe the applicability of ForCES for the 168 following control-forwarding plane services: 170 o Discovery, Capability Information Exchange 172 o Topology Information Exchange 174 o Configuration 176 o Routing Exchange 178 o QoS Exchange 180 o Security Exchange 182 o Filtering Exchange 184 o Encapsulation/Tunneling Exchange 186 o NAT and Application-level Gateways 188 o Measurement and Accounting 190 o Diagnostics 192 o CE Redundancy or CE Failover 194 4.1.1. Discovery, Capability Information Exchange 196 Discovery is the process by which CEs and FEs learn of each other's 197 existence. ForCES assumes that CEs and FEs already know sufficient 198 information to begin communication in a secure manner. The ForCES 199 protocol is only applicable after CEs and FEs have found each other. 200 ForCES makes no assumption about whether discovery was performed 201 using a dynamic protocol or merely static configuration. 203 During the discovery phase, CEs and FEs exchange capability 204 information with each other. For example, the FEs express the number 205 of interface ports they provide, as well as the static and 206 configurable attributes of each port. 208 In addition to initial configuration, the CEs and FEs also exchange 209 dynamic configuration changes using ForCES. For example, FEs 210 asynchronously inform the CE of an increase/decrease in available 211 resources or capabilities on the FE. 213 4.1.2. Topology Information Exchange 215 In this context, topology information relates to how the FEs are 216 interconnected with each other with respect to packet forwarding. 217 Topology discovery is outside the scope of the ForCES protocol. An 218 implementation can choose its own method of topology discovery (for 219 example use a standard topology discovery protocol like LLDP, BFD; or 220 apply a static topology configuration policy). Once the topology is 221 established, ForCES protocol may be used to transmit the resulting 222 information to the CE. 224 4.1.3. Configuration 226 ForCES is used to perform FE configuration. For example, CEs set 227 configurable FE attributes such as IP addresses, etc. for their 228 interfaces. 230 4.1.4. Routing Exchange 232 ForCES may be used to deliver packet forwarding information resulting 233 from CE routing calculations. For example, CEs may send forwarding 234 table updates to the FEs, so that they can make forwarding decisions. 235 FEs may inform the CE in the event of a forwarding table miss. 237 4.1.5. QoS Exchange 239 ForCES may be used to exchange QoS capabilities between CEs and FEs. 240 For example, an FE may express QoS capabilities to the CE. Such 241 capabilities might include metering, policing, shaping, and queuing 242 functions. The CE may use ForCES to configure these capabilities. 244 4.1.6. Security Exchange 246 ForCES may be used to exchange Security information between CEs and 247 FEs. For example, the FE may use ForCES to express the types of 248 encryption that it is capable of using in an IPsec tunnel. The CE 249 may use ForCES to configure such a tunnel. 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. 279 4.1.11. Diagnostics 281 ForCES may be used for CEs and FEs to exchange diagnostic 282 information. For example, an FE can send self-test results to the 283 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 LAN, 314 where reliability is high, closely controlled, and not susceptible to 315 external disruption that does not also affect the 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 also 319 the FE's primary packet forwarding connection, and so if that link 320 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 o 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 sharing 335 an interconnect such as Ethernet or PCI. In this locality, the 336 majority of the data traffic being forwarded typically does not 337 traverse the same links as the ForCES control traffic. 339 o multiple boxes: separated CE and FE where physical locality could 340 be same rack, room, building, or long distance which could span 341 across continents and oceans. ForCES is applicable in localities 342 consisting of control and forwarding elements which are separated by 343 a single hop or multiple hops in the network. 345 5. Security Considerations 347 The ForCES architecture allows for a variety of security levels[6]. 348 When operating under a secured physical environment, or for other 349 operational concerns (in some cases performance issues) the operator 350 may turn off all the security functions between CE and FE. When the 351 operator makes a decision to secure the path between the FE and CE 352 then the operator chooses from one of the options provided by the 353 TML. Security choices provided by the TML take effect during the 354 pre-association phase of the ForCES protocol. An operator may choose 355 to use all, some or none of the security services provided by the TML 356 in a CE-FE connection. A ForCES NE is required to provide CE/FE node 357 authentication services, and may provide message integrity and 358 confidentially services. The NE may provide these services by 359 employing IPSEC or TLS depending on the choice of TML used in the 360 deployment of the NE. 362 6. ForCES Manageability 364 From one perspective, it is a single network element; as an example 365 if the ForCES NE is specifically a router that needs to be managed 366 then it is managed in essentially the same way any router is managed. 367 From another perspective element management can view the individual 368 entities and interfaces that make up a ForCES NE. 370 6.1. NE as an atomic element 372 From the ForCES requirements RFC 3654, Section 4, point 4: 374 A NE must support the appearance of a single functional device. 376 As a single functional device a ForCES NE runs protocols and each of 377 the protocols has it own existing manageability aspects that are 378 documented elsewhere. As an example, router would also have a 379 configuration interface. When viewed in this manner, the NE is 380 controlled as a single routing entity and no new management beyond 381 what is already available for routers and routing protocols would be 382 required for a ForCES NE. 384 6.2. NE as composed of manageable elements 386 When viewed as a decomposed set of elements from the management 387 perspective, the ForCES NE is divided into a set of one of more 388 Control Elements, Forwarding Elements and the interfaces between 389 them. The interface functionality between the CE and the FE is 390 provided by the ForCES protocol. As with all IETF protocols a MIB is 391 provided for the purposes of managing the protocol. 393 Additionally the architecture makes provision for configuration 394 control of the individual CEs and FEs. This is handled by elements 395 named FE manager (FEM) and the CE manager (CEM). Specifically from 396 the ForCES requirements RFC [RFC 3654], Section 4, point 4: 398 However, external entities (e.g., FE managers and CE managers) may 399 have direct access to individual ForCES protocol elements for 400 providing information to transition them from the pre-association to 401 post-association phase. 403 6.3. ForCES Protocol MIB 405 The ForCES MIB [I-D.ietf-forces-mib] is a primarily read-only MIB 406 that captures information related to the ForCES protocol. This 407 includes state information about the associations between CE(s) and 408 FE(s) in the NE. 410 The ForCES MIB does not include information that is specified in 411 other MIBs, such as packet counters for interfaces, etc. 413 More specifically, the information in the ForCES MIB relative to 414 associations includes: 416 - identifiers of the elements in the association 418 - state of the association 420 - configuration parameters of the association 422 - statistics of the association 424 6.3.1. MIB Management of an FE 426 While it is possible to manage a FE from a element manager, several 427 requirements relating to this have been included in the ForCES 428 Requirements. 430 From the ForCES Requirements [RFC 3654], Section 4, point 14: 432 1. The ability for a management tool (e.g., SNMP) to be used to read 433 (but not change) the state of FE should not be precluded. 435 2. It must not be possible for management tools (e.g., SNMP, etc) to 436 change the state of a FE in a manner that affects overall NE behavior 437 without the CE being notified. 439 The ForCES Requirements [RFC 3654], Section 5.7, goes further in 440 discussing the manner in which FEs should handle management requests 441 that are specifically directed to the FE: 443 For a ForCES NE that is an IP router, RFC 1812 [2] also dictates that 444 "Routers must be manageable by SNMP". In general, for the post- 445 association phase, most external management tasks (including SNMP) 446 should be done through interaction with the CE in order to support 447 the appearance of a single functional device. Therefore, it is 448 recommended that an SNMP agent be implemented by CEs and that the 449 SNMP messages received by FEs be redirected to their CEs. AgentX 450 framework defined in RFC 2741 ([6]) may be applied here such that CEs 451 act in the role of master agent to process SNMP protocol messages 452 while FEs act in the role of subagent to provide access to the MIB 453 objects residing on FEs. AgentX protocol messages between the master 454 agent (CE) and the subagent (FE) are encapsulated and transported via 455 ForCES, just like data packets from any other application layer 456 protocols. 458 6.4. The FEM and CEM 460 Though out of scope for the initial ForCES specification effort, the 461 ForCES architecture include two entities, the CE Manager (CEM) and 462 the FE Manager (FEM). From the ForCES Protocols Specification 463 [I-D.ietf-forces-protocol]. 465 CE Manager (CEM) - A logical entity responsible for generic CE 466 management tasks. It is particularly used during the pre-association 467 phase to determine with which FE(s) a CE should communicate. 469 FE Manager (FEM) - A logical entity responsible for generic FE 470 management tasks. It is used during pre-association phase to 471 determine with which CE(s) an FE should communicate. 473 7. Contributors 475 The following are the contributors who were instrumental in the 476 creation of earlier releases of this document or who gave good 477 suggestions to this document. 479 Mark Handley, ICIR. 481 8. IANA Considerations 483 This document has no IANA actions. 485 [RFC Editor: please remove this section prior to publication.] 487 9. Acknowledgments 489 Many of the colleagues in our companies and participants in the 490 ForCES mailing list have provided invaluable input into this work. 491 Particular thanks to Jamal Hadi Salim. 493 10. References 495 10.1. Normative References 497 [I-D.ietf-forces-mib] 498 HAAS, R., "ForCES MIB", draft-ietf-forces-mib-10 (work in 499 progress), September 2008. 501 [I-D.ietf-forces-model] 502 Halpern, J. and J. Salim, "ForCES Forwarding Element 503 Model", draft-ietf-forces-model-16 (work in progress), 504 October 2008. 506 [I-D.ietf-forces-protocol] 507 Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., 508 Khosravi, H., and W. Wang, "ForCES Protocol 509 Specification", draft-ietf-forces-protocol-22 (work in 510 progress), March 2009. 512 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 513 June 1999. 515 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 516 of IP Control and Forwarding", RFC 3654, November 2003. 518 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 519 "Forwarding and Control Element Separation (ForCES) 520 Framework", RFC 3746, April 2004. 522 10.2. Informative References 524 [RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, 525 B., and J. Segers, "Megaco Protocol Version 1.0", 526 RFC 3015, November 2000. 528 [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, 529 "General Switch Management Protocol (GSMP) V3", RFC 3292, 530 June 2002. 532 Authors' Addresses 534 Alan Crouch 535 Intel 536 2111 NE 25th Avenue 537 Hillsboro, OR 97124 USA 538 USA 540 Phone: +1 503 264 2196 541 Email: alan.crouch@intel.com 543 Hormuzd Khosravi 544 Intel 545 2111 NE 25th Avenue 546 Hillsboro, OR 97124 USA 547 USA 549 Phone: 1-503-264-0334 550 Email: hormuzd.m.khosravi@intel.com 552 Avri Doria 553 LTU 554 Lulea University of Technology 555 Sweden 557 Phone: +46 73 277 1788 558 Email: avri@acm.org 560 Xin-ping Wang 561 Huawei 562 Beijing 563 China 565 Phone: +86 10 82836067 566 Email: carly.wang@huawei.com 568 Kentaro Ogawa 569 NTT Corporation 570 3-9-11 Midori-cho 571 Musashino-shi, Tokyo 180-8585 572 Japan 574 Email: ogawa.kentaro@lab.ntt.co.jp