idnits 2.17.1 draft-aranda-nfvrg-recursive-vnf-05.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 394 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 (February 27, 2018) is 2249 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 478 -- Looks like a reference, but probably isn't: '2' on line 480 -- Looks like a reference, but probably isn't: '3' on line 482 -- Looks like a reference, but probably isn't: '4' on line 484 -- Looks like a reference, but probably isn't: '5' on line 486 -- Looks like a reference, but probably isn't: '6' on line 488 -- Looks like a reference, but probably isn't: '7' on line 490 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NFVRG P. Aranda Gutierrez 3 Internet-Draft UC3M 4 Intended status: Informational D. Lopez 5 Expires: August 31, 2018 Telefonica 6 S. Salsano 7 Univ. of Rome Tor Vergata/CNIT 8 E. Batanero 9 February 27, 2018 11 High-level VNF Descriptors using NEMO 12 draft-aranda-nfvrg-recursive-vnf-05 14 Abstract 16 Current efforts in the scope of Network Function Virtualisation(NFV) 17 propose YAML-based descriptors for Virtual Network Functions (VNFs) 18 and for their composition in Network Services (NS) These descriptors 19 are human-readable but hardly understandable by humans. On the other 20 hand, there has been an effort proposed to the IETF to define a 21 human-readable (and understandable) representation for networks, 22 known as NEMO. In this draft, we propose a simple extension to NEMO 23 to accommodate VNF Descriptors (VNFDs) in a similar manner as inline 24 assembly is integrated in higher-level programming languages. 26 This approach enables the creation of recursive VNF forwarding graphs 27 in Service Descriptors, practically making them recursive. An 28 implementation generating VNF Descriptors (VNFDs) for OpenMANO and 29 OSM is available. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at https://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on August 31, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (https://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology and abbreviations . . . . . . . . . . . . . . . . 3 67 3. Prior art . . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3.1. Virtual network function descriptors . . . . . . . . . . 3 69 3.1.1. OpenMANO VNFDs . . . . . . . . . . . . . . . . . . . 4 70 3.1.2. ETSI MANO VNFDs . . . . . . . . . . . . . . . . . . . 5 71 3.2. NEMO . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 4. Additional requirements on NEMO . . . . . . . . . . . . . . . 8 73 4.1. Referencing VNFDs in a NodeModel . . . . . . . . . . . . 8 74 4.2. Referencing the network interfaces of a VNF in a 75 NodeModel . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.3. An example . . . . . . . . . . . . . . . . . . . . . . . 8 77 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 9 78 6. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 85 11.2. Informative References . . . . . . . . . . . . . . . . . 11 86 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 Currently, there is a lot of on-going activity to deploy NFV in the 92 network. From the point of view of the orchestration, Virtual 93 Network Functions are blocks that are deployed in the infrastructure 94 as independent units. Following the reference architectural model 95 proposed in [ETSI-NFV-MANO], VNFs provide for one layer of components 96 (VNF components(VNFCs)) below, i.e. a set of VNFCs accessible to a 97 VNF provider can be composed into VNFs. However, there is no simple 98 way to use existing VNFs as components in VNFs with a higher degree 99 of complexity. In addition, Network Service Descriptors (NSD) and 100 VNF Descriptors (VNFDs) specified in [ETSI-NFV-MANO] and used in 101 different open source MANO frameworks are YAML-based files, which 102 despite being human readable, are not easy to understand. 104 On the other hand, there has been recently an attempt to work on a 105 modelling language for networks or Network Modelling (NEMO) language. 106 This language is human-readable and provides constructs that support 107 recursiveness. In this draft, we propose an addition to NEMO to make 108 it interact with VNFDs supported by a NFV MANO framework. This 109 integration creates a new language for VNFDs that is recursive, 110 allowing VNFs to be created based on the definitions of existing 111 VNFs. 113 This draft uses two example formats to show how low level descriptors 114 can be imported into NEMO. The first one is the format used in the 115 OpenMANO [1] framework. The second one follows strictly the 116 specifications provided by ETSI NFV ISG in [ETSI-NFV-MANO]. 117 Conceptually, other descriptor formats like TOSCA can also be used at 118 this level. 120 2. Terminology and abbreviations 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in [RFC2119]. 126 3. Prior art 128 3.1. Virtual network function descriptors 130 Virtual network function descriptors (VNFDs) are used in the 131 Management and orchestration (MANO) framework of the ETSI NFV to 132 achieve the optimal deployment of virtual network functions (VNFs). 133 The Virtual Infrastructure Manager (VIM) uses this information to 134 place the functions optimally. VNFDs include information of the 135 components of a specific VNF and their interconnection to implement 136 the VNF, in the form of a forwarding graph. In addition to the 137 forwarding graph, the VNFD includes information regarding the 138 interfaces of the VNF. These are then used to connect the VNF to 139 either physical or logical interfaces once it is deployed. 141 There are different MANO frameworks available. For this draft, we 142 will first concentrate on the example of OpenMANO [2], which uses a 143 YAML [3] representation similar to the one specified in 145 [ETSI-NFV-MANO]. Then we will provide an example using the exact 146 format specified in [ETSI-NFV-MANO]. 148 3.1.1. OpenMANO VNFDs 150 Taking the example from the (public) OpenMANO github repository, we 151 can easily identify the virtual interfaces of the sample VNFs in 152 their descriptors: 154 +----------------------------+ 155 | | 156 mgt0 | +---------------+ | ge0 157 | | | | 158 ---+-----+ Template VM +------+------ 159 | | | | 160 | +---+--------+--+ | 161 | | | | 162 +---------+--------+---------+ 163 | | 164 xe0 xe1 166 vnf: 167 name: TEMPLATE 168 description: This is a template to help in the creation of 169 # class: parent # Optional. Used to organize VNFs 170 external-connections: 171 - name: mgmt0 172 type: mgmt 173 VNFC: TEMPLATE-VM 174 local_iface_name: mgmt0 175 description: Management interface 176 - name: xe0 177 type: data 178 VNFC: TEMPLATE-VM 179 local_iface_name: xe0 180 description: Data interface 1 181 - name: xe1 182 type: data 183 VNFC: TEMPLATE-VM 184 local_iface_name: xe1 185 description: Data interface 2 186 - name: ge0 187 type: bridge 188 VNFC: TEMPLATE-VM 189 local_iface_name: ge0 190 description: Bridge interface 192 Figure 1: Sample VNF and descriptor (source: OpenMANO github) 194 3.1.2. ETSI MANO VNFDs 196 In this example we consider the VNF represented in Figure 6.4 of 197 [ETSI-NFV-MANO]. Its internal diagram, including a VNF component, is 198 represented in Figure Figure 2. A YAML representation of the VNF 199 Descriptor is reported in Figure Figure 3. The topology of the 200 interconnection of VNFs is expressed by using the abstraction of 201 Virtual Links, which interconnect Connection Points of the VNFs. The 202 Virtual Links are described by Virtual Link Descriptors (VLD) files. 203 An example YAML representation of the Virtual Link VL1 in the example 204 VNF is reported in Figure Figure 3. In order to understand the 205 topology, a (potentially large) set of VNFD and VLD files needs to be 206 analysed. For a human programmer of the service, this representation 207 is not friendly to write and very hard to read/understand/debug. 209 +----------------------------+ 210 | VNF1 | 211 +----------------------------+ 212 | | 213 | +-------------+ | 214 | | VNFC11 | | 215 | +-------------+ | 216 | | | | 217 | | +----+ | | 218 | | |CP14| | | 219 | | +-+--+ | | 220 | | | | | 221 | +-------------+ | 222 | | | 223 | +--+----+ | 224 | +----+ VL11 +---+ | 225 | | +--+----+ | | 226 | | | | | 227 | +-+--+ +-+--+ +--+-+ | 228 | |CP11| |CP12| |CP13| | 229 | +-+--+ +-+--+ +--+-+ | 230 | | | | | 231 +----------------------------+ 232 | | | 233 +----+--+ +--+----+ +-+-----+ 234 | VL1 | | VL2 | | VL3 | 235 +-------+ +-------+ +-------+ 237 Figure 2: VNF example 239 ####################################### 240 # VNF Descriptor of a VNF called vnf1 241 ####################################### 242 id: vnf1 243 description_version: '0.1' 244 vendor: netgroup 245 version: '0.1' 246 connection_point: 247 - id: cp11 248 type: '' 249 virtual_link_reference: vl11 250 - id: cp12 251 type: '' 252 virtual_link_reference: vl11 253 - id: cp13 254 type: '' 255 virtual_link_reference: vl11 256 vdu: 257 - id: vdu11 258 computation_requirement: '' 259 virtual_memory_resource_element: '' 260 virtual_network_bandwidth_resource: '' 261 vnfc: 262 - id: vnfc11 263 connection_point: 264 - id: cp14 265 type: NIC 266 virtual_link_reference: vl11 267 virtual_link: 268 - id: vl11 269 connection_points_references: 270 - cp11 271 - cp12 272 - cp13 273 - cp14 274 connectivity_type: ' E-Line' 275 root_requirement: '' 277 Figure 3: ETSI MANO compliant VNF descriptor example 279 ############################################ 280 # Virtual Link Descriptor of a VL called vl1 281 ############################################ 282 id: vl1 283 descriptor_version: '0.1' 284 test_access: none 285 vendor: netgroup 286 connection: 287 - cp01 288 - cp11 289 connectivity_type: E-LAN 290 number_of_endpoints: 2 291 root_requirement: '' 293 Figure 4: ETSI MANO compliant Virtual Link descriptor example 295 3.2. NEMO 297 The Network Modeling (NEMO) language is described in 298 [I-D.xia-sdnrg-nemo-language]. It provides a simple way of 299 describing network scenarios. The language is based on a two-stage 300 process. In the first stage, models for nodes, links and other 301 entities are defined. In the second stage, the defined models are 302 instantiated. The NEMO language also allows for behavioural 303 descriptions. A variant of the NEMO language is used in the 304 OpenDaylight NEMO northbound API [4]. 306 NEMO allows to define NodeModels, which are then instantiated in the 307 infrastructure. NodeModels are recursive and can be build with basic 308 node types or with previously defined NodeModels. An example for a 309 script defining a NodeModel is shown below: 311 CREATE NodeModel dmz 312 Property string: location-fw, string: location-n2, 313 string: ipprefix, string: gatewayip, string: srcip, 314 string: subnodes-n2; 315 Node fw1 316 Type fw 317 Property location: location-fw, 318 operating-mode: layer3; 319 ... 321 Figure 5: Creating a NodeModel in NEMO 323 4. Additional requirements on NEMO 325 In order to integrate VNFDs into NEMO, we need to take into account 326 two specifics of VNFDs, which cannot be expressed in the current 327 language model. Firstly, we need a way to reference the file which 328 holds the VNFD provided by the VNF developer. This will normally be 329 a universal resource identifier (URI). Additionally, we need to make 330 the NEMO model aware of the virtual network interfaces. 332 4.1. Referencing VNFDs in a NodeModel 334 As explained in the introduction, in order integrate VNFDs into the 335 NEMO language in the easiest way we need to reference the VNFD as a 336 Universal Resource Identifier (URI) as defined in RFC 3986 [RFC3986]. 337 To this avail, we define a new element in the NodeModel to import the 338 VNFD: 340 CREATE NodeModel VNFD ; 342 4.2. Referencing the network interfaces of a VNF in a NodeModel 344 As shown in Figure 1, VNFDs include an exhaustive list of interfaces, 345 including the interfaces to the management network. However, since 346 these interfaces may not be significant for specific network 347 scenarios and since interface names in the VNFD may not be adequate 348 in NEMO, we propose to define a new entity, namely the 349 ConnectionPoint, which is included in the node model . 351 CREATE NodeModel ; 352 ConnectionPoint at VNFD:; 354 4.3. An example 356 Once these two elements are included in the NEMO language, it is 357 possibly to recursively define NodeModel elements that use VNFDs in 358 the lowest level of recursion. Firstly, we create NodeModels from 359 VNFDs: 361 CREATE NodeModel sample_vnf VNFD https://github.com/nfvlabs 362 /openmano.git/openmano/vnfs/examples/dataplaneVNF1.yaml; 363 ConnectionPoint data_inside at VNFD:ge0; 364 ConnectionPoint data_outside at VNFD:ge1; 366 Import from a sample VNFD from the OpenMANO repository 368 Then we can reuse these NodeModels recursively to create complex 369 NodeModels: 371 CREATE NodeModel complex_vnf; 372 Node input_vnf Type sample_vnf; 373 Node output_vnf Type shaper_vnf; 374 ConnectionPoint input; 375 ConnectionPoint output 376 Connection icon Type p2p Endnodes input, input_vnf:data_inside; 377 Connection ocon Type p2p Endnodes output, output_vnf:wan; 378 Connection intn Type p2p input_vnf:data_outside, output_vnf:lan; 380 Create a composed NodeModel 382 This NodeModel definition creates a composed model linking the 383 sample_vnf created from the VNFD with a hypothetical shaper_vnf 384 defined elsewhere. This definition can be represented graphically as 385 follows: 387 +--------------------------------------------------------+ 388 | complex_vnf | 389 | +--------------+ +--------------+ | 390 input | | | | output 391 +------+ sample_vnf +-----------+ shaper_vnf +-------+ 392 | | | | | | 393 | +--------------+ +--------------+ | 394 | data_inside data_outside lan wan | 395 +--------------------------------------------------------+ 397 Figure 6 399 In ETSI NFV, a network service is described by one or more VNFs that 400 are connected through one or more network VNFFGs. This is no more 401 than what is defined in the composed NodeModel shown if Figure 6. By 402 using NEMO, we provide a simple way to define VNF forwarding graphs 403 (VNF-FGs) in network service descriptors in a recursive way. 405 5. Implementation 407 There is a proof of concept implementation of the concepts described 408 in this draft is available at github [5]. This proof of concept is 409 implemented as an OpenDayLight (ODL) [6] plugin and includes two 410 output stages to generate VNFDs for OpenMANO and OSM. In its current 411 implementation, the ODL plugin depends on an outdated NEMO project. 413 6. Future work 415 Future work includes an implementation that does not depend on ODL 416 and extensions to the language to separate control and data plane 417 connections explicitly. 419 7. Conclusion 421 With the strategy defined in this document, we are able to link a 422 low-level VNF description into a high-level description language for 423 networks like NEMO. Effectively, we are introducing recursiveness in 424 VNFDs, allowing complex service descriptors to be built by reusing 425 previously tested descriptors graphs as building blocks. 427 Although we have used the OpenMANO descriptor format in this 428 document, other descriptors and concepts (i.e. as those used by TOSCA 429 [7]) can also be used as the lowest level in this extension to the 430 NEMO language. 432 8. IANA Considerations 434 This draft includes no request to IANA. 436 9. Security Considerations 438 The VNFD construct as IMPORT allows referencing external resources. 439 Developers using it in NEMO scripts are advised to verify the source 440 of those external resources, and whenever possible, rely on sources 441 with a verifiable identity through cryptographic methods. 443 10. Acknowledgement 445 This work has been partially performed in the scope of the 446 SUPERFLUIDITY project, which has received funding from the European 447 Union's Horizon 2020 research and innovation programme under grant 448 agreement No.671566 (Research and Innovation Action). 450 11. References 452 11.1. Normative References 454 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 455 Requirement Levels", BCP 14, RFC 2119, 456 DOI 10.17487/RFC2119, March 1997, 457 . 459 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 460 Resource Identifier (URI): Generic Syntax", STD 66, 461 RFC 3986, DOI 10.17487/RFC3986, January 2005, 462 . 464 [ETSI-NFV-MANO] 465 ETSI, "Network Functions Virtualisation (NFV); Management 466 and Orchestration", ETSI GS NFV-MAN 001 V1.1.1 (2014-12), 467 December 2014. 469 11.2. Informative References 471 [I-D.xia-sdnrg-nemo-language] 472 Xia, Y., Jiang, S., Zhou, T., Hares, S., and Y. Zhang, 473 "NEMO (NEtwork MOdeling) Language", draft-xia-sdnrg-nemo- 474 language-04 (work in progress), April 2016. 476 11.3. URIs 478 [1] https://github.com/nfvlabs/openmano 480 [2] https://github.com/nfvlabs/openmano 482 [3] yaml.org 484 [4] https://wiki.opendaylight.org/view/NEMO:Main 486 [5] https://github.com/telefonicaid/vibnemo 488 [6] http://www.opendaylight.org 490 [7] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv- 491 v1.0.html 493 Authors' Addresses 495 Pedro A. Aranda Gutierrez 496 Universidad Carlos III Madrid 497 Leganes 28911 498 Spain 500 Email: paranda@it.uc3m.es 501 Diego R. Lopez 502 Telefonica I+D 503 Zurbaran, 12 504 Madrid 28010 505 Spain 507 Email: diego.r.lopez@telefonica.com 509 Stefano Salsano 510 Univ. of Rome Tor Vergata/CNIT 511 Via del Politecnico, 1 512 Rome 00133 513 Italy 515 Email: stefano.salsano@uniroma2.it 517 Elena Batanero 519 Email: elena.batanero.18@gmail.com