idnits 2.17.1
draft-ietf-sfc-problem-statement-02.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 (February 14, 2014) is 3723 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
No issues found here.
Summary: 1 error (**), 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: August 18, 2014 Brocade
6 February 14, 2014
8 Service Function Chaining Problem Statement
9 draft-ietf-sfc-problem-statement-02.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 such service functions, and the subsequent "steering" of traffic
18 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 August 18, 2014.
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 3. Service Function Chaining . . . . . . . . . . . . . . . . . . 9
62 4. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 11
63 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
65 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
67 9. Informative References . . . . . . . . . . . . . . . . . . . . 17
68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
70 1. Introduction
72 The delivery of end-to-end services often require various Service
73 Functions (SF) including traditional network service functions (for
74 example firewalls and server load balancers), as well as application-
75 specific features. Service functions may be delivered within the
76 context of an isolated user group, or shared amongst many users/user
77 groups
79 Current service function deployment models are relatively static in
80 that they are tightly coupled to network topology and physical
81 resources. The result of that static nature of existing deployments
82 greatly reduces, and in many cases, limits the ability of an operator
83 to introduce new services and/or service functions. Furthermore
84 there is a cascading effect: service changes affect other services.
86 This document outlines the problems encountered with existing service
87 deployment models for Service Function Chaining (SFC) (often referred
88 to simply as service chaining; in this document the terms will be
89 used interchangeably), as well as the problems of service chain
90 creation/ deletion, policy integration with service chains, and
91 policy enforcement within the network infrastructure.
93 1.1. Definition of Terms
95 Classification: Locally instantiated policy that results in matching
96 of traffic flows for identification of appropriate outbound
97 forwarding actions.
99 Network Overlay: A logical network built, via virtual links or
100 packet encapsulation, over an existing network (the underlay).
102 Service Function Chain (SFC): A service Function chain defines an
103 ordered set of service functions that must be applied to packets
104 and/or frames selected as a result of classification. The implied
105 order may not be a linear progression as nodes may copy to more
106 than one branch. The term service chain is often used as
107 shorthand for service function chain.
109 Service Function: A function that is responsible for specific
110 treatment of received packets. A Service Function can act at the
111 network layer or other OSI layers. A Service Function can be a
112 virtual instance or be embedded in a physical network element.
113 One of multiple Service Functions can be embedded in the same
114 network element. Multiple instances of the Service Function can
115 be enabled in the same administrative domain.
117 A non-exhaustive list of Service Functions includes: firewalls,
118 WAN and application acceleration, Deep Packet Inspection (DPI),
119 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID
120 injection [RFC6967], HTTP Header Enrichment functions, TCP
121 optimizer, etc.
123 The generic term "L4-L7 services" is often used to describe many
124 service functions.
126 Service Node: Service Node (SN): Physical or virtual element that
127 hosts one or more service functions.
129 Network Service: An externally visible service offered by a network
130 operator; a service may consist of a single service function or a
131 composite built from several service functions executed in one or
132 more pre-determined sequences and delivered by one or more service
133 nodes.
135 2. Problem Space
137 The following points describe aspects of existing service deployments
138 that are problematic, and are being addressed by the Service Function
139 Chaining effort.
141 1. Topological Dependencies: Network service deployments are often
142 coupled to network topology. Such dependency imposes
143 constraints on the service delivery, potentially inhibiting the
144 network operator from optimally utilizing service resources, and
145 reduces the flexibility. This limits scale, capacity, and
146 redundancy across network resources.
148 These topologies serve only to "insert" the service function
149 (i.e., ensure that traffic traverses a service function); they
150 are not required from a native packet delivery perspective. For
151 example, firewalls often require an "in" and "out" layer-2
152 segment and adding a new firewall requires changing the topology
153 (i.e., adding new layer-2 segments).
155 As more service functions are required - often with strict
156 ordering - topology changes are needed before and after each
157 service function resulting in complex network changes and device
158 configuration. In such topologies, all traffic, whether a
159 service function needs to be applied or not, often passes
160 through the same strict order.
162 The topological coupling limits placement and selection of
163 service functions: service functions are "fixed" in place by
164 topology and therefore placement and service function selection
165 taking into account network topology information is not viable.
167 A common example is web servers using a server load balancer as
168 the default gateway. When the web service responds to non-load
169 balanced traffic (e.g., administrative or backup operations) all
170 traffic from the server must traverse the load balancer forcing
171 network administrators to create complex routing schemes or
172 create additional interfaces to provide an alternate topology.
174 2. Configuration complexity: A direct consequence of topological
175 dependencies is the complexity of the entire configuration,
176 specifically in deploying service function chains. Simple
177 actions such as changing the order of the service functions in a
178 service function chain require changes to the topology. Changes
179 to the topology are avoided by the network operator once
180 installed, configured and deployed in production environments
181 fearing misconfiguration and downtime. All of this leads to
182 very static service delivery deployments. Furthermore, the
183 speed at which these topological changes can be made is not
184 rapid or dynamic enough as it often requires manual
185 intervention, or use of slow provisioning systems.
187 The service itself can contribute to the complexity: it may
188 require an intricate combination of very different capabilities,
189 regardless of the underlying topology. QoS-based, resilient VPN
190 service offerings are a typical example of such complex service
191 offerings.
193 3. Constrained High Availability: An effect of topological
194 dependency is constrained service function high availability.
195 Worse, when modified, inadvertent non-high availability or
196 downtime can result.
198 Since traffic reaches many service functions based on network
199 topology, alternate, or redundant service functions must be
200 placed in the same topology as the primary service.
202 4. Consistent Ordering of Service Functions: Service functions are
203 typically independent; service function_1 (SF1)...service
204 function_n (SFn) are unrelated and there is no notion at the
205 service layer that SF1 occurs before SF2. However, to an
206 administrator many service functions have a strict ordering that
207 must be in place, yet the administrator has no consistent way to
208 impose and verify the ordering of the functions that are used to
209 deliver a given service.
211 5. Service Chain Construction: Service function chains today are
212 most typically built through manual configuration processes.
213 These are slow and error prone. With the advent of newer
214 service deployment models the control/management planes provide
215 not only connectivity state, but will also be increasingly
216 utilized for the creation of network services. Such a control/
217 management planes could be centralized, or be distributed.
219 6. Application of Service Policy: Service functions rely on
220 topology information such as VLANs or packet (re) classification
221 to determine service policy selection, i.e. the service function
222 specific action taken. Topology information is increasingly
223 less viable due to scaling, tenancy and complexity reasons. The
224 topological information is often stale, providing the operator
225 with inaccurate placement that can result in suboptimal resource
226 utilization. Furthermore topology-centric information often
227 does not convey adequate information to the service functions,
228 forcing functions to individually perform more granular
229 classification.
231 7. Transport Dependence: Service functions can and will be deployed
232 in networks with a range of transports, including under and
233 overlays. The coupling of service functions to topology
234 requires service functions to support many transports or for a
235 transport gateway function to be present.
237 8. Elastic Service Delivery: Given the current state of the art for
238 adding/removing service functions largely centers around VLANs
239 and routing changes, rapid changes to the service deployment can
240 be hard to realize due to the risk and complexity of such
241 changes.
243 9. Traffic Selection Criteria: Traffic selection is coarse, that
244 is, all traffic on a particular segment traverse service
245 functions whether the traffic requires service enforcement or
246 not. This lack of traffic selection is largely due to the
247 topological nature of service deployment since the forwarding
248 topology dictates how (and what) data traverses service
249 function(s). In some deployments, more granular traffic
250 selection is achieved using policy routing or access control
251 filtering. This results in operationally complex configurations
252 and is still relatively inflexible.
254 10. Limited End-to-End Service Visibility: Troubleshooting service
255 related issues is a complex process that involve both network-
256 specific and service-specific expertise. This is especially the
257 case when service function chains span multiple DCs, or across
258 administrative boundaries. Furthermore, the physical and
259 virtual environments (network and service), can be highly
260 divergent in terms of topology and that topological variance
261 adds to these challenges.
263 11. Per-Service (re)Classification: Classification occurs at each
264 service function independent from previously applied service
265 functions. More importantly, the classification functionality
266 often differs per service function and service functions may not
267 leverage the results from other service functions.
269 12. Symmetric Traffic Flows: Service function chains may be
270 unidirectional or bidirectional; unidirectional is one where
271 traffic is passed through a set of service functions in one
272 forwarding direction only. Bidirectional is one where traffic
273 is passed through a set of service functions in both forwarding
274 directions. Existing service deployment models provide a static
275 approach to realizing forward and reverse service function chain
276 association most often requiring complex configuration of each
277 network device throughout the forwarding path.
279 13. Multi-vendor Service Functions: Deploying service functions from
280 multiple vendors often require per-vendor expertise: insertion
281 models differ, there are limited common attributes and inter-
282 vendor service functions do not share information.
284 3. Service Function Chaining
286 Service Function Chaining aims to address the aforementioned problems
287 associated with service deployment. Concretely, SFC will investigate
288 solutions that address the following elements:
290 1. Service Overlay: Service function chaining utilizes a service
291 specific overlay that creates the service topology. The service
292 overlay is independent of the network topology and allows
293 operators to use whatever overlay or underlay they prefer to
294 create a path between service functions, and to locate service
295 functions in the network as needed.
297 Within the service topology, service functions can be viewed as
298 resources for consumption and an arbitrary topology constructed
299 to connect those resources in a required order. Adding new
300 service functions to the topology is easily accomplished, and no
301 underlying network changes are required.
303 Lastly, the service overlay can provide service specific
304 information needed for troubleshooting service-related issues.
306 2. Control Plane: Service aware control plane(s) provide information
307 about the available service functions on a network. The
308 information provided by the control plane includes service
309 network location (for topology creation), service type (e.g.
310 firewall, load balancer, etc.) and, optionally, administrative
311 information about the service functions such as load, capacity
312 and operating status. The service aware control plane allows for
313 the formulation of service function chains and exchanges
314 requisite information needed to instantiate the service function
315 chains in the network.
317 Furthermore, the service aware control plane may interact with
318 the topology aware control plane (if separate) to ensure optimal
319 selection (and possibly placement) of service function within a
320 service path.
322 3. Service Classification: Classification is used to select which
323 traffic enters a service overlay. The granularity of the
324 classification varies based on device capabilities, customer
325 requirements, and service offered. Initial classification is
326 used to start the service function chain. Subsequent
327 classification can be used within a given service function chain
328 to alter the sequence of service functions applied. Symmetric
329 classification ensures that forward and reverse chains are in
330 place.
332 4. Dataplane Metadata: Data plane metadata provides the ability to
333 exchange information between the network and service functions,
334 between service functions, and service functions and the network.
335 Metadata can include the result of antecedent classification,
336 information from external sources or forwarding related data.
337 For example, service functions utilize metadata, as required, for
338 localized policy decisions.
340 In addition to sharing of information, the use of metadata
341 addresses several of the issues raised in section 2, most notably
342 the de-coupling of policy from the topology, and the need for
343 per-service classification (and re-classification).
345 A common approach to service metadata creates a common foundation
346 for interoperability between service functions, regardless of
347 vendor.
349 4. Related IETF Work
351 The following subsections discuss related IETF work and are provided
352 for reference. This section is not exhaustive, rather it provides an
353 overview of the various initiatives and how they relate to network
354 service chaining.
356 1. [L3VPN]: The L3VPN working group is responsible for defining,
357 specifying and extending BGP/MPLS IP VPNs solutions. Although
358 BGP/MPLS IP VPNs can be used as transport for service chaining
359 deployments, the service chaining WG focuses on the service
360 specific protocols, not the general case of VPNs. Furthermore,
361 BGP/MPLS IP VPNs do not address the requirements for service
362 chaining.
364 2. [LISP]: LISP provides locator and ID separation. LISP can be
365 used as an L3 overlay to transport service chaining data but does
366 not address the specific service chaining problems highlighted in
367 this document.
369 3. [NVO3]: The NVO3 working group is chartered with creation of
370 problem statement and requirements documents for multi-tenant
371 network overlays. NVO3 WG does not address service chaining
372 protocols.
374 4. [ALTO]: The Application Layer Traffic Optimization Working Group
375 is chartered to provide topological information at a higher
376 abstraction layer, which can be based upon network policy, and
377 with application-relevant service functions located in it. The
378 mechanism for ALTO obtaining the topology can vary and policy can
379 apply to what is provided or abstracted. This work could be
380 leveraged and extended to address the need for services
381 discovery.
383 5. [I2RS]: The Interface to the Routing System Working Group is
384 chartered to investigate the rapid programming of a device's
385 routing system, as well as the service of a generalized, multi-
386 layered network topology. This work could be leveraged and
387 extended to address some of the needs for service chaining in the
388 topology and device programming areas.
390 5. Summary
392 This document highlights problems associated with network service
393 deployment today and identifies several key areas that will be
394 addressed by the service chaining working group. Furthermore, this
395 document identifies four components that are the basis for serice
396 chaining. These components will form the areas of focus for the
397 working group.
399 6. Security Considerations
401 Security considerations are not addressed in this problem statement
402 only document. Given the scope of service chaining, and the
403 implications on data and control planes, security considerations are
404 clearly important and will be addressed in the specific protocol and
405 deployment documents created by the service chaining working group.
407 7. Contributors
409 The following people are active contributors to this document and
410 have provided review, content and concepts (listed alphabetically by
411 surname):
413 Puneet Agarwal
414 Broadcom
415 Email: pagarwal@broadcom.com
417 Mohamed Boucadair
418 France Telecom
419 Email: mohamed.boucadair@orange.com
421 Abhishek Chauhan
422 Citrix
423 Email: Abhishek.Chauhan@citrix.com
425 Uri Elzur
426 Intel
427 Email: uri.elzur@intel.com
429 Kevin Glavin
430 Riverbed
431 Email: Kevin.Glavin@riverbed.com
433 Ken Gray
434 Cisco Systems
435 Email: kegray@cisco.com
437 Jim Guichard
438 Cisco Systems
439 Email:jguichar@cisco.com
441 Christian Jacquenet
442 France Telecom
443 Email: christian.jacquenet@orange.com
445 Surendra Kumar
446 Cisco Systems
447 Email: smkumar@cisco.com
449 Nic Leymann
450 Deutsche Telekom
451 Email: n.leymann@telekom.de
453 Darrel Lewis
454 Cisco Systems
455 Email: darlewis@cisco.com
457 Rajeev Manur
458 Broadcom
459 Email:rmanur@broadcom.com
461 Brad McConnell
462 Rackspace
463 Email: bmcconne@rackspace.com
465 Carlos Pignataro
466 Cisco Systems
467 Email: cpignata@cisco.com
469 Michael Smith
470 Cisco Systems
471 Email: michsmit@cisco.com
473 Navindra Yadav
474 Cisco Systems
475 Email: nyadav@cisco.com
477 8. Acknowledgments
479 The authors would like to thank David Ward, Rex Fernando and Jim
480 French for their reviews and comments.
482 9. Informative References
484 [ALTO] "Application-Layer Traffic Optimization (alto)",
485 .
487 [I2RS] "Interface to the Routing System (i2rs)",
488 .
490 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)",
491 .
493 [LISP] "Locator/ID Separation Protocol (lisp)",
494 .
496 [NVO3] "Network Virtualization Overlays (nvo3)",
497 .
499 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
500 Address Translator (Traditional NAT)", RFC 3022,
501 January 2001.
503 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
504 NAT64: Network Address and Protocol Translation from IPv6
505 Clients to IPv4 Servers", RFC 6146, April 2011.
507 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
508 "Analysis of Potential Solutions for Revealing a Host
509 Identifier (HOST_ID) in Shared Address Deployments",
510 RFC 6967, June 2013.
512 Authors' Addresses
514 Paul Quinn (editor)
515 Cisco Systems, Inc.
517 Email: paulq@cisco.com
519 Thomas Nadeau (editor)
520 Brocade
522 Email: tnadeau@lucidvision.com