Architecture and application scenario for fused service function chain
draft-dai-sfc-fused-architecture-and-scenario-01

Document Type Active Internet-Draft (individual)
Authors Jinyou Dai  , Xueshun Wang  , Jun Gao 
Last updated 2021-06-27
Stream (None)
Intended RFC status (None)
Formats pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                             J. Dai
INTERNET-DRAFT                                                   X. Wang
Intended Status: Informational                                    J. Gao
Expires:  December 28, 2021                                  Fiberhome/CICT                  
                                                        June 28, 2021

 Architecture and application scenario for fused service function chain 
            draft-dai-sfc-fused-architecture-and-scenario-01

    
Abstract

   This document discusses the architecture and application scenarios 
   of fused service function chain. Fused service function chain means  
   that two or more service function chains are fused to become a single
   service function chain from the view of data plane and control plane.
   Fused service function chain is a expansion for service function chain.
   Anyhow, some mechanism or methods need to be used when two or more   
   service function chains are fused to be a single service function     
   chain. 

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/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors. All rights reserved.

  
Dai, et al.              Expires December 28, 2021                 [Page 1]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   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 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.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1  Terminology . . . . . . . . . . . . . . . . . . . . . . . .  4
   2. Architecture of Fused Service Function Chain  . . . . . . . . .  4
     2.1. General Architecture for Fused Service Functional Chain . .  4
     2.2.  Interface in the Fused Service Function Chain  . . . . . .  6
     2.3.  OAM Architecture for Fused Service Function Chain  . . . .  6
   3  Application Scenarios of Fused Service Function Chain   . . . .  7
     3.1. F-SFC for Wide-area Enterprise Network  . . . . . . . . . .  7
     3.2. F-SFC in Cross-domain Scenario. . . . . . . . . . . . . . .  8
     3.3. SFC as a Service in Cloud. . . . . . . .  . . . . . . . . .  9
     3.4. F-SFC in Mobile Edge Computing. . . . . . . . . . . . . . . 10
     3.5. F-SFC in Distributed Active/Active Data Center. . . . . . . 11
     3.6. F-SFC in Network Function Virtualization Context. . . . . . 12
   4  Additional Requirements for Fused Service Function Chain. . . . 13
     4.1 Function Aspect. . . . . . . . . . . .  . . .  . . .  . . .  13
     4.2 Performance Aspect  . . . . . . . . .  . . . . . . .  . . .  13
     4.3 Control Aspect   . . . . . . .  . . .  . . . . . . . . . . . 13
     4.4 Management Aspect . . . . . . .  . . .  . . .  . . . . . . . 14
     4.5 Other Aspect  . . . . . . .  . . .  . . .  . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   6  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
   7  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 14
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1  Normative References  . . . . . . . . . . . . . . . . . . . 15
     8.2  Informative References  . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

1.  Introduction

   The delivery of end-to-end services often requires various service
   functions.  These include traditional network service functions such
   as firewalls and traditional IP Network Address Translators (NATs),

Dai, et al.              Expires December 28, 2021                 [Page 2]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   as well as application-specific functions.  The definition and
   instantiation of an ordered set of service functions and subsequent
   "steering" of traffic through them is termed Service Function
   Chaining (SFC).[RFC7665]. [RFC7498] describes the motive for 
   service function chain. 
   
    o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
      .  +--------------+                  +------------------~~~
      .  |   Service    |       SFC        |  Service  +---+   +---+
      .  |Classification|  Encapsulation   | Function  |sf1|...|sfn|
   +---->|   Function   |+---------------->|   Path    +---+   +---+
      .  +--------------+                  +------------------~~~
      . SFC-enabled Domain
    o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
   
        Figure 1: Architecture of service function chain
   
   RFC 7665 has also described a high-level logical architecture of an 
   SFC-enabled domain that can be seen in figure 1 (see also figure 2 
   of RFC 7665).

                        +------------+
                        |Subdomain#1 |
                        |  in DC1    |
                        +----+-------+
                             |
                     .---- SFF1 ------.   +----+
           +----+   /     /  |         \--|CF#4|
       --->|CF#1|--/---->'   |          \ +----+
           +----+ /  SC#1    |           \
                  |          |            |
                  |          V    .------>|--->
                  |         /    /        |
                   \         |   /        /
            +----+  \        |  /        /  +----+
            |CF#2|---\       | /        /---|CF#3|
            +----+    '---- SFF2 ------'    +----+
                             |
                        +----+-------+
                        |Subdomain#2 |
                        |   in DC2   |
                        +------------+
           Legend:
             SC#1: Service Chain 1
               DC: Data Center
    
   Figure 2: Architecture for hierarchical service function chain
   
  

