idnits 2.17.1 draft-ietf-teas-actn-info-model-04.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 document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2017) is 2381 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'ACTN-Req' on line 846 looks like a reference -- Missing reference section? 'ACTN-Frame' on line 850 looks like a reference -- Missing reference section? 'RFC7926' on line 863 looks like a reference -- Missing reference section? 'ACTN-REQ' on line 309 looks like a reference -- Missing reference section? 'TE-TOPO' on line 856 looks like a reference -- Missing reference section? 'Path-Compute' on line 867 looks like a reference -- Missing reference section? 'RFC5441' on line 447 looks like a reference -- Missing reference section? 'RFC3630' on line 767 looks like a reference -- Missing reference section? 'RFC7471' on line 767 looks like a reference -- Missing reference section? 'RFC4427' on line 512 looks like a reference -- Missing reference section? 'RFC5541' on line 859 looks like a reference -- Missing reference section? 'RFC 3209' on line 759 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Teas Working Group Young Lee 2 Internet Draft Huawei 4 Intended status: Informational Sergio Belotti 5 Nokia 6 Expires: April 16, 2018 7 Dhruv Dhody 8 Huawei 10 Daniele Ceccarelli 11 Ericsson 13 Bin Yeong Yoon 14 ETRI 16 October 16, 2017 18 Information Model for Abstraction and Control of TE Networks (ACTN) 20 draft-ietf-teas-actn-info-model-04.txt 22 Abstract 24 This draft provides an information model for Abstraction and Control 25 of Traffic Engineered (TE) networks (ACTN). 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with 30 the provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six 38 months and may be updated, replaced, or obsoleted by other documents 39 at any time. It is inappropriate to use Internet-Drafts as 40 reference material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on April 16, 2018. 49 Copyright Notice 51 Copyright (c) 2017 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction ..................................................3 67 1.1. Terminology...............................................4 68 2. ACTN Common Interfaces Information Model ......................4 69 3. Virtual Network primitives ....................................6 70 3.1. VN Instantiate............................................6 71 3.2. VN Modify.................................................7 72 3.3. VN Delete.................................................7 73 3.4. VN Update.................................................7 74 3.5. VN Compute................................................8 75 4. Traffic Engineering (TE) primitives ...........................8 76 4.1. TE Instantiate............................................9 77 4.2. TE Modify.................................................9 78 4.3. TE Delete.................................................9 79 4.4. TE Topology Update (for TE resources).....................9 80 4.5. Path Compute.............................................10 81 5. VN Objects ...................................................11 82 5.1. VN Identifier............................................11 83 5.2. VN Service Characteristics...............................11 84 5.3. VN End-Point.............................................14 85 5.4. VN Objective Function....................................14 86 5.5. VN Action Status.........................................15 87 5.6. VN Topology..............................................15 88 5.7. VN Member................................................15 89 5.7.1. VN Computed Path....................................16 90 5.7.2. VN Service Preference...............................16 91 6. TE Objects ...................................................17 92 6.1. TE Tunnel Characteristic.................................17 93 7. Mapping of VN Primitives with VN Objects .....................19 94 8. Mapping of TE Primitives with TE Objects .....................20 95 9. References ...................................................21 96 9.1. Normative References.....................................21 97 9.2. Informative References...................................21 98 10.Contributors .................................................22 99 Contributors' Addresses..........................................22 100 Authors' Addresses...............................................22 102 1. Introduction 104 This draft provides an information model for the requirements 105 identified in the ACTN requirements [ACTN-Req] and the ACTN 106 interfaces identified in the ACTN architecture and framework 107 document [ACTN-Frame]. 109 The purpose of this draft is to put all information elements of ACTN 110 in one place before proceeding to development work necessary for 111 protocol extensions and data models. 113 The ACTN reference architecture [ACTN-Frame] identified a three-tier 114 control hierarchy as depicted in Figure 1: 116 - Customer Network Controllers (CNC) 117 - Multi-Domain Service Coordinator (MDSC) 118 - Provisioning Network Controllers (PNC). 120 +-------+ +-------+ +-------+ 121 | CNC-A | | CNC-B | | CNC-C | 122 +-------+ +-------+ +-------+ 123 \ | / 124 ---------- | CMI ------------ 125 \ | / 126 +-----------------------+ 127 | MDSC | 128 +-----------------------+ 129 / | \ 130 -------- | MPI ------------ 131 / | \ 132 +-------+ +-------+ +-------+ 133 | PNC | | PNC | | PNC | 134 +-------+ +-------+ +-------+ 136 Figure 1: A Three-tier ACTN control hierarchy 138 The two interfaces with respect to the MDSC, one north of the MDSC 139 and the other south of the MDSC are referred to as CMI (CNC-MDSC 140 Interface) and MPI (MDSC-PNC Interface), respectively. It is 141 intended to model these two interfaces and derivative interfaces 142 thereof (e.g., MDSC to MSDC in a hierarchy of MDSCs) with one common 143 model. 145 1.1. Terminology 147 Refer VN, VNS to [ACTN-Frame] and abstraction and abstract topology 148 to [RFC7926]. 150 2. ACTN Common Interfaces Information Model 152 This section provides ACTN common interface information model to 153 describe in terms of primitives, objects, their properties 154 (represented as attributes), their relationships, and the resources 155 for the service applications needed in the ACTN context. 157 The standard interface is described between a client controller and 158 a server controller. A client-server relationship is recursive 159 between a CNC and a MDSC and between a MDSC and a PNC. In the CMI, 160 the client is a CNC while the server is a MDSC. In the MPI, the 161 client is a MDSC and the server is a PNC. There may also be MDSC- 162 MDSC interface(s) that need to be supported. This may arise in a 163 hierarchy of MDSCs in which workloads may need to be partitioned to 164 multiple MDSCs. 166 Basic primitives (messages) are required between the CNC-MDSC and 167 MDSC-PNC controllers. These primitives can then be used to support 168 different ACTN network control functions like network topology 169 request/query, VN service request, path computation and connection 170 control, VN service policy negotiation, enforcement, routing 171 options, etc. 173 There are two different types of primitives depending of the type of 174 interface: 176 - Virtual Network primitives at CMI 177 - Traffic Engineering primitives at MPI 179 As well described in [ACTN-Frame], at the CMI level, there is no 180 need for detailed TE information since the basic functionality is to 181 translate customer service information into virtual network service 182 operation. 184 At the MPI level, MDSC has the main scope for multi-domain 185 coordination and creation of a single e2e abstracted network view 186 which is strictly related to TE information. 188 As for topology, this document employs two types of topology: 190 - The first type is referred to as virtual network topology which 191 is associated a VN. Virtual network topology is a customized 192 topology for view and control by the customer. See Section 3.1 193 for details. 195 - The second type is referred to as TE topology which is associated 196 with provider network operation on which we can apply policy to 197 obtain the required level of abstraction to represent the 198 underlying physical network topology. 200 3. Virtual Network primitives 202 This section provides a list of main VN primitives related to 203 virtual network which are necessary to satisfy ACTN requirements 204 specified in [ACTN-REQ] 206 At a minimum, the following VN action primitives should be 207 supported: 209 - VN Instantiate (See Section 3.1.1. for the description) 211 - VN Modify (See Section 3.1.2. for the description) 213 - VN Delete (See Section 3.1.3. for the description) 215 - VN Update ((See Section 3.1.4. for the description) 217 - VN Path Compute (See Section 3.1.5. for the description) 219 - VN Query (See Section 3.1.6. for the description) 221 is an object describing the main VN primitives. 223 VN Action can assume one of the mentioned above primitives values. 225 ::= | 227 | 229 | 231 | 233 | 235 237 All these actions will solely happen at CMI level between Customer 238 Network Controller (CNC) and Multi Domain Service Coordinator 239 (MDSC). 241 3.1. VN Instantiate 243 refers to an action from customers/applications to 244 request the creation of VNs. Depending on the agreement between 245 client and provider can imply different VN 246 operations and view, depending on the type of VN requested. You can 247 have two types of VN instantiation: 249 VN type 1: Where VN is viewed as a set of edge-to-edge links, 250 referred as VN members in ACTN terminology. 252 VN type 2: Where VN is viewed as a VN-topology which is comprised of 253 virtual nodes and virtual links. See Section 5.6 for details. 255 Please see [ACTN-Frame] for details regarding the types of VN. 257 3.2. VN Modify 259 refers to an action issued from customers/applications 260 to modify an existing VN (i.e., an instantiated VN). 262 3.3. VN Delete 264 refers to an action issued from customers/applications 265 to delete an existing VN. 267 3.4. VN Update 269 refers to any update to the VN that needs to be updated 270 to the customers. VN Update fulfills a push model at CMI level, to 271 make aware customers of any specific changes in the topology details 272 related to VN instantiated. 274 VN Update, depending of the type of VN instantiated, can be an 275 update of VN members (edge-to-edge links) in case of VN type 1, or a 276 virtual topology view update in case of VN type 2. 278 The connection-related information (e.g., LSPs) update association 279 with VNs will be part of the "translation" function that happens in 280 MDSC to map/translate VN request into TE semantics. This information 281 will be provided in case customer optionally wants to have more 282 detailed TE information associated with the instantiated VN. 284 3.5. VN Compute 286 consists of Request and Reply. Request refers to an 287 action from customers/applications to request a VN computation. 289 Reply refers to the reply in response to 290 Request. 292 Request/Reply is to be differentiated from a VN 293 Instantiate. The purpose of VN Compute is a priori exploration to 294 compute network resources availability and getting a possible VN 295 view in which path details can be specified matching 296 customer/applications constraints. This a priori exploration may not 297 guarantee the availability of the computed network resources at the 298 time of instantiation. 300 refers to inquiry pertaining to the VN that has been 301 already instantiated. VN Query fulfills a pull model and permit to 302 get topology view. 304 refers to the reply in response to . 306 4. Traffic Engineering (TE) primitives 308 This section provides a list of main TE primitives necessary to 309 satisfy ACTN requirements specified in [ACTN-REQ] related to typical 310 TE operations supported at MPI level. 312 At a minimum, the following TE action primitives should be 313 supported: 315 - TE Instantiate/Modify/Delete 317 - TE Topology Update (See Section 4.4. for the description) 319 - Path Compute 321 is an object describing the main TE primitives. 323 TE Action can assume one of the mentioned above primitives values. 325 ::= | 327 | 329 | 330 | 332 | 334 All these actions will solely happen at MPI level between Multi 335 Domain Service Coordinator (MDSC) and Provisioning Network Controller 336 (PNC). 338 4.1. TE Instantiate 340 refers to an action issued from MDSC to PNC to 341 instantiate new TE tunnels. 343 4.2. TE Modify 345 refers to an action issued from MDSC to PNC to modify 346 existing TE tunnels. 348 4.3. TE Delete 350 refers to an action issued from MDSC to PNC to delete 351 existing TE tunnels. 353 4.4. TE Topology Update (for TE resources) 355 is a primitive specifically related to MPI to 356 provide TE resource update between any domain controller towards 357 MDSC regarding the entire content of any "domain controller" actual 358 TE topology or an abstracted filtered view of TE topology depending 359 on negotiated policy. 361 See [TE-TOPO] for detailed YANG implementation of TE topology 362 update. 364 ::= 366 ::= [] 367 ::= [] 370 ::= [] 372 ::= 374 ::= 375 [] 377 ::= [] 379 Where 381 provides information on level of abstraction (as 382 determined a priori). 384 is an identifier that identifies a specific 385 te-topology, e.g., te-types:te-topology-id [TE-TOPO]. 387 is detailed information related to a specific node 388 belonging to a te-topology, e.g., te-node-attributes [TE-TOPO]. 390 is information related to the specific link related 391 belonging to a te-topology, e.g., te-link-attributes [TE-TOPO]. 393 is detailed information 394 associated with the termination points of te-link related to a 395 specific node, e.g., interface-switching-capability [TE-TOPO]. 397 4.5. Path Compute 399 consists of Request and Reply. Request refers to an 400 action from MDSC to PNC to request a path computation. 402 Reply refers to the reply in response to Request. 405 The context of is described in [Path-Compute]. 407 5. VN Objects 409 This section provides a list of objects associated to VN action 410 primitives. 412 5.1. VN Identifier 414 is a unique identifier of the VN. 416 5.2. VN Service Characteristics 418 VN Service Characteristics describes the customer/application 419 requirements against the VNs to be instantiated. 421 ::= 423 (...) 425 427 Where 429 ::= |||| 432 The Connectivity Type identifies the type of required VN Service. In 433 addition to the classical type of services (e.g. P2P/P2MP etc.), 434 ACTN defines the "multi-destination" service that is a new P2P 435 service where the end points are not fixed. They can be chosen among 436 a list of pre-configured end points or dynamically provided by the 437 CNC. 439 ::= 441 [] 443 The VN Traffic Matrix represents the traffic matrix parameters for 444 the required the service connectivity. Bandwidth is a mandatory 445 parameter and a number of optional constrains can be specified in 446 the (e.g. diversity, cost). They can include 447 objective functions and TE metrics bounds as specified in [RFC5441]. 449 Further details on the VN constraints are specified below: 451 ::= [] 453 [] 455 [] 457 ( | ) 459 Where: 461 identifies the layer topology at which the VN 462 service is requested. It could be for example MPLS, ODU, and OCh. 464 allows asking for diversity constraints for a VN 465 Instantiate/Modify or a VN Path Compute. For example, a new VN or 466 a path is requested in total diversity from an existing one (e.g. 467 diversity exclusion). 469 ::= ( (...)) | 471 ( (...)) 473 is used to get the SRLG associated with the 474 different tunnels composing a VN. Based on the realization of VN 475 required, group of physical resources can be impacted by the same 476 risk. VN member (i.e., edge-to-edge link) can be impacted by this 477 shared risk. 479 can include all the Metrics (cost, delay, delay 480 variation, latency), bandwidth utilization parameters defined and 481 referenced by [RFC3630] and [RFC7471]. 483 See Section 5.4. 485 describes all attributes related to the VN 486 recovery level and its survivability policy enforced by the 487 customers/applications. 489 ::= 491 [] 493 [] 495 Where: 497 is a value representing the requested 498 level of resiliency required against the VN. The following 499 values are defined: 501 . Unprotected VN 502 . VN with per tunnel recovery: The recovery level is defined 503 against the tunnels composing the VN and it is specified in 504 the . 506 ::= <0:1>|<1+1>|<1:1>|<1:N>|| 508 510 The VN Tunnel Recovery Level indicates the type of protection 511 or restoration mechanism applied to the VN. It augments the 512 recovery types defined in [RFC4427]. 514 ::= [] 516 [] 518 [] 520 [] 522 Where: 524 is a delegation policy to the Server 525 to allow or not a local reroute fix upon a failure of the 526 primary LSP. 528 is only applied on the MPI where the MDSC 529 (client) provides a domain preference to each PNC (server), 530 e.g., when an inter-domain link fails, then PNC can choose 531 the alternative peering with this info. 533 is a policy that allows a server to trigger an 534 updated VN topology upon failure without an explicit request 535 from the client. Push action can be set as default unless 536 otherwise specified. 538 is another policy that triggers an 539 incremental update from the server since the last period of 540 update. Incremental update can be set as default unless 541 otherwise specified. 543 5.3. VN End-Point 545 Object describes the VN's customer end-point 546 characteristics. 548 ::= ( 550 [] 552 [])... 554 Where: 556 represents a unique identifier of the 557 client end-point. They are used by the customer to ask for the 558 setup of a virtual network creation. A is defined 559 against each AP in the network and is shared between customer and 560 provider. Both the customer and the provider will map it against 561 his own physical resources. 563 identifies the capabilities of the access 564 link related to the given access point. (e.g., max-bandwidth, 565 bandwidth availability, etc.) 567 indicates if an end-point is source or not. 569 5.4. VN Objective Function 571 The VN Objective Function applies to each VN member (i.e., each E2E 572 tunnel) of a VN. 574 The VN Objective Function can reuse objective functions defined in 575 [RFC5541] section 4. 577 For a single path computation, the following objective functions are 578 defined: 580 o MCP is the Minimum Cost Path with respect to a specific 581 metric (e.g. shortest path). 582 o MLP is the Minimum Load Path, that means find a path 583 composted by te-link least loaded. 584 o MBP is the Maximum residual Bandwidth Path. 586 For a concurrent path computation, the following objective functions 587 are defined: 589 o MBC is to Minimize aggregate Bandwidth Consumption. 590 o MLL is to Minimize the Load of the most loaded Link. 591 o MCC is to Minimize the Cumulative Cost of a set of paths. 593 5.5. VN Action Status 595 is the status indicator whether the VN has been 596 successfully instantiated, modified, or deleted in the server 597 network or not in response to a particular VN action. 599 Note that this action status object can be implicitly indicated and 600 thus not included in any of the VN primitives discussed in Section 601 2.3. 603 5.6. VN Topology 605 When a VN is seen by the customer as a topology, it is referred to 606 as VN topology. This is associated with VN Type 2, which is 607 comprised of virtual nodes virtual and links. 609 ::= 611 ::= [] 613 :: = [] 615 5.7. VN Member 617 describes details of a VN Member which is a list of a set 618 of VN Members represented as . 620 ::= [] 622 Where ::= 624 [] 626 628 is the VN End-Point information for the 629 ingress portion of the AP. See Section 5.3 for 630 details. 632 is the VN End-Point information for the egress 633 portion of the AP. See Section 5.3 for details. 635 describes the instantiated LSPs in the 636 Provider's network for the VN Type 1. It describes the instantiated 637 LSPs over the VN topology for VN Type 2. 639 5.7.1. VN Computed Path 641 The VN Computed Path is the list of paths obtained after the VN path 642 computation request from higher controller. Note that the computed 643 path is to be distinguished from the LSP. When the computed path is 644 signaled in the network (and thus the resource is reserved for that 645 path), it becomes an LSP. 647 ::= (...) 649 5.7.2. VN Service Preference 651 This section provides VN Service preference. VN Service is defined 652 in Section 2. 654 ::= [] 656 [] 658 [] 660 Where 662 describes any preference related to 668 Virtual Network Service (VNS) that application/client can enforce 669 via CNC towards lower level controllers. For example, permission 670 the correct selection from the network of the destination related 671 to the indicated VNF It is e.g. the case of VM migration among 672 data center and CNC can enforce specific policy that can permit 673 MDSC/PNC to calculate the correct path for the connectivity 674 supporting the data center interconnection required by 675 application. 677 describes if the End- 678 Point (e.g. Data Center) can support load balancing, disaster 679 recovery or VM migration and so can be part of the selection by 680 MDSC following service Preference enforcement by CNC. 682 6. TE Objects 684 6.1. TE Tunnel Characteristic 686 Tunnel Characteristics describes the parameters needed to configure 687 TE tunnel. 689 ::= [] 691 693 [] 695 [] 697 [] 699 701 [] 703 Where 705 ::= ||| 707 The Tunnel Type identifies the type of required tunnel. In this 708 draft, only P2P model is provided. 710 is the TE tunnel identifier 712 it represents the layer technology of the LSPs 713 supporting the tunnel 714 ::= 716 ::= ||||prot | 719 are the base tunnel configuration constraints 720 parameters. 722 Where ::= [] 724 [] 726 [] 728 [] 730 [] 732 [] 734 [] 736 [] 738 references the topology used to compute the tunnel 739 path. 741 is the bandwidth used as parameter in path computation 743 ::= | | 745 provides the type of resources from which the tunnel 746 has to be disjointed 748 is a group of physical resources impacted by the same risk 749 from which an E2E tunnel is required to be disjointed. 751 ::= 753 where 755 indicates the level of priority to taking resources 756 from another tunnel [RFC 3209] 758 indicates the level of priority to hold resources 759 avoiding preemption from another tunnel [RFC 3209] 760 it represent structure to validate link belonging to 761 path of the tunnel (RFC 3209) 763 ::= | 765 can include all the Metrics (cost, delay, delay variation, 766 latency), bandwidth utilization parameters defined and referenced by 767 [RFC3630] and [RFC7471]. 769 ::= 771 ::= | | | | 772 | 774 See chapter 5.4 for objective function type description. 776 7. Mapping of VN Primitives with VN Objects 778 This section describes the mapping of VN Primitives with VN Objects 779 based on Section 5. 781 ::= 783 785 [] 787 [] 789 ::= 791 793 795 [] 797 [] 799 ::= 800 :: = 802 [] 804 [] 806 ::= 808 810 [] 812 ::= 814 ::= 816 ::= 818 820 [] 822 8. Mapping of TE Primitives with TE Objects 824 This section describes the mapping of TE Primitives with TE Objects 825 based on Section 6. 827 ::= 829 ::= 830 ::= 832 :: = 834 836 ::= 838 ::= 840 842 9. References 844 9.1. Normative References 846 [ACTN-Req] Y. Lee, et al., "Requirements for Abstraction and Control 847 of Transport Networks", draft-ietf-teas-actn-requirements, 848 work in progress. 850 [ACTN-Frame] D. Ceccarelli, et al., "Framework for Abstraction and 851 Control of Transport Networks", draft-ietf-teas-actn- 852 framework, work in progress. 854 9.2. Informative References 856 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 857 draft-ietf-teas-yang-te-topo, work in progress. 859 [RFC5541] JL. Le Roux, JP. Vasseur and Y. Lee, "Encoding of 860 Objective Functions in the Path Computation Element 861 Communication Protocol (PCEP)", RFC 5541, June 2009. 863 [RFC7926] A. Farrel, et al., "Problem Statement and Architecture for 864 Information Exchange between Interconnected Traffic- 865 Engineered Networks", RFC 7926, July 2016. 867 [Path-Compute] I. Busi, S. Belotti, et al., "Yang model for 868 requesting Path Computation", draft-busibel-teas-yang- 869 path-computation", work in progress. 871 10. Contributors 873 Contributors' Addresses 875 Authors' Addresses 877 Young Lee (Editor) 878 Huawei Technologies 879 5340 Legacy Drive 880 Plano, TX 75023, USA 881 Phone: (469)277-5838 882 Email: leeyoung@huawei.com 884 Sergio Belotti (Editor) 885 Alcatel Lucent 886 Via Trento, 30 887 Vimercate, Italy 888 Email: sergio.belotti@alcatel-lucent.com 890 Dhruv Dhody 891 Huawei Technologies, 892 Divyashree Technopark, Whitefield 893 Bangalore, India 894 Email: dhruv.ietf@gmail.com 896 Daniele Ceccarelli 897 Ericsson 898 Torshamnsgatan,48 899 Stockholm, Sweden 900 Email: daniele.ceccarelli@ericsson.com 902 Bin Yeong Yoon 903 ETRI 904 Email: byyun@etri.re.kr 906 Haomian Zheng 907 Huawei Technologies 908 Email: zhenghaomian@huawei.com 910 Xian Zhang 911 Huawei Technologies 912 Email: zhang.xian@huawei.com