idnits 2.17.1 draft-bernardos-intarea-vim-discovery-01.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 (February 25, 2019) is 1885 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: August 29, 2019 InterDigital 6 February 25, 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-01 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 August 29, 2019. 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 144 [I-D.irtf-nfvrg-gaps-network-virtualization], by describing 145 mechanisms allowing dynamic discovery of virtualization resources and 146 orchestrators in IPv6-based networks. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in [RFC2119]. 154 While [RFC2119] describes interpretations of these key words in terms 155 of protocol specifications and implementations, they are used in this 156 document to describe requirements for the SFC mechanisms to 157 efficiently enable fog RAN. 159 The following terms used in this document are defined by the ETSI NFV 160 ISG, the ONF and the IETF: 162 NFV Infrastructure (NFVI): totality of all hardware and software 163 components which build up the environment in which VNFs are 164 deployed 166 NFV Management and Orchestration (NFV-MANO): functions 167 collectively provided by NFVO, VNFM, and VIM. 169 NFV Orchestrator (NFVO): functional block that manages the Network 170 Service (NS) lifecycle and coordinates the management of NS 171 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 172 resources (supported by the VIM) to ensure an optimized allocation 173 of the necessary resources and connectivity. 175 Virtualized Infrastructure Manager (VIM): functional block that is 176 responsible for controlling and managing the NFVI compute, storage 177 and network resources, usually within one operator's 178 Infrastructure Domain. 180 Virtualized Network Function (VNF): implementation of a Network 181 Function that can be deployed on a Network Function Virtualisation 182 Infrastructure (NFVI). 184 Virtualized Network Function Manager (VNFM): functional block that 185 is responsible for the lifecycle management of VNF. 187 3. Network Function Virtualization 189 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 190 quasi-standard IT virtualization technology to consolidate many 191 network equipment types into industry standard high volume servers, 192 switches, and storage. It enables implementing network functions in 193 software that can run on a range of industry standard server hardware 194 and can be moved to, or loaded in, various locations in the network 195 as required, without the need to install new equipment. The ETSI NFV 196 is one of the predominant NFV reference framework and architectural 197 footprints [nfv_sota_research_challenges]. The ETSI NFV framework 198 architecture framework is composed of three domains (Figure 1): 200 o Virtualized Network Function, running over the NFVI. 202 o NFV Infrastructure (NFVI), including the diversity of physical 203 resources and how these can be virtualized. NFVI supports the 204 execution of the VNFs. 206 o NFV Management and Orchestration, which covers the orchestration 207 and life-cycle management of physical and/or software resources 208 that support the infrastructure virtualization, and the life-cycle 209 management of VNFs. NFV Management and Orchestration focuses on 210 all virtualization specific management tasks necessary in the NFV 211 framework. 213 +-------------------------------------------+ +---------------+ 214 | Virtualized Network Functions (VNFs) | | | 215 | ------- ------- ------- ------- | | | 216 | | | | | | | | | | | | 217 | | VNF | | VNF | | VNF | | VNF | | | | 218 | | | | | | | | | | | | 219 | ------- ------- ------- ------- | | | 220 +-------------------------------------------+ | | 221 | | 222 +-------------------------------------------+ | | 223 | NFV Infrastructure (NFVI) | | NFV | 224 | ----------- ----------- ----------- | | Management | 225 | | Virtual | | Virtual | | Virtual | | | and | 226 | | Compute | | Storage | | Network | | | Orchestration | 227 | ----------- ----------- ----------- | | | 228 | +---------------------------------------+ | | | 229 | | Virtualization Layer | | | | 230 | +---------------------------------------+ | | | 231 | +---------------------------------------+ | | | 232 | | ----------- ----------- ----------- | | | | 233 | | | Compute | | Storage | | Network | | | | | 234 | | ----------- ----------- ----------- | | | | 235 | | Hardware resources | | | | 236 | +---------------------------------------+ | | | 237 +-------------------------------------------+ +---------------+ 239 Figure 1: ETSI NFV framework 241 The NFV architectural framework identifies functional blocks and the 242 main reference points between such blocks. Some of these are already 243 present in current deployments, whilst others might be necessary 244 additions in order to support the virtualization process and 245 consequent operation. The functional blocks are (Figure 2): 247 o Virtualized Network Function (VNF). 249 o Element Management (EM). 251 o NFV Infrastructure, including: Hardware and virtualized resources, 252 and Virtualization Layer. 254 o Virtualized Infrastructure Manager(s) (VIM). 256 o NFV Orchestrator. 258 o VNF Manager(s). 260 o Service, VNF and Infrastructure Description. 262 o Operations and Business Support Systems (OSS/BSS). 264 +--------------------+ 265 +-------------------------------------------+ | ---------------- | 266 | OSS/BSS | | | NFV | | 267 +-------------------------------------------+ | | Orchestrator +-- | 268 | ---+------------ | | 269 +-------------------------------------------+ | | | | 270 | --------- --------- --------- | | | | | 271 | | EM 1 | | EM 2 | | EM 3 | | | | | | 272 | ----+---- ----+---- ----+---- | | ---+---------- | | 273 | | | | |--|-| VNF | | | 274 | ----+---- ----+---- ----+---- | | | manager(s) | | | 275 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 276 | ----+---- ----+---- ----+---- | | | | | 277 +------|-------------|-------------|--------+ | | | | 278 | | | | | | | 279 +------+-------------+-------------+--------+ | | | | 280 | NFV Infrastructure (NFVI) | | | | | 281 | ----------- ----------- ----------- | | | | | 282 | | Virtual | | Virtual | | Virtual | | | | | | 283 | | Compute | | Storage | | Network | | | | | | 284 | ----------- ----------- ----------- | | ---+------ | | 285 | +---------------------------------------+ | | | | | | 286 | | Virtualization Layer | |--|-| VIM(s) +-------- | 287 | +---------------------------------------+ | | | | | 288 | +---------------------------------------+ | | ---------- | 289 | | ----------- ----------- ----------- | | | | 290 | | | Compute | | Storage | | Network | | | | | 291 | | | hardware| | hardware| | hardware| | | | | 292 | | ----------- ----------- ----------- | | | | 293 | | Hardware resources | | | NFV Management | 294 | +---------------------------------------+ | | and Orchestration | 295 +-------------------------------------------+ +--------------------+ 297 Figure 2: ETSI NFV reference architecture 299 4. Fog Virtualization Overview 301 Virtualization is invading all domains of the E2E 5G network, 302 including the access, as a mean to achieve the necessary flexibility 303 in support of the E2E slicing concept. The ETSI NFV framework is the 304 cornerstone for making virtualization such a promising technology 305 that can be matured in time for 5G. Typically, virtualization has 306 been mostly envisaged in the core network, where sophisticated data 307 centers and clouds provided the right substrate. And mostly, the 308 framework focused on virtualizing network functions, so called VNFs 309 (virtualized network functions), which were somewhat limited to 310 functions that are delay tolerant, typically from the core and 311 aggregation transport. 313 As the community has recently been developing the 5G applications and 314 their technical requirements, it has become clear that certain 315 applications would require very low latency which is extremely 316 challenging and stressing for the network to deliver through a pure 317 centralized architecture. The need to provide networking, computing, 318 and storage capabilities closer to the users has therefore emerged, 319 leading to what is known today as the concept of intelligent edge. 320 ETSI has been the first to address this need recently by developing 321 the framework of mobile edge computing (MEC). 323 Such an intelligent edge could not be envisaged without 324 virtualization. Beyond applications, it raises a clear opportunity 325 for networking functions to execute at the edge benefiting from 326 inherent low latencies. 328 Whilst it is appreciated the particular challenge for the intelligent 329 edge concept in dealing with mobile users, the edge virtualization 330 substrate has been largely assumed to be fixed or stationary. 331 Although little developed, the intelligent edge concept is being 332 extended further to scenarios where for example the edge computing 333 substrate is on the move, e.g., on-board a car or a train, or that it 334 is distributed further down the edge, even integrating resources from 335 different stakeholders, into what is known as the fog. The 336 challenges and opportunities for such extensions of the intelligent 337 edge remain an exciting area of future research. 339 Figure 3 shows a diagram representing the fog virtualization concept. 340 The fog is composed by virtual resources on top of heterogeneous 341 resources available at the edge and even further in the RAN and end- 342 user devices. These resources are therefore owned by different 343 stakeholders who collaboratively form a single hosting environment 344 for the VNFs to run. As an example, virtual resources provided to 345 the fog might be running on eNBs, APs, at micro data centers deployed 346 in shopping malls, cars, trains, etc. The fog is connected to data 347 centers deeper into the network architecture (at the edge ir the 348 core). On the top part of the figure, an example of user and control 349 plane VNFs is shown. User plane VNFs are represented as "fx", and 350 control ones as "ctrlx". Depending on the functionality implemented 351 by these VNFs and the service requirements, these VNFs would be 352 mapped (i.e., instantiated) differently to the physical resouces (as 353 described in [I-D.aranda-sfc-dp-mobile]). 355 -------- --------- --------- 356 control | ctr1 |........................| ctrl2 |...| ctrl3 | 357 plane -------- --------- --------- 358 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 359 ------ ------ ------ 360 .| f3 |.........| f5 |.....| f6 | 361 ------ ------ . ------ ------ ------ 362 user | f1 |.......| f2 |. . 363 plane ------ ------ . ------ . 364 .| f4 |............. 365 ------ 366 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 367 +--------------------------------+ +-------------------+ 368 | ------- -------- -------- | | ---------- | 369 | | | | | | | | | ---------- | | 370 | | @UE | | @car | | @eNB | | | ---------- | | | 371 | ------- -------- -------- | | | Data | | | | 372 | | | | Center | | - | 373 | -------- Heterogeneous ------- | | | (DC) |- | 374 phy | | | computing | | | | ---------- | 375 infra | |@train| devices | @AP | |==| ---------- | 376 | -------- forming ------- | | ---------- | | 377 | the fog | | ---------- | | | 378 | --------- ------------ | | | Data | | | | 379 | | | | | | | | Center | | - | 380 | | @mall | | @localDC | | | | (DC) |- | 381 | --------- ------------ | | ---------- | 382 | FOG | | CLOUD | 383 +--------------------------------+ +-------------------+ 384 <--------- fog and edge -----------------> 385 <--- edge & central cloud ---> 387 Figure 3: Fog virtualization 389 5. Problem statemement 391 Virtualized resources do not need to be limited to those available in 392 traditional data centers, where the infrastructure is stable, static, 393 typically homogeneous and managed by a single admin entity. 394 Computational capabilities are becoming more and more ubiquitous, 395 with terminal devices getting extremely powerful, as well as other 396 types of devices that are close to the end users at the edge (e.g., 397 vehicular onboard devices for infotainment, micro data centers 398 deployed at the edge, etc.). It is envisioned that these devices 399 would be able to offer storage, computing and networking resources to 400 nearby network infrastructure, devices and things (the fog paradigm). 401 These resources can be used to host functions, for example to 402 offload/complement other resources available at traditional data 403 centers, but also to reduce the end-to-end latency or to provide 404 access to specialized information (e.g., context available at the 405 edge) or hardware. 407 In this draft, we consider that a mobile terminal may: (i) provide 408 resources for others to be used, by integrating them into an existing 409 virtualization infrastructure (either fixed or mobile); and/or (ii) 410 consume resources offered by others, by integrating them into the set 411 of resources under the management of the given mobile terminal. WE 412 look at how to enable virtualization infrastructures to dynamically 413 integrate resources that are mobile and volatile (because either the 414 terminal hosting the resources is mobile/volatile or the terminal 415 controlling them is mobile/volatile). Since the fog resources are 416 volatile, i.e. may dynamically appear and disappear, and may be 417 mobile, i.e. may move from one place to another, mechanisms to 418 discover and advertise virtualized fog resources are required. 420 Taking the ETSI NFV architecture (see Section 3) as a baseline for 421 the virtualization of the fog nodes, the discovery of a 422 virtualization resource can be done either through (i) the discovery 423 of NFVI from a VIM; or through (ii) the discovery of VIMs and 424 associated NFVI from an NFVO. In this draft, we focus on the 425 alternative (ii), that is, the discovery of the VIMs and NFVI1 from 426 an NFVO. Both mobile VIM+NFVI, and mobile NFVO are in the scope of 427 the document. 429 The relationship between an NFVO and the resources it is capable to 430 orchestrate through a VIM is statically defined according to the 431 current ETSI NFV specifications [etsi_nfv_002] [etsi_nfv_ifa_005]. 432 The interface Or-Vi (between NFVO and VIM) [etsi_nfv_ifa_005] does 433 not include any discovery and automatic registration of (mobile) VIMs 434 from a (mobile) NFVO. Therefore, currently there is no standardized 435 mechanism defined for such a discovery and registration specified by 436 ETSI or any other SDO. This is the gap addressed by this draft. 438 We cover two different scenarios: 440 o A mobile terminal (hosting mobile resources) joins a network where 441 there is an existing virtualization infrastructure. The mobile 442 terminal hosts both some kind of NFVI (resources) plus a VIM (in 443 charge of managing those resources and providing an appropriate 444 interfaces for others to use and control them). 446 o A mobile terminal (looking for available resources) joins a 447 network where there are virtualization resources available. The 448 mobile terminal hosts a NFVO, capable of integrating and 449 controlling others' virtual resources. 451 6. Advertisement and discovery of mobile resources (VIM+NFVI) 453 This document describes IPv6 extensions to allow discovery of 454 virtualization resources, in the form of a VIM + associated NFVI. 455 Examples of scenarios where this is useful are shown in Figure 4 and 456 Figure 5, including also a high-level view of the solution. 458 __ 459 ___________ _( )_ 460 ---------- _( )_ ----------- _( )_ 461 | device |-(_ VIM--NFVI _) | network |-(_ NFVO _) 462 ---------- (___________) ----------- (_ _) 463 | | (__) 464 XXX (1. attachment) | 465 | | 466 +---2. Advertisement----------->| 467 | | 468 |<......(3. VIM Registration)..>| 469 | | 471 Figure 4: VIM+NFVI advertisement 473 Figure 4 shows an scenario in which a mobile device with available 474 resources (NFVI, and associated VIM) attaches to a network (step 1). 475 Then, it advertises (step 2) that it has virtualization resources 476 (and their characteristics, such as the type of VIM) that could be 477 eventually used. An NFVO sitting in the network can then decide to 478 register the VIM for later use (step 3). This document specifies 479 some options for step 2 based on IP signaling. Step 3 is 480 implementation dependent and very much VIM-NFVO specific. 482 Similarly, Figure 5 shows a scenario with a mobile NFVO. A mobile 483 device with an embedded NFVO attaches to a network (step 1). Then, 484 it queries the network (step 2) to learn if there are virtualization 485 resources available. If so, the network conveys that information 486 (step 3). The NFVO can then decide to register the VIM for later use 487 (step 4). This document specifies some options for steps 2 and 3 488 based on IP signaling. Step 4 is implementation dependent and very 489 much VIM-NFVO specific. 491 ___________ 492 _( )_ 493 ______ _( +-NFVI )_ 494 ------------ _( )_ ----------- _( / )_ 495 | terminal |-(_ NFVO _) | network |-(_ VIM(s)---NFVI _) 496 ------------ (______) ----------- (_ \ _) 497 | | (_ +-NFVI _) 498 XXX (1. attachment) | (___________) 499 | | 500 +---2. Request----------------->| 501 | | 502 |<-----------3. Advertisement---| 503 | | 504 |<..(4. VIM Registration)......>| 505 | | 507 Figure 5: VIM+NFVI discovery 509 6.1. IPv6 ND-based discovery 511 This section describes a solution based on IPv6 Neighbor Discovery 512 [RFC4861]. The solution is based on defining a new set of options to 513 convey information about available virtualization resources, 514 including optional attributes. In such a way, it is possible to 515 discover VIM+NFVI resources available at: 517 o A mobile device connecting to the network, such as a smartphone or 518 a device embedded in a vehicle. This device might have some 519 available resources that other mobile devices, or the network 520 infrastructure can opportunistically use. 522 o The network infrastructure, e.g., at the edge, like micro-data 523 centers deployed at the very edge of the network. Mobile devices 524 can use these available resources to computationally offload some 525 tasks that require low latency and/or information that is only 526 available at the edge (such as radio related information). 528 The discovery of available resources (VIM+NFVI) is based on a 529 combination of proactive and reactive advertisement. IPv6 Neighbor 530 Discovery (ND) [RFC4861] is a very good approach to convey this 531 information as, (i) it is widely deployed, (ii) it is very 532 lightweight and easy to implement, (iii) it allows dynamic updates 533 due to network topology updates (e.g., a device connecting/ 534 disconnecting from a network), and (iv) it is independent on the 535 network access technology. 537 The basic operation of ND-based VIM+NFVI discovery consists in the 538 advertisement of virtual resources in IPv6 ND messages from the 539 device hosting those virtual resources. This can be done, for 540 example by a mobile host sending unsolicited Neighbor Advertisement 541 (NA) messages (or in response to a Neighbor Solicitation, NS) 542 including the new VIM+NFVI options -- as shown in Figure 6 -- or even 543 including them in Router Solicitations. Another example would be the 544 network infrastructure advertising available resources by including 545 VIM+NFVI options in Router Advertisement (RA) or Neighbor 546 Advertisement messages -- as shown in Figure 7. 548 __ 549 ___________ _( )_ 550 ---------- _( )_ ----------- _( )_ 551 | device |-(_ VIM--NFVI _) | network |-(_ NFVO _) 552 ---------- (___________) ----------- (_ _) 553 | | (__) 554 +--Unsolicited Neigh. Advert.-->| 555 | (incld. VIM+NFVI opt.) | 556 | | 558 Figure 6: Example of VIM+NFVI advertisement via unsolicited NA 560 ___________ 561 _( )_ 562 ______ _( +-NFVI )_ 563 ------------ _( )_ ----------- _( / )_ 564 | terminal |-(_ NFVO _) | network |-(_ VIM(s)---NFVI _) 565 ------------ (______) ----------- (_ \ _) 566 | | (_ +-NFVI _) 567 |<--------Router Advertisement--+ (___________) 568 | (incld. VIM+NFVI opt.) | 569 | | 571 Figure 7: Example of VIM+NFVI advertisement via RA 573 6.2. VIM+NFVI options 575 New ND VIM+NFVI options are defined to be used with Neigbor 576 Solicitation, Neighbor Advertisement, Router Solicitation and Router 577 Advertisement options. The presence of any of these options is used 578 to signal the availability of VIM+NFVI. These options are used to 579 convey information of associated attributes, like: 581 o Available Virtualized Compute Resources. 583 o Available Virtualized Storage Resources. 585 o Available Virtualized Networking Resources. 587 o Type of virtualization e.g., full virtualization, para 588 virtualization, hybrid virtualization. 590 o Available hypervisor e.g., bare metal or hosted hypervisor. 592 o Supported virtual machine images or container format. 594 o Power profile, e.g., battery or mains powered, battery capacity, 595 charge status, etc. 597 o Volatility profile, e.g., expected availability. 599 o Type of VIM and version. 601 o Protocol APIs supported by the VIM. 603 o URI of the VIM. 605 The format of these options is described next. Note that this list 606 is just an example and that additional options could be added. 608 6.2.1. Available Virtualized Compute Resources 610 The format of this option is shown below. This option should be 611 padded when necessary to ensure that they end on their natural 64-bit 612 boundaries, as specified in [RFC4861]. 614 0 1 2 3 615 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 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | Type | Length |N| Reserved0 | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | cpuArch | numVirtualCpu | virtualCpuClock | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | accelCapab | vCpuOP| vMemOP| virtualMemSize | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Reserved1 | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Type 628 To be assigned by IANA. 630 Length 632 2 634 N 635 1-bit NUMA supported flag. When set, indicates that the memory 636 allocation can be cognisant of the relevant process/core 637 allocation. 639 Reserved0 641 This field is unused for now. The value MUST be initialized to 0 642 by the sender and MUST be ignored by the receiver. 644 cpuArch 646 8-bit identifier indicating the type CPU architecture type. 647 Examples are: 1 (x86), 2 (ARM). 649 numVirtualCpu 651 8-bit unsigned integer. Indicates the number of virtual CPUs. 653 virtualCpuClock 655 16-bit unsigned integer. Indicates the Minimum virtual CPU clock 656 rate (in MHz). 658 accelCapab 660 8-bit mask indicating the acceleration capabilities. Examples 661 are: 1 (crypto), 2 (GPU). 663 vCpuOP 665 8-bit unsigned integer. Indicates the CPU core oversubscription 666 policy, e.g. the relation of virtual CPU cores to physical CPU 667 cores/threads. A value of 0 indicates that no concrete policy is 668 defined. 670 vMemOP 672 8-bit unsigned integer. Indicates the memory core 673 oversubscription policy in terms of virtual memory to physical 674 memory on the platform. A value of 0 indicates that no concrete 675 policy is defined. 677 Reserved1 679 This field is unused for now. The value MUST be initialized to 0 680 by the sender and MUST be ignored by the receiver. 682 6.2.2. Available Virtualized Storage Resources 684 The format of this option is shown below. This option should be 685 padded when necessary to ensure that they end on their natural 64-bit 686 boundaries, as specified in [RFC4861]. 688 0 1 2 3 689 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 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | Type | Length | sizeOfStorage | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Reserved | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 Type 698 To be assigned by IANA. 700 Length 702 1 704 sizeOfStorage 706 16-bit unsigned integer. Indicates the Size of virtualised 707 storage resource (in GB). 709 Reserved 711 This field is unused for now. The value MUST be initialized to 0 712 by the sender and MUST be ignored by the receiver. 714 6.2.3. Available Virtualized Networking Resources 716 The format of this option is shown below. This option should be 717 padded when necessary to ensure that they end on their natural 64-bit 718 boundaries, as specified in [RFC4861]. 720 0 1 2 3 721 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 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Type | Length | bandwidth | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | networkType | Reserved | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 Type 729 To be assigned by IANA. 731 Length 733 1 735 bandwidth 737 16-bit unsigned integer. Indicates the minimum network bandwidth 738 (in Mbps). 740 networkType 742 8-bit unsigned identifier. Indicates the type of network that 743 maps to the virtualised network. Examples are: 1 (local), 2 744 (vlan), 3 (vxlan), 4(gre). 746 Reserved 748 This field is unused for now. The value MUST be initialized to 0 749 by the sender and MUST be ignored by the receiver. 751 6.2.4. Type of virtualization 753 The format of this option is shown below. This option should be 754 padded when necessary to ensure that they end on their natural 64-bit 755 boundaries, as specified in [RFC4861]. 757 0 1 2 3 758 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 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | Type | Length | virtType | hypervisor | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 | Reserved | 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 Type 767 To be assigned by IANA. 769 Length 771 1 773 virtType 774 8-bit identifier indicating the type of virtualization. Examples 775 are: 1 (full virtualization), 2 (para virtualization), 3 (hybrid 776 virtualization). 778 hypervisor 780 8-bit identifier indicating the type of hypervisor (if 781 applicable). Examples are: 0 (not applicable), 1 (type 1), 2 782 (type 2). 784 Reserved 786 This field is unused for now. The value MUST be initialized to 0 787 by the sender and MUST be ignored by the receiver. 789 6.2.5. Power profile 791 The format of this option is shown below. This option should be 792 padded when necessary to ensure that they end on their natural 64-bit 793 boundaries, as specified in [RFC4861]. 795 0 1 2 3 796 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 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Type | Length |B|C| BatStat | Reserved0 | 799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 | Reserved1 | 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 Type 805 To be assigned by IANA. 807 Length 809 1 811 B 813 1-bit Battery-powered flag. When set, indicates that the sending 814 device is battery powered. 816 C 818 1-bit Charging flag. If the B flag is set to 0, this MUST be set 819 to 0. When set, indicates that the battery is charging. 821 BatStat 822 6-bit integer indicating the charge of the charge of the Battery. 823 If the B flag is set to 0, this MUST be set to 0. A value of 64 824 indicates that the battery is full. 826 Reserved0 828 This field is unused for now. The value MUST be initialized to 0 829 by the sender and MUST be ignored by the receiver. 831 Reserved1 833 This field is unused for now. The value MUST be initialized to 0 834 by the sender and MUST be ignored by the receiver. 836 6.2.6. Volatility profile 838 The format of this option is shown below. This option should be 839 padded when necessary to ensure that they end on their natural 64-bit 840 boundaries, as specified in [RFC4861]. 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Type | Length | ExpectedAvailability | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Reserved | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 Type 852 To be assigned by IANA. 854 Length 856 1 858 ExpectedAvailability 860 16-bit integer indicating the expected availability (in units of 861 seconds). This is an estimation from the sender. How this is set 862 is implementation dependent. 864 Reserved 866 This field is unused for now. The value MUST be initialized to 0 867 by the sender and MUST be ignored by the receiver. 869 6.2.7. URI of the VIM 871 The format of this option is shown below. This option should be 872 padded when necessary to ensure that they end on their natural 64-bit 873 boundaries, as specified in [RFC4861]. 875 0 1 2 3 876 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 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Type | Length | Reserved | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | VimUri | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 Type 885 To be assigned by IANA. 887 Length 889 1 891 Reserved 893 This field is unused for now. The value MUST be initialized to 0 894 by the sender and MUST be ignored by the receiver. 896 VimUri 898 A variable-length encoded string containing the URI of the VIM. 900 7. IANA Considerations 902 TBD. 904 8. Security Considerations 906 TBD. 908 9. Acknowledgments 910 The work in this draft will be further developed and explored under 911 the framework of the H2020 5G-CORAL project (Grant 761586). 913 10. References 915 10.1. Normative References 917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, 919 DOI 10.17487/RFC2119, March 1997, 920 . 922 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 923 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 924 DOI 10.17487/RFC4861, September 2007, 925 . 927 10.2. Informative References 929 [etsi_nfv_002] 930 ""Network Functions Virtualization (NFV); Architectural 931 Framework," ETSI GS NFV 002 v1.1.1", October 2013. 933 [etsi_nfv_ifa_005] 934 ""Network Functions Virtualisation (NFV) Release 2; 935 Management and Orchestration; Or-Vi reference point - 936 Interface and Information Model Specification," ETSI GS 937 NFV-IFA 005 V2.3.1", August 2017. 939 [etsi_nfv_whitepaper] 940 "Network Functions Virtualisation (NFV). White Paper 2", 941 October 2014. 943 [I-D.aranda-sfc-dp-mobile] 944 Gutierrez, P., Gramaglia, M., Lopez, D., and W. Haeffner, 945 "Service Function Chaining Dataplane Elements in Mobile 946 Networks", draft-aranda-sfc-dp-mobile-04 (work in 947 progress), June 2017. 949 [I-D.irtf-nfvrg-gaps-network-virtualization] 950 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 951 Aranda, P., and P. Lynch, "Network Virtualization Research 952 Challenges", draft-irtf-nfvrg-gaps-network- 953 virtualization-10 (work in progress), September 2018. 955 [nfv_sota_research_challenges] 956 Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De 957 Turck, F., and R. Boutaba, "Network Function 958 Virtualization: State-of-the-art and Research Challenges", 959 IEEE Communications Surveys & Tutorials Volume: 18, Issue: 960 1, September 2015. 962 [onf_sdn_architecture] 963 "SDN Architecture (Issue 1.1), ONF TR-521", February 2016. 965 Authors' Addresses 967 Carlos J. Bernardos 968 Universidad Carlos III de Madrid 969 Av. Universidad, 30 970 Leganes, Madrid 28911 971 Spain 973 Phone: +34 91624 6236 974 Email: cjbc@it.uc3m.es 975 URI: http://www.it.uc3m.es/cjbc/ 977 Alain Mourad 978 InterDigital Europe 980 Email: Alain.Mourad@InterDigital.com 981 URI: http://www.InterDigital.com/