Dai, et al.              Expires December 28, 2021                 [Page 3]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   There are many application scenarios that can use technologies or 
   methods related to service function chain. However, some 
   application scenarios have not yet been covered by RFC 7665.  

   RFC 8459 has illustrated the difficult problem of implementing SFC
   across a large, geographically dispersed network, potentially
   comprised of millions of hosts and thousands of network-forwarding
   elements and which may involve multiple operational teams (with
   varying functional responsibilities). The adaptive layout for such 
   circumstance is given in figure 2 (see also figure 1 of RFC 8459). 

   Hierarchical service function chain described in RFC 8459 is only 
   one of the application scenarios that have not been covered by 
   RFC 7665. Many other application scenarios that can be enhanced by
   service function chain can't yet be covered by RFC 8459. Then new 
   architecture and requirements are needed. 

   About some other application scenarios, there is also a need to fuse 
   two or more independent service function chains to Form a single 
   service function chain from the view of data plane and control plane. 

   For example, when an enterprise network includes two physically    
   separated sub-networks, it is possible to deploy two correlated 
   service function chains in the two independent sub-networks 
   respectively. However, logically and functionally, the two 
   correlated service function chains should be thought as an identical 
   service function chain.     

1.1  Terminology

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

2.  Architecture of Fused Service Function Chain

2.1.  General Architecture for Fused Service Functional Chain

   As is described in clause 1, there is a need to fuse two or more 
   service fucntion chain to form a single service chain when service
   function chain is applied in some application scenarios. the afore-
   mentioned single service function chain is called fused service   
   function chain (F-SFC).

   At first, a F-SFC is composed of two or more service function chains  
   that are logically independent each other and possibly seperate 
   physically. 
       
   Secondly, a F-SFC can be thought as a single service function chain
   from the view of data plane and management plane. That is to say, 
   data packet can be steered through all selected SFs within the F-SFC 

Dai, et al.              Expires December 28, 2021                 [Page 4]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   according to preset configuration. moreover, a F-SFC can be 
   managed by a management entity and the management entity can think 
   the F-SFC as an ordinary service function chain. 

   Thirdly, all service function chains within a F-SFC can still work 
   as an independent service function chain. In other words, if a F-SFC   
   consists of SFC A, SFC B and SFC C, SFCs with the F-SFC such as SFC  
   A can also be used as an independent if it is needed. 

      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 
      . +--------------+              +---------------------~~~
      . |   Service    |    SFC       |  Service   +----+    +----+
      . |Classification| Encapsulation| Function  |sf11|...|sf1n|
   +--->|   Function   |+------------>|   Path     +----+    +----+
      . +--------------+              +---------------------~~~
      . 
      .

      . +--------------+                +---------------------~~~
      . |   Service    |    SFC          |  Service  +----+   +----+
      . |Classification| Encapsulation| Function  |sf21|...|sf2m|
   +--->|   Function   |+-----^------>|   Path    +----+   +----+
     |. +--------------+      |         +---------------------~~~
     |      Bypass            |
     +------------------------+
   +--->......
      . +--------------+                +---------------------~~~
      . |   Service    |    SFC          |  Service   +----+   +----+
      . |Classification| Encapsulation| Function  |sfk1|...|sfkl|
   +--->|   Function   |+-----^------>|   Path      +----+   +----+
     |. +--------------+      |         +---------------------~~~
     |      Bypass            |
     +------------------------+
      . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 

   Figure 3: General architecture for fused service function chain

   Figure 3 describes a general architecture of F-SFC. From the figure,   
   it can be learned that the F-SFC is composed of SFC1, SFC2 ... and 
   SFCj. SFC1 consists SF11, SF12 ... and SF1n. SFC2 consists SF21, 
   SF22 ... and SF2m. ... SFCk consists SFk1, SFk2 ... and SFkl. 

   All SFs within SFC1, SFC2 ... and SFCj can be used by F-SFC. On the 
   one hand, SFs within SFC(i+1) should be used after SFs within SFC(i) 
   in order to keep the logical order of SFCs. On the other hand, SFs 
   within the same SFC should take action based on logical order of the 
   SFC.  

