SFC dynamic instantiation
draft-lee-sfc-dynamic-instantiation-00
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Seungik Lee , Myung-Ki Shin | ||
| Last updated | 2014-07-04 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-lee-sfc-dynamic-instantiation-00
Network Working Group S. Lee
Internet-Draft M-K. Shin
Intended status: Informational ETRI
Expires: January 5, 2015 July 4, 2014
SFC dynamic instantiation
draft-lee-sfc-dynamic-instantiation-00
Abstract
SFC instantiation may be static or dynamic. In a static
instantiation, specific SF instances are predetermined by network
operator's configuration or policy. However, since it does not
consider the current state of network resources such as availability
of the SF instances, the static instantiation may create more
vulnerable SFPs to state changes of the network resources such as
failure or overload. This document specifies SFC dynamic
instantiation capability to create and update SFPs considering
traffic optimization, failover of SFIs, and load balancing.
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 January 5, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Lee & Shin Expires January 5, 2015 [Page 1]
Internet-Draft SFC dynamic instantiation July 2014
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 instantiation . . . . . . . . . . . . . . . . . . . . . . 3
4. Dynamic instantiation of SFC . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Normative References . . . . . . . . . . . . . . . . . . 6
7.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
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 and
customer 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).
The SFC remains still if there are no changes in the operator's
policies for the target traffic. However, the SFP may vary in time
with resource state of SF instances and underlying transport at the
instantiation to support traffic optimization, failover of service
function instances (SFIs), or load balancing. For example, an
instance of SF_A can be replaced by another instance of SF_A deployed
at a different service node (SN) when the former one fails to
function.
This document specifies SFC dynamic instantiation capability to
create and update SFPs considering traffic optimization, failover of
SFIs, and load balancing. Based on the capability and the use cases,
SFC architecture needs to consider the attributes of resources for SF
instances at control plane.
Lee & Shin Expires January 5, 2015 [Page 2]
Internet-Draft SFC dynamic instantiation July 2014
2. Terminology
This document uses the following terms and most of them were
reproduced from [I-D.ietf-sfc-problem-statement] and
[I-D.quinn-sfc-arch].
o Classification: Locally instantiated policy and customer/network/
service profile matching of traffic flows for identification of
appropriate outbound forwarding actions.
o Service Function (SF): A function that is responsible for specific
treatment of received packets. A Service Function can act at the
network layer or other OSI layers.
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: An offering provided by an operator that is delivered
using one or more service functions. This may also be referred to
as a composite service.
o Service Node (SN): Physical or virtual element that hosts one or
more service functions and has one or more network locators
associated with it for reachability and service delivery.
o Service Function Chain (SFC): A service Function chain defines an
ordered set of service functions 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 nodes that copy to more than one branch. The term service
chain is often used as shorthand for service function chain.
o Service Function Path (SFP): The instantiation of a SFC in the
network. Packets follow a service function path from a classifier
through the requisite service functions.
3. SFC instantiation
Service function chaining provides 3-level abstraction of the network
for service delivery: SFC overlay, Service Function Path (SFP), and
Service Function Chain (SFC).
The physical resources for Service Functions and their connectivity
are abstracted as a SFC overlay.
Lee & Shin Expires January 5, 2015 [Page 3]
Internet-Draft SFC dynamic instantiation July 2014
An ordered set of service functionalities per traffic is specified by
a SFC. The SFC can be further deployed by a SFP which specifies the
logical functions with their physical instances.
Under this abstraction, the traffic flows are forwarded along the
SFPs which can be obtained by two separate steps: classification and
SFC instantiation.
o Classification: SFCs are selected and identified by a
classification function according to the traffic steering policy
defined by network operators. The policy just defines which
service functions must be applied to traffic flows in specific
orders. It does not consider which network resources are
available or ready for the service functions.
o SFC instantiation: In order to forward the traffic flows along the
SFC, it needs to be instantiated to a SFP by selecting the
specific instances of the service functions given in the SFC
considering the state of resources and transport.
+------+ +------+ +------+
SFC | SF1 |-----------| SF2 |-----------| SF3 |
+------+ +------+ +------+
+------+ +------+ +------+
SFP#1 |SF1_a |-----------|SF2_b |-----------|SF3_a |
+------+ +------+ +------+
+------+ +------+ +------+
SFP#2 |SF1_a |-----------|SF2_a |-----------|SF3_b |
+------+ +------+ +------+
+-------+
| SF2_a |
+-------+ +-------+ +-------+
| SF1_a | ___/ | SF3_a |
+-------+ (___) +-------+
___/ / \ ___/
SFC overlay (___)+-----------+ +-----------+(___)
\ ___ / \
(___) +-------+
\ | SF3_b |
+-------+ +-------+
| SF2_b |
+-------+
Figure 1: SFC instantiation
Lee & Shin Expires January 5, 2015 [Page 4]
Internet-Draft SFC dynamic instantiation July 2014
For example as depicted in Figure 1, {SFC: SF1 -> SF2 -> SF3} is
selected for a traffic flow by the classification function. This SFC
can be further instantiated to two different SFPs: {SFP#1: SF1_a ->
SF2_b -> SF3_a} and {SFP#2: SF1_a -> SF2_a -> SF3_b} by selecting one
of multiple instances of the service functions.
The SFC instantiation may be static or dynamic. In a static
instantiation, specific SF instances are predetermined 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 of network resources such as
availability of the SF instances, the static instantiation may create
more vulnerable SFPs to state changes of the network resources such
as failure or overload.
4. Dynamic instantiation of SFC
In a dynamic SFC instantiation, SF instances are selected considering
attribute of the network resources at time of demand, specifically:
o SF instances for every SF given are selected to construct a
complete SFP before starting to forward traffic flows along the
SFP
o SF instance is selected or replaced at time of delivering the
traffic flow to the SF
The use of two different methods for creating SFPs depends on use
cases of the dynamic SFC instantiation as follows:
o Traffic optimization: constructs SFPs with low stress and stretch
considering the different locations of multiple SF instances.
o Load balancing: selects SF instances to distribute load for the
traffic considering the current status of SF instances or service
nodes where the instances are embedded.
o Failover of SF instance: selects live SF instances and replaces SF
instances in failure by checking their availability.
In order to support those use cases, the criteria to select one of
multiple service function instances (SFIs) may vary but mainly from
state of network resources and attributes of traffic flow such as:
o Availability, load, performance of SF instances, service nodes,
SFP transport links (among SF instances)
Lee & Shin Expires January 5, 2015 [Page 5]
Internet-Draft SFC dynamic instantiation July 2014
o Topological location of source and destination
o Volume of traffic flow
5. Security Considerations
TBD.
6. IANA Considerations
TBD.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-07,
June 2014.
[I-D.quinn-sfc-arch]
Quinn, P. and J. Halpern, "Service Function Chaining (SFC)
Architecture", draft-quinn-sfc-arch-05, May 2014.
Authors' Addresses
Seung-Ik Lee
ETRI
218 Gajeong-ro Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 1483
Email: seungiklee@etri.re.kr
Lee & Shin Expires January 5, 2015 [Page 6]
Internet-Draft SFC dynamic instantiation July 2014
Myung-Ki Shin
ETRI
218 Gajeong-ro Yuseung-Gu
Daejeon 305-700
Korea
Phone: +82 42 860 4847
Email: mkshin@etri.re.kr
Lee & Shin Expires January 5, 2015 [Page 7]