[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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]