Dai, et al.              Expires December 28, 2021                 [Page 5]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   It is noted that all CFs (Classification Function) in SFC2 ... SFCk 
   can be configurated to work in By-pass mode in order that SFC2 ...  
   SFCk can action based on the result of the CF in SFC1. It is sure all
   CFs can also work in normal mode.        

2.2.  Interface in the Fused Service Function Chain

   It can also be learned from figure 3 that some interfaces are needed 
   to compose a F-SFC.  
  
   At first, a kind of interface between SFC(i) and SFC(i+1) need to be 
   deployed in order to connect SFC(i) and SFC(i+1) seamlessly.
   
   Secondly, some interfaces within SFC(i) are also necessary to 
   implement the F-SFC. For example, when CF in SFC(i) is by-passed, an   
   interface should be used to connect the ingress end of the CF and 
   the egress end of the CF.  

   Thirdly, there are some interfaces to be designed to connect F-SFC 
   and outside of the F-SFC. 

2.3.  OAM Architecture for Fused Service Function Chain

   2.3.1. Additional OAM Components

   RFC 8924 describes the OAM framework for service function chain. CF 
   component, SF component and SFC component are three main components 
   related to SFC OAM. 

   F-SFC is substantially different from ordinary SFC, so the 
   components related to OAM within F-SFC are also differnet from that 
   within an ordinary SFC. 

   All the afore-mentioned CF component, SF component and SFC component 
   are still effective in F-SFC. And there are three additional 
   components to be taken into account:
   
   - F-SFC components.

   - Interface components.

   - SFF components. 
   
   2.3.2. Additional OAM Functions 
   
   RFC 8924 also describes some OAM functions as follows:

   - Connectivity functions.
 

Dai, et al.              Expires December 28, 2021                 [Page 6]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   
   - Continuity functions.
   
   - Trace functions.

   - Performance measurement functions.
   
   There are some other OAM functions that are necessary to F-SFC such 
   as some functions described as follows.

   - Discovery function.

   - Service awareness function.  

3  Application Scenarios of Fused Service Function Chain
 
3.1. F-SFC for Wide-area Enterprise Network

                           Service Function Chain  A         
                       +---+      +---+      +---+ 
                       |SF1|      |SF2|  ... |SFm|  
        +------+       +---+      +---+      +---+   
        |      |         |          |          |              
        |Classi|       +-----+    +-----+    +-----+          
    --->|fier  |--->   | SFF1|----| SFF2|----| SFFn|         
        |      |       +-----+    +-----+    +-----+        
        +------+         
                          (~~~~~~~~~~)
                         (   Other    )
             -------->  (              )-------->
                         (  network   )
                          (          )
                           ~~~~~~~~~~
                        Service Function Chain  B         
                       +---+      +---+       +---+ 
                       |SF1|      |SF2|   ... |SFl|  
        +------+       +---+      +---+       +---+   
        |      |         |          |           |              
        |Classi|       +-----+    +-----+    +-----+          
    --->|fier  |--->   | SFF1|----| SFF2|----| SFFk|         
        |      |       +-----+    +-----+    +-----+        
        +------+         

  Figure 4: Logical structure for F-SFC in enterprise network

   The first typical application scenario of F-SFC is wide-area 
   enterface network. A large-scale enterprise often has two or 
   more parts seperated each other physically. Then, there are 
   also two or more physically 

