Use Case of Hierarchical Service Function Chaining

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. 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. 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 tenant but it may have different policies. For example, the traffic between users may have higher priority compared with the traffic for advertisement. 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. 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.

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.

Figure 2:Inter-DC SFC in distributed DCs network

: 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.

[ 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

[ 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