idnits 2.17.1 draft-aranda-nfvrg-recursive-vnf-04.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 393 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 (September 05, 2017) is 2418 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 469 -- Looks like a reference, but probably isn't: '2' on line 471 -- Looks like a reference, but probably isn't: '3' on line 473 -- Looks like a reference, but probably isn't: '4' on line 475 -- Looks like a reference, but probably isn't: '5' on line 477 -- Looks like a reference, but probably isn't: '6' on line 479 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 8 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: March 9, 2018 Telefonica 6 S. Salsano 7 Univ. of Rome Tor Vergata/CNIT 8 E. Batanero 9 September 05, 2017 11 High-level VNF Descriptors using NEMO 12 draft-aranda-nfvrg-recursive-vnf-04 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 March 9, 2018. 48 Copyright Notice 50 Copyright (c) 2017 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. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 10 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 84 10.2. Informative References . . . . . . . . . . . . . . . . . 11 85 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 Currently, there is a lot of on-going activity to deploy NFV in the 91 network. From the point of view of the orchestration, Virtual 92 Network Functions are blocks that are deployed in the infrastructure 93 as independent units. Following the reference architectural model 94 proposed in [ETSI-NFV-MANO], VNFs provide for one layer of components 95 (VNF components(VNFCs)) below, i.e. a set of VNFCs accessible to a 96 VNF provider can be composed into VNFs. However, there is no simple 97 way to use existing VNFs as components in VNFs with a higher degree 98 of complexity. In addition, Network Service Descriptors (NSD) and 99 VNF Descriptors (VNFDs) specified in [ETSI-NFV-MANO] and used in 100 different open source MANO frameworks are YAML-based files, which 101 despite being human readable, are not easy to understand. 103 On the other hand, there has been recently an attempt to work on a 104 modelling language for networks or Network Modelling (NEMO) language. 105 This language is human-readable and provides constructs that support 106 recursiveness. In this draft, we propose an addition to NEMO to make 107 it interact with VNFDs supported by a NFV MANO framework. This 108 integration creates a new language for VNFDs that is recursive, 109 allowing VNFs to be created based on the definitions of existing 110 VNFs. 112 This draft uses two example formats to show how low level descriptors 113 can be imported into NEMO. The first one is the format used in the 114 OpenMANO [1] framework. The second one follows strictly the 115 specifications provided by ETSI NFV ISG in [ETSI-NFV-MANO]. 116 Conceptually, other descriptor formats like TOSCA can also be used at 117 this level. 119 2. Terminology and abbreviations 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 3. Prior art 127 3.1. Virtual network function descriptors 129 Virtual network function descriptors (VNFDs) are used in the 130 Management and orchestration (MANO) framework of the ETSI NFV to 131 achieve the optimal deployment of virtual network functions (VNFs). 132 The Virtual Infrastructure Manager (VIM) uses this information to 133 place the functions optimally. VNFDs include information of the 134 components of a specific VNF and their interconnection to implement 135 the VNF, in the form of a forwarding graph. In addition to the 136 forwarding graph, the VNFD includes information regarding the 137 interfaces of the VNF. These are then used to connect the VNF to 138 either physical or logical interfaces once it is deployed. 140 There are different MANO frameworks available. For this draft, we 141 will first concentrate on the example of OpenMANO [2], which uses a 142 YAML [3] representation similar to the one specified in 144 [ETSI-NFV-MANO]. Then we will provide an example using the exact 145 format specified in [ETSI-NFV-MANO]. 147 3.1.1. OpenMANO VNFDs 149 Taking the example from the (public) OpenMANO github repository, we 150 can easily identify the virtual interfaces of the sample VNFs in 151 their descriptors: 153 +----------------------------+ 154 | | 155 mgt0 | +---------------+ | ge0 156 | | | | 157 ---+-----+ Template VM +------+------ 158 | | | | 159 | +---+--------+--+ | 160 | | | | 161 +---------+--------+---------+ 162 | | 163 xe0 xe1 165 vnf: 166 name: TEMPLATE 167 description: This is a template to help in the creation of 168 # class: parent # Optional. Used to organize VNFs 169 external-connections: 170 - name: mgmt0 171 type: mgmt 172 VNFC: TEMPLATE-VM 173 local_iface_name: mgmt0 174 description: Management interface 175 - name: xe0 176 type: data 177 VNFC: TEMPLATE-VM 178 local_iface_name: xe0 179 description: Data interface 1 180 - name: xe1 181 type: data 182 VNFC: TEMPLATE-VM 183 local_iface_name: xe1 184 description: Data interface 2 185 - name: ge0 186 type: bridge 187 VNFC: TEMPLATE-VM 188 local_iface_name: ge0 189 description: Bridge interface 191 Figure 1: Sample VNF and descriptor (source: OpenMANO github) 193 3.1.2. ETSI MANO VNFDs 195 In this example we consider the VNF represented in Figure 6.4 of 196 [ETSI-NFV-MANO]. Its internal diagram, including a VNF component, is 197 represented in Figure Figure 2. A YAML representation of the VNF 198 Descriptor is reported in Figure Figure 3. The topology of the 199 interconnection of VNFs is expressed by using the abstraction of 200 Virtual Links, which interconnect Connection Points of the VNFs. The 201 Virtual Links are described by Virtual Link Descriptors (VLD) files. 202 An example YAML representation of the Virtual Link VL1 in the example 203 VNF is reported in Figure Figure 3. In order to understand the 204 topology, a (potentially large) set of VNFD and VLD files needs to be 205 analysed. For a human programmer of the service, this representation 206 is not friendly to write and very hard to read/understand/debug. 208 +----------------------------+ 209 | VNF1 | 210 +----------------------------+ 211 | | 212 | +-------------+ | 213 | | VNFC11 | | 214 | +-------------+ | 215 | | | | 216 | | +----+ | | 217 | | |CP14| | | 218 | | +-+--+ | | 219 | | | | | 220 | +-------------+ | 221 | | | 222 | +--+----+ | 223 | +----+ VL11 +---+ | 224 | | +--+----+ | | 225 | | | | | 226 | +-+--+ +-+--+ +--+-+ | 227 | |CP11| |CP12| |CP13| | 228 | +-+--+ +-+--+ +--+-+ | 229 | | | | | 230 +----------------------------+ 231 | | | 232 +----+--+ +--+----+ +-+-----+ 233 | VL1 | | VL2 | | VL3 | 234 +-------+ +-------+ +-------+ 236 Figure 2: VNF example 238 ####################################### 239 # VNF Descriptor of a VNF called vnf1 240 ####################################### 241 id: vnf1 242 description_version: '0.1' 243 vendor: netgroup 244 version: '0.1' 245 connection_point: 246 - id: cp11 247 type: '' 248 virtual_link_reference: vl11 249 - id: cp12 250 type: '' 251 virtual_link_reference: vl11 252 - id: cp13 253 type: '' 254 virtual_link_reference: vl11 255 vdu: 256 - id: vdu11 257 computation_requirement: '' 258 virtual_memory_resource_element: '' 259 virtual_network_bandwidth_resource: '' 260 vnfc: 261 - id: vnfc11 262 connection_point: 263 - id: cp14 264 type: NIC 265 virtual_link_reference: vl11 266 virtual_link: 267 - id: vl11 268 connection_points_references: 269 - cp11 270 - cp12 271 - cp13 272 - cp14 273 connectivity_type: ' E-Line' 274 root_requirement: '' 276 Figure 3: ETSI MANO compliant VNF descriptor example 278 ############################################ 279 # Virtual Link Descriptor of a VL called vl1 280 ############################################ 281 id: vl1 282 descriptor_version: '0.1' 283 test_access: none 284 vendor: netgroup 285 connection: 286 - cp01 287 - cp11 288 connectivity_type: E-LAN 289 number_of_endpoints: 2 290 root_requirement: '' 292 Figure 4: ETSI MANO compliant Virtual Link descriptor example 294 3.2. NEMO 296 The Network Modeling (NEMO) language is described in 297 [I-D.xia-sdnrg-nemo-language]. It provides a simple way of 298 describing network scenarios. The language is based on a two-stage 299 process. In the first stage, models for nodes, links and other 300 entities are defined. In the second stage, the defined models are 301 instantiated. The NEMO language also allows for behavioural 302 descriptions. A variant of the NEMO language is used in the 303 OpenDaylight NEMO northbound API [4]. 305 NEMO allows to define NodeModels, which are then instantiated in the 306 infrastructure. NodeModels are recursive and can be build with basic 307 node types or with previously defined NodeModels. An example for a 308 script defining a NodeModel is shown below: 310 CREATE NodeModel dmz 311 Property string: location-fw, string: location-n2, 312 string: ipprefix, string: gatewayip, string: srcip, 313 string: subnodes-n2; 314 Node fw1 315 Type fw 316 Property location: location-fw, 317 operating-mode: layer3; 318 ... 320 Figure 5: Creating a NodeModel in NEMO 322 4. Additional requirements on NEMO 324 In order to integrate VNFDs into NEMO, we need to take into account 325 two specifics of VNFDs, which cannot be expressed in the current 326 language model. Firstly, we need a way to reference the file which 327 holds the VNFD provided by the VNF developer. This will normally be 328 a universal resource identifier (URI). Additionally, we need to make 329 the NEMO model aware of the virtual network interfaces. 331 4.1. Referencing VNFDs in a NodeModel 333 As explained in the introduction, in order integrate VNFDs into the 334 NEMO language in the easiest way we need to reference the VNFD as a 335 Universal Resource Identifier (URI) as defined in RFC 3986 [RFC3986]. 336 To this avail, we define a new element in the NodeModel to import the 337 VNFD: 339 CREATE NodeModel VNFD ; 341 4.2. Referencing the network interfaces of a VNF in a NodeModel 343 As shown in Figure 1, VNFDs include an exhaustive list of interfaces, 344 including the interfaces to the management network. However, since 345 these interfaces may not be significant for specific network 346 scenarios and since interface names in the VNFD may not be adequate 347 in NEMO, we propose to define a new entity, namely the 348 ConnectionPoint, which is included in the node model . 350 CREATE NodeModel ; 351 ConnectionPoint at VNFD:; 353 4.3. An example 355 Once these two elements are included in the NEMO language, it is 356 possibly to recursively define NodeModel elements that use VNFDs in 357 the lowest level of recursion. Firstly, we create NodeModels from 358 VNFDs: 360 CREATE NodeModel sample_vnf VNFD https://github.com/nfvlabs 361 /openmano.git/openmano/vnfs/examples/dataplaneVNF1.yaml; 362 ConnectionPoint data_inside at VNFD:ge0; 363 ConnectionPoint data_outside at VNFD:ge1; 365 Import from a sample VNFD from the OpenMANO repository 367 Then we can reuse these NodeModels recursively to create complex 368 NodeModels: 370 CREATE NodeModel complex_vnf; 371 Node input_vnf Type sample_vnf; 372 Node output_vnf Type shaper_vnf; 373 ConnectionPoint input; 374 ConnectionPoint output 375 Connection icon Type p2p Endnodes input, input_vnf:data_inside; 376 Connection ocon Type p2p Endnodes output, output_vnf:wan; 377 Connection intn Type p2p input_vnf:data_outside, output_vnf:lan; 379 Create a composed NodeModel 381 This NodeModel definition creates a composed model linking the 382 sample_vnf created from the VNFD with a hypothetical shaper_vnf 383 defined elsewhere. This definition can be represented graphically as 384 follows: 386 +--------------------------------------------------------+ 387 | complex_vnf | 388 | +--------------+ +--------------+ | 389 input | | | | output 390 +------+ sample_vnf +-----------+ shaper_vnf +-------+ 391 | | | | | | 392 | +--------------+ +--------------+ | 393 | data_inside data_outside lan wan | 394 +--------------------------------------------------------+ 396 Figure 6 398 In ETSI NFV, a network service is described by one or more VNFs that 399 are connected through one or more network VNFFGs. This is no more 400 than what is defined in the composed NodeModel shown if Figure 6. By 401 using NEMO, we provide a simple way to define VNF forwarding graphs 402 (VNF-FGs) in network service descriptors in a recursive way. 404 5. Implementation 406 There is a proof of concept implementation of the concepts described 407 in this draft is available at github [5]. It includes two output 408 stages to generate VNFDs for OpenMANO and OSM. 410 6. Conclusion 412 With the strategy defined in this document, we are able to link a 413 low-level VNF description into a high-level description language for 414 networks like NEMO. Effectively, we are introducing recursiveness in 415 VNFDs, allowing complex service descriptors to be built by reusing 416 previously tested descriptors graphs as building blocks. 418 Although we have used the OpenMANO descriptor format in this 419 document, other descriptors and concepts (i.e. as those used by TOSCA 420 [6]) can also be used as the lowest level in this extension to the 421 NEMO language. 423 7. IANA Considerations 425 This draft includes no request to IANA. 427 8. Security Considerations 429 The VNFD construct as IMPORT allows referencing external resources. 430 Developers using it in NEMO scripts are advised to verify the source 431 of those external resources, and whenever possible, rely on sources 432 with a verifiable identity through cryptographic methods. 434 9. Acknowledgement 436 This work has been partially performed in the scope of the 437 SUPERFLUIDITY project, which has received funding from the European 438 Union's Horizon 2020 research and innovation programme under grant 439 agreement No.671566 (Research and Innovation Action). 441 10. References 443 10.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 451 Resource Identifier (URI): Generic Syntax", STD 66, 452 RFC 3986, DOI 10.17487/RFC3986, January 2005, 453 . 455 [ETSI-NFV-MANO] 456 ETSI, "Network Functions Virtualisation (NFV); Management 457 and Orchestration", ETSI GS NFV-MAN 001 V1.1.1 (2014-12), 458 December 2014. 460 10.2. Informative References 462 [I-D.xia-sdnrg-nemo-language] 463 Xia, Y., Jiang, S., Zhou, T., Hares, S., and Y. Zhang, 464 "NEMO (NEtwork MOdeling) Language", draft-xia-sdnrg-nemo- 465 language-04 (work in progress), April 2016. 467 10.3. URIs 469 [1] https://github.com/nfvlabs/openmano 471 [2] https://github.com/nfvlabs/openmano 473 [3] yaml.org 475 [4] https://wiki.opendaylight.org/view/NEMO:Main 477 [5] https://github.com/telefonicaid/vibnemo 479 [6] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv- 480 v1.0.html 482 Authors' Addresses 484 Pedro A. Aranda Gutierrez 485 Universidad Carlos III Madrid 486 Leganes 28911 487 Spain 489 Email: paranda@it.uc3m.es 491 Diego R. Lopez 492 Telefonica I+D 493 Zurbaran, 12 494 Madrid 28010 495 Spain 497 Email: diego.r.lopez@telefonica.com 499 Stefano Salsano 500 Univ. of Rome Tor Vergata/CNIT 501 Via del Politecnico, 1 502 Rome 00133 503 Italy 505 Email: stefano.salsano@uniroma2.it 506 Elena Batanero 508 Email: elena.batanero.18@gmail.com