Dai, et al.              Expires December 28, 2021                 [Page 7]

                      
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   seperated sub-networks that are owned by the same enterprise and 
   corresponding to those seperated parts of the enterprise. 

   For example, if an enterprise has part A located in city A and part 
   B located in city B, there is a sub-network A deployed in part A 
   meanwhile there is also a sub-network B deployed in part B.  
  
   It is possible that a SFC A is designed in sub-network A and a SFC B 
   is designed in sub-network B. However, some functions can be 
   implemented by co-operation of SFC A and SFC B. Coordination between 
   SFC A and SFC B can be realized by co-operation of management 
   entities for sub-network A and sub-network B. Nevertheless, it is a 
   better solution to use F-SFC.

   Figure 4 describes the logical structure for F-SFC in wide-area 
   enterprise network.     

3.2. F-SFC in Cross-domain Scenario

   +-------------------------------------------------+                                              
   |  Domain A       Service Function Chain  A       |   
   |                 +---+      +---+      +---+     |
   |                 |SF1|      |SF2|  ... |SFm|     |
   |     +------+    +---+      +---+      +---+     |
   |     |      |      |          |          |       |       
   |     |Classi|    +-----+    +-----+    +-----+   |       
   | --->|fier  |--->| SFF1|----| SFF2|----| SFFn|   |--->   
   |     |      |    +-----+    +-----+    +-----+   |     
   |     +------+                                    |
   +-------------------------------------------------+

       +-------------------------------------------------+                                           
       |    Domain B     Service Function Chain  A       |   
       |                 +---+      +---+      +---+     |
       |                 |SF1|      |SF2|  ... |SFm|     |
       |     +------+    +---+      +---+      +---+     |
       |     |      |      |          |          |       |       
       |     |Classi|    +-----+    +-----+    +-----+   |       
   --->| --->|fier  |--->| SFF1|----| SFF2|----| SFFn|   |   
       |     |      |    +-----+    +-----+    +-----+   |     
       |     +------+                                    |
       +-------------------------------------------------+

    Figure 5: Logical structure for F-SFC in cross-domained SFC
  
    Figure 5 describes another application scenario in which the two 
    SFCs to be fused belong to two different network domains. Although 
    the two SFCs are in different network domains, they can be 
    deployed in the same physical location.

Dai, et al.              Expires December 28, 2021                 [Page 8]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

    
    For example, if SFC A is deployed in a ipv4 network domain, 
    meanwhile SFC B is in a Srv6 network domain. SFC A and SFC B can be 
    thought to be in different network domain.

    It is also possible for SFC A in network domain A and SFC B in 
    network domain B to be fused to a more powerful F-SFC.  
  
3.3. SFC as a Service in Cloud 

                          (~~~~~~~~~~~~~~~~~~~~~~~~~~)
                         (   +---+                    )
                        (    |SFi|     +---+           )
                       (     +---+     |SFj|            )
                      (                +---+             )
         +------+    (                                    )
         |Classi|   (                CLOUD                 )
                     (       +---+                        )
         |fier  |-->  (      |SFk|            +----+     )
         +------+      (     +---+            |... |    )
                        (            +----+   +----+   )
                         (           |SFFl|           )
                          (          +----+          )
                           (                        )
                            ~~~~~~~~~~~~~~~~~~~~~~~~
      Figure 6: Logical structure for F-SFC in SFCaaS

   With the development of the network function virtualization and 
   cloud computing, it will be a gerenal mode to realize some network 
   functions based on cloud. 
  
   On the other hand, some network functions should also be deployed 
   in SFC mode when the network functions are implemented by a series 
   of functional entities in order.

   In addition, it is a proper solution to implement some network 
   functions based on cloud mode and SFC mode. For example, realization 
   of big data pre-processing function needs more network resources and 
   would better be designed according to distributing mode. Many 
   functional entities in the network cloud can be used to finish part 
   or big data pre-processing function. However, those function entities 
   need to be organized as a SFC under some circumstances.

   SFC in cloud is called SFCaaS (SFC as a Service) in this document. 
   Figure 6 depicts the logical structure for SFCaaS. About SFCaaS, the 
   SFC components except CFs come from the cloud. 

