idnits 2.17.1
draft-quinn-sfc-problem-statement-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
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.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (October 4, 2013) is 3849 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC2119' is defined on line 441, but no explicit
reference was found in the text
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Quinn
3 Internet-Draft J. Guichard
4 Intended status: Informational S. Kumar
5 Expires: April 7, 2014 Cisco Systems, Inc.
6 P. Agarwal
7 R. Manur
8 Broadcom
9 A. Chauhan
10 Citrix
11 N. Leymann
12 Deutsche Telekom
13 M. Boucadair
14 C. Jacquenet
15 France Telecom
16 M. Smith
17 N. Yadav
18 Insieme Networks
19 T. Nadeau
20 K. Gray
21 Juniper Networks
22 B. McConnell
23 Rackspace
24 K. Glavin
25 Riverbed
26 October 4, 2013
28 Service Function Chaining Problem Statement
29 draft-quinn-sfc-problem-statement-00.txt
31 Abstract
33 This document provides an overview of the issues associated with the
34 deployment of services functions (such as firewalls, load balancers)
35 in large-scale environments. The term service function chaining is
36 used to describe the deployment of such service functions, and the
37 ability of a network operator to specify an ordered list of service
38 functions that should be applied to a deterministic set of traffic
39 flows. Such service function chains require integration of service
40 policy alongside the deployment of applications, while allowing for
41 the optimal utilization of network resources.
43 Status of this Memo
45 This Internet-Draft is submitted in full conformance with the
46 provisions of BCP 78 and BCP 79.
48 Internet-Drafts are working documents of the Internet Engineering
49 Task Force (IETF). Note that other groups may also distribute
50 working documents as Internet-Drafts. The list of current Internet-
51 Drafts is at http://datatracker.ietf.org/drafts/current/.
53 Internet-Drafts are draft documents valid for a maximum of six months
54 and may be updated, replaced, or obsoleted by other documents at any
55 time. It is inappropriate to use Internet-Drafts as reference
56 material or to cite them other than as "work in progress."
58 This Internet-Draft will expire on April 7, 2014.
60 Copyright Notice
62 Copyright (c) 2013 IETF Trust and the persons identified as the
63 document authors. All rights reserved.
65 This document is subject to BCP 78 and the IETF Trust's Legal
66 Provisions Relating to IETF Documents
67 (http://trustee.ietf.org/license-info) in effect on the date of
68 publication of this document. Please review these documents
69 carefully, as they describe your rights and restrictions with respect
70 to this document. Code Components extracted from this document must
71 include Simplified BSD License text as described in Section 4.e of
72 the Trust Legal Provisions and are provided without warranty as
73 described in the Simplified BSD License.
75 Table of Contents
77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
78 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
79 2. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . 6
80 3. Service Function Chaining . . . . . . . . . . . . . . . . . . 9
81 4. Service Function Chaining Use Cases . . . . . . . . . . . . . 11
82 4.1. Enterprise Data Center Service Chaining . . . . . . . . . 11
83 4.2. Mobility Service Chaining . . . . . . . . . . . . . . . . 11
84 5. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 12
85 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
90 9.2. Informative References . . . . . . . . . . . . . . . . . . 16
91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
93 1. Introduction
95 Services that are composed of service functions require more flexible
96 service function deployment models than those typically available in
97 networks today. Such services may utilize traditional network
98 service functions (for example firewalls and server load balancers),
99 as well as higher layer applications and features. Services may be
100 delivered within a specific context so that isolated user groups
101 attached to a common network may be formed. Such user groups may
102 require unique capabilities with the ability to tailor service
103 characteristics on a per-tenant/per-subscriber/per-VPN basis that
104 must not affect other user groups
106 Current service function deployment models are relatively static in
107 that they are bound to fixed network topologies and resources. At
108 present, these deployments are not easily manipulated (i.e.: moved,
109 created or destroyed) even when virtualized elements are deployed.
110 This poses a problem in highly elastic service environments that
111 require relatively rapid creation, destruction or movement of real or
112 virtual service functions or network elements. Additionally, the
113 transition to virtual platforms requires an agile service insertion
114 model that supports elastic and very granular service delivery, and
115 post-facto modification; supports the movement of service functions
116 and application workloads in the existing network, all the while
117 retaining the network and service policies and the ability to easily
118 bind service policy to granular information such as per-subscriber
119 state.
121 This document outlines the problems encountered with existing service
122 deployment models for service function chaining (often referred to
123 simply as service chaining; in this document the terms will be used
124 interchangeably), as well as the problems of service chain creation/
125 deletion, policy integration with service chains, and policy
126 enforcement within the network infrastructure.
128 1.1. Definition of Terms
130 Classification: Locally instantiated policy and customer/network/
131 service profile matching of traffic flows for identification of
132 appropriate outbound forwarding actions.
134 Network Overlay: Logical network built on top of existing network
135 (the underlay). Packets are encapsulated or tunneled to create
136 the overlay network topology.
138 Service Chain: A service chain defines the required functions and
139 associated order (service-function1 --> service-function 2) that
140 must be applied to packets and/or frames. A service chain does
141 not specify the network location or specific instance of service
142 functions (e.g. firewall1 vs. firewall2).
144 Service Function: A network or application based packet treatment,
145 application, compute or storage resource, used singularly or in
146 concert with other service functions within a service chain to
147 enable a service offered by a network operator.
149 A non-exhaustive list of Service Functions includes: firewalls,
150 WAN and application acceleration, Deep Packet Inspection (DPI),
151 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID
152 injection, HTTP Header Enrichment functions, TCP optimizer, etc.
154 The generic term "L4-L7 services" is often used to describe many
155 service functions.
157 Service Node: Physical or virtual element providing one or more
158 service functions.
160 Network Service: An externally visible service offered by a network
161 operator; a service may consist of a single service function or a
162 composite built from several service functions executed in one or
163 more pre-determined sequences and delivered by one or more service
164 nodes.
166 2. Problem Areas
168 The following points describe aspects of existing service deployment
169 that are problematic, and are being addressed by the network service
170 chaining effort.
172 1. Topological Dependencies: Network service deployments are often
173 coupled to the physical network topology creating constraints on
174 service delivery and potentially inhibiting the network operator
175 from optimally utilizing service resources. This limits scale,
176 capacity, and redundancy across network resources.
178 These topologies serve only to "insert" the service function
179 (i.e. ensure that traffic traverse a service function); they are
180 not required from a native packet delivery perspective. For
181 example, firewalls often require an "in" and "out" layer-2
182 segment and adding a new firewall requires changing the topology
183 (i.e. adding new L2 segments).
185 As more service functions are required - often with strict
186 ordering - topology changes are needed before and after each
187 service function resulting in complex network changes and device
188 configuration. In such topologies, all traffic, whether a
189 service function needs to be applied or not, often passes
190 through the same strict order.
192 A common example is web servers using a server load balancer as
193 the default gateway. When the web service responds to non-load
194 balanced traffic (e.g. administrative or backup operations) all
195 traffic from the server must traverse the load balancer forcing
196 network administrators to create complex routing schemes or
197 create additional interfaces to provide an alternate topology.
199 2. Configuration complexity: A direct consequence of topological
200 dependencies is the complexity of the entire configuration,
201 specifically in deploying service chains. Simple actions such
202 as changing the order of the service functions in a service
203 chain require changes to the topology. Changes to the topology
204 are avoided by the network operator once installed, configured
205 and deployed in production environments fearing misconfiguration
206 and downtime. All of this leads to very static service delivery
207 models. Furthermore, the speed at which these topological
208 changes can be made is not rapid or dynamic enough as it often
209 requires manual intervention, or use of slow provisioning
210 systems.
212 The service itself can contribute to complexity: it may require
213 an intricate combination of very different capabilities,
214 regardless of the underlying topology. QoS-based, resilient VPN
215 service offerings are a typical example of such complexity.
217 3. Constrained High Availability: An effect of topological
218 dependency is constrained service function high availability.
219 Worse, when modified, inadvertent non-high availability can
220 result.
222 Since traffic reaches service functions based on network
223 topology, alternate, or redundant service functions must be
224 placed in the same topology as the primary service.
226 4. Consistent Ordering of Service Functions: Service functions are
227 typically independent; service function_1 (SF1)...service
228 function_n (SFn) are unrelated and there is no notion at the
229 service layer that SF1 occurs before SF2. However, to an
230 administrator many service functions have a strict ordering that
231 must be in place, yet the administrator has no consistent way to
232 impose and verify the ordering of the functions that used to
233 deliver a given service.
235 5. Service Chain Construction: Service chains today are most
236 typically built through manual configuration processes. These
237 are slow and error prone. With the advent of newer service
238 deployment models the control / management planes will provide
239 not only connectivity state, but will also be increasingly
240 utilized for the formation of services. Such a control /
241 management plane could be centrally controlled and managed, or
242 be distributed between a subset of end-systems.
244 6. Application of Service Policy: Service functions rely on
245 topology information such as VLANs or packet (re) classification
246 to determine service policy selection, i.e. the service function
247 specific action taken. Topology information is increasingly
248 less viable due to scaling, tenancy and complexity reasons. The
249 topological information is often stale, providing the operator
250 with inaccurate placement that can result in suboptimal resource
251 utilization. Per-service function packet classification is
252 inefficient and prone to errors, duplicating functionality
253 across service functions. Furthermore packet classification is
254 often too coarse lacking the ability to determine class of
255 traffic with enough detail.
257 7. Transport Dependence: Service functions can and will be deployed
258 in networks with a range of transports, including under and
259 overlays. The coupling of service functions to topology
260 requires service functions to support many transports or for a
261 transport gateway function to be present.
263 8. Elastic Service Delivery: Given the current state of the art for
264 adding/removing service functions largely centers around VLANs
265 and routing changes, rapid changes to the service layer can be
266 hard to realize due to the risk and complexity of such changes.
268 9. Traffic Selection Criteria: Traffic selection is coarse, that
269 is, all traffic on a particular segment traverse service
270 functions whether the traffic requires service enforcement or
271 not. This lack of traffic selection is largely due to the
272 topological nature of service deployment since the forwarding
273 topology dictates how (and what) data traverses service
274 function(s). In some deployments, more granular traffic
275 selection is achieved using policy routing or access control
276 filtering. This results in operationally complex configurations
277 and is still relatively inflexible.
279 10. Limited End-to-End Service Visibility: Troubleshooting service
280 related issues is a complex process that involve network and
281 service expertise. This is especially the case when service
282 chains span multiple DCs, or across administrative boundaries
283 such as externally consumable service chain components.
284 Furthermore, the physical and virtual environments (network and
285 service), can be highly divergent in terms of topology and that
286 topological variance adds to these challenges.
288 11. Per-Service (re)Classification: Classification occurs at each
289 service, independent from previously applied service functions.
290 These unrelated classification events consume resources per
291 service. More importantly, the classification functionality
292 often differs per service function and service function cannot
293 leverage the results from other deployed network or service.
295 12. Symmetric Traffic Flows: Service chains may be unidirectional or
296 bidirectional; unidirectional is one where traffic is passed
297 through a set of service functions in one forwarding direction
298 only. Bidirectional is one where traffic is passed through a
299 set of service functions in both forwarding directions.
300 Existing service deployment models provide a static approach to
301 realizing forward and reverse service chain association most
302 often requiring complex configuration of each network device
303 throughout the forwarding path.
305 13. Multi-vendor Service Functions: Deploying service functions from
306 multiple vendors often requires per-vendor expertise: insertion
307 models differ, there are limited common attributes and inter-
308 vendor service functions do not share information.
310 3. Service Function Chaining
312 Service chaining provides a framework to address the aforementioned
313 problems associated with service deployments:
315 1. Service Overlay: Service chaining utilizes a service specific
316 overlay that creates the service topology: the overlay creates a
317 path between service nodes. The service overlay is independent
318 of the network topology and allows operators to use whatever
319 overlay or underlay they prefer and to locate service functions
320 in the network as needed.
322 Within the service topology, service functions can be viewed as
323 resources for consumption and an arbitrary topology constructed
324 to connect those resources in a required order. Adding new
325 service functions to the topology is easily accomplished, and no
326 underlying network changes are required. Furthermore, additional
327 service instances, for redundancy or load distribution, can be
328 added or removed to the service topology as required.
330 Lastly, the service overlay can provide service specific
331 information needed for troubleshooting service-related issues.
333 2. Generic Service Control Plane (GSCP): GSCP provides information
334 about the available service functions on a network. The
335 information provided by the control plane includes service
336 network location (for topology creation), service type (e.g.
337 firewall, load balancer, etc.) and, optionally, administrative
338 information about the service functions such as load, capacity
339 and operating status. GSCP allows for the formulation of service
340 chains and disseminates the service chains to the network.
342 3. Service Classification: Classification is used to select which
343 traffic enters a service overlay. The granularity of the
344 classification varies based on device capabilities, customer
345 requirements, and service functionality. Initial classification
346 is used to start the service chain. Subsequent classification
347 can be used within a given service chain to alter the sequence of
348 service functions applied. Symmetric classification ensures that
349 forward and reverse chains are in place.
351 4. Dataplane Metadata: Dataplane metadata provides the ability to
352 exchange information between the network and service functions,
353 service functions and service functions and service functions and
354 the network. Metadata can include the result of antecedent
355 classification, information from external sources or forwarding
356 related data. For example, service functions utilize metadata,
357 as required, for localized policy decision. A common approach to
358 service metadata creates a common foundation for interoperability
359 between service functions, regardless of vendor.
361 4. Service Function Chaining Use Cases
363 The following sections provide high level overviews of several common
364 service chaining deployments.
366 4.1. Enterprise Data Center Service Chaining
368 TBD
370 4.2. Mobility Service Chaining
372 TBD
374 5. Related IETF Work
376 The following subsections discuss related IETF work and are provided
377 for reference. This section is not exhaustive, rather it provides an
378 overview of the various initiatives and how they relate to network
379 service chaining.
381 1. L3VPN[L3VPN]: The L3VPN working group is responsible for
382 defining, specifying and extending BGP/MPLS IP VPNs solutions.
383 Although BGP/MPLS IP VPNs can be used as transport for service
384 chaining deployments, the service chaining WG focuses on the
385 service specific protocols, not the general case of VPNs.
386 Furthermore, BGP/MPLS IP VPNs do not address the requirements for
387 service chaining.
389 2. LISP[LISP]: LISP provides locator and ID separation. LISP can be
390 used as an L3 overlay to transport service chaining data but does
391 not address the specific service chaining problems highlighted in
392 this document.
394 3. NVO3[NVO3]: The NVO3 working group is chartered with creation of
395 problem statement and requirements documents for multi-tenant
396 network overlays. NVO3 WG does not address service chaining
397 protocols.
399 4. ALTO[ALTO]: The Application Layer Traffic Optimization Working
400 Group is chartered to provide topological information at a higher
401 abstraction layer, which can be based upon network policy, and
402 with application-relevant service functions located in it. The
403 mechanism for ALTO obtaining the topology can vary and policy can
404 apply to what is provided or abstracted. This work could be
405 leveraged and extended to address the need for services
406 discovery.
408 5. I2RS[I2RS]: The Interface to the Routing System Working Group is
409 chartered to investigate the rapid programming of a device's
410 routing system, as well as the service of a generalized, multi-
411 layered network topology. This work could be leveraged and
412 extended to address some of the needs for service chaining in the
413 topology and device programming areas.
415 6. Summary
417 This document highlights problems associated with network service
418 deployment today and identifies several key areas that will be
419 addressed by the service chaining working group. Furthermore, this
420 document identifies four components that are the basis for serice
421 chaining. These components will form the areas of focus for the
422 working group.
424 7. Security Considerations
426 Security considerations are not addressed in this problem statement
427 only document. Given the scope of service chaining, and the
428 implications on data and control planes, security considerations are
429 clearly important and will be addressed in the specific protocol and
430 deployment documents created by the service chaining working group.
432 8. Acknowledgments
434 The authors would like to thank David Ward, Rex Fernando and Jim
435 French for their contributions.
437 9. References
439 9.1. Normative References
441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
442 Requirement Levels", BCP 14, RFC 2119, March 1997.
444 9.2. Informative References
446 [ALTO] "Application-Layer Traffic Optimization (alto)",
447 .
449 [I2RS] "Interface to the Routing System (i2rs)",
450 .
452 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)",
453 .
455 [LISP] "Locator/ID Separation Protocol (lisp)",
456 .
458 [NVO3] "Network Virtualization Overlays (nvo3)",
459 .
461 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
462 Address Translator (Traditional NAT)", RFC 3022,
463 January 2001.
465 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
466 NAT64: Network Address and Protocol Translation from IPv6
467 Clients to IPv4 Servers", RFC 6146, April 2011.
469 Authors' Addresses
471 Paul Quinn
472 Cisco Systems, Inc.
474 Email: paulq@cisco.com
476 Jim Guichard
477 Cisco Systems, Inc.
479 Email: jguichar@cisco.com
481 Surendra Kumar
482 Cisco Systems, Inc.
484 Email: smkumar@cisco.com
486 Puneet Agarwal
487 Broadcom
489 Email: pagarwal@broadcom.com
491 Rajeev Manur
492 Broadcom
494 Email: rmanur@broadcom.com
496 Abhishek Chauhan
497 Citrix
499 Email: Abhishek.Chauhan@citrix.com
501 Nic Leymann
502 Deutsche Telekom
504 Email: n.leymann@telekom.de
505 Mohamed Boucadair
506 France Telecom
508 Email: mohamed.boucadair@orange.com
510 Christian Jacquenet
511 France Telecom
513 Email: christian.jacquenet@orange.com
515 Michael Smith
516 Insieme Networks
518 Email: michsmit@insiemenetworks.com
520 Navindra Yadav
521 Insieme Networks
523 Email: nyadav@insiemenetworks.com
525 Thomas Nadeau
526 Juniper Networks
528 Email: tnadeau@juniper.net
530 Ken Gray
531 Juniper Networks
533 Email: kgray@juniper.net
535 Brad McConnell
536 Rackspace
538 Email: bmcconne@rackspace.com
540 Kevin Glavin
541 Riverbed
543 Email: Kevin.Glavin@riverbed.com