+----------------------------------------------+
               |                                              |
               |       SFC  Control & Management Planes       |
       +-------|                                              |
       |       |                                              |
       C1      +------^-----------^-------------^-------------+
+---------------------|C3---------|-------------|-------------+
|      |            +----+        |             |             |
|      |            | SF |        |C2           |C2           |
|      |            +----+        |             |             |
| +----V--- --+       |           |             |             |
| |   SFC     |     +----+      +-|--+        +----+          |
| |Classifier |---->|SFF |----->|SFF |------->|SFF |          |
| |   Node    |<----|    |<-----|    |<-------|    |          |
| +-----------+     +----+      +----+        +----+          |
|                     |           |              |            |
|                     |C2      -------           |            |
|                     |       |       |     +-----------+ C4  |
|                     V     +----+ +----+   | SFC Proxy |-->  |
|                           | SF | |SF  |   +-----------+     |
|                           +----+ +----+                     |
|                             |C3    |C3                      |
|  SFC Data Plane Components  V      V                        |
+-------------------------------------------------------------+

Figure 1: SFC Control Plane: Overview

3.2. Centralized vs. Distributed

The SFC control plane can be (logically) centralized, distributed or a combination thereof. Whether one or multiple SFC Control Elements are enabled is deployment-specific. Nevertheless, the following comments can be made:

SFC management (including SFC monitoring and supervision):

is likely to be centralized.

SFC Mapping Rules:

i.e., service instructions to bind a flow to a service function chain are likely to be managed by a central SFC Control Element, but the resulting policies can be shared among several Control Elements. Note, these policies can be complemented with local information (e.g., an IPv4 address/IPv6 prefix assigned to a customer) because such information may not be available to the central entity but known only during network attachment phase.

Path computation:

can be either distributed or centralized. Distributed path computation means that the selection of the exact sequence of SF functions that a packet needs to invoke (along with instances and/or SFF locator information) is a result of a distributed path selection algorithm executed by involved nodes. For some traffic engineering proposes, the SFP may be constrained by the control plane; as such, some SFPs can be fully specified (i.e., list all the SFF/SFs that need to be solicited) or partially specified (e.g., exclude some nodes, explicitly select which instance of a given SF needs to be invoked, etc.).

SFC Resiliency (including restoration)

refers to mechanisms to ensure high available service function chains. It includes means to detect node/link/path failures. Both centralized and distributed mechanism to ensure SFC resiliency can be envisaged.

Implementing a (logically) centralized path computation engine requires information to be dynamically communicated to the central SFC Control Element, such as the list of available SF instances, SFF locators, load status, SFP availability, etc.

3.3. Interface Reference Points

The following sub-sections describe the interfaces between the SFC Control & Management Planes, as well as various SFC data plane elements

3.3.1. C1: Interface between SFC Control Plane & SFC Classifier

As a reminder, a Classifier is a function that is responsible for classifying traffic based on (pre-defined) rules.

This interface is used to install SFC classification rules in Classifiers. Once classification rules are populated, SFC Classifiers are responsible for binding incoming traffic to service function chains according to these classification rules. Note, the SFC control plane must not make any assumption on how the traffic is to be bound to a given SFC. In other words, classification rules are deployment-specific. For instance, classification can rely on a subset of the information carried in a received packet such as 5-tuple classification, be subscriber-aware, be driven by traffic engineering considerations, or any combination thereof.

The SFC control plane should be responsible for removing invalid (and stale) mappings from the classification tables maintained by the classifiers. Also, local sanity checks mechanisms may be supported locally by the Classifiers, but those are out of scope.

Classification rules may be updated, deleted or disabled by the control plane. Criteria that would trigger those operations are deployment-specific.

Given that service function chaining solutions may be applied to very large sets of traffic, any control solution should take scaling issues into consideration as part of the design.

Below are listed some functional objectives for this interface:

• Rationalize the management of classification rules.
• Maintain a global view of instantiated rules in all Classifiers in an SFC-enabled domain.
• Check the consistency of instantiated classification rules within the same Classifier or among multiple Classifier.
• Assess the impact of removing or modifying a classification entry on packets entering an SFC-enabled domain.
• Aggregate classification rules for the sake of performance optimization (mainly reduce lookup delays).
• Adjust classification rules when rules are based on volatile identifiers (e.g., an IPv4 address, IPv6 prefix).
• Allow to rapidly restore SFC states during failure events that occurred at a Classifier (or a Control Element).

