Internet DRAFT - draft-liu-sfc-nesting-use-case
draft-liu-sfc-nesting-use-case
Service Function Chaining Working Group D. Liu
Internet-Draft J. Cao
Intended status: Standards Track Alibaba Group
Expires: January 6, 2016 July 05, 2015
Use Case of Hierarchical Service Function Chaining
draft-liu-sfc-nesting-use-case-01
Abstract
This document proposes use case and requirement of hierarchical
service function chaining.
Requirements Language
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].
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). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 6, 2016.
Copyright Notice
Copyright (c) 2015 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. Code Components extracted from this document must
Liu & Cao Expires January 6, 2016 [Page 1]
Internet-Draft Hierarchical SFC July 2015
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.
Table of Contents
1. Use case of Hierarchical SFC . . . . . . . . . . . . . . . . 2
2. Requirement of Hierarchical Service Function Chaining . . . . 8
3. contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Normative References . . . . . . . . . . . . . . . . . . 9
7.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Use case of Hierarchical SFC
The advantage of hierarchical service function chaining compared with
normal or flat service function chaining is that it can reduce the
management complexity significantly. This section discusses the use
cases that shows the advantage of hierarchical service chaining.
Use case 1: Traffic Identificaiton
The scenario discussed in this section is called hierarchical service
function chaining. As shown in figure 1, there are two types of
service function chains. The first type is SFC1. There are two sub-
type service function chains of SFC1, SFC1_1 and SFC1_2. SFC1_1 and
SFC1_2 belongs to the same type of service function chain type SFC1.
The second type of service function chain is SFC2. There are two
sub-type service function chains of SFC2, namely SFC2_1 and SFC2_2.
There are two more types of service function chain of sub-type
SFC2_1, namely SFC2_1_1 and SFC2_1_2. For service function chain
SFC2, there is one sub-type of service function chain called SFC2_2.
o As figure 1 shows, there are two tenants in a public cloud. All
of the first tenant's traffic is identified as SFC1 and all of the
second tenant's traffic is identified as SFC2. A more concrete
example is that the first tenant is social networking service and
the second tenant is online gaming service.
o For the social networking service traffic SFC1, the first sub-type
of SFC1 is the traffic between users and it is identified as
SFC1_1. The second sub-type of SFC1 is the traffic for
advertisement and it is identified as SFC1_2. The traffic of both
SFC1_1 and SFC1_2 belong to the same social networking service
Liu & Cao Expires January 6, 2016 [Page 2]
Internet-Draft Hierarchical SFC July 2015
tenant but it may have different policies. For example, the
traffic between users may have higher priority compared with the
traffic for advertisement.
o For the online gaming service SFC2, the first sub-type of SFC2 is
the traffic of gaming interaction and it is identified as SFC2_1.
There two more sub-type of SFC2_1, the first sub-type is the
traffic that belongs to VIP users and it is identified as
SFC2_2_1. The other sub-type is the traffic that belongs to
normal user and it is identified as SFC2_1_2. Both the traffic of
SFC2_1_1 and SFC2_1_2 belong to online gaming interaction traffic
but it may have different policy. For example, the traffic of
SFC2_1_1 may have higher priority compared with the traffic of
SFC2_1_2.
o The second sub-type of online gaming service is user payment
traffic and it is identified as SFC2_2. Both of traffic SFC2_1
and SFC2_2 belong to the online gaming service tenant but it may
have different policies. For example, the online gaming
interaction traffic may have higher priority compared with the
payment traffic.
Data center operator can use hierachical service function chaining to
identify user tarffic in different granularity. For example, data
center operator could manage all the social networking traffic using
SFC1. They can also manage the advertisement traffic within the
social networking traffic as SFC1_1. The management complexity could
be reduced compared with normal SFC.
Liu & Cao Expires January 6, 2016 [Page 3]
Internet-Draft Hierarchical SFC July 2015
+----------------+ +-----------------+
| +--------+ | | +--------+ |
| | VM1 |<--|-------|----| VM1 |---|----> SFC1/SFC1_1
| +--------+ | +-- |----+--------+---|----> SFC1/SFC1_2
| +--------+ | | | +--------+ |
| | VM2 |<--|---+ +-|----| VM2 |---|----> SFC2/SFC2_1/SFC2_1_1
| +--------+ | | | +--------+ |
| +--------+<--|-----+ | +--------+ |
| | VM3 |<--|-------|----| VM3 |---|----> SFC2/SFC2_1/SFC2_1_2
| +--------+ | | +--------+ |
| +--------+ | | +--------+ |
| | VM4 |<--|-------|----| VM4 |---|----> SFC2/SFC2_2
| +--------+ | | +--------+ |
| ... | | |
+----------------+ +-----------------+
DB Web
Figure 1: Hierarchical Service Function Chaining Scenario
Use case 2: Inter-Datacenter SFC
Hierarchical service chaining could be used to simplify inter-
datacenter SFC management. [draft-ietf-sfc-dc-use-cases-02] has
discussed the inter-datacenter SFC use case. One concrete example of
inter-datacenter SFC is shown in figure 3. Multiple local data-
centers are deployed in a geographically distributed manner. A
central datacenter which contains service functions that can not be
virtualized and have low usage rate is deployed centrally. Deploying
those service function in every local datacenter will increase the
CAPEX/OPEX. So the datacenter operator prefer to deploy those
service functions in a central datacenter.
When we use "Flat(Normal) SFC", the number of SFPs managed in central
datacenter may increase and the change of SFP configuration in the
central datacenter will affect other data-centers. For example, as
shown in figure 4, when we put a new SF in the central datacenter and
set a new SFP, change of SFP configuration would be required for each
datacenter. On the other hand, if we use hierarchical SFC approach,
we can manage each datacenter independently, and the management
complexity can be reduced.
Liu & Cao Expires January 6, 2016 [Page 4]
Internet-Draft Hierarchical SFC July 2015
.--.__.--.__.--.
( )-.
.' )
( Internet )
( -'
'-( __)
^ '---'~'---' ^
| ^ |
+-------+ | +-------+
| +----+----+ |
| | Central | <=========|====== Central DC:
| | DC | | Some HW APL
| ++---+---++ | which have
| | | | | low usage
| +--------+ | +--------+ | rate are
| | v | | deployed in
| | [ UEs ] | | central DC.
+-+---+-+ Area#x +-+---+-+
| Local | | Local | <== Local DCs
| DC#1 | ... | DC#n | are deployed
+---+---+ +---+---+ geographically
| | distributed.
| |
v v
[ UEs ] [ UEs ]
Area#a Area#n
Figure 2:Inter-DC SFC in distributed DCs network
Liu & Cao Expires January 6, 2016 [Page 5]
Internet-Draft Hierarchical SFC July 2015
---> : Existing Path
===> : New Path
.---------. .---------.
/ LDC#1 \ / CDC \
+--+ | | | -+
|CF|-----------------------------------------> |
| |-----------------------------------------> |
| |=========================================> |
+--+ | +-----------------------> |
\ / | +--------------------> |
'--------' | | #=================> |
| | # \ / -+
.---------. | | # '---------'
/ LDC#2 \ | | #
+--+ | | | #
|CF|-----------------+ | #
| |--------------------+ #
| |=======================#
+--+ |
\ /
'--------'
| |
+------v------+
Figure 3: Issues of inter-DC SFC as flat SFC
Use case 3: Simplify SFC management
In this use case, hierarchical service chaining is used to simplify
service function chaining management by reducing the number of SFP.
As shown in figure 4, there are two types of user traffic: HTTP and
video. There are five security functions deployed in the security
domain. The datacenter operator want to enforce the five different
security policies to these two types of traffic separately. If we
use flat SFC (normal branching), 10 SFPs is needed in each domain.
On the other hand, if we use hierarchical SFC, only 5 SFPs in
domain#1 and 2 SFPs in domain#2 will be required as shown in figure
5.
Liu & Cao Expires January 6, 2016 [Page 6]
Internet-Draft Hierarchical SFC July 2015
. . . . . . . . . . .. . . . . . . . . . . . . . . ..
. Domain#1 . . Domain#2 .
. Security Domain . . HTTP with WAF .
. . . +->[ HHE ]----->[ NAT ] :
. . . | :
. . . | Video Traffic with WAF.
. +---->[ WAF ]------.------+->[Video Opt.]-->[ NAT ] :
. | . . :
. | . . HTTP with Anti-Virus .
. | . . +->[ HHE ]----->[ NAT ] :
. | . . | :
. | . . | Video with Anti-Virus .
. +---->[Anti-Virus]--------+->[Video Opt.]-->[ NAT ] :
. | . . :
. | . . HTTP with IPS .
. | . . +->[ HHE ]----->[ NAT ] :
. | . . | :
[CF]->[DPI]------->[ IPS ]-------------+ Video Traffic with IPS .
. | . . +->[Video Opt.]-->[ NAT ] :
. | . . :
. | . . HTTP with IDS .
. +---->[ IDS ]-------------+->[ HHE ]----->[ NAT ] :
. | . . | :
. | . . | Video Traffic with IDS .
. | . . +->[Video Opt.]-->[ NAT ] :
. | . . :
. | . . HTTP with Traffic Monitor.
. +---->[Traffic]-----------+->[ HHE ]----->[ NAT ] :
. Monitor . . | :
. . . |Video with Traffic Monitor
. . . +->[Video Opt.]-->[ NAT ] :
. . . . . . .. . . . . . . . . . . ... . . . . . . ..
Figure 4: Flat SFC in separated domains network
Liu & Cao Expires January 6, 2016 [Page 7]
Internet-Draft Hierarchical SFC July 2015
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ..
. Domain#1(Security Domain) . . Domain#2 .
. . . .
[CF]---->[ DPI(Sub-domain GW) ]------>[Sub-domain GW ]------------->
. | ^ . . | ^ .
. +----->[ WAF ]-----+ . . +-->[ HHE ]------>[ NAT ]-+ .
. | | . . | | .
. +-->[Anti-Virus]---+ . . +-->[Video Opt.]->[ NAT ]-+ .
. | | . . .
. +----->[ IPS ]-----+ . . . . . . . . . . . . . .. . . .
. | | .
. +----->[ IDS ]-----+ .
. | | .
. +-->[ Monitor ]----+ .
. . . . . . . . . . . . . . . .
Figure 5: Hierarchical in separated domains network
2. Requirement of Hierarchical Service Function Chaining
The requirement of hierarchical service function chaining is:
o The service function chain solution should allow hierarchical
structure.
o One service function chain may have multiple sub-domain of service
function chain.
o The number of levels of the hierarchical structure of a service
function chain should not be limited.
o Increase of the number of SFP by SFC across multiple DCs could be
limited
o The control and configuration in each domain should be independent
o metadata could be maintaind between some domains
o The paths in bi-direction could be symmetry in each domain
3. contributors
Shunsuke Homma: NTT Email: homma.shunsuke@lab.ntt.co.jp
Liu & Cao Expires January 6, 2016 [Page 8]
Internet-Draft Hierarchical SFC July 2015
4. IANA Considerations
This document makes no request of IANA.
5. Security Considerations
TBD
6. Acknowledgements
The authors would like to thank Shunsuke Homma for the useful
comments and suggestions.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
[draft-ietf-sfc-architecture-07]
"Service Function Chaining (SFC) Architecture", February
2015.
[draft-ietf-sfc-dc-use-cases]
"Service Function Chaining Use Cases In Data Centers",
January 2015.
Authors' Addresses
Dapeng Liu
Alibaba Group
Beijing
China
Phone: +86-13911788933
Email: maxpassion@gmail.com
Jie Cao
Alibaba Group
Hangzhou
China
Liu & Cao Expires January 6, 2016 [Page 9]
