Service function Chaining S. Lee
Internet-Draft ETRI
Intended status: Informational S. Pack
Expires: April 30, 2015 KU
M-K. Shin
ETRI
E. Paik
KT
October 27, 2014
SFC dynamic instantiation
draft-lee-sfc-dynamic-instantiation-01
Abstract
This document describes a control plane architecture for dynamic
instantiation of service function chains which dynamically creates
and adapts service function paths to optimize performance of the
service function paths. This document further defines basic
operations for the dynamic instantiations; and performance metrics of
service function path components, i.e., service function instances
and forwarding links among service function forwarders for evaluation
of the service function path.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lee, et al. Expires April 30, 2015 [Page 1]
Internet-Draft SFC dynamic instantiation October 2014
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. SFC dynamic instantiation . . . . . . . . . . . . . . . . . . 4
4. Control plane architecture . . . . . . . . . . . . . . . . . 6
5. Operational procedures . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
The current service delivery model is bound to static topologies and
manually configured resources. This has motivated a more flexible
deployment model which orchestrates the service delivery separated
from the network. Service function chaining
[I-D.ietf-sfc-problem-statement] provides a new service deployment
model that delivers the traffic along the predefined logical paths of
service functions (SFs), called service function chains (SFCs) with
no regard of network topologies or transport mechanisms.
A SFC is determined by classification of target traffic based on
operator's policy. Since it is described with logical SFs, the
service function chain needs to be instantiated by selecting
instances of the SFs, which results in a service function path (SFP).
Performance of a SFP depends on the current state or attributes
(e.g., availability, topological location, and latency) of SFP
components (i.e., SF instances (SFIs) and forwarding links among SFFs
(SFLs)). Thus, the SFP performance may vary according to which SFIs
are selected at SFC instantiation; and it may also vary in time with
the state or attributes of the SFP components.
This document describes a control plane architecture for dynamic
instantiation of SFCs which dynamically creates and adapts SFPs to
Lee, et al. Expires April 30, 2015 [Page 2]
Internet-Draft SFC dynamic instantiation October 2014
optimize the SFP performance considering the current state and
attributes of SFIs and SFLs. This document further defines basic
operations for the dynamic instantiations and performance metrics of
SFP components for SFP evaluation.
2. Terminology
This document uses the following terms and most of them were
reproduced from [I-D.ietf-sfc-problem-statement] and
[I-D.ietf-sfc-architecture].
o Classification: Locally instantiated policy and customer/network/
service profile matching of traffic flows for identification of
appropriate outbound forwarding actions.
o Service Function Chain (SFC): A service function chain defines a
set of abstract service functions and ordering constraints that
must be applied to packets and/or frames selected as a result of
classification. The implied order may not be a linear progression
as the architecture allows for SFCs that copy to more than one
branch, and also allows for ere there is flexibility in the order
in which service functions need to be applied. The term service
chain is often used as shorthand for service function chain.
o Service Function (SF): A function that is responsible for specific
treatment of received packets. A Service Function can act at
various layers of a protocol stack (e.g., at the network layer or
other OSI layers). As a logical component, a Service Function can
be realized as a virtual element or be embedded in a physical
network element. One or multiple Service Functions can be
embedded in the same network element. Multiple occurrences of the
Service Function can exist in the same administrative domain.
o Service Function Instance (SFI): The instantiation of Service
Function that can be a virtual instance or be embedded in a
physical network element. One of multiple Service Functions can
be embedded in the same network element. Multiple instances of
the Service Function can be enabled in the same administrative
domain.
o Service Function Forwarder (SFF): A service function forwarder is
responsible for delivering traffic received from the network to
one or more connected service functions according to information
carried in the SFC encapsulation, as well as handling traffic
coming back from the SF. Additionally, a service function
forwarder is responsible for delivering traffic to a classifier
when needed and supported, mapping out traffic to another SFF (in
the same or different type of overlay), and terminating the SFP.
Lee, et al. Expires April 30, 2015 [Page 3]
Internet-Draft SFC dynamic instantiation October 2014
o Service Function Path (SFP): The SFP provides a level of
indirection between the fully abstract notion of service chain as
a sequence of abstract service functions to be delivered, and the
fully specified notion of exactly which SFF/SFs the packet will
visit when it actually traverses the network. By allowing the
control components to specify this level of indirection, the
operator may control the degree of SFF/SF selection authority that
is delegated to the network.
o Service Forwarding Link (SFL): An overlay link between two SFFs
over which the packet will visit SF along the SFP.
3. SFC dynamic instantiation
A service function chain is composed of one or more logical service
functions and it can be further instantiated with a SFP which
contains physical instances of the logical SFs. Since multiple
instances of a SF may be available, different sets of SFI (i.e.,
SFPs) can be built per SFC.
For example in Figure 1, a SFC {SF1 -> SF2 -> SF3} selected for a
traffic flow can be further instantiated with two different SFPs:
SFP#1 {SF1_a -> SF2_a -> SF3_a} and SFP#2 {SF1_b -> SF2_b -> SF3_b}
by selecting one of multiple instances of the service functions.
+------+ +------+ +------+
SFC | SF1 |-----------| SF2 |-----------| SF3 |
+------+ +------+ +------+
+------+ +------+ +------+
|SF1_a | |SF2_a | |SF3_a |
+------+ +------+ +------+
SFP#1 | | |
******** ******** ********
* SFF *-----------* SFF *-----------* SFF *
******** SFL ******** SFL ********
SFP#2 | | |
+------+ +------+ +------+
|SF1_b | |SF2_b | |SF3_b |
+------+ +------+ +------+
Figure 1: SFC instantiation
Under this abstraction, a SFC can be constructed by the following
operations:
Lee, et al. Expires April 30, 2015 [Page 4]
Internet-Draft SFC dynamic instantiation October 2014
o Classification: One SFC is selected and identified by a
classification function according to the traffic steering policy
defined by the network operator. The policy just logically
defines which service functions must be applied to traffic flows
in a specific order.
o Re-classification (or branching): According to an intermediate
result of packet treatment, the current SFC can be updated by
adding or removing SFs, which results in creation of a new SFP.
o SFC instantiation: In order to define the physical forwarding
paths for the traffic, the SFC needs to be instantiated to a SFP
by selecting a specific instance of each service function that is
given in the SFC. The SFP can be updated by replacing one or more
conventional SF instances with the other ones at run-time. Note
that it does not cause change of a SF but change of a physical
instance of the same SF.
The SFC instantiation may be static or dynamic. In a static
instantiation, specific SF instances are pre-determined by network
operator's configuration or policy. The static instantiation may be
more convenient for network administrators because they can easily
expect the result and troubleshooting locations. However, since it
does not consider the current state and attribute of SFIs, the static
instantiation may create more vulnerable SFPs to state changes of the
SFIs such as failure or overload.
In a dynamic SFC instantiation, SFIs are selected according to their
states and attributes at time of demand, specifically at initial
classification or during intermediate traversal of the SFP.
o At classification: SF instances are selected to initially
construct a SFP before starting to forward the incoming traffic
flows
o At intermediate traversal: One or more SF instances are selected
and dynamically replaced during traversing the SFP to update the
SFP
The example use cases of SFC dynamic instantiation are as follows:
o SFP fail-over: re-construct a SFP with replacing the failed SFI
with new SFI selected
o End-to-end service optimization: construct or maintain a SFP with
a low stretch considering the topological locations of SFI and
properties (e.g., latency, bandwidth) of SFLs
Lee, et al. Expires April 30, 2015 [Page 5]
Internet-Draft SFC dynamic instantiation October 2014
o Traffic optimization: construct or maintain SFPs to localize the
traffic in the network considering load and administrative domains
of SFIs and SFLs.
o Load balancing: construct or maintain SFPs to distribute the load
of shared SFIs and SFLs.
For more details about the use cases, refer to
[I-D.lee-nfvrg-resource-management-service-chain].
4. Control plane architecture
In order to instantiate a SFC dynamically according to the state and
attributes of SFP components, the following functional building
blocks are required in a SFC control plane architecture.
SFC instantiation
o Evaluate SFIs and SFLs based on the measurements obtained from SFP
component management building block
o Select SFIs to construct a SFP optimized according to the
evaluation results
o Enforce the constructed SFP for incoming traffic to the
classification node via interface-(a)
o Replace SFIs to update a SFP adapted to changes of state or
attributes of SFIs and SFLs
o Enforce the updated SFP for upcoming SFC traversal to SFFs via
interface-(b)
SFP component management
o Collect and monitor state and attributes of SFIs and SFLs via
interface-(d) and interface-(c), respectively
o Provide the collected state and attributes of SFIs and SFLs to SFC
instantiation building block for evaluation
Lee, et al. Expires April 30, 2015 [Page 6]
Internet-Draft SFC dynamic instantiation October 2014
#=================================================#
# #
# +---------------+ +---------------+ #
# ____| SFC |______| SFP component | #
# | | instantiation | | management | #
# | +---------------+ +---------------+ #
# | | ^ ^ #
#===|=============|=================|=====|=======#
| | | |
|(a) |(b) |(c) |(d)
| | | |
| | +------+ | +------+
| | | SFI | | | SFI |
| | +------+ | +------+
V V | | |
******** ******** ********
-* CLSF *-------* SFF *-----------* SFF *--------
******** ******** ********
Figure 2: Control plane architecture for SFC dynamic instantiation
The state and attributes of SFP components for SFP evaluation can be
obtained via interface-(c) and interface-(d). Examples of the state
and attributes of SFP components are as follows:
o availability (or failure) of a SFI and a SFL
o a topological location of a SFI
o a utilization rate of a SFI
o a throughput of a SFI
o energy consumption of SFI
o bandwidth of a SFL
o latency of a SFL
5. Operational procedures
(TBD)
Lee, et al. Expires April 30, 2015 [Page 7]
Internet-Draft SFC dynamic instantiation October 2014
6. Security Considerations
(TBD)
7. IANA Considerations
(TBD)
8. References
8.1. Normative References
[I-D.ietf-sfc-architecture]
Halpern, J. and C. Pignataro, "Service Function Chaining
(SFC) Architecture", draft-ietf-sfc-architecture-02 (work
in progress), September 2014.
[I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-10
(work in progress), August 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.lee-nfvrg-resource-management-service-chain]
Lee, S., Pack, S., Shin, M., and E. Paik, "Resource
Management for Dynamic Service Chain Adaptation", draft-
lee-nfvrg-resource-management-service-chain-00 (work in
progress), October 2014.
[I-D.ww-sfc-control-plane]
Li, H., Wu, Q., Boucadair, M., Jacquenet, C., and W.
Haeffner, "Service Function Chaining (SFC) Control Plane
Achitecture", draft-ww-sfc-control-plane-03 (work in
progress), September 2014.
Authors' Addresses
Lee, et al. Expires April 30, 2015 [Page 8]
Internet-Draft SFC dynamic instantiation October 2014
Seung-Ik Lee
ETRI
218 Gajeong-ro Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 1483
Email: seungiklee@etri.re.kr
Sangheon Pack
Korea University
145 Anam-ro, Seongbuk-gu
Seoul 136-701
Korea
Phone: +82 2 3290 4825
Email: shpack@etri.re.kr
Myung-Ki Shin
ETRI
218 Gajeong-ro Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 4847
Email: mkshin@etri.re.kr
EunKyoung Paik
KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82 2 526 5233
Email: eun.paik@kt.com
Lee, et al. Expires April 30, 2015 [Page 9]