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