Internet DRAFT - draft-jiang-sfc-arch
draft-jiang-sfc-arch
Internet Working Group Y. Jiang
H. Li
Internet Draft Huawei
Intended status: Informational
Expires: August 2014 February 14, 2014
An Architecture of Service Function Chaining
draft-jiang-sfc-arch-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF 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 August 14, 2014.
Copyright Notice
Copyright (c) 2014 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
Jiang, et al Expires August 14, 2014 [Page 1]
Internet-Draft Service Chaining Architecture February 2014
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Abstract
As network virtualization is opening the gate to much more innovative
services for service providers, Service Function Chaining (SFC)
provides a flexible way of service provisioning and facilitates their
deployments.
This document provides a general abstract architecture for service
chaining. It is a flexible and scalable architecture which can
fulfill requirements of SFC. Some solutions based on this
architecture are also discussed and compared. This architecture can
be used as a guideline and also a criterion for the design of SFC.
Table of Contents
1. Conventions used in this document ......................... 3
2. Terminology ............................................... 3
3. Introduction .............................................. 3
4. Service Chaining Architecture ............................. 5
5. Service Chaining Topology ................................. 7
6. Service Chaining Construction ............................. 7
6.1. Service chaining Controller ............................ 8
7. Availability and Scalability of Service Chaining........... 8
8. Service Chaining Solution Considerations .................. 9
8.1. Ethernet compatible solution ........................... 9
8.2. IP/MPLS compatible solution ........................... 10
8.3. Solution of Network-Located Function Chaining (NLFC) .. 10
8.4. Solution with a standalone service header ............. 10
9. Security Considerations .................................. 10
10. IANA Considerations ...................................... 11
11. References ............................................... 11
11.1. Normative References ............................... 11
11.2. Informative References ............................. 11
12. Acknowledgments .......................................... 11
Appendix Change Log .......................................... 11
Authors' Addresses ............................................ 12
Jiang, et al Expires August 14, 2014 [Page 2]
Internet-Draft Service Chaining Architecture February 2014
1. 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 [RFC2119].
2. Terminology
Service Flow: packets/frames with specific service characteristics
(e.g., packets matching a specific tuple of fields in Ethernet, IP,
TCP, HTTP headers and etc.) or determined by some service policies
(such as access port and etc.)
Service Classifier (SCLA), an entity which can classify incoming
packets/frames into different service flows based on their service
characteristics or some policies.
Service Function (SF): a logical entity which can provide one or
more service processing functions for packets/frames such as firewall,
DPI (Deep Packet Inspection), LI (Lawful Intercept) and etc. Usually
these processing functions are computation intensive. This entity may
also provide packet/frame encapsulation/decapsulation capability.
Service Chain (SC): one or more service processing functions in a
specific order which are chained together to provide a composite
service, and packets/frames from one or more service flow should
follow and be processed in sequence.
Service Chaining Domain: a domain where packet is forwarded using
service chaining mechanism.
Service Forwarding Entity (SFE): a logical entity which forwards
packets/frames to SFs attached to this SFE or other SFEs in the same
service chain. Optionally, it provides mapping, insertion and removal
of header(s) in packets/frames. Note service forwarding path may not
be the shortest path to its destination.
Service Function Chaining (SFC): a mechanism of building service chains
and forwarding packets/frames of service flows through them.
3. Introduction
With the maturity of hardware/software in network virtualization, it
is possible for service providers to provide more innovative services.
Jiang, et al Expires August 14, 2014 [Page 3]
Internet-Draft Service Chaining Architecture February 2014
Service chaining provides a flexible way to construct services, e.g.,
it is easy to insert/remove, and upgrade service processing functions
for a service in this framework. It is thus possible to define very
complex services over heterogeneous networks in a consistent way with
the help of service chaining.
Several drafts have already been proposed for service chaining with
different approaches ([NLFC], [NSH] and [L3VPNSC]) and more solutions
are expected to emerge in the near future.
This document provides architecture and abstraction of the critical
components for service function chaining, and it is hoped to shed
some lights on the design of service chaining. Possible solutions of
service chaining are also outlined and compared in this document so
that they can be gauged under the same criterion.
Jiang, et al Expires August 14, 2014 [Page 4]
Internet-Draft Service Chaining Architecture February 2014
4. Service Chaining Architecture
In order to decouple the service from the networks, three layers of
protocols are envisioned in the stack of SFC:
-Service layer;
-SFC forwarding layer;
-Network under layer.
In the Service Layer, service functions may be provided with metadata
capability, but they may also behave like the traditional network
devices such as firewall or DPI. Therefore, a null or service layer
encapsulation/decapsulation may be needed.
In the SFC forwarding layer, a Sevice Chain (SC) can be abstracted to
consist of the following components:
- At least one Service CLAssifier (SCLA), which classifies incoming
packets/frames into different service flows based on their service
characteristics or some policies;
- One or more Service Forwarding Entities (SFEs), which make up the
forwarding path of a SC, and each SFE is attached with one or more
Service Functions.
- One or more Service Functions (SFs), which are connected with SFEs
and provide various service processing functions for a SC.
Service chaining architecture with a single SFE is demonstrated in
Figure 1. Upon their entry into a service chaining domain,
packets/frames are classified by SCLA into different service flows.
Then packets/frames from a specific service flow are forwarded by SFE
into one or more SFs in a service chain in correct order. Upon
completion of all service processing, they exit the service chaining
domain. It should be noted that SCLA, SFE, and even SFs can be
implemented in a single network element.
Jiang, et al Expires August 14, 2014 [Page 5]
Internet-Draft Service Chaining Architecture February 2014
SF SF
/-\ /-\ SF: Service Function
| | ... | |
\+/ \+/ SFE: Service Forward Entity
| |
| | SCLA: Service CLAssifier
| |
+--------+ +-+---------+--+
ENTRY| | | |EXIT
----+ SCLA +-----+ SFE +----
| | | |
+--------+ +--------------+
Figure 1 Service Chain with a single SFE
Service chaining architecture with multiple SFEs is further
demonstrated in Figure 2.
SF SF SF SF
/-\ /-\ /-\ /-\
| | ... | | | | ... | |
\+/ \+/ \+/ \+/
| | | |
| | | |
| | | |
+--------+ +-+---------+--+ +-+---------+--+
ENTRY| | | | | | EXIT
----+ SCLA +-----+ SFE +---------+ SFE +-----
| | | | | |
+--------+ +--------------+ +--------------+
Figure 2 Service Chain with Multiple SFEs
The Network under layer such as IP, MPLS, and Ethernet provides the
traditional transport (routing and switching) capability for the SCs.
Interconnections between SFs and their SFEs, and between SFE peers
can be a physical/logical link or a network path which may be an
Ethernet or IP/MPLS underlay network. Ethernet, IP/MPLS or other
Jiang, et al Expires August 14, 2014 [Page 6]
Internet-Draft Service Chaining Architecture February 2014
tunneling technologies such as those being in progress in NVO3
workgroup can be used for this underlay network.
5. Service Chaining Topology
SCLA, SF and SFE can be implemented as a standalone network entity,
or in a network entity combined with other functions (such as one SFE
plus one or more SFs, one SCLA plus one SFE, or one SCLA plus one SFE
and one or more SFs). Furthermore, they may be implemented as
software modules running in a DC, in clouds or as standalone physical
equipments.
Following service chaining topologies can be supported by this
architecture:
-Daisy chain
This is a type of service chain in the shape of a daisy, as
demonstrated in Figure 1, where multiple SFs are attached to a single
SFE, and SFs cannot send packets/frames directly to each other but
via one shared SFE.
-Lily chain
This is a type of service chain in the shape of a lily. It can be
regarded as a simplified form of Figure 2, where only a single SF is
attached to each SFE, and the SFEs are connected from one to another
in sequence.
-Hybrid chain
Part of a hybrid chain may be Daisy chain and other parts may be Lily
chain, thus it can be readily combined by the previous two.
More complex service chains can be constructed by reclassification of
a SC (for example, by providing multiple SCLAs in a SC); or by change
of the metadata in a SF (thus enforce a change to its forwarding
paradigm).
6. Service Chaining Construction
Attachment of SFs onto an SFE could be pre-configured on the SFE; or
updated by some auto discovery and registering procedure when an SF
first attaches to it.
Jiang, et al Expires August 14, 2014 [Page 7]
Internet-Draft Service Chaining Architecture February 2014
6.1. Service chaining Controller
A service chaining controller which centrally manages service chains
(e.g., set up, remove, and monitor service chains) can be implemented
together with an SDN controller or a network orchestrator. OSS may
also be used as a platform to provide this kind of control function.
In service layer, a Service Graph (SG) shall be defined for each
Service Chain (SC), which consists of a list of Service Functions and
their order, and parameters for the service flow over the SC.
In service forwarding layer, a Service Forwarding Graph (SFG) shall
be defined for each Service Chain, which consists of a list of
Service Functions and SFEs between them.
The service chaining controller is responsible for mapping a SG to a
SFG, installing/updating/removing classification tables on/from the
SCLAs, and installing/updating/removing service forwarding tables
on/from the SFEs.
A northbound RESTful API can be specified for the SC controller to
manage and control SCs over the web.
7. Availability and Scalability of Service Chaining
Two options for load balancing are possible:
-Load balancing on flows
It is very convenient to provide load balancing and make it scalable
in this architecture: construct multiple service chains which provide
the same set of service processing functions; the SCLA classifies a
service flow into sub-flows, and each sub-flow is directed into a
different service chain.
-Load balancing on SFs/paths
It is also possible to provide load balancing in finer granularity.
Such as, provide multiple SFs with the same service processing
function if a compute bottleneck is expected or found for this
service processing function; provide multiple paths between a pair of
SFEs if shortage of bandwidth is expected or found for the single
path between them. The SFE should be able to load balance a service
flow over these SFs or paths with some pre-determined algorithms.
Jiang, et al Expires August 14, 2014 [Page 8]
Internet-Draft Service Chaining Architecture February 2014
High availability of a service chain will be discussed in a next
version.
8. Service Chaining Solution Considerations
A solution must be able to classify packets/frames into different
service flows. This is done by the Service Classifier (a packet/frame
is classified with a tuple of fields in one or more headers or local
policy). After the classification, a Service Identification (SID) may
be applied to the packet/frame so that no further classification is
needed in subsequent SFEs. SID can be mapped to traditional header
fields such as a VLAN or an MPLS label (hence VLAN mapping or MPLS
label swap is needed), or carried in a new service header (hence an
extra header is inserted).
A solution must be able to forward packets/frames across all service
processing entities in a service chain in a correct sequence. This is
done by the service forwarding entity with the help of SID.
A solution should support the exchange of information between service
processing entity and the service forwarding entity. For example, the
processing result of a packet in a service processing entity can be
encoded in a service header in the packets. But for long term service
states (which can influence the processing of multiple
packets/frames), they can be locally stored and/or signaled to
service forwarding entity or other service processing entities by
some specific control channels (e.g., OpenFlow protocol).
[REQ] outlines a suite of requirements for service function chaining.
Possible solutions for service chaining are outlined in the following
sub-sections.
8.1. Ethernet compatible solution
Ethernet technology (IEEE 802.1Q, 802.1ad, and etc.) or DC technology
can be used to support service chaining. SCLA maps service ID of a
service flow to a VLAN (e.g., C-VLAN and S-VLAN) ID or a VXLAN ID in
a frame. SFE then forwards the frame with the VLAN ID to appropriate
SFs for service processing (may need to change VLAN ID for each SF).
The issue with this solution: its service chaining layer is entangled
with its transport layer, thus planning and provisioning of service
chains are complex, and it may not be a scalable solution to be used
Jiang, et al Expires August 14, 2014 [Page 9]
Internet-Draft Service Chaining Architecture February 2014
in a large network since VLAN ID or VXLAN ID space is shared by both
service ID and tunnel ID.
8.2. IP/MPLS compatible solution
MPLS can be used to support service chaining - only an MPLS label is
needed to represent SID of a service flow. Service ID of a service
flow is mapped to an MPLS label in the packets by the SCLA. SFE then
forwards frames with the label to appropriate SFs for service
processing (may need to swap the label for each SF).
[L3VPNSC] demonstrates how service topology specific Route Targets
can be introduced into BGP/MPLS VPN to support automatic signaling of
service chaining.
Similarly, L2VPN may be crafted to support service chaining.
8.3. Solution of Network-Located Function Chaining (NLFC)
[NLFC] proposes a solution of using NLFC Map (an ordered list of NLF
identifiers) for service chaining, where a packet carries a map index
of its service chain, then NLF nodes forward the packet by looking up
the map index in locally stored NLFC Policy Table for its next NLF
node.
8.4. Solution with a standalone service header
A standalone service header can provide an independent layer of
protocol data unit, so that service specific information such as SID
can be carried over all kinds of underlay networks with no need of
mapping.
[NSH] proposes a new Network Service Header for service chaining,
which consists of a Base Header and a Context Header.
[SCHM] also introduces a simple service chaining header and how to
use it to build service chains.
9. Security Considerations
This document proposes architecture for the service chaining,
outlines several types of its topology, and discusses possible
approaches in this domain, thus no security issue is raised at
present. It was expected that further solutions for these
requirements will deal with security considerations specifically.
Jiang, et al Expires August 14, 2014 [Page 10]
Internet-Draft Service Chaining Architecture February 2014
10. IANA Considerations
No IANA action is needed for this document.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
11.2. Informative References
[NLFC] Boucadair, M., and Jacquenet, C., "Service Function Chaining:
Framework & Architecture", draft-boucadair-sfc-framework-02,
February 2014.
[NSH] Quinn, P., and Fernando, R., and et al, "Network Service
Header", draft-quinn-sfc-nsh-01, February 2014.
[SCHM] Niu, L., Li, H., and Jiang, Y., "A Service Function Chaining
Header and its Mechanism", draft-niu-sfc-mechanism-00,
January 2014.
[L3VPNSC] Fernando, R., Rao, D., and et al, "Virtual Topologies for
Service Chaining in BGP IP VPNs", draft-rfernando-l3vpn-
service-chaining-01, June 2013.
[REQ] Boucadair, M., and et al, "Requirements for Service Function
Chaining", draft-boucadair-sfc-requirements-03, February
2014.
[PS] Quinn, P., and et al, "Network Service Header",draft-ietf-sfc-
problem-statement
12. Acknowledgments
TBD.
Appendix Change Log
A.1 draft-jiang-service-chaining-arch-00, June 2013
A.2 draft-jiang-sfc-arch-00, October 2013
A.2 draft-jiang-sfc-arch-01, February 2014
Jiang, et al Expires August 14, 2014 [Page 11]
Internet-Draft Service Chaining Architecture February 2014
Authors' Addresses
Yuanlong Jiang
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129, China
Email: jiangyuanlong@huawei.com
Hongyu Li
Huawei Technologies Co., Ltd.
Bantian, Longgang district
Shenzhen 518129, China
Email: hongyu.lihongyu@huawei.com
Jiang, et al Expires August 14, 2014 [Page 12]
