idnits 2.17.1
draft-ietf-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 (January 28, 2014) is 3739 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Missing Reference: 'RFC6459' is mentioned on line 355, but not defined
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, Ed.
3 Internet-Draft Cisco Systems, Inc.
4 Intended status: Informational T. Nadeau, Ed.
5 Expires: August 1, 2014 Lucidvision
6 January 28, 2014
8 Service Function Chaining Problem Statement
9 draft-ietf-sfc-problem-statement-00.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 1, 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 . . . . . . . . . . . . . . . . . . 8
62 4. Service Function Chaining Use Cases . . . . . . . . . . . . . 10
63 4.1. Enterprise Data Center Service Chaining . . . . . . . . . 10
64 4.2. 3GPP Gi Interface Service Function Chaining . . . . . . . 10
65 5. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 12
66 6. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
68 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 15
69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
70 10. Informative References . . . . . . . . . . . . . . . . . . . . 17
71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
73 1. Introduction
75 The delivery of end-to-end services often require various Service
76 Functions (SF) including traditional network service functions (for
77 example firewalls and server load balancers), as well as application-
78 specific features. Service functions may be delivered within the
79 context of an isolated user group, or shared amongst many users/user
80 groups
82 Current service function deployment models are relatively static in
83 that they are tightly coupled to network topology and physical
84 resources. The result of that static nature of existing deployments
85 greatly reduces, and in many cases, limits the ability of an operator
86 to introduce new services and/or service functions. Furthermore
87 there is a cascading effect: service changes affect other services.
89 This document outlines the problems encountered with existing service
90 deployment models for Service Function Chaining (SFC) (often referred
91 to simply as service chaining; in this document the terms will be
92 used interchangeably), as well as the problems of service chain
93 creation/ deletion, policy integration with service chains, and
94 policy enforcement within the network infrastructure.
96 1.1. Definition of Terms
98 Classification: Locally instantiated customer/network/service policy
99 used to identify and select traffic flow(s) requiring appropriate
100 outbound forwarding actions.
102 Network Overlay: A logical network built, via virtual links or
103 packet encapsulation, over an existing network (the underlay).
105 Service Function Chain: A service chain defines an ordered set of
106 service functions that must be applied to packets and/or frames
107 selected as a result of classification
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: Physical or virtual element offering one or more
127 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 A common example is web servers using a server load balancer as
163 the default gateway. When the web service responds to non-load
164 balanced traffic (e.g., administrative or backup operations) all
165 traffic from the server must traverse the load balancer forcing
166 network administrators to create complex routing schemes or
167 create additional interfaces to provide an alternate topology.
169 2. Configuration complexity: A direct consequence of topological
170 dependencies is the complexity of the entire configuration,
171 specifically in deploying service function chains. Simple
172 actions such as changing the order of the service functions in a
173 service function chain require changes to the topology. Changes
174 to the topology are avoided by the network operator once
175 installed, configured and deployed in production environments
176 fearing misconfiguration and downtime. All of this leads to
177 very static service delivery deployments. Furthermore, the
178 speed at which these topological changes can be made is not
179 rapid or dynamic enough as it often requires manual
180 intervention, or use of slow provisioning systems.
182 The service itself can contribute to the complexity: it may
183 require an intricate combination of very different capabilities,
184 regardless of the underlying topology. QoS-based, resilient VPN
185 service offerings are a typical example of such complex service
186 offerings.
188 3. Constrained High Availability: An effect of topological
189 dependency is constrained service function high availability.
190 Worse, when modified, inadvertent non-high availability or
191 downtime can result.
193 Since traffic reaches many service functions based on network
194 topology, alternate, or redundant service functions must be
195 placed in the same topology as the primary service.
197 4. Consistent Ordering of Service Functions: Service functions are
198 typically independent; service function_1 (SF1)...service
199 function_n (SFn) are unrelated and there is no notion at the
200 service layer that SF1 occurs before SF2. However, to an
201 administrator many service functions have a strict ordering that
202 must be in place, yet the administrator has no consistent way to
203 impose and verify the ordering of the functions that are used to
204 deliver a given service.
206 5. Service Chain Construction: Service function chains today are
207 most typically built through manual configuration processes.
208 These are slow and error prone. With the advent of newer
209 service deployment models the control/management planes provide
210 not only connectivity state, but will also be increasingly
211 utilized for the creation of network services. Such a control/
212 management planes could be centralized, or be distributed.
214 6. Application of Service Policy: Service functions rely on
215 topology information such as VLANs or packet (re) classification
216 to determine service policy selection, i.e. the service function
217 specific action taken. Topology information is increasingly
218 less viable due to scaling, tenancy and complexity reasons. The
219 topological information is often stale, providing the operator
220 with inaccurate placement that can result in suboptimal resource
221 utilization. Furthermore topology-centric information often
222 does not convey adequate information to the service functions,
223 forcing functions to individually perform more granular
224 classification.
226 7. Transport Dependence: Service functions can and will be deployed
227 in networks with a range of transports, including under and
228 overlays. The coupling of service functions to topology
229 requires service functions to support many transports or for a
230 transport gateway function to be present.
232 8. Elastic Service Delivery: Given the current state of the art for
233 adding/removing service functions largely centers around VLANs
234 and routing changes, rapid changes to the service deployment can
235 be hard to realize due to the risk and complexity of such
236 changes.
238 9. Traffic Selection Criteria: Traffic selection is coarse, that
239 is, all traffic on a particular segment traverse service
240 functions whether the traffic requires service enforcement or
241 not. This lack of traffic selection is largely due to the
242 topological nature of service deployment since the forwarding
243 topology dictates how (and what) data traverses service
244 function(s). In some deployments, more granular traffic
245 selection is achieved using policy routing or access control
246 filtering. This results in operationally complex configurations
247 and is still relatively inflexible.
249 10. Limited End-to-End Service Visibility: Troubleshooting service
250 related issues is a complex process that involve both network-
251 specific and service-specific expertise. This is especially the
252 case when service function chains span multiple DCs, or across
253 administrative boundaries. Furthermore, the physical and
254 virtual environments (network and service), can be highly
255 divergent in terms of topology and that topological variance
256 adds to these challenges.
258 11. Per-Service (re)Classification: Classification occurs at each
259 service function independent from previously applied service
260 functions. More importantly, the classification functionality
261 often differs per service function and service functions may not
262 leverage the results from other service functions.
264 12. Symmetric Traffic Flows: Service function chains may be
265 unidirectional or bidirectional; unidirectional is one where
266 traffic is passed through a set of service functions in one
267 forwarding direction only. Bidirectional is one where traffic
268 is passed through a set of service functions in both forwarding
269 directions. Existing service deployment models provide a static
270 approach to realizing forward and reverse service function chain
271 association most often requiring complex configuration of each
272 network device throughout the forwarding path.
274 13. Multi-vendor Service Functions: Deploying service functions from
275 multiple vendors often require per-vendor expertise: insertion
276 models differ, there are limited common attributes and inter-
277 vendor service functions do not share information.
279 3. Service Function Chaining
281 Service Function Chaining aims to address the aforementioned problems
282 associated with service deployment. Concretely, SFC will investigate
283 solutions that address the following elements:
285 1. Service Overlay: Service function chaining utilizes a service
286 specific overlay that creates the service topology. The service
287 overlay is independent of the network topology and allows
288 operators to use whatever overlay or underlay they prefer to
289 create a path between Service nodes, and to locate service
290 functions in the network as needed.
292 Within the service topology, service functions can be viewed as
293 resources for consumption and an arbitrary topology constructed
294 to connect those resources in a required order. Adding new
295 service functions to the topology is easily accomplished, and no
296 underlying network changes are required.
298 Lastly, the service overlay can provide service specific
299 information needed for troubleshooting service-related issues.
301 2. Control Plane: Service aware control plane(s) provide information
302 about the available service functions on a network. The
303 information provided by the control plane includes service
304 network location (for topology creation), service type (e.g.
305 firewall, load balancer, etc.) and, optionally, administrative
306 information about the service functions such as load, capacity
307 and operating status. The service aware control plane allows for
308 the formulation of service function chains and exchanges
309 requisite information needed to instantiate the service function
310 chains in the network.
312 3. Service Classification: Classification is used to select which
313 traffic enters a service overlay. The granularity of the
314 classification varies based on device capabilities, customer
315 requirements, and service offered. Initial classification is
316 used to start the service function chain. Subsequent
317 classification can be used within a given service function chain
318 to alter the sequence of service functions applied. Symmetric
319 classification ensures that forward and reverse chains are in
320 place.
322 4. Dataplane Metadata: Data plane metadata provides the ability to
323 exchange information between the network and service functions,
324 between service functions, and service functions and the network.
325 Metadata can include the result of antecedent classification,
326 information from external sources or forwarding related data.
328 For example, service functions utilize metadata, as required, for
329 localized policy decisions.
331 In addition to sharing of information, the use of metadata
332 addresses several of the issues raised in section 2, most notably
333 the de-coupling of policy from the topology, and the need for
334 per-service classification (and re-classification).
336 A common approach to service metadata creates a common foundation
337 for interoperability between service functions, regardless of
338 vendor.
340 4. Service Function Chaining Use Cases
342 The following sections provide high level overviews of several common
343 service chaining deployments.
345 4.1. Enterprise Data Center Service Chaining
347 TBD
349 4.2. 3GPP Gi Interface Service Function Chaining
351 3GPP defines the Gi interface as the reference point between the GGSN
352 (Gateway GPRS Support Node) and an external PDN (Packet Domain
353 Network) [RFC6459]. This interface reference point is called SGi in
354 4G networks (i.e., between the PDN Gateway and an external PDN)
355 [RFC6459]. Note, there is no standard specification of such
356 reference points (i.e., Gi and SGi) in terms of functions to be
357 located in that segment.
359 In light of current deployments, plenty of Service Functions are
360 enabled in the Gi Interface (e.g., DPI, billing and charging, TCP
361 optimization, web optimization, video optimization, header
362 enrichment, etc.). Some of these Service Functions are co-located on
363 the same device while others are enabled in standalone boxes. In
364 order to fulfill new business needs, especially to offer innovative
365 added-value services, the number of enabled Service Functions in the
366 Gi Interface is still growing.
368 Several (S)Gi Interfaces can be deployed within the same PLMN (Public
369 Land Mobile Network). This depends mainly on the number of PDNs and
370 other factors. Each of these interfaces may involve a differentiated
371 set of Service Functions to be involved.
373 The current model that consists of adding new "boxes" to fulfill new
374 business guidelines has shown its limit. Concretely, current
375 deployments suffer from the following problems:
377 o Complexity to introduce new Service Functions because of the
378 constraint on the underlying topology.
380 o Lack of visibility on dependency between Service Functions.
382 o Lack of automated and flexible means to assess the impact of
383 withdrawing a Service Function or a feature offered by a Service
384 Function from the traffic forwarding path.
386 o The connectivity service logic may be stalled because of the
387 dependency on the physical topology.
389 o Lack of deterministic means to:
391 * Improve service provisioning and delivery.
393 * Ease the manageability of the SGi/Gi Interface.
395 5. Related IETF Work
397 The following subsections discuss related IETF work and are provided
398 for reference. This section is not exhaustive, rather it provides an
399 overview of the various initiatives and how they relate to network
400 service chaining.
402 1. [L3VPN]: The L3VPN working group is responsible for defining,
403 specifying and extending BGP/MPLS IP VPNs solutions. Although
404 BGP/MPLS IP VPNs can be used as transport for service chaining
405 deployments, the service chaining WG focuses on the service
406 specific protocols, not the general case of VPNs. Furthermore,
407 BGP/MPLS IP VPNs do not address the requirements for service
408 chaining.
410 2. [LISP]: LISP provides locator and ID separation. LISP can be
411 used as an L3 overlay to transport service chaining data but does
412 not address the specific service chaining problems highlighted in
413 this document.
415 3. [NVO3]: The NVO3 working group is chartered with creation of
416 problem statement and requirements documents for multi-tenant
417 network overlays. NVO3 WG does not address service chaining
418 protocols.
420 4. [ALTO]: The Application Layer Traffic Optimization Working Group
421 is chartered to provide topological information at a higher
422 abstraction layer, which can be based upon network policy, and
423 with application-relevant service functions located in it. The
424 mechanism for ALTO obtaining the topology can vary and policy can
425 apply to what is provided or abstracted. This work could be
426 leveraged and extended to address the need for services
427 discovery.
429 5. [I2RS]: The Interface to the Routing System Working Group is
430 chartered to investigate the rapid programming of a device's
431 routing system, as well as the service of a generalized, multi-
432 layered network topology. This work could be leveraged and
433 extended to address some of the needs for service chaining in the
434 topology and device programming areas.
436 6. Summary
438 This document highlights problems associated with network service
439 deployment today and identifies several key areas that will be
440 addressed by the service chaining working group. Furthermore, this
441 document identifies four components that are the basis for serice
442 chaining. These components will form the areas of focus for the
443 working group.
445 7. Security Considerations
447 Security considerations are not addressed in this problem statement
448 only document. Given the scope of service chaining, and the
449 implications on data and control planes, security considerations are
450 clearly important and will be addressed in the specific protocol and
451 deployment documents created by the service chaining working group.
453 8. Contributors
455 The following people are active contributors to this document and
456 have provided review, content and concepts (listed alphabetically by
457 surname):
459 Puneet Agarwal (pagarwal@broadcom.com), Mohamed Boucadair
460 (mohamed.boucadair@orange.com), Abhishek Chauhan
461 (Abhishek.Chauhan@citrix.com), Uri Elzur (uri.elzur@intel.com), Kevin
462 Glavin (Kevin.Glavin@riverbed.com), Ken Gray (kgray@juniper.net), Jim
463 Guichard (jguichar@cisco.com), Christian Jacquenet
464 (christian.jacquenet@orange.com), Surendra Kumar (smkumar@cisco.com),
465 Nic Leymann (n.leymann@telekom.de), Darrel Lewis
466 (darlewis@cisco.com), Rajeev Manur (rmanur@broadcom.com), Brad
467 McConnell (bmcconne@rackspace.com), Carlos Pignataro
468 (cpignata@cisco.com), Michael Smith (michsmit@insiemenetworks.com),
469 Navindra Yadav (nyadav@insiemenetworks.com).
471 9. Acknowledgments
473 The authors would like to thank David Ward, Rex Fernando and Jim
474 French for their contributions.
476 10. Informative References
478 [ALTO] "Application-Layer Traffic Optimization (alto)",
479 .
481 [I2RS] "Interface to the Routing System (i2rs)",
482 .
484 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)",
485 .
487 [LISP] "Locator/ID Separation Protocol (lisp)",
488 .
490 [NVO3] "Network Virtualization Overlays (nvo3)",
491 .
493 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
494 Address Translator (Traditional NAT)", RFC 3022,
495 January 2001.
497 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
498 NAT64: Network Address and Protocol Translation from IPv6
499 Clients to IPv4 Servers", RFC 6146, April 2011.
501 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno,
502 "Analysis of Potential Solutions for Revealing a Host
503 Identifier (HOST_ID) in Shared Address Deployments",
504 RFC 6967, June 2013.
506 Authors' Addresses
508 Paul Quinn (editor)
509 Cisco Systems, Inc.
511 Email: paulq@cisco.com
513 Thomas Nadeau (editor)
514 Lucidvision
516 Email: tnadeau@lucidvision.com