NFVRG P. Aranda Gutierrez
Internet-Draft DRL. Lopez
Intended status: Informational Telefonica
Expires: December 23, 2016 June 21, 2016
High-level VNF Descriptors using NEMO
draft-aranda-nfvrg-recursive-vnf-00
Abstract
Current efforts in the scope of Network Function Virtualisation(NFV)
propose YAML-based descriptors for Virtual Network Functions (VNFs).
These descriptors are human-readable but hardly understandable by
humans. On the other hand, there has been an effort proposed to the
IETF to define a human-readable (and understandable) representation
for networks, known as NEMO. In this draft, we propose a simple
extension to NEMO to accomodate VNFDs in a similar manner as inline
assembly is integrated in higher-level programming languages.
This approach enables the creation of recursive VNF forwarding graphs
in Service Descriptors, practically making them recursive.
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 December 23, 2016.
Copyright Notice
Copyright (c) 2016 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
(http://trustee.ietf.org/license-info) in effect on the date of
Aranda Gutierrez & LopezExpires December 23, 2016 [Page 1]
Internet-Draft High-level VNFDs with NEMO June 2016
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 and abbreviations . . . . . . . . . . . . . . . . 3
3. Prior art . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Virtual network function descriptors . . . . . . . . . . 3
3.2. NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Additional requirements on NEMO . . . . . . . . . . . . . . . 5
4.1. Referencing VNFDs in a NodeModel . . . . . . . . . . . . 5
4.2. Referencing the network interfaces of a VNF in a
NodeModel . . . . . . . . . . . . . . . . . . . . . . . . 5
4.3. An example . . . . . . . . . . . . . . . . . . . . . . . 6
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Currently, there is a lot of activity going on to use NFV in the
network. From the point of view of the orchestration, Virtual
Network Functions are blocks that are deployed in the infrastructure
as independent units. They provide for one layer of components (VNF
components(VNFCs)) below, i.e. a set of VNFCs accessible to a VNF
provider can be composed into VNFs. However, there is no simple way
to use existing VNFs as components in VNFs with a higher degree of
complexity. In addition, VNFDs used in different open source MANO
frameworks are YAML-based files, which despite being human readable,
are not easy to understand.
On the other hand, there has been recently an attempt to work on a
modelling language for networks (NEMO). This language is human-
readable and provides a NodeModel construct to describe nodes that
supports recursiveness. In this draft, we propose an addition to
NEMO to make it interact with VNFDs supported by a NFV MANO
framework. This integration creates a new language for VNFDs that is
Aranda Gutierrez & LopezExpires December 23, 2016 [Page 2]
Internet-Draft High-level VNFDs with NEMO June 2016
recursive, allowing VNFs to be created based on the definitions of
existing VNFs.
This draft uses OpenMANO and OSM descriptor references as an example
for the lowest level descriptors that are imported into NEMO.
Conceptually, other descriptor formats like TOSCA can also be used at
this level.
2. Terminology and abbreviations
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].
3. Prior art
3.1. Virtual network function descriptors
Virtual network function descriptors (VNFDs) are used in the
Management and orchestration (MANO) framework of the ETSI NFV to
achieve the optimal deployment of virtual network functions (VNFs).
The Virtual Infrastructure Manager (VIM) uses this information to
place the functions optimally. VNFDs include information of the
components of a specific VNF and their interconnection to implement
the VNF, in the form of a forwarding graph. In addition to the
forwarding graph, the vnfd includes information regarding the
interfaces of the VNF. These are then used to connect the VNF to
either physical or logical interfaces once it is deployed.
There are different MANO frameworks available. For this draft, we
will concentrate on the example of OpenMANO [1], which usesYAML [2].
Taking the example from the (public) OpenMANO github repository, we
can easily identify the virtual interfaces of the sample VNFs in
their descriptors:
Aranda Gutierrez & LopezExpires December 23, 2016 [Page 3]
Internet-Draft High-level VNFDs with NEMO June 2016
+----------------------------+
| |
mgt0 | +---------------+ | ge0
| | | |
---+-----+ Template VM +------+------
| | | |
| +---+--------+--+ |
| | | |
+---------+--------+---------+
| |
xe0 xe1
vnf:
name: TEMPLATE
description: This is a template to help in the creation of
# class: parent # Optional. Used to organize VNFs
external-connections:
- name: mgmt0
type: mgmt
VNFC: TEMPLATE-VM
local_iface_name: mgmt0
description: Management interface
- name: xe0
type: data
VNFC: TEMPLATE-VM
local_iface_name: xe0
description: Data interface 1
- name: xe1
type: data
VNFC: TEMPLATE-VM
local_iface_name: xe1
description: Data interface 2
- name: ge0
type: bridge
VNFC: TEMPLATE-VM
local_iface_name: ge0
description: Bridge interface
Figure 1: Sample VNF and descriptor (source: OpenMANO github)
3.2. NEMO
The Network Modeling (NEMO) language is described in
[I-D.xia-sdnrg-nemo-language]. It provides a simple way of
describing network scenarios. The language is based on a two-stage
process. In the first stage, models for nodes, links and other
entities are defined. In the second stage, the defined models are
instanciated. The NEMO language also allows for behavioural
Aranda Gutierrez & LopezExpires December 23, 2016 [Page 4]
Internet-Draft High-level VNFDs with NEMO June 2016
descriptions. A variant of the NEMO language is used in the
OpenDaylight NEMO northbound API [3].
NEMO allows to define NodeModels, which are then instanciated in the
infrastructure. NodeModels are recursive and can be build with basic
node types or with previously defined NodeModels. An example for a
script defining a NodeModel is shown below:
CREATE NodeModel dmz
Property string: location-fw, string: location-n2,
string: ipprefix, string: gatewayip, string: srcip,
string: subnodes-n2;
Node fw1
Type fw
Property location: location-fw,
operating-mode: layer3;
...
Figure 2: Creating a NodeModel in NEMO
4. Additional requirements on NEMO
In order to integrate VNFDs into NEMO, we need to take into account
two specifics of VNFDs, which cannot be expressed in the current
language model. Firstly, we need a way to reference the file which
holds the VNFD provided by the VNF developer. This will normally be
a universal resource identifier (URI). Additionally, we need to make
the NEMO model aware of the virtual network interfaces.
4.1. Referencing VNFDs in a NodeModel
As explained in the introduction, in order integrate VNFDs into the
NEMO language in the easiest way we need to reference the VNFD as a
Universal Resource Identifier (URI) as defined in RFC 3986 [RFC3986].
To this avail, we define a new element in the NodeModel to import the
VNFD:
CREATE NodeModel NAME <node_model_name>
IMPORT VNFD FROM <vnfd_uri>
4.2. Referencing the network interfaces of a VNF in a NodeModel
As shown in Figure 1, VNFDs include an exhaustive list of interfaces,
including the interfaces to the management network. However, since
these interfaces may not be significant for specific network
scenarios and since interface names in the VNFD may not be adequate
Aranda Gutierrez & LopezExpires December 23, 2016 [Page 5]
Internet-Draft High-level VNFDs with NEMO June 2016
in NEMO, we propose to define a new element in the node model, namely
the ConnectionPoint.
CREATE NodeModel NAME <node_model_name>
DEFINE ConnectionPoint <cp_name> FROM VNFD:<iface_from_vnfd>
4.3. An example
Once these two elements are included in the NEMO language, it is
possibly to recursively define NodeModel elements that use VNFDs in
the lowest level of recursion. Firstly, we create NodeModels from
VNFDs:
CREATE NodeModel NAME SampleVNF
IMPORT VNFD from https://github.com/nfvlabs/openmano.git
/openmano/vnfs/examples/dataplaneVNF1.yaml
DEFINE ConnectionPoint data_inside as VNFD:ge0
DEFINE ConnectionPoint data_outside as VNFD:ge1
Import from a sample VNFD from the OpenMANO repository
Then we can reuse these NodeModels recursively to create complex
NodeModels:
CREATE NodeModel NAME ComplexNode
Node InputVNF TYPE SampleVNF
Node OutputVNF TYPE ShaperVNF
DEFINE ConnectionPoint input
DEFINE ConnectionPoint output
CONNECTION input_connection FROM input TO InputVNF:data_inside
TYPE p2p
CONNECTION output_connection FROM output TO ShaperVNF:wan
TYPE p2p
CONNECTION internal FROM InputVNF:data_outside TO ShaperVNF:lan
TYPE p2p
Create a composed NodeModel
This NodeModel definition creates a composed model linking the
SampleVNF created from the VNFD with a hypothetical ShaperVNF defined
elsewhere. This definition can be represented graphically as
follows:
Aranda Gutierrez & LopezExpires December 23, 2016 [Page 6]
Internet-Draft High-level VNFDs with NEMO June 2016
+------------------------------------------------------+
| ComplexVNF |
| +-------------+ +-------------+ |
input | | | | output
+------+ SampleVNF +-----------+ ShaperVNF +-------+
| | | | | |
| +-------------+ +-------------+ |
| data_inside data_outside lan wan |
+------------------------------------------------------+
Figure 3
In ETSI NFV, a network service is described by one or more VNFs that
are connected through one or more network VNFFGs. This is no more
than what is defined in the composed NodeModel shown if Figure 3. By
using NEMO, we provide a simple way to define VNF forwarding
graphs(VNF-FGs) in network service descriptors in a recursive way.
5. Conclusion
With the strategy defined in this document, we are able to link a
low-level VNF description into a high-level description language for
networks like NEMO. Effectively, we are introducing recursiveness in
VNFDs, allowing complex service descriptors to be built by reusing
previously tested descriptors graphs as building blocks.
Although we have used the OpenMANO descriptor format in this
document, other descriptors and concepts (i.e. as those used by TOSCA
[4]) can also be used as the lowest level in this extension to the
NEMO language.
6. IANA Considerations
This draft includes no request to IANA.
7. Security Considerations
The IMPORT construct allows referencing external resources.
Developers using it in NEMO scripts are advised to verify the source
of those external resources, and whenever possible, rely on sources
with a verifiable identity through cryptographic methods.
8. Acknowledgement
This work has been partially performed in the scope of the
SUPERFLUIDITY project, which has received funding from the European
Aranda Gutierrez & LopezExpires December 23, 2016 [Page 7]
Internet-Draft High-level VNFDs with NEMO June 2016
Union's Horizon 2020 research and innovation programme under grant
agreement No.671566 (Research and Innovation Action).
9. References
9.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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>.
9.2. Informative References
[I-D.xia-sdnrg-nemo-language]
Xia, Y., Jiang, S., Zhou, T., Hares, S., and Y. Zhang,
"NEMO (NEtwork MOdeling) Language", draft-xia-sdnrg-nemo-
language-04 (work in progress), April 2016.
9.3. URIs
[1] https://github.com/nfvlabs/openmano
[2] yaml.org
[3] https://wiki.opendaylight.org/view/NEMO:Main
[4] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv-
v1.0.html
Authors' Addresses
Pedro A. Aranda Gutierrez
Telefonica I+D
Zurbaran, 10
Madrid 28010
Spain
Email: pedroa.aranda@telefonica.com
Aranda Gutierrez & LopezExpires December 23, 2016 [Page 8]
Internet-Draft High-level VNFDs with NEMO June 2016
Diego R. Lopez
Telefonica I+D
Zurbaran, 12
Madrid 28010
Spain
Email: diego.r.lopez@telefonica.com
Aranda Gutierrez & LopezExpires December 23, 2016 [Page 9]