idnits 2.17.1 draft-bernardos-intarea-vim-discovery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- 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 (August 26, 2019) is 1706 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: February 27, 2020 InterDigital 6 August 26, 2019 8 IPv6-based discovery and association of Virtualization Infrastructure 9 Manager (VIM) and Network Function Virtualization Orchestrator (NFVO) 10 draft-bernardos-intarea-vim-discovery-02 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 February 27, 2020. 54 Copyright Notice 56 Copyright (c) 2019 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. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 While [RFC2119] describes interpretations of these key words in terms 154 of protocol specifications and implementations, they are used in this 155 document to describe requirements for the SFC mechanisms to 156 efficiently enable fog RAN. 158 The following terms used in this document are defined by the ETSI NFV 159 ISG, the ONF and the IETF: 161 NFV Infrastructure (NFVI): totality of all hardware and software 162 components which build up the environment in which VNFs are 163 deployed 165 NFV Management and Orchestration (NFV-MANO): functions 166 collectively provided by NFVO, VNFM, and VIM. 168 NFV Orchestrator (NFVO): functional block that manages the Network 169 Service (NS) lifecycle and coordinates the management of NS 170 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 171 resources (supported by the VIM) to ensure an optimized allocation 172 of the necessary resources and connectivity. 174 Virtualized Infrastructure Manager (VIM): functional block that is 175 responsible for controlling and managing the NFVI compute, storage 176 and network resources, usually within one operator's 177 Infrastructure Domain. 179 Virtualized Network Function (VNF): implementation of a Network 180 Function that can be deployed on a Network Function Virtualisation 181 Infrastructure (NFVI). 183 Virtualized Network Function Manager (VNFM): functional block that 184 is responsible for the lifecycle management of VNF. 186 3. Network Function Virtualization 188 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 189 quasi-standard IT virtualization technology to consolidate many 190 network equipment types into industry standard high volume servers, 191 switches, and storage. It enables implementing network functions in 192 software that can run on a range of industry standard server hardware 193 and can be moved to, or loaded in, various locations in the network 194 as required, without the need to install new equipment. The ETSI NFV 195 is one of the predominant NFV reference framework and architectural 196 footprints [nfv_sota_research_challenges]. The ETSI NFV framework 197 architecture framework is composed of three domains (Figure 1): 199 o Virtualized Network Function, running over the NFVI. 201 o NFV Infrastructure (NFVI), including the diversity of physical 202 resources and how these can be virtualized. NFVI supports the 203 execution of the VNFs. 205 o NFV Management and Orchestration, which covers the orchestration 206 and life-cycle management of physical and/or software resources 207 that support the infrastructure virtualization, and the life-cycle 208 management of VNFs. NFV Management and Orchestration focuses on 209 all virtualization specific management tasks necessary in the NFV 210 framework. 212 +-------------------------------------------+ +---------------+ 213 | Virtualized Network Functions (VNFs) | | | 214 | ------- ------- ------- ------- | | | 215 | | | | | | | | | | | | 216 | | VNF | | VNF | | VNF | | VNF | | | | 217 | | | | | | | | | | | | 218 | ------- ------- ------- ------- | | | 219 +-------------------------------------------+ | | 220 | | 221 +-------------------------------------------+ | | 222 | NFV Infrastructure (NFVI) | | NFV | 223 | ----------- ----------- ----------- | | Management | 224 | | Virtual | | Virtual | | Virtual | | | and | 225 | | Compute | | Storage | | Network | | | Orchestration | 226 | ----------- ----------- ----------- | | | 227 | +---------------------------------------+ | | | 228 | | Virtualization Layer | | | | 229 | +---------------------------------------+ | | | 230 | +---------------------------------------+ | | | 231 | | ----------- ----------- ----------- | | | | 232 | | | Compute | | Storage | | Network | | | | | 233 | | ----------- ----------- ----------- | | | | 234 | | Hardware resources | | | | 235 | +---------------------------------------+ | | | 236 +-------------------------------------------+ +---------------+ 238 Figure 1: ETSI NFV framework 240 The NFV architectural framework identifies functional blocks and the 241 main reference points between such blocks. Some of these are already 242 present in current deployments, whilst others might be necessary 243 additions in order to support the virtualization process and 244 consequent operation. The functional blocks are (Figure 2): 246 o Virtualized Network Function (VNF). 248 o Element Management (EM). 250 o NFV Infrastructure, including: Hardware and virtualized resources, 251 and Virtualization Layer. 253 o Virtualized Infrastructure Manager(s) (VIM). 255 o NFV Orchestrator. 257 o VNF Manager(s). 259 o Service, VNF and Infrastructure Description. 261 o Operations and Business Support Systems (OSS/BSS). 263 +--------------------+ 264 +-------------------------------------------+ | ---------------- | 265 | OSS/BSS | | | NFV | | 266 +-------------------------------------------+ | | Orchestrator +-- | 267 | ---+------------ | | 268 +-------------------------------------------+ | | | | 269 | --------- --------- --------- | | | | | 270 | | EM 1 | | EM 2 | | EM 3 | | | | | | 271 | ----+---- ----+---- ----+---- | | ---+---------- | | 272 | | | | |--|-| VNF | | | 273 | ----+---- ----+---- ----+---- | | | manager(s) | | | 274 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 275 | ----+---- ----+---- ----+---- | | | | | 276 +------|-------------|-------------|--------+ | | | | 277 | | | | | | | 278 +------+-------------+-------------+--------+ | | | | 279 | NFV Infrastructure (NFVI) | | | | | 280 | ----------- ----------- ----------- | | | | | 281 | | Virtual | | Virtual | | Virtual | | | | | | 282 | | Compute | | Storage | | Network | | | | | | 283 | ----------- ----------- ----------- | | ---+------ | | 284 | +---------------------------------------+ | | | | | | 285 | | Virtualization Layer | |--|-| VIM(s) +-------- | 286 | +---------------------------------------+ | | | | | 287 | +---------------------------------------+ | | ---------- | 288 | | ----------- ----------- ----------- | | | | 289 | | | Compute | | Storage | | Network | | | | | 290 | | | hardware| | hardware| | hardware| | | | | 291 | | ----------- ----------- ----------- | | | | 292 | | Hardware resources | | | NFV Management | 293 | +---------------------------------------+ | | and Orchestration | 294 +-------------------------------------------+ +--------------------+ 296 Figure 2: ETSI NFV reference architecture 298 4. Fog Virtualization Overview 300 Virtualization is invading all domains of the E2E 5G network, 301 including the access, as a mean to achieve the necessary flexibility 302 in support of the E2E slicing concept. The ETSI NFV framework is the 303 cornerstone for making virtualization such a promising technology 304 that can be matured in time for 5G. Typically, virtualization has 305 been mostly envisaged in the core network, where sophisticated data 306 centers and clouds provided the right substrate. And mostly, the 307 framework focused on virtualizing network functions, so called VNFs 308 (virtualized network functions), which were somewhat limited to 309 functions that are delay tolerant, typically from the core and 310 aggregation transport. 312 As the community has recently been developing the 5G applications and 313 their technical requirements, it has become clear that certain 314 applications would require very low latency which is extremely 315 challenging and stressing for the network to deliver through a pure 316 centralized architecture. The need to provide networking, computing, 317 and storage capabilities closer to the users has therefore emerged, 318 leading to what is known today as the concept of intelligent edge. 319 ETSI has been the first to address this need recently by developing 320 the framework of mobile edge computing (MEC). 322 Such an intelligent edge could not be envisaged without 323 virtualization. Beyond applications, it raises a clear opportunity 324 for networking functions to execute at the edge benefiting from 325 inherent low latencies. 327 Whilst it is appreciated the particular challenge for the intelligent 328 edge concept in dealing with mobile users, the edge virtualization 329 substrate has been largely assumed to be fixed or stationary. 330 Although little developed, the intelligent edge concept is being 331 extended further to scenarios where for example the edge computing 332 substrate is on the move, e.g., on-board a car or a train, or that it 333 is distributed further down the edge, even integrating resources from 334 different stakeholders, into what is known as the fog. The 335 challenges and opportunities for such extensions of the intelligent 336 edge remain an exciting area of future research. 338 Figure 3 shows a diagram representing the fog virtualization concept. 339 The fog is composed by virtual resources on top of heterogeneous 340 resources available at the edge and even further in the RAN and end- 341 user devices. These resources are therefore owned by different 342 stakeholders who collaboratively form a single hosting environment 343 for the VNFs to run. As an example, virtual resources provided to 344 the fog might be running on eNBs, APs, at micro data centers deployed 345 in shopping malls, cars, trains, etc. The fog is connected to data 346 centers deeper into the network architecture (at the edge ir the 347 core). On the top part of the figure, an example of user and control 348 plane VNFs is shown. User plane VNFs are represented as "fx", and 349 control ones as "ctrlx". Depending on the functionality implemented 350 by these VNFs and the service requirements, these VNFs would be 351 mapped (i.e., instantiated) differently to the physical resouces (as 352 described in [I-D.aranda-sfc-dp-mobile]). 354 -------- --------- --------- 355 control | ctr1 |........................| ctrl2 |...| ctrl3 | 356 plane -------- --------- --------- 357 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 358 ------ ------ ------ 359 .| f3 |.........| f5 |.....| f6 | 360 ------ ------ . ------ ------ ------ 361 user | f1 |.......| f2 |. . 362 plane ------ ------ . ------ . 363 .| f4 |............. 364 ------ 365 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 366 +--------------------------------+ +-------------------+ 367 | ------- -------- -------- | | ---------- | 368 | | | | | | | | | ---------- | | 369 | | @UE | | @car | | @eNB | | | ---------- | | | 370 | ------- -------- -------- | | | Data | | | | 371 | | | | Center | | - | 372 | -------- Heterogeneous ------- | | | (DC) |- | 373 phy | | | computing | | | | ---------- | 374 infra | |@train| devices | @AP | |==| ---------- | 375 | -------- forming ------- | | ---------- | | 376 | the fog | | ---------- | | | 377 | --------- ------------ | | | Data | | | | 378 | | | | | | | | Center | | - | 379 | | @mall | | @localDC | | | | (DC) |- | 380 | --------- ------------ | | ---------- | 381 | FOG | | CLOUD | 382 +--------------------------------+ +-------------------+ 383 <--------- fog and edge -----------------> 384 <--- edge & central cloud ---> 386 Figure 3: Fog virtualization 388 5. Problem statemement 390 Virtualized resources do not need to be limited to those available in 391 traditional data centers, where the infrastructure is stable, static, 392 typically homogeneous and managed by a single admin entity. 393 Computational capabilities are becoming more and more ubiquitous, 394 with terminal devices getting extremely powerful, as well as other 395 types of devices that are close to the end users at the edge (e.g., 396 vehicular onboard devices for infotainment, micro data centers 397 deployed at the edge, etc.). It is envisioned that these devices 398 would be able to offer storage, computing and networking resources to 399 nearby network infrastructure, devices and things (the fog paradigm). 400 These resources can be used to host functions, for example to 401 offload/complement other resources available at traditional data 402 centers, but also to reduce the end-to-end latency or to provide 403 access to specialized information (e.g., context available at the 404 edge) or hardware. 406 In this draft, we consider that a mobile terminal may: (i) provide 407 resources for others to be used, by integrating them into an existing 408 virtualization infrastructure (either fixed or mobile); and/or (ii) 409 consume resources offered by others, by integrating them into the set 410 of resources under the management of the given mobile terminal. WE 411 look at how to enable virtualization infrastructures to dynamically 412 integrate resources that are mobile and volatile (because either the 413 terminal hosting the resources is mobile/volatile or the terminal 414 controlling them is mobile/volatile). Since the fog resources are 415 volatile, i.e. may dynamically appear and disappear, and may be 416 mobile, i.e. may move from one place to another, mechanisms to 417 discover and advertise virtualized fog resources are required. 419 Taking the ETSI NFV architecture (see Section 3) as a baseline for 420 the virtualization of the fog nodes, the discovery of a 421 virtualization resource can be done either through (i) the discovery 422 of NFVI from a VIM; or through (ii) the discovery of VIMs and 423 associated NFVI from an NFVO. In this draft, we focus on the 424 alternative (ii), that is, the discovery of the VIMs and NFVI1 from 425 an NFVO. Both mobile VIM+NFVI, and mobile NFVO are in the scope of 426 the document. 428 The relationship between an NFVO and the resources it is capable to 429 orchestrate through a VIM is statically defined according to the 430 current ETSI NFV specifications [etsi_nfv_002] [etsi_nfv_ifa_005]. 431 The interface Or-Vi (between NFVO and VIM) [etsi_nfv_ifa_005] does 432 not include any discovery and automatic registration of (mobile) VIMs 433 from a (mobile) NFVO. Therefore, currently there is no standardized 434 mechanism defined for such a discovery and registration specified by 435 ETSI or any other SDO. This is the gap addressed by this draft. 437 We cover two different scenarios: 439 o A mobile terminal (hosting mobile resources) joins a network where 440 there is an existing virtualization infrastructure. The mobile 441 terminal hosts both some kind of NFVI (resources) plus a VIM (in 442 charge of managing those resources and providing an appropriate 443 interfaces for others to use and control them). 445 o A mobile terminal (looking for available resources) joins a 446 network where there are virtualization resources available. The 447 mobile terminal hosts a NFVO, capable of integrating and 448 controlling others' virtual resources. 450 6. Advertisement and discovery of mobile resources (VIM+NFVI) 452 This document describes IPv6 extensions to allow discovery of 453 virtualization resources, in the form of a VIM + associated NFVI. 454 Examples of scenarios where this is useful are shown in Figure 4 and 455 Figure 5, including also a high-level view of the solution. 457 __ 458 ___________ _( )_ 459 ---------- _( )_ ----------- _( )_ 460 | device |-(_ VIM--NFVI _) | network |-(_ NFVO _) 461 ---------- (___________) ----------- (_ _) 462 | | (__) 463 XXX (1. attachment) | 464 | | 465 +---2. Advertisement----------->| 466 | | 467 |<......(3. VIM Registration)..>| 468 | | 470 Figure 4: VIM+NFVI advertisement 472 Figure 4 shows an scenario in which a mobile device with available 473 resources (NFVI, and associated VIM) attaches to a network (step 1). 474 Then, it advertises (step 2) that it has virtualization resources 475 (and their characteristics, such as the type of VIM) that could be 476 eventually used. An NFVO sitting in the network can then decide to 477 register the VIM for later use (step 3). This document specifies 478 some options for step 2 based on IP signaling. Step 3 is 479 implementation dependent and very much VIM-NFVO specific. 481 Similarly, Figure 5 shows a scenario with a mobile NFVO. A mobile 482 device with an embedded NFVO attaches to a network (step 1). Then, 483 it queries the network (step 2) to learn if there are virtualization 484 resources available. If so, the network conveys that information 485 (step 3). The NFVO can then decide to register the VIM for later use 486 (step 4). This document specifies some options for steps 2 and 3 487 based on IP signaling. Step 4 is implementation dependent and very 488 much VIM-NFVO specific. 490 ___________ 491 _( )_ 492 ______ _( +-NFVI )_ 493 ------------ _( )_ ----------- _( / )_ 494 | terminal |-(_ NFVO _) | network |-(_ VIM(s)---NFVI _) 495 ------------ (______) ----------- (_ \ _) 496 | | (_ +-NFVI _) 497 XXX (1. attachment) | (___________) 498 | | 499 +---2. Request----------------->| 500 | | 501 |<-----------3. Advertisement---| 502 | | 503 |<..(4. VIM Registration)......>| 504 | | 506 Figure 5: VIM+NFVI discovery 508 6.1. IPv6 ND-based discovery 510 This section describes a solution based on IPv6 Neighbor Discovery 511 [RFC4861]. The solution is based on defining a new set of options to 512 convey information about available virtualization resources, 513 including optional attributes. In such a way, it is possible to 514 discover VIM+NFVI resources available at: 516 o A mobile device connecting to the network, such as a smartphone or 517 a device embedded in a vehicle. This device might have some 518 available resources that other mobile devices, or the network 519 infrastructure can opportunistically use. 521 o The network infrastructure, e.g., at the edge, like micro-data 522 centers deployed at the very edge of the network. Mobile devices 523 can use these available resources to computationally offload some 524 tasks that require low latency and/or information that is only 525 available at the edge (such as radio related information). 527 The discovery of available resources (VIM+NFVI) is based on a 528 combination of proactive and reactive advertisement. IPv6 Neighbor 529 Discovery (ND) [RFC4861] is a very good approach to convey this 530 information as, (i) it is widely deployed, (ii) it is very 531 lightweight and easy to implement, (iii) it allows dynamic updates 532 due to network topology updates (e.g., a device connecting/ 533 disconnecting from a network), and (iv) it is independent on the 534 network access technology. 536 The basic operation of ND-based VIM+NFVI discovery consists in the 537 advertisement of virtual resources in IPv6 ND messages from the 538 device hosting those virtual resources. This can be done, for 539 example by a mobile host sending unsolicited Neighbor Advertisement 540 (NA) messages (or in response to a Neighbor Solicitation, NS) 541 including the new VIM+NFVI options -- as shown in Figure 6 -- or even 542 including them in Router Solicitations. Another example would be the 543 network infrastructure advertising available resources by including 544 VIM+NFVI options in Router Advertisement (RA) or Neighbor 545 Advertisement messages -- as shown in Figure 7. 547 __ 548 ___________ _( )_ 549 ---------- _( )_ ----------- _( )_ 550 | device |-(_ VIM--NFVI _) | network |-(_ NFVO _) 551 ---------- (___________) ----------- (_ _) 552 | | (__) 553 +--Unsolicited Neigh. Advert.-->| 554 | (incld. VIM+NFVI opt.) | 555 | | 557 Figure 6: Example of VIM+NFVI advertisement via unsolicited NA 559 ___________ 560 _( )_ 561 ______ _( +-NFVI )_ 562 ------------ _( )_ ----------- _( / )_ 563 | terminal |-(_ NFVO _) | network |-(_ VIM(s)---NFVI _) 564 ------------ (______) ----------- (_ \ _) 565 | | (_ +-NFVI _) 566 |<--------Router Advertisement--+ (___________) 567 | (incld. VIM+NFVI opt.) | 568 | | 570 Figure 7: Example of VIM+NFVI advertisement via RA 572 6.2. VIM+NFVI options 574 New ND VIM+NFVI options are defined to be used with Neigbor 575 Solicitation, Neighbor Advertisement, Router Solicitation and Router 576 Advertisement options. The presence of any of these options is used 577 to signal the availability of VIM+NFVI. These options are used to 578 convey information of associated attributes, like: 580 o Available Virtualized Compute Resources. 582 o Available Virtualized Storage Resources. 584 o Available Virtualized Networking Resources. 586 o Type of virtualization e.g., full virtualization, para 587 virtualization, hybrid virtualization. 589 o Available hypervisor e.g., bare metal or hosted hypervisor. 591 o Supported virtual machine images or container format. 593 o Power profile, e.g., battery or mains powered, battery capacity, 594 charge status, etc. 596 o Volatility profile, e.g., expected availability. 598 o Type of VIM and version. 600 o Protocol APIs supported by the VIM. 602 o URI of the VIM. 604 The format of these options is described next. Note that this list 605 is just an example and that additional options could be added. 607 6.2.1. Available Virtualized Compute Resources 609 The format of this option is shown below. This option should be 610 padded when necessary to ensure that they end on their natural 64-bit 611 boundaries, as specified in [RFC4861]. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type | Length |N| Reserved0 | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | cpuArch | numVirtualCpu | virtualCpuClock | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | accelCapab | vCpuOP| vMemOP| virtualMemSize | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Reserved1 | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Type 627 To be assigned by IANA. 629 Length 631 2 633 N 634 1-bit NUMA supported flag. When set, indicates that the memory 635 allocation can be cognisant of the relevant process/core 636 allocation. 638 Reserved0 640 This field is unused for now. The value MUST be initialized to 0 641 by the sender and MUST be ignored by the receiver. 643 cpuArch 645 8-bit identifier indicating the type CPU architecture type. 646 Examples are: 1 (x86), 2 (ARM). 648 numVirtualCpu 650 8-bit unsigned integer. Indicates the number of virtual CPUs. 652 virtualCpuClock 654 16-bit unsigned integer. Indicates the Minimum virtual CPU clock 655 rate (in MHz). 657 accelCapab 659 8-bit mask indicating the acceleration capabilities. Examples 660 are: 1 (crypto), 2 (GPU). 662 vCpuOP 664 8-bit unsigned integer. Indicates the CPU core oversubscription 665 policy, e.g. the relation of virtual CPU cores to physical CPU 666 cores/threads. A value of 0 indicates that no concrete policy is 667 defined. 669 vMemOP 671 8-bit unsigned integer. Indicates the memory core 672 oversubscription policy in terms of virtual memory to physical 673 memory on the platform. A value of 0 indicates that no concrete 674 policy is defined. 676 Reserved1 678 This field is unused for now. The value MUST be initialized to 0 679 by the sender and MUST be ignored by the receiver. 681 6.2.2. Available Virtualized Storage Resources 683 The format of this option is shown below. This option should be 684 padded when necessary to ensure that they end on their natural 64-bit 685 boundaries, as specified in [RFC4861]. 687 0 1 2 3 688 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 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 | Type | Length | sizeOfStorage | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Reserved | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 Type 697 To be assigned by IANA. 699 Length 701 1 703 sizeOfStorage 705 16-bit unsigned integer. Indicates the Size of virtualised 706 storage resource (in GB). 708 Reserved 710 This field is unused for now. The value MUST be initialized to 0 711 by the sender and MUST be ignored by the receiver. 713 6.2.3. Available Virtualized Networking Resources 715 The format of this option is shown below. This option should be 716 padded when necessary to ensure that they end on their natural 64-bit 717 boundaries, as specified in [RFC4861]. 719 0 1 2 3 720 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 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Type | Length | bandwidth | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | networkType | Reserved | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 Type 728 To be assigned by IANA. 730 Length 732 1 734 bandwidth 736 16-bit unsigned integer. Indicates the minimum network bandwidth 737 (in Mbps). 739 networkType 741 8-bit unsigned identifier. Indicates the type of network that 742 maps to the virtualised network. Examples are: 1 (local), 2 743 (vlan), 3 (vxlan), 4(gre). 745 Reserved 747 This field is unused for now. The value MUST be initialized to 0 748 by the sender and MUST be ignored by the receiver. 750 6.2.4. Type of virtualization 752 The format of this option is shown below. This option should be 753 padded when necessary to ensure that they end on their natural 64-bit 754 boundaries, as specified in [RFC4861]. 756 0 1 2 3 757 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 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Type | Length | virtType | hypervisor | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Reserved | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 Type 766 To be assigned by IANA. 768 Length 770 1 772 virtType 773 8-bit identifier indicating the type of virtualization. Examples 774 are: 1 (full virtualization), 2 (para virtualization), 3 (hybrid 775 virtualization). 777 hypervisor 779 8-bit identifier indicating the type of hypervisor (if 780 applicable). Examples are: 0 (not applicable), 1 (type 1), 2 781 (type 2). 783 Reserved 785 This field is unused for now. The value MUST be initialized to 0 786 by the sender and MUST be ignored by the receiver. 788 6.2.5. Power profile 790 The format of this option is shown below. This option should be 791 padded when necessary to ensure that they end on their natural 64-bit 792 boundaries, as specified in [RFC4861]. 794 0 1 2 3 795 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 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Type | Length |B|C| BatStat | Reserved0 | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Reserved1 | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 Type 804 To be assigned by IANA. 806 Length 808 1 810 B 812 1-bit Battery-powered flag. When set, indicates that the sending 813 device is battery powered. 815 C 817 1-bit Charging flag. If the B flag is set to 0, this MUST be set 818 to 0. When set, indicates that the battery is charging. 820 BatStat 821 6-bit integer indicating the charge of the charge of the Battery. 822 If the B flag is set to 0, this MUST be set to 0. A value of 64 823 indicates that the battery is full. 825 Reserved0 827 This field is unused for now. The value MUST be initialized to 0 828 by the sender and MUST be ignored by the receiver. 830 Reserved1 832 This field is unused for now. The value MUST be initialized to 0 833 by the sender and MUST be ignored by the receiver. 835 6.2.6. Volatility profile 837 The format of this option is shown below. This option should be 838 padded when necessary to ensure that they end on their natural 64-bit 839 boundaries, as specified in [RFC4861]. 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Type | Length | ExpectedAvailability | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Reserved | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Type 851 To be assigned by IANA. 853 Length 855 1 857 ExpectedAvailability 859 16-bit integer indicating the expected availability (in units of 860 seconds). This is an estimation from the sender. How this is set 861 is implementation dependent. 863 Reserved 865 This field is unused for now. The value MUST be initialized to 0 866 by the sender and MUST be ignored by the receiver. 868 6.2.7. URI of the VIM 870 The format of this option is shown below. This option should be 871 padded when necessary to ensure that they end on their natural 64-bit 872 boundaries, as specified in [RFC4861]. 874 0 1 2 3 875 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 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Type | Length | Reserved | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | VimUri | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 Type 884 To be assigned by IANA. 886 Length 888 1 890 Reserved 892 This field is unused for now. The value MUST be initialized to 0 893 by the sender and MUST be ignored by the receiver. 895 VimUri 897 A variable-length encoded string containing the URI of the VIM. 899 7. IANA Considerations 901 TBD. 903 8. Security Considerations 905 TBD. 907 9. Acknowledgments 909 The work in this draft will be further developed and explored under 910 the framework of the H2020 5G-CORAL project (Grant 761586). 912 10. References 914 10.1. Normative References 916 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 917 Requirement Levels", BCP 14, RFC 2119, 918 DOI 10.17487/RFC2119, March 1997, 919 . 921 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 922 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 923 DOI 10.17487/RFC4861, September 2007, 924 . 926 10.2. Informative References 928 [etsi_nfv_002] 929 ""Network Functions Virtualization (NFV); Architectural 930 Framework," ETSI GS NFV 002 v1.1.1", October 2013. 932 [etsi_nfv_ifa_005] 933 ""Network Functions Virtualisation (NFV) Release 2; 934 Management and Orchestration; Or-Vi reference point - 935 Interface and Information Model Specification," ETSI GS 936 NFV-IFA 005 V2.3.1", August 2017. 938 [etsi_nfv_whitepaper] 939 "Network Functions Virtualisation (NFV). White Paper 2", 940 October 2014. 942 [I-D.aranda-sfc-dp-mobile] 943 Gutierrez, P., Gramaglia, M., Lopez, D., and W. Haeffner, 944 "Service Function Chaining Dataplane Elements in Mobile 945 Networks", draft-aranda-sfc-dp-mobile-04 (work in 946 progress), June 2017. 948 [nfv_sota_research_challenges] 949 Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De 950 Turck, F., and R. Boutaba, "Network Function 951 Virtualization: State-of-the-art and Research Challenges", 952 IEEE Communications Surveys & Tutorials Volume: 18, Issue: 953 1, September 2015. 955 [onf_sdn_architecture] 956 "SDN Architecture (Issue 1.1), ONF TR-521", February 2016. 958 [RFC8568] Bernardos, CJ., Rahman, A., Zuniga, JC., Contreras, LM., 959 Aranda, P., and P. Lynch, "Network Virtualization Research 960 Challenges", RFC 8568, DOI 10.17487/RFC8568, April 2019, 961 . 963 Authors' Addresses 965 Carlos J. Bernardos 966 Universidad Carlos III de Madrid 967 Av. Universidad, 30 968 Leganes, Madrid 28911 969 Spain 971 Phone: +34 91624 6236 972 Email: cjbc@it.uc3m.es 973 URI: http://www.it.uc3m.es/cjbc/ 975 Alain Mourad 976 InterDigital Europe 978 Email: Alain.Mourad@InterDigital.com 979 URI: http://www.InterDigital.com/