Internet DRAFT - draft-parker-sfc-chain-to-path
draft-parker-sfc-chain-to-path
SFC R. Parker
Internet Draft Affirmed Networks
Intended status: Informational November 8, 2013
Expires: May 7, 2014
Service Function Chaining: Chain to Path Reduction
draft-parker-sfc-chain-to-path-00
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 8, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document.
Parker Expires May 7, 2014 [Page 1]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
Abstract
The service function chaining concept differentiates between a
service function chain and a service function path. A chain is a
sequence of service function types whereas a path is a sequence of
service function instances that realize each type of service
function.
This document describes the architectural approach to reducing the
abstract service function chain to the concrete service function
path.
Table of Contents
1. Introduction...................................................3
1.1. Service Function Chaining Concepts........................3
1.2. Scope.....................................................3
1.3. Objectives................................................4
1.4. Rationale.................................................4
2. Conventions used in this document..............................4
3. New SFC Functional Entities....................................6
3.1. SFC Proxy.................................................6
3.1.1. SFC Proxy for Non-last Service Function..............6
3.1.2. SFC Proxy for Last Service Function..................6
3.2. Service Function Load Balancer............................6
3.2.1. Proxy Service Function Load Balancer.................7
4. Service Function Path Topologies...............................7
4.1. Chain Comprised of Singly-located Service Functions.......7
4.1.1. With Non-SFC-aware Service Functions.................7
4.2. Chain Comprised of Multiply-located Service Functions.....8
4.2.1. With Non-SFC-aware Service Functions.................9
4.3. Hybrid Chains.............................................9
5. Security Considerations.......................................10
6. IANA Considerations...........................................10
7. Conclusions...................................................10
8. References....................................................11
8.1. Normative References.....................................11
8.2. Informative References...................................11
9. Acknowledgments...............................................11
Parker Expires May 7, 2014 [Page 2]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
1. Introduction
1.1. Service Function Chaining Concepts
The service function chain is an abstract sequenced set of service
functions, as described in [I-D.boucadair-sfc-framework]. Service
functions that participate in SFC are assumed to be transparent
"midbox" service functions, where transparent in this usage denotes
only that the service function is not explicitly addressed by either
communications endpoint.
The service function locator, also described in [I-D.boucadair-sfc-
framework], is the means to bind the abstract service functions to
physical or virtual instantiations. The completed mapping of a
service function chain through the locators of its constituent
service functions is called a service function path, also described
in [I-D.boucadair-sfc-framework].
A service function may have a single locator, or multiple locators.
When multiple locators are specified, a load balancing operation is
required to select which one of the instances shall be used for any
particular service function path. This document describes an
approach where the service function path is rendered in real time,
on a packet by packet basis, from the service function chain.
1.2. Scope
This document defines a technique whereby service function chains
may be rendered in real time as service function paths. This
document does not make any assumptions regarding the behavior of any
particular service function or the appropriate technique (i.e.,
stateless, stateful, etc.) to load balance for a given service
function.
Load balancing across multiple locators may involve liveness
checking or load checking. No assumptions are made regarding the
appropriate technique to determine the liveness or load for a
particular service function. Such load balancing may also involve
other policies, such as location of the service function instance
relative to the location of one or both communication endpoints.
No assumptions are made regarding the use or type of policy to
perform load balancing for a service function.
Parker Expires May 7, 2014 [Page 3]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
1.3. Objectives
. SFC classifier (PDP) actions identical for SFC-aware and non-SFC-
aware service functions
. SFC classifier (PDP)_actions identical for singly-located and
multiply-located service functions
. SFC classifier (PDP) actions identical for any service function
. Preceding service function actions identical for SFC-aware and
non-SFC-aware succeeding service functions
. Preceding service function actions identical for singly-located
and multiply-located succeeding service functions
. Preceding service function actions identical for any succeeding
service function
. SFC does not specify or limit mechanisms and behaviors for load
balancing within a service function
1.4. Rationale
SFC proxy functionality for non-SFC aware service functions and load
balancing for multiply-located service functions (SFC-aware and non-
SFC-aware) belongs to the service function domain. It is not
possible nor is it desirable to specify, in a practical manner,
either proxy functionality or load balancing for any arbitrary
service function.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
An abstract service function (i.e., part of a service chain
definition) is denoted as '<F>'.
A concrete service function instance (i.e. a service function that
has been located) is denoted as '<F>.<n>'.
Parker Expires May 7, 2014 [Page 4]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
An SFC service function proxy, as will be defined later in this
document, is denoted as '<F>.p'.
A service function load balancer is denoted as '<F>.lb'.
A combined service function load balancer and proxy, as will be
defined later in this document, is denoted as '<F>.plb'.
Unless otherwise specified, the term "Service Function Chain" shall
be more broadly interpreted as "Service Function Graph". It is
understood that any service function may include a reclassifier
(i.e., Policy Decision Point) in order to make dynamic branching
decisions along the service function graph.
Parker Expires May 7, 2014 [Page 5]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
3. New SFC Functional Entities
The following SFC functional entities are in addition to those
identified in [I-D.boucadair-sfc-framework].
3.1. SFC Proxy
An SFC proxy front-ends a legacy service function that is not SFC-
aware.
3.1.1. SFC Proxy for Non-last Service Function
When receiving packets from the preceding service function (or the
PDP if this service function is first), the SFC proxy terminates
both the transport and SFC service headers. The resulting packets
are forwarded to the legacy service function. The legacy service
function must be provisioned to return the packets back to the SFC
proxy.
When receiving returned packets from the legacy service function,
the SFC proxy generates appropriate transport and SFC service
headers towards the succeeding service function.
It is permissible for an SFC Proxy to also act as a reclassifier,
thereby making a branching decision on a service function graph.
3.1.2. SFC Proxy for Last Service Function
It shall be an implementation decision as to whether a non-SFC-aware
service function that is the last service function in the chain
returns the packets to its proxy or send the packets beyond the end
of the chain directly.
3.2. Service Function Load Balancer
A service function load balancer manages all load balancing duties
for its constituent SFC-aware service function instances. How this
is accomplished for the given service function is completely outside
the scope of this document.
The service function load balancer appears to preceding services, or
the PDP if the service function is the first in the chain, as a
single entity that receives all traffic for that service function
within the particular chain. Thus, preceding services and the PDP,
itself, never concern themselves with the fact that the succeeding
service may have multiple locators.
Parker Expires May 7, 2014 [Page 6]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
Since the service function load balancer is managing SFC-aware
service function instances, it is not, itself eligible to be a
reclassifier (Policy Decision Point).
3.2.1. Proxy Service Function Load Balancer
The proxy service function load balancer is a combination of the
service function proxy and the SFC-aware load balancer. Since it
terminates the transport and SFC service headers, the proxy service
function load balancer is eligible to be a reclassifier (Policy
Decision Point).
4. Service Function Path Topologies
This section provides a number of example topologies that
demonstrate the real-time reduction of the service function chain to
a specific service function path.
4.1. Chain Comprised of Singly-located Service Functions
This topology is the simplest since the chain and path have a 1:1
correspondence. An example service function path comprised solely
of singly-located, SFC-aware service functions is depicted below.
+-----+ +-----+ +-----+ +-----+
----->| PDP |----->| A.1 |----->| B.1 |----->| C.1 |----->
+-----+ +-----+ +-----+ +-----+
4.1.1. With Non-SFC-aware Service Functions
In this use case, the service functions require an SFC-proxy to act
as front-end.
+-----+ +-----+ +-----+ +-----+
----->| PDP |----->| A.p |----->| B.p |----->| C.p |----->
+-----+ +-----+ +-----+ +-----+
| ^ | ^ | ^
| | | | | |
+-----+ +-----+ +-----+
| A.1 | | B.1 | | C.1 |
+-----+ +-----+ +-----+
Parker Expires May 7, 2014 [Page 7]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
4.2. Chain Comprised of Multiply-located Service Functions
This use case supports load balancing across multiple service
function instances. For clarity, each load balancer is shown as
having picked a particular service instance. The means by which
this selection is made is outside the scope of this document.
+-----+ +------+ +------+ +------+
--->| PDP |----->| A.lb | +-->| B.lb | +-->| C.lb |
+-----+ +------+ | +------+ | +------+
| | | | |
| +-----+ | | +-----+ | | +-----+
+-->| A.1 |-+ + | B.1 | | + | C.1 |
| +-----+ | +-----+ | | +-----+
| | | |
| +-----+ | +-----+ | | +-----+
+ | A.2 | +-->| B.2 |-+ + | C.2 |
+-----+ +-----+ | +-----+
|
| +-----+
+-->| C.3 |--->
+-----+
As can be seen from this diagram, the preceding node (PDP or service
function) always propagates packets to the responsible load balancer
for the next service function in the chain. The load balancer
makes a service function appropriate selection for the packet and
forwards to one of the service function instances. Since the
service function instances are SFC-aware, they directly forward the
packet to the next service function load balancer, or out of the
chain entirely, if the last service function in the chain.
Parker Expires May 7, 2014 [Page 8]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
4.2.1. With Non-SFC-aware Service Functions
This use case could be achieved by front-ending each service
instance with an SFC proxy. Such an approach is entirely valid.
However, an alternative approach is also supported by use of the
proxy service function load balancer.
+-----+ +-------+ +-------+ +-------+
---->| PDP |--->| A.plb |------->| B.plb |------>| C.plb |----->
+-----+ +-------+ +-------+ +-------+
| ^ | ^ | ^
| | | | | |
| | | | | |
| +------+ | +------+ | +------+
| | | | | |
| +-----+ | | +-----+ | | +-----+ |
+-->| A.1 |-+ + | B.1 | | + | C.1 | |
| +-----+ | +-----+ | | +-----+ |
| | | | |
| +-----+ | +-----+ | | +-----+ |
+ | A.2 | +-->| B.2 |-+ + | C.2 | |
+-----+ +-----+ | +-----+ |
| |
| +-----+ |
+-->| C.3 |-+
+-----+
It can be seen that this diagram differs from the previous in that
the service functions must return the packets to their respective
proxy/load balancer for appropriate transport and SFC service header
encapsulation.
4.3. Hybrid Chains
A chain of service functions may support any combination of service
functions that are singly-located SFC-aware, load-balanced SFC-
aware, singly-located proxied, and load-balanced proxied.
Parker Expires May 7, 2014 [Page 9]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
5. Security Considerations
All SFC entities must be protected against DDoS attacks, malformed
packets, and poorly configured (deliberately or not) service chains
and service function locator tables.
6. IANA Considerations
There are no IANA considerations for this document.
7. Conclusions
By strictly layering SFC chaining, SFC proxy, and load balancing, a
simpler more resilient end-to-end service function chaining
architecture is achieved. Handling of failed service function
instances as well as static and dynamic expansion and contraction of
the service function is localized to an entity that has been
designed specifically for that type of service function.
Both preceding service functions (or PDP) and succeeding service
functions are completely unaware of whether a service function is
SFC-aware, multiply instantiated, both, or neither.
This architecture provides a unified approach for incorporation of
multiple instances of SFC-aware service functions, for incorporation
of non-SFC-aware legacy service functions, and for incorporation of
multiple instances of non-SFC aware legacy service functions.
Parker Expires May 7, 2014 [Page 10]
Internet-Draft SFC Chain to Path Reduction November 8, 2013
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[I-D.boucadair-sfc-framework]
M. Bouadair, C. Jacquenet, R. Parker, D. Lopez, J. Guichard,
C. Pignataro, "Service Function Chaining: Framework &
Architecture", http://tools.ietf.org/html/draft-boucadair-
sfc-framework-00 (work in progress), October 3, 2013
[I-D.quinn-sfc-nsh]
P. Quinn, et. al., "Network Service Header",
http://tools.ietf.org/html/draft-quinn-sfc-nsh-00 (work in
progress), October 7, 2013
9. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Ron Parker
Affirmed Networks
Acton, MA 01720
USA
Email: ron_parker@affirmednetworks.com
Parker Expires May 7, 2014 [Page 11]
