Internet DRAFT - draft-bernardos-nfvrg-vim-discovery
draft-bernardos-nfvrg-vim-discovery
NFV RG CJ. Bernardos
Internet-Draft UC3M
Intended status: Experimental A. Mourad
Expires: September 6, 2018 InterDigital
March 5, 2018
IPv6-based discovery and association of Virtualization Infrastructure
Manager (VIM) and Network Function Virtualization Orchestrator (NFVO)
draft-bernardos-nfvrg-vim-discovery-00
Abstract
Virtualized resources do not need to be limited to those available in
traditional data centers, where the infrastructure is stable, static,
typically homogeneous and managed by a single admin entity.
Computational capabilities are becoming more and more ubiquitous,
with terminal devices getting extremely powerful, as well as other
types of devices that are close to the end users at the edge (e.g.,
vehicular onboard devices for infotainment, micro data centers
deployed at the edge, etc.). It is envisioned that these devices
would be able to offer storage, computing and networking resources to
nearby network infrastructure, devices and things (the fog paradigm).
These resources can be used to host functions, for example to
offload/complement other resources available at traditional data
centers, but also to reduce the end-to-end latency or to provide
access to specialized information (e.g., context available at the
edge) or hardware.
This document describes mechanisms allowing dynamic discovery of
virtualization resources and orchestrators in IPv6-based networks.
New IPv6 neighbor discovery options are defined.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Bernardos & Mourad Expires September 6, 2018 [Page 1]
Internet-Draft VIM+NFVI discovery March 2018
This Internet-Draft will expire on September 6, 2018.
Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Network Function Virtualization . . . . . . . . . . . . . . . 4
4. Fog Virtualization Overview . . . . . . . . . . . . . . . . . 7
5. Problem statemement . . . . . . . . . . . . . . . . . . . . . 8
6. Advertisement and discovery of mobile resources (VIM+NFVI) . 9
6.1. IPv6 ND-based discovery . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The telecommunications sector is experiencing a major revolution that
will shape the way networks and services are designed and deployed
for the next decade. We are witnessing an explosion in the number of
applications and services demanded by users, which are now really
capable of accessing them on the move. In order to cope with such a
demand, some network operators are looking at the cloud computing
paradigm, which enables a potential reduction of the overall costs by
outsourcing communication services from specific hardware in the
operator's core to server farms scattered in data centers. These
services have different characteristics if compared with conventional
IT services that have to be taken into account in this cloudification
process. Also the transport network is affected in that it is
Bernardos & Mourad Expires September 6, 2018 [Page 2]
Internet-Draft VIM+NFVI discovery March 2018
evolving to a more sophisticated form of IP architecture with trends
like separation of control and data plane traffic, and more fine-
grained forwarding of packets (beyond looking at the destination IP
address) in the network to fulfill new business and service goals.
Virtualization of functions also provides operators with tools to
deploy new services much faster, as compared to the traditional use
of monolithic and tightly integrated dedicated machinery. As a
natural next step, mobile network operators need to re-think how to
evolve their existing network infrastructures and how to deploy new
ones to address the challenges posed by the increasing customers'
demands, as well as by the huge competition among operators. All
these changes are triggering the need for a modification in the way
operators and infrastructure providers operate their networks, as
they need to significantly reduce the costs incurred in deploying a
new service and operating it. Some of the mechanisms that are being
considered and already adopted by operators include: sharing of
network infrastructure to reduce costs, virtualization of core
servers running in data centers as a way of supporting their load-
aware elastic dimensioning, and dynamic energy policies to reduce the
monthly electricity bill. However, this has proved to be tough to
put in practice, and not enough. Indeed, it is not easy to deploy
new mechanisms in a running operational network due to the high
dependency on proprietary (and sometime obscure) protocols and
interfaces, which are complex to manage and often require configuring
multiple devices in a decentralized way.
Network function virtualization (NFV) [etsi_nfv_whitepaper] and
software defined networking (SDN) [onf_sdn_architecture] are changing
the way the telecommunications sector will deploy, extend and operate
their networks. The ETSI NFV Industry Specification Group (ISG) is
developing the baseline NFV architecture, under some assumptions to
make this development easier. One of these assumptions is that the
resources used to run the virtualized functions are well known in
advance by the management and orchestration entities, as well as
stable. This document goes beyond this assumption
[I-D.irtf-nfvrg-gaps-network-virtualization], by describing
mechanisms allowing dynamic discovery of virtualization resources and
orchestrators in IPv6-based networks.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
While [RFC2119] describes interpretations of these key words in terms
of protocol specifications and implementations, they are used in this
Bernardos & Mourad Expires September 6, 2018 [Page 3]
Internet-Draft VIM+NFVI discovery March 2018
document to describe requirements for the SFC mechanisms to
efficiently enable fog RAN.
The following terms used in this document are defined by the ETSI NFV
ISG, the ONF and the IETF:
NFV Infrastructure (NFVI): totality of all hardware and software
components which build up the environment in which VNFs are
deployed
NFV Management and Orchestration (NFV-MANO): functions
collectively provided by NFVO, VNFM, and VIM.
NFV Orchestrator (NFVO): functional block that manages the Network
Service (NS) lifecycle and coordinates the management of NS
lifecycle, VNF lifecycle (supported by the VNFM) and NFVI
resources (supported by the VIM) to ensure an optimized allocation
of the necessary resources and connectivity.
Virtualized Infrastructure Manager (VIM): functional block that is
responsible for controlling and managing the NFVI compute, storage
and network resources, usually within one operator's
Infrastructure Domain.
Virtualized Network Function (VNF): implementation of a Network
Function that can be deployed on a Network Function Virtualisation
Infrastructure (NFVI).
Virtualized Network Function Manager (VNFM): functional block that
is responsible for the lifecycle management of VNF.
3. Network Function Virtualization
The ETSI ISG NFV is a working group which, since 2012, aims to evolve
quasi-standard IT virtualization technology to consolidate many
network equipment types into industry standard high volume servers,
switches, and storage. It enables implementing network functions in
software that can run on a range of industry standard server hardware
and can be moved to, or loaded in, various locations in the network
as required, without the need to install new equipment. The ETSI NFV
is one of the predominant NFV reference framework and architectural
footprints [nfv_sota_research_challenges]. The ETSI NFV framework
architecture framework is composed of three domains (Figure 1):
o Virtualized Network Function, running over the NFVI.
Bernardos & Mourad Expires September 6, 2018 [Page 4]
Internet-Draft VIM+NFVI discovery March 2018
o NFV Infrastructure (NFVI), including the diversity of physical
resources and how these can be virtualized. NFVI supports the
execution of the VNFs.
o NFV Management and Orchestration, which covers the orchestration
and life-cycle management of physical and/or software resources
that support the infrastructure virtualization, and the life-cycle
management of VNFs. NFV Management and Orchestration focuses on
all virtualization specific management tasks necessary in the NFV
framework.
+-------------------------------------------+ +---------------+
| Virtualized Network Functions (VNFs) | | |
| ------- ------- ------- ------- | | |
| | | | | | | | | | | |
| | VNF | | VNF | | VNF | | VNF | | | |
| | | | | | | | | | | |
| ------- ------- ------- ------- | | |
+-------------------------------------------+ | |
| |
+-------------------------------------------+ | |
| NFV Infrastructure (NFVI) | | NFV |
| ----------- ----------- ----------- | | Management |
| | Virtual | | Virtual | | Virtual | | | and |
| | Compute | | Storage | | Network | | | Orchestration |
| ----------- ----------- ----------- | | |
| +---------------------------------------+ | | |
| | Virtualization Layer | | | |
| +---------------------------------------+ | | |
| +---------------------------------------+ | | |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | |
| +---------------------------------------+ | | |
+-------------------------------------------+ +---------------+
Figure 1: ETSI NFV framework
The NFV architectural framework identifies functional blocks and the
main reference points between such blocks. Some of these are already
present in current deployments, whilst others might be necessary
additions in order to support the virtualization process and
consequent operation. The functional blocks are (Figure 2):
o Virtualized Network Function (VNF).
o Element Management (EM).
Bernardos & Mourad Expires September 6, 2018 [Page 5]
Internet-Draft VIM+NFVI discovery March 2018
o NFV Infrastructure, including: Hardware and virtualized resources,
and Virtualization Layer.
o Virtualized Infrastructure Manager(s) (VIM).
o NFV Orchestrator.
o VNF Manager(s).
o Service, VNF and Infrastructure Description.
o Operations and Business Support Systems (OSS/BSS).
+--------------------+
+-------------------------------------------+ | ---------------- |
| OSS/BSS | | | NFV | |
+-------------------------------------------+ | | Orchestrator +-- |
| ---+------------ | |
+-------------------------------------------+ | | | |
| --------- --------- --------- | | | | |
| | EM 1 | | EM 2 | | EM 3 | | | | | |
| ----+---- ----+---- ----+---- | | ---+---------- | |
| | | | |--|-| VNF | | |
| ----+---- ----+---- ----+---- | | | manager(s) | | |
| | VNF 1 | | VNF 2 | | VNF 3 | | | ---+---------- | |
| ----+---- ----+---- ----+---- | | | | |
+------|-------------|-------------|--------+ | | | |
| | | | | | |
+------+-------------+-------------+--------+ | | | |
| NFV Infrastructure (NFVI) | | | | |
| ----------- ----------- ----------- | | | | |
| | Virtual | | Virtual | | Virtual | | | | | |
| | Compute | | Storage | | Network | | | | | |
| ----------- ----------- ----------- | | ---+------ | |
| +---------------------------------------+ | | | | | |
| | Virtualization Layer | |--|-| VIM(s) +-------- |
| +---------------------------------------+ | | | | |
| +---------------------------------------+ | | ---------- |
| | ----------- ----------- ----------- | | | |
| | | Compute | | Storage | | Network | | | | |
| | | hardware| | hardware| | hardware| | | | |
| | ----------- ----------- ----------- | | | |
| | Hardware resources | | | NFV Management |
| +---------------------------------------+ | | and Orchestration |
+-------------------------------------------+ +--------------------+
Figure 2: ETSI NFV reference architecture
Bernardos & Mourad Expires September 6, 2018 [Page 6]
Internet-Draft VIM+NFVI discovery March 2018
4. Fog Virtualization Overview
Virtualization is invading all domains of the E2E 5G network,
including the access, as a mean to achieve the necessary flexibility
in support of the E2E slicing concept. The ETSI NFV framework is the
cornerstone for making virtualization such a promising technology
that can be matured in time for 5G. Typically, virtualization has
been mostly envisaged in the core network, where sophisticated data
centers and clouds provided the right substrate. And mostly, the
framework focused on virtualizing network functions, so called VNFs
(virtualized network functions), which were somewhat limited to
functions that are delay tolerant, typically from the core and
aggregation transport.
As the community has recently been developing the 5G applications and
their technical requirements, it has become clear that certain
applications would require very low latency which is extremely
challenging and stressing for the network to deliver through a pure
centralized architecture. The need to provide networking, computing,
and storage capabilities closer to the users has therefore emerged,
leading to what is known today as the concept of intelligent edge.
ETSI has been the first to address this need recently by developing
the framework of mobile edge computing (MEC).
Such an intelligent edge could not be envisaged without
virtualization. Beyond applications, it raises a clear opportunity
for networking functions to execute at the edge benefiting from
inherent low latencies.
Whilst it is appreciated the particular challenge for the intelligent
edge concept in dealing with mobile users, the edge virtualization
substrate has been largely assumed to be fixed or stationary.
Although little developed, the intelligent edge concept is being
extended further to scenarios where for example the edge computing
substrate is on the move, e.g., on-board a car or a train, or that it
is distributed further down the edge, even integrating resources from
different stakeholders, into what is known as the fog. The
challenges and opportunities for such extensions of the intelligent
edge remain an exciting area of future research.
Figure 3 shows a diagram representing the fog virtualization concept.
The fog is composed by virtual resources on top of heterogeneous
resources available at the edge and even further in the RAN and end-
user devices. These resources are therefore owned by different
stakeholders who collaboratively form a single hosting environment
for the VNFs to run. As an example, virtual resources provided to
the fog might be running on eNBs, APs, at micro data centers deployed
in shopping malls, cars, trains, etc. The fog is connected to data
Bernardos & Mourad Expires September 6, 2018 [Page 7]
Internet-Draft VIM+NFVI discovery March 2018
centers deeper into the network architecture (at the edge ir the
core). On the top part of the figure, an example of user and control
plane VNFs is shown. User plane VNFs are represented as "fx", and
control ones as "ctrlx". Depending on the functionality implemented
by these VNFs and the service requirements, these VNFs would be
mapped (i.e., instantiated) differently to the physical resouces (as
described in [I-D.aranda-sfc-dp-mobile]).
-------- --------- ---------
control | ctr1 |........................| ctrl2 |...| ctrl3 |
plane -------- --------- ---------
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
------ ------ ------
.| f3 |.........| f5 |.....| f6 |
------ ------ . ------ ------ ------
user | f1 |.......| f2 |. .
plane ------ ------ . ------ .
.| f4 |.............
------
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
+--------------------------------+ +-------------------+
| ------- -------- -------- | | ---------- |
| | | | | | | | | ---------- | |
| | @UE | | @car | | @eNB | | | ---------- | | |
| ------- -------- -------- | | | Data | | | |
| | | | Center | | - |
| -------- Heterogeneous ------- | | | (DC) |- |
phy | | | computing | | | | ---------- |
infra | |@train| devices | @AP | |==| ---------- |
| -------- forming ------- | | ---------- | |
| the fog | | ---------- | | |
| --------- ------------ | | | Data | | | |
| | | | | | | | Center | | - |
| | @mall | | @localDC | | | | (DC) |- |
| --------- ------------ | | ---------- |
| FOG | | CLOUD |
+--------------------------------+ +-------------------+
<--------- fog and edge ----------------->
<--- edge & central cloud --->
Figure 3: Fog virtualization
5. Problem statemement
Virtualized resources do not need to be limited to those available in
traditional data centers, where the infrastructure is stable, static,
typically homogeneous and managed by a single admin entity.
Computational capabilities are becoming more and more ubiquitous,
Bernardos & Mourad Expires September 6, 2018 [Page 8]
Internet-Draft VIM+NFVI discovery March 2018
with terminal devices getting extremely powerful, as well as other
types of devices that are close to the end users at the edge (e.g.,
vehicular onboard devices for infotainment, micro data centers
deployed at the edge, etc.). It is envisioned that these devices
would be able to offer storage, computing and networking resources to
nearby network infrastructure, devices and things (the fog paradigm).
These resources can be used to host functions, for example to
offload/complement other resources available at traditional data
centers, but also to reduce the end-to-end latency or to provide
access to specialized information (e.g., context available at the
edge) or hardware.
Since the fog resources are volatile, i.e. may dynamically appear and
disappear, and may be mobile, i.e. may move from one place to
another, mechanisms to discover and advertise virtualized fog
resources are required.
Taking ETSI NFV architecture (see Section 3) as a baseline for the
virtualization of the fog nodes, the discovery of a virtualization
resource can be done either through (i) the discovery of NFVI from a
VIM; or through (ii) the discovery of VIMs and associated NFVI from
an NFVO. In this document we focus on the alternative ii) that is
the discovery of the VIMs and NFVI from an NFVO. This is so because
a VIM is typically NFVI-specific, and therefore these two are more
often than not tied together.
The relationship between an NFVO and the resources it is capable to
orchestrate through a VIM is statically defined according to the
current ETSI NFV specifications [etsi_nfv_002] [etsi_nfv_ifa_005].
The interface Or-Vi (between NFVO and VIM) [etsi_nfv_ifa_005] does
not include any discovery and automatic registration of (mobile) VIMs
from a (mobile) NFVO.
6. Advertisement and discovery of mobile resources (VIM+NFVI)
This document describes IPv6 extensions to allow discovery of
virtualization resources, in the form of a VIM + associated NFVI.
Examples of scenarios where this is useful are shown in Figure 4 and
Figure 5, including also a high-level view of the solution.
Bernardos & Mourad Expires September 6, 2018 [Page 9]
Internet-Draft VIM+NFVI discovery March 2018
__
___________ _( )_
------------ _( )_ ----------- _( )_
| terminal |-(_ VIM--NFVI _) | network |-(_ NFVO _)
------------ (___________) ----------- (_ _)
| | (__)
XXX (1. attachment) |
| |
+---2. Advertisement----------->|
| |
|<......(3. VIM Registration)...+
| |
Figure 4: VIM+NFVI advertisement
Figure 4 shows an scenario in which a mobile terminal with available
resources (NFVI, and associated VIM) attaches to a network (step 1).
Then, it advertises (step 2) that it has virtualization resources
(and their characteristics, such as the type of VIM) that could be
eventually used. An NFVO sitting in the network can then decide to
register the VIM for later use (step 3). This document specifies
some options for step 2 based on IP signaling. Step 3 is
implementation dependent and very much VIM-NFVO specific.
Similarly, Figure 5 shows a scenario with a mobile NFVO. A mobile
terminal with an embedded NFVO attaches to a network (step 1). Then,
it queries the network (step 2) to learn if there are virtualization
resources available. If so, the network conveys that information
(step 3). The NFVO can then decide to register the VIM for later use
(step 4). This document specifies some options for steps 2 and 3
based on IP signaling. Step 4 is implementation dependent and very
much VIM-NFVO specific.
Bernardos & Mourad Expires September 6, 2018 [Page 10]
Internet-Draft VIM+NFVI discovery March 2018
___________
_( )_
______ _( +-NFVI )_
------------ _( )_ ----------- _( / )_
| terminal |-(_ NFVO _) | network |-(_ VIM(s)---NFVI _)
------------ (______) ----------- (_ \ _)
| | (_ +-NFVI _)
XXX (1. attachment) | (___________)
| |
+---2. Request----------------->|
| |
|<-----------3. Advertisement---|
| |
+...(4. VIM Registration)......>|
| |
Figure 5: VIM+NFVI discovery
6.1. IPv6 ND-based discovery
TBD.
7. IANA Considerations
N/A.
8. Security Considerations
TBD.
9. Acknowledgments
The work in this draft will be further developed and explored under
the framework of the H2020 5G-CORAL project (Grant 761586).
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Bernardos & Mourad Expires September 6, 2018 [Page 11]
Internet-Draft VIM+NFVI discovery March 2018
10.2. Informative References
[etsi_nfv_002]
""Network Functions Virtualization (NFV); Architectural
Framework," ETSI GS NFV 002 v1.1.1", October 2013.
[etsi_nfv_ifa_005]
""Network Functions Virtualisation (NFV) Release 2;
Management and Orchestration; Or-Vi reference point -
Interface and Information Model Specification," ETSI GS
NFV-IFA 005 V2.3.1", August 2017.
[etsi_nfv_whitepaper]
"Network Functions Virtualisation (NFV). White Paper 2",
October 2014.
[I-D.aranda-sfc-dp-mobile]
Gutierrez, P., Gramaglia, M., Lopez, D., and W. Haeffner,
"Service Function Chaining Dataplane Elements in Mobile
Networks", draft-aranda-sfc-dp-mobile-04 (work in
progress), June 2017.
[I-D.irtf-nfvrg-gaps-network-virtualization]
Bernardos, C., Rahman, A., Zuniga, J., Contreras, L.,
Aranda, P., and P. Lynch, "Network Virtualization Research
Challenges", draft-irtf-nfvrg-gaps-network-
virtualization-09 (work in progress), February 2018.
[nfv_sota_research_challenges]
Mijumbi, R., Serrat, J., Gorricho, J-L., Bouten, N., De
Turck, F., and R. Boutaba, "Network Function
Virtualization: State-of-the-art and Research Challenges",
IEEE Communications Surveys & Tutorials Volume: 18, Issue:
1, September 2015.
[onf_sdn_architecture]
"SDN Architecture (Issue 1.1), ONF TR-521", February 2016.
Authors' Addresses
Bernardos & Mourad Expires September 6, 2018 [Page 12]
Internet-Draft VIM+NFVI discovery March 2018
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Alain Mourad
InterDigital Europe
Email: Alain.Mourad@InterDigital.com
URI: http://www.InterDigital.com/
Bernardos & Mourad Expires September 6, 2018 [Page 13]
