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