idnits 2.17.00 (12 Aug 2021) /tmp/idnits33377/draft-bernardos-sfc-distributed-control-operation-04.txt: -(371): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(372): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(374): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(375): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(379): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(380): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(385): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(386): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(393): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(395): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(466): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(469): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(475): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(480): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(484): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(530): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(531): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(534): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(536): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(542): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(583): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(589): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(591): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(593): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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: ---------------------------------------------------------------------------- == There are 41 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 March 2022) is 54 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SFC WG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Experimental A. Mourad 5 Expires: 22 September 2022 InterDigital 6 21 March 2022 8 Distributed SFC control operation 9 draft-bernardos-sfc-distributed-control-operation-04 11 Abstract 13 Service function chaining (SFC) allows the instantiation of an 14 ordered set of service functions and subsequent "steering" of traffic 15 through them. In order to set up and maintain SFC instances, a 16 control plane is required, which typically is centralized. In 17 certain environments, such as fog computing ones, such centralized 18 control might not be feasible, calling for distributed SFC control 19 solutions. This document describes a general framework for 20 distributed SFC operation. 22 Status of This Memo 24 This Internet-Draft is submitted 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). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on 22 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Distributed SFC control operation . . . . . . . . . . . . . . 7 59 4.1. P-CTRL taking over C-CTRL . . . . . . . . . . . . . . . . 8 60 4.1.1. P-CTRL taking over C-CTRL due to a local monitoring 61 event . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.1.2. P-CTRL taking over C-CTRL due to a C-CTRL failure . . 10 63 4.1.3. C-CTRL gaining back control . . . . . . . . . . . . . 12 64 4.2. Inter P-CTRL seamless handover . . . . . . . . . . . . . 13 65 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 8.1. Normative References . . . . . . . . . . . . . . . . . . 14 70 8.2. Informative References . . . . . . . . . . . . . . . . . 14 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 73 1. Introduction 75 Virtualization of functions provides operators with tools to deploy 76 new services much faster, as compared to the traditional use of 77 monolithic and tightly integrated dedicated machinery. As a natural 78 next step, mobile network operators need to re-think how to evolve 79 their existing network infrastructures and how to deploy new ones to 80 address the challenges posed by the increasing customers' demands, as 81 well as by the huge competition among operators. All these changes 82 are triggering the need for a modification in the way operators and 83 infrastructure providers operate their networks, as they need to 84 significantly reduce the costs incurred in deploying a new service 85 and operating it. Some of the mechanisms that are being considered 86 and already adopted by operators include: sharing of network 87 infrastructure to reduce costs, virtualization of core servers 88 running in data centers as a way of supporting their load-aware 89 elastic dimensioning, and dynamic energy policies to reduce the 90 monthly electricity bill. However, this has proved to be tough to 91 put in practice, and not enough. Indeed, it is not easy to deploy 92 new mechanisms in a running operational network due to the high 93 dependency on proprietary (and sometime obscure) protocols and 94 interfaces, which are complex to manage and often require configuring 95 multiple devices in a decentralized way. 97 Service Functions are widely deployed and essential in many networks. 98 These Service Functions provide a range of features such as security, 99 WAN acceleration, and server load balancing. Service Functions may 100 be instantiated at different points in the network infrastructure 101 such as data center, the WAN, the RAN, and even on mobile nodes. 103 Service functions (SFs), also referred to as VNFs, or just functions, 104 are hosted on compute, storage and networking resources. The hosting 105 environment of a function is called Service Function Provider or 106 NFVI-PoP (using ETSI NFV terminology). 108 Services are typically formed as a composition of SFs (VNFs), with 109 each SF providing a specific function of the whole service. Services 110 also referred to as Network Services (NS), according to ETSI 111 terminology. 113 With the arrival of virtualization, the deployment model for service 114 function is evolving to one where the traffic is steered through the 115 functions wherever they are deployed (functions do not need to be 116 deployed in the traffic path anymore). For a given service, the 117 abstracted view of the required service functions and the order in 118 which they are to be applied is called a Service Function Chain 119 (SFC). An SFC is instantiated through selection of specific service 120 function instances on specific network nodes to form a service graph: 121 this is called a Service Function Path (SFP). The service functions 122 may be applied at any layer within the network protocol stack 123 (network layer, transport layer, application layer, etc.). 125 The concept of fog computing has emerged driven by the Internet of 126 Things (IoT) due to the need of handling the data generated from the 127 end-user devices. The term fog is referred to any networked 128 computational resource in the continuum between things and cloud. A 129 fog node may therefore be an infrastructure network node such as an 130 eNodeB or gNodeB, an edge server, a customer premises equipment 131 (CPE), or even a user equipment (UE) terminal node such as a laptop, 132 a smartphone, or a computing unit on-board a vehicle, robot or drone. 134 In fog computing, the functions composing an SFC are hosted on 135 resources that are inherently heterogeneous, volatile and mobile 136 [I-D.bernardos-sfc-fog-ran]. This means that resources might appear 137 and disappear, and the connectivity characteristics between these 138 resources may also change dynamically. These scenarios call for 139 distributed SFC control solutions, where there are SFC pseudo 140 controllers, enabling autonomous SFC self-orchestration capabilities. 141 The concept of SFC pseudo controller (P-CTRL) is described in 142 [I-D.bernardos-sfc-distributed-control], as well different procedures 143 for their discovery and initialization. 145 This document introduces a framework for local distributed SFC 146 operation, by allowing P-CTRLs to temporarily substitute the central 147 controller (C-CTRL) in its task to carry out the global lifecycle 148 management of the given SFC. 150 2. Terminology 152 The following terms used in this document are defined by the IETF in 153 [RFC7665]: 155 Service Function (SF): a function that is responsible for specific 156 treatment of received packets (e.g., firewall, load balancer). 158 Service Function Chain (SFC): for a given service, the abstracted 159 view of the required service functions and the order in which they 160 are to be applied. This is somehow equivalent to the Network 161 Function Forwarding Graph (NF-FG) at ETSI. 163 Service Function Forwarder (SFF): A service function forwarder is 164 responsible for forwarding traffic to one or more connected 165 service functions according to information carried in the SFC 166 encapsulation, as well as handling traffic coming back from the 167 SF. 169 SFI: SF instance. 171 Service Function Path (SFP): the selection of specific service 172 function instances on specific network nodes to form a service 173 graph through which an SFC is instantiated. 175 The following terms are defined and used in this document: 177 SFC Pseudo Controller (P-CTRL): logical entity 178 [I-D.bernardos-sfc-distributed-control], complementing the SFC 179 controller/orchestrator found in current architectures and 180 deployments. It is service specific, meaning that it is defined 181 and meaningful in the context of a given network service. 182 Compared to existing SFC controllers/orchestrators, which manage 183 multiple SFCs instantiated over a common infrastructure, pseudo 184 controllers are constrained to service specific lifecycle 185 management. 187 SFC Central Controller (C-CTRL): central control plane logical 188 entity in charge of configuring and managing the SFC components 189 [RFC7665]. 191 3. Problem statement 193 Mobile network architectures are evolving to support network 194 virtualization and service function orchestration. Current Service 195 Function Chain (SFC) architectures [RFC7665] rely on a centralized 196 controller/orchestrator (C-CTRL) which shall be connected to all the 197 hosts participating in a given SFC. This poses issues and 198 inefficiencies in fog computing environments especially because of 199 the mobility and volatility of some hosts, as well as the associated 200 signaling overhead. 202 These problems can be alleviated by enabling autonomous SFC self- 203 orchestration (SOC), based on the concept of SFC pseudo controller 204 (P-CTRL) introduced in [I-D.bernardos-sfc-distributed-control]. A 205 pseudo controller is capable of substituting (at least temporarily 206 and partially) the centralized SFC controller in situations where the 207 centralized controller may not be able to perform its functions 208 (e.g., when the connectivity with some hosts is broken). 210 [I-D.bernardos-sfc-distributed-control] introduces the role of the 211 SFC pseudo controller and describes mechanisms to select and 212 initialize a service-specific SFC pseudo controller among host nodes 213 which are participating in the SFC. This document specifies 214 mechanisms to enable an SFC pseudo controller trigger and control NS 215 lifecycle management operations, such as migration of NS functions, 216 chains or parts of a chain. 218 Figure 1 shows an exemplary scenario where a host UE makes use of an 219 NS composed of the chain of SFs F1-F2-F3. These functions may be 220 application functions -- using 3GPP jargon -- network functions or 221 over-the-top functions. Non-limiting examples of these functions 222 are: load balancers, traffic steering, performance enhancement 223 proxies (PEPs), video transcoders, firewalls, etc. In this example, 224 F1 instance runs on a first UE (node A), F2 instance runs on a second 225 UE (node B), and F3 instance runs on a gNB (node D). SFC pseudo 226 controller instances are assumed running on UE node A and D (which is 227 a gNB). Node A and B are connected via D2D communications. If all 228 the UEs move out of the coverage of the gNB node D, the service chain 229 will then need to be reconfigured to maintain service continuity as 230 gNB node D is hosting one function (F3) of the chain and would become 231 disconnected. Since gNB node D is also providing the UEs with 232 connectivity to the network infrastructure where the SFC central 233 controller is hosted, this type of event cannot be resolved by the 234 SFC controller, as the nodes hosting the functions would be 235 disconnected from the central controller. Similar problems arise in 236 highly mobile/volatile and/or latency-demanding scenarios, where 237 centralized lifecycle management becomes unsuitable. 239 o 240 node B | 241 +--------|-+ F1+-·-·-+F2+-·-·-+F3 SFC 242 | ········ | 243 <==== | |P-CTRL| | 244 | ········ | 245 +-·-·-+F2 | 246 o / +---+------+ ________ 247 | · · _( )_ 248 +--------|-+ / / _( +--------+ )_ 249 | | · · (_ | C-CTRL | _) 250 | | / / (_+--------+_) 251 | |· | (________) 252 | +-·-·/ · 253 | F1 | | ( (oo) ) 254 +----------+ · o /\ ········ 255 node A | | /\/\ |P-CTRL| 256 +-----·--|-+ /\/\/\········ 257 | | | /\/ \/\ (F3) 258 | · | node D 259 <==== | | | 260 | + | 261 | F3 | 262 +----------+ 263 node C 265 Figure 1: Example scenario: disrupted SFC due to mobility 267 In these scenarios, an SFC pseudo controller can substitute (at least 268 temporarily and partially) the centralized SFC controller when the 269 latter is not available or able to perform a given task. This 270 document proposes solutions addressing the following problem: How to 271 enable SFC pseudo controllers to perform NS lifecycle management 272 operations, such as migration of functions, service chains or parts 273 of a chain? This requires solving the sub-problems listed below. 275 * When a SFC centralized controller (C-CTRL) is in charge, what 276 mechanisms and exchanges are needed between the C-CTRL and a SFC 277 pseudo-controller (P-CTRL), and the nodes, so as to facilitate a 278 seamless transition from C-CTRL to P-CTRL (due to an event, e.g. 279 failure, of the C-CTRL)? 281 * When P-CTRL takes over from the C-CTRL, what actions shall it take 282 towards other P-CTRLs, so as to sustain seamless transition if a 283 first P-CTRL fails (e.g., moving from P-CTRL A to P-CTRL B)? 285 * When C-CTRL is back into the picture, how shall the control 286 transfer seamlessly back from P-CTRL to C-CTRL? 288 4. Distributed SFC control operation 290 A key concept is to allow a P-CTRL to take over temporarily and 291 partially from the C-CTRL to perform NS lifecycle management 292 decisions. The definition, selection and initialization of a P-CTRL 293 is covered in [I-D.bernardos-sfc-distributed-control]. 295 Using Figure 1, we can think of an example where a function (F3) is 296 migrated from node D to node C, triggered by the move of nodes A and 297 B hosting F1 and F2 away from the coverage of node D hosting F3 298 (nodes A nd B are UEs within coverage of node D which is a gNB). The 299 P-CTRL in node B performs OAM operations locally and monitors the NS- 300 specific SLAs. Upon detecting or predicting that the NS-specific 301 SLAs may not be met in the near future, P-CTRL A takes actions to 302 temporary and partially substitute C-CTRL, and starts performing 303 local NS lifecycle management operations (e.g., instantiating F3 on 304 node C, since current hosting node -- node D --is predicted to become 305 unreachable soon). 307 Note that, in the previous example, the prediction and local NS 308 lifecycle management operations could have been performed by P-CTRL 309 running at node D as well. We have assumed that the active 310 (designated) P-CTRL is running at node B, but could have been at node 311 D as well, which would imply the need to also migrate the active 312 P-CTRL role to node B. 314 Thanks to enabling P-CTRL B to perform local NS lifecycle management 315 decisions, service continuity will be guaranteed when C-CTRL fails or 316 is out of reach. 318 The "activation" of P-CTRL operation only occurs when C-CTRL cannot 319 properly operate (e.g., it is disconnected from the SFC or it is not 320 reacting fast enough to the local changing conditions). For example, 321 P-CTRL can send a scaling command to a given node, in order to adapt 322 the resources to the current NS demands. P-CTRL would also notify 323 this to C-CTRL, as soon as the connection to C-CTRL is recovered so 324 that both are synchronized. 326 In order to support the operation of P-CTRLs complementing or 327 replacing the operation of the C-CTRL, the following operations are 328 needed: 330 * When an NS is onboarded, the C-CTRL receives an NS descriptor 331 (NSD), together with the VNF descriptors (VNFDs) of the functions 332 composing the service, and the Operations, Administration and 333 Maintenance Descriptor (OAMD), which includes the information of 334 what needs to be monitored to ensure a given SLA. 336 * When the NS is instantiated, in addition to the regular 337 orchestration decisions (e.g., placement of functions on available 338 resources, etc.), the C-CTRL, based on its knowledge of existing 339 P-CTRLs, decides how monitoring is going to be performed. This 340 includes: (i) What is monitored by each P-CTRL node (e.g., vCPU 341 load, bandwidth of a certain link, etc.) and how (e.g., active, 342 passive or hybrid monitoring); (ii) Which orchestrators are in 343 charge of collecting and processing the measurements. 345 Currently defined mechanisms assume a semi-static environment and the 346 standardized message flows do not support dynamic migration of the 347 SFC controller role to other entities. Therefore, new signaling 348 flows need to be defined between C-CTRL and P-CTRLs and in-between 349 P-CTRLs: (i) allowing prediction of events via local monitoring and 350 faster reaction, (ii) enabling orchestration when C-CTRL is 351 temporarily unreachable, and (iii) supporting migrating CTRL role to 352 P-CTRLs. 354 4.1. P-CTRL taking over C-CTRL 356 There are two main triggers for a P-CTRL to take over from the 357 C-CTRL: a local monitoring event or a C-CTRL failure. We specify 358 next the procedures for each of these two triggers. 360 4.1.1. P-CTRL taking over C-CTRL due to a local monitoring event 362 In this case, the C-CTRL has delegated some monitoring actions to the 363 P-CTRL, as indicated in the OAMD sent by the C-CTRL to the P-CTRL. 365 +---------+ +----+ +---------+ +---------+ +----------+ +------+ 366 | node A | | C | | node B | | node D | | 3GPP | | SFC | 367 |P-CTRL F1| | F3 | |P-CTRL F2| |P-CTRL F3| |ctrl plane| |C-CTRL| 368 +--+----+-+ +----+ +--+----+-+ +--+----+-+ +----------+ +------+ 369 | | | | | | | | | 370 | F1@A<->F2@B<->F3@D SFC network service | | 371 | |<-·-·-·-·-·-·-·-·-·>|<-·-·-·-·->| |A.Serv. OAM | 372 | | | | | | | |<-·-·-·-·-·>| 373 | | | | |B.Serv. OAM monitor. | | 374 | | | | |-·-·-·-·-·-·-·-·-·-·>| | 375 | | | | |<-·-·-·-·-·-·-·-·-·-·| | 376 | | | | | | | | | 377 | | | | |C.Serv. OAM monitor. | | 378 | | | | |<-·-·-| | | | 379 | | | | |-·-·-·-·-·-·-·-·-·-·>| | 380 | | | | |<-·-·-·-·-·-·-·-·-·-·| | 381 | | | | |-·-·->| | | | 382 | | D.Serv. OAM monitor. | | | | 383 | | |<-·-·->| | | | | | 384 | | | |<-·-·-·-·->| | | | 385 |<-·>|<-·-·-·-·-·-·->| | | | | | 386 |<-·-·-·-·-·-·-·-·-·>| | | | | | 387 | | | | | | | | | 388 | | P-CTRL@B detects that it's | | | 389 | | loosing connectivity with D | | | 390 | | | | | | | | | 391 | | Orch. signal. | | | | | | 392 | | |<-·-·->| | | | | | 393 | |<-·-·-·-·-·-·->| | | | | | 394 | | | | | Sync. with C-CTRL | | 395 | | | | |<·-·-·-·-·-·-·-·-·-·>| | 396 | | | | | | | | | 398 Figure 2: P-CTRL taking over C-CTRL due to a local monitoring event 400 A detailed message sequence chart is shown in Figure 2. The 401 different steps are described next: 403 * (We assume that the network service has been instantiated and 404 there is traffic: F1@A--F2@B--F3@D). 406 * C-CTRL runs overall OAM monitoring of the network services. This 407 can be done for example by contacting the 3GPP network to obtain 408 different network analytics via NEF. This is shown in the figure 409 as A. 411 * P-CTRLs are running service specific OAM monitoring actions, as 412 indicated in the OAMD sent by the C-CTRL in the network service 413 instantiation procedure. This requires signaling procedures. 414 Various non-limiting example options are possible: 416 - The P-CTRL may directly obtain information metrics from 417 different network functions through the network exposure 418 function (NEF). This is shown in the figure as B. 420 - The P-CTRL may indirectly obtain the information metrics 421 through the local AF or NF hosted on the UE, which interacts 422 with any other entity inside or outside 3GPP (e.g., AF to AF, 423 NF to AF, or NF to NF) and then parse these on the interface to 424 the P-CTRL. If the function hosted on the UE is an NF, and the 425 info is about 3GPP network data analytics, then the NF will go 426 get some data from NWDAF and locally at the UE, expose these to 427 the P-CTRL. This is shown in the figure as C. 429 - In addition to the former (mutually exclusive approaches), it 430 is also possible to perform local OAM monitoring via standalone 431 procedures, such as local OAM monitoring and the use of SFC 432 OAM. This is shown in the figure as D. 434 The interface between the P-CTRL and the SFC functions running on 435 the UE to obtain OAM metrics may be a local API, or standard 436 interface like IETF SFC OAM, or like the interface between 3GPP 437 NWDAF and an NWDAF service consumer. 439 * At a certain point in time, a local monitoring event, which cannot 440 be detected by the C-CTRL, triggers the whole process. In the 441 example of the figure P-CTRL@node B detects that B is losing 442 connectivity with node D. 444 * The P-CTRL takes an orchestration decision based on its local 445 knowledge and signals it to the involved nodes. The decision 446 consists in migrating/moving F3 from node D to C. New extensions 447 to MIPv6 are used, as described in TBD. Alternatively, extensions 448 to IETF SFC NSH can also be used, as described in TBD. 450 * The P-CTRL also informs the C-CTRL to keep it synchronized. 451 Similarly, the C-CTRL can then update other P-CTRLs if needed. 452 New extensions to NSH are used (NS lifecycle management), as 453 described in TBD. 455 4.1.2. P-CTRL taking over C-CTRL due to a C-CTRL failure 457 In this case, the P-CTRL detects/predicts a C-CTRL failure (e.g., it 458 becomes unreachable). 460 +---------+ +----+ +---------+ +---------+ +----------+ +------+ 461 | node A | | C | | node B | | node D | | 3GPP | | SFC | 462 |P-CTRL F1| | F3 | |P-CTRL F2| |P-CTRL F3| |ctrl plane| |C-CTRL| 463 +--+----+-+ +----+ +--+----+-+ +--+----+-+ +----------+ +------+ 464 | | | | | | | | | 465 | F1@A<->F2@B<->F3@D SFC network service | | 466 | |<-·-·-·-·-·-·-·-·-·>|<-·-·-·-·->| | | 467 | | | | | | | | | 468 | | | | | C-CTRL connectivity failure | 469 | | | | |<·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·->| 470 | P-CTRL@B detects that connectivity | | 471 | with C-CTRL is lost (or about to be) | | 472 | | | | | | | | | 473 | | | | | Sync with C-CTRL (if | 474 | | | | | failure is predicted) | 475 | | | | |<·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·->| 476 | | P-CTRL@B becomes the | | | | 477 | | CTRL for the service | | | | 478 | | | | | | | | | 479 | P-CTRL activation | | | | | | 480 |<-·-·-·-·-·-·-·-·-·>| | | | | | 481 | | | | | | | | | 482 | | Orch. signal. | | | | | | 483 | | |<-·-·->| | | | | | 484 | |<-·-·-·-·-·-·->| | | | | | 485 | | | | | | | | | 487 Figure 3: P-CTRL taking over C-CTRL due to a C-CTRL failure 489 A detailed message sequence chart is shown in Figure 3. The 490 different steps are described next: 492 * (We assume that the network service has been instantiated and 493 there is traffic: F1@A--F2@B--F3@D). 495 * A failure can be detected by a P-CTRL via multiple mechanisms, 496 such as: (i) Sending periodic keep-alive messages to the C-CTRL; 497 (ii) Transport-layer mechanisms that allow detecting connectivity 498 failures; (iii) Observing a lack of action from the C-CTRL upon an 499 event that requires an orchestration action. 501 * A failure can also be predicted by a P-CTRL, by using local 502 monitoring information. 504 * When a C-CTRL failure is detected, the designated backup P-CTRL 505 takes over the orchestration of the network service, by: 507 - Notifying other P-CTRLs, as well as selecting a new designated 508 backup P-CTRL. This involves the synchronization of relevant 509 information (orchestration DBs, descriptors, etc.) with C-CTRL 510 (if the failure is predicted). This is done through new IETF 511 SFC NSH extensions (NS lifecycle management), as described in 512 TBD. 514 - The P-CTRL becoming the SFC controller/orchestrator. From this 515 point of time on, the P-CTRL can send orchestration signaling. 516 Extensions to IETF NSH or MIPv6 can be used, as described in 517 TBD and TBD. 519 4.1.3. C-CTRL gaining back control 521 We describe next, using an example, how a C-CTRL may get back the 522 orchestration control, temporarily delegated to a P-CTRL. 524 +---------+ +----+ +---------+ +---------+ +----------+ +------+ 525 | node A | | C | | node B | | node D | | 3GPP | | SFC | 526 |P-CTRL F1| | F3 | |P-CTRL F2| |P-CTRL F3| |ctrl plane| |C-CTRL| 527 +--+----+-+ +----+ +--+----+-+ +--+----+-+ +----------+ +------+ 528 | | | | | | | | | 529 | | | | | Connectivity OK notification | 530 | | | | | | | |-·-·-·-·-·->| 531 | | | |-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·>| 532 | | | | | | | | | 533 | | | | Request to take over SFC control | 534 | | | |<·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-| 535 | | | | Orchestration state sync. | 536 | | | |-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·>| 537 | | | | | | | | | 538 | | | | | | | | C-CTRL 539 | | | | | | | | regains 540 | | | | | | | | control 541 | | | | Notification C-CTRL back in control | 542 |<-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-·-| 543 | | | | | | | | | 545 Figure 4: C-CTRL gaining back control 547 A detailed message sequence chart is shown in Figure 4. The 548 different steps are described next: 550 * When a C-CTRL loses connectivity with the nodes involved in a 551 service, it enters into recovery mode, waiting for the 552 connectivity to be recovered. C-CTRL can learn that connectivity 553 has been regained using NSH OAM signaling or 3GPP signaling from 554 the NEF or the P-CTRL itself. 556 * When connectivity is gained back to a P-CTRL, the C-CTRL signals 557 its availability so the P-CTRL can give back the control of the 558 service. To do so, IETF SFC NSH extensions (NS lifecycle 559 management) can be used, as described in TBD. 561 * The C-CTRL becomes now the active SFC controller/orchestrator for 562 the service. 564 * The C-CTRL notifies to other P-CTRLs that it is back in control of 565 the service, using IETF SFC NSH extensions (NS lifecycle 566 management), as described in TBD. 568 4.2. Inter P-CTRL seamless handover 570 In scenarios with no C-CTRL reachability, it might be needed to 571 transition from one P-CTRL to another one (e.g., because of mobility 572 of the nodes while the C-CTRL is not reachable). 574 Reactive transition is supported as for the case of C-CTRL failure. 575 Proactive/seamless transition is addressed as follows. 577 +---------+ +----+ +----+ +---------+ +----------+ +------+ 578 | node A | | C | | B | | node D | | 3GPP | | SFC | 579 |P-CTRL F1| | F3 | | F2 | |P-CTRL F3| |ctrl plane| |C-CTRL| 580 +--+----+-+ +----+ +----+ +--+----+-+ +----------+ +------+ 581 | | | | | | | | 582 | F1@A<->F2@B<->F3@D SFC network service | | 583 | |<-·-·-·-·-·-·->|<-·-·-·-·->| | | 584 | | | | | | | | 585 | | | | P-CTRL@D can no | | 586 | | | | longer act as CTRL | | 587 | | | | | | | | 588 Notification to other P-CTRLs| | | | 589 |<-·-·-·-·-·-·-·-·-·-·-·-·-·| | | | 590 Request to take over control | | | | 591 |-·-·-·-·-·-·-·-·-·-·-·-·-·>| | | | 592 Orchestration state sync | | | | 593 |<-·-·-·-·-·-·-·-·-·-·-·-·-·| | | | 594 | | | | | | | | 595 P-CTRL@A becomes| | | | | | 596 the CTRL for | | | | | | 597 the service | | | | | | 598 | | | | | | | | 600 Figure 5: Inter P-CTRL seamless handover 602 A detailed message sequence chart is shown in Figure 5. The 603 different steps are described next: 605 * (We assume that the network service has been instantiated and 606 there is traffic: F1@A--F2@B--F3@D). 608 * When the active (designated) P-CTRL detects that it might not be 609 able to operate in the near future (lack of resources, battery, 610 moving away, etc.), a notification is sent to other P-CTRLs using 611 new IETF SFC NSH extensions (NS lifecycle management), as 612 described in TBD. 614 * Each P-CTRL receiving the notification message that is ready to 615 take over the role of active P-CTRL sends a message to the current 616 P-CTRL, which selects one. New IETF SFC NSH extensions are used 617 to convey this signaling. 619 * At this point, the new P-CTRL becomes the SFC controller/ 620 orchestrator of the service. 622 5. IANA Considerations 624 N/A. 626 6. Security Considerations 628 TBD. 630 7. Acknowledgments 632 The work in this draft has been partially supported by the H2020 633 5Growth (Grant 856709) and 5G-DIVE projects (Grant 859881). 635 8. References 637 8.1. Normative References 639 [I-D.bernardos-sfc-distributed-control] 640 Bernardos, C. J. and A. Mourad, "Distributed SFC control 641 for fog environments", Work in Progress, Internet-Draft, 642 draft-bernardos-sfc-distributed-control-05, 27 January 643 2022, . 646 8.2. Informative References 648 [I-D.bernardos-sfc-fog-ran] 649 Bernardos, C. J. and A. Mourad, "Service Function Chaining 650 Use Cases in Fog RAN", Work in Progress, Internet-Draft, 651 draft-bernardos-sfc-fog-ran-10, 22 October 2021, 652 . 655 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 656 Chaining (SFC) Architecture", RFC 7665, 657 DOI 10.17487/RFC7665, October 2015, 658 . 660 Authors' Addresses 662 Carlos J. Bernardos 663 Universidad Carlos III de Madrid 664 Av. Universidad, 30 665 28911 Leganes, Madrid 666 Spain 667 Phone: +34 91624 6236 668 Email: cjbc@it.uc3m.es 669 URI: http://www.it.uc3m.es/cjbc/ 671 Alain Mourad 672 InterDigital Europe 673 Email: Alain.Mourad@InterDigital.com 674 URI: http://www.InterDigital.com/