The control plane must instruct the Classifier whether it can trust an existing SFC marking of an incoming packet or whether it must be ignored.

For bidirectional packet processing purposes (e.g., full or partial path symmetry), the control plane invokes this interface to configure the appropriate classification entries.

A Classifier can send unsolicited messages through this interface to notify the SFC Control & Management Planes about specific events.

When re-classification is allowed in an SFC-enabled domain, this interface can be used to control Classifiers co-resident with SFC-aware SFs, SFC Proxies, or SFFs to manage re-classification rules .

SFC Classification policy entry should be bound to one single service function chain (or one single SFP); when an incoming packet matches more than one classification entry, tie-breaking criteria should be specified (e.g., priority). Such tie-breaking criteria should be instructed by the control plane.

The identification of instantiated SFCs/SFPs is local to each administrative domain; it is policy-based and deployment-specific.

3.3.2. C2: Interface between SFC Control Plane & SFF

SFFs make traffic forwarding decisions according to the entries maintained in their SFC forwarding policy table. Such table is populated by the SFC control plane through the C2 interface.

This interface is also used to instruct a SFF about the SFC-aware SFs that it can service. Local means may be enabled between the SFC- aware SFs and SFFs to allow for the dynamic attachment of SFs to a SFF but those means are unspecified in this document.

The C2 interface is also used for collecting states of attributes (e.g., availability, workload, latency), for example, to dynamically adjust Service Function Paths.

3.3.3. C3: Interface between SFC Control Plane & SFC-aware SFs

The SFC control plane uses this interface to interact with SFC-aware SFs.

SFs may need to output some processing results of packets to the SFC control plane. This information can be used by the SFC control plane to update the SFC classification rules and the SFC forwarding policy table entries.

This Interface is used to collect such kind of feedback information from SFs. For example, the following information can be exchanged between a SF and the SFC control plane:

• SF execution status: Some SFs may need to send information to the control plane to fine tune SFPs. For example, a threat-detecting SF can periodically send the threat characteristics via this interface, such as high probability of threat with packet size equal to 47. The control plane can then add "packet-size=47" matching criteria to SFF to steer traffic with packet size equal to 47 to a scrubbing center.
• SF Liveliness update: When SFs are under stress that yielded the crossing of some performance thresholds, the SFC control plane needs to be notified to adjust SFPs accordingly (especially when the centralized path computation mode is enabled).

The SFC control needs the above status information for various tasks it undertakes, but this information may be acquired directly from SFs or indirectly from other management and control systems in the operational environment.

This interface is also used to instruct an SFC-aware SF about any context information it needs to supply in the context of a given SFC.

Also, this interface informs the SFC-aware SF about the semantics of a context information, which would otherwise have opaque meaning. Several attributes may be associated with a context information such as (but not limited to) the "scope" (e.g., per-packet, per-flow or per host), whether it is "mandatory" or "optional" to process flows bound to a given chain, etc. Note that a context may be mandatory for "chain 1", but optional for "chain 2".

The control plane may indicate, for a given service function chain, an order for consuming a set of contexts supplied in a packet.

A SFC-aware SF can also be instructed about the behavior is should adopt after consuming a context information that was supplied in the SFC header. For example, the context can be maintained or stripped. The SFC-aware SF can be instructed to inject a new context header into the SFC header.

Multiple SFs may be located within the same physical node, and no SFF is enabled in that same node, means to unambiguously forward the traffic to the appropriate SF must be supported.

An SF can be instructed to strip the SFC information for the chains it terminates.

3.3.4. C4: Interface between SFC Control Plane & SFC Proxy

The SFC control plane uses this interface to interact with an SFC Proxy.

The SFC proxy can be instructed about authorized SFC-unware SFs it can service. A SFC Proxy can be instructed about the behavior it should adopt to process the context information that was supplied in the SFC header on behalf of a SFC-unware SF, e.g., the context can be maintained or stripped.

The SFC proxy is also instructed about the semantics of a context information, which would otherwise have opaque meaning. Several attributes may be associated with a context information such as (but not limited to) the "scope" (e.g., per-packet, per-flow or per host), whether it is "mandatory" or "optional" to process flows bound to a given chain, etc.

