idnits 2.17.1 draft-ietf-forces-applicability-02.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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 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.) 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 (26 June 2003) is 7609 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? '1' on line 325 looks like a reference -- Missing reference section? '5' on line 337 looks like a reference -- Missing reference section? '4' on line 335 looks like a reference -- Missing reference section? '7' on line 342 looks like a reference -- Missing reference section? '2' on line 328 looks like a reference -- Missing reference section? '3' on line 332 looks like a reference -- Missing reference section? '6' on line 339 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force ForCES WG 3 INTERNET-DRAFT Alan Crouch/Intel 4 draft-ietf-forces-applicability-02.txt Mark Handley/ICIR 6 26 June 2003 7 Expires: December 2003 9 ForCES Applicability Statement 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet- Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The ForCES protocol defines a standard framework and mechanism 35 for the interconnection between Control Elements and 36 Forwarding Engines in IP routers and similar devices. In this 37 document we describe the applicability of the ForCES model and 38 protocol. We provide example deployment scenarios and 39 functionality, as well as document applications that would be 40 inappropriate for ForCES. 42 1. Purpose 44 The purpose of the ForCES Applicability Statement is to capture the 45 intent of the ForCES protocol designers as to how the protocol should be 46 used. The Applicability Statement will evolve alongside the protocol, 47 and will go to RFC as informational around the same time the as the 48 protocol goes to RFC. 50 2. Overview 52 The ForCES protocol defines a standard framework and mechanism for the 53 exchange of information between the logically separate functionality of 54 the control and data forwarding planes of IP routers and similar 55 devices. It focuses on the communication necessary for separation of 56 control plane functionality such as routing protocols, signaling 57 protocols, and admission control from data forwarding plane per-packet 58 activities such as packet forwarding, queuing, and header editing. 60 This document defines the applicability of the ForCES mechanisms. It 61 describes types of configurations and settings where ForCES is most 62 appropriately applied. This document also describes scenarios and 63 configurations where ForCES would not be appropriate for use. 65 3. Terminology A set of terminology associated with ForCES is defined 66 in [1]. That terminology is reused here and the reader is directed to 67 [1] for the following definitions: 69 o CE: Control Element. 71 o FE: Forwarding Element. 73 o ForCES: ForCES protocol. 75 4. Applicability to IP Networks 77 The purpose of this section is to list the areas of ForCES applicability 78 in IP network devices. Relatively low performance devices may be 79 implemented on a simple processor which performs both control and packet 80 forwarding functionality. ForCES is not applicable for such devices. 81 Higher performance devices typically distribute work amongst interface 82 processors, and these devices (FEs) therefore need to communicate with 83 the control element(s) to perform their job. ForCES provides a standard 84 way to do this communication. 86 The remainder of this section lists the applicable services which ForCES 87 may support, applicable FE functionality, applicable CE-FE link 88 scenarios, and applicable topologies in which ForCES may be deployed. 90 4.1. Applicable Services 92 In this section we describe the applicability of ForCES for the 93 following control-forwarding plane services: 95 o Discovery, Capability Information Exchange 97 o Topology Information Exchange 99 o Configuration 101 o Routing Exchange 103 o QoS Exchange 105 o Security Exchange 107 o Filtering Exchange 109 o Encapsulation/Tunneling Exchange 111 o NAT and Application-level Gateways 113 o Measurement and Accounting 115 o Diagnostics 117 o CE Redundancy or CE Failover 118 4.1.1. Discovery, Capability Information Exchange 120 Discovery is the process by which CEs and FEs learn of each other's 121 existence. ForCES assumes that CEs and FEs already know sufficient 122 information to begin communication in a secure manner. 123 The ForCES protocol is only applicable after CEs and FEs have found 124 each other. ForCES makes no assumption about whether discovery was 125 performed using a dynamic protocol or merely static configuration. 127 During the discovery phase, CEs and FEs may exchange capability 128 information with each other. For example, the FEs may express the 129 number of interface ports they provide, as well as the static and 130 configurable attributes of each port. 132 In addition to initial configuration, the CEs and FEs may also exchange 133 dynamic configuration changes using ForCES. For example, FE's 134 asynchronously inform the CE of an increase/decrease in available 135 resources or capabilities on the FE. 137 4.1.2. Topology Information Exchange 139 In this context, topology information relates to how the FEs are 140 interconnected with each other with respect to packet forwarding. 141 Whilst topology discovery is outside the scope of the ForCES protocol, a 142 standard topology discovery protocol may be selected and used to "learn" 143 the topology, and then the ForCES protocol may be used to transmit the 144 resulting information to the CE. 146 4.1.3. Configuration 148 ForCES is used to perform FE configuration. For example, CEs set 149 configurable FE attributes such as IP addresses. 151 4.1.4. Routing Exchange 153 ForCES may be used to deliver packet forwarding information resulting 154 from CE routing calculations. For example, CEs may send forwarding 155 table updates to the FEs, so that they can make forwarding decisions. 156 FEs may inform the CE in the event of a forwarding table miss. 158 4.1.5. QoS Exchange 160 ForCES may be used to exchange QoS capabilities between CEs and FEs. 161 For example, an FE may express QoS capabilities to the CE. Such 162 capabilities might include metering, policing, shaping, and queuing 163 functions. The CE may use ForCES to configure these capabilities. 165 4.1.6. Security Exchange 167 ForCES may be used to exchange Security information between CEs and FEs. 168 For example, the FE may use ForCES to express the types of encryption 169 that it is capable of using in an IPsec tunnel. The CE may use ForCES 170 to configure such a tunnel. 172 4.1.7. Filtering Exchange and Firewalls 174 ForCES may be used to exchange filtering information. For example, FEs 175 may use ForCES to express the filtering functions such as classification 176 and action that they can perform, and the CE may configure these 177 capabilities. 179 4.1.8. Encapsulation, Tunneling Exchange 181 ForCES may be used to exchange encapsulation capabilities of an FE, such 182 as tunneling, and the configuration of such capabilities. 184 4.1.9. NAT and Application-level Gateways 186 ForCES may be used to exchange configuration information for Network 187 Address Translators. Whilst ForCES is not specifically designed for the 188 configuration of application-level gateway functionality, this may be in 189 scope for some types of application-level gateways. 191 4.1.10. Measurement and Accounting 193 ForCES may be used to exchange configuration information regarding 194 traffic measurement and accounting functionality. In this area, ForCES 195 may overlap somewhat with functionality provided by alternative network 196 management mechanisms such as SNMP. In some cases ForCES may be used to 197 convey information to the CE to be reported externally using SNMP. 198 However, in other cases it may make more sense for the FE to directly 199 speak SNMP. 201 4.1.11. Diagnostics 203 ForCES may be used for CE's and FE's to exchange diagnostic information. 204 For example, an FE can send self-test results to the CE. 206 4.1.12. CE Redundancy or CE Failover 208 ForCES is a master-slave protocol where FE's are slaves and CE's are 209 masters. Basic mechanisms for CE redundancy/failover are provided in 210 ForCES protocol. Broad concepts such as implementing CE Redundancy, CE 211 Failover, and CE-CE communication, while not precluded by the ForCES 212 architecture, are considered outside the scope of ForCES protocol. 213 ForCES protocol is designed to handle CE-FE communication, and is not 214 intended for CE-CE communication. 216 4.2. CE-FE Link Capacity 218 When using ForCES, the bandwidth of the CE-FE link is a consideration, 219 and cannot be ignored. For example, sending a full routing table of 220 110K routes is reasonable over a 100Mbit Ethernet interconnect, but 221 could be non-trivial over a lower-bandwidth link. ForCES should be 222 sufficiently future-proof to be applicable in scenarios where routing 223 tables grow to several orders of magnitude greater than their current 224 size (approximately 100K routes). However, we also note that not all IP 225 routers need full routing tables. 227 4.3. CE/FE Locality 229 We do not intend ForCES to be applicable in configurations where the CE 230 and FE are located arbitrarily in the network. In particular, ForCES is 231 intended for environments where one of the following applies: 233 o The control interconnect is some form of local bus, switch, or LAN, 234 where reliability is high, closely controlled, and not susceptible 235 to external disruption that does not also affect the CEs and/or 236 FEs. 238 o The control interconnect shares fate with the FE's forwarding 239 function. Typically this is because the control connection is also 240 the FE's primary packet forwarding connection, and so if that link 241 goes down, the FE cannot forward packets anyway. 243 The key guideline is that the reliability of the device should not be 244 significantly reduced by the separation of control and forwarding 245 functionality. 247 ForCES is applicable in localities consisting of control and forwarding 248 elements which are either components in the same physical box, or are 249 separated at most by one local network hop (historically referred to as 250 "Very Close" localities). 252 Example: a network element with a single control blade, and one or more 253 forwarding blades, all present in the same chassis and sharing an 254 interconnect such as Ethernet or PCI. In this locality, the majority of 255 the data traffic being forwarded typically does not traverse the same 256 links as the ForCES control traffic. 258 5. Limitations and Out-of-Scope Items 260 ForCES was designed to enable logical separation of control and 261 forwarding planes in IP network devices. However, ForCES is not 262 intended to be applicable to all services or to all possible CE/FE 263 localities. 265 The purpose of this section is to list limitations and out-of-scope 266 items for ForCES. 268 5.1. Out of Scope Services 270 The following control-forwarding plane services are explicitly not 271 addressed by ForCES: 273 o Label Switching 275 o Multimedia Gateway Control (MEGACO). 277 5.1.1. Label Switching 279 Label Switching is the purview of the GSMP Working Group in the Sub- IP 280 Area of the IETF. GSMP is a general purpose protocol to control a label 281 switch. GSMP defines mechanisms to separate the label switch data plane 282 from the control plane label protocols such as LDP [5]. For more 283 information on GSMP, see [4]. 285 5.1.2. Separation of Control and Forwarding in Multimedia Gateways" 287 MEGACO defines a protocol used between elements of a physically 288 decomposed multimedia gateway. Separation of call control channels from 289 bearer channels is the purview of MEGACO. For more information on 290 MEGACO, see [7]. 292 5.2. Localities 294 ForCES protocol was intended to work within the localities described in 295 the last section. Outside these boundaries, care must be taken or the 296 protocol may not work right. Examples of localities where ForCES was 297 not originally intended to be used: 299 o Localities where there are multiple hops between CE and FE. 301 o Localities where hops between the CE and FE are dynamically routing 302 using IP routing protocols. 304 o Localities where the loss of the CE-FE link is of non-negligible 305 probability. 307 o Localities where two or more FEs controlled by the same CE cannot 308 communicate, either directly, or indirectly via other FEs 309 controlled by the same CE. 311 6. Security Considerations 313 The security of ForCES protocol will be addressed in the Protocol 314 Specification [2]. For security requirements, see architecture 315 requirement #5 and protocol requirement #2 in the Requirements Draft 316 [1]. The ForCES protocol assumes that the CE and FE are in the same 317 administration, and have shared secrets as a means of administration. 318 Whilst it might be technically feasible to have the CE and FE 319 administered independently, we strongly discourage such uses, because 320 they would require a significantly different trust model from that 321 ForCES assumes. 323 7. Normative 325 [1] Anderson, T et. al., "Requirements for Separation of IP Control and 326 Forwarding", draft-ietf-forces-requirements-09.txt, May 2003 328 [2] ForCES Protocol Specification (to-be-written) 330 8. Informative 332 [3] Salim, J e. al., "Netlink as an IP Services Protocol", draft-ietf- 333 forces-netlink-04.txt, December 2002 335 [4] Doria, A, Sundell, K, Hellstrand, F, Worster, T, "General Switch 336 Management Protocol (GSMP) V3" RFC 3292, June 2002 337 [5] Andersson et al., "LDP Specification" RFC 3036, January 2001 339 [6] Bradner, S, "Key words for use in RFCs to Indicate Requirement 340 Levels", RFC 2119, Harvard University, March 1997 342 [7] F. Cuervo et al., "Megaco Protocol Version 1.0" RFC 3015, November 343 2000 345 9. Acknowledgments 347 The authors wish to thank Jamal Hadi Salim, Hormuzd Khosravi, Vip 348 Sharma, and many others for their invaluable contributions. 350 10. Author's Addresses 352 Alan Crouch 353 Intel 354 2111 NE 25th Avenue 355 Hillsboro, OR 97124 USA 356 Phone: +1 503 264 2196 357 Email: alan.crouch@intel.com 359 Mark Handley 360 ICIR 361 1947 Center Street, Suite 600 362 Berkeley, CA 94708, USA 363 Email: mjh@icsi.berkeley.edu