Network Working Group H. Li
Internet-Draft Q. Wu
Intended status: Standards Track H. Huang
Expires: January 22, 2015 Huawei
M. Boucadair
C. Jacquenet
France Telecom
W. Haeffner
Vodafone
July 21, 2014
Service Function Chain Control Plane Framework
draft-ww-sfc-control-plane-02
Abstract
As described in [I.D-boucadair-sfc-framework], the dynamic
enforcement of a Service-derived, adequate forwarding policy for
packets entering a network that supports such advanced Service
Functions has become a key challenge for operators and service
providers.
This document is based on [I.D-boucadair-sfc-framework] and discusses
how the Service Functions chain is structured and how Service
Function Chaining path is provisioned and setup.
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 22, 2015.
Li, et al. Expires January 22, 2015 [Page 1]
Internet-Draft SFC CP July 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
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 3
3. Data plane basic assumption . . . . . . . . . . . . . . . . . 3
4. SFC Control Plane Overview . . . . . . . . . . . . . . . . . 4
4.1. Control plane PDP . . . . . . . . . . . . . . . . . . . . 5
4.2. F interface . . . . . . . . . . . . . . . . . . . . . . . 6
4.3. C1 interface . . . . . . . . . . . . . . . . . . . . . . 6
4.4. C2 interface . . . . . . . . . . . . . . . . . . . . . . 6
5. Signaling procedure . . . . . . . . . . . . . . . . . . . . . 7
5.1. Service Function Chain Structuring . . . . . . . . . . . 7
5.2. Service Function Path Determining . . . . . . . . . . . . 7
5.3. Service Topology Building . . . . . . . . . . . . . . . . 8
5.4. Service Function Chaining Path Setup and Policy Table
configuration . . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Service Function Chaining(SFC) refers to the delivery of added value
services by invoking, in a given order, a set of Service Functions
along the forwarding path towards a specific destination [I.D-quinn-
sfc-problem-statement]. Service functions involved in a given SFC
may include advanced Service Functions such as load-balancing,
firewalling, intrusion prevention. A given SFC domain may involve
several instances of the same Service Functions. Service Function
instances can be automatically added to or removed from a given SFC.
Li, et al. Expires January 22, 2015 [Page 2]
Internet-Draft SFC CP July 2014
Service functions can be co-located or embedded in distinct physical
nodes, or virtualized.
As described in [I.D-boucadair-sfc-framework], the dynamic
enforcement of a SF-derived, adequate forwarding policy for packets
entering a network that supports such advanced Service Functions has
become a key challenge for operators and service providers.
This document is based on [I.D-boucadair-sfc-framework] and discusses
how the Service Function Chains are structured and how Service
Function Chaining path is provisioned and setup.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119].
3. Data plane basic assumption
The control plane framework described in this document applies to SFC
architectures defined by [ID Jiang-SFC-ARCH], [ID Boucadair-SFC-
framework]and [ID Quinn-SFC-ARCH].
The SFC data plane characteristics considered as basic assumptions by
the SFC control framework are summarized below:
o Traffic that enters a SFC domain is firstly classified according
to the rules provided to the classifier node by the PDP, and then
forwarded into the SFC domain according to the various Service
Functions that need to be invoked, as per the corresponding SFC
instructions. SFC-specific forwarding information is used by
service function nodes to make traffic forwarding decisions,
according to the contents of the chain. That is, traffic is
forwarded to the SF Node that embeds the next SF function to
invoke. Classification in the SCLA is done according to a set of
classification rules that are provided by the PDP.
o The Service Node forwards packets according to the entries
maintained in the SFC Policy Table. A Service Node can be a L2/L3
network device that embeds SF functions that can be invoked for a
given chain. A Service node may embed one or more Service
Functions (Fig. 1).
o When a Service node needs to forward a packet to a node that
cannot process SFC-specific information as carried in the packet,
the packet is usually forwarded to a SFC proxy.
Li, et al. Expires January 22, 2015 [Page 3]
Internet-Draft SFC CP July 2014
4. SFC Control Plane Overview
For the purpose of defining the SFC control plane framework, the
control plane PDP is broken up into five distinct components
Policy
Maintains SFC-related policy provisioning information (chain
structures, classification rules) and possibly other information
(e.g., information that pertains to user data and services).
Meta Data
May include Subscriber profile, access network type, network load,
etc. Subscriber attributes may include access bandwidth (e.g.,
512K,1M,2M,4M), QoS level (e.g., Gold, Silver, Bronze), access
line/cell id, payment status, Radio Access Technology (RAT)
(GPRS,UMTS,HSPA,LTE), etc. Subscriber attributes may vary
frequently and the control plane PDP therefore needs to be
informed about such modification in a timely manner.
Service Template Profile
Include service function template and service chain template.
Path management
This component is used to map a service function chain to a
forwarding path, in case the said forwarding path is PDP-computed
and traffic engineered [I.D-wu-pce-traffic-steering-sfc].
Chain management
This is the component that helps the PDP dynamically structure a
SFC chain, based upon various inputs that include service function
information as collected through the management interface (e.g.,
the outcomes of a negotiation between a customer and a service
provider, as documented in RFC7297).
Li, et al. Expires January 22, 2015 [Page 4]
Internet-Draft SFC CP July 2014
+--------------------------------------+
| PDP |
| +-------+ +----------+ +----------+ |
| |Policy | | Service | |Meta Data | |
| +-------+ | template | | | |
| +---------++----------+ +----------+ |
| | Path | +-----------+ |
+-------+-|Management | Chain | |
| | +---------+ | Management| |
| +---+ +-----------+ +
| | | |
C1 C1 +------^--^--------------^--^----------+
| | | | C2 | | C2
| | F| F| |Service F| F| | Service
| | | | | Node1 | | | Node2
+----V---V--+ +-+--+--V-+ +--+--+-V-+
|SFC Ingress| | | | | | | | |
| Node |---->| |----->| | | |
(Classifier)|<----|SF1 SF2 |<---- | |
+-----------+ | | |SF3 SF4 |
+---------+ +---------+
Figure 1: SFC Control Plane Overview
There are three interfaces connected to the Control Plane PDP.
C1 Interface: the interface between the control plane PDP and the
Service Classifier (SCLA). Classification rules are installed on
the SCLA via this interface. In addition, this interface can be
used by the Path management component to trigger the dynamic
computation and selection of traffic-engineered paths that will be
used to forward traffic according to SFC information.
C2 Interface: the interface between the control plane PDP and the
Service node. SFC-based forwarding entries on service nodes are
provided by the PDP via this interface.
F Interface: This interface is used by service functions to
feedback service or application level information of a dataflow to
the control plane PDP.
4.1. Control plane PDP
The control plane PDP is in charge of service function chain creation
and maintenance, service chain path instantiation (in case the PDP is
involved in the dynamic SFC path computation and selection), mapping
Li, et al. Expires January 22, 2015 [Page 5]
Internet-Draft SFC CP July 2014
between SFC and service function path, SFC Policy Table creation and
configuration, including the sequence of SFs in a service function
chain, SF information, SFC paths and metadata.
The control plane PDP may be fed with service function chain
information from the Management application. A SFC service template
information may look like:
{{MBR>1Mbps, RAT='UMTS', protocol='HTTP', QOS='Gold'},goto'sfc1'}
The control plane PDP may combine the management plane-originated
information with subscriber attributes provided by the metadata
component. The PDP also creates classification rules and installs
them on the classifier nodes. The control plane PDP also assigns SFC
identification and installs SFC Policy Tables in the Service Nodes.
4.2. F interface
Service functions, e.g., deep packet inspection (DPI) or firewall may
need to output some processing results of packets to the control
system. This information can be used by the control plane PDP to
update the SFC classification rules and SFC forwarding entries.
The F Interface is used to collect such kind of feedback information
from the service functions or the SF nodes.
4.3. C1 interface
This interface is used to install SFC classification rules in Service
Classifier(SCLA) nodes. These rules are created by the SFC control
Plane PDP. These rules may be updated by information provided by the
Service Nodes (in case a change of the network topology has occurred,
for example).
SCLA binds incoming traffic to SFCs according to these classification
rules.
4.4. C2 interface
Service Nodes make traffic forwarding decisions according to the
entries maintained in their SFC Policy Table. Such Table is
populated by the control plane PDP through the C2 interface.
Each SF has a unique service function identifier to identify itself
in the SFC forwarding plane. The locator is typically referred to as
a network address. In case the SF instance is directly connected to
a Service node, the forwarding entry may also include the port
through which the SF instance can be reached.
Li, et al. Expires January 22, 2015 [Page 6]
Internet-Draft SFC CP July 2014
Some proxy function may also use the C2 interface to get the mapping
between a SF Identifier and a SF locator from the control plane PDP.
5. Signaling procedure
5.1. Service Function Chain Structuring
The chain management component of the Control Plane PDP is
responsible for the dynamic structuring of service function chains
(i.e., define an ordered list of service function identifiers) that
can be supported, as a function of the services that can be
delivered, among other information that may include subscriber-
specific information. For example, a service function chain can be
structured as:
service-chain 100 {
10 url-filter
20 web-cache
30 web-optimizer
40 firewall
}
In this service function chain, each Service Function needs to be
assigned with a unique SF identifier and can be located using SF
locators. A Service Function chain should be assigned a SF Map
Index. A service function identifier does not necessarily hint the
service offered by that SF; its purpose is to uniquely identify a SF
among those present in a SFC-enabled domain.
5.2. Service Function Path Determining
The path management component of the control plane PDP is responsible
for service function path determination. Service function path
determination is referred to determine an ordered list of locators of
each service function that belongs to a service function chain.
The service function path determining may be static or pre-determined
using specific SF instances, or dynamic - choosing the locators of
service explicit SF instances at the time of delivering traffic to
the SF.
When there are multiple instances of a given SF that belongs to a
given SFC, each of these instances is assigned a unique locator.
These multiple instances may actually be invoked within the context
of a single chain, or within the context of multiple chains depending
on how the said chains are structured. The latter case may lead to
multiple SFP paths. In some other cases, a Service function path can
pre-computed by path management component for traffic engineering
Li, et al. Expires January 22, 2015 [Page 7]
Internet-Draft SFC CP July 2014
purposes. Service function path doesn't need to be pre- determined.
The chain management component responsible for structuring the
service chains cannot decide in advance the actual path that will be
followed by packets.
When service function chain structuring is complete, the control
plane PDP will use the Path management component to determine the
locator of each specific SF instance in the chain and return a set of
SF locators associated with A service function chain.
In addition, the path management component also maintains the mapping
between service function chains and service function paths. The
control plane PDP can use the path management component to acquire
the service function path ID (i.e., service function map index).
5.3. Service Topology Building
When an SFC is instantiated into the network it is necessary to
select the locator of the specific instances of SFs that will be
used, and to construct the service overlay for that SFC using SF's
network locator. The Service overlay is built on top of the
underlying network. The resulting service overlay is meant to
facilitate SFC domain operation, as it may provide a better, up-to-
date, network-wise overview of the SF status and usage on a per SFC
basis.
A service specific overlay utilized by SFC then results in the
creation of the service topology. Service topology information
consists of network topology information collected from the
underlying network and SF-related information (such as Service
Function administration information and Service Function capability
information) that may be collected from the management interface.
Network topology information can be collected from the network by
using an IGP or BGP-LS [I.D-draft-idr-ls-distribution]. SF-related
information includes SF Identifier, SF Locator, Service Function
administration information (e.g., available memory, CPU utilization,
available storage capacity, etc.) or Service Function capability
information (e.g., supported ACL numbers, virtual context number).
But the creation of the service topology is not conditioned by the
creation of the network topology: what is required is the mapping
between SF-related information and existing network topology
information. Additional service functions or Service Function
instances, for redundancy or load distribution purposes, can be added
to or removed from the service topology as required.
Li, et al. Expires January 22, 2015 [Page 8]
Internet-Draft SFC CP July 2014
5.4. Service Function Chaining Path Setup and Policy
Table configuration
Once a SFC is structured, traffic classification rules are derived
and provided to the classifier nodes, along with the information
maintained in Policy Tables. The policy table is built based on SFC
policy and SFC service template information and metadata information
captured by using policy, service template and metadata components,
respectively when a Service function path is determined. The policy
table will be populated at each participating node involved in the
application of a service function chain and used by them to make
their forwarding decisions on a typical SF Hop-by-Hop basis.
6. Security Considerations
TBD
7. Acknowledgements
The author would like to thank LAC Chidung for his review and
comments that helped improve this document.
8. References
8.1. Normative References
[I.D-boucadair-sfc-framework]
Boucadair, M., "Service Function Chaining: Framework &
Architecture", ID draft-boucadair-sfc-framework-00,
October 2013.
[I.D-quinn-sfc-problem-statement]
Quinn, P., "Network Service Chaining Problem Statement",
ID draft-quinn-nsc-problem-statement-03, August 2013.
[I.D-wu-pce-traffic-steering-sfc]
Wu, Q., Dhody, D., Boucadair, M., Boucadair, C., and J.
Tantsura, "PCEP Extensions for traffic steering support in
Service Function Chaining", ID draft-wu-pce-traffic-
steering-sfc-02, Feburary 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
Li, et al. Expires January 22, 2015 [Page 9]
Internet-Draft SFC CP July 2014
8.2. Informative References
[RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based
Architecture", RFC 4655, August 2006.
Authors' Addresses
Hongyu Li
Huawei
Huawei Industrial Base,Bantian,Longgang
Shenzhen
China
Email: hongyu.li@huawei.com
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: bill.wu@huawei.com
Huang(Oliver) Huang
Huawei
Huawei Industrial Base,Bantian,Longgang
Shenzhen
China
Email: oliver.huang@huawei.com
Mohamed Boucadair
France Telecom
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Christian Jacquenet
France Telecom
Rennes 35000
France
Email: christian.jacquenet@orange.com
Li, et al. Expires January 22, 2015 [Page 10]
Internet-Draft SFC CP July 2014
Walter Haeffner
Vodafone D2 GmbH
Ferdinand-Braun-Platz 1
Duesseldorf 40549
DE
Email: walter.haeffner@vodafone.com
Li, et al. Expires January 22, 2015 [Page 11]