The SFC Proxy can also be instructed to add SF some new context information into the SFC header on behalf of a SFC-unaware SF.

The C4 interface is also used for collecting attribute states (e.g., availability, workload, latency), for example, to dynamically adjust Service Function Paths.

4. Additional Considerations

4.1. Discovery of the SFC Control Element

SFC data plane functional elements need to be provisioned with the locators of the Control Elements. This can be achieved using a variety if mechanisms such as static configuration or the activation of a service discovery mechanism. The exact specification of how this provisioning is achieved is out of scope.

4.2. SF Symmetry

Some SFs require both directions of a flow to traverse. Some service function chains require full symmetry. If a SF (e.g., stateful firewall or NAT) needs both direction of a flow, it is the SF instantiation that needs both direction of a flow to traverse, not the abstract SF (which can have many instantiations spread across the network).

4.3. Pre-deploying SFCs

Enabling service function chains should preserve some deployment practices adopted by Operators. Particularly, installing a service function chain (and its associated SFPs) should allow for pre-deployment testing and validation purposes (that is a restricted and controlled usage of such service function chain (and associated SFPs)).

4.4. Withraw a Service Function (SF)

During the lifetime of a SFC, a given SF can be decommissioned. To accommodate such context and any other case where a SF is to be withdrawn, the control plane should instruct the SFC data plane functional element about the behavior to adopt. Particularly:

1. a first approach would be to update the service function chains (and associated SFPs) where that SF is present by removing any reference to that SF. Doing so avoids to induce service failures for end users.
2. a second approach would be to delete/deactivate any service function chain (and its associated SFPs) that involves that SF but install new service function chains.

4.5. SFC/SFP Operations

Various actions can be executed on a service function chain (and associated SFPs) that is structured by the SFC Control & Management planes. Indeed, a service function chain (and associated SFPs) can be enabled, disabled, its structure modified by adding a new SF hop or remove an SF from the sequence of SFs to be invoked, its classification rules modified, etc.

A modification of a service function chain can trigger control messages with the appropriate SFC-aware nodes accordingly.

4.6. Unsolicited (Notification) Messages

Involved SFC data plane functional element must be instructed to send unsolicited notifications when loops are detected, a problem in the structure of a service function chain is encountered, a long unavailable forwarding path time is observed, etc.

Specific criteria to send unsolicited notifications to a Control Element should be fine tuned by the control plane using the interface defined in Section 3.3.

4.7. SF Liveness Detection

The control plane must allow to detect the liveliness of SFs of an SFC-enabled domain. In particular, it must allow to dynamically detect that a SF instance is out of service and notify the relevant Control Element elements accordingly. The liveness information may be acquired directly from SFs or indirectly from other management and control systems in the operational environment.

Liveness status records for all SF instances, and service function chains (including the SFPs bound to a given chain) are maintained by the SFC Control & Management.

The Classifier may be notified by the control plane or be part of the liveness detection procedure.

The ability of a SFC Control Element to check the liveness of each SF present in service function chain has several advantages, including:

• Enhanced status reporting by the control & management planes (i.e., an operational status for any given service chain derived from liveness state of its SFs).
• Ability to support various resiliency policies (i.e., bypass a node embedding an SF, use alternate node, use alternate chain, drop traffic, etc.) .
• Ability to support load balancing capabilities to solicit multiple SF instances that provide equivalent functions.

Because a node embedding a SF can be responsive from a reachability standpoint (e.g., IP level) while the function its provides may be broken (e.g., a NAT module may be down), additional means to assess whether an SF is up and running are required. These means may be service-specific.

4.8. Monitoring & Counters

SFC-specific counters and statistics must be provided using of the interfaces defined in Section 3.3. These data include (but not limited to):

• Number of flows ever and currently assigned to a given service function chain and a given SFP.
• Number of flows, packets, bytes dropped due to policy.
• Number of packets and bytes in/out per service function chain.
• Number of flows, packets, bytes dropped due to unknown service function chain (this is valid in particular for a SF node).

4.9. SFC/SFP Diagnosis

• [[Note: This section is expected to be removed once the working group adopts a document on OAM.]]

