idnits 2.17.1 draft-crouch-forces-applicability-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) ** There are 2 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (28 February 2002) is 8085 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) == Unused Reference: '3' is defined on line 370, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 379, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-forces-requirements-01 ** Downref: Normative reference to an Informational draft: draft-ietf-forces-requirements (ref. '1') -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- No information found for draft-salim-netlink-jhsk - is the name correct? == Outdated reference: A later version (-11) exists of draft-ietf-gsmp-06 -- Obsolete informational reference (is this intentional?): RFC 3036 (ref. '5') (Obsoleted by RFC 5036) -- Obsolete informational reference (is this intentional?): RFC 3015 (ref. '7') (Obsoleted by RFC 3525) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force ForCES WG 2 INTERNET-DRAFT Alan Crouch/Intel Labs 3 draft-crouch-forces-applicability-01.txt Mark Handley/ACIRI 4 28 February 2002 5 Expires: August 2002 7 ForCES Applicability Statement 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet- Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The ForCES protocol defines a standard framework and mechanism 33 for the interconnection between Control Elements and 34 Forwarding Engines in IP routers and similar devices. In this 35 document we describe the applicability of the ForCES model and 36 protocol. We provide example deployment scenarios and 37 functionality, as well as document applications that would be 38 inappropriate for ForCES. 40 1. Overview 42 The ForCES protocol defines a standard framework and mechanism for the 43 exchange of information between the logically separate functionality of 44 the control and data forwarding planes of IP routers and similar 45 devices. It focuses on the communication necessary for separation of 46 control plane functionality such as routing protocols, signaling 47 protocols, and admission control from data forwarding plane per-packet 48 activities such as packet forwarding, queuing, and header editing. 50 This document defines the applicability of the ForCES mechanisms. It 51 describes types of configurations and settings where ForCES is most 52 appropriately applied. This document also describes scenarios and 53 configurations where ForCES would not be appropriate for use. 55 2. Terminology 57 CE: Control Element. The processor or processors providing the control 58 plane functionality in an IP router and similar devices. The CE 59 will normally run routing protocols, signaling protocols, 60 admission control mechanisms, and similar functionality. 62 FE: Forwarding Engine. A box, card, or processor that forwards IP 63 packets. An FE will comprise one or more network interfaces, and 64 typically provide route lookup, packet filtering, classification, 65 queuing and other functionality associated with the forwarding or 66 discard of packets. 68 ForCES: 69 refers to the specific protocol and associated conventions used for 70 communication between the CE and a set of FEs. 72 3. Applicability to IP Networks 74 The purpose of this section is to list the areas of ForCES applicability 75 in IP network devices. Relatively low performance devices may be 76 implemented on a simple processor which performs both control and packet 77 forwarding functionality. ForCES is not applicable for such devices. 78 Higher performance devices typically distribute work amongst interface 79 processors, and these devices (FEs) therefore need to communicate with 80 the control element(s) to perform their job. ForCES provides a standard 81 way to do this communication. 83 The remainder of this section lists the applicable services which ForCES 84 may support, applicable FE functionality, applicable CE-FE link 85 scenarios, and applicable topologies in which ForCES may be deployed. 87 3.1. Applicable Services 89 In this section we describe the applicability of ForCES for the 90 following control-forwarding plane services: 92 o Discovery, Capability Information Exchange 94 o Topology Information Exchange 96 o Configuration 98 o Routing Exchange 100 o QoS Exchange 102 o Security Exchange 104 o Filtering Exchange 106 o Encapsulation/Tunneling Exchange 108 o NAT and Application-level Gateways 110 o Measurement and Accounting 112 o Diagnostics 114 o Redundancy 115 3.1.1. Discovery, Capability Information Exchange 117 Discovery is the process by which CEs and FEs learn of each other's 118 existence. ForCES assumes that CEs and FEs already know sufficient 119 information to begin communication in a secure manner. 120 The ForCES protocol is only applicable after CEs and FEs have found 121 each other. ForCES makes no assumption about whether discovery was 122 performed using a dynamic protocol or merely static configuration. 124 During the discovery phase, CEs and FEs may exchange capability 125 information with each other. For example, the FEs may express the 126 number of interface ports they provide, as well as the static and 127 configurable attributes of each port. 129 In addition to initial configuration, the CEs and FEs may also exchange 130 dynamic configuration changes using ForCES. For example, FE's 131 asynchronously inform the CE of an increase/decrease in available 132 resources or capabilities on the FE. 134 3.1.2. Topology Information Exchange 136 In this context, topology information relates to how the FEs are 137 interconnected with each other with respect to packet forwarding. 138 Whilst topology discovery is outside the scope of the ForCES protocol, a 139 standard topology discovery protocol may be selected and used to "learn" 140 the topology, and then the ForCES protocol may be used to transmit the 141 resulting information to the CE. 143 3.1.3. Configuration 145 ForCES is used to perform FE configuration. For example, CEs set 146 configurable FE attributes such as IP addresses. 148 3.1.4. Routing Exchange 150 ForCES may be used to deliver packet forwarding information resulting 151 from CE routing calculations. For example, CEs may send forwarding 152 table updates to the FEs, so that they can make forwarding decisions. 153 FEs may inform the CE in the event of a forwarding table miss. 155 3.1.5. QoS Exchange 157 ForCES may be used to exchange QoS capabilities between CEs and FEs. 158 For example, an FE may express QoS capabilities to the CE. Such 159 capabilities might include metering, policing, shaping, and queuing 160 functions. The CE may use ForCES to configure these capabilities. 162 3.1.6. Security Exchange 164 ForCES may be used to exchange Security information between CEs and FEs. 165 For example, the FE may use ForCES to express the types of encryption 166 that it is capable of using in an IPsec tunnel. The CE may use ForCES 167 to configure such a tunnel. 169 3.1.7. Filtering Exchange and Firewalls 171 ForCES may be used to exchange filtering information. For example, FEs 172 may use ForCES to express the filtering functions such as classification 173 and action that they can perform, and the CE may configure these 174 capabilities. 176 3.1.8. Encapsulation, Tunneling Exchange 178 ForCES may be used to exchange encapsulation capabilities of an FE, such 179 as tunneling, and the configuration of such capabilities. 181 3.1.9. NAT and Application-level Gateways 183 ForCES may be used to exchange configuration information for Network 184 Address Translators. Whilst ForCES is not specifically designed for the 185 configuration of application-level gateway functionality, this may be in 186 scope for some types of application-level gateways. 188 3.1.10. Measurement and Accounting 190 ForCES may be used to exchange configuration information regarding 191 traffic measurement and accounting functionality. In this area, ForCES 192 may overlap somewhat with functionality provided by alternative network 193 management mechanisms such as SNMP. In some cases ForCES may be used to 194 convey information to the CE to be reported externally using SNMP. 195 However, in other cases it may make more sense for the FE to directly 196 speak SNMP. 198 3.1.11. Diagnostics 200 ForCES may be used for CE's and FE's to exchange diagnostics 201 information. For example, an FE can send diagnostic information like 202 self-test results to the CE. 204 3.1.12. Redundancy 206 ForCES is a master-slave protocol where FE's are slaves and CE's are 207 masters. FE's process messages in the order in which they are received 208 from their CE. Concepts such as CE Redundancy, CE Failover, and CE-CE 209 communication, while not precluded by the ForCES architecture, are 210 considered outside the scope of ForCES protocol. 212 3.2. CE-FE Link Capacity 214 When using ForCES, the bandwidth of the CE-FE link is a consideration, 215 and cannot be ignored. For example, sending a full routing table of 216 110K routes is reasonable over a 100Mbit Ethernet interconnect, but is 217 non-trivial over a T1 line (which could occur in a Close Locality (see 218 3.3.2). ForCES should be sufficiently future-proof to be applicable in 219 scenarios where routing tables grow to several orders of magnitude 220 greater than their current size (approximately 100K routes). However, 221 we also note that not all IP routers need full routing tables. 223 3.3. CE/FE Locality 225 We do not intend ForCES to be applicable in configurations where the CE 226 and FE are located arbitrarily in the network. In particular, ForCES is 227 intended for environments where one of the following applies: 229 o The control interconnect is some form of local bus, switch, or LAN, 230 where reliability is high, closely controlled, and not susceptible 231 to external disruption that does not also affect the CEs and/or 232 FEs. 234 o The control interconnect shares fate with the FE's forwarding 235 function. Typically this is because the control connection is also 236 the FE's primary packet forwarding connection, and so if that link 237 goes down, the FE cannot forward packets anyway. 239 The key guideline is that the reliability of the device should not be 240 significantly reduced by the separation of control and forwarding 241 functionality. 243 Taking this into account, ForCES is applicable in the following CE/FE 244 localities in IP networks: 246 o Very Close Localities. 248 o Close Localities 250 3.3.1. Very Close Localities 252 Very Close localities consist of control and forwarding elements which 253 are either components in the same physical box, or are separated at most 254 by one local network hop. An example of a Very Close locality is a 255 network element with a single control blade, and one or more forwarding 256 blades, all present in the same chassis and sharing an interconnect such 257 as Ethernet or PCI. In Very Close localities, the data traffic being 258 forwarded typically does not traverse the same links as the ForCES 259 control traffic. 261 3.3.2. Close Localities 263 Close localities consist of control and forwarding separation for IP 264 forwarding devices where the control and forwarding elements are in 265 close proximity. The definition of "close proximity" is deliberately 266 ambiguous, but might include devices located in the same room, or 267 devices separated by only a very small number of IP hops. Note that to 268 satisfy the reliability requirements, if these is more than one IP hop 269 between a CE and an FE, these hops will not normally be dynamically 270 routed, as in the general case this would not satisfy the constraints 271 above. 273 A specific example of a Close locality is an FE that is located remotely 274 as Customer Premise Equipment (CPE), and a CE located in their Internet 275 Service Provider's facilities . This is an extreme example of the 276 applicability of ForCES. Note that natural fate- sharing exists between 277 the CE and FE. A potentially unreliable link connects the CE and the 278 FE, but if that link were lost, the FE would stop forwarding to and from 279 the ISP, irrespective of the location of the CE. However, if the FE 280 were also required to forward traffic between subnets at the customer 281 premises, this would not satisfy the fate-sharing constraint, as local 282 forwarding would also cease when the link to the ISP fails. 284 Note that not all ForCES functionality may be possible in Close 285 localities. In particular, if the scenario and traffic conditions call 286 for a large amount of ForCES traffic, the network between the CE and FE 287 may not have sufficient capacity to handle the control traffic. 288 Designers considering using ForCES in Close Localities need to take this 289 into account, and ensure that such eventualities do not arise. Also, as 290 the control traffic may share network links with data traffic, ForCES 291 traffic will need to be given priority access to that capacity. 292 Typically this priority needs to be even higher priority than that of 293 the CE's routing protocol traffic. 295 4. Limitations and Out-of-Scope Items 297 ForCES was designed to enable logical separation of control and 298 forwarding planes in IP network devices. However, ForCES is not 299 intended to be applicable to all services or to all possible CE/FE 300 localities. 302 The purpose of this section is to list limitations and out-of-scope 303 items for ForCES. 305 4.1. Out of Scope Services 307 The following control-forwarding plane services are explicitly not 308 addressed by ForCES: 310 o Label Switching 312 o Multimedia Gateway Control (MEGACO). 314 4.1.1. Label Switching 316 Label Switching is the purview of the GSMP Working Group in the Sub- IP 317 Area of the IETF. GSMP is a general purpose protocol to control a label 318 switch. GSMP defines mechanisms to separate the label switch data plane 319 from the control plane label protocols such as LDP [5]. For more 320 information on GSMP, see [4]. 322 4.1.2. Separation of Control and Forwarding in Multimedia Gateways" 324 MEGACO defines a protocol used between elements of a physically 325 decomposed multimedia gateway. Separation of call control channels from 326 bearer channels is the purview of MEGACO. For more information on 327 MEGACO, see [7]. 329 4.2. Localities 331 Examples of network localities that are not appropriate for ForCES are: 333 o Localities where there are a large number of hops between CE and 334 FE. Typically three hops might be considered an upper bound. 336 o Localities where the hops between the CE and FE are dynamically 337 routing using IP routing protocols. 339 o Localities where the loss of the CE-FE link is of non-negligible 340 probability, and where if the CE were co-located with the FE, 341 useful packet forwarding would have been able to continue despite 342 the loss of the link. 344 o Localities where two or more FEs controlled by the same CE cannot 345 communicate, either directly, or indirectly via other FEs 346 controlled by the same CE. 348 5. Security Considerations 350 The security of ForCES protocol will be addressed in the Protocol 351 Specification [2]. For security requirements, see architecture 352 requirement #5 and protocol requirement #2 in the Requirements Draft 353 [1]. The ForCES protocol assumes that the CE and FE are in the same 354 administration, and have shared secrets as a means of administration. 355 Whilst it might be technically feasible to have the CE and FE 356 administered independently, we strongly discourage such uses, because 357 they would require a significantly different trust model from that 358 ForCES assumes. 360 6. Normative References 362 [1] Anderson, T et. al., "Requirements for Separation of IP Control and 363 Forwarding", draft-ietf-forces-requirements-01.txt, Intel Labs, 364 September 2001. 366 [2] ForCES Protocol Specification (to-be-written) 368 7. Informative References 370 [3] Salim, J et. al., "Netlink as an IP Services Protocol", draft-salim- 371 netlink-jhsk-01.txt, Znyx Networks, September 2001. 373 [4] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General switch 374 Management Protocol V3," Internet Draft draft-ietf-gsmp-06.txt, July 375 2000. work in progress 377 [5] Andersson et. al., "LDP Specification" RFC 3036, January 2001 379 [6] Bradner, S, "Key words for use in RFCs to Indicate Requirement 380 Levels", RFC 2119, Harvard University, March 1997. 382 [7] F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November 383 2000 385 8. Acknowledgments 387 The authors wish to thank Jamal Hadi Salim, Hormuzd Khosravi, Vip Sharma, and 388 many others for their invaluable contributions. 390 9. Author's Addresses 392 Alan Crouch 393 Intel Labs 394 2111 NE 25th Avenue 395 Hillsboro, OR 97124 USA 396 Phone: +1 503 264 2196 397 Email: alan.crouch@intel.com 399 Mark Handley 400 ICSI 401 1947 Center Street, Suite 600 402 Berkeley, CA 94708, USA 403 Email: mjh@icsi.berkeley.edu