idnits 2.17.1
draft-quinn-nsc-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 (June 13, 2013) is 3969 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Unused Reference: 'RFC2119' is defined on line 345, but no explicit
reference was found in the text
== Unused Reference: 'L3VPN' is defined on line 350, but no explicit
reference was found in the text
== Unused Reference: 'LISP' is defined on line 353, but no explicit
reference was found in the text
== Unused Reference: 'NVO3' is defined on line 356, but no explicit
reference was found in the text
Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Guichard
3 Internet-Draft S. Kumar
4 Intended status: Informational P. Quinn
5 Expires: December 15, 2013 Cisco Systems, Inc.
6 M. Smith
7 N. Yadav
8 Insieme Networks
9 June 13, 2013
11 Network Service Chaining Problem Statement
12 draft-quinn-nsc-problem-statement-00.txt
14 Abstract
16 This document provides an overview of the issues associated with the
17 deployment of network services (such as firewalls, load balancers) in
18 large-scale environments. The term service chaining is used to
19 describe the deployment of such services, and the ability of a
20 network operator to specify an ordered list of services that should
21 be applied to a deterministic set of traffic flows. Such service
22 chains require integration of service policy alongside the deployment
23 of applications, while maintaining optimal use of available network
24 capacity and resources.
26 Status of this Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on December 15, 2013.
43 Copyright Notice
45 Copyright (c) 2013 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3
62 2. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . 5
63 3. Service Chaining for Adding Network Services . . . . . . . . . 8
64 4. Related IETF Work . . . . . . . . . . . . . . . . . . . . . . 9
65 5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
70 8.2. Informative References . . . . . . . . . . . . . . . . . . 13
71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
73 1. Introduction
75 New data center (DC) network and Internet cloud architectures require
76 more flexible deployment models that are able to support many
77 different forms of applications and related network services.
78 Network services include traditional services such as firewalls and
79 server load balancer, as well as applications and features that
80 operate on network data. Additionally, these services must be
81 delivered in the context of multi-tenancy where each individual
82 tenant is an isolated client organization attached to the data
83 center, and may require unique capabilities with the ability to
84 tailor service characteristics on a per-tenant basis.
86 The current network service deployment models are relatively static,
87 and bound to topology for insertion and policy selection.
88 Furthermore, they do not adapt well to elastic service environments
89 enabled by virtualization. Additionally, the transition to virtual
90 platforms requires an agile service insertion model that supports
91 elastic service delivery; supports the movement of service functions
92 and application workloads in the network while retaining the network
93 and service policies and the ability to easily bind service policy to
94 granular information such as per-subscriber state.
96 This document outlines the problems encountered with existing service
97 deployment models for service chaining, as well as the problems of
98 service chain creation/deletion, policy selection integration with
99 service chains, and policy enforcement within the network
100 infrastructure.
102 1.1. Definition of Terms
104 Classification: Locally instantiated policy and customer/network/
105 service profile matching of traffic flows for identification of
106 appropriate outbound forwarding actions.
108 Network Overlay: Logical network built on top of existing network
109 (the underlay). Packets are encapsulated or tunneled to create
110 the overlay network topology.
112 Service Chain: A service chain defines the services required
113 (e.g.FW), and their order (service1 --> service2) that must be
114 applied to packets and/or frames.
116 Service Function: A L4-L7 service function (NAT, FW, DPI, IDS,
117 application based packet treatment), application, compute
118 resource, storage, or content used singularly or in collaboration
119 with other service functions to enable a service offered by a
120 network operator.
122 Service Node: Physical or virtual element providing one or more
123 service functions.
125 Network Service: An externally visible service offered by a network
126 operator; a service may consist of a single service function or a
127 composite built from several service functions executed in one or
128 more pre-determined sequences.
130 2. Problem Areas
132 The following points describe aspects of existing service deployment
133 techniques that are problematic, and are being addressed by the
134 network service chaining effort.
136 1. Topological Dependencies: Network service deployments are often
137 coupled to the physical network topology creating artificial
138 constraints on delivery and inhibiting the network operator from
139 sharing service resources and scale capacity/redundancy across
140 multiple network devices. These topologies serve only to
141 "insert" the service function; they are not required from a
142 native packet delivery perspective. For example, firewalls
143 often require an "in" and "out" layer-2 segment and adding a new
144 firewall requires changing the topology (i.e. adding new L2
145 segments). As more services are required - often with strict
146 ordering - topology changes are needed before and after each
147 service resulting in complex network changes and device
148 configuration. In such topologies, all traffic, whether a
149 service needs to be applied or not, often passes through the
150 same strict order. A common example is web servers using a
151 server load balancer as the default gateway. When the web
152 service responds to non-load balanced traffic (e.g.
153 administrative or backup operations) all traffic from the server
154 must traverse the load balancer forcing network administrators
155 to create complex routing schemes or create additional
156 interfaces to provide an alternate topology.
158 2. Configuration complexity: A direct consequence of topological
159 dependencies is the complexity of the entire configuration,
160 specifically in deploying service chains. Simple actions such
161 as changing the order of the service functions in a service
162 chain require changes to the topology. Changes to the topology
163 is avoided by the network operator once installed, configured
164 and deployed in production environments fearing misconfiguration
165 and downtime. All of this leads to very static service delivery
166 models.
168 3. Constrained High Availability: An effect of topological
169 dependency is constrained service high availability. Since
170 traffic reaches services based on network topology, alternate,
171 or redundant service functions must be placed in the same
172 topology as the primary service.
174 4. Consistent Ordering of Service Functions: Service functions are
175 typically independent; service function_1 (SF1)...service
176 function_n (SFn) are unrelated and there is no notion at the
177 service layer that SF1 occurs before SF2. However, to an
178 administrator many service functions have a strict ordering that
179 must be in place, yet the administrator has no consistent way to
180 impose and verify the deployed service ordering.
182 5. Service Chain Construction: Service chains today are most
183 typically built through manual configuration processes. With
184 the advent of newer service deployment models the control plane
185 will provide not only connectivity state and membership
186 distribution across tenants, but will also be increasingly
187 utilized for the formation of services. Such a control plane
188 could be centrally controlled and managed, or be distributed
189 between a subset of end-systems. Formation of closed user
190 groups that are able to maintain separation of forwarding and
191 connectivity state, while at the same time be independently
192 identified and directed through appropriate services, requires
193 the ability to create "zones" of awareness and "chained"
194 services.
196 6. Application of Service Policy: Service functions rely on
197 topology information such as VLANs or packet (re) classification
198 to determine service policy selection, i.e. the service action
199 taken. Topology information is increasingly less viable due to
200 scaling, tenancy and complexity reasons. Per-service function
201 packet classification is inefficient and prone to errors,
202 duplicating functionality across services. Furthermore packet
203 classification is often too coarse lacking the ability to
204 determine class of traffic with enough detail.
206 7. Transport Dependence: Services can and will be deployed in
207 networks with a range of transports, including under and
208 overlays. The coupling of services to topology requires
209 services to support many transports or for a transport gateway
210 function to be present.
212 8. Elastic Service Delivery: Given the current state of the art for
213 adding/removing services largely centers around VLANs and
214 routing changes, rapid changes to the service layer can be hard
215 to realize due to the risk and complexity of such changes.
217 9. Traffic Selection Criteria: Traffic selection is coarse, that
218 is, all traffic on a particular segment is sent to a service
219 whether the traffic requires service enforcement or not. This
220 lack of traffic selection is largely due to the topological
221 nature of service deployment since the forwarding topology
222 dictates how (and what) data traverses the service(s). In some
223 deployments, more granular traffic selection is achieved using
224 policy routing or access control filtering. This results in
225 operationally complex configurations and is still relatively
226 inflexible.
228 10. Limited End-to-End Service Visibility: Troubleshooting service
229 related issues is a complex process that involve network and
230 service expertise.
232 11. Per-Service (re)Classification: Classification occurs at each
233 service, independently from previous service functions. These
234 unrelated classification events consume resources per service.
235 More importantly, the classification functionality often differs
236 per service and services cannot leverage the results from other
237 deployed network or service.
239 12. Symmetric Traffic Flows: Service chains may be unidirectional or
240 bidirectional; unidirectional is one where traffic is passed
241 through a set of service functions in one forwarding direction
242 only. Bidirectional is one where traffic is passed through a
243 set of service functions in both forwarding directions.
244 Existing service deployment models provide a static approach to
245 realizing forward and reverse service chain association most
246 often requiring complex configuration of each network device
247 throughout the forwarding path.
249 3. Service Chaining for Adding Network Services
251 Service chaining provides a framework to address the aforementioned
252 problems associated with service deployments:
254 1. Service Overlay: Service chaining utilizes a service specific
255 overlay that creates the service topology: the overlay creates a
256 path between service nodes. The service overlay is independent
257 of the network topology and allows operators to use whatever
258 overlay or underlay they prefer and to place services in the
259 network as needed. Within the service topology, services can be
260 viewed as resources for consumption and an arbitrary topology
261 constructed to connect those resources in a required order.
262 Furthermore, additional service instances, for redundancy or load
263 distribution, can be added or removed to the service topology as
264 required. Lastly, the service overlay can provide service
265 specific information needed for troubleshooting service-related
266 issues.
268 2. Generic Service Control Plane (GSCP): GSCP provides information
269 about the available services on a network. The information
270 provided by the control plane includes service network location
271 (for topology creation), service type (e.g. firewall vs. load
272 balancer) and, optionally, administrative information about the
273 services such as load, capacity and operating status. GSCP
274 allows for the formulation of service chains and disseminates the
275 service chains to the network.
277 3. Service Classification: Classification is used to select which
278 traffic enters a service overlay. The granularity of the
279 classification varies based on device capabilities, customer
280 requirements, and service functionality. Initial classification
281 is used to start the service chain. Subsequent classification
282 can be used within a given service chain to alter the sequence of
283 services applied. Symmetric classification ensures that forward
284 and reverse chains are in place.
286 4. Dataplane Metadata: Dataplane metadata provides the ability to
287 exchange information between the network and services, services
288 and services and services and the network. Metadata can include
289 the result of antecedent classification, information from
290 external sources or forwarding related data. For example,
291 services utilize metadata, as required, for localized policy
292 decision.
294 4. Related IETF Work
296 The following subsections discuss related IETF work and are provided
297 for reference. This section is not exhaustive, rather it provides an
298 overview of the various initiatives and how they relate to network
299 service chaining.
301 1. L3VPN: The L3VPN working group is responsible for defining,
302 specifying and extending BGP/MPLS IP VPNs solutions. Although
303 BGP/MPLS IP VPNs can be used as transport for service chaining
304 deployments, the service chaining WG focuses on the service
305 specific protocols, not the general case of VPNs. Furthermore,
306 BGP/MPLS IP VPNs do not address the requirements for service
307 chaining.
309 2. LISP: LISP provides locator and ID separation. LISP can be used
310 as an L3 overlay to transport service chaining data but does not
311 address the specific service chaining problems highlighted in
312 this document.
314 3. NVO3: The NVO3 working group is chartered with creation of
315 problem statement and requirements documents for multi-tenant
316 network overlays. NVO3 WG does not address service chaining
317 protocols.
319 5. Summary
321 This document highlights problems associated with network service
322 deployment today and identifies several key areas that will be
323 addressed by the service chaining working group. Furthermore, this
324 document identifies four components that are the basis for serice
325 chaining. These components will form the areas of focus for the
326 working group.
328 6. Security Considerations
330 Security considerations are not addressed in this problem statement
331 only document. Given the scope of service chaining, and the
332 implications on data and control planes, security considerations are
333 clearly important and will be addressed in the specific protocol and
334 deployment documents created by the service chaining working group.
336 7. Acknowledgments
338 The authors would like to thank David Ward and Rex Fernando for their
339 contributions.
341 8. References
343 8.1. Normative References
345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
346 Requirement Levels", BCP 14, RFC 2119, March 1997.
348 8.2. Informative References
350 [L3VPN] "Layer 3 Virtual Private Networks (l3vpn)",
351 .
353 [LISP] "Locator/ID Separation Protocol (lisp)",
354 .
356 [NVO3] "Network Virtualization Overlays (nvo3)",
357 .
359 Authors' Addresses
361 Jim Guichard
362 Cisco Systems, Inc.
364 Email: jguichar@cisco.com
366 Surendra Kumar
367 Cisco Systems, Inc.
369 Email: smkumar@cisco.com
371 Paul Quinn
372 Cisco Systems, Inc.
374 Email: paulq@cisco.com
376 Michael Smith
377 Insieme Networks
379 Email: michsmit@insiemenetworks.com
381 Navindra Yadav
382 Insieme Networks
384 Email: nyadav@insiemenetworks.com