Network Working Group J. Dai INTERNET-DRAFT Fiberhome/CICT,PCL Intended Status: Informational S. Yu Expires: December 28, 2024 PCL X. Wang J. Gao Fiberhome/CICT June 28, 2024 Architecture and application scenario for fused service function chain draft-dai-sfc-fused-architecture-and-scenario-06 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, control plane and management plane. Fused service function chain is an expansion for general 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 based on architecture described in this memo. 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, 2024 [Page 1] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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 to cooperate. These include traditional network service functions such as firewalls and traditional IP Network Address Dai, et al. Expires December 28, 2024 [Page 2] INTERNET DRAFT Architecture for fused SFC June 28, 2024 Translators (NATs),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, 2024 [Page 3] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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, control plane and management plane. For example, when an enterprise network includes two or more physically separated sub-networks, it is possible to deploy two correlated service function chains in the two or more independent sub-networks respectively. However, logically and functionally, the two or more 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 chains 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,control plane and management plane. That is to say, data packet can be steered through all selected SFs within the Dai, et al. Expires December 28, 2024 [Page 4] INTERNET DRAFT Architecture for fused SFC June 28, 2024 F-SFC 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, 2024 [Page 5] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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, 2024 [Page 6] INTERNET DRAFT Architecture for fused SFC June 28, 2024 - 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, 2024 [Page 7] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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, 2024 [Page 8] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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, 2024 [Page 9] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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, 2024 [Page 10] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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, 2024 [Page 11] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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, 2024 [Page 12] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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, 2024 [Page 13] INTERNET DRAFT Architecture for fused SFC June 28, 2024 - 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, 2024 [Page 14] INTERNET DRAFT Architecture for fused SFC June 28, 2024 [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: djy96@sina.com Shaohua Yu PCL. China Email: yush@cae.cn 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, 2024 [Page 15] INTERNET DRAFT Architecture for fused SFC June 28, 2024 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, 2024 [Page 16]