idnits 2.17.1 draft-aranda-nfvrg-recursive-vnf-06.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 395 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 (July 15, 2018) is 2102 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 562 -- Looks like a reference, but probably isn't: '2' on line 564 -- Looks like a reference, but probably isn't: '3' on line 566 -- Looks like a reference, but probably isn't: '4' on line 568 -- Looks like a reference, but probably isn't: '5' on line 570 -- Looks like a reference, but probably isn't: '6' on line 572 -- Looks like a reference, but probably isn't: '7' on line 574 -- Looks like a reference, but probably isn't: '8' on line 576 -- Looks like a reference, but probably isn't: '11' on line 582 -- Looks like a reference, but probably isn't: '12' on line 584 -- Looks like a reference, but probably isn't: '13' on line 587 -- Looks like a reference, but probably isn't: '9' on line 578 -- Looks like a reference, but probably isn't: '10' on line 580 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 15 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: January 16, 2019 Telefonica 6 S. Salsano 7 Univ. of Rome Tor Vergata/CNIT 8 E. Batanero 9 July 15, 2018 11 High-level VNF Descriptors using NEMO 12 draft-aranda-nfvrg-recursive-vnf-06 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 January 16, 2019. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 4. Additional requirements on NEMO . . . . . . . . . . . . . . . 9 73 4.1. Referencing VNFDs in a NodeModel . . . . . . . . . . . . 9 74 4.2. Referencing the network interfaces of a VNF in a 75 NodeModel . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.3. An example . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Implementation . . . . . . . . . . . . . . . . . . . . . . . 10 78 6. Operational Experience . . . . . . . . . . . . . . . . . . . 11 79 7. Future work . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 83 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 84 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 86 12.2. Informative References . . . . . . . . . . . . . . . . . 14 87 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 90 1. Introduction 92 Currently, there is a lot of on-going activity to deploy NFV in the 93 network. From the point of view of the orchestration, Virtual 94 Network Functions are blocks that are deployed in the infrastructure 95 as independent units. Following the reference architectural model 96 proposed in [ETSI-NFV-MANO], VNFs provide for one layer of components 97 (VNF components(VNFCs)) below, i.e. a set of VNFCs accessible to a 98 VNF provider can be composed into VNFs. However, there is no simple 99 way to use existing VNFs as components in VNFs with a higher degree 100 of complexity. In addition, Network Service Descriptors (NSD) and 101 VNF Descriptors (VNFDs) specified in [ETSI-NFV-MANO] and used in 102 different open source MANO frameworks are YAML-based files, which 103 despite being human readable, are not easy to understand. 105 On the other hand, there has been recently an attempt to work on a 106 modelling language for networks or Network Modelling (NEMO) language. 107 This language is human-readable and provides constructs that support 108 recursiveness. In this draft, we propose an addition to NEMO to make 109 it interact with VNFDs supported by a NFV MANO framework. This 110 integration creates a new language for VNFDs that is recursive, 111 allowing VNFs to be created based on the definitions of existing 112 VNFs. 114 This draft uses two example formats to show how low level descriptors 115 can be imported into NEMO. The first one is the format used in the 116 OpenMANO [1] framework. The second one follows strictly the 117 specifications provided by ETSI NFV ISG in [ETSI-NFV-MANO]. 118 Conceptually, other descriptor formats like TOSCA can also be used at 119 this level. 121 2. Terminology and abbreviations 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in [RFC2119]. 127 3. Prior art 129 3.1. Virtual network function descriptors 131 Virtual network function descriptors (VNFDs) are used in the 132 Management and orchestration (MANO) framework of the ETSI NFV to 133 achieve the optimal deployment of virtual network functions (VNFs). 134 The Virtual Infrastructure Manager (VIM) uses this information to 135 place the functions optimally. VNFDs include information of the 136 components of a specific VNF and their interconnection to implement 137 the VNF, in the form of a forwarding graph. In addition to the 138 forwarding graph, the VNFD includes information regarding the 139 interfaces of the VNF. These are then used to connect the VNF to 140 either physical or logical interfaces once it is deployed. 142 There are different MANO frameworks available. For this draft, we 143 will first concentrate on the example of OpenMANO [2], which uses a 144 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 \ 379 Endnodes input_vnf:data_outside, output_vnf:lan; 381 Create a composed NodeModel 383 This NodeModel definition creates a composed model linking the 384 sample_vnf created from the VNFD with a hypothetical shaper_vnf 385 defined elsewhere. This definition can be represented graphically as 386 follows: 388 +--------------------------------------------------------+ 389 | complex_vnf | 390 | +--------------+ +--------------+ | 391 input | | | | output 392 +------+ sample_vnf +-----------+ shaper_vnf +-------+ 393 | | | | | | 394 | +--------------+ +--------------+ | 395 | data_inside data_outside lan wan | 396 +--------------------------------------------------------+ 398 Figure 6 400 In ETSI NFV, a network service is described by one or more VNFs that 401 are connected through one or more network VNFFGs. This is no more 402 than what is defined in the composed NodeModel shown if Figure 6. By 403 using NEMO, we provide a simple way to define VNF forwarding graphs 404 (VNF-FGs) in network service descriptors in a recursive way. 406 5. Implementation 408 There is a proof of concept implementation of the concepts described 409 in this draft is available at github [5]. This proof of concept is 410 implemented as an OpenDayLight (ODL) [6] plugin and includes two 411 output stages to generate VNFDs for OpenMANO and OSM. In its current 412 implementation, the ODL plugin depends on an outdated NEMO project. 414 This implementation is currently being updated to OpenDaylight Oxygen 415 (the latest version at the time of writing), as a first step towards 416 an ODL-independent implementation. 418 6. Operational Experience 420 We have used NEMO descriptors in the context of the MAMI Project [7], 421 to describe a measurement network service based on three virtual 422 network function components: 424 1. A Trafic [8] traffic generator and sink based on iperf3. 426 2. A tshark [9]-based packet capture 428 3. An InfluxDB [10]-based time series database to store measurements 430 The Network Service Descriptor must always include two instances of 431 the trafic-based VNFC, while the tshak VNFC and the influxdb VNFC are 432 optional (more information is provided at the trafic VNFC creation 433 description page [11].) 435 The process of creating the different node models is incremental. We 436 start by importing the node models: 438 CREATE NodeModel trafic VNFD https:///trafic.yaml; 439 ConnectionPoint mgmt at VNFD:eth0; 440 ConnectionPoint gen at VNFD:eth1; 442 CREATE NodeModel tshark VNFD https:///tshark.yaml; 443 ConnectionPoint mgmt at VNFD:eth0; 444 ConnectionPoint probe at VNFD:eth1; 446 CREATE NodeModel influxdb VNFD https:///influxdb.yaml; 447 ConnectionPoint mgmt at VNFD:eth0; 449 Figure 7: Creating VNFCs 451 Then, we create the kernel NSD, based on the trafic VNFCs only: 453 CREATE NodeModel trafic_kernel; 454 Node iperf-servers Type trafic; 455 Node iperf-clients Type trafic; 456 ConnectionPoint client; 457 ConnectionPoint server; 458 ConnectionPoint mgmt; 459 Connection icon Type p2p Endnodes client, iperfs-clients:gen; 460 Connection ocon Type p2p Endnodes server, iperfs-servers:gen; 461 Connection mgmt Type Lan \ 462 Endnodes mgmt, iperfs-servers:mgmt, iperfs-clients:mgmt; 464 Figure 8: Kernel NSD based on the trafic VNFCs 466 Adding the influxdb VNFC to create an autonomous measurement NSD that 467 includes local storage for the measurement results is accomplished 468 with the following NEMO script: 470 CREATE NodeModel 471 Node iperf-servers Type trafic_kernel; 472 Node database Type influxdb; 473 ConnectionPoint client; 474 ConnectionPoint server; 475 ConnectionPoint mgmt; 476 Connection icon Type p2p Endnodes client, trafic_kernel:client; 477 Connection ocon Type p2p Endnodes server, trafic_kernel:server; 478 Connection mgmt Type Lan \ 479 Endnodes mgmt, trafic_kernel:mgmt, influxdb:mgmt; 481 Figure 9: Adding influxdb 483 NEMO has shown a fundamental advantage when compared to YAML or JSON- 484 based descriptors: since it is human-understandable, the development 485 and debugging times of moderate to complex network service 486 descriptors have been shortened considerably and the learning curve 487 is much shallower compared with the original formats. 489 NEMO allows to identify requirements both for itself and MANO 490 developers more quickly. An example is the connection of the 491 wireshark-based traffic sniffing VNFC. The current connection types 492 (LAN or p2p ) do not consider port mirroring, a functionality 493 provided by the TAPaaS plugin in Openstack. This requirement will be 494 fed back to the different MANO communities (OSM, etc.) as a user 495 requirement. 497 7. Future work 499 Future work includes extensions to the language to separate control 500 and data plane connections explicitly and new types of connectivity 501 models, including a model that provides the TAP as a Service [12] 502 (TAPaaS) functionality available for OpenStack. 504 8. Conclusion 506 With the strategy defined in this document, we are able to link a 507 low-level VNF description into a high-level description language for 508 networks like NEMO. Effectively, we are introducing recursiveness in 509 VNFDs, allowing complex service descriptors to be built by reusing 510 previously tested descriptors graphs as building blocks. 512 Although we have used the OpenMANO and OSM descriptor formats in this 513 document and for the reference implementation, other descriptors and 514 concepts (i.e. as those used by TOSCA [13]) can also be used as the 515 lowest level in this extension to the NEMO language. 517 9. IANA Considerations 519 This draft includes no request to IANA. 521 10. Security Considerations 523 The VNFD construct as IMPORT allows referencing external resources. 524 Developers using it in NEMO scripts are advised to verify the source 525 of those external resources, and whenever possible, rely on sources 526 with a verifiable identity through cryptographic methods. 528 11. Acknowledgement 530 The work presented in this paper is partially funded by the European 531 Union's Horizon 2020 research and innovation programme under grant 532 agreement No 688421. 534 12. References 536 12.1. Normative References 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", BCP 14, RFC 2119, 540 DOI 10.17487/RFC2119, March 1997, 541 . 543 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 544 Resource Identifier (URI): Generic Syntax", STD 66, 545 RFC 3986, DOI 10.17487/RFC3986, January 2005, 546 . 548 [ETSI-NFV-MANO] 549 ETSI, "Network Functions Virtualisation (NFV); Management 550 and Orchestration", ETSI GS NFV-MAN 001 V1.1.1 (2014-12), 551 December 2014. 553 12.2. Informative References 555 [I-D.xia-sdnrg-nemo-language] 556 Xia, Y., Jiang, S., Zhou, T., Hares, S., and Y. Zhang, 557 "NEMO (NEtwork MOdeling) Language", draft-xia-sdnrg-nemo- 558 language-04 (work in progress), April 2016. 560 12.3. URIs 562 [1] https://github.com/nfvlabs/openmano 564 [2] https://github.com/nfvlabs/openmano 566 [3] yaml.org 568 [4] https://wiki.opendaylight.org/view/NEMO:Main 570 [5] https://github.com/telefonicaid/vibnemo 572 [6] http://www.opendaylight.org 574 [7] https://mami-project.eu 576 [8] https://github.com/mami-project/trafic/ 578 [9] https://www.wireshark.org 580 [10] https://www.influxdata.com 582 [11] https://github.com/mami-project/trafic/blob/master/README-VM.md 584 [12] https://docs.openstack.org/developer/dragonflow/specs/ 585 tap_as_a_service.html 587 [13] http://docs.oasis-open.org/tosca/tosca-nfv/v1.0/tosca-nfv- 588 v1.0.html 590 Authors' Addresses 592 Pedro A. Aranda Gutierrez 593 Universidad Carlos III Madrid 594 Leganes 28911 595 Spain 597 Email: paranda@it.uc3m.es 599 Diego R. Lopez 600 Telefonica I+D 601 Zurbaran, 12 602 Madrid 28010 603 Spain 605 Email: diego.r.lopez@telefonica.com 607 Stefano Salsano 608 Univ. of Rome Tor Vergata/CNIT 609 Via del Politecnico, 1 610 Rome 00133 611 Italy 613 Email: stefano.salsano@uniroma2.it 615 Elena Batanero 617 Email: elena.batanero.18@gmail.com