idnits 2.17.1 draft-ietf-forces-applicability-06.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 : ---------------------------------------------------------------------------- ** 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 368: '... A NE MUST support the appearance of...' RFC 2119 keyword, line 392: '...e.g., FE managers and CE managers) MAY...' RFC 2119 keyword, line 427: '... the state of FE SHOULD NOT be preclud...' RFC 2119 keyword, line 429: '... 2. It MUST NOT be possible for man...' RFC 2119 keyword, line 437: '... RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP"....' 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 (July 2, 2009) is 5413 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '3' on line 130 -- Looks like a reference, but probably isn't: '4' on line 130 -- Looks like a reference, but probably isn't: '6' on line 443 == Missing Reference: 'RFC 3654' is mentioned on line 433, but not defined -- Looks like a reference, but probably isn't: '2' on line 437 == Unused Reference: 'RFC2629' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC3654' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC3746' is defined on line 504, but no explicit reference was found in the text == Unused Reference: 'RFC3015' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC3292' is defined on line 514, 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: 4 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: January 3, 2010 A. Doria 6 LTU 7 X. Wang 8 Huawei 9 K. Ogawa 10 NTT Corporation 11 July 2, 2009 13 ForCES Applicability Statement 14 draft-ietf-forces-applicability-06 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 January 3, 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. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 12 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 104 1. Purpose 106 The purpose of the ForCES Applicability Statement is to capture the 107 intent of the ForCES protocol [I-D.ietf-forces-protocol] designers as 108 to how the protocol could be used (in conjunction with the ForCES 109 model [I-D.ietf-forces-model]). 111 2. Overview 113 The ForCES protocol defines a standard framework and mechanism for 114 the exchange of information between the logically separate 115 functionality of the control and data forwarding planes of IP routers 116 and similar devices. It focuses on the communication necessary for 117 separation of control plane functionality such as routing protocols, 118 signaling protocols, and admission control from data forwarding plane 119 per-packet activities such as packet forwarding, queuing, and header 120 editing. 122 This document defines the applicability of the ForCES mechanisms. It 123 describes types of configurations and settings where ForCES is most 124 appropriately applied. This document also describes scenarios and 125 configurations where ForCES would not be appropriate for use. 127 3. Terminology 129 A set of terminology associated with ForCES is defined in [3, 4]. 130 That terminology is reused here and the reader is directed to [3, 4] 131 for the following definitions: 133 o CE: Control Element. 135 o FE: Forwarding Element. 137 o ForCES: ForCES protocol. 139 o TML: Transport Mapping Layer. 141 4. Applicability to IP Networks 143 The purpose of this section is to list the areas of ForCES 144 applicability in IP network devices. Relatively low end routing 145 systems may be implemented on simple hardware which performs both 146 control and packet forwarding functionality. ForCES may not make 147 sense for such devices. 149 Higher end routing systems typically distribute work amongst 150 interface processing elements, and these devices (FEs) therefore need 151 to communicate with the control element(s) to perform their job. 152 ForCES provides a standard way to do this communication. 154 The remainder of this section lists the applicable services which 155 ForCES may support, applicable FE functionality, applicable CE-FE 156 link scenarios, and applicable topologies in which ForCES may be 157 deployed. 159 4.1. Applicable Services 161 In this section we describe the applicability of ForCES for the 162 following control-forwarding plane services: 164 o Discovery, Capability Information Exchange 166 o Topology Information Exchange 168 o Configuration 170 o Routing Exchange 172 o QoS Exchange 174 o Security Exchange 176 o Filtering Exchange 178 o Encapsulation/Tunneling Exchange 180 o NAT and Application-level Gateways 182 o Measurement and Accounting 184 o Diagnostics 186 o CE Redundancy or CE Failover 188 4.1.1. Discovery, Capability Information Exchange 190 Discovery is the process by which CEs and FEs learn of each other's 191 existence. ForCES assumes that CEs and FEs already know sufficient 192 information to begin communication in a secure manner. The ForCES 193 protocol is only applicable after CEs and FEs have found each other. 194 ForCES makes no assumption about whether discovery was performed 195 using a dynamic protocol or merely static configuration. 197 During the discovery phase, CEs and FEs exchange capability 198 information with each other. For example, the FEs express the number 199 of interface ports they provide, as well as the static and 200 configurable attributes of each port. 202 In addition to initial configuration, the CEs and FEs also exchange 203 dynamic configuration changes using ForCES. For example, FEs 204 asynchronously inform the CE of an increase/decrease in available 205 resources or capabilities on the FE. 207 4.1.2. Topology Information Exchange 209 In this context, topology information relates to how the FEs are 210 interconnected with each other with respect to packet forwarding. 211 Topology discovery is outside the scope of the ForCES protocol. An 212 implementation can choose its own method of topology discovery(for 213 example use a standard topology discovery portocol like LLDP, BFD;or 214 apply a static topology configuration policy).Once the topology is 215 established, ForCES protocol may be used to transmit the resulting 216 information to the CE. 218 4.1.3. Configuration 220 ForCES is used to perform FE configuration. For example, CEs set 221 configurable FE attributes such as IP addresses, etc. for their 222 interfaces. 224 4.1.4. Routing Exchange 226 ForCES may be used to deliver packet forwarding information resulting 227 from CE routing calculations. For example, CEs may send forwarding 228 table updates to the FEs, so that they can make forwarding decisions. 229 FEs may inform the CE in the event of a forwarding table miss. 231 4.1.5. QoS Exchange 233 ForCES may be used to exchange QoS capabilities between CEs and FEs. 234 For example, an FE may express QoS capabilities to the CE. Such 235 capabilities might include metering, policing, shaping, and queuing 236 functions. The CE may use ForCES to configure these capabilities. 238 4.1.6. Security Exchange 240 ForCES may be used to exchange Security information between CEs and 241 FEs. For example, the FE may use ForCES to express the types of 242 encryption that it is capable of using in an IPsec tunnel. The CE 243 may use ForCES to configure such a tunnel. 245 4.1.7. Filtering Exchange and Firewalls 247 ForCES may be used to exchange filtering information. For example, 248 FEs may use ForCES to express the filtering functions such as 249 classification and action that they can perform, and the CE may 250 configure these capabilities. 252 4.1.8. Encapsulation, Tunneling Exchange 254 ForCES may be used to exchange encapsulation capabilities of an FE, 255 such as tunneling, and the configuration of such capabilities. 257 4.1.9. NAT and Application-level Gateways 259 ForCES may be used to exchange configuration information for Network 260 Address Translators. Whilst ForCES is not specifically designed for 261 the configuration of application-level gateway functionality, this 262 may be in scope for some types of application-level gateways. 264 4.1.10. Measurement and Accounting 266 ForCES may be used to exchange configuration information regarding 267 traffic measurement and accounting functionality. In this area, 268 ForCES may overlap somewhat with functionality provided by 269 alternative network management mechanisms such as SNMP. In some 270 cases ForCES may be used to convey information to the CE to be 271 reported externally using SNMP. 273 4.1.11. Diagnostics 275 ForCES may be used for CEs and FEs to exchange diagnostic 276 information. For example, an FE can send self-test results to the 277 CE. 279 4.1.12. CE Redundancy or CE Failover 281 CE failover and redundancy are out of scope in the initial version of 282 ForCES protocol. Basic mechanisms for CE redundancy/failover are not 283 presently implemented. Broad concepts such as implementing CE 284 Redundancy, CE Failover, and CE-CE communication, while not precluded 285 by the ForCES architecture, are considered outside the scope of 286 ForCES protocol. ForCES protocol is designed to handle CE- FE 287 communication, and is not intended for CE-CE communication. 289 4.2. CE-FE Link Capability 291 When using ForCES, the bandwidth of the CE-FE link is a 292 consideration, and cannot be ignored. For example, sending a full 293 routing table of 110K routes is reasonable over a 100Mbit Ethernet 294 interconnect, but could be non-trivial over a lower-bandwidth link. 295 ForCES should be sufficiently future-proof to be applicable in 296 scenarios where routing tables grow to several orders of magnitude 297 greater than their current size. However, we also note that not all 298 IP routers need full routing tables. 300 4.3. CE/FE Locality 302 ForCES is intended for environments where one of the following 303 applies: 305 o The control interconnect is some form of local bus, switch, or LAN, 306 where reliability is high, closely controlled, and not susceptible to 307 external disruption that does not also affect the CEs and/or FEs. 309 o The control interconnect shares fate with the FE's forwarding 310 function. Typically this is because the control connection is also 311 the FE's primary packet forwarding connection, and so if that link 312 goes down, the FE cannot forward packets anyway. 314 The key guideline is that the reliability of the device should not be 315 significantly reduced by the separation of control and forwarding 316 functionality. 318 Taking this into account, ForCES is applicable in the following CE/FE 319 localities: 321 o single box NE: chassis with multiple CEs and FEs setup. ForCES is 322 applicable in localities consisting of control and forwarding 323 elements which are components in the same physical box. 325 Example: a network element with a single control blade, and one or 326 more forwarding blades, all present in the same chassis and sharing 327 an interconnect such as Ethernet or PCI. In this locality, the 328 majority of the data traffic being forwarded typically does not 329 traverse the same links as the ForCES control traffic. 331 o multiple boxes: separated CE and FE where physical locality could 332 be same rack, room, building, or long distance which could span 333 across continents and oceans. ForCES is applicable in localities 334 consisting of control and forwarding elements which are separated at 335 single hop or multiple hops network. 337 5. Security Considerations 339 The ForCES architecture allows for a variety of security levels[6]. 341 When operating under a secured physical environment, or for other 342 operational concerns (in some cases performance issues) the operator 343 may turn off all the security functions between CE and FE. When the 344 operator makes a decision to secure the path between the FE and CE 345 then the operator chooses from one of the options provided by the 346 TML. Security choices provided by the TML take effect during the 347 pre-association phase of the ForCES protocol. An operator may choose 348 to use all, some or none of the security services provided by the TML 349 in a CE-FE connection. A ForCES NE is required to provide CE/FE node 350 authentication services, and may provide message integrity and 351 confidentially services. The NE may provide these services by 352 employing IPSEC or TLS depending on the choice of TML used in the 353 deployment of the NE. 355 6. ForCES Manageability 357 From the management perspective, an NE can be viewed in at least two 358 ways. From one perspective, it is a single network element, 359 specifically a router that needs to be managed in essentially the 360 same way any router is managed. From another perspective element 361 management can view the individual entities and interfaces that make 362 up a ForCES NE. 364 6.1. NE as an atomic element 366 From the ForCES requirements RFC 3654, Section 4, point 4: 368 A NE MUST support the appearance of a single functional device. 370 As a single functional device a ForCES NE runs protocols and each of 371 the protocols has it own existing manageability aspects that are 372 document elsewhere. As a router it would also have a configuration 373 interface. When viewed in this manner, the NE is controlled as 374 single routing entity and no new management beyond what is already 375 available for routers and routing protocols would be required for a 376 ForCES NE. 378 6.2. NE as composed of manageable elements 380 When viewed as a decomposed set of elements from the management 381 perspective, the ForCES NE is divided into a set of one of more 382 Control Elements, Forwarding Elements and the interfaces between 383 them. The interface functionality between the CE and the FE is 384 provided by the ForCES protocol. As with all IETF protocols a MIB is 385 provided for the purposes of managing the protocol. 387 Additionally the architecture makes provision for configuration 388 control of the individual CEs and FEs. This is handled by elements 389 named FE manager (FEM) and the CE manager (CEM). Specifically from 390 the ForCES requirements RFC [RFC 3654], Section 4, point 4: 392 However, external entities (e.g., FE managers and CE managers) MAY 393 have direct access to individual ForCES protocol elements for 394 providing information to transition them from the pre-association to 395 post-association phase. 397 6.3. ForCES Protocol MIB 399 The ForCES MIB [I-D.ietf-forces-mib] is a primarily read-only MIB 400 that captures information related to the ForCES protocol. This 401 includes state information about the associations between CE(s) and 402 FE(s) in the NE. 404 The ForCES MIB does not include information that is specified in 405 other MIBs, such as packet counters for interfaces, etc. 407 More specifically, the information in the ForCES MIB relative to 408 associations includes: 410 - identifiers of the elements in the association 412 - state of the association 414 - configuration parameters of the association 416 - statistics of the association 418 6.3.1. MIB Management of an FE 420 While it is possible to manage a FE from a element manager, several 421 requirements relating to this have been included in the ForCES 422 Requirements. 424 From the ForCES Requirements [RFC 3654], Section 4, point 14: 426 1. The ability for a management tool (e.g., SNMP) to be used to read 427 (but not change) the state of FE SHOULD NOT be precluded. 429 2. It MUST NOT be possible for management tools (e.g., SNMP, etc) to 430 change the state of a FE in a manner that affects overall NE behavior 431 without the CE being notified. 433 The ForCES Requirements [RFC 3654], Section 5.7, goes further in 434 discussing the manner in which FEs should handle management requests 435 that are specifically directed to the FE: 437 RFC 1812 [2] also dictates that "Routers MUST be manageable by SNMP". 438 In general, for the post-association phase, most external management 439 tasks (including SNMP) should be done through interaction with the CE 440 in order to support the appearance of a single functional device. 441 Therefore, it is recommended that an SNMP agent be implemented by CEs 442 and that the SNMP messages received by FEs be redirected to their 443 CEs. AgentX framework defined in RFC 2741 ([6]) may be applied here 444 such that CEs act in the role of master agent to process SNMP 445 protocol messages while FEs act in the role of subagent to provide 446 access to the MIB objects residing on FEs. AgentX protocol messages 447 between the master agent (CE) and the subagent (FE) are encapsulated 448 and transported via ForCES, just like data packets from any other 449 application layer protocols. 451 6.4. The FEM and CEM 453 Though out of scope for the initial ForCES specification effort, the 454 ForCES architecture include two entities, the CE Manager (CEM) and 455 the FE Manager (FEM). From the ForCES Protocols Specification 456 [I-D.ietf-forces-protocol]. 458 CE Manager (CEM) - A logical entity responsible for generic CE 459 management tasks. It is particularly used during the pre-association 460 phase to determine with which FE(s) a CE should communicate. 462 FE Manager (FEM) - A logical entity responsible for generic FE 463 management tasks. It is used during pre-association phase to 464 determine with which CE(s) an FE should communicate. 466 7. Contributors 468 The following are the contributors who were instrumental in the 469 creation of earlier releases of this document or who gave good 470 suggestions to this document. 472 Mark Handley,ICIR. 474 8. Acknowledgments 476 Many of the colleagues in our companies and participants in the 477 ForCES mailing list have provided invaluable input into this work. 478 Particular thanks to Jamal Hadi Salim. 480 9. References 481 9.1. Normative References 483 [I-D.ietf-forces-mib] 484 HAAS, R., "ForCES MIB", draft-ietf-forces-mib-10 (work in 485 progress), September 2008. 487 [I-D.ietf-forces-model] 488 Halpern, J. and J. Salim, "ForCES Forwarding Element 489 Model", draft-ietf-forces-model-16 (work in progress), 490 October 2008. 492 [I-D.ietf-forces-protocol] 493 Dong, L., Doria, A., Gopal, R., HAAS, R., Salim, J., 494 Khosravi, H., and W. Wang, "ForCES Protocol 495 Specification", draft-ietf-forces-protocol-22 (work in 496 progress), March 2009. 498 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 499 June 1999. 501 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 502 of IP Control and Forwarding", RFC 3654, November 2003. 504 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 505 "Forwarding and Control Element Separation (ForCES) 506 Framework", RFC 3746, April 2004. 508 9.2. Informative References 510 [RFC3015] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, 511 B., and J. Segers, "Megaco Protocol Version 1.0", 512 RFC 3015, November 2000. 514 [RFC3292] Doria, A., Hellstrand, F., Sundell, K., and T. Worster, 515 "General Switch Management Protocol (GSMP) V3", RFC 3292, 516 June 2002. 518 Authors' Addresses 520 Alan Crouch 521 Intel 522 2111 NE 25th Avenue 523 Hillsboro, OR 97124 USA 524 USA 526 Phone: +1 503 264 2196 527 Email: alan.crouch@intel.com 529 Hormuzd Khosravi 530 Intel 531 2111 NE 25th Avenue 532 Hillsboro, OR 97124 USA 533 USA 535 Phone: 1-503-264-0334 536 Email: hormuzd.m.khosravi@intel.com 538 Avri Doria 539 LTU 540 Lulea University of Technology 541 Sweden 543 Phone: +46 73 277 1788 544 Email: avri@acm.org 546 Xin-ping Wang 547 Huawei 548 Beijing 549 China 551 Phone: +86 10 82836067 552 Email: carly.wang@huawei.com 554 Kentaro Ogawa 555 NTT Corporation 556 3-9-11 Midori-cho 557 Musashino-shi, Tokyo 180-8585 558 Japan 560 Email: ogawa.kentaro@lab.ntt.co.jp