Dai, et al.              Expires December 28, 2021                 [Page 9]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   SFCaaS relies on SFs and SFFs in the cloud, so it is not easy to 
   organize a SFC. Then, a network funciton will possibly be realized 
   by cooperation of a group of SFCs. Thus, F-SFC is a candidate 
   solution for this application scenario. 
     
3.4. F-SFC in Mobile Edge Computing
  
   At present, mobile edge computing (MEC) has become a hot research 
   point. Mobile edge computing is the result of convergence between 
   mobile network and Internet and it has expectable application 
   prospect. 

   Mobile edge computing focuses on making full use of the resources of
   the mobile network and internet of things. Because of diversity and 
   physical decentralization of the resources from mobile edge 
   computing,it is more complicated to organize the resources.

   If a network function is planned to be implemented by mobile edge 
   computing, many physical devices and many logical function entities
   are necessary to cooperate to finish the task. Under many 
   circumstanses, those physical devices or logical entities need to 
   work in order, then, service function chain is good solution for 
   such circumstances.

 
                              (~~~~~~~~~~~~~~~~~~~~~~~~~~)
                             (                            )
                            (                              )
                           (                                )
    +------+              (                                  )
    |Classi| --------->  (              Cloud                 )
    |fier  |              (                                  )
    +------+               (                                )
                            (                              )
                             (                            )
                              (                          )
                               (                        )
                                ~/~~~~~~~~~~~~~~~~~~\~~~
                                /                    \
                               /                      \
     (~~~~~~~~~~~~~~~~~~~~~~~~~~)       (~~~~~~~~~~~~~~~~~~~~~~~~)
    ( |SF1i| |SFF1j| ...|SF1k|   )     (|SF2i| |SFF2j| ...|SF2k|  )
   (  +----+ +-----+    +----+    )   ( +----+ +-----+    +----+   )
  (            Edge                ) ..(           Edge             )
   (   +----+ +-----+             )    (   +----+  +-----+         )
    (  |SF1m| |SFF1n|  |... |    )      (  |SF2m|  |SFF2n|  |... |)
     (                          )         (                      )
      ~~~~~~~~~~~~~~~~~~~~~~~~~~           ~~~~~~~~~~~~~~~~~~~~~~

          Figure 7: Logical structure for F-SFC in MEC

Dai, et al.              Expires December 28, 2021                [Page 10]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

     
   As physical devices or logical entities are physically decentralized, 
   it is possible that two or more service function chain are needed to 
   realize a certain network function, then, F-SFC is a appropriate 
   solution. 

   Figure 7 describes logical structure for F-SFC in MEC. In figure 7, 
   all or partial SFs and SFFs of the service function chain are 
   deployed at the edge. In the meantime, two or more service function 
   chains are dsigned in the mobile network or the network edge. Those 
   service function chains should be merged to a single service 
   function chain.