The Control & Management planes should allow for the following:

• Assess the status of the serviceability of a SF (i.e., the SF provides the service(s) it is configured for). Obviously, this assessment must not rely only on IP reachability to decide whether a SF is up and running.
• Diagnose the availability of a SFC (including the availability of a particular SFP bound to a given SFC).
• Retrieve the set of service function chains that are enabled within a domain.
• Assess whether an SFC-enabled domain is appropriately configured (including, check the configured chains are matching what should be configured in that domain, and ensure coherent classification rules are installed in and enforced by all the Classifiers of the SFC-enabled domain).
• Correlate classification policies with observed forwarding actions (including, assess the output of the classification rule applied on a packet presented to a Classifier of an SFC-enabled domain).
• Support the correlation between a service function chain and the actual forwarding path followed by a packet matching that service function chain.
• Notify the SFC Control Element whenever some (critical) events occur (for example, a malfunctioning SF instance).
• Re-use SF built-in diagnostic procedures specific to each SF.

The SFC control plane must be able to invoke SFC OAM mechanisms, and to determine the results of OAM operations.

4.10. Considerations Specific to the Centralized Path Computation Model

This section focuses on issues that are specific to the centralized deployment model (Section 3.2).

4.10.1. Service Function Path Adjustment

A SFP is determined by composing SF instances and overlay links among SFFs. Thus, the status of a SFP depends on the states or attributes (e.g., availability, topological location, latency, workload, etc.) of its components. For example, failure of a single SF instance results in failure of the whole SFP. Since these states or attributes of SFP components may vary in time, their changes should monitored and SFPs should be dynamically adjusted.

Examples of use cases for SFP adjustment are listed below:

SFP fail-over:

re-construct a SFP with replacing the failed SF instance with another instance of the same SF.

SFP with better latency experience:

re-construct a SFP with a low path stretch considering the changes in topological locations of SF instances and the latency induced by the (overlay) connectivity among SFFs.

Traffic engineered SFC:

re-construct SFPs to localize the traffic in the network considering various TE goals such as bypass a node, bypass a link, etc. These techniques may be used for planned maintenance operations on a SFC-enabled domain.

SF/SFC Load balancing:

re-construct SFPs to distribute the workload among various SF instances.

For more details about the use cases, refer to [I-D.lee-nfvrg-resource-management-service-chain].

The procedures for SFP adjustment may be handled by the SFC control plane as follows:

• Collect and monitor states and attributes of SF instances and overlay links via the C2 interface (Section 3.3.2) and the C3 interface (Section 3.3.3).
• Evaluate SF instances and overlay links based on the monitoring results.
• Select SF instances to re-determine a SFP according to the evaluation results.
• Replace target SF instances (e.g., in a failure or overladed) with newly selected ones.
• Enforce the updated SFP for upcoming SFC traversal to SFFs via the C1 interface (Section 3.3.1) or the C2 interface (Section 3.3.2).

4.10.2. Head End Initiated SFP Establishment

In some scenarios where a SFC Control Element is not connected to all SFFs in a SFC-enabled domain, the SFC control plane can send the explicit SFF-SF-sequence or SF-sequence to the SFC head-end, e.g., the SFC Classifier via the C1 interface (Section 3.3.1). SFC head-end can use a signaling protocol to establish the SFF-SF-sequence based on the SF-sequence.

4.10.3. (Regional) Restoration of Service Functions

There are situations that it might not be feasible for the Classifier to be notified of the changes of SFF-sequence or SFF-SF-Sequence for a given SFP because of the time taken for the notification and the limited capability of the Classifiers.

If a SF has a large number of instantiations, it scales better if the Classifier doesn't need to be notified with status of visible instantiations of SFs on a SFP.

It might not be always feasible for the Classifier to be aware of the exact SF instances selected for a given SFP due to too many instances for each SF, notifications not being promptly sent to the Classifier, or other reasons. This is about multiple instances of the same SF attached to one SFF node; those instances can be handled by the SFF via local load balancing schemes.

Regional restoration can take the similar approach as the global restoration: choosing a regional ingress node that can take over the responsibility of installing the new steering policies to the involved SFFs or network nodes. Typically, the regional ingress node should be:

