Internet DRAFT - draft-lee-sfc-verification
draft-lee-sfc-verification
Network Working Group S. Lee
Internet-Draft M. Shin
Intended status: Informational ETRI
Expires: August 18, 2014 February 14, 2014
Service Function Chaining Verification
draft-lee-sfc-verification-00
Abstract
This document addresses the possible conflicts among different
service function chains. These conflicts may occur when 1) a traffic
flow satisfies two or more classification rules of different service
function chains; and 2) a service function cannot provide enough
resource for a service function chain due to load of other service
function chains. These conflicts need to be detected and resolved at
deploying a new service chain.
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 August 18, 2014.
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
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Lee & Shin Expires August 18, 2014 [Page 1]
Internet-Draft SFC Verification February 2014
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Verification of Service Function Chains . . . . . . . . . . . 3
4. Security Considerations . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Normative References . . . . . . . . . . . . . . . . . . 4
6.2. Informative References . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4
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 (SFC)
[I-D.ietf-sfc-problem-statement] provides a new service deployment
model that delivers the traffic along the predefined logical paths of
service functions (i.e., service overlays or service chains). The
service overlay provides a specific order of network services with no
regard of network topologies. The traffic is classified with a set
of rules in different granularity to select a target service overlay.
The service overlays are configured to be isolated from each other
with virtualization of the network resources and different traffic
classification rules. However, the service overlays can share the
physical network resources (such as network links, service nodes, and
service functions); and the traffic classification rules can overlap
each other. This may cause unexpected QoS degradation in a composite
network service due to network service overload; and service failure
due to loops or interventions of the service overlays. It is
required to detect and resolve these conflicts when deploying a new
service function chain.
This document formulates these problems as two conflicts at deploying
service function chains: rule conflict and resource conflict.
2. Problem Areas
The problem areas of the conflicts can be specified as follows:
1. Rule conflict:
Lee & Shin Expires August 18, 2014 [Page 2]
Internet-Draft SFC Verification February 2014
An incoming traffic flow (i.e., a series of packets) is
classified according to a classification rules to determine which
service function chain will handle it. The classification is
based on the contents of one or more packet header fields so that
the classification rule may vary in different granularity. This
may bring a problematic case that an incoming packet matches two
or more classification rules of different service function
chains, which can result in a service chain loop or intervention.
For example, let's assume that there are two service function
chains: SFC_A which handles the video traffics; and SFC_B which
handles the packets sent by host H. Video traffic from host H
satisfies both of SFC_A and SFC_B and this brings a rule conflict
at service classification.
2. Resource conflict:
A service function chain constitutes a service-specific overlay
that utilizes network resources such as service nodes, network
links between service functions, and service function instances.
These network resources may be shared by different service
function chains. This brings an uncertainty in QoS of service
function chains if there is no coordination for the use of
network resources. For example, let's assume that a service
function instance F is shared by the service function paths of
SFC_A and SFC_B. If the service function instance F is fully
loaded by the traffic over SFC_A, SFC_B cannot provide an
expected service quality due to resource shortage.
3. Verification of Service Function Chains
The aforementioned problems arise from the conflicts between two or
more service function chains. Thus, it is required to have a
verification function to detect and avoid those conflicts.
The rule conflict can be detected by examining if there is any
overlapping in a new classification rule with the existing
classification rules when deploying a new service function chain. A
bitwise comparison of target packet headers can be used for the
examination. However, if the rules classify the packets with the
header filed values in different layers (e.g., IP address and TCP
port), then inclusive relationship between different classification
rules should be also considered.
When a new classification rule is detected to have a conflict with
the existing ones, then the new service function chain should be
rejected to remove an uncertainty. While different priorities of the
classification rules in a conflict can be used instead, it may bring
higher complexity in rule matching and priority decisions.
Lee & Shin Expires August 18, 2014 [Page 3]
Internet-Draft SFC Verification February 2014
The resource conflict can be detected by checking if the resource of
the network and service functions is available enough for the new
service function chain. An explicit request for the resources can be
made beforehand by the service function chain or the resource usage
can be dynamically determined by classified traffic over the service
function path. When the resource is not available enough for a
request, the new service function chain can be rejected to be
deployed. An alternative service function path can be dynamically
initiated instead to utilize different network resources or service
function instances for the chain.
4. Security Considerations
TBD.
5. IANA Considerations
TBD.
6. References
6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
6.2. Informative References
[I-D.ietf-sfc-problem-statement]
Quinn, P. and T. Nadeau, "Service Function Chaining
Problem Statement", draft-ietf-sfc-problem-statement-00,
January 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 August 18, 2014 [Page 4]
Internet-Draft SFC Verification February 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 August 18, 2014 [Page 5]
