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