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

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

service-chain 100 {
          10 url-filter
          20 web-cache
          30 web-optimizer
          40 firewall
}

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:

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

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.

8.2. Informative References

[RFC4655]

Farrel, A., "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.

Authors' Addresses