One document matched: draft-ww-sfc-control-plane-01.txt
Differences from draft-ww-sfc-control-plane-00.txt
Service Function Chaining H. Li
Internet-Draft Q. Wu
Intended status: Informational O. Huang
Expires: January 3, 2015 Huawei
M. Boucadair
C. Jacquenet
France Telecom
W. Haeffner
Vodafone
July 2, 2014
Service Function Chain control framework
draft-ww-sfc-control-plane-01
Abstract
This document describes a control framework for service function
chaining (SFC), which defines interfaces between SFC control system
and other SFC related entities e.g. service chain management
interface, user profile interfaces, feedback interface and interfaces
to dataplane. This document also describes necessary control
functions in the SFC control framework and discuss how a set of
available Service Functions are provisioned and how Service Function
Chaining path is 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 3, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires January 3, 2015 [Page 1]
Internet-Draft SFC CP July 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. Data plane basic assumption . . . . . . . . . . . . . . . . . 4
4. Service function chain control framework . . . . . . . . . . 4
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. SFC Control System . . . . . . . . . . . . . . . . . . . 6
4.3. F interface . . . . . . . . . . . . . . . . . . . . . . . 7
4.4. C1 interface . . . . . . . . . . . . . . . . . . . . . . 7
4.5. C2 interface . . . . . . . . . . . . . . . . . . . . . . 7
5. Signaling procedure . . . . . . . . . . . . . . . . . . . . . 7
5.1. Building overlay Topology . . . . . . . . . . . . . . . . 7
5.2. Service Function Map Selection . . . . . . . . . . . . . 8
5.3. Service Function Chaining (SFC) Policy decision . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Appendix A. . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Network operators use various mechanisms to steer and adapt user
traffic according their business needs. In general two complementary
building blocks support this task:
o Policing and shaping for upstream and downstream traffic in the
access network. The two related endpoints are on one end the user
equipment and on the other end a service creation node, e.g. a
BNG, a P-GW or a CMTS. A policy and charging control function
typically supports traffic steering within this closed
environment. Two types of metadata are typically in use for
traffic and service management within the access network. One set
includes the user and service profiles configured and residing in
a policy server or more general within some control plane systems.
Li, et al. Expires January 3, 2015 [Page 2]
Internet-Draft SFC CP July 2014
These data are static and describe basically the contracted SLAs
including charging rules. The other set of metadata may originate
from different equipment in the access network and describes e.g.
the momentary state of the network or more precisely, a network
segment.
o Service functions residing in a LAN segment between the service
creation node and the final internal or external service
platforms. Downstream and upstream user packets are forced by
some methods to pass an ordered sequence of service functions
a.k.a. Service Function Chain, on their way to the user terminal
or the addressed service platform. Downstream and upstream
traffic may pass different service chains. While policing in the
access network affects the transport properties, service functions
additionally may optimize the payload of user plane traffic or
provide some Value Added Services. Service Function Chains use
control plane or data plane metadata to properly control and steer
the data traffic. For more details see the SFC use case drafts
[mobility], [general], [DC],[long lived flows].
Service Function Chains (SFC) are essential for the business of a
network or a data center operator Since they enable operators to
provide services with flexible combinations of existing capabilities
in the network.
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 describes a control framework for service function
chaining (SFC), which defines interfaces between SFC control system
and other SFC related entities e.g. service chain management
interface, user profile interfaces, feedback interface and interfaces
to data plane. This document also describes necessary control
functions in the SFC control framework and discuss how a set of
available Service Functions are provisioned and how Service Function
Chaining path is setup.
2. Terminology
This document uses terminologies introduced in [SFC-PS] , [ID Jiang-
SFC-ARCH] and [ID Boucadair-SFC-framework]. Besides, following terms
are also used.
SFid
SF identifier which uniquely identifies an SF instance
Li, et al. Expires January 3, 2015 [Page 3]
Internet-Draft SFC CP July 2014
SFE
Service Forwarding Entity
3. Data plane basic assumption
The control framework described in this document applies to SFC
architectures defined by [ID Jiang-SFC-ARCH], [ID Boucadair-SFC-
framework]and [ID Quinn-SFC-ARCH].
SFC data plane characters in these drafts are summarized below, as
basic assumptions for SFC control framework.
o Data plane traffic is firstly classified by a service classifier
(SCLA), and encapsulated with a SFC header and an underlay network
header. The SFC Header MUST include SFC-specific forwarding
information used by SFEs to pass the data plane traffic to the
next service instance within the chain. Classification in the
SCLA is done by a set of control and/or user plane metadata.
o SFE forwards SFC packets according to its SFC forwarding entry. A
SFE typically is a virtualized or a L2/L3 forwarding device able
to interpret the SFC header. A SFE may serve one or more Service
Functions (Fig. 1).
o When SFE decides to send a SFC packet to a non-SFC aware SF
instance, it sends the packet to a SFC proxy.
4. Service function chain control framework
Li, et al. Expires January 3, 2015 [Page 4]
Internet-Draft SFC CP July 2014
+-----------+
|Management | abstract definition of the
| System | SFC
+-----------+
|
|M
+-----+ +------------+------------+
| AAA/+-----------+ |
| PCRF| A | | F
+-----+ | SFC control system +------------+
| | |
| +------+ |
+-+-----------+-----------+ C2| |
|C1 |F |C2 |F \F | |
| +---+ | +---+ +---+ | +--++
| |SF | | |SF | | SF| | |SF |
+-----+ +-+-+ | +-+-+ +-+-+ | +--++
| | | | | | |
| --+ | +-+ +-+ | +--+
+---+--+ ++--+--++ ++--+--++
------>|SCLA +--------->| SFE +--------->+ SFE |---->
+------+ +-------+ +-------+
Figure 1. SFC control framework
4.1. Overview
As illustrated in Figure 1, SFC control framework is composed of a
SFC control system and related interfaces. SFC control system is a
central control/management plane entity and includes functions
managing and controlling SFCs. SFC control system also contains
interfaces that can be used to interact with AAA/PCRF server,
Management System, SFE, SF respectively. Service functions can be
co-located with SFE or physically separated from SFEs with each
attached by one or more Service Functions.
The framework supports demands on SFC abstractions and automatic
generation of the underlay connectivity.
As decision center of all the service function chains in domain, SFC
control system can receive subscriber attributes from AAA/policy
server or Policy and Charging Rule Function (PCRF), it also can
receive service function chain configuration from the Management
System and installs corresponding classification rules and forwarding
tables on SFC data plane. SFC control system also collects SFs
topology information and feedbacks from SCLA, SFE, and SF.
There are several interfaces connected to the SFC control system.
Li, et al. Expires January 3, 2015 [Page 5]
Internet-Draft SFC CP July 2014
M Interface: the Management System uses this interface to define
service function chains and related policies regarding user data
and service information.
A Interface: the interface between the SFC control system and AAA,
policy server or PCRF, through which subscriber and network
metadata are injected. Metadata include subscriber and service
profile, access network type, network loads etc.
C1 Interface: the interface between the SFC control system and the
Service Classifier (SCLA). Classification rules are configured on
SCLA via this interface.
C2 Interface: the interface between the SFC control system and the
Service Forwarding Entity (SFE). Forwarding entries on SFEs are
configured via this interface.
F Interface: This interface is used by service functions to
feedback service or application level information of a dataflow to
the SFC control system.
4.2. SFC Control System
The SFC control system is in charge of maintaining service chain
topologies information, creating and configuring service chain
forwarding entries, including the sequence of SFs in a service chain,
SF information, SFC paths and metadata.
The SFC control system receives service function chain vectors from
the Management System. A SFC vector may look like:
{{MBR>1Mbps, RAT='UMTS', protocol='HTTP', QOS='Gold'},goto'sfc1'}
The SFC control system combines these policies with subscriber
attributes inputted from the policy server or PCRF, creates
classification rules and configures them on SCLA. The SFC control
system also assigns SFC identification and configures forwarding
entries on SFEs.
Both fixed broadband and mobile broadband networks use policy server
or PCRF to maintain subscriber attributes including access bandwidth
(512K,1M,2M,4M), QoS level (Gold, Silver, Bronze), access line/cell
id, payment status, Radio Access Technology (RAT)
(GPRS,UMTS,HSPA,LTE),etc. Subscriber attributes are volatile and
need to be updated to the SFC control system instantly through A
interface.
Li, et al. Expires January 3, 2015 [Page 6]
Internet-Draft SFC CP July 2014
4.3. 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. These information can be used by the control system to
update the SFC classification rules and SFC forwarding entries.
The F Interface is a logical interface used to collect such kind of
feed information from data plane.
4.4. C1 interface
This interface is used to install SFC classification rules to Service
Classifier(SCLA). These rules are created by the SFC control system
by calculating inputs of subscriber attributes from A interface,
service chain policies from M interface and possibly feedback from F
interface.
SCLA directs traffic to SFCs according to these classification rules.
4.5. C2 interface
SFE takes the responsibility of the service function chain
forwarding. SFC forwarding entries in the SFE are configured by the
control system through C2 interface.
Each SF has a unique service function identifier to identify itself
in SFC forwarding plane, which is correlated to its network address
on the SFC control system. In case that the SF instance is directly
connected to a SFE node, the forwarding entry may include attaching
port of the SF instance.
Some proxy may also use C2 interface to get the SFid/Network address
mapping from the control system.
5. Signaling procedure
5.1. Building overlay Topology
Network topology information can be collected from network by using
IGP or BGP-LS [I.D-draft-idr-ls-distribution]. The Service overlay
is built on top of underlying network and creates a forwarding path
between SFE Nodes or connected graph for these SFE Nodes. Not all
SFE Nodes need to be directly connected. A service specific overlay
utilized by SFC creates the overlay topology. Overlay topology is
created based on network topology information collected from
underlying network and SF related information collected from
management interface. Overlay topology information includes SF
Li, et al. Expires January 3, 2015 [Page 7]
Internet-Draft SFC CP July 2014
Identifier, SF Locator, Service Function administration information
(e.g., available memory,CPU utilization,Available storage)or Service
Function capability information(e.g.,supported ACLnumbers, virtual
context number) A topology management function can located in SFC
control system or physically separated from the entity that supports
the SFC control system.
Adding new Service Functions to Overlay Node in the overlay topology
is easily accomplished, and no underlying network changes are
required. Furthermore, additional service Functions or Service
Function instances, for redundancy or load distribution purpose, can
be added or removed to the service topology as required.
5.2. Service Function Map Selection
When overlay topology is created by a service-specific overlay
utilized by Service Function Chaining, each Service Function type is
assigned with a unique SF identifier and can be located using SF
locator.
To select appropriate service function for service function chain, a
service request may be send to topology management function. The
Service request carries various constraint information or resource
requirements (e.g., SF location constraint, SF order constraint, SF
capability information). The topology management function returns
computed path information to SFC control system. SFC control system
will compose the Service Function Map based on the returned computed
path. If there are multiple Service Functions or Service Function
Instances can satisfy service requirements, the PDP will select
appropriate Service Function based on Service Functions capability
info or local policy to build Service Function Map.
5.3. Service Function Chaining (SFC) Policy decision
The SFC control system gets SFC policy and SFC service topology
definition from M interface (see 4.2.). The SFC control system may
retrieve computed path information from topology management function
and compose them into service Function Map. In addition, the SFC
control system will interact with AAA/PCRF server to correlate
subscriber profile with SFC and make policy decision via F interface.
6. Security Considerations
TBD
Li, et al. Expires January 3, 2015 [Page 8]
Internet-Draft SFC CP July 2014
7. Acknowledgements
The author would like to thank LAC Chidung for his review and
comments that help improvement to this document.
8. References
8.1. Normative References
[I.D-quinn-sfc-problem-statement]
Quinn, P., "Network Service Chaining Problem Statement",
ID draft-quinn-nsc-problem-statement-03, August 2013.
8.2. Informative References
[I.D-boucadair-sfc-framework]
Boucadair, M., "Service Function Chaining: Framework &
Architecture", ID draft-boucadair-sfc-framework-00,
October 2013.
[I.D-jiang-sfc-arch]
Jiang , Y. and H. Li, "An Architecture of Service Function
Chaining", ID draft-jiang-sfc-arch-01, February 2014.
[I.D-quinn-sfc-arch]
Quinn, P., Ed. and J. Halpern, Ed., "Service Function
Chaining (SFC) Architecture", ID draft-quinn-sfc-arch-05,
May 2014.
[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.
Appendix A. Appendix A.
Yang Shi
Huawei
Beijing, 100085
China
Email: shiyang1@huawei.com
XianGuo Zhang
Huawei
Beijing, 100085
China
Email: zhangxianguo09@huawei.com
Li, et al. Expires January 3, 2015 [Page 9]
Internet-Draft SFC CP July 2014
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
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 3, 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 3, 2015 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 02:45:37 |