idnits 2.17.1
draft-quinn-nsc-problem-statement-01.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 (July 13, 2013) is 3933 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC2119' is defined on line 399, but no explicit
reference was found in the text
Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group P. Quinn
3 Internet-Draft J. Guichard
4 Intended status: Informational S. Kumar
5 Expires: January 14, 2014 Cisco Systems, Inc.
6 A. Chauhan
7 Citrix
8 N. Leymann
9 Deutsche Telekom
10 M. Boucadair
11 C. Jacquenet
12 France Telecom
13 M. Smith
14 N. Yadav
15 Insieme Networks
16 T. Nadeau
17 K. Gray
18 Juniper Networks
19 B. McConnell
20 Rackspace
21 July 13, 2013
23 Network Service Chaining Problem Statement
24 draft-quinn-nsc-problem-statement-01.txt
26 Abstract
28 This document provides an overview of the issues associated with the
29 deployment of network services functions (such as firewalls, load
30 balancers) in large-scale environments. The term service chaining is
31 used to describe the deployment of such services, and the ability of
32 a network operator to specify an ordered list of services that should
33 be applied to a deterministic set of traffic flows. Such service
34 chains require integration of service policy alongside the deployment
35 of applications, while allowing for the optimal utilization of
36 network resources.
38 Status of this Memo
40 This Internet-Draft is submitted in full conformance with the
41 provisions of BCP 78 and BCP 79.
43 Internet-Drafts are working documents of the Internet Engineering
44 Task Force (IETF). Note that other groups may also distribute
45 working documents as Internet-Drafts. The list of current Internet-
46 Drafts is at http://datatracker.ietf.org/drafts/current/.
48 Internet-Drafts are draft documents valid for a maximum of six months
49 and may be updated, replaced, or obsoleted by other documents at any
50 time. It is inappropriate to use Internet-Drafts as reference
51 material or to cite them other than as "work in progress."
53 This Internet-Draft will expire on January 14, 2014.
55 Copyright Notice
57 Copyright (c) 2013 IETF Trust and the persons identified as the
58 document authors. All rights reserved.
60 This document is subject to BCP 78 and the IETF Trust's Legal
61 Provisions Relating to IETF Documents
62 (http://trustee.ietf.org/license-info) in effect on the date of
63 publication of this document. Please review these documents
64 carefully, as they describe your rights and restrictions with respect
65 to this document. Code Components extracted from this document must
66 include Simplified BSD License text as described in Section 4.e of
67 the Trust Legal Provisions and are provided without warranty as
68 described in the Simplified BSD License.
70 Table of Contents
72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
73 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4
74 2. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . 6
75 3. Service Function Chaining for Adding Network Services . . . . 9
76 4. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 10
77 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
81 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
82 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
85 1. Introduction
87 New data center (DC) networks, mobile networks, Internet cloud
88 architectures and existing networks require more flexible deployment
89 models that are able to support many different forms of applications
90 and related network services. Network services include but are not
91 limited to, traditional services such as firewalls and server load
92 balancers, as well as applications and features that operate on
93 network data. Additionally, these services must be delivered in the
94 context of multi-tenancy where each individual tenant is an isolated
95 user group attached to a common data center. These isolated tenants
96 may require unique capabilities with the ability to tailor service
97 characteristics on a per-tenant basis that should not affect other
98 contexts. Similarly, in other deployments, service feature
99 deployments might be associated with subscribers (e.g. activated at
100 the GI interface), or within the scope of a VPN offering.
102 The current network service deployment models are relatively static
103 in that they are bound to relatively fixed topology as well as
104 relatively static resources. At present, these models are not easily
105 manipulated (i.e.: moved, created or destroyed) even when virtualized
106 elements are deployed. This poses a problem in highly elastic
107 service environments that require relatively rapid creation,
108 destruction or movement of real or virtual services or network
109 elements. Additionally, the transition to virtual platforms requires
110 an agile service insertion model that supports elastic and very
111 granular service delivery, and post-facto modification; supports the
112 movement of service functions and application workloads in the
113 existing network, all the while retaining the network and service
114 policies and the ability to easily bind service policy to granular
115 information such as per-subscriber state.
117 This document outlines the problems encountered with existing service
118 deployment models for service chaining, as well as the problems of
119 service chain creation/deletion, policy selection integration with
120 service chains, and policy enforcement within the network
121 infrastructure.
123 1.1. Definition of Terms
125 Classification: Locally instantiated policy and customer/network/
126 service profile matching of traffic flows for identification of
127 appropriate outbound forwarding actions.
129 Network Overlay: Logical network built on top of existing network
130 (the underlay). Packets are encapsulated or tunneled to create
131 the overlay network topology.
133 Service Chain: A service chain defines the services required
134 (e.g.FW), and their order (service1 --> service2) that must be
135 applied to packets and/or frames.
137 Service Function: A L4-L7 service function (NAT, FW, DPI, IDS,
138 application based packet treatment), application, compute
139 resource, storage, or content used singularly or in collaboration
140 with other service functions to enable a service offered by a
141 network operator.
143 Service Node: Physical or virtual element providing one or more
144 service functions.
146 Network Service: An externally visible service offered by a network
147 operator; a service may consist of a single service function or a
148 composite built from several service functions executed in one or
149 more pre-determined sequences and delivered by one or more service
150 nodes.
152 2. Problem Areas
154 The following points describe aspects of existing service deployment
155 that are problematic, and are being addressed by the network service
156 chaining effort.
158 1. Topological Dependencies: Network service deployments are often
159 coupled to the physical network topology creating constraints on
160 service delivery and potentially inhibiting the network operator
161 from optimally utilizing service resources. This limits scale,
162 capacity, and redundancy across network resources.
164 These topologies serve only to "insert" the service function
165 (i.e. ensure that traffic traverse a service function); they are
166 not required from a native packet delivery perspective. For
167 example, firewalls often require an "in" and "out" layer-2
168 segment and adding a new firewall requires changing the topology
169 (i.e. adding new L2 segments).
171 As more service functions are required - often with strict
172 ordering - topology changes are needed before and after each
173 service function resulting in complex network changes and device
174 configuration. In such topologies, all traffic, whether a
175 service function needs to be applied or not, often passes
176 through the same strict order.
178 A common example is web servers using a server load balancer as
179 the default gateway. When the web service responds to non-load
180 balanced traffic (e.g. administrative or backup operations) all
181 traffic from the server must traverse the load balancer forcing
182 network administrators to create complex routing schemes or
183 create additional interfaces to provide an alternate topology.
185 2. Configuration complexity: A direct consequence of topological
186 dependencies is the complexity of the entire configuration,
187 specifically in deploying service chains. Simple actions such
188 as changing the order of the service functions in a service
189 chain require changes to the topology. Changes to the topology
190 are avoided by the network operator once installed, configured
191 and deployed in production environments fearing misconfiguration
192 and downtime. All of this leads to very static service delivery
193 models. Furthermore, the speed at which these topological
194 changes can be made is not rapid or dynamic enough as it often
195 requires manual intervention, or use of slow provisioning
196 systems.
198 The service itself can contribute to complexity: it may require
199 an intricate combination of very different capabilities,
200 regardless of the underlying topology. QoS-based, resilient VPN
201 service offerings are a typical example of such complexity.
203 3. Constrained High Availability: An effect of topological
204 dependency is constrained service function high availability.
205 Worse, when modified, inadvertent non-high availability can
206 result.
208 Since traffic reaches services based on network topology,
209 alternate, or redundant service functions must be placed in the
210 same topology as the primary service.
212 4. Consistent Ordering of Service Functions: Service functions are
213 typically independent; service function_1 (SF1)...service
214 function_n (SFn) are unrelated and there is no notion at the
215 service layer that SF1 occurs before SF2. However, to an
216 administrator many service functions have a strict ordering that
217 must be in place, yet the administrator has no consistent way to
218 impose and verify the ordering of the functions that used to
219 deliver a given service.
221 5. Service Chain Construction: Service chains today are most
222 typically built through manual configuration processes. These
223 are slow and error prone. With the advent of newer service
224 deployment models the control / management planes will provide
225 not only connectivity state, but will also be increasingly
226 utilized for the formation of services. Such a control /
227 management plane could be centrally controlled and managed, or
228 be distributed between a subset of end-systems.
230 6. Application of Service Policy: Service functions rely on
231 topology information such as VLANs or packet (re) classification
232 to determine service policy selection, i.e. the service function
233 specific action taken. Topology information is increasingly
234 less viable due to scaling, tenancy and complexity reasons. The
235 topological information is often stale, providing the operator
236 with inaccurate placement that can result in suboptimal resource
237 utilization. Per-service function packet classification is
238 inefficient and prone to errors, duplicating functionality
239 across services. Furthermore packet classification is often too
240 coarse lacking the ability to determine class of traffic with
241 enough detail.
243 7. Transport Dependence: Services can and will be deployed in
244 networks with a range of transports, including under and
245 overlays. The coupling of services to topology requires
246 services to support many transports or for a transport gateway
247 function to be present.
249 8. Elastic Service Delivery: Given the current state of the art for
250 adding/removing services largely centers around VLANs and
251 routing changes, rapid changes to the service layer can be hard
252 to realize due to the risk and complexity of such changes.
254 9. Traffic Selection Criteria: Traffic selection is coarse, that
255 is, all traffic on a particular segment traverse service
256 functions whether the traffic requires service enforcement or
257 not. This lack of traffic selection is largely due to the
258 topological nature of service deployment since the forwarding
259 topology dictates how (and what) data traverses service
260 function(s). In some deployments, more granular traffic
261 selection is achieved using policy routing or access control
262 filtering. This results in operationally complex configurations
263 and is still relatively inflexible.
265 10. Limited End-to-End Service Visibility: Troubleshooting service
266 related issues is a complex process that involve network and
267 service expertise. This is especially the case when service
268 chains span multiple DCs, or across administrative boundaries
269 such as externally consumable service chain components.
271 11. Per-Service (re)Classification: Classification occurs at each
272 service, independent from previously applied service functions.
273 These unrelated classification events consume resources per
274 service. More importantly, the classification functionality
275 often differs per service and services cannot leverage the
276 results from other deployed network or service.
278 12. Symmetric Traffic Flows: Service chains may be unidirectional or
279 bidirectional; unidirectional is one where traffic is passed
280 through a set of service functions in one forwarding direction
281 only. Bidirectional is one where traffic is passed through a
282 set of service functions in both forwarding directions.
283 Existing service deployment models provide a static approach to
284 realizing forward and reverse service chain association most
285 often requiring complex configuration of each network device
286 throughout the forwarding path.
288 3. Service Function Chaining for Adding Network Services
290 Service chaining provides a framework to address the aforementioned
291 problems associated with service deployments:
293 1. Service Overlay: Service chaining utilizes a service specific
294 overlay that creates the service topology: the overlay creates a
295 path between service nodes. The service overlay is independent
296 of the network topology and allows operators to use whatever
297 overlay or underlay they prefer and to locate service functions
298 in the network as needed. Within the service topology, services
299 can be viewed as resources for consumption and an arbitrary
300 topology constructed to connect those resources in a required
301 order. Furthermore, additional service instances, for redundancy
302 or load distribution, can be added or removed to the service
303 topology as required. Lastly, the service overlay can provide
304 service specific information needed for troubleshooting service-
305 related issues.
307 2. Generic Service Control Plane (GSCP): GSCP provides information
308 about the available services on a network. The information
309 provided by the control plane includes service network location
310 (for topology creation), service type (e.g. firewall, load
311 balancer, etc.) and, optionally, administrative information about
312 the services such as load, capacity and operating status. GSCP
313 allows for the formulation of service chains and disseminates the
314 service chains to the network.
316 3. Service Classification: Classification is used to select which
317 traffic enters a service overlay. The granularity of the
318 classification varies based on device capabilities, customer
319 requirements, and service functionality. Initial classification
320 is used to start the service chain. Subsequent classification
321 can be used within a given service chain to alter the sequence of
322 services applied. Symmetric classification ensures that forward
323 and reverse chains are in place.
325 4. Dataplane Metadata: Dataplane metadata provides the ability to
326 exchange information between the network and services, services
327 and services and services and the network. Metadata can include
328 the result of antecedent classification, information from
329 external sources or forwarding related data. For example,
330 services utilize metadata, as required, for localized policy
331 decision.
333 4. Related IETF Work
335 The following subsections discuss related IETF work and are provided
336 for reference. This section is not exhaustive, rather it provides an
337 overview of the various initiatives and how they relate to network
338 service chaining.
340 1. L3VPN[L3VPN]: The L3VPN working group is responsible for
341 defining, specifying and extending BGP/MPLS IP VPNs solutions.
342 Although BGP/MPLS IP VPNs can be used as transport for service
343 chaining deployments, the service chaining WG focuses on the
344 service specific protocols, not the general case of VPNs.
345 Furthermore, BGP/MPLS IP VPNs do not address the requirements for
346 service chaining.
348 2. LISP[LISP]: LISP provides locator and ID separation. LISP can be
349 used as an L3 overlay to transport service chaining data but does
350 not address the specific service chaining problems highlighted in
351 this document.
353 3. NVO3[NVO3]: The NVO3 working group is chartered with creation of
354 problem statement and requirements documents for multi-tenant
355 network overlays. NVO3 WG does not address service chaining
356 protocols.
358 4. ALTO[ALTO]: The Application Layer Traffic Optimization Working
359 Group is chartered to provide topological information at a higher
360 abstraction layer, which can be based upon network policy, and
361 with application-relevant services located in it. The mechanism
362 for ALTO obtaining the topology can vary and policy can apply to
363 what is provided or abstracted. This work could be leveraged and
364 extended to address the need for services discovery.
366 5. I2RS[I2RS]: The Interface to the Routing System Working Group is
367 chartered to investigate the rapid programming of a device's
368 routing system, as well as the service of a generalized, multi-
369 layered network topology. This work could be leveraged and
370 extended to address some of the needs for service chaining in the
371 topology and device programming areas.
373 5. Summary
375 This document highlights problems associated with network service
376 deployment today and identifies several key areas that will be
377 addressed by the service chaining working group. Furthermore, this
378 document identifies four components that are the basis for serice
379 chaining. These components will form the areas of focus for the
380 working group.
382 6. Security Considerations
384 Security considerations are not addressed in this problem statement
385 only document. Given the scope of service chaining, and the
386 implications on data and control planes, security considerations are
387 clearly important and will be addressed in the specific protocol and
388 deployment documents created by the service chaining working group.
390 7. Acknowledgments
392 The authors would like to thank David Ward, Rex Fernando and Jim
393 French for their contributions.
395 8. References
397 8.1. Normative References
399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
400 Requirement Levels", BCP 14, RFC 2119, March 1997.
402 8.2. Informative References
404 [ALTO] "Application-Layer Traffic Optimization (alto)",
405 .
407 [I2RS] "Interface to the Routing System (i2rs)",
408 .
410 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)",
411 .
413 [LISP] "Locator/ID Separation Protocol (lisp)",
414 .
416 [NVO3] "Network Virtualization Overlays (nvo3)",
417 .
419 Authors' Addresses
421 Paul Quinn
422 Cisco Systems, Inc.
424 Email: paulq@cisco.com
426 Jim Guichard
427 Cisco Systems, Inc.
429 Email: jguichar@cisco.com
431 Surendra Kumar
432 Cisco Systems, Inc.
434 Email: smkumar@cisco.com
436 Abhishek Chauhan
437 Citrix
439 Email: Abhishek.Chauhan@citrix.com
441 Nic Leymann
442 Deutsche Telekom
444 Email: n.leymann@telekom.de
446 Mohamed Boucadair
447 France Telecom
449 Email: mohamed.boucadair@orange.com
451 Christian Jacquenet
452 France Telecom
454 Email: christian.jacquenet@orange.com
455 Michael Smith
456 Insieme Networks
458 Email: michsmit@insiemenetworks.com
460 Navindra Yadav
461 Insieme Networks
463 Email: nyadav@insiemenetworks.com
465 Thomas Nadeau
466 Juniper Networks
468 Email: tnadeau@juniper.net
470 Ken Gray
471 Juniper Networks
473 Email: kgray@juniper.net
475 Brad McConnell
476 Rackspace
478 Email: bmcconne@rackspace.com