Mobility challenges in virtualization environments
Universidad Carlos III de Madrid
Av. Universidad, 30Leganes, Madrid28911Spain+34 91624 6236cjbc@it.uc3m.eshttp://www.it.uc3m.es/cjbc/
InterDigital Europe
Alain.Mourad@InterDigital.comhttp://www.InterDigital.com/
Internet
DMM
Mobility is no longer restricted to physical end systems roaming among radio
points of attachment. Current mobile network deployments do not only consider
the traditional client-server model, but also include scenarios in which
services are decomposed into functions that run on virtualized resources, thus
becoming virtual functions. This opens the door for new scenarios in which
mobility now includes: (i) the end-system mobility (traditional scenario), (ii)
a physical resource hosting a virtual function (part of a service being consumed
by a end-system) moving, and (iii) a virtual function part of a service moving
(migrating) to a different physical resource. As these scenarios are expected to
be more commonly deployed in the short future, this documents aims at presenting
the new mobility-related scenarios and the potential gaps in terms of IETF
protocols.
Virtualization of functions 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.
Service Functions are widely deployed and essential in many networks. These
Service Functions provide a range of features such as security, WAN
acceleration, and server load balancing. Service Functions may be instantiated
at different points in the network infrastructure such as data center, the WAN,
the RAN, and even on mobile nodes.
Service functions (SFs), also referred to as VNFs, or just functions, are hosted
on compute, storage and networking resources. The hosting environment of a
function is called Service Function Provider or NFVI-PoP (using ETSI NFV
terminology).
Services are typically formed as a composition of SFs (VNFs), with each SF
providing a specific function of the whole service. Services also referred to as
Network Services (NS), according to ETSI terminology.
With the arrival of virtualization, the deployment model for service function is
evolving to one where the traffic is steered through the functions wherever they
are deployed (functions do not need to be deployed in the traffic path anymore).
For a given service, the abstracted view of the required service functions and
the order in which they are to be applied is called a Service Function Chain
(SFC). An SFC is instantiated through selection of specific service function
instances on specific network nodes to form a service graph: this is called a
Service Function Path (SFP). The service functions may be applied at any layer
within the network protocol stack (network layer, transport layer, application
layer, etc.).
The concept of fog computing has emerged driven by the Internet of Things (IoT)
due to the need of handling the data generated from the end-user devices. The
term fog is referred to any networked computational resource in the continuum
between things and cloud. A fog node may therefore be an infrastructure network
node such as an eNodeB or gNodeB, an edge server, a customer premises equipment
(CPE), or even a user equipment (UE) terminal node such as a laptop, a
smartphone, or a computing unit on-board a vehicle, robot or drone.
In fog computing, the functions composing an SFC are hosted on resources that
are inherently heterogeneous, volatile and mobile . This means that resources might appear
and disappear, and the connectivity characteristics between these resources may
also change dynamically.
Taking all the above into account, mobility is no longer restricted to physical
end systems roaming among radio points of attachment. Current mobile network
deployments do not only consider the traditional client-server model, but also
include scenarios in which services are decomposed into functions that run on
virtualized resources, thus becoming virtual functions. This opens the door for
new scenarios in which mobility now includes: (i) the end-system mobility
(traditional scenario), (ii) a physical resource hosting a virtual function
(part of a service being consumed by a end-system) moving, and (iii) a virtual
function part of a service moving (migrating) to a different physical resource.
The aforementioned scenarios can be represented in , where: (i) a UE can roam between PoA1 and
PoA2; (ii) a physical resource, part of a SFC (denoted a SFCx) can move while
hosting a virtual function part of a running service consumed by the UE; and,
(iii) a virtual function vnf2 can move from a node (SFC2) to another one (SFC3).
This is the "classical" scenario in which a UE roams from one point of
attachment to another one. While this have been studied extensively and multiple
solutions are standardized, covering both client-based host and network mobility, and
network-based , these solutions were designed assuming
scenarios where the end-system device was communicating with a server (a
correspondent node, CN) that was in general static and/or running in a physical
server. Current, virtualization and SFC enabled environment add new challenges
to be considered, such as:
Virtualization support at the target destination network.
Availability of (virtual) services and functions at the target destination network.
Programmability capabilities of the target network.
etc.
Current solutions do not account for all these new variables, and therefore
might be subject of new work at the IETF and/or other SDOs such as IEEE, 3GPP
and ETSI.
This is a "new" mobility scenario, in which the moving entity is not the
end-system, but a physical resource hosting one (or several) virtual network
functions part of a service consumed by the end-system. This adds new challenges
to cope with, such as:
How to ensure connectivity of the whole SFC, and to the end-system.
How to guarantee that the end-to-end connectivity maintains the overall required
service QoS. Note that this does not only consists of the "last mile" radio
segment (as in traditional mobility scenarios), but the whole SFC connectivity.
etc.
Current solutions do not account for all these new variables, and therefore
might be subject of new work at the IETF and/or other SDOs such as IEEE, 3GPP
and ETSI.
This is also a "new" mobility scenario, though some limited work has been at
least discussed in the NVO3 WG in the past. In this case, what is moving is a
virtual function instance, from one resource (server) to another. This adds new
challenges to cope with, such as:
Whether to add simultaneous connectivity to both the current (old) and target
(new) location of the function to facilitate the migration.
How to guarantee that the end-to-end connectivity maintains the overall required
service QoS.
etc.
Current solutions do not account for all these new variables, and therefore
might be subject of new work at the IETF and/or other SDOs such as IEEE, 3GPP
and ETSI.
TBD.
TBD.
TBD.
This work has been partially supported by the Spanish Ministry of Economic
Affairs and Digital Transformation and the European Union-NextGenerationEU
through the UNICO 5G I+D 6G-DATADRIVEN. This work has also been partially funded
by the European Commission Horizon Europe SNS JU PREDICT-6G (GA 101095890)
Project.