idnits 2.17.00 (12 Aug 2021) /tmp/idnits14755/draft-sambo-ccamp-yang-fsm-transponder-reconf-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 : ---------------------------------------------------------------------------- ** 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 (July 2, 2018) is 1419 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: draft-ietf-i2rs-yang-network-topo has been published as RFC 8345 == Outdated reference: A later version (-05) exists of draft-sambo-netmod-yang-fsm-02 Summary: 2 errors (**), 0 flaws (~~), 4 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: January 3, 2019 Scuola Superiore Sant'Anna 6 G. Fioccola 7 Telecom Italia 8 F. Cugini 9 CNIT 10 D. Ceccarelli 11 Ericsson 12 H. Song 13 T. Zhou 14 Huawei 15 July 2, 2018 17 Finite state machine YANG model augmentation for Transponder 18 Reconfiguration 19 draft-sambo-ccamp-yang-fsm-transponder-reconf-01 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 January 3, 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 . . . 9 73 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 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. A future version of the draft will 370 expand the list of actions also including the mechanism for recovery 371 the remaining traffic. 373 6. Code of the YANG model for transponder reconfiguration 375 The related code is reported below. 377 file "ietf-treconf@2016-03-15.yang" 378 module ietf-treconf { 379 namespace "http://sssup.it/fsm"; 380 prefix fsm; 382 organization 383 "Scuola Superiore Sant'Anna Network and Services Laboratory"; 385 contact 386 " Editor: Matteo Dallaglio 387 388 "; 390 description 391 "This module contains a YANG definitions of a generic finite state 392 machine."; 394 revision 2016-03-15 { 395 description "Initial Revision."; 396 reference 397 "RFC xxxx:"; 398 } 400 identity TRANSITION { 401 description "Base for all types of event"; 402 } 404 identity ON_CHANGE { 405 base TRANSITION; 406 description 407 "The event when the database changes."; 408 } 410 // typedef statements 412 typedef transition-type { 413 description "it defines the transition type"; 414 type identityref { 415 base TRANSITION; 416 } 417 } 419 typedef transition-id-type { 420 description "it defines the transition id type"; 421 type uint32; 422 } 423 // grouping statements 424 grouping action-block { 425 description "it defines the grouping action"; 426 leaf id { 427 description "it defines the id of the transition"; 428 type transition-id-type; 429 } 430 leaf type { 431 description "it defines if the action has to be simply executed 432 or if a conditional statement has to be checked before execution"; 434 type enumeration { 435 enum "CONDITIONAL_OP"{ 436 description "it defines the type CONDITIONAL OPERATION to check a 437 statement before execution. In this draft, at the moment, only SIMPLE 438 will be assumed"; 440 } 441 enum "SIMPLE_OP"{ 442 description "it defines the type SIMPLE OPERATION: i.e., an operation 443 to be directly executed; 444 } 445 } 446 mandatory true; 447 } 449 grouping execution-top { 450 description "it defines the execution attribute"; 451 anyxml execute { 452 description "Represent the action to perform"; 453 } 454 leaf next-action { 455 type transition-id-type; 456 description "the id of the next action to execute"; 457 } 458 } 460 container simple { 461 when "../type = 'SIMPLE_OP'"; 462 description 463 "Simple execution of an action without checking any condition"; 464 uses execution-top; 465 } 466 } 468 grouping action-top { 469 description "it defines the grouping of action"; 471 list action { 472 description "it defines the list of actions"; 473 key "id"; 475 ordered-by user; 476 uses action-block; 477 } 478 } 480 grouping on-change { 481 description 482 "Event occuring when a modification of one or more 483 objects occurs"; 485 leaf threshold-parameter { 486 description "it defines the threshold of an event determined by 487 a threshold exceed"; 488 type decimal64; 489 } 491 leaf threshold-operator { 492 description "it defines the operator to check the threshold 493 exceed: <, > <=, >="; 494 type string; 495 } 497 } 499 grouping transition-top { 500 description "it defines the grouping transition"; 501 leaf name { 502 description "it defines the transition name"; 503 type string; 504 mandatory true; 505 } 507 leaf description { 508 description "it describes the transition with a string"; 509 type string; 510 } 512 // list of all possible events 513 uses on-change { 514 when "type = 'ON_CHANGE'"; 515 } 516 container transition-action { 517 description "it defines the container actions to take during the 518 transition"; 519 uses action-top; 520 } 521 } 523 grouping transitions-top { 524 description "it defines the grouping transition"; 525 container transitions { 526 description "it defines the container transitions"; 527 list transition { 528 description "it defines the list of transitions"; 529 key "name"; 530 uses transition-top; 532 } 533 } 534 } 536 // data definition statements 538 uses transitions-top; 540 // extension statements 542 // feature statements 544 // augment statements 546 // rpc statements 548 // notification statements 550 // identity statements 552 // typedef statements 554 typedef state-id-type { 555 description "it defines the id type of the states"; 556 type uint32; 557 } 559 // grouping statements 560 grouping state-top { 561 description "it defines the grouping state"; 563 leaf id { 564 description "it defines the id of the state"; 565 type state-id-type; 566 } 568 leaf description { 569 description "it describes the state with a string"; 570 type string; 571 } 573 grouping next-state-top { 574 description "it defines the grouping next state"; 575 leaf next-state { 576 type leafref { 577 path "../../../../../../../../../states/state/id"; 578 } 579 description "Id of the next state"; 580 } 581 } 583 uses transitions-top { 584 augment "transitions/transition/transition-action/action/simple" { 585 //uses next-state-top; 586 leaf next-state { 587 type leafref { 588 path "../../../../../../../../states/state/id"; 589 } 590 description "Id of the next state"; 591 } 592 } 593 } 595 } 597 grouping states-top { 598 description "it defines the attributes of state-top"; 599 leaf current-state { 600 description "it defines the current state"; 601 type leafref { 602 description "it refers to its id"; 603 path "../states/state/id"; 604 } 605 } 607 container states { 608 description "it defines the container states"; 609 list state { 610 description "it defines the list of states"; 611 key "id"; 612 uses state-top; 613 } 614 } 615 } 617 // data definition statements 619 uses states-top; 621 // extension statements 623 // feature statements 625 // augment statements. 627 // rpc statements 629 // notification statements 631 }//module fsm 633 635 7. Acknowledgements 637 This work has been partially supported by the European Commission 638 through the H2020 ORCHESTRA (Optical peRformanCe monitoring enabling 639 dynamic networks using a Holistic cross-layEr, Self-configurable 640 Truly flexible approach, grant agreement no: H2020-645360) project. 641 The views expressed here are those of the authors only. The European 642 Commission is not liable for any use that may be made of the 643 information in this document. 645 8. Security Considerations 647 TBD 649 9. IANA Considerations 651 TBD 653 10. References 655 10.1. Normative References 657 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 658 Requirement Levels", BCP 14, RFC 2119, 659 DOI 10.17487/RFC2119, March 1997, 660 . 662 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 663 the Network Configuration Protocol (NETCONF)", RFC 6020, 664 DOI 10.17487/RFC6020, October 2010, 665 . 667 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 668 and A. Bierman, Ed., "Network Configuration Protocol 669 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 670 . 672 [RFC7491] King, D. and A. Farrel, "A PCE-Based Architecture for 673 Application-Based Network Operations", RFC 7491, 674 DOI 10.17487/RFC7491, March 2015, 675 . 677 10.2. Informative References 679 [I-D.ietf-i2rs-yang-network-topo] 680 Clemm, A., Medved, J., Varga, R., Bahadur, N., 681 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 682 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 683 progress), December 2017. 685 [I-D.sambo-netmod-yang-fsm] 686 Sambo, N., Castoldi, P., Fioccola, G., Cugini, F., Song, 687 H., and T. Zhou, "YANG model for finite state machine", 688 draft-sambo-netmod-yang-fsm-02 (work in progress), March 689 2018. 691 [I-D.vergara-ccamp-flexigrid-yang] 692 Madrid, U., Perdices, D., Lopezalvarez, V., Dios, O., 693 King, D., Lee, Y., and G. Galimberti, "YANG data model for 694 Flexi-Grid Optical Networks", draft-vergara-ccamp- 695 flexigrid-yang-06 (work in progress), January 2018. 697 [I-D.zhang-ccamp-l1-topo-yang] 698 zhenghaomian@huawei.com, z., Fan, Z., Sharma, A., and X. 699 Liu, "A YANG Data Model for Optical Transport Network 700 Topology", draft-zhang-ccamp-l1-topo-yang-07 (work in 701 progress), April 2017. 703 Authors' Addresses 705 Nicola Sambo 706 Scuola Superiore Sant'Anna 707 Via Moruzzi 1 708 Pisa 56124 709 Italy 711 Email: nicola.sambo@sssup.it 713 Piero Castoldi 714 Scuola Superiore Sant'Anna 715 Via Moruzzi 1 716 Pisa 56124 717 Italy 719 Email: piero.castoldi@sssup.it 721 Andrea Sgambelluri 722 Scuola Superiore Sant'Anna 723 Via Moruzzi 1 724 Pisa 56124 725 Italy 727 Email: andrea.sgambelluri@sssup.it 729 Giuseppe Fioccola 730 Telecom Italia 731 Via Reiss Romoli, 274 732 Torino 10148 733 Italy 735 Email: giuseppe.fioccola@telecomitalia.it 736 Filippo Cugini 737 CNIT 738 Via Moruzzi 1 739 Pisa 56124 740 Italy 742 Email: filippo.cugini@cnit.it 744 Daniele Ceccarelli 745 Ericsson 746 Torshamnsgatan,48 747 Stockholm 164 40 748 Sweden 750 Email: daniele.ceccarelli@ericsson.com 752 Haoyu Song 753 Huawei 754 2330 Central Expressway 755 Santa Clara, CA 95050 756 USA 758 Email: haoyu.song@huawei.com 760 Tianran Zhou 761 Huawei 762 156 Beiqing Road 763 Beijing 100095 764 China 766 Email: zhoutianran@huawei.com