• on the data path of the flow of the given SFC;
• in front of the relevant SFFs or network nodes that are impacted by the change of the SFP;
• capable of encoding the detailed SFP to the Service Chain Header of data packets of the identified flow; and
• capable of removing the detailed SFP encoding in data packets after all the impacted SFFs and network nodes completed the policy installation.

5. Security Considerations

5.1. Secure Communications

The SFC Control Elements and the participating SFC data plane elements must mutually authenticate. SFC data plane elements must ignore instructions received from unauthenticated SFC Control Elements. The credentials details used during authentication can be used by the SFC control plane to decide whether specific authorization may be granted to a Service Function with regards to some specific operations (e.g., authorize a given SF to access specific context information).

In case multiple SFC data plane elements are embedded in the same node, the authentication mechanism may be executed as a whole; not for each instance.

A SFC data plane element must be able to send authenticated unsolicited notifications to a SFC Control Element.

The communication between a Control Element and SFC data plane elements must provide integrity and replay protection.

An SFC Control Element may instruct a Service Function to include specific security token(s) that may be used to decrypt traffic upstream. The security token may be supplied by the SFC control plane or by an authorized Service Function (e.g., TLS proxy). The exact details on how authorization is granted to a specific SF, including via a control plane interface, should be specified.

A Service Function must by default discard any action from a SFC Control Element that requires specific right privileges (e.g., access to a legal intercept log, mirror the traffic, etc.).

5.2. Pervasive Monitoring

The authentication mechanism should be immune to pervasive monitoring [RFC7258]. An attacker can intercept traffic by installing classification rules that would lead to redirect all or part of the traffic to an illegitimate network node. Means to protect against attacks that would lead to install, remove, or modify classification rules must be supported.

5.3. Privacy

The SFC control plane must be able to control the information that is leaked outside an SFC-enabled domain. Particularly, the SFC control plane must support means to preserve privacy [RFC6973]. Context headers may indeed reveal privacy information (e.g., IMSI, user name, user profile, location, etc.). Those headers must not be exposed outside the operator's domain. Also, means to protect context headers from eavesdroppers should be enforced.

5.4. Denial-of-Service (DoS)

In order to protect against denial of service that would be caused by a misbehaving trusted SFC Control Element, SFC data plane elements should rate limit the messages received from an SFC Control Element.

5.5. Illegitimate Discovery of SFs and SFC Control Elements

Means to defend against soliciting illegitimate SFs/SFFs that do not belong to the SFC-enabled domain must be enabled. Such means must be defined in service function discovery and SFC Control Element discovery specification documents.

6. IANA Considerations

This document does not require any IANA actions.

7. Acknowledgements

This document is the result of merging with [I-D.lee-sfc-dynamic-instantiation].

The authors would like to thank Shibi Huang for providing input and LAC Chidung for his review and comments that helped improve this document.

The text about the semantic of a context information is provided by Dave Dolson.

8. References

8.1. Normative References

8.2. Informative References

Appendix A. RSP-related Considerations

This section records some contributions proposed by L. Dunbar and A. Malis, but have not been discussed yet among authors.

A.1. Encoding the Exact SFF-SF-sequence in Data Packets

Encoding the exact RSP in every packet has the benefit and the issues associated with source routing. This approach may not be optimal when the SFP doesn't change very frequently, as in minutes or hours.

There are contexts that it might not be feasible for the head end Classifier to be notified of the changes of SFF-sequence or SFF-SF-Sequence for a given SFP because of the time taken for the notification and the limited capability of the Classifier nodes.

A.2. Fully Controlled SFF-SF-Sequence for a SFP

This section describes the information that can be exchanged over C2 interface (Section 3.3.2) when the SFC Control Element explicitly passes the steering policies to all SFFs for the SFF-SF-Sequence of a given SFC. In this model, each SFF doesn't need to signal other SFFs for the SFP.

Suppose the SFC ID for this SFP is “yellow”, an example of policy to “sff-a” is depicted in Figure 2 (for illustration proposes)

           Matching                     |       Action
----------------------------------------+-------------------------
SFC ID = "yellow" & ingress = sffx-port | next-hop: "sf2" & VID
SFC ID = "yellow" & ingress = sf2-port  | next-hop: "sf3" & VID
SFC ID = "yellow" & ingress = sf3-port  | next-hop: sff-b