3.5 F-SFC in Distributed Active/Active Data Center

   Another candidate application scenario for F-SFC is active/active 
   data center.

   If multiple and distributed data centers are designed and deployed
   according active/active mode, advantages are obvious. At first, 
   the idleness of a data center is avoided so that network resources
   can be made full use. Secondly, when one data center is out of 
   order, there is no obvious negative influence to the user of the 
   data center.

   When service function chain is applied in active/active data center,
   F-SFC is also a appropriate solution. It is essential to deploy a 
   single service function chain in every data center. It is not a good
   design to control and manage the service function chains 
   respectively. So It is a better solution to fuse the service 
   function chains
    

                     |        (~~~~~~~~~~~~~~~~~~~~~~~~)
                     |       (|SFAi| |SFFAj| ...|SFAk|  )
                     |      ( +----+ +-----+    +----+   )
                     |---- (                              )
                     |      (   +----+  +-----+          )
                     |       (  |SFAm|  |SFFAn|  |... | )
     +------+        |        (                        )
     |Classi| ------>|         ~~~~~~~~~~~~~~~~~~~~~~~~
     |fier  |        |
     +------+        |         (~~~~~~~~~~~~~~~~~~~~~~~~~~)         
                     |        (|SFBi| |SFFBj| ...|SFBk|    )
                     |       (  +----+ +-----+    +----+    )
                     |----  (                               )
                     |       (   +----+ +-----+             )
                     |        (  |SFBm| |SFFBn|  |... |    ) 
                     |         (                          )  
                     |          ~~~~~~~~~~~~~~~~~~~~~~~~~~   

     Figure 8: Logical structure for F-SFC in Active/Active DC
                
               

Dai, et al.              Expires December 28, 2021                [Page 11]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   to form a single service fucntion chain.

   Figure 8 describes the logical structure for F-SFC applied in 
   distributed active/active data center.In the figure, there are many
   SFs and SFFs designed in every data center, F-SFC can fuse those SFs
   and SFFs with the outside CF to form a integrated service function 
   chain. 

3.6 F-SFC in Network Function Virtualization Context 
                                                      
   Network function virtualization context is also proper for F-SFC. 
   When a service function chain is deployed in NFV context, SFs and 
   SFFs can be implemented based on VMs(Virtual Machine). VMs can be 
   designed in different servers, so VMs are physically discentralized. 
   On the other hand, a VM can migrate from one server to another, it 
   causes that management of the VMs become more difficult. When SFs 
   or SFFs are realized by VMs, SFs or SFFs would also be 
   discentralized and can be migrated from one server to another, 
   then, organization of a service function chain in NFC context is 
   also difficult.
 
   When it is necessary for two or more service function chains in NFV
   context to cooperate to realize a network function, it is also not 
   a good design to organize the service function chains seperately. 
   In reality, F-SFC is a better solution under such circumstance.

  
                              +----------+
                              |Classifier| 
                              +----------+
                                   |   
                       ----------------------------
                          |                  |
    +----------------------------+      +--------------------------+
    |Server A                    |      |Server B                  |  
    | +----+ +-----+    +----    |      |+----+ +-----+    +----+  |
    | |vSFi| |vSFFj| ...|vSFk|   |      ||vSFl| |vSFFo| ...|vSFp|  |
    | +----+ +-----+    +----+   |      |+----+ +-----+    +----+  |
    |                            |  ... |                          |
    |  +----+ +-----+  +----+    |      |  +----+  +-----+  +----+ |
    |  |vSFm| |vSFFn|  |... |    |      |  |vSFq|  |vSFFh|  |... | |
    |  +----+ +-----+  +----+    |      |  +----+  +-----+  +----+ |
    |                            |      |                          |     
    +----------------------------+      +--------------------------+
       
         Figure 9: Logical structure for F-SFC in NFC         
 
   Figure 9 describes such application scenario. In figure 9, SFs are 

Dai, et al.              Expires December 28, 2021                [Page 12]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

     
   realized by VMs and called vSFs, and SFFs are realized by VMs and 
   called vSFFs. vSFs and vSFFs can be organized to form two or more 
   service function chains. Multiple service fucntion chains can be 
   fused to be a single service chain.  

4  Additional Requirements for Fused Service Function Chain 

   When two or more service function chains are fused to form a single
   service function chain, there are some new requirements to be taken
   into account while comparing to the general service fucntion chain.

   There are several aspects related to the additional requirements, 
   the following are those aspects:
   
   - Function aspect.

   - Performance aspect.

   - Control aspect.

   - Management aspect.
 
   - Other aspect.  

4.1 Function Aspect

   Additional functional requirement can be specified as follows:
   
   - F-SFC shall support all capability that every member service 
   function chain can support.   
    
   - F-SFC should support flow-control function between adjacent member
   service function chains.  

