Skip to main content

Service Function Chaining
charter-ietf-sfc-00-05

The information below is for an older proposed charter
Document Proposed charter Service Function Chaining WG (sfc) Snapshot
Title Service Function Chaining
Last updated 2013-11-26
State Draft Charter
WG State BOF
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

charter-ietf-sfc-00-05

Service delivery is undergoing significant change with the introduction
of virtualization, network overlays, and orchestration. Service delivery
is currently both a technical and an organizational challenge that
involves significant modification to the network configuration thereby
impacting the speed at which services can be deployed and increasing
operational costs. Services are typically implemented by the ordered
combination of a number of service functions that are deployed at
different points within a network. Today, a common deployment model has
service functions physically inserted on the data-forwarding path
between communicating peers. Going forward, however, there is a desire
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 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 and the network nodes on which
they are provided, thereby forming 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, 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:

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

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

  3. 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 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 path realized at the
    network layer or at any other layer, and the same encapsulation will
    apply for the construction of service function paths regardless of
    the actual service.

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

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