idnits 2.17.1 draft-ietf-forces-applicability-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. 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 (October 10, 2009) is 5311 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 131 -- Looks like a reference, but probably isn't: '4' on line 131 -- Looks like a reference, but probably isn't: '6' on line 444 == Missing Reference: 'RFC 3654' is mentioned on line 434, but not defined -- Looks like a reference, but probably isn't: '2' on line 438 == Unused Reference: 'RFC2629' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 509, but no explicit reference was found in the text == Unused Reference: 'RFC3746' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC3015' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC3292' is defined on line 522, 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: April 13, 2010 A. Doria 6 LTU 7 X. Wang 8 Huawei 9 K. Ogawa 10 NTT Corporation 11 October 10, 2009 13 ForCES Applicability Statement 14 draft-ietf-forces-applicability-07 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. This document may contain material 20 from IETF Documents or IETF Contributions published or made publicly 21 available before November 10, 2008. The person(s) controlling the 22 copyright in some of this material may not have granted the IETF 23 Trust the right to allow modifications of such material outside the 24 IETF Standards Process. Without obtaining an adequate license from 25 the person(s) controlling the copyright in such materials, this 26 document may not be modified outside the IETF Standards Process, and 27 derivative works of it may not be created outside the IETF Standards 28 Process, except to format it for publication as an RFC or to 29 translate it into languages other than English. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on April 13, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents in effect on the date of 56 publication of this document (http://trustee.ietf.org/license-info). 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. 60 Abstract 62 The ForCES protocol defines a standard framework and mechanism for 63 the interconnection between Control Elements and Forwarding Elements 64 in IP routers and similar devices. In this document we describe the 65 applicability of the ForCES model and protocol. We provide example 66 deployment scenarios and functionality, as well as document 67 applications that would be inappropriate for ForCES. 69 Table of Contents 71 1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 4. Applicability to IP Networks . . . . . . . . . . . . . . . . . 4 75 4.1. Applicable Services . . . . . . . . . . . . . . . . . . . 5 76 4.1.1. Discovery, Capability Information Exchange . . . . . . 5 77 4.1.2. Topology Information Exchange . . . . . . . . . . . . 6 78 4.1.3. Configuration . . . . . . . . . . . . . . . . . . . . 6 79 4.1.4. Routing Exchange . . . . . . . . . . . . . . . . . . . 6 80 4.1.5. QoS Exchange . . . . . . . . . . . . . . . . . . . . . 6 81 4.1.6. Security Exchange . . . . . . . . . . . . . . . . . . 6 82 4.1.7. Filtering Exchange and Firewalls . . . . . . . . . . . 7 83 4.1.8. Encapsulation, Tunneling Exchange . . . . . . . . . . 7 84 4.1.9. NAT and Application-level Gateways . . . . . . . . . . 7 85 4.1.10. Measurement and Accounting . . . . . . . . . . . . . . 7 86 4.1.11. Diagnostics . . . . . . . . . . . . . . . . . . . . . 7 87 4.1.12. CE Redundancy or CE Failover . . . . . . . . . . . . . 7 88 4.2. CE-FE Link Capability . . . . . . . . . . . . . . . . . . 7 89 4.3. CE/FE Locality . . . . . . . . . . . . . . . . . . . . . . 8 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 91 6. ForCES Manageability . . . . . . . . . . . . . . . . . . . . . 9 92 6.1. NE as an atomic element . . . . . . . . . . . . . . . . . 9 93 6.2. NE as composed of manageable elements . . . . . . . . . . 9 94 6.3. ForCES Protocol MIB . . . . . . . . . . . . . . . . . . . 10 95 6.3.1. MIB Management of an FE . . . . . . . . . . . . . . . 10 96 6.4. The FEM and CEM . . . . . . . . . . . . . . . . . . . . . 11 97 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 98 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 99 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 101 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 102 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 105 1. Purpose 107 The purpose of the ForCES Applicability Statement is to capture the 108 intent of the ForCES protocol [I-D.ietf-forces-protocol] designers as 109 to how the protocol could be used (in conjunction with the ForCES 110 model [I-D.ietf-forces-model]). 112 2. Overview 114 The ForCES protocol defines a standard framework and mechanism for 115 the exchange of information between the logically separate 116 functionality of the control and data forwarding planes of IP routers 117 and similar devices. It focuses on the communication necessary for 118 separation of control plane functionality such as routing protocols, 119 signaling protocols, and admission control from data forwarding plane 120 per-packet activities such as packet forwarding, queuing, and header 121 editing. 123 This document defines the applicability of the ForCES mechanisms. It 124 describes types of configurations and settings where ForCES is most 125 appropriately applied. This document also describes scenarios and 126 configurations where ForCES would not be appropriate for use. 128 3. Terminology 130 A set of terminology associated with ForCES is defined in [3, 4]. 131 That terminology is reused here and the reader is directed to [3, 4] 132 for the following definitions: 134 o CE: Control Element. 136 o FE: Forwarding Element. 138 o ForCES: ForCES protocol. 140 o TML: Transport Mapping Layer. 142 4. Applicability to IP Networks 144 The purpose of this section is to list the areas of ForCES 145 applicability in IP network devices. Relatively low end routing 146 systems may be implemented on simple hardware which performs both 147 control and packet forwarding functionality. ForCES may not make 148 sense for such devices. 150 Higher end routing systems typically distribute work amongst 151 interface processing elements, and these devices (FEs) therefore need 152 to communicate with the control element(s) to perform their job. 153 ForCES provides a standard way to do this communication. 155 The remainder of this section lists the applicable services which 156 ForCES may support, applicable FE functionality, applicable CE-FE 157 link scenarios, and applicable topologies in which ForCES may be 158 deployed. 160 4.1. Applicable Services 162 In this section we describe the applicability of ForCES for the 163 following control-forwarding plane services: 165 o Discovery, Capability Information Exchange 167 o Topology Information Exchange 169 o Configuration 171 o Routing Exchange 173 o QoS Exchange 175 o Security Exchange 177 o Filtering Exchange 179 o Encapsulation/Tunneling Exchange 181 o NAT and Application-level Gateways 183 o Measurement and Accounting 185 o Diagnostics 187 o CE Redundancy or CE Failover 189 4.1.1. Discovery, Capability Information Exchange 191 Discovery is the process by which CEs and FEs learn of each other's 192 existence. ForCES assumes that CEs and FEs already know sufficient 193 information to begin communication in a secure manner. The ForCES 194 protocol is only applicable after CEs and FEs have found each other. 195 ForCES makes no assumption about whether discovery was performed 196 using a dynamic protocol or merely static configuration. 198 During the discovery phase, CEs and FEs exchange capability 199 information with each other. For example, the FEs express the number 200 of interface ports they provide, as well as the static and 201 configurable attributes of each port. 203 In addition to initial configuration, the CEs and FEs also exchange 204 dynamic configuration changes using ForCES. For example, FEs 205 asynchronously inform the CE of an increase/decrease in available 206 resources or capabilities on the FE. 208 4.1.2. Topology Information Exchange 210 In this context, topology information relates to how the FEs are 211 interconnected with each other with respect to packet forwarding. 212 Topology discovery is outside the scope of the ForCES protocol. An 213 implementation can choose its own method of topology discovery(for 214 example use a standard topology discovery protocol like LLDP, BFD;or 215 apply a static topology configuration policy).Once the topology is 216 established, ForCES protocol may be used to transmit the resulting 217 information to the CE. 219 4.1.3. Configuration 221 ForCES is used to perform FE configuration. For example, CEs set 222 configurable FE attributes such as IP addresses, etc. for their 223 interfaces. 225 4.1.4. Routing Exchange 227 ForCES may be used to deliver packet forwarding information resulting 228 from CE routing calculations. For example, CEs may send forwarding 229 table updates to the FEs, so that they can make forwarding decisions. 230 FEs may inform the CE in the event of a forwarding table miss. 232 4.1.5. QoS Exchange 234 ForCES may be used to exchange QoS capabilities between CEs and FEs. 235 For example, an FE may express QoS capabilities to the CE. Such 236 capabilities might include metering, policing, shaping, and queuing 237 functions. The CE may use ForCES to configure these capabilities. 239 4.1.6. Security Exchange 241 ForCES may be used to exchange Security information between CEs and 242 FEs. For example, the FE may use ForCES to express the types of 243 encryption that it is capable of using in an IPsec tunnel. The CE 244 may use ForCES to configure such a tunnel. 246 4.1.7. Filtering Exchange and Firewalls 248 ForCES may be used to exchange filtering information. For example, 249 FEs may use ForCES to express the filtering functions such as 250 classification and action that they can perform, and the CE may 251 configure these capabilities. 253 4.1.8. Encapsulation, Tunneling Exchange 255 ForCES may be used to exchange encapsulation capabilities of an FE, 256 such as tunneling, and the configuration of such capabilities. 258 4.1.9. NAT and Application-level Gateways 260 ForCES may be used to exchange configuration information for Network 261 Address Translators. Whilst ForCES is not specifically designed for 262 the configuration of application-level gateway functionality, this 263 may be in scope for some types of application-level gateways. 265 4.1.10. Measurement and Accounting 267 ForCES may be used to exchange configuration information regarding 268 traffic measurement and accounting functionality. In this area, 269 ForCES may overlap somewhat with functionality provided by 270 alternative network management mechanisms such as SNMP. In some 271 cases ForCES may be used to convey information to the CE to be 272 reported externally using SNMP. 274 4.1.11. Diagnostics 276 ForCES may be used for CEs and FEs to exchange diagnostic 277 information. For example, an FE can send self-test results to the 278 CE. 280 4.1.12. CE Redundancy or CE Failover 282 CE failover and redundancy are out of scope in the initial version of 283 ForCES protocol. Basic mechanisms for CE redundancy/failover are not 284 presently implemented. Broad concepts such as implementing CE 285 Redundancy, CE Failover, and CE-CE communication, while not precluded 286 by the ForCES architecture, are considered outside the scope of 287 ForCES protocol. ForCES protocol is designed to handle CE- FE 288 communication, and is not intended for CE-CE communication. 290 4.2. CE-FE Link Capability 292 When using ForCES, the bandwidth of the CE-FE link is a 293 consideration, and cannot be ignored. For example, sending a full 294 routing table is reasonable over a high bandwidth link, but could be 295 non-trivial over a lower-bandwidth link. ForCES should be 296 sufficiently future-proof to be applicable in scenarios where routing 297 tables grow to several orders of magnitude greater than their current 298 size. However, we also note that not all IP routers need full 299 routing tables. 301 4.3. CE/FE Locality 303 ForCES is intended for environments where one of the following 304 applies: 306 o The control interconnect is some form of local bus, switch, or LAN, 307 where reliability is high, closely controlled, and not susceptible to 308 external disruption that does not also affect the CEs and/or FEs. 310 o The control interconnect shares fate with the FE's forwarding 311 function. Typically this is because the control connection is also 312 the FE's primary packet forwarding connection, and so if that link 313 goes down, the FE cannot forward packets anyway. 315 The key guideline is that the reliability of the device should not be 316 significantly reduced by the separation of control and forwarding 317 functionality. 319 Taking this into account, ForCES is applicable in the following CE/FE 320 localities: 322 o single box NE: chassis with multiple CEs and FEs setup. ForCES is 323 applicable in localities consisting of control and forwarding 324 elements which are components in the same physical box. 326 Example: a network element with a single control blade, and one or 327 more forwarding blades, all present in the same chassis and sharing 328 an interconnect such as Ethernet or PCI. In this locality, the 329 majority of the data traffic being forwarded typically does not 330 traverse the same links as the ForCES control traffic. 332 o multiple boxes: separated CE and FE where physical locality could 333 be same rack, room, building, or long distance which could span 334 across continents and oceans. ForCES is applicable in localities 335 consisting of control and forwarding elements which are separated by 336 a single hop or multiple hops in the network. 338 5. Security Considerations 340 The ForCES architecture allows for a variety of security levels[6]. 342 When operating under a secured physical environment, or for other 343 operational concerns (in some cases performance issues) the operator 344 may turn off all the security functions between CE and FE. When the 345 operator makes a decision to secure the path between the FE and CE 346 then the operator chooses from one of the options provided by the 347 TML. Security choices provided by the TML take effect during the 348 pre-association phase of the ForCES protocol. An operator may choose 349 to use all, some or none of the security services provided by the TML 350 in a CE-FE connection. A ForCES NE is required to provide CE/FE node 351 authentication services, and may provide message integrity and 352 confidentially services. The NE may provide these services by 353 employing IPSEC or TLS depending on the choice of TML used in the 354 deployment of the NE. 356 6. ForCES Manageability 358 From the management perspective, an NE can be viewed in at least two 359 ways. From one perspective, it is a single network element, 360 specifically a router that needs to be managed in essentially the 361 same way any router is managed. From another perspective element 362 management can view the individual entities and interfaces that make 363 up a ForCES NE. 365 6.1. NE as an atomic element 367 From the ForCES requirements RFC 3654, Section 4, point 4: 369 A NE must support the appearance of a single functional device. 371 As a single functional device a ForCES NE runs protocols and each of 372 the protocols has it own existing manageability aspects that are 373 documented elsewhere. As a router it would also have a configuration 374 interface. When viewed in this manner, the NE is controlled as a 375 single routing entity and no new management beyond what is already 376 available for routers and routing protocols would be required for a 377 ForCES NE. 379 6.2. NE as composed of manageable elements 381 When viewed as a decomposed set of elements from the management 382 perspective, the ForCES NE is divided into a set of one of more 383 Control Elements, Forwarding Elements and the interfaces between 384 them. The interface functionality between the CE and the FE is 385 provided by the ForCES protocol. As with all IETF protocols a MIB is 386 provided for the purposes of managing the protocol. 388 Additionally the architecture makes provision for configuration 389 control of the individual CEs and FEs. This is handled by elements 390 named FE manager (FEM) and the CE manager (CEM). Specifically from 391 the ForCES requirements RFC [RFC 3654], Section 4, point 4: 393 However, external entities (e.g., FE managers and CE managers) may 394 have direct access to individual ForCES protocol elements for 395 providing information to transition them from the pre-association to 396 post-association phase. 398 6.3. ForCES Protocol MIB 400 The ForCES MIB [I-D.ietf-forces-mib] is a primarily read-only MIB 401 that captures information related to the ForCES protocol. This 402 includes state information about the associations between CE(s) and 403 FE(s) in the NE. 405 The ForCES MIB does not include information that is specified in 406 other MIBs, such as packet counters for interfaces, etc. 408 More specifically, the information in the ForCES MIB relative to 409 associations includes: 411 - identifiers of the elements in the association 413 - state of the association 415 - configuration parameters of the association 417 - statistics of the association 419 6.3.1. MIB Management of an FE 421 While it is possible to manage a FE from a element manager, several 422 requirements relating to this have been included in the ForCES 423 Requirements. 425 From the ForCES Requirements [RFC 3654], Section 4, point 14: 427 1. The ability for a management tool (e.g., SNMP) to be used to read 428 (but not change) the state of FE should not be precluded. 430 2. It must not be possible for management tools (e.g., SNMP, etc) to 431 change the state of a FE in a manner that affects overall NE behavior 432 without the CE being notified. 434 The ForCES Requirements [RFC 3654], Section 5.7, goes further in 435 discussing the manner in which FEs should handle management requests 436 that are specifically directed to the FE: 438 RFC 1812 [2] also dictates that "Routers must be manageable by SNMP". 439 In general, for the post-association phase, most external management 440 tasks (including SNMP) should be done through interaction with the CE 441 in order to support the appearance of a single functional device. 442 Therefore, it is recommended that an SNMP agent be implemented by CEs 443 and that the SNMP messages received by FEs be redirected to their 444 CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here 445 such that CEs act in the role of master agent to process SNMP 446 protocol messages while FEs act in the role of subagent to provide 447 access to the MIB objects residing on FEs. AgentX protocol messages 448 between the master agent (CE) and the subagent (FE) are encapsulated 449 and transported via ForCES, just like data packets from any other 450 application layer protocols. 452 6.4. The FEM and CEM 454 Though out of scope for the initial ForCES specification effort, the 455 ForCES architecture include two entities, the CE Manager (CEM) and 456 the FE Manager (FEM). From the ForCES Protocols Specification 457 [I-D.ietf-forces-protocol]. 459 CE Manager (CEM) - A logical entity responsible for generic CE 460 management tasks. It is particularly used during the pre-association 461 phase to determine with which FE(s) a CE should communicate. 463 FE Manager (FEM) - A logical entity responsible for generic FE 464 management tasks. It is used during pre-association phase to 465 determine with which CE(s) an FE should communicate. 467 7. Contributors 469 The following are the contributors who were instrumental in the 470 creation of earlier releases of this document or who gave good 471 suggestions to this document. 473 Mark Handley,ICIR. 475 8. IANA Considerations 477 This document has no IANA actions. 479 [RFC Editor: please remove this section prior to publication.] 481 9. Acknowledgments 483 Many of the colleagues in our companies and participants in the 484 ForCES mailing list have provided invaluable input into this work. 485 Particular thanks to Jamal Hadi Salim. 487 10. References 489 10.1. Normative References 491 [I-D.ietf-forces-mib] 492 HAAS, R., "ForCES MIB", draft-ietf-forces-mib-10 (work in 493 progress), September 2008. 495 [I-D.ietf-forces-model] 496 Halpern, J. and J. Salim, "ForCES Forwarding Element 497 Model", draft-ietf-forces-model-16 (work in progress), 498 October 2008. 500 [I-D.ietf-forces-protocol] 501 Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., 502 Khosravi, H., and W. Wang, "ForCES Protocol 503 Specification", draft-ietf-forces-protocol-22 (work in 504 progress), March 2009. 506 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 507 June 1999. 509 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 510 of IP Control and Forwarding", RFC 3654, November 2003. 512 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 513 "Forwarding and Control Element Separation (ForCES) 514 Framework", RFC 3746, April 2004. 516 10.2. Informative References 518 [RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, 519 B., and J. Segers, "Megaco Protocol Version 1.0", 520 RFC 3015, November 2000. 522 [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, 523 "General Switch Management Protocol (GSMP) V3", RFC 3292, 524 June 2002. 526 Authors' Addresses 528 Alan Crouch 529 Intel 530 2111 NE 25th Avenue 531 Hillsboro, OR 97124 USA 532 USA 534 Phone: +1 503 264 2196 535 Email: alan.crouch@intel.com 537 Hormuzd Khosravi 538 Intel 539 2111 NE 25th Avenue 540 Hillsboro, OR 97124 USA 541 USA 543 Phone: 1-503-264-0334 544 Email: hormuzd.m.khosravi@intel.com 546 Avri Doria 547 LTU 548 Lulea University of Technology 549 Sweden 551 Phone: +46 73 277 1788 552 Email: avri@acm.org 554 Xin-ping Wang 555 Huawei 556 Beijing 557 China 559 Phone: +86 10 82836067 560 Email: carly.wang@huawei.com 562 Kentaro Ogawa 563 NTT Corporation 564 3-9-11 Midori-cho 565 Musashino-shi, Tokyo 180-8585 566 Japan 568 Email: ogawa.kentaro@lab.ntt.co.jp