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]