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.

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. Terminology
• 3. Data plane basic assumption
• 4. Service function chain control framework
• 4.1. Overview
• 4.2. SFC Control System
• 4.3. F interface
• 4.4. C1 interface
• 4.5. C2 interface
• 5. Signaling procedure
• 5.1. Building overlay Topology
• 5.2. Service Function Map Selection
• 5.3. Service Function Chaining (SFC) Policy decision
• 6. Security Considerations
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Appendix A. Appendix A.
• Authors' Addresses

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:

• 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. 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.
• 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

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.

• 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.
• 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).
• 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

                          +-----------+
                          |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.

• 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.

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 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

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

8.2. Informative References

Appendix A. Appendix A.

   Yang Shi
   Huawei
   Beijing,   100085
   China
   Email: shiyang1@huawei.com

   XianGuo Zhang
   Huawei
   Beijing,   100085
   China
   Email: zhangxianguo09@huawei.com

Authors' Addresses