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