idnits 2.17.1 draft-ietf-teas-actn-vn-yang-05.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 746 has weird spacing: '... "delay path ...' == Line 1184 has weird spacing: '... rpc vn-co...' -- The document date (June 13, 2019) is 1769 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) == Missing Reference: 'TE-Topo' is mentioned on line 128, but not defined == Missing Reference: 'RFCXXXX' is mentioned on line 177, but not defined == Missing Reference: 'TE-Tunnel' is mentioned on line 179, but not defined == Missing Reference: 'ACTN-INFO' is mentioned on line 481, but not defined == Missing Reference: 'RFC6241' is mentioned on line 2334, but not defined == Missing Reference: 'RFC8040' is mentioned on line 2334, but not defined == Missing Reference: 'RFC6242' is mentioned on line 2337, but not defined == Missing Reference: 'RFC8446' is mentioned on line 2338, but not defined == Missing Reference: 'RFC8341' is mentioned on line 2340, but not defined == Missing Reference: 'RFC3688' is mentioned on line 2387, but not defined == Missing Reference: 'RFC6020' is mentioned on line 2398, but not defined Summary: 1 error (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Y. Lee (Editor) 2 Internet Draft Futurewei 3 Intended Status: Standard Track 4 Expires: December 13, 2019 D. Dhody (Editor) 5 Huawei 7 D. Ceccarelli 8 Ericsson 10 I. Bryskin 11 Futurewei 13 B. Yoon 14 ETRI 16 June 13, 2019 18 A Yang Data Model for VN Operation 20 draft-ietf-teas-actn-vn-yang-05 22 Abstract 24 This document provides a YANG data model generally applicable to any 25 mode of Virtual Network (VN) operation. 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 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 This Internet-Draft will expire on December 13, 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 (http://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 60 respect to this document. Code Components extracted from this 61 document must include Simplified BSD License text as described in 62 Section 4.e of the Trust Legal Provisions and are provided without 63 warranty as described in the Simplified BSD License. 65 Table of Contents 67 Introduction.....................................................3 68 1.................................................................3 69 1.1. Terminology...............................................4 70 1.2. Tree diagram..............................................4 71 1.3. Prefixes in Data Node Names...............................4 72 2. Use-case of VN Yang Model in the ACTN context..................5 73 2.1. Type 1 VN.................................................5 74 2.2. Type 2 VN.................................................6 75 3. High-Level Control Flows with Examples.........................7 76 3.1. Type 1 VN Illustration....................................7 77 3.2. Type 2 VN Illustration....................................9 78 4. VN Model Usage................................................12 79 4.1. Customer view of VN......................................12 80 4.2. Auto-creation of VN by MDSC..............................12 81 4.3. Innovative Services......................................12 82 4.3.1. VN Compute..........................................12 83 4.3.2. Multi-sources and Multi-destinations................12 84 4.3.3. Others..............................................13 85 4.3.4. Summary.............................................14 86 5. VN YANG Model (Tree Structure)................................14 87 6. VN YANG Code..................................................16 88 7. JSON Example..................................................29 89 7.1. VN JSON..................................................30 90 7.2. TE-topology JSON.........................................35 91 8. Security Considerations.......................................51 92 9. IANA Considerations...........................................52 93 10. Acknowledgments..............................................53 94 11. References...................................................54 95 11.1. Normative References....................................54 96 11.2. Informative References..................................54 97 12. Contributors.................................................55 98 Authors' Addresses...............................................55 100 1. Introduction 102 This document provides a YANG data model generally applicable to any 103 mode of Virtual Network (VN) operation. 105 The VN model defined in this document is applicable in generic sense 106 as an independent model in and of itself. The VN model defined in 107 this document can also work together with other customer service 108 models such as L3SM [RFC8299], L2SM [L2SM] and L1CSM [L1CSM] to 109 provide a complete life-cycle service management and operations. 111 The YANG model discussed in this document basically provides the 112 following: 114 o Characteristics of Access Points (APs) that describe customer's 115 end point characteristics; 117 o Characteristics of Virtual Network Access Points (VNAP) that 118 describe How an AP is partitioned for multiple VNs sharing the AP 119 and its reference to a Link Termination Point (LTP) of the 120 Provider Edge (PE) Node; 122 o Characteristics of Virtual Networks (VNs) that describe the 123 customer's VNs in terms of VN Members comprising a VN, multi- 124 source and/or multi-destination characteristics of VN Member, the 125 VN's reference to TE-topology's Abstract Node; 127 The actual VN instantiation and computation is performed with 128 Connectivity Matrices sub-module of TE-Topology Model [TE-Topo] 129 which provides TE network topology abstraction and management 130 operation. Once TE-topology Model is used in triggering VN 131 instantiation over the networks, TE-tunnel [TE-tunnel] Model will 132 inevitably interact with TE-Topology model for setting up actual 133 tunnels and LSPs under the tunnels. 135 Abstraction and Control of Traffic Engineered Networks (ACTN) 136 describes a set of management and control functions used to operate 137 one or more TE networks to construct virtual networks that can be 138 represented to customers and that are built from abstractions of the 139 underlying TE networks [RFC8453]. ACTN is the primary example of the 140 usage of the VN Yang model. 142 Sections 2 and 3 provide the discussion of how the VN Yang model is 143 applicable to the ACTN context where Virtual Network Service (VNS) 144 operation is implemented for the Customer Network Controller (CNC)- 145 Multi-Domain Service Coordinator (MSDC) interface (CMI). 147 The YANG model on the CMI is also known as customer service model in 148 [RFC8309]. The YANG model discussed in this document is used to 149 operate customer-driven VNs during the VN instantiation, VN 150 computation, and its life-cycle service management and operations. 152 The VN operational state is included in the same tree as the 153 configuration consistent with Network Management Datastore 154 Architecture (NMDA) [RFC8342]. The origin of the data is indicated 155 as per the origin metadata annotation. 157 1.1. Terminology 159 Refer to [RFC8453], [RFC7926], and [RFC8309] for the key terms used 160 in this document. 162 1.2. Tree diagram 164 A simplified graphical representation of the data model is used in 165 Section 5 of this this document. The meaning of the symbols in 166 these diagrams is defined in [RFC8340]. 168 1.3. Prefixes in Data Node Names 170 In this document, names of data nodes and other data model objects 171 are prefixed using the standard prefix associated with the 172 corresponding YANG imported modules, as shown in Table 1. 174 +---------+------------------------------+-----------------+ 175 | Prefix | YANG module | Reference | 176 +---------+------------------------------+-----------------+ 177 | vn | ietf-vn | [RFCXXXX] | 178 | nw | ietf-network | [RFC8345] | 179 | te-types| ietf-te-types | [TE-Tunnel] | 180 | te-topo | ietf-te-topology | [TE-TOPO] | 181 +---------+------------------------------+-----------------+ 183 Table 1: Prefixes and corresponding YANG modules 185 Note: The RFC Editor will replace XXXX with the number assigned to 186 the RFC once this draft becomes an RFC. 188 2. Use-case of VN Yang Model in the ACTN context 190 In this section, ACTN is being used to illustrate the general usage 191 of the VN yang model. The model presented in this section has the 192 following ACTN context. 194 +-------+ 195 | CNC | 196 +-------+ 197 | 198 | VN YANG + TE-topology YANG 199 | 200 +-----------------------+ 201 | MDSC | 202 +-----------------------+ 204 Figure 1. ACTN CMI 206 Both ACTN VN YANG and TE-topology models are used over the CMI to 207 establish a VN over TE networks. 209 In the context of 5G transport application, 5G Traffic Provisioning 210 Manager (TPM) that provides slicing requirements to the transport 211 networks (i.e., MDSC) can be considered as a type of CNC. The ACTN 212 CMI provides the necessary interface functions between 5G and 213 transport networks in order to facilitate dynamic VN creation and 214 its lifecycle management with proper feedback loop for monitoring. 216 2.1. Type 1 VN 218 As defined in [RFC8453], a Virtual Network is a customer view of the 219 TE network. To recapitulate VN types from [RFC8453], Type 1 VN is 220 defined as follows: 222 The VN can be seen as a set of edge-to-edge abstract links (a Type 1 223 VN). Each abstract link is referred to as a VN member and is formed 224 as an end-to-end tunnel across the underlying networks. Such tunnels 225 may be constructed by recursive slicing or abstraction of paths in 226 the underlying networks and can encompass edge points of the 227 customer's network, access links, intra-domain paths, and inter- 228 domain links. 230 If we were to create a VN where we have four VN-members as follows: 232 VN-Member 1 L1-L4 233 VN-Member 2 L1-L7 234 VN-Member 3 L2-L4 235 VN-Member 4 L3-L8 237 Where L1, L2, L3, L4, L7 and L8 correspond to a Customer 238 End-Point, respectively. 240 This VN can be modeled as one abstract node representation as 241 follows in Figure 2: 243 +---------------+ 244 L1 ------| |------ L4 245 L2 ------| AN 1 |------ L7 246 L3 ------| |------ L8 247 +---------------+ 249 Figure 2. Abstract Node (One node topology) 251 Modeling a VN as one abstract node is the easiest way for customers 252 to express their end-to-end connectivity; however, customers are not 253 limited to express their VN only with one abstract node. In some 254 cases, more than one abstract nodes can be employed to express their 255 VN. 257 2.2. Type 2 VN 259 For some VN members of a VN, the customers are allowed to configure 260 the actual path (i.e., detailed virtual nodes and virtual links) 261 over the VN/abstract topology agreed mutually between CNC and MDSC 262 prior to or a topology created by the MDSC as part of VN 263 instantiation. Type 2 VN is always built on top of a Type 1 VN. 265 If a Type 2 VN is desired for some or all of VN members of a type 1 266 VN (see the example in Section 2.1), the TE-topology model can 267 provide the following abstract topology (that consists of virtual 268 nodes and virtual links) which is built on top of the Type 1 VN. 270 +----------------------------------------------+ 271 | S1 S2 | 272 | O---------------O | 273 | ________/ \______ \ | 274 | / \ \ | 275 |S3 / \ S4 \ S5 | 276 L1----|-O----------------------O---------O-----------|------L4 277 | \ \ \ | 278 | \ \ \ | 279 | \ S6 \ S7 \ S8 | 280 | O ----------------O---------O-------|------L7 281 | / \ / \ ____/ | 282 |S9 / \ /S10 \ / | 283 L2-----|---O-----O---------------------O--------------|------L8 284 | / S11 | 285 L3-----|-- | 286 | | 287 +----------------------------------------------+ 289 Figure 3. Type 2 topology 291 As you see from Figure 3, the Type 1 abstract node is depicted as a 292 Type 1 abstract topology comprising of detailed virtual nodes and 293 virtual links. 295 As an example, if VN-member 1 (L1-L4) is chosen to configure its own 296 path over Type 2 topology, it can select, say, a path that consists 297 of the ERO {S3,S4,S5} based on the topology and its service 298 requirement. This capability is enacted via TE-topology 299 configuration by the customer. 301 3. High-Level Control Flows with Examples 303 3.1. Type 1 VN Illustration 305 If we were to create a VN where we have four VN-members as follows: 307 VN-Member 1 L1-L4 308 VN-Member 2 L1-L7 309 VN-Member 3 L2-L4 310 VN-Member 4 L3-L8 312 Where L1, L2, L3, L4, L7 and L8 correspond to Customer End-Point, 313 respectively. 315 This VN can be modeled as one abstract node representation as 316 follows: 318 +---------------+ 319 L1 ------| |------ L4 320 L2 ------| AN 1 |------ L7 321 L3 ------| |------ L8 322 +---------------+ 324 If this VN is Type 1, the following diagram shows the message flow 325 between CNC and MDSC to instantiate this VN using VN and TE-Topology 326 Models. 328 +--------+ +--------+ 329 | CNC | | MDSC | 330 +--------+ +--------+ 331 | | 332 | | 333 CNC POST TE-topo | POST /nw:networks/nw:network/ | 334 model(with Conn. | nw:node/te-node-id/ | 335 | tet:connectivity-matrices/ | 336 Matrix on one | tet:connectivity-matrix | 337 Abstract node |-------------------------------->| 338 | HTTP 200 | 339 |<--------------------------------| 340 | | 341 CNC POST the | POST /VN | 342 VN identifying |-------------------------------->| If there is 343 AP, VNAP and VN- | | multi-dest'n 344 Members and maps | | module, then 345 to the TE-topo | HTTP 200 | MDSC selects a 346 |<--------------------------------| src or dest'n 347 | | and update 348 | | VN YANG 349 CNC GET the | GET /VN | 350 VN YANG status |-------------------------------->| 351 | | 352 | HTTP 200 (VN with status: | 353 | selected VN-members | 354 | in case of multi s-d) | 355 |<--------------------------------| 356 | | 358 3.2. Type 2 VN Illustration 360 For some VN members, the customer may want to "configure" explicit 361 routes over the path that connects its two end-points. Let us 362 consider the following example. 364 VN-Member 1 L1-L4 (via S3, S4, and S5) 366 VN-Member 2 L1-L7 (via S3, S4, S7 and S8) 368 VN-Member 3 L2-L7 (via S9, S10, and S11) 370 VN-Member 4 L3-L8 (via S9, S10 and S11) 372 Where the following topology is the underlay for Abstraction Node 1 373 (AN1). 375 AN1 376 ............................................ 377 . S1 S2 . 378 . O---------------O . 379 . ________/ \______ \ . 380 . / \ \ . 381 . S3/ \ S4 \ S5 . 382 L1----.-O----------------------O---------O-------.----------L4 383 . \ \ \ . 384 . \ \ \ . 385 . \ S6 \ S7 \ S8 . 386 . O ----------------O---------O---.----------L5 387 . / \ / \ ____/ \__.__________L6 388 .S9 / \ /S10 \ / . 389 L2-----.---O-----O---------------------O----------.----------L7 390 . / S11\_________.__________L8 391 L3-----.-- . 392 ............................................ 394 There are two options depending on whether CNC or MDSC creates the 395 single abstract node topology. 397 Case 1: 399 If CNC creates the single abstract node topology, the following 400 diagram shows the message flow between CNC and MDSC to instantiate 401 this VN using VN and TE-Topology Model. 403 +--------+ +--------+ 404 | CNC | | MDSC | 405 +--------+ +--------+ 406 | | 407 | | 408 CNC POST TE-topo | POST /nw:networks/nw:network/ | 409 model(with Conn. | nw:node/te-node-id/tet:connectivity- | 410 Matrix on one | matrices/tet:connectivity-matrix | 411 Abstract node and|---------------------------------------->| 412 Explicit paths in| | 413 The conn. Matrix | HTTP 200 | 414 |<----------------------------------------| 415 | | 416 CNC POST the | POST /VN | 417 VN identifying |---------------------------------------->| 418 AP, VNAP and VN- | | 419 Members and maps | | 420 to the TE-topo | HTTP 200 | 421 |<----------------------------------------| 422 | | 423 | | 424 CNC GET the | GET /VN | 425 VN YANG status |---------------------------------------->| 426 | | 427 | HTTP 200 (VN with status) | 428 |<----------------------------------------| 429 | | 431 Case 2: 433 On the other hand, if MDSC create the single abstract node topology 434 based VN YANG posted by the CNC, the following diagram shows the 435 message flow between CNC and MDSC to instantiate this VN using VN 436 and TE-Topology Models. 438 +--------+ +--------+ 439 | CNC | | MDSC | 440 +--------+ +--------+ 441 | | 442 | | 443 CNC POST VN | | 444 Identifying AP, | | 445 VNAP and VN- | POST /VN | MDSC populates 446 Members |-------------------------------->| a single Abst. 447 | HTTP 200 | node topology 448 |<--------------------------------| by itself 449 | | 450 CNC GET VN & | GET /VN & | 451 POST TE-Topo | POST /nw:networks/nw:network/ | 452 Models (with | nw:node/te-node-id/tet: | 453 Conn. Matrix on | connectivity-matrices/ | 454 | tet:connectivity-matrix | 455 the Abstract Node|-------------------------------->| 456 and explicit | | 457 paths in the | | 458 Conn. Matrix | | 459 | HTTP 200 | 460 |<--------------------------------| 461 | | 462 | | 463 CNC GET the | GET /VN | 464 VN YANG status |-------------------------------->| 465 | | 466 | HTTP 200 (VN with status) | 467 |<--------------------------------| 468 | | 470 Section 7 provides JSON examples for both VN model and TE-topology 471 Connectivity Matrix sub-model to illustrate how a VN can be created 472 by the CNC making use of the VN module as well as the TE-topology 473 Connectivity Matrix module. 475 4. VN Model Usage 477 4.1. Customer view of VN 479 The VN-Yang model allows to define a customer view, and allows the 480 customer to communicate using the VN constructs as described in the 481 [ACTN-INFO]. It also allows to group the set of edge-to-edge links 482 (i.e., VN members) under a common umbrella of VN. This allows the 483 customer to instantiate and view the VN as one entity, making it 484 easier for some customers to work on VN without worrying about the 485 details of the provider based YANG models. 487 This is similar to the benefits of having a separate YANG model for 488 the customer services as described in [RFC8309], which states that 489 service models do not make any assumption of how a service is 490 actually engineered and delivered for a customer. 492 4.2. Auto-creation of VN by MDSC 494 The VN could be configured at the MDSC explicitly by the CNC using 495 the VN yang model. In some other cases, the VN is not explicitly 496 configured, but created automatically by the MDSC based on the 497 customer service model and local policy, even in these case the VN 498 yang model can be used by the CNC to learn details of the underlying 499 VN created to meet the requirements of customer service model. 501 4.3. Innovative Services 503 4.3.1. VN Compute 505 VN Model supports VN compute (pre-instantiation mode) to view the 506 full VN as a single entity before instantiation. Achieving this via 507 path computation or "compute only" tunnel setup does not provide the 508 same functionality. 510 4.3.2. Multi-sources and Multi-destinations 512 In creating a virtual network, the list of sources or destinations 513 or both may not be pre-determined by the customer. For instance, for 514 a given source, there may be a list of multiple-destinations to 515 which the optimal destination may be chosen depending on the network 516 resource situations. Likewise, for a given destination, there may 517 also be multiple-sources from which the optimal source may be 518 chosen. In some cases, there may be a pool of multiple sources and 519 destinations from which the optimal source-destination may be 520 chosen. The following YANG module is shown for describing source 521 container and destination container. The following YANG tree shows 522 how to model multi-sources and multi-destinations. 524 +--rw vn 525 +--rw vn-list* [vn-id] 526 +--rw vn-id uint32 527 +--rw vn-name? string 528 +--rw vn-topology-id? te-types:te-topology-id 529 +--rw abstract-node? 530 -> /nw:networks/network/node/tet:te-node-id 531 +--rw vn-member-list* [vn-member-id] 532 | +--rw vn-member-id uint32 533 | +--rw src 534 | | +--rw src? 535 -> /ap/access-point-list/access-point-id 536 | | +--rw src-vn-ap-id? 537 -> /ap/access-point-list/vn-ap/vn-ap-id 538 | | +--rw multi-src? boolean {multi-src-dest}? 539 | +--rw dest 540 | | +--rw dest? 541 -> /ap/access-point-list/access-point-id 542 | | +--rw dest-vn-ap-id? 543 -> /ap/access-point-list/vn-ap/vn-ap-id 544 | | +--rw multi-dest? boolean {multi-src-dest}? 545 | +--rw connetivity-matrix-id? 546 -> /nw:networks/network/node/tet:te/te-node-attributes/connectivity- 547 matrices/connectivity-matrix/id 548 | +--ro oper-status? identityref 549 +--ro if-selected? boolean {multi-src-dest}? 550 +--rw admin-status? identityref 551 +--ro oper-status? identityref 553 4.3.3. Others 555 The VN Yang model can be easily augmented to support the mapping of 556 VN to the Services such as L3SM and L2SM as described in [TE-MAP]. 558 The VN Yang model can be extended to support telemetry, performance 559 monitoring and network autonomics as described in [ACTN-PM]. 561 4.3.4. Summary 563 This section summarizes the innovative service features of the VN 564 Yang. 566 o Maintenance of AP and VNAP along with VN. 568 o VN construct to group of edge-to-edge links 570 o VN Compute (pre-instantiate) 572 o Multi-Source / Multi-Destination 574 o Ability to support various VN and VNS Types 576 * VN Type 1: Customer configures the VN as a set of VN 577 Members. 578 No other details need to be set by customer, making for a 579 simplified operations for the customer. 581 * VN Type 2: Along with VN Members, the customer could also 582 provide an abstract topology, this topology is provided by 583 the Abstract TE Topology Yang Model. 585 5. VN YANG Model (Tree Structure) 587 module: ietf-vn 588 +-rw ap 589 | +-rw access-point-list* [access-point-id] 590 | +-rw access-point-id uint32 591 | +-rw access-point-name? string 592 | +-rw max-bandwidth? te-types:te-bandwidth 593 | +-rw avl-bandwidth? te-types:te-bandwidth 594 | +-rw vn-ap* [vn-ap-id] 595 | +-rw vn-ap-id uint32 596 | +-rw vn? 597 -> /vn/vn-list/vn-id 598 | +-rw abstract-node? 599 -> /nw:networks/network/node/tet:te-node-id 600 | +-rw ltp? 601 -> /nw:networks/network/node/nt:termination-point/tet:te-tp-id 602 +-rw vn 603 +-rw vn-list* [vn-id] 604 +-rw vn-id uint32 605 +-rw vn-name? string 606 +-rw vn-topology-id? te-types:te-topology-id 607 +-rw abstract-node? 608 -> /nw:networks/network/node/tet:te-node-id 609 +-rw vn-member-list* [vn-member-id] 610 | +-rw vn-member-id uint32 611 | +-rw src 612 | | +-rw src? 613 -> /ap/access-point-list/access-point-id 614 | | +-rw src-vn-ap-id? 615 -> /ap/access-point-list/vn-ap/vn-ap-id 616 | | +-rw multi-src? boolean {multi-src-dest}? 617 | +-rw dest 618 | | +-rw dest? 619 -> /ap/access-point-list/access-point-id 620 | | +-rw dest-vn-ap-id? 621 -> /ap/access-point-list/vn-ap/vn-ap-id 622 | | +-rw multi-dest? boolean {multi-src-dest}? 623 | +-rw connectivity-matrix-id? 624 -> /nw:networks/network/node/tet:te/te-node-attribute 625 /connectivity-matrices/connectivity-matrix/id 626 | +-ro oper-status? identityref 627 +-ro if-selected? boolean {multi-src-dest}? 628 +-rw admin-status? identityref 629 +-ro oper-status? identityref 630 +-rw vn-level-diversity? vn-disjointness 632 rpcs: 633 +--x vn-compute 634 +--w input 635 | +--w abstract-node? 636 -> /nw:networks/network/node/tet:te-node-id 637 | +--w vn-member-list* [vn-member-id] 638 | | +--w vn-member-id uint32 639 | | +--w src 640 | | | +--w src? 641 -> /ap/access-point-list/access-point-id 642 | | | +--w src-vn-ap-id? 643 -> /ap/access-point-list/vn-ap/vn-ap-id 644 | | | +--w multi-src? boolean {multi-src-dest}? 645 | | +--w dest 646 | | | +--w dest? 647 -> /ap/access-point-list/access-point-id 648 | | | +--w dest-vn-ap-id? 649 -> /ap/access-point-list/vn-ap/vn-ap-id 650 | | | +--w multi-dest? boolean {multi-src-dest}? 651 | | +--w connectivity-matrix-id? 652 -> /nw:networks/network/node/tet:te/te-node-attributes 653 /connectivity-matrices/connectivity-matrix/id 654 | +--w vn-level-diversity? vn-disjointness 655 +-ro output 656 +-ro vn-member-list* [vn-member-id] 657 +-ro vn-member-id uint32 658 +-ro src 659 | +-ro src? -> 660 /ap/access-point-list/access-point-id 661 | +-ro src-vn-ap-id? -> 662 /ap/access-point-list/vn-ap/vn-ap-id 663 | +-ro multi-src? boolean {multi-src-dest}? 664 +-ro dest 665 | +-ro dest? -> 666 /ap/access-point-list/access-point-id 667 | +-ro dest-vn-ap-id? -> 668 /ap/access-point-list/vn-ap/vn-ap-id 669 | +-ro multi-dest? boolean {multi-src-dest}? 670 +-ro connectivity-matrix-id? 671 -> /nw:networks/network/node/tet:te/te-node-attributes 672 /connectivity-matrices/connectivity-matrix/id 673 +-ro if-selected? boolean {multi-src-dest}? 674 +-ro compute-status? identityref 676 6. VN YANG Code 678 The YANG code is as follows: 680 file "ietf-vn@2019-06-20.yang" 682 module ietf-vn { 683 yang-version 1.1; 684 namespace "urn:ietf:params:xml:ns:yang:ietf-vn"; 685 prefix "vn"; 687 /* Import network */ 688 import ietf-network { 689 prefix "nw"; 690 reference 691 "RFC 8345: A YANG Data Model for Network Topologies"; 692 } 693 /* Import network topology */ 694 import ietf-network-topology { 695 prefix "nt"; 696 reference 697 "RFC 8345: A YANG Data Model for Network Topologies"; 698 } 700 /* Import TE generic types */ 701 import ietf-te-types { 702 prefix "te-types"; 703 reference 704 "I-D.ietf-teas-yang-te-types: Traffic Engineering 705 Common YANG Types"; 706 } 708 /* Import Abstract TE Topology */ 709 import ietf-te-topology { 710 prefix "tet"; 711 reference 712 "I-D.ietf-teas-yang-te-topo: YANG Data Model for 713 Traffic Engineering (TE) Topologies"; 714 } 716 organization 717 "IETF Traffic Engineering Architecture and Signaling (TEAS) 718 Working Group"; 719 contact 720 "Editor: Young Lee 721 : Dhruv Dhody "; 722 description 723 "This module contains a YANG module for the VN. It 724 describes a VN operation module that takes place in the 725 context of the CNC-MDSC Interface (CMI) of the ACTN 726 architecture where the CNC is the actor of a VN 727 Instantiation/modification /deletion."; 728 revision 2019-06-10 { 729 description 730 "initial version."; 731 reference 732 "TBD"; 733 } 734 /* 735 * Features 736 */ 737 feature multi-src-dest { 738 description 739 "Support for selection of one src or destination 740 among multiple."; 741 } 743 /*identity path-metric-delay { 744 base te-types:path-metric-type; 745 description 746 "delay path metric"; 747 } 748 identity path-metric-delay-variation { 749 base te-types:path-metric-type; 750 description 751 "delay-variation path metric"; 752 } 753 identity path-metric-loss { 754 base te-types:path-metric-type; 755 description 756 "loss path metric"; 757 }*/ 759 identity vn-state-type { 760 description 761 "Base identity for VN state"; 762 } 763 identity vn-state-up { 764 base vn-state-type; 765 description "VN state up"; 766 } 767 identity vn-state-down { 768 base vn-state-type; 769 description "VN state down"; 770 } 771 identity vn-admin-state-type { 772 description 773 "Base identity for VN admin states"; 774 } 775 identity vn-admin-state-up { 776 base vn-admin-state-type; 777 description "VN administratively state up"; 778 } 779 identity vn-admin-state-down { 780 base vn-admin-state-type; 781 description "VN administratively state down"; 782 } 783 identity vn-compute-state-type { 784 description 785 "Base identity for compute states"; 786 } 787 identity vn-compute-state-computing { 788 base vn-compute-state-type; 789 description 790 "State path compute in progress"; 791 } 792 identity vn-compute-state-computation-ok { 793 base vn-compute-state-type; 794 description 795 "State path compute successful"; 796 } 797 identity vn-compute-state-computatione-failed { 798 base vn-compute-state-type; 799 description 800 "State path compute failed"; 801 } 802 /* 803 * Groupings 804 */ 806 typedef vn-disjointness { 807 type bits { 808 bit node { 809 position 0; 810 description "node disjoint"; 811 } 812 bit link { 813 position 1; 814 description "link disjoint"; 815 } 816 bit srlg { 817 position 2; 818 description "srlg disjoint"; 819 } 820 } 821 description 822 "type of the resource disjointness for 823 VN level applied across all VN members 824 in a VN"; 825 } 827 grouping vn-ap { 828 description 829 "VNAP related information"; 830 leaf vn-ap-id { 831 type uint32; 832 description 833 "unique identifier for the referred 834 VNAP"; 835 } 836 leaf vn { 837 type leafref { 838 path "/vn/vn-list/vn-id"; 839 } 840 description 841 "reference to the VN"; 842 } 843 leaf abstract-node { 844 type leafref { 845 path "/nw:networks/nw:network/nw:node/" 846 +"tet:te-node-id"; 847 } 848 description 849 "a reference to the abstract node in TE 850 Topology"; 851 } 852 leaf ltp { 853 type leafref { 854 path "/nw:networks/nw:network/nw:node/" 855 +"nt:termination-point/tet:te-tp-id"; 856 } 857 description 858 "Reference LTP in the TE-topology"; 859 } 860 } 861 grouping access-point{ 862 description 863 "AP related information"; 864 leaf access-point-id { 865 type uint32; 866 description 867 "unique identifier for the referred 868 access point"; 869 } 870 leaf access-point-name { 871 type string; 872 description 873 "ap name"; 874 } 876 leaf max-bandwidth { 877 type te-types:te-bandwidth; 878 description 879 "max bandwidth of the AP"; 880 } 881 leaf avl-bandwidth { 882 type te-types:te-bandwidth; 883 description 884 "available bandwidth of the AP"; 885 } 886 /*add details and any other properties of AP, 887 not associated by a VN 888 CE port, PE port etc. 889 */ 890 list vn-ap { 891 key vn-ap-id; 892 uses vn-ap; 893 description 894 "list of VNAP in this AP"; 895 } 896 }//access-point 897 grouping vn-member { 898 description 899 "vn-member is described by this container"; 900 leaf vn-member-id { 901 type uint32; 902 description 903 "vn-member identifier"; 904 } 905 container src 906 { 907 description 908 "the source of VN Member"; 909 leaf src { 910 type leafref { 911 path "/ap/access-point-list/access-point-id"; 912 } 913 description 914 "reference to source AP"; 915 } 916 leaf src-vn-ap-id{ 917 type leafref { 918 path "/ap/access-point-list/vn-ap/vn-ap-id"; 919 } 920 description 921 "reference to source VNAP"; 922 } 923 leaf multi-src { 924 if-feature multi-src-dest; 925 type boolean; 926 description 927 "Is source part of multi-source, where 928 only one of the source is enabled"; 929 } 930 } 931 container dest 932 { 933 description 934 "the destination of VN Member"; 935 leaf dest { 936 type leafref { 937 path "/ap/access-point-list/access-point-id"; 938 } 939 description 940 "reference to destination AP"; 941 } 942 leaf dest-vn-ap-id{ 943 type leafref { 944 path "/ap/access-point-list/vn-ap/vn-ap-id"; 945 } 946 description 947 "reference to dest VNAP"; 948 } 949 leaf multi-dest { 950 if-feature multi-src-dest; 951 type boolean; 952 description 953 "Is destination part of multi-destination, where 954 only one of the destination is enabled"; 955 } 956 } 957 leaf connectivity-matrix-id{ 958 type leafref { 959 path "/nw:networks/nw:network/nw:node/tet:te/" 960 + "tet:te-node-attributes/" 961 + "tet:connectivity-matrices/" 962 + "tet:connectivity-matrix/tet:id"; 964 } 965 description 966 "reference to connectivity-matrix"; 967 } 968 }//vn-member 969 /* 970 grouping policy { 971 description 972 "policy related to vn-member-id"; 973 leaf local-reroute { 974 type boolean; 975 description 976 "Policy to state if reroute 977 can be done locally"; 978 } 979 leaf push-allowed { 980 type boolean; 981 description 982 "Policy to state if changes 983 can be pushed to the customer"; 984 } 985 leaf incremental-update { 986 type boolean; 987 description 988 "Policy to allow only the 989 changes to be reported"; 990 } 991 }//policy 992 */ 993 grouping vn-policy { 994 description 995 "policy for VN-level diverisity"; 996 leaf vn-level-diversity { 997 type vn-disjointness; 998 description 999 "the type of disjointness on the VN level 1000 (i.e., across all VN members)"; 1001 } 1002 } 1003 /* 1004 grouping metrics-op { 1005 description 1006 "metric related information"; 1007 list metric{ 1008 key "metric-type"; 1009 config false; 1010 description 1011 "The list of metrics for VN"; 1012 leaf metric-type { 1013 type identityref { 1014 base te-types:path-metric-type; 1015 } 1016 description 1017 "The VN metric type."; 1018 } 1019 leaf value{ 1020 type uint32; 1021 description 1022 "The limit value"; 1023 } 1024 } 1025 } 1026 */ 1027 /* 1028 grouping metrics { 1029 description 1030 "metric related information"; 1031 list metric{ 1032 key "metric-type"; 1033 description 1034 "The list of metrics for VN"; 1035 uses te:path-metrics-bounds_config; 1036 container optimize{ 1037 description 1038 "optimizing constraints"; 1039 leaf enabled{ 1040 type boolean; 1041 description 1042 "Metric to optimize"; 1043 } 1044 leaf value{ 1045 type uint32; 1046 description 1047 "The computed value"; 1048 } 1049 } 1050 } 1051 } 1052 */ 1053 /* 1054 grouping service-metric { 1055 description 1056 "service-metric"; 1057 uses te:path-objective-function_config; 1058 uses metrics; 1059 uses te-types:common-constraints_config; 1060 uses te:protection-restoration-params_config; 1061 uses policy; 1062 }//service-metric 1063 */ 1064 /* 1065 * Configuration data nodes 1066 */ 1068 container ap { 1069 description 1070 "AP configurations"; 1071 list access-point-list { 1072 key "access-point-id"; 1073 description 1074 "access-point identifier"; 1075 uses access-point { 1076 description 1077 "access-point information"; 1078 } 1079 } 1080 } 1082 container vn { 1083 description 1084 "VN configurations"; 1085 list vn-list { 1086 key "vn-id"; 1087 description 1088 "a virtual network is identified by a vn-id"; 1089 leaf vn-id { 1090 type uint32; 1091 description 1092 "a unique vn identifier"; 1093 } 1094 leaf vn-name { 1095 type string; 1096 description "vn name"; 1097 } 1098 leaf vn-topology-id{ 1099 type te-types:te-topology-id; 1100 description 1101 "An optional identifier to the TE Topology 1102 Model where the abstract nodes and links 1103 of the Topology can be found for Type 2 1104 VNS"; 1105 } 1106 leaf abstract-node { 1107 type leafref { 1108 path "/nw:networks/nw:network/nw:node/" 1109 + "tet:te-node-id"; 1110 } 1111 description 1112 "a reference to the abstract node in TE 1113 Topology"; 1114 } 1115 list vn-member-list{ 1116 key "vn-member-id"; 1117 description 1118 "List of VN-members in a VN"; 1119 uses vn-member; 1120 /*uses metrics-op;*/ 1121 leaf oper-status { 1122 type identityref { 1123 base vn-state-type; 1124 } 1125 config false; 1126 description 1127 "VN-member operational state."; 1128 } 1130 } 1131 leaf if-selected{ 1132 if-feature multi-src-dest; 1133 type boolean; 1134 default false; 1135 config false; 1136 description 1137 "Is the vn-member is selected among the 1138 multi-src/dest options"; 1139 } 1140 /* 1141 container multi-src-dest{ 1142 if-feature multi-src-dest; 1143 config false; 1144 description 1145 "The selected VN Member when multi-src 1146 and/or mult-destination is enabled."; 1147 leaf selected-vn-member{ 1148 type leafref { 1149 path "/vn/vn-list/vn-member-list" 1150 + "/vn-member-id"; 1151 } 1152 description 1153 "The selected VN Member along the set 1154 of source and destination configured 1155 with multi-source and/or multi-destination"; 1156 } 1157 } 1158 */ 1159 /*uses service-metric;*/ 1160 leaf admin-status { 1161 type identityref { 1162 base vn-admin-state-type; 1163 } 1164 default vn-admin-state-up; 1165 description "VN administrative state."; 1166 } 1167 leaf oper-status { 1168 type identityref { 1169 base vn-state-type; 1170 } 1171 config false; 1172 description "VN operational state."; 1173 } 1174 uses vn-policy; 1175 }//vn-list 1176 }//vn 1178 /* 1179 * Notifications - TBD 1180 */ 1181 /* 1182 * RPC 1183 */ 1184 rpc vn-compute{ 1185 description 1186 "The VN computation without actual 1187 instantiation"; 1188 input { 1189 leaf abstract-node { 1190 type leafref { 1191 path "/nw:networks/nw:network/nw:node/" 1192 + "tet:te-node-id"; 1193 } 1194 description 1195 "a reference to the abstract node in TE 1196 Topology"; 1197 } 1198 list vn-member-list{ 1199 key "vn-member-id"; 1200 description 1201 "List of VN-members in a VN"; 1202 uses vn-member; 1203 } 1204 uses vn-policy; 1205 /*uses service-metric;*/ 1206 } 1207 output { 1208 list vn-member-list{ 1209 key "vn-member-id"; 1210 description 1211 "List of VN-members in a VN"; 1212 uses vn-member; 1213 leaf if-selected{ 1214 if-feature multi-src-dest; 1215 type boolean; 1216 default false; 1217 description 1218 "Is the vn-member is selected among 1219 the multi-src/dest options"; 1220 } 1221 /*uses metrics-op;*/ 1222 leaf compute-status { 1223 type identityref { 1224 base vn-compute-state-type; 1225 } 1226 description 1227 "VN-member compute state."; 1228 } 1229 } 1230 /* 1231 container multi-src-dest{ 1232 if-feature multi-src-dest; 1233 description 1234 "The selected VN Member when multi-src 1235 and/or mult-destination is enabled."; 1236 leaf selected-vn-member-id{ 1237 type uint32; 1238 description 1239 "The selected VN Member-id from the 1240 input"; 1241 } 1242 }*/ 1243 } 1244 } 1245 } 1247 1249 7. JSON Example 1251 This section provides json implementation examples as to how VN YANG 1252 model and TE topology model are used together to instantiate virtual 1253 networks. 1255 The example in this section includes following VN 1257 o VN1 (Type 1): Which maps to the single node topology abstract1 1258 (node D1) and consist of VN Members 104 (L1 to L4), 107 (L1 to 1259 L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8). We also 1260 show how disjointness (node, link, srlg) is supported in the 1261 example on the global level (i.e., connectivity matrices level). 1263 o VN2 (Type 2): Which maps to the single node topology abstract2 1264 (node D2), this topology has an underlay topology (absolute) (see 1265 figure in section 3.2). This VN has a single VN member 105 (L1 to 1266 L5) and an underlay path (S4 and S7) has been set in the 1267 connectivity matrix of abstract2 topology; 1269 o VN3 (Type 1): This VN has a multi-source, multi-destination 1270 feature enable for VN Member 104 (L1 to L4)/107 (L1 to L7) 1271 [multi-src] and VN Member 204 (L2 to L4)/304 (L3 to L4) [multi- 1272 dest] usecase. The selected VN-member is known via the field "if- 1273 selected" and the corresponding connectivity-matrix-id. 1275 Note that the VN YANG model also include the AP and VNAP which shows 1276 various VN using the same AP. 1277 7.1. VN JSON 1279 { 1280 "ap":{ 1281 "access-point-list": [ 1282 { 1283 "access-point-id": 101, 1284 "access-point-name": "101", 1285 "vn-ap": [ 1286 { 1287 "vn-ap-id": 10101, 1288 "vn": 1, 1289 "abstract-node": "D1", 1290 "ltp": "1-0-1" 1291 }, 1292 { 1293 "vn-ap-id": 10102, 1294 "vn": 2, 1295 "abstract-node": "D2", 1296 "ltp": "1-0-1" 1297 }, 1298 { 1299 "vn-ap-id": 10103, 1300 "vn": 3, 1301 "abstract-node": "D3", 1302 "ltp": "1-0-1" 1303 }, 1304 ] 1305 }, 1306 { 1307 "access-point-id": 202, 1308 "access-point-name": "202", 1309 "vn-ap": [ 1310 { 1311 "vn-ap-id": 20201, 1312 "vn": 1, 1313 "abstract-node": "D1", 1314 "ltp": "2-0-2" 1315 } 1316 ] 1317 }, 1318 { 1319 "access-point-id": 303, 1320 "access-point-name": "303", 1321 "vn-ap": [ 1322 { 1323 "vn-ap-id": 30301, 1324 "vn": 1, 1325 "abstract-node": "D1", 1326 "ltp": "3-0-3" 1327 }, 1328 { 1329 "vn-ap-id": 30303, 1330 "vn": 3, 1331 "abstract-node": "D3", 1332 "ltp": "3-0-3" 1333 } 1334 ] 1335 }, 1336 { 1337 "access-point-id": 440, 1338 "access-point-name": "440", 1339 "vn-ap": [ 1340 { 1341 "vn-ap-id": 44001, 1342 "vn": 1, 1343 "abstract-node": "D1", 1344 "ltp": "4-4-0" 1345 } 1346 ] 1347 }, 1348 { 1349 "access-point-id": 550, 1350 "access-point-name": "550", 1351 "vn-ap": [ 1352 { 1353 "vn-ap-id": 55002, 1354 "vn": 2, 1355 "abstract-node": "D2", 1356 "ltp": "5-5-0" 1357 } 1358 ] 1359 }, 1360 { 1361 "access-point-id": 770, 1362 "access-point-name": "770", 1363 "vn-ap": [ 1364 { 1365 "vn-ap-id": 77001, 1366 "vn": 1, 1367 "abstract-node": "D1", 1368 "ltp": "7-7-0" 1369 }, 1370 { 1371 "vn-ap-id": 77003, 1372 "vn": 3, 1373 "abstract-node": "D3", 1374 "ltp": "7-7-0" 1375 } 1376 ] 1377 }, 1378 { 1379 "access-point-id": 880, 1380 "access-point-name": "880", 1381 "vn-ap": [ 1382 { 1383 "vn-ap-id": 88001, 1384 "vn": 1, 1385 "abstract-node": "D1", 1386 "ltp": "8-8-0" 1387 }, 1388 { 1389 "vn-ap-id": 88003, 1390 "vn": 3, 1391 "abstract-node": "D3", 1392 "ltp": "8-8-0" 1393 } 1394 ] 1395 } 1396 ] 1397 }, 1398 "vn":{ 1399 "vn-list": [ 1400 { 1401 "vn-id": 1, 1402 "vn-name": "vn1", 1403 "vn-topology-id": "te-topology:abstract1", 1404 "abstract-node": "D1", 1405 "vn-member-list": [ 1406 { 1407 "vn-member-id": 104, 1408 "src": { 1409 "src": 101, 1410 "src-vn-ap-id": 10101, 1411 }, 1412 "dest": { 1413 "dest": 440, 1414 "dest-vn-ap-id": 44001, 1415 }, 1416 "connectivity-matrix-id": 104 1417 }, 1418 { 1419 "vn-member-id": 107, 1420 "src": { 1421 "src": 101, 1422 "src-vn-ap-id": 10101, 1423 }, 1424 "dest": { 1425 "dest": 770, 1426 "dest-vn-ap-id": 77001, 1427 }, 1428 "connectivity-matrix-id": 107 1429 }, 1430 { 1431 "vn-member-id": 204, 1432 "src": { 1433 "src": 202, 1434 "dest-vn-ap-id": 20401, 1435 }, 1436 "dest": { 1437 "dest": 440, 1438 "dest-vn-ap-id": 44001, 1439 }, 1440 "connectivity-matrix-id": 204 1441 }, 1442 { 1443 "vn-member-id": 308, 1444 "src": { 1445 "src": 303, 1446 "src-vn-ap-id": 30301, 1447 }, 1448 "dest": { 1449 "dest": 880, 1450 "src-vn-ap-id": 88001, 1451 }, 1452 "connectivity-matrix-id": 308 1453 }, 1454 { 1455 "vn-member-id": 108, 1456 "src": { 1457 "src": 101, 1458 "src-vn-ap-id": 10101, 1459 }, 1460 "dest": { 1461 "dest": 880, 1462 "dest-vn-ap-id": 88001, 1463 }, 1464 "connectivity-matrix-id": 108 1465 } 1466 ] 1467 }, 1468 { 1469 "vn-id": 2, 1470 "vn-name": "vn2", 1471 "vn-topology-id": "te-topology:abstract2", 1472 "abstract-node": "D2", 1473 "vn-member-list": [ 1474 { 1475 "vn-member-id": 105, 1476 "src": { 1477 "src": 101, 1478 "src-vn-ap-id": 10102, 1479 }, 1480 "dest": { 1481 "dest": 550, 1482 "dest-vn-ap-id": 55002, 1483 }, 1484 "connectivity-matrix-id": 105 1485 } 1486 ] 1487 }, 1488 { 1489 "vn-id": 3, 1490 "vn-name": "vn3", 1491 "vn-topology-id": "te-topology:abstract3", 1492 "abstract-node": "D3", 1493 "vn-member-list": [ 1494 { 1495 "vn-member-id": 104, 1496 "src": { 1497 "src": 101, 1498 }, 1499 "dest": { 1500 "dest": 440, 1501 "multi-dest": true 1502 } 1503 }, 1504 { 1505 "vn-member-id": 107, 1506 "src": { 1507 "src": 101, 1508 "src-vn-ap-id": 10103, 1509 }, 1510 "dest": { 1511 "dest": 770, 1512 "dest-vn-ap-id": 77003, 1513 "multi-dest": true 1514 }, 1515 "connectivity-matrix-id": 107, 1516 "if-selected":true, 1517 }, 1518 { 1519 "vn-member-id": 204, 1520 "src": { 1521 "src": 202, 1522 "multi-src": true, 1523 }, 1524 "dest": { 1525 "dest": 440, 1526 }, 1527 }, 1528 { 1529 "vn-member-id": 304, 1530 "src": { 1531 "src": 303, 1532 "src-vn-ap-id": 30303, 1533 "multi-src": true, 1534 }, 1535 "dest": { 1536 "dest": 440, 1537 "src-vn-ap-id": 44003, 1538 }, 1539 "connectivity-matrix-id": 304, 1540 "if-selected":true, 1541 }, 1542 ] 1543 }, 1545 ] 1546 } 1548 } 1549 } 1551 7.2. TE-topology JSON 1553 { 1554 "networks": { 1555 "network": [ 1556 { 1557 "network-types": { 1558 "te-topology": {} 1559 }, 1560 "network-id": "abstract1", 1561 "provider-id": 201, 1562 "client-id": 600, 1563 "te-topology-id": "te-topology:abstract1", 1564 "node": [ 1565 { 1566 "node-id": "D1", 1567 "te-node-id": "2.0.1.1", 1568 "te": { 1569 "te-node-attributes": { 1570 "domain-id" : 1, 1571 "is-abstract": [null], 1572 "connectivity-matrices": { 1573 "is-allowed": true, 1574 "path-constraints": { 1575 "bandwidth-generic": { 1576 "te-bandwidth": { 1577 "generic": [ 1578 { 1579 "generic": "0x1p10", 1580 } 1581 ] 1582 } 1583 } 1584 "disjointness": "node link srlg", 1586 }, 1587 "connectivity-matrix": [ 1588 { 1589 "id": 104, 1590 "from": "1-0-1", 1591 "to": "4-4-0" 1592 }, 1593 { 1594 "id": 107, 1595 "from": "1-0-1", 1596 "to": "7-7-0" 1597 }, 1598 { 1599 "id": 204, 1600 "from": "2-0-2", 1601 "to": "4-4-0" 1602 }, 1603 { 1604 "id": 308, 1605 "from": "3-0-3", 1606 "to": "8-8-0" 1607 }, 1608 { 1609 "id": 108, 1610 "from": "1-0-1", 1611 "to": "8-8-0" 1612 }, 1613 ] 1614 } 1615 } 1616 }, 1617 "termination-point": [ 1618 { 1619 "tp-id": "1-0-1", 1620 "te-tp-id": 10001, 1621 "te": { 1622 "interface-switching-capability": [ 1623 { 1624 "switching-capability": "switching-otn", 1625 "encoding": "lsp-encoding-oduk" 1626 } 1627 ] 1628 } 1629 }, 1630 { 1631 "tp-id": "1-1-0", 1632 "te-tp-id": 10100, 1633 "te": { 1634 "interface-switching-capability": [ 1635 { 1636 "switching-capability": "switching-otn", 1637 "encoding": "lsp-encoding-oduk" 1638 } 1639 ] 1640 } 1641 }, 1642 { 1643 "tp-id": "2-0-2", 1644 "te-tp-id": 20002, 1645 "te": { 1646 "interface-switching-capability": [ 1647 { 1648 "switching-capability": "switching-otn", 1649 "encoding": "lsp-encoding-oduk" 1650 } 1651 ] 1652 } 1653 }, 1654 { 1655 "tp-id": "2-2-0", 1656 "te-tp-id": 20200, 1657 "te": { 1658 "interface-switching-capability": [ 1659 { 1660 "switching-capability": "switching-otn", 1661 "encoding": "lsp-encoding-oduk" 1662 } 1663 ] 1664 } 1665 }, 1666 { 1667 "tp-id": "3-0-3", 1668 "te-tp-id": 30003, 1669 "te": { 1670 "interface-switching-capability": [ 1671 { 1672 "switching-capability": "switching-otn", 1673 "encoding": "lsp-encoding-oduk" 1674 } 1675 ] 1676 } 1677 }, 1678 { 1679 "tp-id": "3-3-0", 1680 "te-tp-id": 30300, 1681 "te": { 1682 "interface-switching-capability": [ 1683 { 1684 "switching-capability": "switching-otn", 1685 "encoding": "lsp-encoding-oduk" 1686 } 1687 ] 1688 } 1689 }, 1690 { 1691 "tp-id": "4-0-4", 1692 "te-tp-id": 40004, 1693 "te": { 1694 "interface-switching-capability": [ 1695 { 1696 "switching-capability": "switching-otn", 1697 "encoding": "lsp-encoding-oduk" 1698 } 1699 ] 1700 } 1701 }, 1702 { 1703 "tp-id": "4-4-0", 1704 "te-tp-id": 40400, 1705 "te": { 1706 "interface-switching-capability": [ 1707 { 1708 "switching-capability": "switching-otn", 1709 "encoding": "lsp-encoding-oduk" 1710 } 1711 ] 1712 } 1713 }, 1714 { 1715 "tp-id": "5-0-5", 1716 "te-tp-id": 50005, 1717 "te": { 1718 "interface-switching-capability": [ 1719 { 1720 "switching-capability": "switching-otn", 1721 "encoding": "lsp-encoding-oduk" 1722 } 1723 ] 1724 } 1725 }, 1726 { 1727 "tp-id": "5-5-0", 1728 "te-tp-id": 50500, 1729 "te": { 1730 "interface-switching-capability": [ 1731 { 1732 "switching-capability": "switching-otn", 1733 "encoding": "lsp-encoding-oduk" 1734 } 1735 ] 1736 } 1737 }, 1738 { 1739 "tp-id": "6-0-6", 1740 "te-tp-id": 60006, 1741 "te": { 1742 "interface-switching-capability": [ 1743 { 1744 "switching-capability": "switching-otn", 1745 "encoding": "lsp-encoding-oduk" 1746 } 1747 ] 1748 } 1749 }, 1750 { 1751 "tp-id": "6-6-0", 1752 "te-tp-id": 60600, 1753 "te": { 1754 "interface-switching-capability": [ 1755 { 1756 "switching-capability": "switching-otn", 1757 "encoding": "lsp-encoding-oduk" 1758 } 1759 ] 1760 } 1761 }, 1762 { 1763 "tp-id": "7-0-7", 1764 "te-tp-id": 70007, 1765 "te": { 1766 "interface-switching-capability": [ 1767 { 1768 "switching-capability": "switching-otn", 1769 "encoding": "lsp-encoding-oduk" 1770 } 1771 ] 1772 } 1773 }, 1774 { 1775 "tp-id": "7-7-0", 1776 "te-tp-id": 70700, 1777 "te": { 1778 "interface-switching-capability": [ 1779 { 1780 "switching-capability": "switching-otn", 1781 "encoding": "lsp-encoding-oduk" 1782 } 1783 ] 1784 } 1785 }, 1786 { 1787 "tp-id": "8-0-8", 1788 "te-tp-id": 80008, 1789 "te": { 1790 "interface-switching-capability": [ 1791 { 1792 "switching-capability": "switching-otn", 1793 "encoding": "lsp-encoding-oduk" 1794 } 1795 ] 1796 } 1797 }, 1798 { 1799 "tp-id": "8-8-0", 1800 "te-tp-id": 80800, 1801 "te": { 1802 "interface-switching-capability": [ 1803 { 1804 "switching-capability": "switching-otn", 1805 "encoding": "lsp-encoding-oduk" 1806 } 1807 ] 1808 } 1809 } 1810 ] 1811 } 1812 ] 1813 }, 1814 { 1815 "network-types": { 1816 "te-topology": {} 1817 }, 1818 "network-id": "abstract2", 1819 "provider-id": 201, 1820 "client-id": 600, 1821 "te-topology-id": "te-topology:abstract2", 1822 "node": [ 1823 { 1824 "node-id": "D2", 1825 "te-node-id": "2.0.1.2", 1826 "te": { 1827 "te-node-attributes": { 1828 "domain-id" : 1, 1829 "is-abstract": [null], 1830 "connectivity-matrices": { 1831 "is-allowed": true, 1832 "underlay": { 1833 "enabled": true 1834 }, 1835 "path-constraints": { 1836 "bandwidth-generic": { 1837 "te-bandwidth": { 1838 "generic": [ 1839 { 1840 "generic": "0x1p10" 1841 } 1842 ] 1843 } 1844 } 1845 }, 1846 "optimizations": { 1847 "objective-function": { 1848 "objective-function-type": "of-maximize-residual- 1849 bandwidth" 1850 } 1851 }, 1852 "connectivity-matrix": [ 1853 { 1854 "id": 105, 1855 "from": "1-0-1", 1856 "to": "5-5-0", 1857 "underlay": { 1858 "enabled": true, 1859 "primary-path": { 1860 "network-ref": "absolute", 1861 "path-element": [ 1862 { 1863 "path-element-id": 1, 1864 "index": 1, 1865 "numbered-hop": { 1866 "address": "4.4.4.4", 1867 "hop-type": "STRICT" 1868 } 1869 }, 1870 { 1871 "path-element-id": 2, 1872 "index": 2, 1873 "numbered-hop": { 1874 "address": "7.7.7.7", 1875 "hop-type": "STRICT" 1876 } 1877 } 1878 ] 1879 } 1880 } 1881 } 1882 ] 1883 } 1884 } 1885 }, 1886 "termination-point": [ 1887 { 1888 "tp-id": "1-0-1", 1889 "te-tp-id": 10001, 1890 "te": { 1891 "interface-switching-capability": [ 1892 { 1893 "switching-capability": "switching-otn", 1894 "encoding": "lsp-encoding-oduk" 1895 } 1896 ] 1897 } 1898 }, 1899 { 1900 "tp-id": "1-1-0", 1901 "te-tp-id": 10100, 1902 "te": { 1903 "interface-switching-capability": [ 1904 { 1905 "switching-capability": "switching-otn", 1906 "encoding": "lsp-encoding-oduk" 1907 } 1908 ] 1909 } 1910 }, 1911 { 1912 "tp-id": "2-0-2", 1913 "te-tp-id": 20002, 1914 "te": { 1915 "interface-switching-capability": [ 1916 { 1917 "switching-capability": "switching-otn", 1918 "encoding": "lsp-encoding-oduk" 1919 } 1920 ] 1921 } 1922 }, 1923 { 1924 "tp-id": "2-2-0", 1925 "te-tp-id": 20200, 1926 "te": { 1927 "interface-switching-capability": [ 1928 { 1929 "switching-capability": "switching-otn", 1930 "encoding": "lsp-encoding-oduk" 1931 } 1932 ] 1933 } 1934 }, 1935 { 1936 "tp-id": "3-0-3", 1937 "te-tp-id": 30003, 1938 "te": { 1939 "interface-switching-capability": [ 1940 { 1941 "switching-capability": "switching-otn", 1942 "encoding": "lsp-encoding-oduk" 1943 } 1944 ] 1945 } 1946 }, 1947 { 1948 "tp-id": "3-3-0", 1949 "te-tp-id": 30300, 1950 "te": { 1951 "interface-switching-capability": [ 1952 { 1953 "switching-capability": "switching-otn", 1954 "encoding": "lsp-encoding-oduk" 1955 } 1956 ] 1957 } 1958 }, 1959 { 1960 "tp-id": "4-0-4", 1961 "te-tp-id": 40004, 1962 "te": { 1963 "interface-switching-capability": [ 1964 { 1965 "switching-capability": "switching-otn", 1966 "encoding": "lsp-encoding-oduk" 1967 } 1968 ] 1969 } 1970 }, 1971 { 1972 "tp-id": "4-4-0", 1973 "te-tp-id": 40400, 1974 "te": { 1975 "interface-switching-capability": [ 1976 { 1977 "switching-capability": "switching-otn", 1978 "encoding": "lsp-encoding-oduk" 1979 } 1980 ] 1981 } 1982 }, 1983 { 1984 "tp-id": "5-0-5", 1985 "te-tp-id": 50005, 1986 "te": { 1987 "interface-switching-capability": [ 1988 { 1989 "switching-capability": "switching-otn", 1990 "encoding": "lsp-encoding-oduk" 1991 } 1992 ] 1993 } 1994 }, 1995 { 1996 "tp-id": "5-5-0", 1997 "te-tp-id": 50500, 1998 "te": { 1999 "interface-switching-capability": [ 2000 { 2001 "switching-capability": "switching-otn", 2002 "encoding": "lsp-encoding-oduk" 2003 } 2004 ] 2005 } 2006 }, 2007 { 2008 "tp-id": "6-0-6", 2009 "te-tp-id": 60006, 2010 "te": { 2011 "interface-switching-capability": [ 2012 { 2013 "switching-capability": "switching-otn", 2014 "encoding": "lsp-encoding-oduk" 2015 } 2016 ] 2017 } 2018 }, 2019 { 2020 "tp-id": "6-6-0", 2021 "te-tp-id": 60600, 2022 "te": { 2023 "interface-switching-capability": [ 2024 { 2025 "switching-capability": "switching-otn", 2026 "encoding": "lsp-encoding-oduk" 2027 } 2028 ] 2029 } 2030 }, 2031 { 2032 "tp-id": "7-0-7", 2033 "te-tp-id": 70007, 2034 "te": { 2035 "interface-switching-capability": [ 2036 { 2037 "switching-capability": "switching-otn", 2038 "encoding": "lsp-encoding-oduk" 2039 } 2040 ] 2041 } 2042 }, 2043 { 2044 "tp-id": "7-7-0", 2045 "te-tp-id": 70700, 2046 "te": { 2047 "interface-switching-capability": [ 2048 { 2049 "switching-capability": "switching-otn", 2050 "encoding": "lsp-encoding-oduk" 2051 } 2052 ] 2053 } 2054 }, 2055 { 2056 "tp-id": "8-0-8", 2057 "te-tp-id": 80008, 2058 "te": { 2059 "interface-switching-capability": [ 2060 { 2061 "switching-capability": "switching-otn", 2062 "encoding": "lsp-encoding-oduk" 2063 } 2064 ] 2065 } 2066 }, 2067 { 2068 "tp-id": "8-8-0", 2069 "te-tp-id": 80800, 2070 "te": { 2071 "interface-switching-capability": [ 2072 { 2073 "switching-capability": "switching-otn", 2074 "encoding": "lsp-encoding-oduk" 2075 } 2076 ] 2077 } 2078 } 2079 ] 2080 } 2081 ] 2082 }, 2083 { 2084 "network-types": { 2085 "te-topology": {} 2086 }, 2087 "network-id": "abstract3", 2088 "provider-id": 201, 2089 "client-id": 600, 2090 "te-topology-id": "te-topology:abstract3", 2091 "node": [ 2092 { 2093 "node-id": "D3", 2094 "te-node-id": "3.0.1.1", 2095 "te": { 2096 "te-node-attributes": { 2097 "domain-id" : 3, 2098 "is-abstract": [null], 2099 "connectivity-matrices": { 2100 "is-allowed": true, 2101 "path-constraints": { 2102 "bandwidth-generic": { 2103 "te-bandwidth": { 2104 "generic": [ 2105 { 2106 "generic": "0x1p10", 2107 } 2109 ] 2110 } 2111 } 2112 }, 2113 "connectivity-matrix": [ 2114 { 2115 "id": 107, 2116 "from": "1-0-1", 2117 "to": "7-7-0" 2118 }, 2119 { 2120 "id": 308, 2121 "from": "3-0-3", 2122 "to": "8-8-0" 2123 }, 2124 ] 2125 } 2126 } 2127 }, 2128 "termination-point": [ 2129 { 2130 "tp-id": "1-0-1", 2131 "te-tp-id": 10001, 2132 "te": { 2133 "interface-switching-capability": [ 2134 { 2135 "switching-capability": "switching-otn", 2136 "encoding": "lsp-encoding-oduk" 2137 } 2138 ] 2139 } 2140 }, 2141 { 2142 "tp-id": "1-1-0", 2143 "te-tp-id": 10100, 2144 "te": { 2145 "interface-switching-capability": [ 2146 { 2147 "switching-capability": "switching-otn", 2148 "encoding": "lsp-encoding-oduk" 2149 } 2150 ] 2151 } 2152 }, 2153 { 2154 "tp-id": "2-0-2", 2155 "te-tp-id": 20002, 2156 "te": { 2157 "interface-switching-capability": [ 2158 { 2159 "switching-capability": "switching-otn", 2160 "encoding": "lsp-encoding-oduk" 2161 } 2162 ] 2163 } 2164 }, 2165 { 2166 "tp-id": "2-2-0", 2167 "te-tp-id": 20200, 2168 "te": { 2169 "interface-switching-capability": [ 2170 { 2171 "switching-capability": "switching-otn", 2172 "encoding": "lsp-encoding-oduk" 2173 } 2174 ] 2175 } 2176 }, 2177 { 2178 "tp-id": "3-0-3", 2179 "te-tp-id": 30003, 2180 "te": { 2181 "interface-switching-capability": [ 2182 { 2183 "switching-capability": "switching-otn", 2184 "encoding": "lsp-encoding-oduk" 2185 } 2186 ] 2187 } 2188 }, 2189 { 2190 "tp-id": "3-3-0", 2191 "te-tp-id": 30300, 2192 "te": { 2193 "interface-switching-capability": [ 2194 { 2195 "switching-capability": "switching-otn", 2196 "encoding": "lsp-encoding-oduk" 2197 } 2198 ] 2199 } 2200 }, 2201 { 2202 "tp-id": "4-0-4", 2203 "te-tp-id": 40004, 2204 "te": { 2205 "interface-switching-capability": [ 2206 { 2207 "switching-capability": "switching-otn", 2208 "encoding": "lsp-encoding-oduk" 2209 } 2210 ] 2211 } 2212 }, 2213 { 2214 "tp-id": "4-4-0", 2215 "te-tp-id": 40400, 2216 "te": { 2217 "interface-switching-capability": [ 2218 { 2219 "switching-capability": "switching-otn", 2220 "encoding": "lsp-encoding-oduk" 2221 } 2222 ] 2223 } 2224 }, 2225 { 2226 "tp-id": "5-0-5", 2227 "te-tp-id": 50005, 2228 "te": { 2229 "interface-switching-capability": [ 2230 { 2231 "switching-capability": "switching-otn", 2232 "encoding": "lsp-encoding-oduk" 2233 } 2234 ] 2235 } 2236 }, 2237 { 2238 "tp-id": "5-5-0", 2239 "te-tp-id": 50500, 2240 "te": { 2241 "interface-switching-capability": [ 2242 { 2243 "switching-capability": "switching-otn", 2244 "encoding": "lsp-encoding-oduk" 2245 } 2246 ] 2247 } 2248 }, 2249 { 2250 "tp-id": "6-0-6", 2251 "te-tp-id": 60006, 2252 "te": { 2253 "interface-switching-capability": [ 2254 { 2255 "switching-capability": "switching-otn", 2256 "encoding": "lsp-encoding-oduk" 2257 } 2258 ] 2259 } 2260 }, 2261 { 2262 "tp-id": "6-6-0", 2263 "te-tp-id": 60600, 2264 "te": { 2265 "interface-switching-capability": [ 2266 { 2267 "switching-capability": "switching-otn", 2268 "encoding": "lsp-encoding-oduk" 2269 } 2270 ] 2271 } 2272 }, 2273 { 2274 "tp-id": "7-0-7", 2275 "te-tp-id": 70007, 2276 "te": { 2277 "interface-switching-capability": [ 2278 { 2279 "switching-capability": "switching-otn", 2280 "encoding": "lsp-encoding-oduk" 2281 } 2282 ] 2283 } 2284 }, 2285 { 2286 "tp-id": "7-7-0", 2287 "te-tp-id": 70700, 2288 "te": { 2289 "interface-switching-capability": [ 2290 { 2291 "switching-capability": "switching-otn", 2292 "encoding": "lsp-encoding-oduk" 2293 } 2294 ] 2295 } 2296 }, 2297 { 2298 "tp-id": "8-0-8", 2299 "te-tp-id": 80008, 2300 "te": { 2301 "interface-switching-capability": [ 2302 { 2303 "switching-capability": "switching-otn", 2304 "encoding": "lsp-encoding-oduk" 2306 } 2307 ] 2308 } 2309 }, 2310 { 2311 "tp-id": "8-8-0", 2312 "te-tp-id": 80800, 2313 "te": { 2314 "interface-switching-capability": [ 2315 { 2316 "switching-capability": "switching-otn", 2317 "encoding": "lsp-encoding-oduk" 2318 } 2319 ] 2320 } 2321 } 2322 ] 2323 } 2324 ] 2325 }, 2326 ] 2327 } 2328 } 2330 8. Security Considerations 2332 The configuration, state, and action data defined in this document 2333 are designed to be accessed via a management protocol with a secure 2334 transport layer, such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 2335 The lowest NETCONF layer is the secure transport layer, and the 2336 mandatory-to-implement secure transport is Secure Shell (SSH) 2337 [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory- 2338 to-implement secure transport is TLS [RFC8446]. 2340 The NETCONF access control model [RFC8341] provides the means to 2341 restrict access for particular NETCONF users to a preconfigured 2342 subset of all available NETCONF protocol operations and content. 2344 The model presented in this document is used in the interface 2345 between the Customer Network Controller (CNC) and Multi-Domain 2346 Service Coordinator (MDSC), which is referred to as CNC-MDSC 2347 Interface (CMI). Therefore, many security risks such as malicious 2348 attack and rogue elements attempting to connect to various ACTN 2349 components. Furthermore, some ACTN components (e.g., MSDC) 2350 represent a single point of failure and threat vector and must also 2351 manage policy conflicts and eavesdropping of communication between 2352 different ACTN components. 2354 A number of configuration data nodes defined in this document are 2355 writable/deletable (i.e., "config true") These data nodes may be 2356 considered sensitive or vulnerable in some network environments. 2358 These are the subtrees and data nodes and their 2359 sensitivity/vulnerability: 2361 - access-point-list: 2362 o access-point-id 2363 o max-bandwidth 2364 o avl-bandwidth 2366 - vn-ap: 2367 o vn-ap-id 2368 o vn 2369 o abstract-node 2370 o ltp 2372 - vn-list 2373 o vn-id 2374 o vn-topology-id 2375 o abstract-node 2377 - vn-member-id 2378 o src 2379 o src-vn-ap-id 2380 o dest 2381 o dest-vn-ap-id 2382 o connectivity-matrix-id 2384 9. IANA Considerations 2386 This document registers the following namespace URIs in the IETF XML 2387 registry [RFC3688]: 2389 -------------------------------------------------------------------- 2390 URI: urn:ietf:params:xml:ns:yang:ietf-vn 2391 Registrant Contact: The IESG. 2392 XML: N/A, the requested URI is an XML namespace. 2393 -------------------------------------------------------------------- 2395 This document registers the following YANG modules in the YANG 2396 Module 2398 Names registry [RFC6020]: 2400 -------------------------------------------------------------------- 2401 name: ietf-vn 2402 namespace: urn:ietf:params:xml:ns:yang:ietf-vn 2403 reference: RFC XXXX (TDB) 2404 -------------------------------------------------------------------- 2406 10. Acknowledgments 2408 The authors would like to thank Xufeng Liu and Adrian Farrel for 2409 their helpful comments and valuable suggestions. 2411 11. References 2413 11.1. Normative References 2415 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work 2416 in progress: draft-ietf-teas-yang-te-topo. 2418 [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic 2419 Engineering Tunnels and Interfaces", work in progress: 2420 draft-ietf-teas-yang-te. 2422 11.2. Informative References 2424 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for 2425 Information Exchange between Interconnected Traffic- 2426 Engineered Networks", RFC 7926, July 2016. 2428 [RFC8453] D. Ceccarelli and Y. Lee (Editors), "Framework for 2429 Abstraction and Control of Traffic Engineered Networks", 2430 RFC 8453, August 2018. 2432 [TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering 2433 and Service Mapping Yang Model", draft-lee-teas-te- 2434 service-mapping-yang, work in progress. 2436 [ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance 2437 Monitoring Telemetry and Network Autonomics", draft-lee- 2438 teas-actn-pm-telemetry-autonomics, work in progress. 2440 [L1CSM] G. Fioccola, Ed. & Y. Lee, Ed., "A Yang Data Model for L1 2441 Connectivity Service Model (L1CSM)", draft-ietf-ccamp- 2442 l1csm-yang, work in progress. 2443 [L2SM] G. Fioccola, Ed., "A YANG Data Model for L2VPN Service 2444 Delivery", draft-ietf-l2sm-l2vpn-service-model, work in 2445 progress. 2447 [RFC8299] Q. Wu, Ed., S. Litkowski, L. Tomotaki, and K. Ogaki, "YANG 2448 Data Model for L3VPN Service Delivery", RFC 8299, January 2449 2018. 2451 [RFC8309] Q. Wu, W. Cheng, and A. Farrel. "Service Models 2452 Explained", RFC 8309, January 2018. 2454 [RFC8340] M. Bjorklund and L. Berger (Editors), "YANG Tree 2455 Diagrams", RFC 8340, March 2018. 2457 [RFC8345] A. Clemm, et al, "A YANG Data Model for Network 2458 Topologies", RFC 8345, March 2018. 2460 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 2461 and R. Wilton, "Network Management Datastore Architecture 2462 (NMDA)", RFC 8342, March 2018. 2464 12. Contributors 2466 Contributor's Addresses 2468 Haomian Zheng 2469 Huawei Technologies 2470 Email: zhenghaomian@huawei.com 2472 Xian Zhang 2473 Huawei Technologies 2474 Email: zhang.xian@huawei.com 2476 Sergio Belotti 2477 Nokia 2478 Email: sergio.belotti@nokia.com 2480 Takuya Miyasaka 2481 KDDI 2482 Email: ta-miyasaka@kddi.com 2484 Authors' Addresses 2486 Young Lee (ed.) 2487 Futurewei Technologies 2488 Email: younglee.tx@gmail.com 2490 Dhruv Dhody (ed.) 2491 Huawei Technologies 2492 Email: dhruv.ietf@gmail.com 2493 Daniele Ceccarelli 2494 Ericsson 2495 Torshamnsgatan,48 2496 Stockholm, Sweden 2497 Email: daniele.ceccarelli@ericsson.com 2499 Igor Bryskin 2500 Huawei 2501 Email: ibryskin@futurewei.com 2503 Bin Yeong Yoon 2504 ETRI 2505 Email: byyun@etri.re.kr 2507 Qin Wu 2508 Huawei Technologies 2509 Email: bill.wu@huawei.com 2511 Peter Park 2512 KT 2513 Email: peter.park@kt.com