4.2 Performance Aspect

   Additional performance requirement can be specified as follows:
   
   - The throughtoutput of F-SFC is requiremed to be not less than the
   minimum of throughoutputs of the member service function chains. 
   
   - The packet loss rate of F-SFC is requiremed to be not greater 
   than the maximum of packet loss rate of the member service function
   chains.

4.3 Control Aspect

   - F-SFC should support the capability to enable/disable CFs in every
   member service chain.

  

Dai, et al.              Expires December 28, 2021                [Page 13]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

     
   - F-SFC should support the capability to re-structure according to 
   the requirement of the specific network funtion.

4.4 Management Aspect

   - F-SFC shall support the capability to manage all member service 
   chains unifiedly.

4.5 Other Aspect

   - F-SFC should support the capability to aware network context 
   between adjacent member service fucntion chains.

5.  Security Considerations

   The security considerations described throughout [RFC7665] and  
   [RFC8300] apply here as well.

   Additionally, when a data packet is forwarded from SFC(i) to 
   SFC(i+1), the path between SFC(i) to SFC(i+1) should provide 
   mechanism to guarantee security of the data packet.
   
   Moreever, when the CF in SFC(i) is by-passed, it should be assured 
   that the bu-passed path has the same security support as the CF.

6  IANA Considerations

   This document has no IANA requirements.
 
7  Acknowledgements

   This document is written by referring to [RFC7665] authored by J. 
   Halpern and C, Pignataro and [RFC8924] authored by S. Aldrin, C. 
   Pignataro, N. Kumar, R. Krishnan and A. Ghanwani. 

   Many thanks to all the afore-mentioned editors and authors.

8  References

8.1  Normative References
              
              [RFC7665]   J. Halpern and  C. Pignataro, "Service 
              Function Chaining (SFC) Architecture", RFC 7665, October
              2015.

              [RFC8300]  P. Quinn, U. Elzur and C. Pignataro, "Network
              Service Header (NSH)",   RFC 8300, January 2018.

 

Dai, et al.              Expires December 28, 2021                [Page 14]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

     
              [RFC8459]  D. Dolson, S. Homma, D. Lopez and M. Boucadair 
              "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 
              September 2018.

              [RFC8924]  S. Aldrin, C. Pignataro, N. Kumar, R. Krishnan
              and A. Ghanwani, "Service Function Chaining (SFC) 
              Operations, Administration, and Maintenance (OAM) 
              Framework", RFC 8924, October 2020.          

8.2  Informative References

              [RFC2119]  S. Bradner, "Key words for use in RFCs to 
              Indicate Requirement Levels", RFC 2119, March 1997.

              [RFC7498]  P. Quinn and T. Nadeau, "Problem Statement for 
              Service Function Chaining", RFC 7468, April 2015.

              [RFC8393]  A. Farrel and J. Drake, "Operating the Network 
              Service Header (NSH) with Next Protocol 'None'", RFC 8393, 
              May 2018.

              [I-D.ietf-sfc-multi-layer-oam]      G. Mirsky, W. Meng, B. 
              Khasnabish and C. Wang, "Active OAM for Service Function 
              Chains in Networks", draft-ietf-sfc-multi-layer-oam-07, 
              December 2020.

Authors' Addresses

   Jinyou Dai
      China Information Communication Technologies Group.
      Gaoxin 4th Road 6#
      Wuhan, Hubei 430079
      China

      Email: djy@fiberhome.com

   Xueshun Wang
      China Information Communication Technologies Group.
      Gaoxin 4th Road 6#
      Wuhan, Hubei 430079
      China

      Email: xswang@fiberhome.com

   

Dai, et al.              Expires December 28, 2021                [Page 15]
INTERNET DRAFT     Architecture for fused SFC   June 28, 2021

   Jun Gao
      China Information Communication Technologies Group.
      Gaoxin 4th Road 6#
      Wuhan, Hubei 430079
      China
 
      Email: jgao@fiberhome.com

Dai, et al.              Expires December 28, 2021                [Page 16]