Internet DRAFT - draft-geng-nfvrg-distributed-nfv
draft-geng-nfvrg-distributed-nfv
NFVRG L. Geng
Internet-Draft China Mobile
Intended status: Informational March 7, 2017
Expires: September 8, 2017
Distributed NFV in Scattered Premises
draft-geng-nfvrg-distributed-nfv-00
Abstract
This document introduces the distributed NFV (D-NFV) concept based on
potential implementation in scattered locations including customer
edge devices and transport network equipments. The motivation of
pushing NFV entities from conventional centralized infrastructures to
distributed promises is discussed, which are driven by the
requirements of high flexibility, low end-to-end latency and faster
time-to-market in future network. To better understand the D-NFV
concept, examples of D-NFV implementation is introduced. Potential
use cases are also described as references for readers. Gaps have
also been recognized in the documents in terms of the investigation
of appropriate virtualization technologies used in the D-NFV and
corresponding management and orchestration challenges.
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 http://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 September 8, 2017.
Copyright Notice
Copyright (c) 2017 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
Geng Expires September 8, 2017 [Page 1]
Internet-Draft Distributed NFV March 2017
(http://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. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3
4. NFV in Different Points of Presence . . . . . . . . . . . . . 3
4.1. Centralized NFV . . . . . . . . . . . . . . . . . . . . . 3
4.2. Distributed NFV . . . . . . . . . . . . . . . . . . . . . 4
5. Typical NFVI-PoPs in Distributed NFV . . . . . . . . . . . . 6
5.1. Distributed NFV in Customer Edge Devices . . . . . . . . 6
5.2. Distributed NFV in Service Provider Transport and Bearer
Networks . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Use cases of Distributed NFV . . . . . . . . . . . . . . . . 7
6.1. Use Case 1 - VNFaaS and VNPaaS in Residential and
Enterprise Network . . . . . . . . . . . . . . . . . . . 7
6.2. Use Case 2 - Mission Critical Services . . . . . . . . . 7
6.3. Use Case 3 - End-to-end Network Slicing Management . . . 8
6.4. Use Case 4 - Managed Multiple Provisioning for Network
Elements . . . . . . . . . . . . . . . . . . . . . . . . 8
6.5. Use Case 5 - Elastic VPN . . . . . . . . . . . . . . . . 8
7. Rethinking VNFs in Distributed NFV . . . . . . . . . . . . . 8
8. Virtualization Technologies in Distributed NFV . . . . . . . 8
9. Management and Orchestration of Distributed NFV . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction
As new services such as IoT start to emerge, service provider's
network is required to have higher flexibility, greater security and
reliable service quality guarantee from customer end to service
provider core. NFV technology has been proved to be an excellent
candidate to fulfil these demands for future network. And it has
been widely investigated in centralized premises including data
centre and mobile core network applications. To further improve
overall system flexibility and performance, it is also extremely
Geng Expires September 8, 2017 [Page 2]
Internet-Draft Distributed NFV March 2017
interesting to explore how NFV technology can be implemented in
scattered network premises.
NFV make use of the virtualization technology to decouple software
functions from hardware infrastructures. There is no fundamental
limitations on where NFV can be applied to. Some network functions
in principle are most efficient when hosted in distributed premises.
In this case, it is worth to consider how these functions can be
virtualized locally to maintain their efficiency whilst benefit from
the flexibility, fast time-to-market deployment and new business
model such as VNPaaS that NFV can offer.
2. Requirements Language
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 RFC 2119 [RFC2119].
3. Terminology and Abbreviations
The terminology and abbreviations used in this document are defined
in this section.
o D-NFV: Distributed NFV. A system architecture where the NFV
entities are distributively implemented in scattered network
premises.
o NFVI-PoPs: NFV infrastructure points of presence. The location
where network functions are realized by VNFs.
4. NFV in Different Points of Presence
In general, NFV provides decoupled software and hardware for vendor-
specific network elements. Based on this principle, VNFs are allowed
to be located anywhere as long as the corresponding infrastructures
support. According to ETSI, proposed points of presence for NFV
include customers' premises, central offices, data centres and etc.
In principle, VNFs should be placed where they are most cost-
effective, providing better efficiency and performances .
4.1. Centralized NFV
At present, most of the NFV deployments are centralized. As an
example, the evolving mobile core network is one of the most popular
areas where centralized NFV deployment most likely to take place in
the near future. It is accelerating its pace in the process of the
transition to the next generation NFV-based architecture for 5G. In
fact, most of the network functions in core network in form of
Geng Expires September 8, 2017 [Page 3]
Internet-Draft Distributed NFV March 2017
conventional vendor-specific network elements are intrinsically
centralized. Naturally, the virtualized entities of these network
functions are expected to follow the centralized architecture.
+------+ Centralized NFVI-PoPs
|Device| +---------------------+
| 1 | ____ | |
+------+-----( )__ | +---+ +---+ +---+ |
+------+ __( )_ | |VNF| |VNF| |VNF| |
|Device| _( )__ + +---+ +---+ +---+ |
| 2 +--( Network ) | |
+------+ (___________________)---| +---------------+ |
| | | NFVI | |
Distributed +---+--+ | +---------------+ |
Devices 1-3 |Device| +---------------------+
| 3 |
+------+
Figure 1
Figure 1 illustrates the scheme diagram of a centralized NFV
deployment. In centralized NFV, conventional vendor-specific network
elements are realized as VNFs which reside in centralized NFVI-PoPs
(i.e. private telecommunication clouds).
The computing and storage hardware resources in the centralized NFV
are commonly in the form of server clusters. They are normally
pooled and usually span across different physical locations. Network
hardware resources (i.e. switches, routers) are essential in
centralized NFV to provide connectivities. These include
connectivities within and between NFVI-PoPs. Given the powerful
computing and storage resources benefited from clusters, centralized
NFV is capable of supporting the virtualization of many complex
network elements. The COTS used in NFVI also guarantees the system
scalability and elastic deployment.
4.2. Distributed NFV
Centralization is not an intrinsic nature of NFV. Many vendor-
specific network elements located in scattered premises may also
benefit from the implementation of NFV by decoupling software and
hardware. Service providers used to replace these equipments or make
a full system upgrade on them to deploy new functions and services.
With the implementation of NFV, service providers can push new
functions and services directly corresponding network elements and
end users respectively simply by the deployment of new VNFs.
Geng Expires September 8, 2017 [Page 4]
Internet-Draft Distributed NFV March 2017
Many services need local processing provided by network functions are
implemented in distributed network elements. These network
functions, when virtualized, still make sense to be hosted at the
same location for many reasons. Some examples are given as follows.
o Security. Service requiring end-to-end security has to be
implemented from the customer end. VNF for such purposes, i.e.
encryption are preferred to be hosted locally.
o Latency. Mission critical services are very sensitive to latency.
Local precessing is preferred to minimize the round trip latency.
o Resilience. In some scenarios where services are provided
remotely in the cloud, customers want their internal networks and
services to keep working when there is a network failure. Locally
hosted VNFs can work as backups for this purpose.
D-NFV focuses on the scenarios where the NFVI-PoPs locate in
scattered premises. Common infrastructures seen in these premises
include but are not limited to end-user devices, customer premises
equipment and dedicated network equipments in transport and bearer
networks.
Distributed
NFVI-PoP 1
+-------------+
| +---+ +---+ |
| |VNF| |VNF| |
| +---+ +---+ |
Distributed | NFVI |
NFVI-PoP 2 +-------------+
+-------------+ _|__
| +---+ +---+ | ( )__ +--------------+
| |VNF| |VNF| +-------( )_ | Centralized |
| +---+ +---+ | _( +------------+Infrastructure|
| NFVI | ( Network ) | (Data Center)|
+-------------+ (___________________) +--------------+
|
+-------------+
Distributed | +---+ +---+ |
NFVI-PoP 3 | |VNF| |VNF| |
| +---+ +---+ |
| NFVI |
+-------------+
Figure 2
Geng Expires September 8, 2017 [Page 5]
Internet-Draft Distributed NFV March 2017
Figure 2 illustrates the scheme diagram of a D-NFV deployment in
customer premises. Instead of nested with integrated software and
hardware, the CPE provides NFVI for various VNFs. Since the VNFs are
decoupled with the hardware resources, service provider can
dynamically deploy corresponding VNFs according to performance and
customer requirements.
The hardware resources in scattered premises are normally different
from that in centralized data centres. Typical examples include SoCs
and individual servers. Given the fact that these infrastructures
are not designed to be clustered, the network hardware between NFVI-
PoPs of D-NFV is not as essential as that of centralized scenario.
However, specific services may require network connectivity between
NFVI-PoPs to achieve better performances. Network connectivity
within NFVI-PoPs in D-NFV may be required depending on the actual
design of the VNF entities.Given the limited computing and storage
resources, VNFs in the D-NFV should be normally much less resource-
hungry than those in centralized NFV.
5. Typical NFVI-PoPs in Distributed NFV
D-NFV focuses on NFV implementations in scattered locations. This
section introduces 2 typical examples of NFVI-PoPs including customer
edge devices and transport network equipments.
5.1. Distributed NFV in Customer Edge Devices
A customer edge device is the first service-provider-owned device for
an end-user to connect to the network and subscribe to specific
services. This device is normally purchased by service providers
with required functionalities. Accordingly, it normally has well-
defined hardware and vendor-specific software.
In residential network, customer edge devices are typically in forms
of WiFi routers, with various uplink interface including PON, xDSL
and cellular. Service providers used to provide only internet access
to residential users and the customer edge devices were rather
simple. Recently, many service provider started to provide value-
added services such as IPTV, VoIP, home storage, remote download and
VPNs. Accordingly, the concept of "intelligent home gateway" is
introduced, which enables the residential customer edge device to
dynamically implement new services by downloading applications.
These application are normally realized as C and Java modules. D-NFV
is another way to provide application and hardware decoupling, with
extra benefits of better isolation between applications, improved
service security, high reliability, managed resource allocation and
comprehensive device capability exposure. As IoT services start to
emerge in residential market, D-NFV can improve overall deployment
Geng Expires September 8, 2017 [Page 6]
Internet-Draft Distributed NFV March 2017
flexibility and generate potential new business model by providing
guaranteed isolation, resources and deep capability exposure for
different value-added service providers
Other example of customer edge devices include enterprise premise and
industrial premise equipment. There are plenty of services which
require local implementation and flexible deployment for optimized
performance. For example, WAN acceleration and firewalls have best
efficiency when they are implemented locally. Meanwhile, low latency
services such as manufacture plant control and item tracking in
industrial network also require extremely high reliability which need
dedicatedly allocated hardware and network resources.
5.2. Distributed NFV in Service Provider Transport and Bearer Networks
The application of NFV in service provider transport network has been
investigated mostly in combination of SDN technology. It is
interesting to see that NFV as a technology is applied to transport
network as a way of implementing the separated control plane in
centralized infrastructure. This can be seen as a coordination of
SDN and NFV technology with the control plane decoupled and
virtualized.
Indeed, as a data plane network equipment, current virtualization
technologies are not efficient enough to provide data forwarding
performance comparable to network processing chips used in these
devices. However, it is attractive to use NFV technology in these
network equipment to provide isolated management and control plane.
There is great potential for service providers to exploit this
technology for a much more flexible management and control model for
data plane equipments at a sliced granularity.
6. Use cases of Distributed NFV
In this version, several use cases are listed for general references.
Descriptions in detail are subjected to be added according to initial
discussion in the group. The author would also like to call for more
use cases for D-NFV identified by the community.
6.1. Use Case 1 - VNFaaS and VNPaaS in Residential and Enterprise
Network
6.2. Use Case 2 - Mission Critical Services
Geng Expires September 8, 2017 [Page 7]
Internet-Draft Distributed NFV March 2017
6.3. Use Case 3 - End-to-end Network Slicing Management
6.4. Use Case 4 - Managed Multiple Provisioning for Network Elements
6.5. Use Case 5 - Elastic VPN
7. Rethinking VNFs in Distributed NFV
In centralized NFV, VNFs are normally virtualized forms of
conventional network elements. Sometimes, the network function of a
network element may be broken into multiple VNFs for specific
implementation considerations. In D-NFVs, VNFs are typically not a
full representation of any existing network element. They are more
like applications or new services that are pushed to the customer or
equipments.
As distributed NFVI-PoP are normally limited in hardware resources,
VNFs with complex functionalities are not recommended in these
infrastructures. Meanwhile, as VNFs in D-NFV are subjected to be
application-specific, it is expected that the variety of VNFs in
D-NFV will proportionally grow with the number of services provided
through the network. Hence, these VNFs need to have fast time-to-
market and adapt to practices like DevOps.
8. Virtualization Technologies in Distributed NFV
The D-NFV may need to consider various virtulization technologies
that are different from centralized NFV, as VNFs in D-NFV are
expected in much smaller granularities. In this case, container-
based virtualization technology may be preferred. This is also due
to the potential large number of VNFs and limited hardware resources
provided in distributed NFVI-PoPs. Further studies need to be
carried out to investigate the appropriated virtualization
technologies used in different scenarios of D-NFV
9. Management and Orchestration of Distributed NFV
The management and orchestration of D-NFV need to consider the
following difference compared with that of centralized NFV.
o Individually located NFVI and VIM - The nature of D-NFV decide the
scattered locations of NFVI-PoPs. In addition, the limited
hardware resources are unlikely to support a full MANO
implementation in distributed NFVI-PoPs and this is simply not
cost-efficient and makes the overall system complicated. Hence a
centralized MANO is expected as a feasible solution. This
introduce a rather diverted model for the virtualization layer
Geng Expires September 8, 2017 [Page 8]
Internet-Draft Distributed NFV March 2017
management where the VIM and NFVI will locate in centralized and
distributed infrastructure respectively.
o Massive number of NFVI-PoPs and VNFs - Distributed NFVI-PoPs have
a large number in quantity. Taking the residential NFVI-PoP as an
example, the number is expected to be millions for a service
provide with a fair size business. This does not count the
potential industrial and IoT applications which introduce even
more. The number of VNFs need to be provisioned can be easily
10-100 times of the NFVI-PoPs. The traditional MANO intrinsically
designed for data center applications simply does not fit. It is
also too heavy for this purpose - D-NFV may not need such
comprehensive resource and network provisioning. The management
and orchestration for D-NFV needs to be redesigned.
10. IANA Considerations
This memo includes no request to IANA.
11. Security Considerations
TBA
12. References
12.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,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
DOI 10.17487/RFC2629, June 1999,
<http://www.rfc-editor.org/info/rfc2629>.
12.2. Informative References
[ETSI-GS-NFV-002]
ETSI, "ETSI GS NFV 002", 2014,
<http://www.etsi.org/deliver/etsi_gs/
NFV/001_099/003/01.02.01_60/gs_NFV003v010201p.pdf>.
Author's Address
Geng Expires September 8, 2017 [Page 9]
Internet-Draft Distributed NFV March 2017
Liang Geng
China Mobile
Email: gengliang@chinamobile.com
Geng Expires September 8, 2017 [Page 10]
