Service Function Chaining
charter-ietf-sfc-00-09
Document | Proposed charter | Service Function Chaining WG (sfc) Snapshot | |
---|---|---|---|
Title | Service Function Chaining | ||
Last updated | 2013-12-06 | ||
State | Start Chartering/Rechartering (Internal Steering Group/IAB Review) | ||
WG | State | Proposed | |
IESG | Responsible AD | Andrew Alston | |
Charter edit AD | Adrian Farrel | ||
Send notices to | jguichar@cisco.com, narten@us.ibm.com, adrian@olddog.co.uk, stbryant@cisco.com |
Network operators frequently utilize service functions such as firewall
filtering, load-balancing and transactional proxies (for example spam
filters) in the delivery of services to end users. Delivery of these
types of services is undergoing significant change with the introduction
of virtualization, network overlays, and orchestration.
Deploying service functions to support service delivery is currently both
a technical and an organizational challenge that involves significant
modification to the network configuration, impacting the speed at which
services can be deployed and increasing operational costs. Such
services are typically implemented by the ordered combination of a
number of service functions that are deployed at different points within
a network.
Today, common deployment models have service functions inserted on
the data-forwarding path between communicating peers. Going forward,
however, there is a need to move to a different model, where service
functions, whether physical or virtualized, are not required to reside on
the direct data path and traffic is instead steered through required service
functions, wherever they are deployed.
For a given service, the abstracted view of the required service
functions and the order in which they are to be applied is called a
Service Function Chain (SFC). An SFC is instantiated through selection
of specific service function instances on specific network nodes to form
a service graph: this is called a Service Function Path (SFP). The
service functions may be applied at any layer within the network
protocol stack (network layer, transport layer, application layer, etc.).
The SFC working group will document a new approach to service delivery
and operation. It will produce an architecture for service function
chaining that includes the necessary protocols or protocol extensions to
convey the service path and service path information to nodes that are
involved in the implementation of service functions and service function
chains, as well as mechanisms for steering traffic through service
functions. The working group will examine what information needs to be
gathered from the network and service functions in support of service
function chaining and how that information may be made available to the
components of the service function chaining architecture. The SFC WG
will closely consider the security implications when documenting these
deliverables.
Specifically, the SFC WG is chartered to deliver the following:
-
Problem Statement: This document will provide a summary of the
problem space to be addressed by the SFC working group including
example high-level use cases. Additionally, the working group will
normalize nomenclature and definitions for service function chaining. -
Architecture: This document will provide a description of the SFC
architectural building blocks and their relationships including
interconnection, placement of SFC specific capabilities, management,
diagnostics, design analysis, and security models, as well as
requirements on the protocol mechanisms. The initial scope is
restricted to a single administrative domain, keeping in mind that
architectural decisions made for the intra-domain case may have
implications for the inter-domain case. -
Generic SFC Encapsulation: This document will describe a single
service-level data plane encapsulation format for conveying the
service function chain and the service function path, and for
communicating context information between nodes that implement
service functions and service function chains. It is intended that
the encapsulation format be agnostic to the layer at which it is
applied and the service that is being constructed. That is, the same
encapsulation may be used on a service function chain applied at
the network layer or at any other layer, and the same encapsulation
format will apply for the construction of service function paths
regardless of the actual service. The working group will consider
using an existing encapsulation (with extensions as appropriate) if
a suitable candidate is found. -
Control Plane Mechanisms: A document will be developed to describe
requirements for conveying information between control or management
elements and SFC implementation points. All protocol extension work
resulting from these requirements should be carried out in the
working group responsible for the protocol being modified in
coordination with this working group, but may be done in this working
group under a revised charter after agreement with all the relevant
WG chairs and responsible ADs. -
Manageability: Work on the management and configuration of SFC
components related to the support of service function chaining will
certainly be needed, but first needs to be better understood and
scoped.