Architecture and application scenario for fused service function chain
draft-dai-sfc-fused-architecture-and-scenario-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Jinyou Dai , Xueshun Wang , Jun Gao | ||
| Last updated | 2022-09-08 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dai-sfc-fused-architecture-and-scenario-03
Network Working Group J. Dai
INTERNET-DRAFT X. Wang
Intended Status: Informational J. Gao
Expires: March 08,2023 Fiberhome/CICT
September 08,2022
Architecture and application scenario for fused service function chain
draft-dai-sfc-fused-architecture-and-scenario-03
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 March 08,2023 [Page 1]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 2]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 3]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 4]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 5]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 6]
INTERNET DRAFT Architecture for fused SFC September 08,2022
- 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 March 08,2023 [Page 7]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 8]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 9]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 10]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 11]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 12]
INTERNET DRAFT Architecture for fused SFC September 08,2022
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 March 08,2023 [Page 13]
INTERNET DRAFT Architecture for fused SFC September 08,2022
- 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 March 08,2023 [Page 14]
INTERNET DRAFT Architecture for fused SFC September 08,2022
[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
Xueshun Wang
China Information Communication Technologies Group.
Gaoxin 4th Road 6#
Wuhan, Hubei 430079
China
Email: xswang@fiberhome.com
Dai, et al. Expires March 08,2023 [Page 15]
INTERNET DRAFT Architecture for fused SFC September 08,2022
Jun Gao
China Information Communication Technologies Group.
Gaoxin 4th Road 6#
Wuhan, Hubei 430079
China
Email: jgao@fiberhome.com
Dai, et al. Expires March 08,2023 [Page 16]