< draft-ietf-sfc-architecture-01.txt   draft-ietf-sfc-architecture-02.txt >
Network Working Group J. Halpern, Ed. Network Working Group J. Halpern, Ed.
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track C. Pignataro, Ed. Intended status: Standards Track C. Pignataro, Ed.
Expires: March 12, 2015 Cisco Expires: March 24, 2015 Cisco
September 8, 2014 September 20, 2014
Service Function Chaining (SFC) Architecture Service Function Chaining (SFC) Architecture
draft-ietf-sfc-architecture-01 draft-ietf-sfc-architecture-02
Abstract Abstract
This document describes an architecture for the specification, This document describes an architecture for the specification,
creation, and ongoing maintenance of Service Function Chains (SFC) in creation, and ongoing maintenance of Service Function Chains (SFC) in
a network. It includes architectural concepts, principles, and a network. It includes architectural concepts, principles, and
components used in the construction of composite services through components used in the construction of composite services through
deployment of SFCs. This document does not propose solutions, deployment of SFCs. This document does not propose solutions,
protocols, or extensions to existing protocols. protocols, or extensions to existing protocols.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 12, 2015. This Internet-Draft will expire on March 24, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 29 skipping to change at page 4, line 29
Note: Beyond this document, the term "service" is overloaded Note: Beyond this document, the term "service" is overloaded
with varying definitions. For example, to some a service is an with varying definitions. For example, to some a service is an
offering composed of several elements within the operator's offering composed of several elements within the operator's
network, whereas for others a service, or more specifically a network, whereas for others a service, or more specifically a
network service, is a discrete element such as a firewall. network service, is a discrete element such as a firewall.
Traditionally, such services (in the latter sense) host a set of Traditionally, such services (in the latter sense) host a set of
service functions and have a network locator where the service service functions and have a network locator where the service
is hosted. is hosted.
SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP
identification, and is used by the SFC-aware functions, such as
the SFF and SFC-aware SFs. The SFC Encapsulation is not used
for network packet forwarding. In addition to SFP
identification, the SFC encapsulation carries dataplane context
information, also referred to as metadata.
Classification: Locally instantiated policy and customer/network/ Classification: Locally instantiated policy and customer/network/
service profile matching of traffic flows for identification of service profile matching of traffic flows for identification of
appropriate outbound forwarding actions. appropriate outbound forwarding actions.
Classifier: An element that performs Classification. Classifier: An element that performs Classification.
Service Function Chain (SFC): A service function chain defines a set
of abstract service functions and ordering constraints that must
be applied to packets and/or frames selected as a result of
classification. The implied order may not be a linear
progression as the architecture allows for SFCs that copy to
more than one branch, and also allows for cases where there is
flexibility in the order in which service functions need to be
applied. The term service chain is often used as shorthand for
service function chain.
Service Function (SF): A function that is responsible for specific Service Function (SF): A function that is responsible for specific
treatment of received packets. A Service Function can act at treatment of received packets. A Service Function can act at
various layers of a protocol stack (e.g., at the network layer various layers of a protocol stack (e.g., at the network layer
or other OSI layers). As a logical component, a Service or other OSI layers). As a logical component, a Service
Function can be realized as a virtual element or be embedded in Function can be realized as a virtual element or be embedded in
a physical network element. One of multiple Service Functions a physical network element. One or multiple Service Functions
can be embedded in the same network element. Multiple can be embedded in the same network element. Multiple
occurrences of the Service Function can exist in the same occurrences of the Service Function can exist in the same
administrative domain. administrative domain.
One or more Service Functions can be involved in the delivery of One or more Service Functions can be involved in the delivery of
added-value services. A non-exhaustive list of abstract Service added-value services. A non-exhaustive list of abstract Service
Functions includes: firewalls, WAN and application acceleration, Functions includes: firewalls, WAN and application acceleration,
Deep Packet Inspection (DPI), LI (Lawful Intercept), server load Deep Packet Inspection (DPI), LI (Lawful Intercept), server load
balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296], balancing, NAT44 [RFC3022], NAT64 [RFC6146], NPTv6 [RFC6296],
HOST_ID injection, HTTP Header Enrichment functions, TCP HOST_ID injection, HTTP Header Enrichment functions, TCP
skipping to change at page 5, line 28 skipping to change at page 5, line 30
Service Function Forwarder (SFF): A service function forwarder is Service Function Forwarder (SFF): A service function forwarder is
responsible for delivering traffic received from the network to responsible for delivering traffic received from the network to
one or more connected service functions according to information one or more connected service functions according to information
carried in the SFC encapsulation, as well as handling traffic carried in the SFC encapsulation, as well as handling traffic
coming back from the SF. Additionally, a service function coming back from the SF. Additionally, a service function
forwarder is responsible for delivering traffic to a classifier forwarder is responsible for delivering traffic to a classifier
when needed and supported, mapping out traffic to another SFF when needed and supported, mapping out traffic to another SFF
(in the same or different type of overlay), and terminating the (in the same or different type of overlay), and terminating the
SFP. SFP.
Service Function Chain (SFC): A service Function chain defines a set Metadata: provides the ability to exchange context information
of abstract service functions and ordering constraints that must between classifiers and SFs and among SFs.
be applied to packets and/or frames selected as a result of
classification. The implied order may not be a linear
progression as the architecture allows for SFCs that copy to
more than one branch, and also allows for cases where there is
flexibility in the order in which service functions need to be
applied. The term service chain is often used as shorthand for
service function chain.
Service Function Path (SFP): The SFP provides a level of indirection Service Function Path (SFP): The SFP provides a level of indirection
between the fully abstract notion of service chain as a sequence between the fully abstract notion of service chain as a sequence
of abstract service functions to be delivered, and the fully of abstract service functions to be delivered, and the fully
specified notion of exactly which SFF/SFs the packet will visit specified notion of exactly which SFF/SFs the packet will visit
when it actually traverses the network. By allowing the control when it actually traverses the network. By allowing the control
components to specify this level of indirection, the operator components to specify this level of indirection, the operator
may control the degree of SFF/SF selection authority that is may control the degree of SFF/SF selection authority that is
delegated to the network. delegated to the network.
SFC Encapsulation: The SFC Encapsulation provides at a minimum SFP
identification, and is used by the SFC-aware functions, such as
the SFF and SFC-aware SFs. The SFC Encapsulation is not used
for network packet forwarding. In addition to SFP
identification, the SFC encapsulation carries data plane context
information, also referred to as metadata.
Rendered Service Path (RSP): The Service Function Path is a Rendered Service Path (RSP): The Service Function Path is a
constrained specification of where packets using a certain constrained specification of where packets using a certain
service chain must go. While it may be so constrained as to service chain must go. While it may be so constrained as to
identify the exact locations, it can also be less specific. identify the exact locations, it can also be less specific.
Packets themselves are of course transmitted from and to Packets themselves are of course transmitted from and to
specific places in the network, visiting a specific sequence of specific places in the network, visiting a specific sequence of
SFFs and SFs. This sequence of actual visits by a packet to SFFs and SFs. This sequence of actual visits by a packet to
specific SFFs and SFs in the network is known as the Rendered specific SFFs and SFs in the network is known as the Rendered
Service Path (RSP). This definition is included here for use by Service Path (RSP). This definition is included here for use by
later documents, such as when solutions may need to discuss the later documents, such as when solutions may need to discuss the
skipping to change at page 7, line 50 skipping to change at page 8, line 4
The architectural allowance that is made for SFPs that delegate The architectural allowance that is made for SFPs that delegate
choice to the network for which SFs and/or SFFs a packet will visit choice to the network for which SFs and/or SFFs a packet will visit
creates potential issues here. A solution that allows such creates potential issues here. A solution that allows such
delegation needs to also describe how the solution ensures that those delegation needs to also describe how the solution ensures that those
service chains that require service function chain symmetry can service chains that require service function chain symmetry can
achieve that. achieve that.
Further, there are state tradeoffs in symmetry. Symmetry may be Further, there are state tradeoffs in symmetry. Symmetry may be
realized in several ways depending on the SFF and classifier realized in several ways depending on the SFF and classifier
functionality. In some cases, "mirrored" classification (S -> D and functionality. In some cases, "mirrored" classification (i.e., from
D -> S) policy may be deployed, whereas in others shared state Source to Destination and from Destination to Source) policy may be
between classifiers may be used to ensure that symmetric flows are deployed, whereas in others shared state between classifiers may be
correctly identified, then steered along the required SFP. At a high used to ensure that symmetric flows are correctly identified, then
level, there are various common cases. In a non-exhaustive way, steered along the required SFP. At a high level, there are various
there can be for example: a single classifier (or a small number of common cases. In a non-exhaustive way, there can be for example: a
classifiers), in which case both incoming and outgoing flows could be single classifier (or a small number of classifiers), in which case
recognized at the same classifier, so the synchronization would be both incoming and outgoing flows could be recognized at the same
feasible by internal mechanisms internal to the classifier. Another classifier, so the synchronization would be feasible by internal
case is the one of stateful classifiers where several classifiers may mechanisms internal to the classifier. Another case is the one of
be clustered and share state. Lastly, another case entails fully stateful classifiers where several classifiers may be clustered and
distributed classifiers, where synchronization needs to be provided share state. Lastly, another case entails fully distributed
through unspecified means. This is a non-comprehensive list of classifiers, where synchronization needs to be provided through
common cases. unspecified means. This is a non-comprehensive list of common cases.
2.3. Service Function Paths 2.3. Service Function Paths
A service function path (SFP) is a mechanism used by service chaining A service function path (SFP) is a mechanism used by service chaining
to express the result of applying more granular policy and to express the result of applying more granular policy and
operational constraints to the abstract requirements of a service operational constraints to the abstract requirements of a service
chain (SFC). This architecture does not mandate the degree of chain (SFC). This architecture does not mandate the degree of
specificity of the SFP. Architecturally, within the same SFC-enabled specificity of the SFP. Architecturally, within the same SFC-enabled
domain, some SFPs may be fully specified, selecting exactly which SFF domain, some SFPs may be fully specified, selecting exactly which SFF
and which SF are to be visited by packets using that SFP, while other and which SF are to be visited by packets using that SFP, while other
skipping to change at page 12, line 22 skipping to change at page 12, line 22
the wire, an SF becomes a resource within a specified administrative the wire, an SF becomes a resource within a specified administrative
domain that is available for consumption as part of a composite domain that is available for consumption as part of a composite
service. SFs send/receive data to/from one or more SFFs. SFC-aware service. SFs send/receive data to/from one or more SFFs. SFC-aware
SFs receive this traffic with the SFC encapsulation. SFs receive this traffic with the SFC encapsulation.
While the SFC architecture defines a new encapsulation - the SFC While the SFC architecture defines a new encapsulation - the SFC
encapsulation - and several logical components for the construction encapsulation - and several logical components for the construction
of SFCs, existing SF implementations may not have the capabilities to of SFCs, existing SF implementations may not have the capabilities to
act upon or fully integrate with the new SFC encapsulation. In order act upon or fully integrate with the new SFC encapsulation. In order
to provide a mechanism for such SFs to participate in the to provide a mechanism for such SFs to participate in the
architecture, an SFC proxy function is defined. The SFC proxy acts architecture, an SFC proxy function is defined (see Section 4.6).
as a gateway between the SFC encapsulation and SFC-unaware SFs. The The SFC proxy acts as a gateway between the SFC encapsulation and
integration of SFC-unaware service functions is discussed in more SFC-unaware SFs. The integration of SFC-unaware service functions is
detail in the SFC proxy section. discussed in more detail in the SFC proxy section.
This architecture allows an SF to be part of multiple SFPs and SFCs. This architecture allows an SF to be part of multiple SFPs and SFCs.
4.3. Service Function Forwarder (SFF) 4.3. Service Function Forwarder (SFF)
The SFF is responsible for forwarding packets and/or frames received The SFF is responsible for forwarding packets and/or frames received
from the network to one or more SFs associated with a given SFF using from the network to one or more SFs associated with a given SFF using
information conveyed in the SFC encapsulation. Traffic from SFs information conveyed in the SFC encapsulation. Traffic from SFs
eventually returns to the same SFF, which is responsible for putting eventually returns to the same SFF, which is responsible for
it back onto the network. injecting traffic back onto the network.
The collection of SFFs and associated SFs creates a service plane The collection of SFFs and associated SFs creates a service plane
overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside. overlay in which SFC-aware SFs, as well as SFC-unaware SFs reside.
Within this service plane, the SFF component connects different SFs Within this service plane, the SFF component connects different SFs
that form a service function path. that form a service function path.
SFFs maintain the requisite SFP forwarding information. SFP SFFs maintain the requisite SFP forwarding information. SFP
forwarding information is associated with a service path identifier forwarding information is associated with a service path identifier
that is used to uniquely identify an SFP. The service forwarding that is used to uniquely identify an SFP. The service forwarding
state enables an SFF to identify which SFs of a given SFP should be state enables an SFF to identify which SFs of a given SFP should be
skipping to change at page 13, line 13 skipping to change at page 13, line 13
that all packets of a given flow are handled the same way, since the that all packets of a given flow are handled the same way, since the
SF may well be stateful. Additionally, the SFF may preserve the SF may well be stateful. Additionally, the SFF may preserve the
handling of packets based on other properties on top of a flow, such handling of packets based on other properties on top of a flow, such
as a subscriber, session, or application instance identification. as a subscriber, session, or application instance identification.
The SFF also has the information to allow it to forward packets to The SFF also has the information to allow it to forward packets to
the next SFF after applying local service functions. Again, while the next SFF after applying local service functions. Again, while
there may be only a single choice available, the architecture allows there may be only a single choice available, the architecture allows
for multiple choices for the next SFF. As with SFs, the solution for multiple choices for the next SFF. As with SFs, the solution
needs to operate such that the behavior with regard to specific flows needs to operate such that the behavior with regard to specific flows
(see the Rendered Service Path) is stable. It should be noted that (see the Rendered Service Path) is stable. The selection of
the selection of available SFs and next SFFs may be interwoven when available SFs and next SFFs may be interwoven when an SFF supports
an SFF supports multiple distinct service functions and the same multiple distinct service functions and the same service function is
service function is available at multiple SFFs. Solutions need to be available at multiple SFFs. Solutions need to be clear about what is
clear about what is allowed in these cases. allowed in these cases.
It should be noted that even when the SFF supports and utilizes Even when the SFF supports and utilizes multiple choices, the
multiple choices, the decision as to whether to use flow-specific decision as to whether to use flow-specific mechanisms or coarser
mechanisms or coarser grained means to ensure that the behavior of grained means to ensure that the behavior of specific flows is stable
specific flows is stable is a matter for specific solutions and is a matter for specific solutions and specific implementations.
specific implementations.
The SFF component has the following primary responsibilities: The SFF component has the following primary responsibilities:
1. SFP forwarding : Traffic arrives at an SFF from the network. The 1. SFP forwarding : Traffic arrives at an SFF from the network. The
SFF determines the appropriate SF the traffic should be forwarded SFF determines the appropriate SF the traffic should be forwarded
to via information contained in the SFC encapsulation. Post-SF, to via information contained in the SFC encapsulation. Post-SF,
the traffic is returned to the SFF, and if needed forwarded to the traffic is returned to the SFF, and if needed forwarded to
another SF associated with that SFF. If there is another non- another SF associated with that SFF. If there is another non-
local (i.e., different SFF) hop in the SFP, the SFF further local (i.e., different SFF) hop in the SFP, the SFF further
encapsulates the traffic in the appropriate network transport encapsulates the traffic in the appropriate network transport
skipping to change at page 14, line 50 skipping to change at page 14, line 50
4.5. Network Overlay and Network Components 4.5. Network Overlay and Network Components
Underneath the SFF there are components responsible for performing Underneath the SFF there are components responsible for performing
the transport (overlay) forwarding. They do not consult the SFC the transport (overlay) forwarding. They do not consult the SFC
encapsulation or inner payload for performing this forwarding. They encapsulation or inner payload for performing this forwarding. They
only consult the outer-transport encapsulation for the transport only consult the outer-transport encapsulation for the transport
(overlay) forwarding. (overlay) forwarding.
4.6. SFC Proxy 4.6. SFC Proxy
In order for the SFC architecture to support SFC-unaware SFs (.e.g In order for the SFC architecture to support SFC-unaware SFs (e.g.,
legacy service functions) a logical SFC proxy function may be used. legacy service functions) a logical SFC proxy function may be used.
This function sits between an SFF and one or more SFs to which the This function sits between an SFF and one or more SFs to which the
SFF is directing traffic. SFF is directing traffic.
The proxy accepts packets from the SFF on behalf of the SF. It The proxy accepts packets from the SFF on behalf of the SF. It
removes the SFC encapsulation, and then uses a local attachment removes the SFC encapsulation, and then uses a local attachment
circuit to deliver packets to SFC unaware SFs. It also receives circuit to deliver packets to SFC unaware SFs. It also receives
packets back from the SF, reapplies the SFC encapsulation, and packets back from the SF, reapplies the SFC encapsulation, and
returns them to the SFF for processing along the service function returns them to the SFF for processing along the service function
skipping to change at page 21, line 42 skipping to change at page 21, line 42
Expecting service functions to deal with packets fragmented by the Expecting service functions to deal with packets fragmented by the
SFC function might be onerous even when such fragmentation was SFC function might be onerous even when such fragmentation was
possible. Thus, at the very least, solutions need to pay attention possible. Thus, at the very least, solutions need to pay attention
to the size cost of their approach. There may be alternative or to the size cost of their approach. There may be alternative or
additional means available, although any solution needs to consider additional means available, although any solution needs to consider
the tradeoffs. the tradeoffs.
These considerations apply to any generic architecture that increases These considerations apply to any generic architecture that increases
the header size. There are also more specific MTU considerations: the header size. There are also more specific MTU considerations:
Effects on Path MTU Discovery (PMTUD) as well as deployment Effects on Path MTU Discovery (PMTUD) as well as deployment
considerations. Deployments within a single administrateive control considerations. Deployments within a single administrative control
or even a single Data Center complex can afford more flexibility in or even a single Data Center complex can afford more flexibility in
dealing with larger packets, and deploying existing mitigations that dealing with larger packets, and deploying existing mitigations that
decrease the likelihood of fragmentation or discard. decrease the likelihood of fragmentation or discard.
5.7. SFC OAM 5.7. SFC OAM
Operations, Administration, and Maintenance (OAM) tools are an Operations, Administration, and Maintenance (OAM) tools are an
integral part of the architecture. These serve various purposes, integral part of the architecture. These serve various purposes,
including fault detection and isolation, and performance management. including fault detection and isolation, and performance management.
For example, there are many advantages of SFP liveness detection, For example, there are many advantages of SFP liveness detection,
skipping to change at page 23, line 39 skipping to change at page 23, line 39
including DDoS attacks. Further, SFC OAM Functions need to not including DDoS attacks. Further, SFC OAM Functions need to not
negatively affect the security considerations of an SFC-enabled negatively affect the security considerations of an SFC-enabled
domain. Additionally, all entities (software or hardware) domain. Additionally, all entities (software or hardware)
interacting with the service chaining mechanisms need to provide interacting with the service chaining mechanisms need to provide
means of security against malformed, poorly configured (deliberate or means of security against malformed, poorly configured (deliberate or
not) protocol constructs and loops. These considerations are largely not) protocol constructs and loops. These considerations are largely
the same as those in any network, particularly an overlay network. the same as those in any network, particularly an overlay network.
7. Contributors and Acknowledgments 7. Contributors and Acknowledgments
The editors would like to thank Sam Aldrin, Linda Dunbar, Alla The editors would like to thank Sam Aldrin, Nicolas Bouthors, Linda
Goldner, Ken Gray, Anil Gunturu, Shunsuke Homma, Dave Hood, Nagendra Dunbar, Alla Goldner, Ken Gray, Barry Greene, Anil Gunturu, David
Kumar, Hongyu Li, Andrew Malis, Guy Meador III, Kengo Naito, Ron Harrington, Shunsuke Homma, Dave Hood, Nagendra Kumar, Hongyu Li,
Parker, Reinaldo Penno, Naiming Shen, Xiaohu Xu, and Lucy Yong for a Andrew Malis, Guy Meador III, Kengo Naito, Ron Parker, Reinaldo
thorough review and useful comments. Penno, Naiming Shen, Xiaohu Xu, and Lucy Yong for a thorough review
and useful comments.
The initial version of this "Service Function Chaining (SFC) The initial version of this "Service Function Chaining (SFC)
Architecture" document is the result of merging two previous Architecture" document is the result of merging two previous
documents, and this section lists the aggregate of authors, editors, documents, and this section lists the aggregate of authors, editors,
contributors and acknowledged participants, all who provided contributors and acknowledged participants, all who provided
important ideas and text that fed into this architecture. important ideas and text that fed into this architecture.
[I-D.boucadair-sfc-framework]: [I-D.boucadair-sfc-framework]:
Authors: Authors:
 End of changes. 16 change blocks. 
58 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/