Internet DRAFT - draft-bernardos-dmm-mobility-virtualization
draft-bernardos-dmm-mobility-virtualization
DMM CJ. Bernardos
Internet-Draft UC3M
Intended status: Informational A. Mourad
Expires: 26 January 2024 InterDigital
25 July 2023
Mobility challenges in virtualization environments
draft-bernardos-dmm-mobility-virtualization-02
Abstract
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.
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."
This Internet-Draft will expire on 26 January 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bernardos & Mourad Expires 26 January 2024 [Page 1]
Internet-Draft Mobility and virtualization July 2023
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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction and Problem Statement . . . . . . . . . . . . . 2
2. End system mobility . . . . . . . . . . . . . . . . . . . . . 4
3. Resource mobility . . . . . . . . . . . . . . . . . . . . . . 5
4. Virtual function mobility . . . . . . . . . . . . . . . . . . 5
5. Requirements for IETF work . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
9. Informative References . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction and Problem Statement
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.
Bernardos & Mourad Expires 26 January 2024 [Page 2]
Internet-Draft Mobility and virtualization July 2023
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
[I-D.bernardos-sfc-fog-ran]. 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
Bernardos & Mourad Expires 26 January 2024 [Page 3]
Internet-Draft Mobility and virtualization July 2023
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 Figure 1, 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).
+----+ +------+
| UE |))))))))| PoA1 +\ +-------+ +-------+ _------_
+----+ +------+ \ | SFC1 | | SFC2 | _( )_
==+ +-o)))o-+ +---( Internet )
+------+ / | vnf1 | | vnf2 | (_ _)
| PoA2 +/ +-------+ +-------+ (______)
+------+ \ /
\ /
+-------+ /
| SFC3 | /
| |/
| *vnf2 |
+-------+
Figure 1: Mobility scenarios in an virtualized SFC-enabled
environment
2. End system mobility
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 [RFC6275] and network [RFC3963] mobility, and
network-based [RFC5213], 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.
Bernardos & Mourad Expires 26 January 2024 [Page 4]
Internet-Draft Mobility and virtualization July 2023
* 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.
3. Resource mobility
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.
4. Virtual function mobility
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.
Bernardos & Mourad Expires 26 January 2024 [Page 5]
Internet-Draft Mobility and virtualization July 2023
5. Requirements for IETF work
TBD.
6. IANA Considerations
TBD.
7. Security Considerations
TBD.
8. Acknowledgments
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.
9. Informative References
[I-D.bernardos-sfc-fog-ran]
Bernardos, C. J. and A. Mourad, "Service Function Chaining
Use Cases in Fog RAN", Work in Progress, Internet-Draft,
draft-bernardos-sfc-fog-ran-10, 22 October 2021,
<https://datatracker.ietf.org/doc/html/draft-bernardos-
sfc-fog-ran-10>.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, DOI 10.17487/RFC3963, January 2005,
<https://www.rfc-editor.org/info/rfc3963>.
[RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
RFC 5213, DOI 10.17487/RFC5213, August 2008,
<https://www.rfc-editor.org/info/rfc5213>.
[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
2011, <https://www.rfc-editor.org/info/rfc6275>.
Authors' Addresses
Bernardos & Mourad Expires 26 January 2024 [Page 6]
Internet-Draft Mobility and virtualization July 2023
Carlos J. Bernardos
Universidad Carlos III de Madrid
Av. Universidad, 30
28911 Leganes, Madrid
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 26 January 2024 [Page 7]
