idnits 2.17.1 draft-bernardos-nfvrg-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 5, 2018) is 2243 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 (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFV RG CJ. Bernardos 3 Internet-Draft UC3M 4 Intended status: Experimental A. Mourad 5 Expires: September 6, 2018 InterDigital 6 March 5, 2018 8 IPv6-based discovery and association of Virtualization Infrastructure 9 Manager (VIM) and Network Function Virtualization Orchestrator (NFVO) 10 draft-bernardos-nfvrg-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 September 6, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Network Function Virtualization . . . . . . . . . . . . . . . 4 70 4. Fog Virtualization Overview . . . . . . . . . . . . . . . . . 7 71 5. Problem statemement . . . . . . . . . . . . . . . . . . . . . 8 72 6. Advertisement and discovery of mobile resources (VIM+NFVI) . 9 73 6.1. IPv6 ND-based discovery . . . . . . . . . . . . . . . . . 11 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 79 10.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 82 1. Introduction 84 The telecommunications sector is experiencing a major revolution that 85 will shape the way networks and services are designed and deployed 86 for the next decade. We are witnessing an explosion in the number of 87 applications and services demanded by users, which are now really 88 capable of accessing them on the move. In order to cope with such a 89 demand, some network operators are looking at the cloud computing 90 paradigm, which enables a potential reduction of the overall costs by 91 outsourcing communication services from specific hardware in the 92 operator's core to server farms scattered in data centers. These 93 services have different characteristics if compared with conventional 94 IT services that have to be taken into account in this cloudification 95 process. Also the transport network is affected in that it is 96 evolving to a more sophisticated form of IP architecture with trends 97 like separation of control and data plane traffic, and more fine- 98 grained forwarding of packets (beyond looking at the destination IP 99 address) in the network to fulfill new business and service goals. 101 Virtualization of functions also provides operators with tools to 102 deploy new services much faster, as compared to the traditional use 103 of monolithic and tightly integrated dedicated machinery. As a 104 natural next step, mobile network operators need to re-think how to 105 evolve their existing network infrastructures and how to deploy new 106 ones to address the challenges posed by the increasing customers' 107 demands, as well as by the huge competition among operators. All 108 these changes are triggering the need for a modification in the way 109 operators and infrastructure providers operate their networks, as 110 they need to significantly reduce the costs incurred in deploying a 111 new service and operating it. Some of the mechanisms that are being 112 considered and already adopted by operators include: sharing of 113 network infrastructure to reduce costs, virtualization of core 114 servers running in data centers as a way of supporting their load- 115 aware elastic dimensioning, and dynamic energy policies to reduce the 116 monthly electricity bill. However, this has proved to be tough to 117 put in practice, and not enough. Indeed, it is not easy to deploy 118 new mechanisms in a running operational network due to the high 119 dependency on proprietary (and sometime obscure) protocols and 120 interfaces, which are complex to manage and often require configuring 121 multiple devices in a decentralized way. 123 Network function virtualization (NFV) [etsi_nfv_whitepaper] and 124 software defined networking (SDN) [onf_sdn_architecture] are changing 125 the way the telecommunications sector will deploy, extend and operate 126 their networks. The ETSI NFV Industry Specification Group (ISG) is 127 developing the baseline NFV architecture, under some assumptions to 128 make this development easier. One of these assumptions is that the 129 resources used to run the virtualized functions are well known in 130 advance by the management and orchestration entities, as well as 131 stable. This document goes beyond this assumption 132 [I-D.irtf-nfvrg-gaps-network-virtualization], by describing 133 mechanisms allowing dynamic discovery of virtualization resources and 134 orchestrators in IPv6-based networks. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 While [RFC2119] describes interpretations of these key words in terms 143 of protocol specifications and implementations, they are used in this 144 document to describe requirements for the SFC mechanisms to 145 efficiently enable fog RAN. 147 The following terms used in this document are defined by the ETSI NFV 148 ISG, the ONF and the IETF: 150 NFV Infrastructure (NFVI): totality of all hardware and software 151 components which build up the environment in which VNFs are 152 deployed 154 NFV Management and Orchestration (NFV-MANO): functions 155 collectively provided by NFVO, VNFM, and VIM. 157 NFV Orchestrator (NFVO): functional block that manages the Network 158 Service (NS) lifecycle and coordinates the management of NS 159 lifecycle, VNF lifecycle (supported by the VNFM) and NFVI 160 resources (supported by the VIM) to ensure an optimized allocation 161 of the necessary resources and connectivity. 163 Virtualized Infrastructure Manager (VIM): functional block that is 164 responsible for controlling and managing the NFVI compute, storage 165 and network resources, usually within one operator's 166 Infrastructure Domain. 168 Virtualized Network Function (VNF): implementation of a Network 169 Function that can be deployed on a Network Function Virtualisation 170 Infrastructure (NFVI). 172 Virtualized Network Function Manager (VNFM): functional block that 173 is responsible for the lifecycle management of VNF. 175 3. Network Function Virtualization 177 The ETSI ISG NFV is a working group which, since 2012, aims to evolve 178 quasi-standard IT virtualization technology to consolidate many 179 network equipment types into industry standard high volume servers, 180 switches, and storage. It enables implementing network functions in 181 software that can run on a range of industry standard server hardware 182 and can be moved to, or loaded in, various locations in the network 183 as required, without the need to install new equipment. The ETSI NFV 184 is one of the predominant NFV reference framework and architectural 185 footprints [nfv_sota_research_challenges]. The ETSI NFV framework 186 architecture framework is composed of three domains (Figure 1): 188 o Virtualized Network Function, running over the NFVI. 190 o NFV Infrastructure (NFVI), including the diversity of physical 191 resources and how these can be virtualized. NFVI supports the 192 execution of the VNFs. 194 o NFV Management and Orchestration, which covers the orchestration 195 and life-cycle management of physical and/or software resources 196 that support the infrastructure virtualization, and the life-cycle 197 management of VNFs. NFV Management and Orchestration focuses on 198 all virtualization specific management tasks necessary in the NFV 199 framework. 201 +-------------------------------------------+ +---------------+ 202 | Virtualized Network Functions (VNFs) | | | 203 | ------- ------- ------- ------- | | | 204 | | | | | | | | | | | | 205 | | VNF | | VNF | | VNF | | VNF | | | | 206 | | | | | | | | | | | | 207 | ------- ------- ------- ------- | | | 208 +-------------------------------------------+ | | 209 | | 210 +-------------------------------------------+ | | 211 | NFV Infrastructure (NFVI) | | NFV | 212 | ----------- ----------- ----------- | | Management | 213 | | Virtual | | Virtual | | Virtual | | | and | 214 | | Compute | | Storage | | Network | | | Orchestration | 215 | ----------- ----------- ----------- | | | 216 | +---------------------------------------+ | | | 217 | | Virtualization Layer | | | | 218 | +---------------------------------------+ | | | 219 | +---------------------------------------+ | | | 220 | | ----------- ----------- ----------- | | | | 221 | | | Compute | | Storage | | Network | | | | | 222 | | ----------- ----------- ----------- | | | | 223 | | Hardware resources | | | | 224 | +---------------------------------------+ | | | 225 +-------------------------------------------+ +---------------+ 227 Figure 1: ETSI NFV framework 229 The NFV architectural framework identifies functional blocks and the 230 main reference points between such blocks. Some of these are already 231 present in current deployments, whilst others might be necessary 232 additions in order to support the virtualization process and 233 consequent operation. The functional blocks are (Figure 2): 235 o Virtualized Network Function (VNF). 237 o Element Management (EM). 239 o NFV Infrastructure, including: Hardware and virtualized resources, 240 and Virtualization Layer. 242 o Virtualized Infrastructure Manager(s) (VIM). 244 o NFV Orchestrator. 246 o VNF Manager(s). 248 o Service, VNF and Infrastructure Description. 250 o Operations and Business Support Systems (OSS/BSS). 252 +--------------------+ 253 +-------------------------------------------+ | ---------------- | 254 | OSS/BSS | | | NFV | | 255 +-------------------------------------------+ | | Orchestrator +-- | 256 | ---+------------ | | 257 +-------------------------------------------+ | | | | 258 | --------- --------- --------- | | | | | 259 | | EM 1 | | EM 2 | | EM 3 | | | | | | 260 | ----+---- ----+---- ----+---- | | ---+---------- | | 261 | | | | |--|-| VNF | | | 262 | ----+---- ----+---- ----+---- | | | manager(s) | | | 263 | | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | | 264 | ----+---- ----+---- ----+---- | | | | | 265 +------|-------------|-------------|--------+ | | | | 266 | | | | | | | 267 +------+-------------+-------------+--------+ | | | | 268 | NFV Infrastructure (NFVI) | | | | | 269 | ----------- ----------- ----------- | | | | | 270 | | Virtual | | Virtual | | Virtual | | | | | | 271 | | Compute | | Storage | | Network | | | | | | 272 | ----------- ----------- ----------- | | ---+------ | | 273 | +---------------------------------------+ | | | | | | 274 | | Virtualization Layer | |--|-| VIM(s) +-------- | 275 | +---------------------------------------+ | | | | | 276 | +---------------------------------------+ | | ---------- | 277 | | ----------- ----------- ----------- | | | | 278 | | | Compute | | Storage | | Network | | | | | 279 | | | hardware| | hardware| | hardware| | | | | 280 | | ----------- ----------- ----------- | | | | 281 | | Hardware resources | | | NFV Management | 282 | +---------------------------------------+ | | and Orchestration | 283 +-------------------------------------------+ +--------------------+ 285 Figure 2: ETSI NFV reference architecture 287 4. Fog Virtualization Overview 289 Virtualization is invading all domains of the E2E 5G network, 290 including the access, as a mean to achieve the necessary flexibility 291 in support of the E2E slicing concept. The ETSI NFV framework is the 292 cornerstone for making virtualization such a promising technology 293 that can be matured in time for 5G. Typically, virtualization has 294 been mostly envisaged in the core network, where sophisticated data 295 centers and clouds provided the right substrate. And mostly, the 296 framework focused on virtualizing network functions, so called VNFs 297 (virtualized network functions), which were somewhat limited to 298 functions that are delay tolerant, typically from the core and 299 aggregation transport. 301 As the community has recently been developing the 5G applications and 302 their technical requirements, it has become clear that certain 303 applications would require very low latency which is extremely 304 challenging and stressing for the network to deliver through a pure 305 centralized architecture. The need to provide networking, computing, 306 and storage capabilities closer to the users has therefore emerged, 307 leading to what is known today as the concept of intelligent edge. 308 ETSI has been the first to address this need recently by developing 309 the framework of mobile edge computing (MEC). 311 Such an intelligent edge could not be envisaged without 312 virtualization. Beyond applications, it raises a clear opportunity 313 for networking functions to execute at the edge benefiting from 314 inherent low latencies. 316 Whilst it is appreciated the particular challenge for the intelligent 317 edge concept in dealing with mobile users, the edge virtualization 318 substrate has been largely assumed to be fixed or stationary. 319 Although little developed, the intelligent edge concept is being 320 extended further to scenarios where for example the edge computing 321 substrate is on the move, e.g., on-board a car or a train, or that it 322 is distributed further down the edge, even integrating resources from 323 different stakeholders, into what is known as the fog. The 324 challenges and opportunities for such extensions of the intelligent 325 edge remain an exciting area of future research. 327 Figure 3 shows a diagram representing the fog virtualization concept. 328 The fog is composed by virtual resources on top of heterogeneous 329 resources available at the edge and even further in the RAN and end- 330 user devices. These resources are therefore owned by different 331 stakeholders who collaboratively form a single hosting environment 332 for the VNFs to run. As an example, virtual resources provided to 333 the fog might be running on eNBs, APs, at micro data centers deployed 334 in shopping malls, cars, trains, etc. The fog is connected to data 335 centers deeper into the network architecture (at the edge ir the 336 core). On the top part of the figure, an example of user and control 337 plane VNFs is shown. User plane VNFs are represented as "fx", and 338 control ones as "ctrlx". Depending on the functionality implemented 339 by these VNFs and the service requirements, these VNFs would be 340 mapped (i.e., instantiated) differently to the physical resouces (as 341 described in [I-D.aranda-sfc-dp-mobile]). 343 -------- --------- --------- 344 control | ctr1 |........................| ctrl2 |...| ctrl3 | 345 plane -------- --------- --------- 346 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 347 ------ ------ ------ 348 .| f3 |.........| f5 |.....| f6 | 349 ------ ------ . ------ ------ ------ 350 user | f1 |.......| f2 |. . 351 plane ------ ------ . ------ . 352 .| f4 |............. 353 ------ 354 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 355 +--------------------------------+ +-------------------+ 356 | ------- -------- -------- | | ---------- | 357 | | | | | | | | | ---------- | | 358 | | @UE | | @car | | @eNB | | | ---------- | | | 359 | ------- -------- -------- | | | Data | | | | 360 | | | | Center | | - | 361 | -------- Heterogeneous ------- | | | (DC) |- | 362 phy | | | computing | | | | ---------- | 363 infra | |@train| devices | @AP | |==| ---------- | 364 | -------- forming ------- | | ---------- | | 365 | the fog | | ---------- | | | 366 | --------- ------------ | | | Data | | | | 367 | | | | | | | | Center | | - | 368 | | @mall | | @localDC | | | | (DC) |- | 369 | --------- ------------ | | ---------- | 370 | FOG | | CLOUD | 371 +--------------------------------+ +-------------------+ 372 <--------- fog and edge -----------------> 373 <--- edge & central cloud ---> 375 Figure 3: Fog virtualization 377 5. Problem statemement 379 Virtualized resources do not need to be limited to those available in 380 traditional data centers, where the infrastructure is stable, static, 381 typically homogeneous and managed by a single admin entity. 382 Computational capabilities are becoming more and more ubiquitous, 383 with terminal devices getting extremely powerful, as well as other 384 types of devices that are close to the end users at the edge (e.g., 385 vehicular onboard devices for infotainment, micro data centers 386 deployed at the edge, etc.). It is envisioned that these devices 387 would be able to offer storage, computing and networking resources to 388 nearby network infrastructure, devices and things (the fog paradigm). 389 These resources can be used to host functions, for example to 390 offload/complement other resources available at traditional data 391 centers, but also to reduce the end-to-end latency or to provide 392 access to specialized information (e.g., context available at the 393 edge) or hardware. 395 Since the fog resources are volatile, i.e. may dynamically appear and 396 disappear, and may be mobile, i.e. may move from one place to 397 another, mechanisms to discover and advertise virtualized fog 398 resources are required. 400 Taking ETSI NFV architecture (see Section 3) as a baseline for the 401 virtualization of the fog nodes, the discovery of a virtualization 402 resource can be done either through (i) the discovery of NFVI from a 403 VIM; or through (ii) the discovery of VIMs and associated NFVI from 404 an NFVO. In this document we focus on the alternative ii) that is 405 the discovery of the VIMs and NFVI from an NFVO. This is so because 406 a VIM is typically NFVI-specific, and therefore these two are more 407 often than not tied together. 409 The relationship between an NFVO and the resources it is capable to 410 orchestrate through a VIM is statically defined according to the 411 current ETSI NFV specifications [etsi_nfv_002] [etsi_nfv_ifa_005]. 412 The interface Or-Vi (between NFVO and VIM) [etsi_nfv_ifa_005] does 413 not include any discovery and automatic registration of (mobile) VIMs 414 from a (mobile) NFVO. 416 6. Advertisement and discovery of mobile resources (VIM+NFVI) 418 This document describes IPv6 extensions to allow discovery of 419 virtualization resources, in the form of a VIM + associated NFVI. 420 Examples of scenarios where this is useful are shown in Figure 4 and 421 Figure 5, including also a high-level view of the solution. 423 __ 424 ___________ _( )_ 425 ------------ _( )_ ----------- _( )_ 426 | terminal |-(_ VIM--NFVI _) | network |-(_ NFVO _) 427 ------------ (___________) ----------- (_ _) 428 | | (__) 429 XXX (1. attachment) | 430 | | 431 +---2. Advertisement----------->| 432 | | 433 |<......(3. VIM Registration)...+ 434 | | 436 Figure 4: VIM+NFVI advertisement 438 Figure 4 shows an scenario in which a mobile terminal with available 439 resources (NFVI, and associated VIM) attaches to a network (step 1). 440 Then, it advertises (step 2) that it has virtualization resources 441 (and their characteristics, such as the type of VIM) that could be 442 eventually used. An NFVO sitting in the network can then decide to 443 register the VIM for later use (step 3). This document specifies 444 some options for step 2 based on IP signaling. Step 3 is 445 implementation dependent and very much VIM-NFVO specific. 447 Similarly, Figure 5 shows a scenario with a mobile NFVO. A mobile 448 terminal with an embedded NFVO attaches to a network (step 1). Then, 449 it queries the network (step 2) to learn if there are virtualization 450 resources available. If so, the network conveys that information 451 (step 3). The NFVO can then decide to register the VIM for later use 452 (step 4). This document specifies some options for steps 2 and 3 453 based on IP signaling. Step 4 is implementation dependent and very 454 much VIM-NFVO specific. 456 ___________ 457 _( )_ 458 ______ _( +-NFVI )_ 459 ------------ _( )_ ----------- _( / )_ 460 | terminal |-(_ NFVO _) | network |-(_ VIM(s)---NFVI _) 461 ------------ (______) ----------- (_ \ _) 462 | | (_ +-NFVI _) 463 XXX (1. attachment) | (___________) 464 | | 465 +---2. Request----------------->| 466 | | 467 |<-----------3. Advertisement---| 468 | | 469 +...(4. VIM Registration)......>| 470 | | 472 Figure 5: VIM+NFVI discovery 474 6.1. IPv6 ND-based discovery 476 TBD. 478 7. IANA Considerations 480 N/A. 482 8. Security Considerations 484 TBD. 486 9. Acknowledgments 488 The work in this draft will be further developed and explored under 489 the framework of the H2020 5G-CORAL project (Grant 761586). 491 10. References 493 10.1. Normative References 495 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 496 Requirement Levels", BCP 14, RFC 2119, 497 DOI 10.17487/RFC2119, March 1997, 498 . 500 10.2. Informative References 502 [etsi_nfv_002] 503 ""Network Functions Virtualization (NFV); Architectural 504 Framework," ETSI GS NFV 002 v1.1.1", October 2013. 506 [etsi_nfv_ifa_005] 507 ""Network Functions Virtualisation (NFV) Release 2; 508 Management and Orchestration; Or-Vi reference point - 509 Interface and Information Model Specification," ETSI GS 510 NFV-IFA 005 V2.3.1", August 2017. 512 [etsi_nfv_whitepaper] 513 "Network Functions Virtualisation (NFV). White Paper 2", 514 October 2014. 516 [I-D.aranda-sfc-dp-mobile] 517 Gutierrez, P., Gramaglia, M., Lopez, D., and W. Haeffner, 518 "Service Function Chaining Dataplane Elements in Mobile 519 Networks", draft-aranda-sfc-dp-mobile-04 (work in 520 progress), June 2017. 522 [I-D.irtf-nfvrg-gaps-network-virtualization] 523 Bernardos, C., Rahman, A., Zuniga, J., Contreras, L., 524 Aranda, P., and P. Lynch, "Network Virtualization Research 525 Challenges", draft-irtf-nfvrg-gaps-network- 526 virtualization-09 (work in progress), February 2018. 528 [nfv_sota_research_challenges] 529 Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De 530 Turck, F., and R. Boutaba, "Network Function 531 Virtualization: State-of-the-art and Research Challenges", 532 IEEE Communications Surveys & Tutorials Volume: 18, Issue: 533 1, September 2015. 535 [onf_sdn_architecture] 536 "SDN Architecture (Issue 1.1), ONF TR-521", February 2016. 538 Authors' Addresses 539 Carlos J. Bernardos 540 Universidad Carlos III de Madrid 541 Av. Universidad, 30 542 Leganes, Madrid 28911 543 Spain 545 Phone: +34 91624 6236 546 Email: cjbc@it.uc3m.es 547 URI: http://www.it.uc3m.es/cjbc/ 549 Alain Mourad 550 InterDigital Europe 552 Email: Alain.Mourad@InterDigital.com 553 URI: http://www.InterDigital.com/