idnits 2.17.1 draft-bernardos-intarea-vim-discovery-06.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 (September 10, 2021) is 952 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 INTAREA WG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Experimental A. Mourad 5 Expires: March 14, 2022 InterDigital 6 September 10, 2021 8 IPv6-based discovery and association of Virtualization Infrastructure 9 Manager (VIM) and Network Function Virtualization Orchestrator (NFVO) 10 draft-bernardos-intarea-vim-discovery-06 12 Abstract 14 Virtualized resources do not need to be limited to those available in 15 traditional data centers, where the infrastructure is stable, static, 16 typically homogeneous and managed by a single admin entity. 17 Computational capabilities are becoming more and more ubiquitous, 18 with terminal devices getting extremely powerful, as well as other 19 types of devices that are close to the end users at the edge (e.g., 20 vehicular onboard devices for infotainment, micro data centers 21 deployed at the edge, etc.). It is envisioned that these devices 22 would be able to offer storage, computing and networking resources to 23 nearby network infrastructure, devices and things (the fog paradigm). 24 These resources can be used to host functions, for example to 25 offload/complement other resources available at traditional data 26 centers, but also to reduce the end-to-end latency or to provide 27 access to specialized information (e.g., context available at the 28 edge) or hardware. 30 This document describes mechanisms allowing dynamic discovery of 31 virtualization resources and orchestrators in IPv6-based networks. 32 In the current version, mechanisms based on piggybacking options on 33 IPv6 neighbor discovery are explored. New IPv6 neighbor discovery 34 options are defined. Additional mechanisms will be explored in 35 future releases of this document. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on March 14, 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Network Function Virtualization . . . . . . . . . . . . . . . 5 74 4. Fog Virtualization Overview . . . . . . . . . . . . . . . . . 7 75 5. Problem statemement . . . . . . . . . . . . . . . . . . . . . 9 76 6. Advertisement and discovery of mobile resources (VIM+NFVI) . 11 77 6.1. IPv6 ND-based discovery . . . . . . . . . . . . . . . . . 12 78 6.2. VIM+NFVI options . . . . . . . . . . . . . . . . . . . . 13 79 6.2.1. Available Virtualized Compute Resources . . . . . . . 14 80 6.2.2. Available Virtualized Storage Resources . . . . . . . 16 81 6.2.3. Available Virtualized Networking Resources . . . . . 16 82 6.2.4. Type of virtualization . . . . . . . . . . . . . . . 17 83 6.2.5. Power profile . . . . . . . . . . . . . . . . . . . . 18 84 6.2.6. Volatility profile . . . . . . . . . . . . . . . . . 19 85 6.2.7. URI of the VIM . . . . . . . . . . . . . . . . . . . 20 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 91 10.2. Informative References . . . . . . . . . . . . . . . . . 21 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 94 1. Introduction 96 The telecommunications sector is experiencing a major revolution that 97 will shape the way networks and services are designed and deployed 98 for the next decade. We are witnessing an explosion in the number of 99 applications and services demanded by users, which are now really 100 capable of accessing them on the move. In order to cope with such a 101 demand, some network operators are looking at the cloud computing 102 paradigm, which enables a potential reduction of the overall costs by 103 outsourcing communication services from specific hardware in the 104 operator's core to server farms scattered in data centers. These 105 services have different characteristics if compared with conventional 106 IT services that have to be taken into account in this cloudification 107 process. Also the transport network is affected in that it is 108 evolving to a more sophisticated form of IP architecture with trends 109 like separation of control and data plane traffic, and more fine- 110 grained forwarding of packets (beyond looking at the destination IP 111 address) in the network to fulfill new business and service goals. 113 Virtualization of functions also provides operators with tools to 114 deploy new services much faster, as compared to the traditional use 115 of monolithic and tightly integrated dedicated machinery. As a 116 natural next step, mobile network operators need to re-think how to 117 evolve their existing network infrastructures and how to deploy new 118 ones to address the challenges posed by the increasing customers' 119 demands, as well as by the huge competition among operators. All 120 these changes are triggering the need for a modification in the way 121 operators and infrastructure providers operate their networks, as 122 they need to significantly reduce the costs incurred in deploying a 123 new service and operating it. Some of the mechanisms that are being 124 considered and already adopted by operators include: sharing of 125 network infrastructure to reduce costs, virtualization of core 126 servers running in data centers as a way of supporting their load- 127 aware elastic dimensioning, and dynamic energy policies to reduce the 128 monthly electricity bill. However, this has proved to be tough to 129 put in practice, and not enough. Indeed, it is not easy to deploy 130 new mechanisms in a running operational network due to the high 131 dependency on proprietary (and sometime obscure) protocols and 132 interfaces, which are complex to manage and often require configuring 133 multiple devices in a decentralized way. 135 Network function virtualization (NFV) [etsi_nfv_whitepaper] and 136 software defined networking (SDN) [onf_sdn_architecture] are changing 137 the way the telecommunications sector will deploy, extend and operate 138 their networks. The ETSI NFV Industry Specification Group (ISG) is 139 developing the baseline NFV architecture, under some assumptions to 140 make this development easier. One of these assumptions is that the 141 resources used to run the virtualized functions are well known in 142 advance by the management and orchestration entities, as well as 143 stable. This document goes beyond this assumption [RFC8568], by 144 describing mechanisms allowing dynamic discovery of virtualization 145 resources and orchestrators in IPv6-based networks. Note that future 146 evolutions of mobile networks beyond 5G already hint the extension of 147 the network towards the edge, including end-user devices, making the 148 need of dynamic resource discovery even more relevant. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 While [RFC2119] describes interpretations of these key words in terms 157 of protocol specifications and implementations, they are used in this 158 document to describe requirements for the SFC mechanisms to 159 efficiently enable fog RAN. 161 The following terms used in this document are defined by the ETSI NFV 162 ISG, the ONF and the IETF: 164 NFV Infrastructure (NFVI): totality of all hardware and software 165 components which build up the environment in which VNFs are 166 deployed 168 NFV Management and Orchestration (NFV-MANO): functions 169 collectively provided by NFVO, VNFM, and VIM. 171 NFV Orchestrator (NFVO): functional block that manages the Network 172 Service (NS) lifecycle and coordinates the management of NS 173 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 174 resources (supported by the VIM) to ensure an optimized allocation 175 of the necessary resources and connectivity. 177 Virtualized Infrastructure Manager (VIM): functional block that is 178 responsible for controlling and managing the NFVI compute, storage 179 and network resources, usually within one operator's 180 Infrastructure Domain. 182 Virtualized Network Function (VNF): implementation of a Network 183 Function that can be deployed on a Network Function Virtualisation 184 Infrastructure (NFVI). 186 Virtualized Network Function Manager (VNFM): functional block that 187 is responsible for the lifecycle management of VNF. 189 3. Network Function Virtualization 191 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 192 quasi-standard IT virtualization technology to consolidate many 193 network equipment types into industry standard high volume servers, 194 switches, and storage. It enables implementing network functions in 195 software that can run on a range of industry standard server hardware 196 and can be moved to, or loaded in, various locations in the network 197 as required, without the need to install new equipment. The ETSI NFV 198 is one of the predominant NFV reference framework and architectural 199 footprints [nfv_sota_research_challenges]. The ETSI NFV framework 200 architecture framework is composed of three domains (Figure 1): 202 o Virtualized Network Function, running over the NFVI. 204 o NFV Infrastructure (NFVI), including the diversity of physical 205 resources and how these can be virtualized. NFVI supports the 206 execution of the VNFs. 208 o NFV Management and Orchestration, which covers the orchestration 209 and life-cycle management of physical and/or software resources 210 that support the infrastructure virtualization, and the life-cycle 211 management of VNFs. NFV Management and Orchestration focuses on 212 all virtualization specific management tasks necessary in the NFV 213 framework. 215 +-------------------------------------------+ +---------------+ 216 | Virtualized Network Functions (VNFs) | | | 217 | ------- ------- ------- ------- | | | 218 | | | | | | | | | | | | 219 | | VNF | | VNF | | VNF | | VNF | | | | 220 | | | | | | | | | | | | 221 | ------- ------- ------- ------- | | | 222 +-------------------------------------------+ | | 223 | | 224 +-------------------------------------------+ | | 225 | NFV Infrastructure (NFVI) | | NFV | 226 | ----------- ----------- ----------- | | Management | 227 | | Virtual | | Virtual | | Virtual | | | and | 228 | | Compute | | Storage | | Network | | | Orchestration | 229 | ----------- ----------- ----------- | | | 230 | +---------------------------------------+ | | | 231 | | Virtualization Layer | | | | 232 | +---------------------------------------+ | | | 233 | +---------------------------------------+ | | | 234 | | ----------- ----------- ----------- | | | | 235 | | | Compute | | Storage | | Network | | | | | 236 | | ----------- ----------- ----------- | | | | 237 | | Hardware resources | | | | 238 | +---------------------------------------+ | | | 239 +-------------------------------------------+ +---------------+ 241 Figure 1: ETSI NFV framework 243 The NFV architectural framework identifies functional blocks and the 244 main reference points between such blocks. Some of these are already 245 present in current deployments, whilst others might be necessary 246 additions in order to support the virtualization process and 247 consequent operation. The functional blocks are (Figure 2): 249 o Virtualized Network Function (VNF). 251 o Element Management (EM). 253 o NFV Infrastructure, including: Hardware and virtualized resources, 254 and Virtualization Layer. 256 o Virtualized Infrastructure Manager(s) (VIM). 258 o NFV Orchestrator. 260 o VNF Manager(s). 262 o Service, VNF and Infrastructure Description. 264 o Operations and Business Support Systems (OSS/BSS). 266 +--------------------+ 267 +-------------------------------------------+ | ---------------- | 268 | OSS/BSS | | | NFV | | 269 +-------------------------------------------+ | | Orchestrator +-- | 270 | ---+------------ | | 271 +-------------------------------------------+ | | | | 272 | --------- --------- --------- | | | | | 273 | | EM 1 | | EM 2 | | EM 3 | | | | | | 274 | ----+---- ----+---- ----+---- | | ---+---------- | | 275 | | | | |--|-| VNF | | | 276 | ----+---- ----+---- ----+---- | | | manager(s) | | | 277 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 278 | ----+---- ----+---- ----+---- | | | | | 279 +------|-------------|-------------|--------+ | | | | 280 | | | | | | | 281 +------+-------------+-------------+--------+ | | | | 282 | NFV Infrastructure (NFVI) | | | | | 283 | ----------- ----------- ----------- | | | | | 284 | | Virtual | | Virtual | | Virtual | | | | | | 285 | | Compute | | Storage | | Network | | | | | | 286 | ----------- ----------- ----------- | | ---+------ | | 287 | +---------------------------------------+ | | | | | | 288 | | Virtualization Layer | |--|-| VIM(s) +-------- | 289 | +---------------------------------------+ | | | | | 290 | +---------------------------------------+ | | ---------- | 291 | | ----------- ----------- ----------- | | | | 292 | | | Compute | | Storage | | Network | | | | | 293 | | | hardware| | hardware| | hardware| | | | | 294 | | ----------- ----------- ----------- | | | | 295 | | Hardware resources | | | NFV Management | 296 | +---------------------------------------+ | | and Orchestration | 297 +-------------------------------------------+ +--------------------+ 299 Figure 2: ETSI NFV reference architecture 301 4. Fog Virtualization Overview 303 Virtualization is invading all domains of the E2E 5G network, 304 including the access, as a mean to achieve the necessary flexibility 305 in support of the E2E slicing concept. The ETSI NFV framework is the 306 cornerstone for making virtualization such a promising technology 307 that can be matured in time for 5G. Typically, virtualization has 308 been mostly envisaged in the core network, where sophisticated data 309 centers and clouds provided the right substrate. And mostly, the 310 framework focused on virtualizing network functions, so called VNFs 311 (virtualized network functions), which were somewhat limited to 312 functions that are delay tolerant, typically from the core and 313 aggregation transport. 315 As the community has recently been developing the 5G applications and 316 their technical requirements, it has become clear that certain 317 applications would require very low latency which is extremely 318 challenging and stressing for the network to deliver through a pure 319 centralized architecture. The need to provide networking, computing, 320 and storage capabilities closer to the users has therefore emerged, 321 leading to what is known today as the concept of intelligent edge. 322 ETSI has been the first to address this need recently by developing 323 the framework of mobile edge computing (MEC). 325 Such an intelligent edge could not be envisaged without 326 virtualization. Beyond applications, it raises a clear opportunity 327 for networking functions to execute at the edge benefiting from 328 inherent low latencies. 330 Whilst it is appreciated the particular challenge for the intelligent 331 edge concept in dealing with mobile users, the edge virtualization 332 substrate has been largely assumed to be fixed or stationary. 333 Although little developed, the intelligent edge concept is being 334 extended further to scenarios where for example the edge computing 335 substrate is on the move, e.g., on-board a car or a train, or that it 336 is distributed further down the edge, even integrating resources from 337 different stakeholders, into what is known as the fog. The 338 challenges and opportunities for such extensions of the intelligent 339 edge remain an exciting area of future research. 341 Figure 3 shows a diagram representing the fog virtualization concept. 342 The fog is composed by virtual resources on top of heterogeneous 343 resources available at the edge and even further in the RAN and end- 344 user devices. These resources are therefore owned by different 345 stakeholders who collaboratively form a single hosting environment 346 for the VNFs to run. As an example, virtual resources provided to 347 the fog might be running on eNBs, APs, at micro data centers deployed 348 in shopping malls, cars, trains, etc. The fog is connected to data 349 centers deeper into the network architecture (at the edge ir the 350 core). On the top part of the figure, an example of user and control 351 plane VNFs is shown. User plane VNFs are represented as "fx", and 352 control ones as "ctrlx". Depending on the functionality implemented 353 by these VNFs and the service requirements, these VNFs would be 354 mapped (i.e., instantiated) differently to the physical resouces (as 355 described in [I-D.aranda-sfc-dp-mobile]). 357 -------- --------- --------- 358 control | ctr1 |........................| ctrl2 |...| ctrl3 | 359 plane -------- --------- --------- 360 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 361 ------ ------ ------ 362 .| f3 |.........| f5 |.....| f6 | 363 ------ ------ . ------ ------ ------ 364 user | f1 |.......| f2 |. . 365 plane ------ ------ . ------ . 366 .| f4 |............. 367 ------ 368 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 369 +--------------------------------+ +-------------------+ 370 | ------- -------- -------- | | ---------- | 371 | | | | | | | | | ---------- | | 372 | | @UE | | @car | | @eNB | | | ---------- | | | 373 | ------- -------- -------- | | | Data | | | | 374 | | | | Center | | - | 375 | -------- Heterogeneous ------- | | | (DC) |- | 376 phy | | | computing | | | | ---------- | 377 infra | |@train| devices | @AP | |==| ---------- | 378 | -------- forming ------- | | ---------- | | 379 | the fog | | ---------- | | | 380 | --------- ------------ | | | Data | | | | 381 | | | | | | | | Center | | - | 382 | | @mall | | @localDC | | | | (DC) |- | 383 | --------- ------------ | | ---------- | 384 | FOG | | CLOUD | 385 +--------------------------------+ +-------------------+ 386 <--------- fog and edge -----------------> 387 <--- edge & central cloud ---> 389 Figure 3: Fog virtualization 391 5. Problem statemement 393 Virtualized resources do not need to be limited to those available in 394 traditional data centers, where the infrastructure is stable, static, 395 typically homogeneous and managed by a single admin entity. 396 Computational capabilities are becoming more and more ubiquitous, 397 with terminal devices getting extremely powerful, as well as other 398 types of devices that are close to the end users at the edge (e.g., 399 vehicular onboard devices for infotainment, micro data centers 400 deployed at the edge, etc.). It is envisioned that these devices 401 would be able to offer storage, computing and networking resources to 402 nearby network infrastructure, devices and things (the fog paradigm). 403 These resources can be used to host functions, for example to 404 offload/complement other resources available at traditional data 405 centers, but also to reduce the end-to-end latency or to provide 406 access to specialized information (e.g., context available at the 407 edge) or hardware. 409 In this draft, we consider that a mobile terminal may: (i) provide 410 resources for others to be used, by integrating them into an existing 411 virtualization infrastructure (either fixed or mobile); and/or (ii) 412 consume resources offered by others, by integrating them into the set 413 of resources under the management of the given mobile terminal. WE 414 look at how to enable virtualization infrastructures to dynamically 415 integrate resources that are mobile and volatile (because either the 416 terminal hosting the resources is mobile/volatile or the terminal 417 controlling them is mobile/volatile). Since the fog resources are 418 volatile, i.e. may dynamically appear and disappear, and may be 419 mobile, i.e. may move from one place to another, mechanisms to 420 discover and advertise virtualized fog resources are required. 422 Taking the ETSI NFV architecture (see Section 3) as a baseline for 423 the virtualization of the fog nodes, the discovery of a 424 virtualization resource can be done either through (i) the discovery 425 of NFVI from a VIM; or through (ii) the discovery of VIMs and 426 associated NFVI from an NFVO. In this draft, we focus on the 427 alternative (ii), that is, the discovery of the VIMs and NFVI1 from 428 an NFVO. Both mobile VIM+NFVI, and mobile NFVO are in the scope of 429 the document. 431 The relationship between an NFVO and the resources it is capable to 432 orchestrate through a VIM is statically defined according to the 433 current ETSI NFV specifications [etsi_nfv_002] [etsi_nfv_ifa_005]. 434 The interface Or-Vi (between NFVO and VIM) [etsi_nfv_ifa_005] does 435 not include any discovery and automatic registration of (mobile) VIMs 436 from a (mobile) NFVO. Therefore, currently there is no standardized 437 mechanism defined for such a discovery and registration specified by 438 ETSI or any other SDO. This is the gap addressed by this draft. 440 We cover two different scenarios: 442 o A mobile terminal (hosting mobile resources) joins a network where 443 there is an existing virtualization infrastructure. The mobile 444 terminal hosts both some kind of NFVI (resources) plus a VIM (in 445 charge of managing those resources and providing an appropriate 446 interfaces for others to use and control them). 448 o A mobile terminal (looking for available resources) joins a 449 network where there are virtualization resources available. The 450 mobile terminal hosts a NFVO, capable of integrating and 451 controlling others' virtual resources. 453 6. Advertisement and discovery of mobile resources (VIM+NFVI) 455 This document describes IPv6 extensions to allow discovery of 456 virtualization resources, in the form of a VIM + associated NFVI. 457 Examples of scenarios where this is useful are shown in Figure 4 and 458 Figure 5, including also a high-level view of the solution. 460 __ 461 ___________ _( )_ 462 ---------- _( )_ ----------- _( )_ 463 | device |-(_ VIM--NFVI _) | network |-(_ NFVO _) 464 ---------- (___________) ----------- (_ _) 465 | | (__) 466 XXX (1. attachment) | 467 | | 468 +---2. Advertisement----------->| 469 | | 470 |<......(3. VIM Registration)..>| 471 | | 473 Figure 4: VIM+NFVI advertisement 475 Figure 4 shows an scenario in which a mobile device with available 476 resources (NFVI, and associated VIM) attaches to a network (step 1). 477 Then, it advertises (step 2) that it has virtualization resources 478 (and their characteristics, such as the type of VIM) that could be 479 eventually used. An NFVO sitting in the network can then decide to 480 register the VIM for later use (step 3). This document specifies 481 some options for step 2 based on IP signaling. Step 3 is 482 implementation dependent and very much VIM-NFVO specific. 484 Similarly, Figure 5 shows a scenario with a mobile NFVO. A mobile 485 device with an embedded NFVO attaches to a network (step 1). Then, 486 it queries the network (step 2) to learn if there are virtualization 487 resources available. If so, the network conveys that information 488 (step 3). The NFVO can then decide to register the VIM for later use 489 (step 4). This document specifies some options for steps 2 and 3 490 based on IP signaling. Step 4 is implementation dependent and very 491 much VIM-NFVO specific. 493 ___________ 494 _( )_ 495 ______ _( +-NFVI )_ 496 ------------ _( )_ ----------- _( / )_ 497 | terminal |-(_ NFVO _) | network |-(_ VIM(s)---NFVI _) 498 ------------ (______) ----------- (_ \ _) 499 | | (_ +-NFVI _) 500 XXX (1. attachment) | (___________) 501 | | 502 +---2. Request----------------->| 503 | | 504 |<-----------3. Advertisement---| 505 | | 506 |<..(4. VIM Registration)......>| 507 | | 509 Figure 5: VIM+NFVI discovery 511 6.1. IPv6 ND-based discovery 513 This section describes a solution based on IPv6 Neighbor Discovery 514 [RFC4861]. The solution is based on defining a new set of options to 515 convey information about available virtualization resources, 516 including optional attributes. In such a way, it is possible to 517 discover VIM+NFVI resources available at: 519 o A mobile device connecting to the network, such as a smartphone or 520 a device embedded in a vehicle. This device might have some 521 available resources that other mobile devices, or the network 522 infrastructure can opportunistically use. 524 o The network infrastructure, e.g., at the edge, like micro-data 525 centers deployed at the very edge of the network. Mobile devices 526 can use these available resources to computationally offload some 527 tasks that require low latency and/or information that is only 528 available at the edge (such as radio related information). 530 The discovery of available resources (VIM+NFVI) is based on a 531 combination of proactive and reactive advertisement. IPv6 Neighbor 532 Discovery (ND) [RFC4861] is a very good approach to convey this 533 information as, (i) it is widely deployed, (ii) it is very 534 lightweight and easy to implement, (iii) it allows dynamic updates 535 due to network topology updates (e.g., a device connecting/ 536 disconnecting from a network), and (iv) it is independent on the 537 network access technology. 539 The basic operation of ND-based VIM+NFVI discovery consists in the 540 advertisement of virtual resources in IPv6 ND messages from the 541 device hosting those virtual resources. This can be done, for 542 example by a mobile host sending unsolicited Neighbor Advertisement 543 (NA) messages (or in response to a Neighbor Solicitation, NS) 544 including the new VIM+NFVI options -- as shown in Figure 6 -- or even 545 including them in Router Solicitations. Another example would be the 546 network infrastructure advertising available resources by including 547 VIM+NFVI options in Router Advertisement (RA) or Neighbor 548 Advertisement messages -- as shown in Figure 7. 550 __ 551 ___________ _( )_ 552 ---------- _( )_ ----------- _( )_ 553 | device |-(_ VIM--NFVI _) | network |-(_ NFVO _) 554 ---------- (___________) ----------- (_ _) 555 | | (__) 556 +--Unsolicited Neigh. Advert.-->| 557 | (incld. VIM+NFVI opt.) | 558 | | 560 Figure 6: Example of VIM+NFVI advertisement via unsolicited NA 562 ___________ 563 _( )_ 564 ______ _( +-NFVI )_ 565 ------------ _( )_ ----------- _( / )_ 566 | terminal |-(_ NFVO _) | network |-(_ VIM(s)---NFVI _) 567 ------------ (______) ----------- (_ \ _) 568 | | (_ +-NFVI _) 569 |<--------Router Advertisement--+ (___________) 570 | (incld. VIM+NFVI opt.) | 571 | | 573 Figure 7: Example of VIM+NFVI advertisement via RA 575 6.2. VIM+NFVI options 577 New ND VIM+NFVI options are defined to be used with Neigbor 578 Solicitation, Neighbor Advertisement, Router Solicitation and Router 579 Advertisement options. The presence of any of these options is used 580 to signal the availability of VIM+NFVI. These options are used to 581 convey information of associated attributes, like: 583 o Available Virtualized Compute Resources. 585 o Available Virtualized Storage Resources. 587 o Available Virtualized Networking Resources. 589 o Type of virtualization e.g., full virtualization, para 590 virtualization, hybrid virtualization. 592 o Available hypervisor e.g., bare metal or hosted hypervisor. 594 o Supported virtual machine images or container format. 596 o Power profile, e.g., battery or mains powered, battery capacity, 597 charge status, etc. 599 o Volatility profile, e.g., expected availability. 601 o Type of VIM and version. 603 o Protocol APIs supported by the VIM. 605 o URI of the VIM. 607 The format of these options is described next. Note that this list 608 is just an example and that additional options could be added. 610 6.2.1. Available Virtualized Compute Resources 612 The format of this option is shown below. This option should be 613 padded when necessary to ensure that they end on their natural 64-bit 614 boundaries, as specified in [RFC4861]. 616 0 1 2 3 617 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Type | Length |N| Reserved0 | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | cpuArch | numVirtualCpu | virtualCpuClock | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | accelCapab | vCpuOP| vMemOP| virtualMemSize | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Reserved1 | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Type 630 To be assigned by IANA. 632 Length 634 2 636 N 637 1-bit NUMA supported flag. When set, indicates that the memory 638 allocation can be cognisant of the relevant process/core 639 allocation. 641 Reserved0 643 This field is unused for now. The value MUST be initialized to 0 644 by the sender and MUST be ignored by the receiver. 646 cpuArch 648 8-bit identifier indicating the type CPU architecture type. 649 Examples are: 1 (x86), 2 (ARM). 651 numVirtualCpu 653 8-bit unsigned integer. Indicates the number of virtual CPUs. 655 virtualCpuClock 657 16-bit unsigned integer. Indicates the Minimum virtual CPU clock 658 rate (in MHz). 660 accelCapab 662 8-bit mask indicating the acceleration capabilities. Examples 663 are: 1 (crypto), 2 (GPU). 665 vCpuOP 667 8-bit unsigned integer. Indicates the CPU core oversubscription 668 policy, e.g. the relation of virtual CPU cores to physical CPU 669 cores/threads. A value of 0 indicates that no concrete policy is 670 defined. 672 vMemOP 674 8-bit unsigned integer. Indicates the memory core 675 oversubscription policy in terms of virtual memory to physical 676 memory on the platform. A value of 0 indicates that no concrete 677 policy is defined. 679 Reserved1 681 This field is unused for now. The value MUST be initialized to 0 682 by the sender and MUST be ignored by the receiver. 684 6.2.2. Available Virtualized Storage Resources 686 The format of this option is shown below. This option should be 687 padded when necessary to ensure that they end on their natural 64-bit 688 boundaries, as specified in [RFC4861]. 690 0 1 2 3 691 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Type | Length | sizeOfStorage | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Reserved | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 Type 700 To be assigned by IANA. 702 Length 704 1 706 sizeOfStorage 708 16-bit unsigned integer. Indicates the Size of virtualised 709 storage resource (in GB). 711 Reserved 713 This field is unused for now. The value MUST be initialized to 0 714 by the sender and MUST be ignored by the receiver. 716 6.2.3. Available Virtualized Networking Resources 718 The format of this option is shown below. This option should be 719 padded when necessary to ensure that they end on their natural 64-bit 720 boundaries, as specified in [RFC4861]. 722 0 1 2 3 723 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Type | Length | bandwidth | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | networkType | Reserved | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 Type 731 To be assigned by IANA. 733 Length 735 1 737 bandwidth 739 16-bit unsigned integer. Indicates the minimum network bandwidth 740 (in Mbps). 742 networkType 744 8-bit unsigned identifier. Indicates the type of network that 745 maps to the virtualised network. Examples are: 1 (local), 2 746 (vlan), 3 (vxlan), 4(gre). 748 Reserved 750 This field is unused for now. The value MUST be initialized to 0 751 by the sender and MUST be ignored by the receiver. 753 6.2.4. Type of virtualization 755 The format of this option is shown below. This option should be 756 padded when necessary to ensure that they end on their natural 64-bit 757 boundaries, as specified in [RFC4861]. 759 0 1 2 3 760 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Type | Length | virtType | hypervisor | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Reserved | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 767 Type 769 To be assigned by IANA. 771 Length 773 1 775 virtType 776 8-bit identifier indicating the type of virtualization. Examples 777 are: 1 (full virtualization), 2 (para virtualization), 3 (hybrid 778 virtualization). 780 hypervisor 782 8-bit identifier indicating the type of hypervisor (if 783 applicable). Examples are: 0 (not applicable), 1 (type 1), 2 784 (type 2). 786 Reserved 788 This field is unused for now. The value MUST be initialized to 0 789 by the sender and MUST be ignored by the receiver. 791 6.2.5. Power profile 793 The format of this option is shown below. This option should be 794 padded when necessary to ensure that they end on their natural 64-bit 795 boundaries, as specified in [RFC4861]. 797 0 1 2 3 798 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Type | Length |B|C| BatStat | Reserved0 | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Reserved1 | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Type 807 To be assigned by IANA. 809 Length 811 1 813 B 815 1-bit Battery-powered flag. When set, indicates that the sending 816 device is battery powered. 818 C 820 1-bit Charging flag. If the B flag is set to 0, this MUST be set 821 to 0. When set, indicates that the battery is charging. 823 BatStat 824 6-bit integer indicating the charge of the charge of the Battery. 825 If the B flag is set to 0, this MUST be set to 0. A value of 64 826 indicates that the battery is full. 828 Reserved0 830 This field is unused for now. The value MUST be initialized to 0 831 by the sender and MUST be ignored by the receiver. 833 Reserved1 835 This field is unused for now. The value MUST be initialized to 0 836 by the sender and MUST be ignored by the receiver. 838 6.2.6. Volatility profile 840 The format of this option is shown below. This option should be 841 padded when necessary to ensure that they end on their natural 64-bit 842 boundaries, as specified in [RFC4861]. 844 0 1 2 3 845 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Type | Length | ExpectedAvailability | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Reserved | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 Type 854 To be assigned by IANA. 856 Length 858 1 860 ExpectedAvailability 862 16-bit integer indicating the expected availability (in units of 863 seconds). This is an estimation from the sender. How this is set 864 is implementation dependent. 866 Reserved 868 This field is unused for now. The value MUST be initialized to 0 869 by the sender and MUST be ignored by the receiver. 871 6.2.7. URI of the VIM 873 The format of this option is shown below. This option should be 874 padded when necessary to ensure that they end on their natural 64-bit 875 boundaries, as specified in [RFC4861]. 877 0 1 2 3 878 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Type | Length | Reserved | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | VimUri | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 885 Type 887 To be assigned by IANA. 889 Length 891 1 893 Reserved 895 This field is unused for now. The value MUST be initialized to 0 896 by the sender and MUST be ignored by the receiver. 898 VimUri 900 A variable-length encoded string containing the URI of the VIM. 902 7. IANA Considerations 904 TBD. 906 8. Security Considerations 908 TBD. 910 9. Acknowledgments 912 The work in this draft will be further developed and explored under 913 the framework of the H2020 5G-DIVE project (Grant 859881). 915 10. References 917 10.1. Normative References 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, 921 DOI 10.17487/RFC2119, March 1997, 922 . 924 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 925 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 926 DOI 10.17487/RFC4861, September 2007, 927 . 929 10.2. Informative References 931 [etsi_nfv_002] 932 ISG, E. N., ""Network Functions Virtualization (NFV); 933 Architectural Framework," ETSI GS NFV 002 v1.1.1", October 934 2013. 936 [etsi_nfv_ifa_005] 937 ISG, E. N., ""Network Functions Virtualisation (NFV) 938 Release 2; Management and Orchestration; Or-Vi reference 939 point - Interface and Information Model Specification," 940 ETSI GS NFV-IFA 005 V2.3.1", August 2017. 942 [etsi_nfv_whitepaper] 943 ISG, E. N., "Network Functions Virtualisation (NFV). White 944 Paper 2", October 2014. 946 [I-D.aranda-sfc-dp-mobile] 947 Gutierrez, P. A. A., Gramaglia, M., Lopez, D. R., and W. 948 Haeffner, "Service Function Chaining Dataplane Elements in 949 Mobile Networks", draft-aranda-sfc-dp-mobile-04 (work in 950 progress), June 2017. 952 [nfv_sota_research_challenges] 953 Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De 954 Turck, F., and R. Boutaba, "Network Function 955 Virtualization: State-of-the-art and Research Challenges", 956 IEEE Communications Surveys & Tutorials Volume: 18, Issue: 957 1, September 2015. 959 [onf_sdn_architecture] 960 (ONF), O. N. F., "SDN Architecture (Issue 1.1), ONF TR- 961 521", February 2016. 963 [RFC8568] Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., 964 Aranda, P., and P. Lynch, "Network Virtualization Research 965 Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019, 966 . 968 Authors' Addresses 970 Carlos J. Bernardos 971 Universidad Carlos III de Madrid 972 Av. Universidad, 30 973 Leganes, Madrid 28911 974 Spain 976 Phone: +34 91624 6236 977 Email: cjbc@it.uc3m.es 978 URI: http://www.it.uc3m.es/cjbc/ 980 Alain Mourad 981 InterDigital Europe 983 Email: Alain.Mourad@InterDigital.com 984 URI: http://www.InterDigital.com/