idnits 2.17.1 draft-aranda-nfvrg-recursive-vnf-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 276 has weird spacing: '..._inside data...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 21, 2016) is 2859 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 341 -- Looks like a reference, but probably isn't: '2' on line 343 -- Looks like a reference, but probably isn't: '3' on line 345 -- Looks like a reference, but probably isn't: '4' on line 347 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFVRG P. Aranda Gutierrez 3 Internet-Draft DRL. Lopez 4 Intended status: Informational Telefonica 5 Expires: December 23, 2016 June 21, 2016 7 High-level VNF Descriptors using NEMO 8 draft-aranda-nfvrg-recursive-vnf-00 10 Abstract 12 Current efforts in the scope of Network Function Virtualisation(NFV) 13 propose YAML-based descriptors for Virtual Network Functions (VNFs). 14 These descriptors are human-readable but hardly understandable by 15 humans. On the other hand, there has been an effort proposed to the 16 IETF to define a human-readable (and understandable) representation 17 for networks, known as NEMO. In this draft, we propose a simple 18 extension to NEMO to accomodate VNFDs in a similar manner as inline 19 assembly is integrated in higher-level programming languages. 21 This approach enables the creation of recursive VNF forwarding graphs 22 in Service Descriptors, practically making them recursive. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 23, 2016. 41 Copyright Notice 43 Copyright (c) 2016 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology and abbreviations . . . . . . . . . . . . . . . . 3 60 3. Prior art . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3.1. Virtual network function descriptors . . . . . . . . . . 3 62 3.2. NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 4. Additional requirements on NEMO . . . . . . . . . . . . . . . 5 64 4.1. Referencing VNFDs in a NodeModel . . . . . . . . . . . . 5 65 4.2. Referencing the network interfaces of a VNF in a 66 NodeModel . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4.3. An example . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 7 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 74 9.2. Informative References . . . . . . . . . . . . . . . . . 8 75 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 78 1. Introduction 80 Currently, there is a lot of activity going on to use NFV in the 81 network. From the point of view of the orchestration, Virtual 82 Network Functions are blocks that are deployed in the infrastructure 83 as independent units. They provide for one layer of components (VNF 84 components(VNFCs)) below, i.e. a set of VNFCs accessible to a VNF 85 provider can be composed into VNFs. However, there is no simple way 86 to use existing VNFs as components in VNFs with a higher degree of 87 complexity. In addition, VNFDs used in different open source MANO 88 frameworks are YAML-based files, which despite being human readable, 89 are not easy to understand. 91 On the other hand, there has been recently an attempt to work on a 92 modelling language for networks (NEMO). This language is human- 93 readable and provides a NodeModel construct to describe nodes that 94 supports recursiveness. In this draft, we propose an addition to 95 NEMO to make it interact with VNFDs supported by a NFV MANO 96 framework. This integration creates a new language for VNFDs that is 97 recursive, allowing VNFs to be created based on the definitions of 98 existing VNFs. 100 This draft uses OpenMANO and OSM descriptor references as an example 101 for the lowest level descriptors that are imported into NEMO. 102 Conceptually, other descriptor formats like TOSCA can also be used at 103 this level. 105 2. Terminology and abbreviations 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. Prior art 113 3.1. Virtual network function descriptors 115 Virtual network function descriptors (VNFDs) are used in the 116 Management and orchestration (MANO) framework of the ETSI NFV to 117 achieve the optimal deployment of virtual network functions (VNFs). 118 The Virtual Infrastructure Manager (VIM) uses this information to 119 place the functions optimally. VNFDs include information of the 120 components of a specific VNF and their interconnection to implement 121 the VNF, in the form of a forwarding graph. In addition to the 122 forwarding graph, the vnfd includes information regarding the 123 interfaces of the VNF. These are then used to connect the VNF to 124 either physical or logical interfaces once it is deployed. 126 There are different MANO frameworks available. For this draft, we 127 will concentrate on the example of OpenMANO [1], which usesYAML [2]. 128 Taking the example from the (public) OpenMANO github repository, we 129 can easily identify the virtual interfaces of the sample VNFs in 130 their descriptors: 132 +----------------------------+ 133 | | 134 mgt0 | +---------------+ | ge0 135 | | | | 136 ---+-----+ Template VM +------+------ 137 | | | | 138 | +---+--------+--+ | 139 | | | | 140 +---------+--------+---------+ 141 | | 142 xe0 xe1 144 vnf: 145 name: TEMPLATE 146 description: This is a template to help in the creation of 147 # class: parent # Optional. Used to organize VNFs 148 external-connections: 149 - name: mgmt0 150 type: mgmt 151 VNFC: TEMPLATE-VM 152 local_iface_name: mgmt0 153 description: Management interface 154 - name: xe0 155 type: data 156 VNFC: TEMPLATE-VM 157 local_iface_name: xe0 158 description: Data interface 1 159 - name: xe1 160 type: data 161 VNFC: TEMPLATE-VM 162 local_iface_name: xe1 163 description: Data interface 2 164 - name: ge0 165 type: bridge 166 VNFC: TEMPLATE-VM 167 local_iface_name: ge0 168 description: Bridge interface 170 Figure 1: Sample VNF and descriptor (source: OpenMANO github) 172 3.2. NEMO 174 The Network Modeling (NEMO) language is described in 175 [I-D.xia-sdnrg-nemo-language]. It provides a simple way of 176 describing network scenarios. The language is based on a two-stage 177 process. In the first stage, models for nodes, links and other 178 entities are defined. In the second stage, the defined models are 179 instanciated. The NEMO language also allows for behavioural 180 descriptions. A variant of the NEMO language is used in the 181 OpenDaylight NEMO northbound API [3]. 183 NEMO allows to define NodeModels, which are then instanciated in the 184 infrastructure. NodeModels are recursive and can be build with basic 185 node types or with previously defined NodeModels. An example for a 186 script defining a NodeModel is shown below: 188 CREATE NodeModel dmz 189 Property string: location-fw, string: location-n2, 190 string: ipprefix, string: gatewayip, string: srcip, 191 string: subnodes-n2; 192 Node fw1 193 Type fw 194 Property location: location-fw, 195 operating-mode: layer3; 196 ... 198 Figure 2: Creating a NodeModel in NEMO 200 4. Additional requirements on NEMO 202 In order to integrate VNFDs into NEMO, we need to take into account 203 two specifics of VNFDs, which cannot be expressed in the current 204 language model. Firstly, we need a way to reference the file which 205 holds the VNFD provided by the VNF developer. This will normally be 206 a universal resource identifier (URI). Additionally, we need to make 207 the NEMO model aware of the virtual network interfaces. 209 4.1. Referencing VNFDs in a NodeModel 211 As explained in the introduction, in order integrate VNFDs into the 212 NEMO language in the easiest way we need to reference the VNFD as a 213 Universal Resource Identifier (URI) as defined in RFC 3986 [RFC3986]. 214 To this avail, we define a new element in the NodeModel to import the 215 VNFD: 217 CREATE NodeModel NAME 218 IMPORT VNFD FROM 220 4.2. Referencing the network interfaces of a VNF in a NodeModel 222 As shown in Figure 1, VNFDs include an exhaustive list of interfaces, 223 including the interfaces to the management network. However, since 224 these interfaces may not be significant for specific network 225 scenarios and since interface names in the VNFD may not be adequate 226 in NEMO, we propose to define a new element in the node model, namely 227 the ConnectionPoint. 229 CREATE NodeModel NAME 230 DEFINE ConnectionPoint FROM VNFD: 232 4.3. An example 234 Once these two elements are included in the NEMO language, it is 235 possibly to recursively define NodeModel elements that use VNFDs in 236 the lowest level of recursion. Firstly, we create NodeModels from 237 VNFDs: 239 CREATE NodeModel NAME SampleVNF 240 IMPORT VNFD from https://github.com/nfvlabs/openmano.git 241 /openmano/vnfs/examples/dataplaneVNF1.yaml 242 DEFINE ConnectionPoint data_inside as VNFD:ge0 243 DEFINE ConnectionPoint data_outside as VNFD:ge1 245 Import from a sample VNFD from the OpenMANO repository 247 Then we can reuse these NodeModels recursively to create complex 248 NodeModels: 250 CREATE NodeModel NAME ComplexNode 251 Node InputVNF TYPE SampleVNF 252 Node OutputVNF TYPE ShaperVNF 253 DEFINE ConnectionPoint input 254 DEFINE ConnectionPoint output 255 CONNECTION input_connection FROM input TO InputVNF:data_inside 256 TYPE p2p 257 CONNECTION output_connection FROM output TO ShaperVNF:wan 258 TYPE p2p 259 CONNECTION internal FROM InputVNF:data_outside TO ShaperVNF:lan 260 TYPE p2p 262 Create a composed NodeModel 264 This NodeModel definition creates a composed model linking the 265 SampleVNF created from the VNFD with a hypothetical ShaperVNF defined 266 elsewhere. This definition can be represented graphically as 267 follows: 269 +------------------------------------------------------+ 270 | ComplexVNF | 271 | +-------------+ +-------------+ | 272 input | | | | output 273 +------+ SampleVNF +-----------+ ShaperVNF +-------+ 274 | | | | | | 275 | +-------------+ +-------------+ | 276 | data_inside data_outside lan wan | 277 +------------------------------------------------------+ 279 Figure 3 281 In ETSI NFV, a network service is described by one or more VNFs that 282 are connected through one or more network VNFFGs. This is no more 283 than what is defined in the composed NodeModel shown if Figure 3. By 284 using NEMO, we provide a simple way to define VNF forwarding 285 graphs(VNF-FGs) in network service descriptors in a recursive way. 287 5. Conclusion 289 With the strategy defined in this document, we are able to link a 290 low-level VNF description into a high-level description language for 291 networks like NEMO. Effectively, we are introducing recursiveness in 292 VNFDs, allowing complex service descriptors to be built by reusing 293 previously tested descriptors graphs as building blocks. 295 Although we have used the OpenMANO descriptor format in this 296 document, other descriptors and concepts (i.e. as those used by TOSCA 297 [4]) can also be used as the lowest level in this extension to the 298 NEMO language. 300 6. IANA Considerations 302 This draft includes no request to IANA. 304 7. Security Considerations 306 The IMPORT construct allows referencing external resources. 307 Developers using it in NEMO scripts are advised to verify the source 308 of those external resources, and whenever possible, rely on sources 309 with a verifiable identity through cryptographic methods. 311 8. Acknowledgement 313 This work has been partially performed in the scope of the 314 SUPERFLUIDITY project, which has received funding from the European 315 Union's Horizon 2020 research and innovation programme under grant 316 agreement No.671566 (Research and Innovation Action). 318 9. References 320 9.1. Normative References 322 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 323 Requirement Levels", BCP 14, RFC 2119, 324 DOI 10.17487/RFC2119, March 1997, 325 . 327 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 328 Resource Identifier (URI): Generic Syntax", STD 66, 329 RFC 3986, DOI 10.17487/RFC3986, January 2005, 330 . 332 9.2. Informative References 334 [I-D.xia-sdnrg-nemo-language] 335 Xia, Y., Jiang, S., Zhou, T., Hares, S., and Y. Zhang, 336 "NEMO (NEtwork MOdeling) Language", draft-xia-sdnrg-nemo- 337 language-04 (work in progress), April 2016. 339 9.3. URIs 341 [1] https://github.com/nfvlabs/openmano 343 [2] yaml.org 345 [3] https://wiki.opendaylight.org/view/NEMO:Main 347 [4] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv- 348 v1.0.html 350 Authors' Addresses 352 Pedro A. Aranda Gutierrez 353 Telefonica I+D 354 Zurbaran, 10 355 Madrid 28010 356 Spain 358 Email: pedroa.aranda@telefonica.com 359 Diego R. Lopez 360 Telefonica I+D 361 Zurbaran, 12 362 Madrid 28010 363 Spain 365 Email: diego.r.lopez@telefonica.com