idnits 2.17.00 (12 Aug 2021) /tmp/idnits30715/draft-bernardos-sfc-distributed-control-05.txt: -(325): 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 9 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 (January 2022) is 119 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: 31 July 2022 InterDigital 6 January 2022 8 Distributed SFC control for fog environments 9 draft-bernardos-sfc-distributed-control-05 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 introduces the role of SFC pseudo- 20 controller and specifies solutions to select and initialize such new 21 logical function. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on 5 July 2022. 40 Copyright Notice 42 Copyright (c) 2022 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 47 license-info) in effect on the date of publication of this document. 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. Code Components 50 extracted from this document must include Revised BSD License text as 51 described in Section 4.e of the Trust Legal Provisions and are 52 provided without warranty as described in the Revised BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Distributed SFC control . . . . . . . . . . . . . . . . . . . 6 60 4.1. SFC pseudo controller initialization . . . . . . . . . . 7 61 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 63 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 64 8. Informative References . . . . . . . . . . . . . . . . . . . 11 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 67 1. Introduction 69 Virtualization of functions provides operators with tools to deploy 70 new services much faster, as compared to the traditional use of 71 monolithic and tightly integrated dedicated machinery. As a natural 72 next step, mobile network operators need to re-think how to evolve 73 their existing network infrastructures and how to deploy new ones to 74 address the challenges posed by the increasing customers' demands, as 75 well as by the huge competition among operators. All these changes 76 are triggering the need for a modification in the way operators and 77 infrastructure providers operate their networks, as they need to 78 significantly reduce the costs incurred in deploying a new service 79 and operating it. Some of the mechanisms that are being considered 80 and already adopted by operators include: sharing of network 81 infrastructure to reduce costs, virtualization of core servers 82 running in data centers as a way of supporting their load-aware 83 elastic dimensioning, and dynamic energy policies to reduce the 84 monthly electricity bill. However, this has proved to be tough to 85 put in practice, and not enough. Indeed, it is not easy to deploy 86 new mechanisms in a running operational network due to the high 87 dependency on proprietary (and sometime obscure) protocols and 88 interfaces, which are complex to manage and often require configuring 89 multiple devices in a decentralized way. 91 Service Functions are widely deployed and essential in many networks. 92 These Service Functions provide a range of features such as security, 93 WAN acceleration, and server load balancing. Service Functions may 94 be instantiated at different points in the network infrastructure 95 such as data center, the WAN, the RAN, and even on mobile nodes. 97 Service functions (SFs), also referred to as VNFs, or just functions, 98 are hosted on compute, storage and networking resources. The hosting 99 environment of a function is called Service Function Provider or 100 NFVI-PoP (using ETSI NFV terminology). 102 Services are typically formed as a composition of SFs (VNFs), with 103 each SF providing a specific function of the whole service. Services 104 also referred to as Network Services (NS), according to ETSI 105 terminology. 107 With the arrival of virtualization, the deployment model for service 108 function is evolving to one where the traffic is steered through the 109 functions wherever they are deployed (functions do not need to be 110 deployed in the traffic path anymore). For a given service, the 111 abstracted view of the required service functions and the order in 112 which they are to be applied is called a Service Function Chain 113 (SFC). An SFC is instantiated through selection of specific service 114 function instances on specific network nodes to form a service graph: 115 this is called a Service Function Path (SFP). The service functions 116 may be applied at any layer within the network protocol stack 117 (network layer, transport layer, application layer, etc.). 119 The concept of fog computing has emerged driven by the Internet of 120 Things (IoT) due to the need of handling the data generated from the 121 end-user devices. The term fog is referred to any networked 122 computational resource in the continuum between things and cloud. A 123 fog node may therefore be an infrastructure network node such as an 124 eNodeB or gNodeB, an edge server, a customer premises equipment 125 (CPE), or even a user equipment (UE) terminal node such as a laptop, 126 a smartphone, or a computing unit on-board a vehicle, robot or drone. 128 In fog computing, the functions composing an SFC are hosted on 129 resources that are inherently heterogeneous, volatile and mobile 130 [I-D.bernardos-sfc-fog-ran]. This means that resources might appear 131 and disappear, and the connectivity characteristics between these 132 resources may also change dynamically. These scenarios call for 133 distributed SFC control solutions, where there are SFC pseudo 134 controllers, enabling autonomous SFC self-orchestration capabilities. 135 This document introduces this concept and presents first ideas on 136 mechanisms to select and initialize a service-specific SFC pseudo 137 controller among host nodes which are participating in the SFC. 139 2. Terminology 141 The following terms used in this document are defined by the IETF in 142 [RFC7665]: 144 Service Function (SF): a function that is responsible for specific 145 treatment of received packets (e.g., firewall, load balancer). 147 Service Function Chain (SFC): for a given service, the abstracted 148 view of the required service functions and the order in which they 149 are to be applied. This is somehow equivalent to the Network 150 Function Forwarding Graph (NF-FG) at ETSI. 152 Service Function Forwarder (SFF): A service function forwarder is 153 responsible for forwarding traffic to one or more connected 154 service functions according to information carried in the SFC 155 encapsulation, as well as handling traffic coming back from the 156 SF. 158 SFI: SF instance. 160 Service Function Path (SFP): the selection of specific service 161 function instances on specific network nodes to form a service 162 graph through which an SFC is instantiated. 164 3. Problem statement 166 [RFC7665] describes an architecture for the specification, creation, 167 and ongoing maintenance of Service Function Chains (SFCs) in a 168 network. It includes architectural concepts, principles, and 169 components used in the construction of composite services through 170 deployment of SFCs. 172 The SFC architecture assumes there is a control plane that configures 173 and manages the SFC components. This role is typically assumed to be 174 played by a centralized controller/orchestrator. This implies that 175 dynamic changes on the SFC (composition, function migration, scaling, 176 etc) can only be performed by the centralized controller, which needs 177 to always have connectivity with the functions, and have updated 178 information on the status of all the nodes hosting the functions. 179 Also, multiple services are managed by the same controller/ 180 orchestrator, even if they provide different functionalities with 181 disparate requirements. 183 In a fog environment, with current management and orchestration 184 solutions, SFCs cannot operate if the nodes hosting the functions get 185 disconnected from the infrastructure. This implies that the 186 lifecycle management of an SFC cannot be managed if disconnected from 187 the centralized controller, which means that important actions (e.g., 188 scaling, migrating a function or updating the data plane) might not 189 take place due to the lack of connectivity with the controller/ 190 orchestrator (even if connectivity issues are just temporal ones). 191 Additionally, lifecycle management of SFCs require up-to-date 192 monitoring information, with a refresh frequency that is service- 193 specific and might involve a very high overhead with the controller. 194 This severely limits the capability of fast reacting to events local 195 to the nodes hosting the functions, as the SFC cannot autonomously 196 self-orchestrate (decisions can only be taken by the centralized 197 controller/orchestrator). 199 Figure 1 shows an exemplary scenario where a drone makes use of a 200 network service composed of the chain of functions F1-F2-F3. F1 runs 201 on the drone itself (node A), F2 runs in another drone (node B) and 202 F3 runs in a gNB on the ground (node D). The service might be, for 203 example, an autonomous video surveillance activity in which a couple 204 of drones with different types of cameras make use of image 205 recognition to decide where to go next. If the drones move out of 206 the coverage of the node D, the service chain needs to be 207 reconfigured (for example migrating F3 to node C) so it can remain 208 operative (as node D is hosting one function of the SFC). Since node 209 D is also providing the drones with connectivity to the network 210 infrastructure where the SFC controller is located, this type of 211 events cannot be resolved by the SFC controller, as the nodes hosting 212 the functions would be disconnected from the controller. 214 node B 215 / \ F1+-·-·-+F2+-·-·-+F3 SFC 216 <==== /\ /\ 217 \-----/ 218 | | 219 +-·-·-·-+F2 | 220 / /---+-\ __________ 221 / \ · \/ / \/ _( )_ 222 /\ /\ / \ · / _( +----------+ )_ 223 \-----/ · / ( (oo) ) (_ | SFC ctrl | _) 224 | +-·-·/ · /\ (_+----------+_) 225 | F1 | | /\/\ (F3) (__________) 226 /-----\ · /\/\/\ 227 \/ \/ / | \ /\/ \/\ 228 \ / /\ · /\ node D 229 node A \---|-/ 230 | + | 231 | F3 | 232 /-----\ 233 <==== \/ \/ 234 \ / 235 node C 237 Figure 1: SFC example scenario 239 Another scenario that cannot be properly tackled with current SFC 240 orchestration approaches control appears with highly mobile/volatile 241 environments and/or latency-demanding services, in which centralized 242 lifecycle management is unfeasible due to its high signaling cost 243 (e.g., they require frequent measurements sent from remote nodes to a 244 centralized controller, generating too much signaling, and involving 245 a delay that might be too long to meet the service requirements). 247 4. Distributed SFC control 249 The fact that -- in fog computing environments -- SFC functions are 250 hosted in heterogeneous, volatile and mobile resources, calls for new 251 orchestration solutions able to cope with dynamic changes to the 252 resources in runtime or ahead of time (in anticipation through 253 prediction) as opposed to today's solutions which are inherently 254 reactive and static or semi-static. 256 These new orchestration solutions have to enable SFCs to autonomously 257 self-orchestrate without having to rely on a centralized controller. 258 The idea introduced in this draft is to enable one of the nodes 259 involved in a service function chain (i.e., in a specific service) to 260 be prepared to take over the control of the SFC and perform network 261 service lifecycle management decisions, replacing at least temporary 262 and at least partially the centralized SFC controller. 264 This draft proposes a new logical entity, complementing the SFC 265 controller/orchestrator found in current architectures and 266 deployments. We refer to this new entity as SFC pseudo controller, 267 and it is characterized by the following: 269 * It is service-specific, meaning that it is defined and meaningful 270 in the context of a given network service. Compared to existing 271 SFC controllers/orchestrators, which manage multiple SFCs 272 instantiated over a common infrastructure, pseudo controllers are 273 constrained to service specific lifecycle management. These SFC 274 pseudo controllers synchronize with the SFC centralized 275 controller/orchestrator to ensure proper resource orchestration. 277 * Potentially, any node involved in a network service might play the 278 role of SFC pseudo controller. But note that it is not mandatory 279 that all nodes are willing/capable to play that role. Therefore, 280 we consider that on a given deployment, only a subset of all the 281 involved nodes are willing or capable of doing so. We refer to 282 these nodes as candidate pseudo controllers. During the 283 initialization phase, out of the candidates, one will be chosen by 284 the SFC controller as selected SFC pseudo controller. Each 285 candidate pseudo controller maintains a local copy of the 286 information required to properly perform lifecycle management of 287 the service. This includes not only information about the network 288 service (e.g., the Network Service Descriptor, NSD, and the 289 Virtual Network Function Descriptors, VNFDs, as defined by ETSI 290 NFV, and the characterization of the resource capabilities of the 291 nodes hosting the functions), but also the information related to 292 performing an efficient monitoring of the service. We refer to 293 this new descriptor as Operations, Administration and Maintenance 294 Descriptor (OAMD). 296 * From the set of available candidate SFC pseudo controllers, one is 297 chosen as selected pseudo controllers for a network service. This 298 active pseudo controller performs monitoring activities at service 299 and resource level and synchronizes periodically with the 300 centralized SFC controller/orchestrator. Note that this is 301 performed in an opportunistic way, if connectivity is available, 302 and that disconnected operation is possible. 304 Candidate pseudo controller instances might be located at any node 305 hosting a service function. The SFC controller typically runs in the 306 network core, at a server (either as a physical or virtual function). 307 The SFC controller and the candidate pseudo controller instances 308 exchange signaling to initialize the selected SFC pseudo controller. 309 This includes signaling to describe the service, signaling to express 310 the readiness and preference from the candidates to play the role of 311 pseudo controller, and the signaling from the SFC controller to 312 indicate the selected one. This is explained in more detail next. 314 4.1. SFC pseudo controller initialization 316 This section describes how SFC pseudo controller candidates are 317 determined and selected SFC pseudo controllers are chosen from the 318 candidate set. 320 +--------+ +--------+ +--------+ +--------+ +----------+ 321 | node A | | node C | | node B | | node D | | SFC ctrl | 322 +--------+ +--------+ +--------+ +--------+ +----------+ 323 | | | | | 324 | F1@A<->F2@B<->F3@C SFC instance traffic | | 325 |<-·-·-·-·-·-·-·-·-·-·-·-·->|<-·-·-·-·-·->| | 326 | | | | | 327 | | |1. Candidate pseudo-controller adv. 328 | | |----------------------------->| 329 |--------------------------------------------------------->| 330 | | | | | 331 | | | 2. Service description | 332 | | |<-----------------------------| 333 |<---------------------------------------------------------| 334 | | | | | 335 | | |3. Candidate pseudo-controller req. 336 | | |----------------------------->| 337 |--------------------------------------------------------->| 338 | | | | | 339 | | | | (4. Selection) 340 | | | | | 341 | | 5. Candidate pseudo-controller resp. 342 |<---------------------------------------------------------| 343 | | | | | 345 Figure 2: SFC pseudo controller initialization 347 A detailed message sequence chart is shown in Figure 2. The 348 different steps are described next: 350 1. Among the fog nodes hosting functions of an SFC, several might be 351 willing to play the role of SFC pseudo controller. There is an 352 exchange of information between the SFC controller and the SFC 353 nodes, where the SFC pseudo controller candidates will be 354 determined by fog nodes' willingness/preference for a service. A 355 preference value from the candidate nodes is used by the SFC 356 controller as primary value to decide which is the selected SFC 357 pseudo controller, but other information can also be used in this 358 decision, such as, but not limited to: local policies, volatility 359 of the node, known capabilities of the node (monitoring, 360 connectivity, available resources, etc) and so on. Those nodes 361 willing to play the role of SFC pseudo controller advertise their 362 presence to the SFC controller, through which SFC controller can 363 recognize the willingness or readiness of the nodes and will 364 enable to inform proper nodes of the detailed service description 365 such as NSD and OAMD. This message includes: 367 * The service ID, identifying the service (note that multiple 368 SFCs might be running in parallel, even with some nodes 369 participating simultaneously in more than one). 371 * An ID of the candidate SFC pseudo controller. This ID 372 uniquely identifies the pseudo controller instance. It might 373 be generated using a unique identifier of the node. 375 2. The SFC controller shares information about the service (e.g., 376 service requirement, desired monitoring configuration) with the 377 nodes, through which information the nodes can assess the own 378 availability as a pseudo controller for the specific service and 379 decides some preferences. This includes: 381 * The service ID, identifying the specific service. 383 * The Network Service Descriptor (NSD) of the service, which 384 includes the description of the chain in terms of composing 385 functions and logical links connecting them, as well as 386 associated requirements (e.g.: compute requirements, 387 connectivity, affinity, etc). 389 * The information required to perform an efficient monitoring of 390 the service: the Operations, Administration and Maintenance 391 Descriptor (OAMD). Examples of this information are: latency 392 constraints for all logical links of the service chain, 393 bandwidth requirements for all logical links, maximum 394 tolerated packet losses for each of the logical links and the 395 whole end-to-end service, tolerated jitter, minimum required 396 availability for a given instantiation (i.e., the minimum time 397 the functions need to remain instantiated on their hosting 398 resources to ensure a minimum consistency for the service), 399 battery status/lifetime, periodicity on which each of the 400 parameters needs to be monitored, etc. 402 * Security capabilities required to manage the service, which 403 include the set of security mechanisms that need to be 404 supported for an (pseudo-)orchestrator to be able to manage 405 the service. This set might include a set of alternatives, so 406 different solutions can be used. Examples of these 407 capabilities are: authentication algorithms, encryption 408 algorithms, supported certificate authorities, etc. 410 3. The candidate SFC pseudo controllers respond to the SFC 411 controller, including the following information: 413 * The service ID, identifying the specific service. 415 * An ID, identifying the SFC pseudo controller instance. 417 * A preference value for the candidate node to play the role of 418 active pseudo controller. This preference is represented with 419 an integer that indicates the willingness of the candidate 420 node to become an "active" SFC pseudo-controller for the 421 running service. This preference is locally selected by the 422 node based on the specifics of the service. Note that the 423 nodes have all the information about the service (contained in 424 the NSD) and its monitoring (the nodes also have the OAMD, 425 which specifies which aspects need to be monitored, at both 426 service and resource level). Each node decides the local 427 preference value based on this service information, as well as 428 its own capabilities (e.g., whether it is capable of 429 performing the associated control and monitoring tasks and if 430 it is willing to assume the associated cost, for example in 431 terms of energy consumption -- if the node is battery- 432 powered). 434 * A list of other known candidate SFC pseudo-controllers. A 435 node might know this based on local broadcasts from those 436 candidate pseudo-controllers (advertising its presence). This 437 allows the SFC controller to discover if there are other 438 potential candidate pseudo-controllers available. 440 * A list of the supported security mechanisms. 442 4. With the information received from the candidate SFC pseudo 443 controllers, the (centralized) SFC controller decides which node 444 becomes the selected SFC pseudo-controller. The selection is 445 based on the preference value indicated by the candidate pseudo 446 controllers. Note that multiple nodes could include the same 447 preference value, and in case of a tie, the SFC controller might 448 use a policy to select one, or simply use a tie-breaking rule 449 (for example selecting the one with a lowest/highest ID). In 450 this example, A is selected to be the SFC pseudo controller. 452 5. The SFC controller responds to the selected SFC pseudo controller 453 with a message that includes: 455 * The service ID, identifying the specific service. 457 * The ID of the selected SFC pseudo controller instance. 459 * Security material. The centralized SFC controller and the SFC 460 nodes have pre-established security credentials, allowing the 461 controller to perform the required orchestration tasks (they 462 have a secure signaling channel). Since this security 463 relationship does not exist between any pair of the nodes, the 464 SFC controller acts as a security "anchor", by providing the 465 SFC pseudo controller -- using the secure channel -- with 466 security material allowing to securely control all the nodes 467 part of the SFC. One example of approach is to generate a 468 certificate, signed by the SFC controller, that can then be 469 used by the SFC pseudo controller. Other approaches are 470 possible. 472 * Profiles of all involved nodes in the service. This includes 473 information about the resources of the involved nodes (plus 474 additional also considered by the SFC controller in case 475 function migration is needed). Note that once a SFC pseudo 476 controller is selected, it could also query and request 477 information about the nodes that are part of the SFC. The 478 information included in the profile of a node may contain: 479 Virtual machine specification, computation properties (RAM 480 size, disk size, memory page size, number of CPUs, number of 481 cores per CPU, number of threads per core), storage 482 requirements, Scale out/scale in limits, network and 483 connectivity properties (number and type of interfaces), etc. 485 * The list of other candidate SFC pseudo-controllers. This 486 allows local synchronization among candidate pseudo 487 controllers if needed. 489 The new signaling messages described below can be implemented as 490 either new protocol messages, e.g., via REST API, or as extensions of 491 either inband or outband protocols. Examples of those include: NSH 492 (for inband signaling among SFC nodes), IPv6 (for outband via new 493 extension headers). Details and examples of signaling will be added 494 in future revisions of this draft. 496 5. IANA Considerations 498 N/A. 500 6. Security Considerations 502 TBD. 504 7. Acknowledgments 506 The work in this draft has been developed under the framework of the 507 H2020 5G-DIVE project (Grant 859881). 509 8. Informative References 511 [I-D.bernardos-sfc-fog-ran] 512 Bernardos, C. J. and A. Mourad, "Service Function Chaining 513 Use Cases in Fog RAN", Work in Progress, Internet-Draft, 514 draft-bernardos-sfc-fog-ran-10, 22 October 2021, 515 . 518 [RFC7665] Halpern, J., Ed. and C. Pignataro, Ed., "Service Function 519 Chaining (SFC) Architecture", RFC 7665, 520 DOI 10.17487/RFC7665, October 2015, 521 . 523 Authors' Addresses 525 Carlos J. Bernardos 526 Universidad Carlos III de Madrid 527 Av. Universidad, 30 528 28911 Leganes, Madrid 529 Spain 531 Phone: +34 91624 6236 532 Email: cjbc@it.uc3m.es 533 URI: http://www.it.uc3m.es/cjbc/ 535 Alain Mourad 536 InterDigital Europe 538 Email: Alain.Mourad@InterDigital.com 539 URI: http://www.InterDigital.com/