NFVRG P. Aranda Gutierrez Internet-Draft DRL. Lopez Intended status: Informational Telefonica Expires: April 17, 2017 S. Salsano Univ. of Rome Tor Vergata/CNIT October 14, 2016 High-level VNF Descriptors using NEMO draft-aranda-nfvrg-recursive-vnf-01 Abstract Current efforts in the scope of Network Function Virtualisation(NFV) propose YAML-based descriptors for Virtual Network Functions (VNFs) and for their composition in Network Services (NS) 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 accommodate VNF Descriptors (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 April 17, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Aranda Gutierrez, et al. Expires April 17, 2017 [Page 1] Internet-Draft High-level VNFDs with NEMO October 2016 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 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.1.1. OpenMANO VNFDs . . . . . . . . . . . . . . . . . . . 3 3.1.2. ETSI MANO VNFDs . . . . . . . . . . . . . . . . . . . 4 3.2. NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Additional requirements on NEMO . . . . . . . . . . . . . . . 8 4.1. Referencing VNFDs in a NodeModel . . . . . . . . . . . . 8 4.2. Referencing the network interfaces of a VNF in a NodeModel . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. An example . . . . . . . . . . . . . . . . . . . . . . . 8 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . 11 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Currently, there is a lot of on-going activity to deploy 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. Following the reference architectural model proposed in [ETSI-NFV-MANO], VNFs 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, Network Service Descriptors (NSD) and VNF Descriptors (VNFDs) specified in [ETSI-NFV-MANO] and used in different open source MANO frameworks are YAML-based files, which despite being human readable, are not easy to understand. Aranda Gutierrez, et al. Expires April 17, 2017 [Page 2] Internet-Draft High-level VNFDs with NEMO October 2016 On the other hand, there has been recently an attempt to work on a modelling language for networks or Network Modelling (NEMO) language. This language is human-readable and provides constructs that support 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 recursive, allowing VNFs to be created based on the definitions of existing VNFs. This draft uses two example formats to show how low level descriptors can be imported into NEMO. The first one is the format used in the OpenMANO [1] framework. The second one follows strictly the specifications provided by ETSI NFV ISG in [ETSI-NFV-MANO]. 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 first concentrate on the example of OpenMANO [2], which uses a YAML [3] representation similar to the one specified in [ETSI-NFV-MANO]. Then we will provide an example using the exact format specified in [ETSI-NFV-MANO]. 3.1.1. OpenMANO VNFDs 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, et al. Expires April 17, 2017 [Page 3] Internet-Draft High-level VNFDs with NEMO October 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.1.2. ETSI MANO VNFDs In this example we consider the VNF represented in Figure 6.4 of [ETSI-NFV-MANO]. Its internal diagram, including a VNF component, is represented in Figure Figure 2. A YAML representation of the VNF Descriptor is reported in Figure Figure 3. The topology of the interconnection of VNFs is expressed by using the abstraction of Virtual Links, which interconnect Connection Points of the VNFs. The Aranda Gutierrez, et al. Expires April 17, 2017 [Page 4] Internet-Draft High-level VNFDs with NEMO October 2016 Virtual Links are described by Virtual Link Descriptors (VLD) files. An example YAML representation of the Virtual Link VL1 in the example VNF is reported in Figure Figure 3. In order to understand the topology, a (potentially large) set of VNFD and VLD files needs to be analysed. For a human programmer of the service, this representation is not friendly to write and very hard to read/understand/debug. +----------------------------+ | VNF1 | +----------------------------+ | | | +-------------+ | | | VNFC11 | | | +-------------+ | | | | | | | +----+ | | | | |CP14| | | | | +-+--+ | | | | | | | | +-------------+ | | | | | +--+----+ | | +----+ VL11 +---+ | | | +--+----+ | | | | | | | | +-+--+ +-+--+ +--+-+ | | |CP11| |CP12| |CP13| | | +-+--+ +-+--+ +--+-+ | | | | | | +----------------------------+ | | | +----+--+ +--+----+ +-+-----+ | VL1 | | VL2 | | VL3 | +-------+ +-------+ +-------+ Figure 2: VNF example Aranda Gutierrez, et al. Expires April 17, 2017 [Page 5] Internet-Draft High-level VNFDs with NEMO October 2016 ####################################### # VNF Descriptor of a VNF called vnf1 ####################################### id: vnf1 description_version: '0.1' vendor: netgroup version: '0.1' connection_point: - id: cp11 type: '' virtual_link_reference: vl11 - id: cp12 type: '' virtual_link_reference: vl11 - id: cp13 type: '' virtual_link_reference: vl11 vdu: - id: vdu11 computation_requirement: '' virtual_memory_resource_element: '' virtual_network_bandwidth_resource: '' vnfc: - id: vnfc11 connection_point: - id: cp14 type: NIC virtual_link_reference: vl11 virtual_link: - id: vl11 connection_points_references: - cp11 - cp12 - cp13 - cp14 connectivity_type: ' E-Line' root_requirement: '' Figure 3: ETSI MANO compliant VNF descriptor example Aranda Gutierrez, et al. Expires April 17, 2017 [Page 6] Internet-Draft High-level VNFDs with NEMO October 2016 ############################################ # Virtual Link Descriptor of a VL called vl1 ############################################ id: vl1 descriptor_version: '0.1' test_access: none vendor: netgroup connection: - cp01 - cp11 connectivity_type: E-LAN number_of_endpoints: 2 root_requirement: '' Figure 4: ETSI MANO compliant Virtual Link descriptor example 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 instantiated. The NEMO language also allows for behavioural descriptions. A variant of the NEMO language is used in the OpenDaylight NEMO northbound API [4]. NEMO allows to define NodeModels, which are then instantiated 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 5: Creating a NodeModel in NEMO Aranda Gutierrez, et al. Expires April 17, 2017 [Page 7] Internet-Draft High-level VNFDs with NEMO October 2016 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 IMPORT VNFD FROM 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 in NEMO, we propose to define a new element in the node model, namely the ConnectionPoint. CREATE NodeModel NAME DEFINE ConnectionPoint 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 Aranda Gutierrez, et al. Expires April 17, 2017 [Page 8] Internet-Draft High-level VNFDs with NEMO October 2016 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: +------------------------------------------------------+ | ComplexVNF | | +-------------+ +-------------+ | input | | | | output +------+ SampleVNF +-----------+ ShaperVNF +-------+ | | | | | | | +-------------+ +-------------+ | | data_inside data_outside lan wan | +------------------------------------------------------+ Figure 6 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 6. By using NEMO, we provide a simple way to define VNF forwarding graphs (VNF-FGs) in network service descriptors in a recursive way. Aranda Gutierrez, et al. Expires April 17, 2017 [Page 9] Internet-Draft High-level VNFDs with NEMO October 2016 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 [5]) 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 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, . [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, . Aranda Gutierrez, et al. Expires April 17, 2017 [Page 10] Internet-Draft High-level VNFDs with NEMO October 2016 [ETSI-NFV-MANO] ETSI, "Network Functions Virtualisation (NFV); Management and Orchestration", ETSI GS NFV-MAN 001 V1.1.1 (2014-12), December 2014. 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] https://github.com/nfvlabs/openmano [3] yaml.org [4] https://wiki.opendaylight.org/view/NEMO:Main [5] 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 Diego R. Lopez Telefonica I+D Zurbaran, 12 Madrid 28010 Spain Email: diego.r.lopez@telefonica.com Aranda Gutierrez, et al. Expires April 17, 2017 [Page 11] Internet-Draft High-level VNFDs with NEMO October 2016 Stefano Salsano Univ. of Rome Tor Vergata/CNIT Via del Politecnico, 1 Rome 00133 Italy Email: stefano.salsano@uniroma2.it Aranda Gutierrez, et al. Expires April 17, 2017 [Page 12]