idnits 2.17.00 (12 Aug 2021) /tmp/idnits33008/draft-dai-sfc-fused-architecture-and-scenario-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC8459' is defined on line 675, but no explicit reference was found in the text == Unused Reference: 'RFC8393' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-sfc-multi-layer-oam' is defined on line 696, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-sfc-multi-layer-oam-07 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Dai 3 INTERNET-DRAFT X. Wang 4 Intended Status: Informational J. Gao 5 Expires: July 26,2022 Fiberhome/CICT 6 January 26,2022 8 Architecture and application scenario for fused service function chain 9 draft-dai-sfc-fused-architecture-and-scenario-02 11 Abstract 13 This document discusses the architecture and application scenarios 14 of fused service function chain. Fused service function chain means 15 that two or more service function chains are fused to become a single 16 service function chain from the view of data plane and control plane. 17 Fused service function chain is a expansion for service function chain. 18 Anyhow, some mechanism or methods need to be used when two or more 19 service function chains are fused to be a single service function 20 chain based on architecture described in this memo. 22 Status of this Memo 24 This Internet-Draft is submitted to IETF in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with 51 respect to this document. Code Components extracted from this 52 document must include Simplified BSD License text as described in 53 Section 4.e of the Trust Legal Provisions and are provided without 54 warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 60 2. Architecture of Fused Service Function Chain . . . . . . . . . 4 61 2.1. General Architecture for Fused Service Functional Chain . . 4 62 2.2. Interface in the Fused Service Function Chain . . . . . . 6 63 2.3. OAM Architecture for Fused Service Function Chain . . . . 6 64 3 Application Scenarios of Fused Service Function Chain . . . . 7 65 3.1. F-SFC for Wide-area Enterprise Network . . . . . . . . . . 7 66 3.2. F-SFC in Cross-domain Scenario. . . . . . . . . . . . . . . 8 67 3.3. SFC as a Service in Cloud. . . . . . . . . . . . . . . . . 9 68 3.4. F-SFC in Mobile Edge Computing. . . . . . . . . . . . . . . 10 69 3.5. F-SFC in Distributed Active/Active Data Center. . . . . . . 11 70 3.6. F-SFC in Network Function Virtualization Context. . . . . . 12 71 4 Additional Requirements for Fused Service Function Chain. . . . 13 72 4.1 Function Aspect. . . . . . . . . . . . . . . . . . . . . 13 73 4.2 Performance Aspect . . . . . . . . . . . . . . . . . . . 13 74 4.3 Control Aspect . . . . . . . . . . . . . . . . . . . . . 13 75 4.4 Management Aspect . . . . . . . . . . . . . . . . . . . . 14 76 4.5 Other Aspect . . . . . . . . . . . . . . . . . . . . . . 14 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 79 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 80 8 References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 81 8.1 Normative References . . . . . . . . . . . . . . . . . . . 15 82 8.2 Informative References . . . . . . . . . . . . . . . . . . 15 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 The delivery of end-to-end services often requires various service 88 functions. These include traditional network service functions such 89 as firewalls and traditional IP Network Address Translators (NATs), 90 as well as application-specific functions. The definition and 91 instantiation of an ordered set of service functions and subsequent 92 "steering" of traffic through them is termed Service Function 93 Chaining (SFC).[RFC7665]. [RFC7498] describes the motive for 94 service function chain. 96 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 . +--------------+ +------------------~~~ 98 . | Service | SFC | Service +---+ +---+ 99 . |Classification| Encapsulation | Function |sf1|...|sfn| 100 +---->| Function |+---------------->| Path +---+ +---+ 101 . +--------------+ +------------------~~~ 102 . SFC-enabled Domain 103 o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 Figure 1: Architecture of service function chain 107 RFC 7665 has also described a high-level logical architecture of an 108 SFC-enabled domain that can be seen in figure 1 (see also figure 2 109 of RFC 7665). 111 +------------+ 112 |Subdomain#1 | 113 | in DC1 | 114 +----+-------+ 115 | 116 .---- SFF1 ------. +----+ 117 +----+ / / | \--|CF#4| 118 --->|CF#1|--/---->' | \ +----+ 119 +----+ / SC#1 | \ 120 | | | 121 | V .------>|---> 122 | / / | 123 \ | / / 124 +----+ \ | / / +----+ 125 |CF#2|---\ | / /---|CF#3| 126 +----+ '---- SFF2 ------' +----+ 127 | 128 +----+-------+ 129 |Subdomain#2 | 130 | in DC2 | 131 +------------+ 132 Legend: 133 SC#1: Service Chain 1 134 DC: Data Center 136 Figure 2: Architecture for hierarchical service function chain 137 There are many application scenarios that can use technologies or 138 methods related to service function chain. However, some 139 application scenarios have not yet been covered by RFC 7665. 141 RFC 8459 has illustrated the difficult problem of implementing SFC 142 across a large, geographically dispersed network, potentially 143 comprised of millions of hosts and thousands of network-forwarding 144 elements and which may involve multiple operational teams (with 145 varying functional responsibilities). The adaptive layout for such 146 circumstance is given in figure 2 (see also figure 1 of RFC 8459). 148 Hierarchical service function chain described in RFC 8459 is only 149 one of the application scenarios that have not been covered by 150 RFC 7665. Many other application scenarios that can be enhanced by 151 service function chain can't yet be covered by RFC 8459. Then new 152 architecture and requirements are needed. 154 About some other application scenarios, there is also a need to fuse 155 two or more independent service function chains to Form a single 156 service function chain from the view of data plane and control plane. 158 For example, when an enterprise network includes two or more physically 159 separated sub-networks, it is possible to deploy two correlated 160 service function chains in the two or more independent sub-networks 161 respectively. However, logically and functionally, the two or more 162 correlated service function chains should be thought as an identical 163 service function chain. 165 1.1 Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in RFC 2119 [RFC2119]. 171 2. Architecture of Fused Service Function Chain 173 2.1. General Architecture for Fused Service Functional Chain 175 As is described in clause 1, there is a need to fuse two or more 176 service fucntion chains to form a single service chain when service 177 function chain is applied in some application scenarios. the afore- 178 mentioned single service function chain is called fused service 179 function chain (F-SFC). 181 At first, a F-SFC is composed of two or more service function chains 182 that are logically independent each other and possibly seperate 183 physically. 185 Secondly, a F-SFC can be thought as a single service function chain 186 from the view of data plane,control plane and management plane. That is 187 to say, data packet can be steered through all selected SFs within the 188 F-SFC according to preset configuration. moreover, a F-SFC can be 189 managed by a management entity and the management entity can think 190 the F-SFC as an ordinary service function chain. 192 Thirdly, all service function chains within a F-SFC can still work 193 as an independent service function chain. In other words, if a F-SFC 194 consists of SFC A, SFC B and SFC C, SFCs with the F-SFC such as SFC 195 A can also be used as an independent if it is needed. 197 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 . +--------------+ +---------------------~~~ 199 . | Service | SFC | Service +----+ +----+ 200 . |Classification| Encapsulation| Function |sf11|...|sf1n| 201 +--->| Function |+------------>| Path +----+ +----+ 202 . +--------------+ +---------------------~~~ 203 . 204 . 206 . +--------------+ +---------------------~~~ 207 . | Service | SFC | Service +----+ +----+ 208 . |Classification| Encapsulation| Function |sf21|...|sf2m| 209 +--->| Function |+-----^------>| Path +----+ +----+ 210 |. +--------------+ | +---------------------~~~ 211 | Bypass | 212 +------------------------+ 213 +--->...... 214 . +--------------+ +---------------------~~~ 215 . | Service | SFC | Service +----+ +----+ 216 . |Classification| Encapsulation| Function |sfk1|...|sfkl| 217 +--->| Function |+-----^------>| Path +----+ +----+ 218 |. +--------------+ | +---------------------~~~ 219 | Bypass | 220 +------------------------+ 221 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223 Figure 3: General architecture for fused service function chain 225 Figure 3 describes a general architecture of F-SFC. From the figure, 226 it can be learned that the F-SFC is composed of SFC1, SFC2 ... and 227 SFCj. SFC1 consists SF11, SF12 ... and SF1n. SFC2 consists SF21, 228 SF22 ... and SF2m. ... SFCk consists SFk1, SFk2 ... and SFkl. 230 All SFs within SFC1, SFC2 ... and SFCj can be used by F-SFC. On the 231 one hand, SFs within SFC(i+1) should be used after SFs within SFC(i) 232 in order to keep the logical order of SFCs. On the other hand, SFs 233 within the same SFC should take action based on logical order of the 234 SFC. 236 It is noted that all CFs (Classification Function) in SFC2 ... SFCk 237 can be configurated to work in By-pass mode in order that SFC2 ... 238 SFCk can action based on the result of the CF in SFC1. It is sure all 239 CFs can also work in normal mode. 241 2.2. Interface in the Fused Service Function Chain 243 It can also be learned from figure 3 that some interfaces are needed 244 to compose a F-SFC. 246 At first, a kind of interface between SFC(i) and SFC(i+1) need to be 247 deployed in order to connect SFC(i) and SFC(i+1) seamlessly. 249 Secondly, some interfaces within SFC(i) are also necessary to 250 implement the F-SFC. For example, when CF in SFC(i) is by-passed, an 251 interface should be used to connect the ingress end of the CF and 252 the egress end of the CF. 254 Thirdly, there are some interfaces to be designed to connect F-SFC 255 and outside of the F-SFC. 257 2.3. OAM Architecture for Fused Service Function Chain 259 2.3.1. Additional OAM Components 261 RFC 8924 describes the OAM framework for service function chain. CF 262 component, SF component and SFC component are three main components 263 related to SFC OAM. 265 F-SFC is substantially different from ordinary SFC, so the 266 components related to OAM within F-SFC are also differnet from that 267 within an ordinary SFC. 269 All the afore-mentioned CF component, SF component and SFC component 270 are still effective in F-SFC. And there are three additional 271 components to be taken into account: 273 - F-SFC components. 275 - Interface components. 277 - SFF components. 279 2.3.2. Additional OAM Functions 281 RFC 8924 also describes some OAM functions as follows: 283 - Connectivity functions. 285 - Continuity functions. 287 - Trace functions. 289 - Performance measurement functions. 291 There are some other OAM functions that are necessary to F-SFC such 292 as some functions described as follows. 294 - Discovery function. 296 - Service awareness function. 298 3 Application Scenarios of Fused Service Function Chain 300 3.1. F-SFC for Wide-area Enterprise Network 302 Service Function Chain A 303 +---+ +---+ +---+ 304 |SF1| |SF2| ... |SFm| 305 +------+ +---+ +---+ +---+ 306 | | | | | 307 |Classi| +-----+ +-----+ +-----+ 308 --->|fier |---> | SFF1|----| SFF2|----| SFFn| 309 | | +-----+ +-----+ +-----+ 310 +------+ 311 (~~~~~~~~~~) 312 ( Other ) 313 --------> ( )--------> 314 ( network ) 315 ( ) 316 ~~~~~~~~~~ 317 Service Function Chain B 318 +---+ +---+ +---+ 319 |SF1| |SF2| ... |SFl| 320 +------+ +---+ +---+ +---+ 321 | | | | | 322 |Classi| +-----+ +-----+ +-----+ 323 --->|fier |---> | SFF1|----| SFF2|----| SFFk| 324 | | +-----+ +-----+ +-----+ 325 +------+ 327 Figure 4: Logical structure for F-SFC in enterprise network 329 The first typical application scenario of F-SFC is wide-area 330 enterface network. A large-scale enterprise often has two or 331 more parts seperated each other physically. Then, there are 332 also two or more physically 333 seperated sub-networks that are owned by the same enterprise and 334 corresponding to those seperated parts of the enterprise. 336 For example, if an enterprise has part A located in city A and part 337 B located in city B, there is a sub-network A deployed in part A 338 meanwhile there is also a sub-network B deployed in part B. 340 It is possible that a SFC A is designed in sub-network A and a SFC B 341 is designed in sub-network B. However, some functions can be 342 implemented by co-operation of SFC A and SFC B. Coordination between 343 SFC A and SFC B can be realized by co-operation of management 344 entities for sub-network A and sub-network B. Nevertheless, it is a 345 better solution to use F-SFC. 347 Figure 4 describes the logical structure for F-SFC in wide-area 348 enterprise network. 350 3.2. F-SFC in Cross-domain Scenario 352 +-------------------------------------------------+ 353 | Domain A Service Function Chain A | 354 | +---+ +---+ +---+ | 355 | |SF1| |SF2| ... |SFm| | 356 | +------+ +---+ +---+ +---+ | 357 | | | | | | | 358 | |Classi| +-----+ +-----+ +-----+ | 359 | --->|fier |--->| SFF1|----| SFF2|----| SFFn| |---> 360 | | | +-----+ +-----+ +-----+ | 361 | +------+ | 362 +-------------------------------------------------+ 364 +-------------------------------------------------+ 365 | Domain B Service Function Chain A | 366 | +---+ +---+ +---+ | 367 | |SF1| |SF2| ... |SFm| | 368 | +------+ +---+ +---+ +---+ | 369 | | | | | | | 370 | |Classi| +-----+ +-----+ +-----+ | 371 --->| --->|fier |--->| SFF1|----| SFF2|----| SFFn| | 372 | | | +-----+ +-----+ +-----+ | 373 | +------+ | 374 +-------------------------------------------------+ 376 Figure 5: Logical structure for F-SFC in cross-domained SFC 378 Figure 5 describes another application scenario in which the two 379 SFCs to be fused belong to two different network domains. Although 380 the two SFCs are in different network domains, they can be 381 deployed in the same physical location. 383 For example, if SFC A is deployed in a ipv4 network domain, 384 meanwhile SFC B is in a Srv6 network domain. SFC A and SFC B can be 385 thought to be in different network domain. 387 It is also possible for SFC A in network domain A and SFC B in 388 network domain B to be fused to a more powerful F-SFC. 390 3.3. SFC as a Service in Cloud 392 (~~~~~~~~~~~~~~~~~~~~~~~~~~) 393 ( +---+ ) 394 ( |SFi| +---+ ) 395 ( +---+ |SFj| ) 396 ( +---+ ) 397 +------+ ( ) 398 |Classi| ( CLOUD ) 399 ( +---+ ) 400 |fier |--> ( |SFk| +----+ ) 401 +------+ ( +---+ |... | ) 402 ( +----+ +----+ ) 403 ( |SFFl| ) 404 ( +----+ ) 405 ( ) 406 ~~~~~~~~~~~~~~~~~~~~~~~~ 407 Figure 6: Logical structure for F-SFC in SFCaaS 409 With the development of the network function virtualization and 410 cloud computing, it will be a gerenal mode to realize some network 411 functions based on cloud. 413 On the other hand, some network functions should also be deployed 414 in SFC mode when the network functions are implemented by a series 415 of functional entities in order. 417 In addition, it is a proper solution to implement some network 418 functions based on cloud mode and SFC mode. For example, realization 419 of big data pre-processing function needs more network resources and 420 would better be designed according to distributing mode. Many 421 functional entities in the network cloud can be used to finish part 422 or big data pre-processing function. However, those function entities 423 need to be organized as a SFC under some circumstances. 425 SFC in cloud is called SFCaaS (SFC as a Service) in this document. 426 Figure 6 depicts the logical structure for SFCaaS. About SFCaaS, the 427 SFC components except CFs come from the cloud. 429 SFCaaS relies on SFs and SFFs in the cloud, so it is not easy to 430 organize a SFC. Then, a network funciton will possibly be realized 431 by cooperation of a group of SFCs. Thus, F-SFC is a candidate 432 solution for this application scenario. 434 3.4. F-SFC in Mobile Edge Computing 436 At present, mobile edge computing (MEC) has become a hot research 437 point. Mobile edge computing is the result of convergence between 438 mobile network and Internet and it has expectable application 439 prospect. 441 Mobile edge computing focuses on making full use of the resources of 442 the mobile network and internet of things. Because of diversity and 443 physical decentralization of the resources from mobile edge 444 computing,it is more complicated to organize the resources. 446 If a network function is planned to be implemented by mobile edge 447 computing, many physical devices and many logical function entities 448 are necessary to cooperate to finish the task. Under many 449 circumstanses, those physical devices or logical entities need to 450 work in order, then, service function chain is good solution for 451 such circumstances. 453 (~~~~~~~~~~~~~~~~~~~~~~~~~~) 454 ( ) 455 ( ) 456 ( ) 457 +------+ ( ) 458 |Classi| ---------> ( Cloud ) 459 |fier | ( ) 460 +------+ ( ) 461 ( ) 462 ( ) 463 ( ) 464 ( ) 465 ~/~~~~~~~~~~~~~~~~~~\~~~ 466 / \ 467 / \ 468 (~~~~~~~~~~~~~~~~~~~~~~~~~~) (~~~~~~~~~~~~~~~~~~~~~~~~) 469 ( |SF1i| |SFF1j| ...|SF1k| ) (|SF2i| |SFF2j| ...|SF2k| ) 470 ( +----+ +-----+ +----+ ) ( +----+ +-----+ +----+ ) 471 ( Edge ) ..( Edge ) 472 ( +----+ +-----+ ) ( +----+ +-----+ ) 473 ( |SF1m| |SFF1n| |... | ) ( |SF2m| |SFF2n| |... |) 474 ( ) ( ) 475 ~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~ 477 Figure 7: Logical structure for F-SFC in MEC 479 As physical devices or logical entities are physically decentralized, 480 it is possible that two or more service function chain are needed to 481 realize a certain network function, then, F-SFC is a appropriate 482 solution. 484 Figure 7 describes logical structure for F-SFC in MEC. In figure 7, 485 all or partial SFs and SFFs of the service function chain are 486 deployed at the edge. In the meantime, two or more service function 487 chains are dsigned in the mobile network or the network edge. Those 488 service function chains should be merged to a single service 489 function chain. 491 3.5 F-SFC in Distributed Active/Active Data Center 493 Another candidate application scenario for F-SFC is active/active 494 data center. 496 If multiple and distributed data centers are designed and deployed 497 according active/active mode, advantages are obvious. At first, 498 the idleness of a data center is avoided so that network resources 499 can be made full use. Secondly, when one data center is out of 500 order, there is no obvious negative influence to the user of the 501 data center. 503 When service function chain is applied in active/active data center, 504 F-SFC is also a appropriate solution. It is essential to deploy a 505 single service function chain in every data center. It is not a good 506 design to control and manage the service function chains 507 respectively. So It is a better solution to fuse the service 508 function chains 510 | (~~~~~~~~~~~~~~~~~~~~~~~~) 511 | (|SFAi| |SFFAj| ...|SFAk| ) 512 | ( +----+ +-----+ +----+ ) 513 |---- ( ) 514 | ( +----+ +-----+ ) 515 | ( |SFAm| |SFFAn| |... | ) 516 +------+ | ( ) 517 |Classi| ------>| ~~~~~~~~~~~~~~~~~~~~~~~~ 518 |fier | | 519 +------+ | (~~~~~~~~~~~~~~~~~~~~~~~~~~) 520 | (|SFBi| |SFFBj| ...|SFBk| ) 521 | ( +----+ +-----+ +----+ ) 522 |---- ( ) 523 | ( +----+ +-----+ ) 524 | ( |SFBm| |SFFBn| |... | ) 525 | ( ) 526 | ~~~~~~~~~~~~~~~~~~~~~~~~~~ 528 Figure 8: Logical structure for F-SFC in Active/Active DC 530 to form a single service fucntion chain. 532 Figure 8 describes the logical structure for F-SFC applied in 533 distributed active/active data center.In the figure, there are many 534 SFs and SFFs designed in every data center, F-SFC can fuse those SFs 535 and SFFs with the outside CF to form a integrated service function 536 chain. 538 3.6 F-SFC in Network Function Virtualization Context 540 Network function virtualization context is also proper for F-SFC. 541 When a service function chain is deployed in NFV context, SFs and 542 SFFs can be implemented based on VMs(Virtual Machine). VMs can be 543 designed in different servers, so VMs are physically discentralized. 544 On the other hand, a VM can migrate from one server to another, it 545 causes that management of the VMs become more difficult. When SFs 546 or SFFs are realized by VMs, SFs or SFFs would also be 547 discentralized and can be migrated from one server to another, 548 then, organization of a service function chain in NFC context is 549 also difficult. 551 When it is necessary for two or more service function chains in NFV 552 context to cooperate to realize a network function, it is also not 553 a good design to organize the service function chains seperately. 554 In reality, F-SFC is a better solution under such circumstance. 556 +----------+ 557 |Classifier| 558 +----------+ 559 | 560 ---------------------------- 561 | | 562 +----------------------------+ +--------------------------+ 563 |Server A | |Server B | 564 | +----+ +-----+ +---- | |+----+ +-----+ +----+ | 565 | |vSFi| |vSFFj| ...|vSFk| | ||vSFl| |vSFFo| ...|vSFp| | 566 | +----+ +-----+ +----+ | |+----+ +-----+ +----+ | 567 | | ... | | 568 | +----+ +-----+ +----+ | | +----+ +-----+ +----+ | 569 | |vSFm| |vSFFn| |... | | | |vSFq| |vSFFh| |... | | 570 | +----+ +-----+ +----+ | | +----+ +-----+ +----+ | 571 | | | | 572 +----------------------------+ +--------------------------+ 574 Figure 9: Logical structure for F-SFC in NFC 576 Figure 9 describes such application scenario. In figure 9, SFs are 577 realized by VMs and called vSFs, and SFFs are realized by VMs and 578 called vSFFs. vSFs and vSFFs can be organized to form two or more 579 service function chains. Multiple service fucntion chains can be 580 fused to be a single service chain. 582 4 Additional Requirements for Fused Service Function Chain 584 When two or more service function chains are fused to form a single 585 service function chain, there are some new requirements to be taken 586 into account while comparing to the general service fucntion chain. 588 There are several aspects related to the additional requirements, 589 the following are those aspects: 591 - Function aspect. 593 - Performance aspect. 595 - Control aspect. 597 - Management aspect. 599 - Other aspect. 601 4.1 Function Aspect 603 Additional functional requirement can be specified as follows: 605 - F-SFC shall support all capability that every member service 606 function chain can support. 608 - F-SFC should support flow-control function between adjacent member 609 service function chains. 611 4.2 Performance Aspect 613 Additional performance requirement can be specified as follows: 615 - The throughtoutput of F-SFC is requiremed to be not less than the 616 minimum of throughoutputs of the member service function chains. 618 - The packet loss rate of F-SFC is requiremed to be not greater 619 than the maximum of packet loss rate of the member service function 620 chains. 622 4.3 Control Aspect 624 - F-SFC should support the capability to enable/disable CFs in every 625 member service chain. 627 - F-SFC should support the capability to re-structure according to 628 the requirement of the specific network funtion. 630 4.4 Management Aspect 632 - F-SFC shall support the capability to manage all member service 633 chains unifiedly. 635 4.5 Other Aspect 637 - F-SFC should support the capability to aware network context 638 between adjacent member service fucntion chains. 640 5. Security Considerations 642 The security considerations described throughout [RFC7665] and 643 [RFC8300] apply here as well. 645 Additionally, when a data packet is forwarded from SFC(i) to 646 SFC(i+1), the path between SFC(i) to SFC(i+1) should provide 647 mechanism to guarantee security of the data packet. 649 Moreever, when the CF in SFC(i) is by-passed, it should be assured 650 that the bu-passed path has the same security support as the CF. 652 6 IANA Considerations 654 This document has no IANA requirements. 656 7 Acknowledgements 658 This document is written by referring to [RFC7665] authored by J. 659 Halpern and C, Pignataro and [RFC8924] authored by S. Aldrin, C. 660 Pignataro, N. Kumar, R. Krishnan and A. Ghanwani. 662 Many thanks to all the afore-mentioned editors and authors. 664 8 References 666 8.1 Normative References 668 [RFC7665] J. Halpern and C. Pignataro, "Service 669 Function Chaining (SFC) Architecture", RFC 7665, October 670 2015. 672 [RFC8300] P. Quinn, U. Elzur and C. Pignataro, "Network 673 Service Header (NSH)", RFC 8300, January 2018. 675 [RFC8459] D. Dolson, S. Homma, D. Lopez and M. Boucadair 676 "Hierarchical Service Function Chaining (hSFC)", RFC 8459, 677 September 2018. 679 [RFC8924] S. Aldrin, C. Pignataro, N. Kumar, R. Krishnan 680 and A. Ghanwani, "Service Function Chaining (SFC) 681 Operations, Administration, and Maintenance (OAM) 682 Framework", RFC 8924, October 2020. 684 8.2 Informative References 686 [RFC2119] S. Bradner, "Key words for use in RFCs to 687 Indicate Requirement Levels", RFC 2119, March 1997. 689 [RFC7498] P. Quinn and T. Nadeau, "Problem Statement for 690 Service Function Chaining", RFC 7468, April 2015. 692 [RFC8393] A. Farrel and J. Drake, "Operating the Network 693 Service Header (NSH) with Next Protocol 'None'", RFC 8393, 694 May 2018. 696 [I-D.ietf-sfc-multi-layer-oam] G. Mirsky, W. Meng, B. 697 Khasnabish and C. Wang, "Active OAM for Service Function 698 Chains in Networks", draft-ietf-sfc-multi-layer-oam-07, 699 December 2020. 701 Authors' Addresses 703 Jinyou Dai 704 China Information Communication Technologies Group. 705 Gaoxin 4th Road 6# 706 Wuhan, Hubei 430079 707 China 709 Email: djy@fiberhome.com 711 Xueshun Wang 712 China Information Communication Technologies Group. 713 Gaoxin 4th Road 6# 714 Wuhan, Hubei 430079 715 China 717 Email: xswang@fiberhome.com 719 Jun Gao 720 China Information Communication Technologies Group. 721 Gaoxin 4th Road 6# 722 Wuhan, Hubei 430079 723 China 725 Email: jgao@fiberhome.com