idnits 2.17.1 draft-sambo-ccamp-yang-fsm-transponder-reconf-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.sambo-netmod-yang-fsm]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 22, 2018) is 2012 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 7491 == Outdated reference: A later version (-05) exists of draft-sambo-netmod-yang-fsm-03 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group N. Sambo 3 Internet-Draft P. Castoldi 4 Intended status: Standards Track A. Sgambelluri 5 Expires: April 25, 2019 Scuola Superiore Sant'Anna 6 G. Fioccola 7 Huawei Technologies 8 F. Cugini 9 CNIT 10 D. Ceccarelli 11 Ericsson 12 H. Song 13 T. Zhou 14 Huawei 15 October 22, 2018 17 Finite state machine YANG model augmentation for Transponder 18 Reconfiguration 19 draft-sambo-ccamp-yang-fsm-transponder-reconf-02 21 Abstract 23 YANG enables to compile a set of consistent vendor-neutral data 24 models for optical networks and components based on actual 25 operational needs emerging from heterogeneous use cases. A YANG 26 model has been also proposed to describe finite state machine to 27 program network elements that are modeled with YANG. This document 28 augments the more generic YANG model for finite state machine 29 [I-D.sambo-netmod-yang-fsm], in order to pre-instruct an optical 30 transponder on the actions to be performed (e.g., code adaptation) in 31 case some events, such as physical layer degradations, occur. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 25, 2019. 50 Copyright Notice 52 Copyright (c) 2018 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Conventions used in this document . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Flexible Transponders . . . . . . . . . . . . . . . . . . . . 4 71 5. Augmenting the FSM YANG model for transponder reconfiguration 7 72 6. Code of the YANG model for transponder reconfiguration . . . 10 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 75 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 78 10.2. Informative References . . . . . . . . . . . . . . . . . 16 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 81 1. Introduction 83 Networks are evolving toward more programmability, flexibility, and 84 multi-vendor interoperability. Multi-vendor interoperability can be 85 applied in the context of nodes, i.e. a node composed of components 86 provided by different vendors (named fully disaggregated white box) 87 is assembled under the same control system. This way, operators can 88 optimize costs and network performance without the need of being tied 89 to single vendor equipment. NETCONF protocol RFC6241 [RFC6241] based 90 on YANG data modeling language RFC6020 [RFC6020] is emerging as a 91 candidate Software Defined Networking (SDN) enabled protocol. First, 92 NETCONF supports both control and management functionalities, thus 93 permits high programmability. Then, YANG enables data modeling in a 94 vendor-neutral way. Some recent works have provided YANG models to 95 describe attributes of links (e.g., identification), nodes (e.g., 96 connectivity matrix), media channels, and transponders (e.g., 97 supported forward error correction - FEC) of networks 98 ([I-D.ietf-i2rs-yang-network-topo] [I-D.vergara-ccamp-flexigrid-yang] 99 [I-D.zhang-ccamp-l1-topo-yang]), also including optical technologies. 100 A YANG model [I-D.sambo-netmod-yang-fsm] has been also proposed to 101 describe finite state machines (FSMs) in order to program actions 102 based on conditions and events in YANG-described devices. Such draft 103 mainly refers to elastic optical networks (EONs), i.e. optical 104 networks based on flexible grid where circuits with different 105 bandwidth requirements are switched. EONs are expected to employ 106 flexible transponders, i.e. transponders supporting multiple bit 107 rates, multiple modulation formats, and multiple codes. Such 108 transponders permits the (re-) configuration of the bit rate value 109 based on traffic requirements, as well as the configuration of the 110 modulation format and code based on the physical characteristics of a 111 path (e.g., quadrature phase shift keying is more robust than 16 112 quadrature amplitude modulation). This document augments the YANG 113 model for FSM [I-D.sambo-netmod-yang-fsm] to be applied in 114 programming reconfiguration of transponders in EONs based on physical 115 layer conditions. In particular, the model enables a centralized 116 remote network controller (managed by a network operator) to instruct 117 a transponder controller about the actions to perform when certain 118 events (e.g., failures) occur. The actions to be taken and the 119 events can be re-programmed on the device. 121 2. Conventions used in this document 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 [RFC2119]. 127 3. Terminology 129 ABNO: Application-Based Network Operations 131 BER: Bit Error Rate 133 EON: Elastic Optical Network 135 FEC: Forward Error Correction 137 FSM: Finite State Machine 139 NETCONF: Network Configuration Protocol 141 OAM: Operation Administration and Maintenance 143 SDN: Software Defined Network 145 YANG: Yet Another Network Generator 147 4. Flexible Transponders 149 Flexible transponders enable several parameters' configurations, 150 through the support of multiple modulation formats, baud rate, and 151 forward error correction (FEC) schemes. This way, transmission 152 parameters can be (re-)configured based on the physical layer 153 conditions. The YANG model presented in this draft enables to pre- 154 program reconfiguration settings of data plane devices in case of 155 changes in the physical layer conditions. In particular, soft 156 failures can be assumed. Soft failures imply transmission 157 performance degradation, in turns a bit error rate (BER) increase, 158 e.g. due to the ageing of some network devices. Without loosing 159 generality, the ABNO architecture is assumed for the control and 160 management of EONs (RFC7491 [RFC7491]). Considering the state of the 161 art, when pre-FEC BER passes above a predefined threshold, it is 162 expected that an alarm is sent to the OAM Handler, which communicates 163 with the ABNO controller that may trigger an SDN controller (that 164 could be the Provisioning Manager of ABNO RFC7491 [RFC7491]) for 165 computing new transmission parameters. The involved ABNO modules are 166 shown in the simplified ABNO architecture of Fig. 1. Then, 167 transponders are reconfigured. When alarms related to several 168 connections impacted by the soft failure are generated, this 169 procedure may be particularly time consuming. The related workflow 170 for transponder reconfiguration is shown in Fig. 2. The proposed 171 model enables an SDN controller to instruct the transponder about 172 reconfiguration of new transmission parameters values if a soft 173 failure occurs. This can be done before the failure occurs (e.g., 174 during the connection instantiation phase or during the connection 175 service), so that data plane devices can promptly reconfigure 176 themselves without querying the SDN controller to trigger an on- 177 demand recovery. This is expected to speed up the recovery process 178 from soft failures. The related flow chart is shown in Fig. 3. 180 ___________ ___________ 181 | ABNO | | OAM | 182 |controller | ------ | Handler | 183 |___________| |___________| 185 | | 186 | | 187 | | 188 ____________ | 189 | SDN | | 190 | controller | | 191 |____________| | 192 | 193 | | 194 | | 195 | | 196 _____________________________ 197 | Client | 198 | network | 199 |_____________________________| 201 Figure 1: Assumed ABNO functional modules 203 _____________________ 204 | 1 | 205 |Sending alarm to the | 206 | OAM Handler | 207 | | 208 |_____________________| 209 | 210 | 211 | 212 _____________________ 213 | 2 | 214 | Trigger | 215 | SDN Controller | 216 | | 217 |_____________________| 218 | 219 | 220 | 221 _____________________ 222 | 3 | 223 | Computation of | 224 | new transmission | 225 | parameters | 226 |_____________________| 227 | 228 | 229 | 230 _____________________ 231 | 4 | 232 | Data plane | 233 | reconfiguration | 234 | | 235 |_____________________| 237 Figure 2: Flow chart of the expected state-of-the-art approach 238 _______________________ 239 | 1 | 240 | Instructing the local | 241 | controller of | 242 | data plane devices | 243 |_______________________| 244 | 245 | 246 | 247 _______________________ 248 | 2 | 249 | Local reconfiguration | 250 | upon failure | 251 | detection | 252 |_______________________| 253 | 254 | 255 | 256 _______________________ 257 | 3 | 258 | | 259 | notification | 260 | | 261 |_______________________| 263 Figure 3: Flow chart of the approach exploiting YANG models in this 264 draft 266 5. Augmenting the FSM YANG model for transponder reconfiguration 268 This section augments the FSM YANG model presented in 269 [I-D.sambo-netmod-yang-fsm] to address the specific use case of 270 transponder reconfiguration triggered by physical layer changes. The 271 FSM is installed by the SDN controller in the local controller of the 272 transponder and then runs there. The installation of the FSM can be 273 enabled through a NETCONF message. Through FSM, the 274 SDN controller instructs the transponder about the possible events 275 (e.g., BER above a threshold) and reactions (e.g., change of 276 modulation format) by setting the thresholds (e.g., BER threshold) 277 and the reconfiguration settings. The FSM model is based on the 278 following main attributes: states, transitions (corresponding to some 279 specific event), and actions. In particular, more specifically with 280 respect to [I-D.sambo-netmod-yang-fsm], in such a use case, a state 281 corresponds to a specific configuration of transponder transmission 282 parameters: e.g., given by the modulation format and the FEC. A 283 transition is triggered when the pre-FEC BER (or another parameter 284 such as the OSNR) is below or above a threshold. To this purpose, 285 with respect to [I-D.sambo-netmod-yang-fsm], the attribute 286 is expressed by the definition of thresholds and operators. The 287 action mainly consists of the change of modulation format and/or FEC. 289 The Tree of the YANG model for transponder reconfiguration 290 (augmentation of the YANG model for FSM) is reported below. 292 module: ietf-treconf 293 +--rw current-state? leafref 294 +--rw states 295 +--rw state [id] 296 +--rw id state-id-type 297 +--rw description? string 298 +--rw transitions 299 +--rw transition [name] 300 +--rw name string 301 +--rw description? string 302 +--rw threshold-parameter? decimal64 303 +--rw threshold-operator? string 304 +--rw transition-action 305 +--rw action [id] 306 +--rw id transition-id-type 307 +--rw type enumeration 308 +--rw simple 309 +--rw execute 310 +--rw next-action? transition-id-type 311 +--rw next-state? Leafref 313 More specifically, the attribute is a list defining all the 314 transponder states. is an attribute defining a list of 315 events that may trigger the change of transponder state (e.g., BER 316 change). defines a threshold value, while 317 defines the operator <,>,<=,>=. Thus, if the 318 event BER>TH has to be modeled, the attribute 319 has to be set to "TH" while to ">". 320 defines a list of actions to take during the transition (e.g. change 321 of modulation format) defines the next transponder state 322 when an action is executed (e.g., new modulation format and FEC). 324 For more details about the other model attributes, the reader can 325 refer to [I-D.sambo-netmod-yang-fsm]. 327 In such a use case, we assume that an event (e.g., BER>TH) is 328 revealed by the digital signal processing (DSP) of the receiver. 329 Once the event is recognized, the modulation format and/or the FEC 330 have to be changed, both at the receiver and the transmitter. Thus, 331 the list of actions to be executed includes the change of 332 transmission parameters at the receiver side. Moreover, transmission 333 and receiver must be synchronized about the transmission settings 334 (modulation format and so no) for a proper transmission. Thus, when 335 the transponder at the receiver side decides to change its state, the 336 remote transponder at the transmitter side has to do the same state 337 transition. To this purpose, the list of actions also includes this 338 coordination. In particular, the transponder at the receiver side 339 sends a message to the transmitter to synchronize about the 340 transmission parameters to be adopted. This message can be sent over 341 a control channel. This way both the transmitter and receiver 342 operates with the same transmission parameters: e.g. the format, 343 FEC, and so on. 345 Such transponder reconfiguration based on FSM has been successfully 346 demonstrated by integrating control and data planes in a lab and 347 field trials. 349 Finally, a last consideration concerns the impact on transmission bit 350 rate when changing some transmission parameters. When passing from a 351 more spectral efficient modulation format (but less robust with 352 respect to physical impairments) to a less spectral efficient 353 modulation format (more robust) such that could be polarization 354 multiplexing 16 quadrature phase shift keying (PM-16QAM) and PM 355 quadrature phase shift keying (PM-QPSK) the bit rate is reduced 356 (halved in the case of PM-16QAM and PM-QPSK). This means that part 357 of the traffic cannot be recovered through FSM, but needs of other 358 restoration mechanisms (e.g., dynamic restoration). As an example, 359 the gain of the proposed FSM mechanism promptly recovering part of 360 the bit rate can be applied to high-priority traffic so that its 361 recovery can be faster without involving central controller, while 362 other classical recovery mechanisms (involving the sending of alarms, 363 their processing, new computations and setup) can be adopted for best 364 effort traffic (as the traffic that cannot be recovered when passing 365 from PM-16QAM to PM-QPSK). The same happens changing the code rate: 366 at fixed baud rate and modulation format, if the code redundancy is 367 increased, the net bit rate is decreased. Again, part of the traffic 368 can be promptly recovered through FSM, while the other by relying on 369 classical recovery mechanisms. Another case of applicability is 370 related to the "functional split" in next generation radio access 371 networks (RANs). In this scenario, the evolved NodeB (eNB) functions 372 are split into two new, most likely virtualized, network entities: 373 the Central Unit (CU) deployed in centralized locations and the 374 Distributed Unit (DU) deployed near the antenna. Several functional 375 splits are being considered, e.g. by 3GPP in TR 38.801 and IEEE 1914 376 Working Group in Next Generation Fronthaul Interface (NGFI). They 377 demand different requirements in terms of latency and capacity to the 378 fronthaul network connecting DU and CU. For example, in 3GPP TR 379 38.801, according to "Option 7c" functional split, 10.1-22.2Gb/s and 380 53.8-86.1Gb/s are required in the downstream and upstream links, 381 respectively, while, according to "Option 8" functional split, 382 157.3Gb/s is required both in downstream and upstream links. Thus, 383 the change of rate could reflect into a change of functional split. 385 6. Code of the YANG model for transponder reconfiguration 387 The related code is reported below. 389 file "ietf-treconf@2016-03-15.yang" 391 module ietf-treconf { 392 namespace "http://sssup.it/fsm"; 393 prefix fsm; 395 organization 396 "Scuola Superiore Sant'Anna Network and Services Laboratory"; 398 contact 399 " Editor: Matteo Dallaglio 400 401 "; 403 description 404 "This module contains a YANG definitions of a generic finite state 405 machine."; 407 revision 2016-03-15 { 408 description "Initial Revision."; 409 reference 410 "RFC xxxx:"; 411 } 413 identity TRANSITION { 414 description "Base for all types of event"; 415 } 417 identity ON_CHANGE { 418 base TRANSITION; 419 description 420 "The event when the database changes."; 421 } 423 // typedef statements 424 typedef transition-type { 425 description "it defines the transition type"; 426 type identityref { 427 base TRANSITION; 428 } 429 } 431 typedef transition-id-type { 432 description "it defines the transition id type"; 433 type uint32; 434 } 436 // grouping statements 437 grouping action-block { 438 description "it defines the grouping action"; 439 leaf id { 440 description "it defines the id of the transition"; 441 type transition-id-type; 442 } 443 leaf type { 444 description "it defines if the action has to be simply executed 445 or if a conditional statement has to be checked before execution"; 447 type enumeration { 448 enum "CONDITIONAL_OP"{ 449 description "it defines the type CONDITIONAL OPERATION to check a 450 statement before execution. In this draft, at the moment, only SIMPLE 451 will be assumed"; 453 } 454 enum "SIMPLE_OP"{ 455 description "it defines the type SIMPLE OPERATION: i.e., an operation 456 to be directly executed; 457 } 458 } 459 mandatory true; 460 } 462 grouping execution-top { 463 description "it defines the execution attribute"; 464 anyxml execute { 465 description "Represent the action to perform"; 466 } 467 leaf next-action { 468 type transition-id-type; 469 description "the id of the next action to execute"; 470 } 472 } 474 container simple { 475 when "../type = 'SIMPLE_OP'"; 476 description 477 "Simple execution of an action without checking any condition"; 478 uses execution-top; 479 } 480 } 482 grouping action-top { 483 description "it defines the grouping of action"; 484 list action { 485 description "it defines the list of actions"; 486 key "id"; 488 ordered-by user; 489 uses action-block; 490 } 491 } 493 grouping on-change { 494 description 495 "Event occuring when a modification of one or more 496 objects occurs"; 498 leaf threshold-parameter { 499 description "it defines the threshold of an event determined by 500 a threshold exceed"; 501 type decimal64; 502 } 504 leaf threshold-operator { 505 description "it defines the operator to check the threshold 506 exceed: <, > <=, >="; 507 type string; 508 } 510 } 512 grouping transition-top { 513 description "it defines the grouping transition"; 514 leaf name { 515 description "it defines the transition name"; 516 type string; 517 mandatory true; 519 } 521 leaf description { 522 description "it describes the transition with a string"; 523 type string; 524 } 526 // list of all possible events 527 uses on-change { 528 when "type = 'ON_CHANGE'"; 529 } 531 container transition-action { 532 description "it defines the container actions to take during the 533 transition"; 534 uses action-top; 535 } 536 } 538 grouping transitions-top { 539 description "it defines the grouping transition"; 540 container transitions { 541 description "it defines the container transitions"; 542 list transition { 543 description "it defines the list of transitions"; 544 key "name"; 545 uses transition-top; 547 } 548 } 549 } 551 // data definition statements 553 uses transitions-top; 555 // extension statements 557 // feature statements 559 // augment statements 561 // rpc statements 563 // notification statements 564 // identity statements 566 // typedef statements 568 typedef state-id-type { 569 description "it defines the id type of the states"; 570 type uint32; 571 } 573 // grouping statements 574 grouping state-top { 575 description "it defines the grouping state"; 576 leaf id { 577 description "it defines the id of the state"; 578 type state-id-type; 579 } 581 leaf description { 582 description "it describes the state with a string"; 583 type string; 584 } 586 grouping next-state-top { 587 description "it defines the grouping next state"; 588 leaf next-state { 589 type leafref { 590 path "../../../../../../../../../states/state/id"; 591 } 592 description "Id of the next state"; 593 } 594 } 596 uses transitions-top { 597 augment "transitions/transition/transition-action/action/simple" { 598 //uses next-state-top; 599 leaf next-state { 600 type leafref { 601 path "../../../../../../../../states/state/id"; 602 } 603 description "Id of the next state"; 604 } 605 } 606 } 608 } 609 grouping states-top { 610 description "it defines the attributes of state-top"; 611 leaf current-state { 612 description "it defines the current state"; 613 type leafref { 614 description "it refers to its id"; 615 path "../states/state/id"; 616 } 617 } 619 container states { 620 description "it defines the container states"; 621 list state { 622 description "it defines the list of states"; 623 key "id"; 624 uses state-top; 625 } 626 } 627 } 629 // data definition statements 631 uses states-top; 633 // extension statements 635 // feature statements 637 // augment statements. 639 // rpc statements 641 // notification statements 643 }//module fsm 645 646 7. Acknowledgements 648 This work has been partially supported by the European Commission 649 through the EU H2020 5G-TRANSFORMER Project (grant no. 761536) and 650 the H2020 ORCHESTRA (Optical peRformanCe monitoring enabling dynamic 651 networks using a Holistic cross-layEr, Self-configurable Truly 652 flexible approach, grant agreement no: H2020-645360) project. The 653 views expressed here are those of the authors only. The European 654 Commission is not liable for any use that may be made of the 655 information in this document. 657 8. Security Considerations 659 TBD 661 9. IANA Considerations 663 TBD 665 10. References 667 10.1. Normative References 669 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 670 Requirement Levels", BCP 14, RFC 2119, 671 DOI 10.17487/RFC2119, March 1997, 672 . 674 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 675 the Network Configuration Protocol (NETCONF)", RFC 6020, 676 DOI 10.17487/RFC6020, October 2010, 677 . 679 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 680 and A. Bierman, Ed., "Network Configuration Protocol 681 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 682 . 684 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 685 Application-Based Network Operations", RFC 7491, 686 DOI 10.17487/RFC7491, March 2015, 687 . 689 10.2. Informative References 691 [I-D.ietf-i2rs-yang-network-topo] 692 Clemm, A., Medved, J., Varga, R., Bahadur, N., 693 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 694 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 695 progress), December 2017. 697 [I-D.sambo-netmod-yang-fsm] 698 Sambo, N., Castoldi, P., Fioccola, G., Cugini, F., Song, 699 H., and T. Zhou, "YANG model for finite state machine", 700 draft-sambo-netmod-yang-fsm-03 (work in progress), July 701 2018. 703 [I-D.vergara-ccamp-flexigrid-yang] 704 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 705 King, D., Lee, Y., and G. Galimberti, "YANG data model for 706 Flexi-Grid Optical Networks", draft-vergara-ccamp- 707 flexigrid-yang-06 (work in progress), January 2018. 709 [I-D.zhang-ccamp-l1-topo-yang] 710 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., and X. 711 Liu, "A YANG Data Model for Optical Transport Network 712 Topology", draft-zhang-ccamp-l1-topo-yang-07 (work in 713 progress), April 2017. 715 Authors' Addresses 717 Nicola Sambo 718 Scuola Superiore Sant'Anna 719 Via Moruzzi 1 720 Pisa 56124 721 Italy 723 Email: nicola.sambo@sssup.it 725 Piero Castoldi 726 Scuola Superiore Sant'Anna 727 Via Moruzzi 1 728 Pisa 56124 729 Italy 731 Email: piero.castoldi@sssup.it 732 Andrea Sgambelluri 733 Scuola Superiore Sant'Anna 734 Via Moruzzi 1 735 Pisa 56124 736 Italy 738 Email: andrea.sgambelluri@sssup.it 740 Giuseppe Fioccola 741 Huawei Technologies 742 Riesstrasse, 25 743 Munich 80992 744 Germany 746 Email: giuseppe.fioccola@huawei.com 748 Filippo Cugini 749 CNIT 750 Via Moruzzi 1 751 Pisa 56124 752 Italy 754 Email: filippo.cugini@cnit.it 756 Daniele Ceccarelli 757 Ericsson 758 Torshamnsgatan,48 759 Stockholm 164 40 760 Sweden 762 Email: daniele.ceccarelli@ericsson.com 764 Haoyu Song 765 Huawei 766 2330 Central Expressway 767 Santa Clara, CA 95050 768 USA 770 Email: haoyu.song@huawei.com 771 Tianran Zhou 772 Huawei 773 156 Beiqing Road 774 Beijing 100095 775 China 777 Email: zhoutianran@huawei.com