idnits 2.17.1 draft-ietf-forces-applicability-03.txt: -(424): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 488. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Missing revision: the document name given in the document, 'draft-ietf-forces-applicability-', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-ietf-forces-applicability-', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-ietf-forces-applicability-', but the file name used is 'draft-ietf-forces-applicability-03' == There are 6 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 3 longer pages, the longest (page 3) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([3,4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 109 has weird spacing: '... the exchan...' == Line 114 has weird spacing: '... data forwa...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (Feb 2006) is 6643 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '3' on line 403 looks like a reference -- Missing reference section? '4' on line 126 looks like a reference -- Missing reference section? '8' on line 366 looks like a reference -- Missing reference section? '7' on line 366 looks like a reference -- Missing reference section? '9' on line 373 looks like a reference -- Missing reference section? '6' on line 398 looks like a reference Summary: 11 errors (**), 1 flaw (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Alan Crouch 3 Internet Draft Hormuzd Khosravi 4 Document: draft-ietf-forces-applicability- Intel Corp. 5 03.txt 6 Expires: July 2006 Mark Handley 7 Working Group: ForCES ICIR 9 Feb 2006 11 ForCES Applicability Statement 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as ``work in 29 progress.'' 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Conventions used in this document 43 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 44 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 45 this document are to be interpreted as described in [2 46 ]. 48 Abstract 50 ForCES Applicability Statement Feb 2006 52 The ForCES protocol defines a standard framework and mechanism for 53 the interconnection between Control Elements and Forwarding Elements 54 in IP routers and similar devices. In this document we describe the 55 applicability of the ForCES model and protocol. We provide example 56 deployment scenarios and functionality, as well as document 57 applications that would be inappropriate for ForCES. 59 Table of Contents 61 1. Purpose.........................................................2 62 2. Overview........................................................3 63 3. Terminology.....................................................3 64 4. Applicability to IP Networks....................................3 65 4.1. Applicable Services...........................................4 66 4.1.1. Discovery, Capability Information Exchange..................4 67 4.1.2. Topology Information Exchange...............................5 68 4.1.3. Configuration...............................................5 69 4.1.4. Routing Exchange............................................5 70 4.1.5. QoS Exchange................................................5 71 4.1.6. Security Exchange...........................................5 72 4.1.7. Filtering Exchange and Firewalls............................5 73 4.1.8. Encapsulation, Tunneling Exchange...........................6 74 4.1.9. NAT and Application-level Gateways..........................6 75 4.1.10. Measurement and Accounting.................................6 76 4.1.11. Diagnostics................................................6 77 4.1.12. CE Redundancy or CE Failover...............................6 78 4.2. CE-FE Link Capability.........................................6 79 4.3. CE/FE Locality................................................7 80 5. Limitations and Out-of-Scope Items..............................7 81 5.1. Out of Scope Services.........................................8 82 5.1.1. Label Switching.............................................8 83 5.1.2. Separation of Control and Forwarding in Multimedia Gateways.8 84 5.2. Localities....................................................8 85 6. Security Considerations.........................................8 86 7. Manageability...................................................9 87 8. References......................................................9 88 8.1. Normative References..........................................9 89 8.2. Informative References........................................9 90 9. Acknowledgments.................................................9 91 10. Authors' Addresses............................................10 93 1. 94 Purpose 96 The purpose of the ForCES Applicability Statement is to capture the 97 intent of the ForCES protocol designers as to how the protocol 99 ForCES Applicability Statement Feb 2006 101 should be used. The Applicability Statement will evolve alongside 102 the protocol, and will go to RFC as informational around the same 103 time the as the protocol goes to RFC. 105 2. 106 Overview 108 The ForCES protocol defines a standard framework and mechanism for 109 the exchange of information between the logically separate 110 functionality of the control and data forwarding planes of IP 111 routers and similar devices. It focuses on the communication 112 necessary for separation of control plane functionality such as 113 routing protocols, signaling protocols, and admission control from 114 data forwarding plane per-packet activities such as packet 115 forwarding, queuing, and header editing. 117 This document defines the applicability of the ForCES mechanisms. It 118 describes types of configurations and settings where ForCES is most 119 appropriately applied. This document also describes scenarios and 120 configurations where ForCES would not be appropriate for use. 122 3. 123 Terminology 125 A set of terminology associated with ForCES is defined in [3, 4]. 126 That terminology is reused here and the reader is directed to [3, 4] 127 for the following definitions: 129 o CE: Control Element. 131 o FE: Forwarding Element. 133 o ForCES: ForCES protocol. 135 4. 136 Applicability to IP Networks 138 The purpose of this section is to list the areas of ForCES 139 applicability in IP network devices. Relatively low performance 140 devices may be implemented on a simple processor which performs both 141 control and packet forwarding functionality. ForCES is not 142 applicable for such devices. 144 Higher performance devices typically distribute work amongst 145 interface processors, and these devices (FEs) therefore need to 146 communicate with the control element(s) to perform their job. 147 ForCES provides a standard way to do this communication. 149 ForCES Applicability Statement Feb 2006 151 The remainder of this section lists the applicable services which 152 ForCES may support, applicable FE functionality, applicable CE-FE 153 link scenarios, and applicable topologies in which ForCES may be 154 deployed. 156 4.1. Applicable Services 158 In this section we describe the applicability of ForCES for the 159 following control-forwarding plane services: 161 o Discovery, Capability Information Exchange 163 o Topology Information Exchange 165 o Configuration 167 o Routing Exchange 169 o QoS Exchange 171 o Security Exchange 173 o Filtering Exchange 175 o Encapsulation/Tunneling Exchange 177 o NAT and Application-level Gateways 179 o Measurement and Accounting 181 o Diagnostics 183 o CE Redundancy or CE Failover 185 4.1.1.Discovery, Capability Information Exchange 187 Discovery is the process by which CEs and FEs learn of each other's 188 existence. ForCES assumes that CEs and FEs already know sufficient 189 information to begin communication in a secure manner. 190 The ForCES protocol is only applicable after CEs and FEs have found 191 each other. ForCES makes no assumption about whether discovery was 192 performed using a dynamic protocol or merely static configuration. 194 During the discovery phase, CEs and FEs may exchange capability 195 information with each other. For example, the FEs may express the 197 ForCES Applicability Statement Feb 2006 199 number 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 may also 203 exchange dynamic configuration changes using ForCES. For example, 204 FE's asynchronously inform the CE of an increase/decrease in 205 available 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 Whilst topology discovery is outside the scope of the ForCES 212 protocol, a standard topology discovery protocol may be selected and 213 used to "learn" the topology, and then the ForCES protocol may be 214 used to transmit the resulting information to the CE. 216 4.1.3.Configuration 218 ForCES is used to perform FE configuration. For example, CEs set 219 configurable FE attributes such as IP addresses, etc. for their 220 interfaces. 222 4.1.4.Routing Exchange 224 ForCES may be used to deliver packet forwarding information 225 resulting from CE routing calculations. For example, CEs may send 226 forwarding table updates to the FEs, so that they can make 227 forwarding decisions. FEs may inform the CE in the event of a 228 forwarding table miss. 230 4.1.5.QoS Exchange 232 ForCES may be used to exchange QoS capabilities between CEs and FEs. 233 For example, an FE may express QoS capabilities to the CE. Such 234 capabilities might include metering, policing, shaping, and queuing 235 functions. The CE may use ForCES to configure these capabilities. 237 4.1.6.Security Exchange 239 ForCES may be used to exchange Security information between CEs and 240 FEs. For example, the FE may use ForCES to express the types of 241 encryption that it is capable of using in an IPsec tunnel. The CE 242 may use ForCES to configure such a tunnel. 244 4.1.7.Filtering Exchange and Firewalls 246 ForCES Applicability Statement Feb 2006 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. However, in other cases it may make 273 more sense for the FE to directly speak SNMP. 275 4.1.11.Diagnostics 277 ForCES may be used for CE's and FE's to exchange diagnostic 278 information. For example, an FE can send self-test results to the 279 CE. 281 4.1.12.CE Redundancy or CE Failover 283 ForCES is a master-slave protocol where FE's are slaves and CE's are 284 masters. Basic mechanisms for CE redundancy/failover are provided 285 in ForCES protocol. Broad concepts such as implementing CE 286 Redundancy, CE Failover, and CE-CE communication, while not 287 precluded by the ForCES architecture, are considered outside the 288 scope of ForCES protocol. ForCES protocol is designed to handle CE- 289 FE communication, and is not intended for CE-CE communication. 291 4.2.CE-FE Link Capability 293 When using ForCES, the bandwidth of the CE-FE link is a 294 consideration, and cannot be ignored. For example, sending a full 295 routing table of 110K routes is reasonable over a 100Mbit Ethernet 297 ForCES Applicability Statement Feb 2006 299 interconnect, but could be non-trivial over a lower-bandwidth link. 300 ForCES should be sufficiently future-proof to be applicable in 301 scenarios where routing tables grow to several orders of magnitude 302 greater than their current size (approximately 100K routes). 303 However, we also note that not all IP routers need full routing 304 tables. 306 4.3.CE/FE Locality 308 We do not intend ForCES to be applicable in configurations where the 309 CE and FE are located arbitrarily in the network. In particular, 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 CEs 316 and/or FEs. 318 o The control interconnect shares fate with the FE's forwarding 319 function. Typically this is because the control connection is also 320 the FE's primary packet forwarding connection, and so if that link 321 goes down, the FE cannot forward packets anyway. 323 The key guideline is that the reliability of the device should not 324 be significantly reduced by the separation of control and forwarding 325 functionality. 327 ForCES is applicable in localities consisting of control and 328 forwarding elements which are either components in the same physical 329 box, or are separated at most by one local network hop (historically 330 referred to as "Very Close" localities). 332 Example: a network element with a single control blade, and one or 333 more forwarding blades, all present in the same chassis and sharing 334 an interconnect such as Ethernet or PCI. In this locality, the 335 majority of the data traffic being forwarded typically does not 336 traverse the same links as the ForCES control traffic. 338 5. 339 Limitations and Out-of-Scope Items 341 ForCES was designed to enable logical separation of control and 342 forwarding planes in IP network devices. However, ForCES is not 343 intended to be applicable to all services or to all possible CE/FE 344 localities. 346 The purpose of this section is to list limitations and out-of-scope 347 items for ForCES. 349 ForCES Applicability Statement Feb 2006 351 5.1.Out of Scope Services 353 The following control-forwarding plane services are explicitly not 354 addressed by ForCES: 356 o Label Switching 358 o Multimedia Gateway Control (MEGACO). 360 5.1.1.Label Switching 362 Label Switching is the purview of the GSMP Working Group in the Sub- 363 IP Area of the IETF. GSMP is a general purpose protocol to control 364 a label switch. GSMP defines mechanisms to separate the label 365 switch data plane from the control plane label protocols such as LDP 366 [8]. For more information on GSMP, see [7]. 368 5.1.2.Separation of Control and Forwarding in Multimedia Gateways 370 MEGACO defines a protocol used between elements of a physically 371 decomposed multimedia gateway. Separation of call control channels 372 from bearer channels is the purview of MEGACO. For more information 373 on MEGACO, see [9]. 375 5.2.Localities 377 ForCES protocol was intended to work within the localities described 378 in the last section. Outside these boundaries, care must be taken 379 or the protocol may not work right. Examples of localities where 380 ForCES was not originally intended to be used: 382 o Localities where there are multiple hops between CE and FE. 384 o Localities where hops between the CE and FE are dynamically 385 routing using IP routing protocols. 387 o Localities where the loss of the CE-FE link is of non- 388 negligible probability. 390 o Localities where two or more FEs controlled by the same CE 391 cannot communicate, either directly, or indirectly via other Fes 392 controlled by the same CE. 394 6. 395 Security Considerations 397 The security of ForCES protocol will be addressed in the Protocol 398 Specification [6]. For security requirements, see architecture 400 ForCES Applicability Statement Feb 2006 402 requirement #5 and protocol requirement #2 in the Requirements Draft 403 [3]. The ForCES protocol assumes that the CE and FE are in the same 404 administration, and have shared secrets as a means of 405 administration. Whilst it might be technically feasible to have the 406 CE and FE administered independently, we strongly discourage such 407 uses, because they would require a significantly different trust 408 model from that ForCES assumes. 410 7. 411 Manageability 412 TBD 414 8. 415 References 416 8.1.Normative References 418 1. S. Bradner, "The Internet Standards Process -Revision 3", RFC 2026, 419 October 1996. 421 2. S. Bradner, "Keywords for use in RFCs to Indicate Requirement 422 Levels", RFC2119 (BCP), IETF, March 1997. 424 3. Khosravi, et al., ��Requirements for Separation of IP Control and 425 Forwarding�, RFC 3654, November 2003. 427 4. L. Yang, et al., � ForCES Architectural Framework�, RFC 3746, 428 April 2004. 430 5. Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z.,and S. 431 Blake, "ForCES Forwarding Element Model", Feb. 2005. 433 6. A. Doria, et al., �ForCES Protocol Specification�, draft-ietf- 434 forces-protocol-06.txt, December 2005. 436 8.2.Informative References 438 7. A. Doria, F. Hellstrand, K. Sundell, T. Worster, �General Switch 439 Management Protocol (GSMP) V3�, RFC 3292, June 2002. 441 8. Andersson et al., "LDP Specification" RFC 3036, January 2001 443 9. F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November 444 2000 446 9. 447 Acknowledgments 448 The authors wish to thank Jamal Hadi Salim, Avri Doria, Vip 449 Sharma, and many others for their invaluable contributions. 451 ForCES Applicability Statement Feb 2006 453 10. 454 Authors' Addresses 456 Alan Crouch 457 Intel 458 2111 NE 25th Avenue 459 Hillsboro, OR 97124 USA 460 Phone: +1 503 264 2196 461 Email: alan.crouch@intel.com 463 Hormuzd Khosravi 464 Intel 465 2111 NE 25th Avenue 466 Hillsboro, OR 97124 467 Phone: 1-503-264-0334 468 Email: hormuzd.m.khosravi@intel.com 470 Mark Handley 471 ICIR 472 1947 Center Street, Suite 600 473 Berkeley, CA 94708, USA 474 Email: mjh@icsi.berkeley.edu 476 Copyright Statement 478 Copyright (C) The Internet Society (2006). This document is subject 479 to the rights, licenses and restrictions contained in BCP 78, and 480 except as set forth therein, the authors retain all their rights. 482 This document and the information contained herein are provided on 483 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 484 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 485 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 486 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 487 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 488 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.