idnits 2.17.1
draft-ietf-sfc-problem-statement-09.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 :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (August 8, 2014) is 3550 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Quinn, Ed.
3 Internet-Draft Cisco Systems, Inc.
4 Intended status: Informational T. Nadeau, Ed.
5 Expires: February 9, 2015 Brocade
6 August 8, 2014
8 Service Function Chaining Problem Statement
9 draft-ietf-sfc-problem-statement-09.txt
11 Abstract
13 This document provides an overview of the issues associated with the
14 deployment of service functions (such as firewalls, load balancers)
15 in large-scale environments. The term service function chaining is
16 used to describe the definition and instantiation of an ordered set
17 of instances of such service functions, and the subsequent "steering"
18 of traffic flows through those service functions.
20 The set of enabled service function chains reflect operator service
21 offerings and is designed in conjunction with application delivery
22 and service and network policy.
24 Status of this Memo
26 This Internet-Draft is submitted in full conformance with the
27 provisions of BCP 78 and BCP 79.
29 Internet-Drafts are working documents of the Internet Engineering
30 Task Force (IETF). Note that other groups may also distribute
31 working documents as Internet-Drafts. The list of current Internet-
32 Drafts is at http://datatracker.ietf.org/drafts/current/.
34 Internet-Drafts are draft documents valid for a maximum of six months
35 and may be updated, replaced, or obsoleted by other documents at any
36 time. It is inappropriate to use Internet-Drafts as reference
37 material or to cite them other than as "work in progress."
39 This Internet-Draft will expire on February 9, 2015.
41 Copyright Notice
43 Copyright (c) 2014 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
56 Table of Contents
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
60 2. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5
61 2.1. Topological Dependencies . . . . . . . . . . . . . . . . . 5
62 2.2. Configuration complexity . . . . . . . . . . . . . . . . . 5
63 2.3. Constrained High Availability . . . . . . . . . . . . . . 6
64 2.4. Consistent Ordering of Service Functions . . . . . . . . . 6
65 2.5. Application of Service Policy . . . . . . . . . . . . . . 6
66 2.6. Transport Dependence . . . . . . . . . . . . . . . . . . . 7
67 2.7. Elastic Service Delivery . . . . . . . . . . . . . . . . . 7
68 2.8. Traffic Selection Criteria . . . . . . . . . . . . . . . . 7
69 2.9. Limited End-to-End Service Visibility . . . . . . . . . . 7
70 2.10. Per-Service Function (re)Classification . . . . . . . . . 7
71 2.11. Symmetric Traffic Flows . . . . . . . . . . . . . . . . . 8
72 2.12. Multi-vendor Service Functions . . . . . . . . . . . . . . 8
73 3. Service Function Chaining . . . . . . . . . . . . . . . . . . 9
74 3.1. Service Overlay . . . . . . . . . . . . . . . . . . . . . 9
75 3.2. Service Classification . . . . . . . . . . . . . . . . . . 9
76 3.3. Dataplane Metadata . . . . . . . . . . . . . . . . . . . . 9
77 4. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 11
78 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
82 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
83 10. Informative References . . . . . . . . . . . . . . . . . . . . 18
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
86 1. Introduction
88 The delivery of end-to-end services often require various service
89 functions including traditional network service functions (for
90 example firewalls and server load balancers), as well as application-
91 specific features. Service functions may be delivered within the
92 context of an isolated user group, or shared amongst many users/user
93 groups.
95 Current service function deployment models are relatively static in
96 that they are tightly coupled to network topology and physical
97 resources. The result of that static nature of existing deployments
98 greatly reduces, and in many cases, limits the ability of an operator
99 to introduce new services and/or service functions. Furthermore
100 there is a cascading effect: service changes affect other services.
102 This document outlines the problems encountered with existing service
103 deployment models for Service Function Chaining (SFC) (often referred
104 to simply as service chaining; in this document the terms will be
105 used interchangeably), as well as the problems of service chain
106 creation, deletion, modification/update, policy integration with
107 service chains, and policy enforcement within the network
108 infrastructure.
110 1.1. Definition of Terms
112 Classification: Locally instantiated policy that results in matching
113 of traffic flows for identification of appropriate outbound
114 forwarding actions.
116 Network Overlay: Locally instantiated policy and customer/network/
117 service profile matching of traffic flows for identification of
118 appropriate outbound forwarding actions.
120 Network Service: An offering provided by an operator that is
121 delivered using one or more service functions. This may also be
122 referred to as a composite service. The term "service" is used to
123 denote a "network service" in the context of this document.
125 Service Function: A function that is responsible for specific
126 treatment of received packets. A Service Function can act at the
127 network layer or other OSI layers. A Service Function can be a
128 virtual instance or be embedded in a physical network element.
129 One of multiple Service Functions can be embedded in the same
130 network element. Multiple instances of the Service Function can
131 be enabled in the same administrative domain.
133 A non-exhaustive list of Service Functions includes: firewalls,
134 WAN and application acceleration, Deep Packet Inspection (DPI),
135 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID
136 injection [RFC6967], HTTP Header Enrichment functions, TCP
137 optimizer, etc.
139 The generic term "L4-L7 services" is often used to describe many
140 service functions.
142 Service Function Chain (SFC): A service Function chain defines an
143 abstract set of service functions and their ordering constraints
144 that must be applied to packets and/or frames selected as a result
145 of classification. The implied order may not be a linear
146 progression as the architecture allows for nodes that copy to more
147 than one branch, and also allows for cases where there is
148 flexibility in the order in which services need to be applied.
149 The term service chain is often used as shorthand for service
150 function chain.
152 Service Overlay: An overlay network created for the purpose of
153 forwarding data to required service functions.
155 Service Topology: The service overlay connectivity forms a service
156 topology.
158 2. Problem Space
160 The following points describe aspects of existing service deployments
161 that are problematic, and that the Service Function Chaining (SFC)
162 working group aims to address.
164 2.1. Topological Dependencies
166 Network service deployments are often coupled to network topology,
167 whether it be physical or virtualized, or a hybrid of the two. Such
168 dependency imposes constraints on the service delivery, potentially
169 inhibiting the network operator from optimally utilizing service
170 resources, and reduces the flexibility. This limits scale, capacity,
171 and redundancy across network resources.
173 These topologies serve only to "insert" the service function (i.e.,
174 ensure that traffic traverses a service function); they are not
175 required from a native packet delivery perspective. For example,
176 firewalls often require an "in" and "out" layer-2 segment and adding
177 a new firewall requires changing the topology (i.e., adding new
178 layer-2 segments).
180 As more service functions are required - often with strict ordering -
181 topology changes are needed before and after each service function
182 resulting in complex network changes and device configuration. In
183 such topologies, all traffic, whether a service function needs to be
184 applied or not, often passes through the same strict order.
186 The topological coupling limits placement and selection of service
187 functions: service functions are "fixed" in place by topology and
188 therefore placement and service function selection taking into
189 account network topology information is not viable. Furthermore,
190 altering the services traversed, or their order, based on flow
191 direction is not possible.
193 A common example is web servers using a server load balancer as the
194 default gateway. When the web service responds to non-load balanced
195 traffic (e.g., administrative or backup operations) all traffic from
196 the server must traverse the load balancer forcing network
197 administrators to create complex routing schemes or create additional
198 interfaces to provide an alternate topology.
200 2.2. Configuration complexity
202 A direct consequence of topological dependencies is the complexity of
203 the entire configuration, specifically in deploying service function
204 chains. Simple actions such as changing the order of the service
205 functions in a service function chain require changes to the
206 topology. Changes to the topology are avoided by the network
207 operator once installed, configured and deployed in production
208 environments for fear of misconfiguration and consequent downtime.
209 All of this leads to very static service delivery deployments.
210 Furthermore, the speed at which these topological changes can be made
211 is not rapid or dynamic enough as it often requires manual
212 intervention, or use of slow provisioning systems.
214 2.3. Constrained High Availability
216 An effect of topological dependency is constrained service function
217 high availability. Worse, when modified, inadvertent non-high
218 availability or downtime can result.
220 Since traffic reaches many service functions based on network
221 topology, alternate, or redundant service functions must be placed in
222 the same topology as the primary service.
224 2.4. Consistent Ordering of Service Functions
226 Service functions are typically independent; service function_1
227 (SF1)...service function_n (SFn) are unrelated and there is no notion
228 at the service layer that SF1 occurs before SF2. However, to an
229 administrator many service functions have a strict ordering that must
230 be in place, yet the administrator has no consistent way to impose
231 and verify the ordering of the service functions that are used to
232 deliver a given service.
234 Service function chains today are most typically built through manual
235 configuration processes. These are slow and error prone. With the
236 advent of newer service deployment models the control and policy
237 planes provide not only connectivity state, but will also be
238 increasingly utilized for the creation of network services. Such
239 control/management planes could be centralized, or be distributed.
241 2.5. Application of Service Policy
243 Service functions rely on topology information such as VLANs or
244 packet (re) classification to determine service policy selection,
245 i.e. the service function specific action taken. Topology
246 information is increasingly less viable due to scaling, tenancy and
247 complexity reasons. The topological information is often stale,
248 providing the operator with inaccurate placement that can result in
249 suboptimal resource utilization. Furthermore topology-centric
250 information often does not convey adequate information to the service
251 functions, forcing functions to individually perform more granular
252 classification.
254 2.6. Transport Dependence
256 Service functions can and will be deployed in networks with a range
257 of transports, including under and overlays. The coupling of service
258 functions to topology requires service functions to support many
259 transport encapsulations or for a transport gateway function to be
260 present.
262 2.7. Elastic Service Delivery
264 Given that the current state of the art for adding/removing service
265 functions largely centers around VLANs and routing changes, rapid
266 changes to the service deployment can be hard to realize due to the
267 risk and complexity of such changes.
269 2.8. Traffic Selection Criteria
271 Traffic selection is coarse, that is, all traffic on a particular
272 segment traverse service functions whether the traffic requires
273 service enforcement or not. This lack of traffic selection is
274 largely due to the topological nature of service deployment since the
275 forwarding topology dictates how (and what) data traverses service
276 function(s). In some deployments, more granular traffic selection is
277 achieved using policy routing or access control filtering. This
278 results in operationally complex configurations and is still
279 relatively inflexible.
281 2.9. Limited End-to-End Service Visibility
283 Troubleshooting service related issues is a complex process that
284 involve both network-specific and service-specific expertise. This
285 is especially the case when service function chains span multiple
286 DCs, or across administrative boundaries. Furthermore, the physical
287 and virtual environments (network and service), can be highly
288 divergent in terms of topology and that topological variance adds to
289 these challenges.
291 2.10. Per-Service Function (re)Classification
293 Classification occurs at each service function independent from
294 previously applied service functions. More importantly, the
295 classification functionality often differs per service function and
296 service functions may not leverage the results from other service
297 functions.
299 2.11. Symmetric Traffic Flows
301 Service function chains may be unidirectional or bidirectional
302 depending on the state requirements of the service functions. In a
303 unidirectional chain traffic is passed through a set of service
304 functions in one forwarding direction only. Bidirectional chains
305 require traffic to be passed through a set of service functions in
306 both forwarding directions. Many common service functions such as
307 DPI and firewall often require bidirectional chaining in order to
308 ensure flow state is consistent.
310 Existing service deployment models provide a static approach to
311 realizing forward and reverse service function chain association most
312 often requiring complex configuration of each network device
313 throughout the SFC.
315 2.12. Multi-vendor Service Functions
317 Deploying service functions from multiple vendors often require per-
318 vendor expertise: insertion models differ, there are limited common
319 attributes and inter-vendor service functions do not share
320 information.
322 3. Service Function Chaining
324 Service Function Chaining aims to address the aforementioned problems
325 associated with service deployment. Concretely, the SFC working
326 group will investigate solutions that address the following elements:
328 3.1. Service Overlay
330 Service function chaining utilizes a service specific overlay that
331 creates the service topology. The service overlay provides service
332 function connectivity and is built "on top" of the existing network
333 topology and allows operators to use whatever overlay or underlay
334 they prefer to create a path between service functions, and to locate
335 service functions in the network as needed.
337 Within the service topology, service functions can be viewed as
338 resources for consumption and an arbitrary topology constructed to
339 connect those resources in a required order. Adding new service
340 functions to the topology is easily accomplished, and no underlying
341 network changes are required.
343 Lastly, the service overlay can provide service specific information
344 needed for troubleshooting service-related issues.
346 3.2. Service Classification
348 Classification is used to select which traffic enters a service
349 overlay. The granularity of the classification varies based on
350 device capabilities, customer requirements, and service offered.
351 Initial classification determines the service function chain required
352 to process the traffic. Subsequent classification can be used within
353 a given service function chain to alter the sequence of service
354 functions applied. Symmetric classification ensures that forward and
355 reverse chains are in place. Similarly, asymmetric -- relative to
356 required service function -- chains can be achieved via service
357 classification.
359 3.3. Dataplane Metadata
361 Data plane metadata provides the ability to exchange information
362 between logical classification points and service functions (and vice
363 versa) and between service functions. As such metadata is not used
364 as forwarding information to deliver packets along the service
365 overlay.
367 Metadata can include the result of antecedent classification and/or
368 information from external sources. Service functions utilize
369 metadata, as required, for localized policy decisions.
371 In addition to sharing of information, the use of metadata addresses
372 several of the issues raised in section 2, most notably the
373 decoupling of policy from the network topology, and the need for per-
374 service function classification (and re-classification).
376 A common approach to service metadata creates a common foundation for
377 interoperability between service functions, regardless of vendor.
379 4. Related IETF Work
381 The following subsections discuss related IETF work and are provided
382 for reference. This section is not exhaustive, rather it provides an
383 overview of the various initiatives and how they relate to network
384 service chaining.
386 1. [L3VPN]: The L3VPN working group is responsible for defining,
387 specifying and extending BGP/MPLS IP VPNs solutions. Although
388 BGP/MPLS IP VPNs can be used as transport for service chaining
389 deployments, the SFC WG focuses on the service specific
390 protocols, not the general case of VPNs. Furthermore, BGP/MPLS
391 IP VPNs do not address the requirements for service chaining.
393 2. [LISP]: LISP provides locator and ID separation. LISP can be
394 used as an L3 overlay to transport service chaining data but does
395 not address the specific service chaining problems highlighted in
396 this document.
398 3. [NVO3]: The NVO3 working group is chartered with creation of
399 problem statement and requirements documents for multi-tenant
400 network overlays. NVO3 WG does not address service chaining
401 protocols.
403 4. [ALTO]: The Application Layer Traffic Optimization Working Group
404 is chartered to provide topological information at a higher
405 abstraction layer, which can be based upon network policy, and
406 with application-relevant service functions located in it. The
407 mechanism for ALTO obtaining the topology can vary and policy can
408 apply to what is provided or abstracted. This work could be
409 leveraged and extended to address the need for services
410 discovery.
412 5. [I2RS]: The Interface to the Routing System Working Group is
413 chartered to investigate the rapid programming of a device's
414 routing system, as well as the service of a generalized, multi-
415 layered network topology. This work could be leveraged and
416 extended to address some of the needs for service chaining in the
417 topology and device programming areas.
419 6. [ForCES]: The ForCES working group has created a framework,
420 requirements, a solution protocol, a logical function block
421 library, and other associated documents in support of Forwarding
422 and Control Element Separation. The work done by ForCES may
423 provide a basis for both the separation of SFC elements, as well
424 as provide protocol and design guidance for those elements.
426 5. Summary
428 This document highlights problems associated with network service
429 deployment today and identifies several key areas that will be
430 addressed by the SFC working group. Furthermore, this document
431 identifies three components that are the basis for service function
432 chaining. These components will form the areas of focus for the
433 working group.
435 6. IANA Considerations
437 This document makes no request to IANA.
439 7. Security Considerations
441 Security considerations are not addressed in this problem statement
442 only document. Given the scope of service chaining, and the
443 implications on data and control planes, security considerations are
444 clearly important and will be addressed in the specific protocol and
445 deployment documents created by the SFC WG.
447 8. Contributors
449 The following people are active contributors to this document and
450 have provided review, content and concepts (listed alphabetically by
451 surname):
453 Puneet Agarwal
454 Broadcom
455 Email: pagarwal@broadcom.com
457 Mohamed Boucadair
458 France Telecom
459 Email: mohamed.boucadair@orange.com
461 Abhishek Chauhan
462 Citrix
463 Email: Abhishek.Chauhan@citrix.com
465 Uri Elzur
466 Intel
467 Email: uri.elzur@intel.com
469 Kevin Glavin
470 Riverbed
471 Email: Kevin.Glavin@riverbed.com
473 Ken Gray
474 Cisco Systems
475 Email: kegray@cisco.com
477 Jim Guichard
478 Cisco Systems
479 Email:jguichar@cisco.com
481 Christian Jacquenet
482 France Telecom
483 Email: christian.jacquenet@orange.com
485 Surendra Kumar
486 Cisco Systems
487 Email: smkumar@cisco.com
489 Nic Leymann
490 Deutsche Telekom
491 Email: n.leymann@telekom.de
493 Darrel Lewis
494 Cisco Systems
495 Email: darlewis@cisco.com
497 Rajeev Manur
498 Broadcom
499 Email:rmanur@broadcom.com
501 Brad McConnell
502 Rackspace
503 Email: bmcconne@rackspace.com
505 Carlos Pignataro
506 Cisco Systems
507 Email: cpignata@cisco.com
509 Michael Smith
510 Cisco Systems
511 Email: michsmit@cisco.com
513 Navindra Yadav
514 Cisco Systems
515 Email: nyadav@cisco.com
517 9. Acknowledgments
519 The authors would like to thank David Ward, Rex Fernando, David
520 Mcdysan, Jamal Hadi Salim, Charles Perkins, Andre Beliveau, Joel
521 Halpern and Jim French for their reviews and comments.
523 10. Informative References
525 [ALTO] "Application-Layer Traffic Optimization (alto)",
526 .
528 [ForCES] "Forwarding and Control Element Separation (forces)",
529 .
531 [I2RS] "Interface to the Routing System (i2rs)",
532 .
534 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)",
535 .
537 [LISP] "Locator/ID Separation Protocol (lisp)",
538 .
540 [NVO3] "Network Virtualization Overlays (nvo3)",
541 .
543 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
544 Address Translator (Traditional NAT)", RFC 3022,
545 January 2001.
547 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
548 NAT64: Network Address and Protocol Translation from IPv6
549 Clients to IPv4 Servers", RFC 6146, April 2011.
551 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
552 "Analysis of Potential Solutions for Revealing a Host
553 Identifier (HOST_ID) in Shared Address Deployments",
554 RFC 6967, June 2013.
556 Authors' Addresses
558 Paul Quinn (editor)
559 Cisco Systems, Inc.
561 Email: paulq@cisco.com
563 Thomas Nadeau (editor)
564 Brocade
566 Email: tnadeau@lucidvision.com