idnits 2.17.1
draft-ietf-sfc-problem-statement-03.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 (April 1, 2014) is 3677 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: October 3, 2014 Brocade
6 April 1, 2014
8 Service Function Chaining Problem Statement
9 draft-ietf-sfc-problem-statement-03.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 October 3, 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 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 (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. Control Plane . . . . . . . . . . . . . . . . . . . . . . 9
76 3.3. Service Classification . . . . . . . . . . . . . . . . . . 9
77 3.4. Dataplane Metadata . . . . . . . . . . . . . . . . . . . . 10
78 4. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 11
79 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
81 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
83 9. Informative References . . . . . . . . . . . . . . . . . . . . 17
84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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, policy integration with service chains, and
107 policy enforcement within the network infrastructure.
109 1.1. Definition of Terms
111 Classification: Locally instantiated policy that results in matching
112 of traffic flows for identification of appropriate outbound
113 forwarding actions.
115 Network Overlay: A logical network built, via virtual links or
116 packet encapsulation, over an existing network (the underlay).
118 Network Service: An externally visible service offered by a network
119 operator; a service may consist of a single service function or a
120 composite built from several service functions executed in one or
121 more pre-determined sequences and delivered by one or more service
122 nodes.
124 Service Function: A function that is responsible for specific
125 treatment of received packets. A Service Function can act at the
126 network layer or other OSI layers. A Service Function can be a
127 virtual instance or be embedded in a physical network element.
128 One of multiple Service Functions can be embedded in the same
129 network element. Multiple instances of the Service Function can
130 be enabled in the same administrative domain.
132 A non-exhaustive list of Service Functions includes: firewalls,
133 WAN and application acceleration, Deep Packet Inspection (DPI),
134 server load balancers, NAT44 [RFC3022], NAT64 [RFC6146], HOST_ID
135 injection [RFC6967], HTTP Header Enrichment functions, TCP
136 optimizer, etc.
138 The generic term "L4-L7 services" is often used to describe many
139 service functions.
141 Service Function Chain (SFC): A service Function chain defines an
142 ordered set of service functions that must be applied to packets
143 and/or layer-2 frames selected as a result of classification. The
144 implied order may not be a linear progression as nodes may copy to
145 more than one branch. The term service chain is often used as
146 shorthand for service function chain.
148 Service Function Path (SFP): The instantiation of a service function
149 chain in the network. Packets follow a service function path from
150 a classifier through the required instances of service functions
151 in the network.
153 Service Node (SN): Physical or virtual element that hosts one or
154 more service functions.
156 Service Overlay: An overlay network created for the purpose of
157 forwarding data along a service function path.
159 Service Topology: The service overlay connectivity forms a service
160 topology.
162 2. Problem Space
164 The following points describe aspects of existing service deployments
165 that are problematic, and that the Service Function Chaining (SFC)
166 working group aims to address.
168 2.1. Topological Dependencies
170 Network service deployments are often coupled to network topology,
171 whether it be real or virtualized, or a hybrid of the two. Such
172 dependency imposes constraints on the service delivery, potentially
173 inhibiting the network operator from optimally utilizing service
174 resources, and reduces the flexibility. This limits scale, capacity,
175 and redundancy across network resources.
177 These topologies serve only to "insert" the service function (i.e.,
178 ensure that traffic traverses a service function); they are not
179 required from a native packet delivery perspective. For example,
180 firewalls often require an "in" and "out" layer-2 segment and adding
181 a new firewall requires changing the topology (i.e., adding new
182 layer-2 segments).
184 As more service functions are required - often with strict ordering -
185 topology changes are needed before and after each service function
186 resulting in complex network changes and device configuration. In
187 such topologies, all traffic, whether a service function needs to be
188 applied or not, often passes through the same strict order.
190 The topological coupling limits placement and selection of service
191 functions: service functions are "fixed" in place by topology and
192 therefore placement and service function selection taking into
193 account network topology information is not viable. Furthermore,
194 altering the services traversed, or their order, based on flow
195 direction is not possible.
197 A common example is web servers using a server load balancer as the
198 default gateway. When the web service responds to non-load balanced
199 traffic (e.g., administrative or backup operations) all traffic from
200 the server must traverse the load balancer forcing network
201 administrators to create complex routing schemes or create additional
202 interfaces to provide an alternate topology.
204 2.2. Configuration complexity
206 A direct consequence of topological dependencies is the complexity of
207 the entire configuration, specifically in deploying service function
208 chains. Simple actions such as changing the order of the service
209 functions in a service function chain require changes to the
210 topology. Changes to the topology are avoided by the network
211 operator once installed, configured and deployed in production
212 environments fearing misconfiguration and downtime. All of this
213 leads to very static service delivery deployments. Furthermore, the
214 speed at which these topological changes can be made is not rapid or
215 dynamic enough as it often requires manual intervention, or use of
216 slow provisioning systems.
218 2.3. Constrained High Availability
220 An effect of topological dependency is constrained service function
221 high availability. Worse, when modified, inadvertent non-high
222 availability or downtime can result.
224 Since traffic reaches many service functions based on network
225 topology, alternate, or redundant service functions must be placed in
226 the same topology as the primary service.
228 2.4. Consistent Ordering of Service Functions
230 Service functions are typically independent; service function_1
231 (SF1)...service function_n (SFn) are unrelated and there is no notion
232 at the service layer that SF1 occurs before SF2. However, to an
233 administrator many service functions have a strict ordering that must
234 be in place, yet the administrator has no consistent way to impose
235 and verify the ordering of the service functions that are used to
236 deliver a given service.
238 Service function chains today are most typically built through manual
239 configuration processes. These are slow and error prone. With the
240 advent of newer service deployment models the control and policy
241 planes provide not only connectivity state, but will also be
242 increasingly utilized for the creation of network services. Such a
243 control/management planes could be centralized, or be distributed.
245 2.5. Application of Service Policy
247 Service functions rely on topology information such as VLANs or
248 packet (re) classification to determine service policy selection,
249 i.e. the service function specific action taken. Topology
250 information is increasingly less viable due to scaling, tenancy and
251 complexity reasons. The topological information is often stale,
252 providing the operator with inaccurate placement that can result in
253 suboptimal resource utilization. Furthermore topology-centric
254 information often does not convey adequate information to the service
255 functions, forcing functions to individually perform more granular
256 classification.
258 2.6. Transport Dependence
260 Service functions can and will be deployed in networks with a range
261 of transports, including under and overlays. The coupling of service
262 functions to topology requires service functions to support many
263 transport encapsulations or for a transport gateway function to be
264 present.
266 2.7. Elastic Service Delivery
268 Given that the current state of the art for adding/removing service
269 functions largely centers around VLANs and routing changes, rapid
270 changes to the service deployment can be hard to realize due to the
271 risk and complexity of such changes.
273 2.8. Traffic Selection Criteria
275 Traffic selection is coarse, that is, all traffic on a particular
276 segment traverse service functions whether the traffic requires
277 service enforcement or not. This lack of traffic selection is
278 largely due to the topological nature of service deployment since the
279 forwarding topology dictates how (and what) data traverses service
280 function(s). In some deployments, more granular traffic selection is
281 achieved using policy routing or access control filtering. This
282 results in operationally complex configurations and is still
283 relatively inflexible.
285 2.9. Limited End-to-End Service Visibility
287 Troubleshooting service related issues is a complex process that
288 involve both network-specific and service-specific expertise. This
289 is especially the case when service function chains span multiple
290 DCs, or across administrative boundaries. Furthermore, the physical
291 and virtual environments (network and service), can be highly
292 divergent in terms of topology and that topological variance adds to
293 these challenges.
295 2.10. Per-Service (re)Classification
297 Classification occurs at each service function independent from
298 previously applied service functions. More importantly, the
299 classification functionality often differs per service function and
300 service functions may not leverage the results from other service
301 functions.
303 2.11. Symmetric Traffic Flows
305 Service function chains may be unidirectional or bidirectional
306 depending on the state requirements of the service functions. In a
307 unidirectional chain traffic is passed through a set of service
308 functions in one forwarding direction only. Bidirectional chains
309 require traffic to be passed through a set of service functions in
310 both forwarding directions. Many common service functions such as
311 DPI and firewall often require bidirectional chaining in order to
312 ensure flow state is consistent.
314 Existing service deployment models provide a static approach to
315 realizing forward and reverse service function chain association most
316 often requiring complex configuration of each network device
317 throughout the SFC.
319 2.12. Multi-vendor Service Functions
321 Deploying service functions from multiple vendors often require per-
322 vendor expertise: insertion models differ, there are limited common
323 attributes and inter- vendor service functions do not share
324 information.
326 3. Service Function Chaining
328 Service Function Chaining aims to address the aforementioned problems
329 associated with service deployment. Concretely, the SFC working
330 group will investigate solutions that address the following elements:
332 3.1. Service Overlay
334 Service function chaining utilizes a service specific overlay that
335 creates the service topology. The service overlay provides service
336 function connectivity and is built "on top" of the existing network
337 topology and allows operators to use whatever overlay or underlay
338 they prefer to create a path between service functions, and to locate
339 service functions in the network as needed.
341 Within the service topology, service functions can be viewed as
342 resources for consumption and an arbitrary topology constructed to
343 connect those resources in a required order. Adding new service
344 functions to the topology is easily accomplished, and no underlying
345 network changes are required.
347 Lastly, the service overlay can provide service specific information
348 needed for troubleshooting service-related issues.
350 3.2. Control Plane
352 Service aware control plane(s) provide information about the
353 available service functions on a network. The information provided
354 by the control plane includes service network location (for topology
355 creation), service type (e.g. firewall, load balancer, etc.) and,
356 optionally, administrative information about the service functions
357 such as load, capacity and operating status. The service aware
358 control plane allows for the formulation of service function chains
359 and exchanges requisite information needed to instantiate the service
360 function chains in the network.
362 Furthermore, the service aware control plane may interact with the
363 topology aware control plane (if separate) to ensure optimal
364 selection (and possibly placement) of service function within a
365 service function path.
367 3.3. Service Classification
369 Classification is used to select which traffic enters a service
370 overlay. The granularity of the classification varies based on
371 device capabilities, customer requirements, and service offered.
372 Initial classification determines the service function chain required
373 to process the traffic. Subsequent classification can be used within
374 a given service function chain to alter the sequence of service
375 functions applied. Symmetric classification ensures that forward and
376 reverse chains are in place. Similarly, asymmetric -- relative to
377 required service function -- chains can be achieved via service
378 classification.
380 3.4. Dataplane Metadata
382 Data plane metadata provides the ability to exchange information
383 between classification entities and service functions, between
384 service functions, service functions and classification entities and
385 service nodes, and as such does not provide forwarding information
386 used to deliver packet along the service overlay.
388 Metadata can include the result of antecedent classification,
389 information from external sources or forwarding related data.
390 Service functions utilize metadata, as required, for localized policy
391 decisions.
393 In addition to sharing of information, the use of metadata addresses
394 several of the issues raised in section 2, most notably the de-
395 coupling of policy from the topology, and the need for per-service
396 classification (and re-classification).
398 A common approach to service metadata creates a common foundation for
399 interoperability between service functions, regardless of vendor.
401 4. Related IETF Work
403 The following subsections discuss related IETF work and are provided
404 for reference. This section is not exhaustive, rather it provides an
405 overview of the various initiatives and how they relate to network
406 service chaining.
408 1. [L3VPN]: The L3VPN working group is responsible for defining,
409 specifying and extending BGP/MPLS IP VPNs solutions. Although
410 BGP/MPLS IP VPNs can be used as transport for service chaining
411 deployments, the SFC WG focuses on the service specific
412 protocols, not the general case of VPNs. Furthermore, BGP/MPLS
413 IP VPNs do not address the requirements for service chaining.
415 2. [LISP]: LISP provides locator and ID separation. LISP can be
416 used as an L3 overlay to transport service chaining data but does
417 not address the specific service chaining problems highlighted in
418 this document.
420 3. [NVO3]: The NVO3 working group is chartered with creation of
421 problem statement and requirements documents for multi-tenant
422 network overlays. NVO3 WG does not address service chaining
423 protocols.
425 4. [ALTO]: The Application Layer Traffic Optimization Working Group
426 is chartered to provide topological information at a higher
427 abstraction layer, which can be based upon network policy, and
428 with application-relevant service functions located in it. The
429 mechanism for ALTO obtaining the topology can vary and policy can
430 apply to what is provided or abstracted. This work could be
431 leveraged and extended to address the need for services
432 discovery.
434 5. [I2RS]: The Interface to the Routing System Working Group is
435 chartered to investigate the rapid programming of a device's
436 routing system, as well as the service of a generalized, multi-
437 layered network topology. This work could be leveraged and
438 extended to address some of the needs for service chaining in the
439 topology and device programming areas.
441 6. [ForCES]: The ForCES working group has created a framework,
442 requirements, a solution protocol, a logical function block
443 library, and other associated documents in support of Forwarding
444 and Control Element Separation. The work done by ForCES may
445 provide a basis for both the separation of SFC elements, as well
446 as provide protocol and design guidance for those elements.
448 5. Summary
450 This document highlights problems associated with network service
451 deployment today and identifies several key areas that will be
452 addressed by the SFC working group. Furthermore, this document
453 identifies four components that are the basis for service function
454 chaining. These components will form the areas of focus for the
455 working group.
457 6. Security Considerations
459 Security considerations are not addressed in this problem statement
460 only document. Given the scope of service chaining, and the
461 implications on data and control planes, security considerations are
462 clearly important and will be addressed in the specific protocol and
463 deployment documents created by the SFC WG group.
465 7. Contributors
467 The following people are active contributors to this document and
468 have provided review, content and concepts (listed alphabetically by
469 surname):
471 Puneet Agarwal
472 Broadcom
473 Email: pagarwal@broadcom.com
475 Mohamed Boucadair
476 France Telecom
477 Email: mohamed.boucadair@orange.com
479 Abhishek Chauhan
480 Citrix
481 Email: Abhishek.Chauhan@citrix.com
483 Uri Elzur
484 Intel
485 Email: uri.elzur@intel.com
487 Kevin Glavin
488 Riverbed
489 Email: Kevin.Glavin@riverbed.com
491 Ken Gray
492 Cisco Systems
493 Email: kegray@cisco.com
495 Jim Guichard
496 Cisco Systems
497 Email:jguichar@cisco.com
499 Christian Jacquenet
500 France Telecom
501 Email: christian.jacquenet@orange.com
503 Surendra Kumar
504 Cisco Systems
505 Email: smkumar@cisco.com
507 Nic Leymann
508 Deutsche Telekom
509 Email: n.leymann@telekom.de
511 Darrel Lewis
512 Cisco Systems
513 Email: darlewis@cisco.com
515 Rajeev Manur
516 Broadcom
517 Email:rmanur@broadcom.com
519 Brad McConnell
520 Rackspace
521 Email: bmcconne@rackspace.com
523 Carlos Pignataro
524 Cisco Systems
525 Email: cpignata@cisco.com
527 Michael Smith
528 Cisco Systems
529 Email: michsmit@cisco.com
531 Navindra Yadav
532 Cisco Systems
533 Email: nyadav@cisco.com
535 8. Acknowledgments
537 The authors would like to thank David Ward, Rex Fernando, David
538 Mcdysan, Jamal Hadi Salim, Charles Perkins, Andre Beliveau, Joel
539 Halpern and Jim French for their reviews and comments.
541 9. Informative References
543 [ALTO] "Application-Layer Traffic Optimization (alto)",
544 .
546 [ForCES] "Forwarding and Control Element Separation (forces)",
547 .
549 [I2RS] "Interface to the Routing System (i2rs)",
550 .
552 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)",
553 .
555 [LISP] "Locator/ID Separation Protocol (lisp)",
556 .
558 [NVO3] "Network Virtualization Overlays (nvo3)",
559 .
561 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
562 Address Translator (Traditional NAT)", RFC 3022,
563 January 2001.
565 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
566 NAT64: Network Address and Protocol Translation from IPv6
567 Clients to IPv4 Servers", RFC 6146, April 2011.
569 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
570 "Analysis of Potential Solutions for Revealing a Host
571 Identifier (HOST_ID) in Shared Address Deployments",
572 RFC 6967, June 2013.
574 Authors' Addresses
576 Paul Quinn (editor)
577 Cisco Systems, Inc.
579 Email: paulq@cisco.com
581 Thomas Nadeau (editor)
582 Brocade
584 Email: tnadeau@lucidvision.com