idnits 2.17.1 draft-lee-teas-actn-vn-yang-11.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 18 instances of too long lines in the document, the longest one being 14 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 635 has weird spacing: '... "delay path ...' == Line 1072 has weird spacing: '... rpc vn-co...' -- The document date (February 27, 2018) is 2249 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: 'Service-YANG' is mentioned on line 103, but not defined == Missing Reference: 'TE-Topo' is mentioned on line 124, but not defined == Missing Reference: 'NMDA' is mentioned on line 132, but not defined == Missing Reference: 'ACTN-Frame' is mentioned on line 137, but not defined == Missing Reference: 'ACTN-FW' is mentioned on line 162, but not defined == Missing Reference: 'ACTN-INFO' is mentioned on line 395, but not defined == Unused Reference: 'TE-TOPO' is defined on line 2241, but no explicit reference was found in the text == Unused Reference: 'TE-tunnel' is defined on line 2244, but no explicit reference was found in the text == Unused Reference: 'ACTN-REQ' is defined on line 2254, but no explicit reference was found in the text == Unused Reference: 'ACTN-FWK' is defined on line 2258, but no explicit reference was found in the text == Unused Reference: 'OIF-VTNS' is defined on line 2274, but no explicit reference was found in the text 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 Dhruv Dhody 3 Intended Status: Standard Track Huawei 4 Expires: August 27, 2018 D. Ceccarelli 5 Ericsson 6 Takuya Miyasaka 7 KDDI 8 Peter Park 9 KT 10 Bin Yeong Yoon 11 ETRI 13 February 27, 2018 15 A Yang Data Model for ACTN VN Operation 17 draft-lee-teas-actn-vn-yang-11 19 Abstract 21 This document provides a YANG data model for the Abstraction and 22 Control of Traffic Engineered (TE) networks (ACTN) Virtual Network 23 Service (VNS) operation. 25 Status of this Memo 27 This Internet-Draft is submitted to IETF in full conformance with 28 the provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six 36 months and may be updated, replaced, or obsoleted by other documents 37 at any time. It is inappropriate to use Internet-Drafts as 38 reference material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html 46 This Internet-Draft will expire on August 27, 2018. 48 Copyright Notice 50 Copyright (c) 2018 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with 58 respect to this document. Code Components extracted from this 59 document must include Simplified BSD License text as described in 60 Section 4.e of the Trust Legal Provisions and are provided without 61 warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction...................................................3 66 1.1. Terminology...............................................4 67 2. ACTN CMI context...............................................4 68 2.1. Type 1 VN.................................................4 69 2.2. Type 2 VN.................................................5 70 3. High-Level Control Flows with Examples.........................6 71 3.1. Type 1 VN Illustration....................................6 72 3.2. Type 2 VN Illustration....................................7 73 4. Justification of the ACTN VN Model on the CMI.................10 74 4.1. Customer view of VN......................................10 75 4.2. Innovative Services......................................10 76 4.2.1. VN Compute..........................................10 77 4.2.2. Multi-sources and Multi-destinations................11 78 4.2.3. Others..............................................11 79 4.3. Summary..................................................12 80 5. ACTN VN YANG Model (Tree Structure)...........................12 81 6. ACTN-VN YANG Code.............................................15 82 7. JSON Example..................................................27 83 7.1. ACTN VN JSON.............................................28 84 7.2. TE-topology JSON.........................................33 85 8. Security Considerations.......................................49 86 9. IANA Considerations...........................................49 87 10. Acknowledgments..............................................50 88 11. References...................................................51 89 11.1. Normative References....................................51 90 11.2. Informative References..................................51 91 12. Contributors.................................................52 92 Authors' Addresses...............................................52 94 1. Introduction 96 This document provides a YANG data model for the Abstraction and 97 Control of Traffic Engineered (TE) networks (ACTN) Virtual Network 98 Service (VNS) operation that is going to be implemented for the 99 Customer Network Controller (CNC)- Multi-Domain Service Coordinator 100 (MSDC) interface (CMI). 102 The YANG model on the CMI is also known as customer service model in 103 [Service-YANG]. The YANG model discussed in this document is used to 104 operate customer-driven VNs during the VN computation, VN 105 instantiation and its life-cycle management and operations. 107 The YANG model discussed in this document basically provides the 108 following: 110 o Characteristics of Access Points (APs) that describe customer's 111 end point characteristics; 113 o Characteristics of Virtual Network Access Points (VNAP) that 114 describe How an AP is partitioned for multiple VNs sharing the AP 115 and its reference to a Link Termination Point (LTP) of the 116 Provider Edge (PE) Node; 118 o Characteristics of Virtual Networks (VNs) that describe the 119 customer's VNs in terms of VN Members comprising a VN, multi- 120 source and/or multi-destination characteristics of VN Member, the 121 VN's reference to TE-topology's Abstract Node; 123 The actual VN instantiation is performed with Connectivity Matrices 124 sub-module of TE-Topology Model [TE-Topo] which interacts with the 125 VN YANG module presented in this draft. 127 [Editor's Note: We need to add why TE-topology was chosen over TE- 128 tunnel model for the partnership with the VN model] 130 The ACTN VN operational state is included in the same tree as the 131 configuration consistent with Network Management Datastore 132 Architecture (NMDA) [NMDA]. The origin of the data is indicated as 133 per the origin metadata annotation. 135 1.1. Terminology 137 Refer to [ACTN-Frame] and [RFC7926] for the key terms used in this 138 document. 140 2. ACTN CMI context 142 The model presented in this document has the following ACTN context. 144 +-------+ 145 | CNC | 146 +-------+ 147 | 148 | VN YANG + TE-topology YANG 149 | 150 +-----------------------+ 151 | MDSC | 152 +-----------------------+ 154 Figure 1. ACTN CMI 156 Both ACTN VN YANG and TE-topology models are used over the CMI to 157 establish a VN over TE networks. 159 2.1. Type 1 VN 161 As defined in [ACTN-FW], a Virtual Network is a customer view of the 162 TE network. To recapitulate VN types from [ACTN-FW], Type 1 VN is 163 defined as follows: 165 The VN can be seen as a set of edge-to-edge links (a Type 1 VN). 166 Each link is referred as a VN member and is formed as an end-to-end 167 tunnel across the underlying networks. Such tunnels may be 168 constructed by recursive slicing or abstraction of paths in the 169 underlying networks and can encompass edge points of the customer's 170 network, access links, intra-domain paths, and inter-domain links. 172 If we were to create a VN where we have four VN-members as follows: 174 VN-Member 1 L1-L4 175 VN-Member 2 L1-L7 176 VN-Member 3 L2-L4 177 VN-Member 4 L3-L8 179 Where L1, L2, L3, L4, L7 and L8 correspond to a Customer 180 End-Point, respectively. 182 This VN can be modeled as one abstract node representation as 183 follows in Figure 2: 185 +---------------+ 186 L1 ------| |------ L4 187 L2 ------| AN 1 |------ L7 188 L3 ------| |------ L8 189 +---------------+ 191 Figure 2. Abstract Node (One node topology) 193 2.2. Type 2 VN 195 For some VN members of a VN, the customers are allowed to configure 196 the actual path (i.e., detailed virtual nodes and virtual links) 197 over the VN/abstract topology agreed mutually between CNC and MDSC 198 prior to or a topology created by the MDSC as part of VN 199 instantiation. Type 2 VN is always built on top of a Type 1 VN. 201 If a Type 2 VN is desired for some or all of VN members of a type 1 202 VN (see the example in Section 2.1), the TE-topology model can 203 provide the following abstract topology (that consists of virtual 204 nodes and virtual links) which is built on top of the Type 1 VN. 206 +----------------------------------------------+ 207 | S1 S2 | 208 | O---------------O | 209 | ________/ \______ \ | 210 | / \ \ | 211 |S3 / \ S4 \ S5 | 212 L1----|-O----------------------O---------O-----------|------L4 213 | \ \ \ | 214 | \ \ \ | 215 | \ S6 \ S7 \ S8 | 216 | O ----------------O---------O-------|------L7 217 | / \ / \ ____/ | 218 |S9 / \ /S10 \ / | 219 L2-----|---O-----O---------------------O--------------|------L8 220 | / S11 | 221 L3-----|-- | 222 | | 223 +----------------------------------------------+ 225 Figure 3. Type 2 topology 227 As you see from Figure 3, the Type 1 abstract node is depicted as a 228 Type 1 abstract topology comprising of detailed virtual nodes and 229 virtual links. 231 As an example, if VN-member 1 (L1-L4) is chosen to configure its own 232 path over Type 2 topology, it can select, say, a path that consists 233 of the ERO {S3,S4,S5} based on the topology and its service 234 requirement. This capability is enacted via TE-topology 235 configuration by the customer. 237 3. High-Level Control Flows with Examples 239 3.1. Type 1 VN Illustration 241 If we were to create a VN where we have four VN-members as follows: 243 VN-Member 1 L1-L4 244 VN-Member 2 L1-L7 245 VN-Member 3 L2-L4 246 VN-Member 4 L3-L8 248 Where L1, L2, L3, L4, L7 and L8 correspond to Customer End-Point, 249 respectively. 251 This VN can be modeled as one abstract node representation as 252 follows: 254 +---------------+ 255 L1 ------| |------ L4 256 L2 ------| AN 1 |------ L7 257 L3 ------| |------ L8 258 +---------------+ 260 If this VN is Type 1, the following diagram shows the message flow 261 between CNC and MDSC to instantiate this VN using ACTN VN and TE- 262 Topology Model. 264 +--------+ +--------+ 265 | CNC | | MDSC | 266 +--------+ +--------+ 267 | | 268 | | 269 CNC POST TE-topo | POST /nw:networks/nw:network/ | 270 model(with Conn. | nw:node/te-node-id/tet:connectivity- | 271 Matrix on one | matrices/tet:connectivity-matrix | 272 Abstract node |---------------------------------------->| 273 | HTTP 200 | 274 |<----------------------------------------| 275 | | 276 CNC POST the ACTN| POST /ACTN VN | 277 VN identifying |---------------------------------------->| If there is 278 AP, VNAP and VN- | | multi-dest'n 279 Members and maps | | module, then 280 to the TE-topo | HTTP 200 | MDSC selects a 281 |<----------------------------------------| src or dest'n 282 | | and update 283 | | ACTN VN YANG 284 CNC GET the ACTN | GET /ACTN VN | 285 VN YANG status |---------------------------------------->| 286 | | 287 | HTTP 200 (ACTN VN with status: selected| 288 | VN-members in case of multi s-d | 289 |<----------------------------------------| 290 | | 292 3.2. Type 2 VN Illustration 294 For some VN members, the customer may want to "configure" explicit 295 routes over the path that connects its two end-points. Let us 296 consider the following example. 298 VN-Member 1 L1-L4 300 VN-Member 2 L1-L7 (via S4 and S7) 302 VN-Member 3 L2-L4 304 VN-Member 4 L3-L8 (via S10) 306 Where the following topology is the underlay for Abstraction Node 1 307 (AN1). 309 S1 S2 310 O---------------O 311 ________/ \______ \ 312 / \ \ 313 S3 / \ S4 \ S5 314 L1------O----------------------O---------O------------------L4 315 \ \ \ 316 \ \ \ 317 \ S6 \ S7 \ S8 318 O ----------------O---------O--------------L5 319 / \ / \ ____/ \_____________L6 320 S9 / \ /S10 \ / 321 L2---------O-----O---------------------O---------------------L7 322 / S11\____________________L8 323 L3-------- 325 If CNC creates the single abstract topology, the following diagram 326 shows the message flow between CNC and MDSC to instantiate this VN 327 using ACTN VN and TE-Topology Model. 329 +--------+ +--------+ 330 | CNC | | MDSC | 331 +--------+ +--------+ 332 | | 333 | | 334 CNC POST TE-topo | POST /nw:networks/nw:network/ | 335 model(with Conn. | nw:node/te-node-id/tet:connectivity- | 336 Matrix on one | matrices/tet:connectivity-matrix | 337 Abstract node and|---------------------------------------->| 338 Explicit paths in| | 339 The conn. Matrix | HTTP 200 | 340 |<----------------------------------------| 341 | | 342 CNC POST the ACTN| POST /ACTN VN | 343 VN identifying |---------------------------------------->| 344 AP, VNAP and VN- | | 345 Members and maps | | 346 to the TE-topo | HTTP 200 | 347 |<----------------------------------------| 348 | | 349 | | 350 CNC GET the ACTN | GET /ACTN VN | 351 VN YANG status |---------------------------------------->| 352 | | 353 | HTTP 200 (ACTN VN with status) | 354 |<----------------------------------------| 355 | | 357 On the other hand, if MDSC create single node topology based ACTN VN 358 YANG posted by the CNC, the following diagram shows the message flow 359 between CNC and MDSC to instantiate this VN using ACTN VN and TE- 360 Topology Model. 362 +--------+ +--------+ 363 | CNC | | MDSC | 364 +--------+ +--------+ 365 | | 366 | | 367 CNC POST ACTN VN | | 368 Identifying AP, | | 369 VNAP and VN- | POST /ACTN VN | MDSC populates 370 Members |---------------------------------------->| a single Abst. 371 | HTTP 200 | node topology 372 |<----------------------------------------| by itself 373 | | 374 CNC POST the ACTN| POST /ACTN VN | 375 VN identifying |---------------------------------------->| 376 AP, VNAP and VN- | | 377 Members and maps | | 378 to the TE-topo | HTTP 200 | 379 |<----------------------------------------| 380 | | 381 | | 382 CNC GET the ACTN | GET /ACTN VN | 383 VN YANG status |---------------------------------------->| 384 | | 385 | HTTP 200 (ACTN VN with status) | 386 |<----------------------------------------| 387 | | 389 4. Justification of the ACTN VN Model on the CMI. 391 4.1. Customer view of VN 393 The VN-Yang model allows to define a customer view, and allows the 394 customer to communicate using the VN constructs as described in the 395 [ACTN-INFO]. It also allows to group the set of edge-to-edge links 396 (i.e., VN members) under a common umbrella of VN. This allows the 397 customer to instantiate and view the VN as one entity, making it 398 easier for some customers to work on VN without worrying about the 399 details of the provider based YANG models. 401 This is similar to the benefits of having a separate YANG model for 402 the customer services as described in [SERVICE-YANG], which states 403 that service models do not make any assumption of how a service is 404 actually engineered and delivered for a customer. 406 4.2. Innovative Services 408 4.2.1. VN Compute 410 ACTN VN supports VN compute (pre-instantiation mode) to view the 411 full VN as a single entity before instantiation. Achieving this via 412 path computation or "compute only" tunnel setup does not provide the 413 same functionality. 415 4.2.2. Multi-sources and Multi-destinations 417 In creating a virtual network, the list of sources or destinations 418 or both may not be pre-determined by the customer. For instance, for 419 a given source, there may be a list of multiple-destinations to 420 which the optimal destination may be chosen depending on the network 421 resource situations. Likewise, for a given destination, there may 422 also be multiple-sources from which the optimal source may be 423 chosen. In some cases, there may be a pool of multiple sources and 424 destinations from which the optimal source-destination may be 425 chosen. The following YANG module is shown for describing source 426 container and destination container. The following YANG tree shows 427 how to model multi-sources and multi-destinations. 429 +--rw actn 430 . . . 431 +--rw vn 432 +--rw vn-list* [vn-id] 433 +--rw vn-id uint32 434 +--rw vn-name? string 435 +--rw vn-topology-id? te-types:te-topology-id 436 +--rw abstract-node? -> /nw:networks/network/node/tet:te-node-id 437 +--rw vn-member-list* [vn-member-id] 438 | +--rw vn-member-id uint32 439 | +--rw src 440 | | +--rw src? -> /actn/ap/access-point-list/access-point-id 441 | | +--rw src-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 442 | | +--rw multi-src? boolean {multi-src-dest}? 443 | +--rw dest 444 | | +--rw dest? -> /actn/ap/access-point-list/access-point- 445 id 446 | | +--rw dest-vn-ap-id? -> /actn/ap/access-point-list/vn-ap/vn-ap-id 447 | | +--rw multi-dest? boolean {multi-src-dest}? 448 | +--rw connetivity-matrix-id? -> /nw:networks/network/node/tet:te/te- 449 node-attributes/connectivity-matrices/connectivity-matrix/id 450 | +--ro oper-status? identityref 451 +--ro if-selected? boolean {multi-src-dest}? 452 +--rw admin-status? identityref 453 +--ro oper-status? identityref 454 +--rw vn-level-diversity? vn-disjointness 456 4.2.3. Others 458 The VN Yang model can be easily augmented to support the mapping of 459 VN to the Services such as L3SM and L2SM as described in [TE-MAP]. 461 The VN Yang model can be extended to support telemetry, performance 462 monitoring and network autonomics as described in [ACTN-PM]. 464 4.3. Summary 466 This section summarizes the innovative service features of the ACTN 467 VN Yang. 469 o Maintenance of AP and VNAP along with VN. 471 o VN construct to group of edge-to-edge links 473 o VN Compute (pre-instantiate) 475 o Multi-Source / Multi-Destination 477 o Ability to support various VN and VNS Types 479 * VN Type 1: Customer configures the VN as a set of VN 480 Members. 481 No other details need to be set by customer, making for a 482 simplified operations for the customer. 484 * VN Type 2: Along with VN Members, the customer could also 485 provide an abstract topology, this topology is provided by 486 the Abstract TE Topology Yang Model. 488 5. ACTN VN YANG Model (Tree Structure) 490 module: ietf-actn-vn 491 +--rw actn 492 +--rw ap 493 | +--rw access-point-list* [access-point-id] 494 | +--rw access-point-id uint32 495 | +--rw access-point-name? string 496 | +--rw max-bandwidth? te-types:te-bandwidth 497 | +--rw avl-bandwidth? te-types:te-bandwidth 498 | +--rw vn-ap* [vn-ap-id] 499 | +--rw vn-ap-id uint32 500 | +--rw vn? -> /actn/vn/vn-list/vn-id 501 | +--rw abstract-node? -> 502 /nw:networks/network/node/tet:te-node-id 503 | +--rw ltp? te-types:te-tp-id 504 +--rw vn 505 +--rw vn-list* [vn-id] 506 +--rw vn-id uint32 507 +--rw vn-name? string 508 +--rw vn-topology-id? te-types:te-topology-id 509 +--rw abstract-node? -> 510 /nw:networks/network/node/tet:te-node-id 511 +--rw vn-member-list* [vn-member-id] 512 | +--rw vn-member-id uint32 513 | +--rw src 514 | | +--rw src? -> /actn/ap/access-point- 515 list/access-point-id 516 | | +--rw src-vn-ap-id? -> /actn/ap/access-point- 517 list/vn-ap/vn-ap-id 518 | | +--rw multi-src? boolean {multi-src-dest}? 519 | +--rw dest 520 | | +--rw dest? -> /actn/ap/access-point- 521 list/access-point-id 522 | | +--rw dest-vn-ap-id? -> /actn/ap/access-point- 523 list/vn-ap/vn-ap-id 524 | | +--rw multi-dest? boolean {multi-src-dest}? 525 | +--rw connetivity-matrix-id? -> 526 /nw:networks/network/node/tet:te/te-node-attributes/connectivity- 527 matrices/connectivity-matrix/id 528 | +--ro oper-status? identityref 529 +--ro if-selected? boolean {multi-src-dest}? 530 +--rw admin-status? identityref 531 +--ro oper-status? identityref 532 +--rw vn-level-diversity? vn-disjointness 534 rpcs: 535 +---x vn-compute 536 +---w input 537 | +---w abstract-node? -> 538 /nw:networks/network/node/tet:te-node-id 539 | +---w vn-member-list* [vn-member-id] 540 | | +---w vn-member-id uint32 541 | | +---w src 542 | | | +---w src? -> /actn/ap/access-point- 543 list/access-point-id 544 | | | +---w src-vn-ap-id? -> /actn/ap/access-point- 545 list/vn-ap/vn-ap-id 546 | | | +---w multi-src? boolean {multi-src-dest}? 547 | | +---w dest 548 | | | +---w dest? -> /actn/ap/access-point- 549 list/access-point-id 550 | | | +---w dest-vn-ap-id? -> /actn/ap/access-point- 551 list/vn-ap/vn-ap-id 552 | | | +---w multi-dest? boolean {multi-src-dest}? 553 | | +---w connetivity-matrix-id? -> 554 /nw:networks/network/node/tet:te/te-node-attributes/connectivity- 555 matrices/connectivity-matrix/id 556 | +---w vn-level-diversity? vn-disjointness 557 +--ro output 558 +--ro vn-member-list* [vn-member-id] 559 +--ro vn-member-id uint32 560 +--ro src 561 | +--ro src? -> /actn/ap/access-point- 562 list/access-point-id 563 | +--ro src-vn-ap-id? -> /actn/ap/access-point- 564 list/vn-ap/vn-ap-id 565 | +--ro multi-src? boolean {multi-src-dest}? 566 +--ro dest 567 | +--ro dest? -> /actn/ap/access-point- 568 list/access-point-id 569 | +--ro dest-vn-ap-id? -> /actn/ap/access-point- 570 list/vn-ap/vn-ap-id 571 | +--ro multi-dest? boolean {multi-src-dest}? 572 +--ro connetivity-matrix-id? -> 573 /nw:networks/network/node/tet:te/te-node-attributes/connectivity- 574 matrices/connectivity-matrix/id 575 +--ro if-selected? boolean {multi-src- 576 dest}? 577 +--ro compute-status? identityref 579 6. ACTN-VN YANG Code 581 The YANG code is as follows: 583 file "ietf-actn-vn@2018-02-27.yang" 585 module ietf-actn-vn { 586 namespace "urn:ietf:params:xml:ns:yang:ietf-actn-vn"; 587 prefix "vn"; 589 /* Import network */ 590 import ietf-network { 591 prefix "nw"; 592 } 594 /* Import TE generic types */ 595 import ietf-te-types { 596 prefix "te-types"; 597 } 599 /* Import Abstract TE Topology */ 600 import ietf-te-topology { 601 prefix "tet"; 602 } 604 organization 605 "IETF Traffic Engineering Architecture and Signaling (TEAS) 606 Working Group"; 607 contact 608 "Editor: Young Lee 609 : Dhruv Dhody "; 610 description 611 "This module contains a YANG module for the ACTN VN. It 612 describes a VN operation module that takes place in the 613 context of the CNC-MDSC Interface (CMI) of the ACTN 614 architecture where the CNC is the actor of a VN 615 Instantiation/modification /deletion."; 616 revision 2018-02-27 { 617 description 618 "initial version."; 619 reference 620 "TBD"; 622 } 623 /* 624 * Features 625 */ 626 feature multi-src-dest { 627 description 628 "Support for selection of one src or destination 629 among multiple."; 630 } 632 /*identity path-metric-delay { 633 base te-types:path-metric-type; 634 description 635 "delay path metric"; 636 } 637 identity path-metric-delay-variation { 638 base te-types:path-metric-type; 639 description 640 "delay-variation path metric"; 641 } 642 identity path-metric-loss { 643 base te-types:path-metric-type; 644 description 645 "loss path metric"; 646 }*/ 648 identity vn-state-type { 649 description 650 "Base identity for VN state"; 651 } 652 identity vn-state-up { 653 base vn-state-type; 654 description "VN state up"; 655 } 656 identity vn-state-down { 657 base vn-state-type; 658 description "VN state down"; 659 } 660 identity vn-admin-state-type { 661 description 662 "Base identity for VN admin states"; 663 } 664 identity vn-admin-state-up { 665 base vn-admin-state-type; 666 description "VN administratively state up"; 668 } 669 identity vn-admin-state-down { 670 base vn-admin-state-type; 671 description "VN administratively state down"; 672 } 673 identity vn-compute-state-type { 674 description 675 "Base identity for compute states"; 676 } 677 identity vn-compute-state-computing { 678 base vn-compute-state-type; 679 description 680 "State path compute in progress"; 681 } 682 identity vn-compute-state-computation-ok { 683 base vn-compute-state-type; 684 description 685 "State path compute successful"; 686 } 687 identity vn-compute-state-computatione-failed { 688 base vn-compute-state-type; 689 description 690 "State path compute failed"; 691 } 692 /* 693 * Groupings 694 */ 696 typedef vn-disjointness { 697 type bits { 698 bit node { 699 position 0; 700 description "node disjoint"; 701 } 702 bit link { 703 position 1; 704 description "link disjoint"; 705 } 706 bit srlg { 707 position 2; 708 description "srlg disjoint"; 709 } 710 } 711 description 712 "type of the resource disjointness for 713 VN level applied across all VN members 714 in a VN"; 715 } 717 grouping vn-ap { 718 description 719 "VNAP related information"; 720 leaf vn-ap-id { 721 type uint32; 722 description 723 "unique identifier for the referred 724 VNAP"; 725 } 726 leaf vn { 727 type leafref { 728 path "/actn/vn/vn-list/vn-id"; 729 } 730 description 731 "reference to the VN"; 732 } 733 leaf abstract-node { 734 type leafref { 735 path "/nw:networks/nw:network/nw:node/" 736 + "tet:te-node-id"; 737 } 738 description 739 "a reference to the abstract node in TE 740 Topology"; 741 } 742 leaf ltp { 743 type te-types:te-tp-id; 744 description 745 "Reference LTP in the TE-topology"; 746 } 747 } 748 grouping access-point{ 749 description 750 "AP related information"; 751 leaf access-point-id { 752 type uint32; 753 description 754 "unique identifier for the referred 755 access point"; 756 } 757 leaf access-point-name { 758 type string; 759 description 760 "ap name"; 761 } 763 leaf max-bandwidth { 764 type te-types:te-bandwidth; 765 description 766 "max bandwidth of the AP"; 767 } 768 leaf avl-bandwidth { 769 type te-types:te-bandwidth; 770 description 771 "available bandwidth of the AP"; 772 } 773 /*add details and any other properties of AP, 774 not associated by a VN 775 CE port, PE port etc. 776 */ 777 list vn-ap { 778 key vn-ap-id; 779 uses vn-ap; 780 description 781 "list of VNAP in this AP"; 782 } 783 }//access-point 784 grouping vn-member { 785 description 786 "vn-member is described by this container"; 787 leaf vn-member-id { 788 type uint32; 789 description 790 "vn-member identifier"; 791 } 792 container src 793 { 794 description 795 "the source of VN Member"; 796 leaf src { 797 type leafref { 798 path "/actn/ap/access-point-list/access-point-id"; 799 } 800 description 801 "reference to source AP"; 802 } 803 leaf src-vn-ap-id{ 804 type leafref { 805 path "/actn/ap/access-point-list/vn-ap/vn-ap-id"; 806 } 807 description 808 "reference to source VNAP"; 809 } 810 leaf multi-src { 811 if-feature multi-src-dest; 812 type boolean; 813 description 814 "Is source part of multi-source, where 815 only one of the source is enabled"; 816 } 817 } 818 container dest 819 { 820 description 821 "the destination of VN Member"; 822 leaf dest { 823 type leafref { 824 path "/actn/ap/access-point-list/access-point-id"; 825 } 826 description 827 "reference to destination AP"; 828 } 829 leaf dest-vn-ap-id{ 830 type leafref { 831 path "/actn/ap/access-point-list/vn-ap/vn-ap-id"; 832 } 833 description 834 "reference to dest VNAP"; 835 } 836 leaf multi-dest { 837 if-feature multi-src-dest; 838 type boolean; 839 description 840 "Is destination part of multi-destination, where 841 only one of the destination is enabled"; 842 } 843 } 844 leaf connetivity-matrix-id{ 845 type leafref { 846 path "/nw:networks/nw:network/nw:node/tet:te/" 847 + "tet:te-node-attributes/" 848 + "tet:connectivity-matrices/" 849 + "tet:connectivity-matrix/tet:id"; 850 } 851 description 852 "reference to connetivity-matrix"; 853 } 854 }//vn-member 855 /* 856 grouping policy { 857 description 858 "policy related to vn-member-id"; 859 leaf local-reroute { 860 type boolean; 861 description 862 "Policy to state if reroute 863 can be done locally"; 864 } 865 leaf push-allowed { 866 type boolean; 867 description 868 "Policy to state if changes 869 can be pushed to the customer"; 870 } 871 leaf incremental-update { 872 type boolean; 873 description 874 "Policy to allow only the 875 changes to be reported"; 876 } 877 }//policy 878 */ 879 grouping vn-policy { 880 description 881 "policy for VN-level diverisity"; 882 leaf vn-level-diversity { 883 type vn-disjointness; 884 description 885 "the type of disjointness on the VN level 886 (i.e., across all VN members)"; 887 } 888 } 889 /* 890 grouping metrics-op { 891 description 892 "metric related information"; 894 list metric{ 895 key "metric-type"; 896 config false; 897 description 898 "The list of metrics for VN"; 899 leaf metric-type { 900 type identityref { 901 base te-types:path-metric-type; 902 } 903 description 904 "The VN metric type."; 905 } 906 leaf value{ 907 type uint32; 908 description 909 "The limit value"; 910 } 911 } 912 } 913 */ 914 /* 915 grouping metrics { 916 description 917 "metric related information"; 918 list metric{ 919 key "metric-type"; 920 description 921 "The list of metrics for VN"; 922 uses te:path-metrics-bounds_config; 923 container optimize{ 924 description 925 "optimizing constraints"; 926 leaf enabled{ 927 type boolean; 928 description 929 "Metric to optimize"; 930 } 931 leaf value{ 932 type uint32; 933 description 934 "The computed value"; 935 } 936 } 937 } 938 } 939 */ 940 /* 941 grouping service-metric { 942 description 943 "service-metric"; 944 uses te:path-objective-function_config; 945 uses metrics; 946 uses te-types:common-constraints_config; 947 uses te:protection-restoration-params_config; 948 uses policy; 949 }//service-metric 950 */ 951 /* 952 * Configuration data nodes 953 */ 954 container actn { 955 description 956 "actn is described by this container"; 957 container ap { 958 description 959 "AP configurations"; 960 list access-point-list { 961 key "access-point-id"; 962 description 963 "access-point identifier"; 964 uses access-point{ 965 description 966 "access-point information"; 967 } 968 } 969 } 970 container vn { 971 description 972 "VN configurations"; 973 list vn-list { 974 key "vn-id"; 975 description 976 "a virtual network is identified by a vn-id"; 977 leaf vn-id { 978 type uint32; 979 description 980 "a unique vn identifier"; 981 } 982 leaf vn-name { 983 type string; 984 description "vn name"; 985 } 986 leaf vn-topology-id{ 987 type te-types:te-topology-id; 988 description 989 "An optional identifier to the TE Topology 990 Model where the abstract nodes and links 991 of the Topology can be found for Type 2 992 VNS"; 993 } 994 leaf abstract-node { 995 type leafref { 996 path "/nw:networks/nw:network/nw:node/" 997 + "tet:te-node-id"; 998 } 999 description 1000 "a reference to the abstract node in TE 1001 Topology"; 1002 } 1003 list vn-member-list{ 1004 key "vn-member-id"; 1005 description 1006 "List of VN-members in a VN"; 1007 uses vn-member; 1008 /*uses metrics-op;*/ 1009 leaf oper-status { 1010 type identityref { 1011 base vn-state-type; 1012 } 1013 config false; 1014 description 1015 "VN-member operational state."; 1016 } 1018 } 1019 leaf if-selected{ 1020 if-feature multi-src-dest; 1021 type boolean; 1022 default false; 1023 config false; 1024 description 1025 "Is the vn-member is selected among the 1026 multi-src/dest options"; 1027 } 1028 /* 1029 container multi-src-dest{ 1030 if-feature multi-src-dest; 1031 config false; 1032 description 1033 "The selected VN Member when multi-src 1034 and/or mult-destination is enabled."; 1035 leaf selected-vn-member{ 1036 type leafref { 1037 path "/actn/vn/vn-list/vn-member-list" 1038 + "/vn-member-id"; 1039 } 1040 description 1041 "The selected VN Member along the set 1042 of source and destination configured 1043 with multi-source and/or multi-destination"; 1044 } 1045 } 1046 */ 1047 /*uses service-metric;*/ 1048 leaf admin-status { 1049 type identityref { 1050 base vn-admin-state-type; 1051 } 1052 default vn-admin-state-up; 1053 description "VN administrative state."; 1054 } 1055 leaf oper-status { 1056 type identityref { 1057 base vn-state-type; 1058 } 1059 config false; 1060 description "VN operational state."; 1061 } 1062 uses vn-policy; 1063 }//vn-list 1064 }//vn 1065 }//actn 1066 /* 1067 * Notifications - TBD 1068 */ 1069 /* 1070 * RPC 1071 */ 1072 rpc vn-compute{ 1073 description 1074 "The VN computation without actual 1075 instantiation"; 1076 input { 1077 leaf abstract-node { 1078 type leafref { 1079 path "/nw:networks/nw:network/nw:node/" 1080 + "tet:te-node-id"; 1081 } 1082 description 1083 "a reference to the abstract node in TE 1084 Topology"; 1085 } 1086 list vn-member-list{ 1087 key "vn-member-id"; 1088 description 1089 "List of VN-members in a VN"; 1090 uses vn-member; 1091 } 1092 uses vn-policy; 1093 /*uses service-metric;*/ 1094 } 1095 output { 1096 list vn-member-list{ 1097 key "vn-member-id"; 1098 description 1099 "List of VN-members in a VN"; 1100 uses vn-member; 1101 leaf if-selected{ 1102 if-feature multi-src-dest; 1103 type boolean; 1104 default false; 1105 description 1106 "Is the vn-member is selected among 1107 the multi-src/dest options"; 1108 } 1109 /*uses metrics-op;*/ 1110 leaf compute-status { 1111 type identityref { 1112 base vn-compute-state-type; 1113 } 1114 description 1115 "VN-member compute state."; 1116 } 1117 } 1118 /* 1119 container multi-src-dest{ 1120 if-feature multi-src-dest; 1121 description 1122 "The selected VN Member when multi-src 1123 and/or mult-destination is enabled."; 1124 leaf selected-vn-member-id{ 1125 type uint32; 1126 description 1127 "The selected VN Member-id from the 1128 input"; 1129 } 1130 }*/ 1131 } 1132 } 1133 } 1135 1137 7. JSON Example 1139 This section provides json implementation examples as to how ACTN VN 1140 YANG model and TE topology model are used together to instantiate 1141 virtual networks. 1143 The example in this section includes following VN 1145 o VN1 (Type 1): Which maps to the single node topology abstract1 1146 (node D1) and consist of VN Members 104 (L1 to L4), 107 (L1 to 1147 L7), 204 (L2 to L4), 308 (L3 to L8) and 108 (L1 to L8). We also 1148 show how disjointness (node, link, srlg) is supported in the 1149 example on the global level (i.e., connectivity matrices level). 1151 o VN2 (Type 2): Which maps to the single node topology abstract2 1152 (node D2), this topology has an underlay topology (absolute) (see 1153 figure in section 3.2). This VN has a single VN member 105 (L1 to 1154 L5) and an underlay path (S4 and S7) has been set in the 1155 connectivity matrix of abstract2 topology; 1157 o VN3 (Type 1): This VN has a multi-source, multi-destination 1158 feature enable for VN Member 104 (L1 to L4)/107 (L1 to L7) 1159 [multi-src] and VN Member 204 (L2 to L4)/304 (L3 to L4) [multi- 1160 dest] usecase. The selected VN-member is known via the field "if- 1161 selected" and the corresponding connectivity-matrix-id. 1163 Note that the ACTN VN YANG model also include the AP and VNAP which 1164 shows various VN using the same AP. 1165 7.1. ACTN VN JSON 1167 { 1168 "actn":{ 1169 "ap":{ 1170 "access-point-list": [ 1171 { 1172 "access-point-id": 101, 1173 "access-point-name": "101", 1174 "vn-ap": [ 1175 { 1176 "vn-ap-id": 10101, 1177 "vn": 1, 1178 "abstract-node": "D1", 1179 "ltp": "1-0-1" 1180 }, 1181 { 1182 "vn-ap-id": 10102, 1183 "vn": 2, 1184 "abstract-node": "D2", 1185 "ltp": "1-0-1" 1186 }, 1187 { 1188 "vn-ap-id": 10103, 1189 "vn": 3, 1190 "abstract-node": "D3", 1191 "ltp": "1-0-1" 1192 }, 1193 ] 1194 }, 1195 { 1196 "access-point-id": 202, 1197 "access-point-name": "202", 1198 "vn-ap": [ 1199 { 1200 "vn-ap-id": 20201, 1201 "vn": 1, 1202 "abstract-node": "D1", 1203 "ltp": "2-0-2" 1204 } 1206 ] 1207 }, 1208 { 1209 "access-point-id": 303, 1210 "access-point-name": "303", 1211 "vn-ap": [ 1212 { 1213 "vn-ap-id": 30301, 1214 "vn": 1, 1215 "abstract-node": "D1", 1216 "ltp": "3-0-3" 1217 }, 1218 { 1219 "vn-ap-id": 30303, 1220 "vn": 3, 1221 "abstract-node": "D3", 1222 "ltp": "3-0-3" 1223 } 1224 ] 1225 }, 1226 { 1227 "access-point-id": 440, 1228 "access-point-name": "440", 1229 "vn-ap": [ 1230 { 1231 "vn-ap-id": 44001, 1232 "vn": 1, 1233 "abstract-node": "D1", 1234 "ltp": "4-4-0" 1235 } 1236 ] 1237 }, 1238 { 1239 "access-point-id": 550, 1240 "access-point-name": "550", 1241 "vn-ap": [ 1242 { 1243 "vn-ap-id": 55002, 1244 "vn": 2, 1245 "abstract-node": "D2", 1246 "ltp": "5-5-0" 1247 } 1248 ] 1249 }, 1250 { 1251 "access-point-id": 770, 1252 "access-point-name": "770", 1253 "vn-ap": [ 1254 { 1255 "vn-ap-id": 77001, 1256 "vn": 1, 1257 "abstract-node": "D1", 1258 "ltp": "7-7-0" 1259 }, 1260 { 1261 "vn-ap-id": 77003, 1262 "vn": 3, 1263 "abstract-node": "D3", 1264 "ltp": "7-7-0" 1265 } 1266 ] 1267 }, 1268 { 1269 "access-point-id": 880, 1270 "access-point-name": "880", 1271 "vn-ap": [ 1272 { 1273 "vn-ap-id": 88001, 1274 "vn": 1, 1275 "abstract-node": "D1", 1276 "ltp": "8-8-0" 1277 }, 1278 { 1279 "vn-ap-id": 88003, 1280 "vn": 3, 1281 "abstract-node": "D3", 1282 "ltp": "8-8-0" 1283 } 1284 ] 1285 } 1286 ] 1287 }, 1288 "vn":{ 1289 "vn-list": [ 1290 { 1291 "vn-id": 1, 1292 "vn-name": "vn1", 1293 "vn-topology-id": "te-topology:abstract1", 1294 "abstract-node": "D1", 1295 "vn-member-list": [ 1296 { 1297 "vn-member-id": 104, 1298 "src": { 1299 "src": 101, 1300 "src-vn-ap-id": 10101, 1301 }, 1302 "dest": { 1303 "dest": 440, 1304 "dest-vn-ap-id": 44001, 1305 }, 1306 "connectivity-matrix-id": 104 1307 }, 1308 { 1309 "vn-member-id": 107, 1310 "src": { 1311 "src": 101, 1312 "src-vn-ap-id": 10101, 1313 }, 1314 "dest": { 1315 "dest": 770, 1316 "dest-vn-ap-id": 77001, 1317 }, 1318 "connectivity-matrix-id": 107 1319 }, 1320 { 1321 "vn-member-id": 204, 1322 "src": { 1323 "src": 202, 1324 "dest-vn-ap-id": 20401, 1325 }, 1326 "dest": { 1327 "dest": 440, 1328 "dest-vn-ap-id": 44001, 1329 }, 1330 "connectivity-matrix-id": 204 1331 }, 1332 { 1333 "vn-member-id": 308, 1334 "src": { 1335 "src": 303, 1336 "src-vn-ap-id": 30301, 1337 }, 1338 "dest": { 1339 "dest": 880, 1340 "src-vn-ap-id": 88001, 1341 }, 1342 "connectivity-matrix-id": 308 1343 }, 1344 { 1345 "vn-member-id": 108, 1346 "src": { 1347 "src": 101, 1348 "src-vn-ap-id": 10101, 1349 }, 1350 "dest": { 1351 "dest": 880, 1352 "dest-vn-ap-id": 88001, 1354 }, 1355 "connectivity-matrix-id": 108 1356 } 1357 ] 1358 }, 1359 { 1360 "vn-id": 2, 1361 "vn-name": "vn2", 1362 "vn-topology-id": "te-topology:abstract2", 1363 "abstract-node": "D2", 1364 "vn-member-list": [ 1365 { 1366 "vn-member-id": 105, 1367 "src": { 1368 "src": 101, 1369 "src-vn-ap-id": 10102, 1370 }, 1371 "dest": { 1372 "dest": 550, 1373 "dest-vn-ap-id": 55002, 1374 }, 1375 "connectivity-matrix-id": 105 1376 } 1377 ] 1378 }, 1379 { 1380 "vn-id": 3, 1381 "vn-name": "vn3", 1382 "vn-topology-id": "te-topology:abstract3", 1383 "abstract-node": "D3", 1384 "vn-member-list": [ 1385 { 1386 "vn-member-id": 104, 1387 "src": { 1388 "src": 101, 1389 }, 1390 "dest": { 1391 "dest": 440, 1392 "multi-dest": true 1393 } 1394 }, 1395 { 1396 "vn-member-id": 107, 1397 "src": { 1398 "src": 101, 1399 "src-vn-ap-id": 10103, 1400 }, 1401 "dest": { 1402 "dest": 770, 1403 "dest-vn-ap-id": 77003, 1404 "multi-dest": true 1405 }, 1406 "connectivity-matrix-id": 107, 1407 "if-selected":true, 1408 }, 1409 { 1410 "vn-member-id": 204, 1411 "src": { 1412 "src": 202, 1413 "multi-src": true, 1414 }, 1415 "dest": { 1416 "dest": 440, 1417 }, 1418 }, 1419 { 1420 "vn-member-id": 304, 1421 "src": { 1422 "src": 303, 1423 "src-vn-ap-id": 30303, 1424 "multi-src": true, 1425 }, 1426 "dest": { 1427 "dest": 440, 1428 "src-vn-ap-id": 44003, 1429 }, 1430 "connectivity-matrix-id": 304, 1431 "if-selected":true, 1432 }, 1433 ] 1434 }, 1436 ] 1437 } 1439 } 1440 } 1442 7.2. TE-topology JSON 1444 { 1445 "networks": { 1446 "network": [ 1447 { 1448 "network-types": { 1449 "te-topology": {} 1450 }, 1451 "network-id": "abstract1", 1452 "provider-id": 201, 1453 "client-id": 600, 1454 "te-topology-id": "te-topology:abstract1", 1455 "node": [ 1456 { 1457 "node-id": "D1", 1458 "te-node-id": "2.0.1.1", 1459 "te": { 1460 "te-node-attributes": { 1461 "domain-id" : 1, 1462 "is-abstract": [null], 1463 "connectivity-matrices": { 1464 "is-allowed": true, 1465 "path-constraints": { 1466 "bandwidth-generic": { 1467 "te-bandwidth": { 1468 "generic": [ 1469 { 1470 "generic": "0x1p10", 1471 } 1472 ] 1473 } 1474 } 1475 "disjointness": "node link srlg", 1477 }, 1478 "connectivity-matrix": [ 1479 { 1480 "id": 104, 1481 "from": "1-0-1", 1482 "to": "4-4-0" 1483 }, 1484 { 1485 "id": 107, 1486 "from": "1-0-1", 1487 "to": "7-7-0" 1488 }, 1489 { 1490 "id": 204, 1491 "from": "2-0-2", 1492 "to": "4-4-0" 1493 }, 1494 { 1495 "id": 308, 1496 "from": "3-0-3", 1497 "to": "8-8-0" 1498 }, 1499 { 1500 "id": 108, 1501 "from": "1-0-1", 1502 "to": "8-8-0" 1503 }, 1504 ] 1505 } 1506 } 1507 }, 1508 "termination-point": [ 1509 { 1510 "tp-id": "1-0-1", 1511 "te-tp-id": 10001, 1512 "te": { 1513 "interface-switching-capability": [ 1514 { 1515 "switching-capability": "switching-otn", 1516 "encoding": "lsp-encoding-oduk" 1517 } 1518 ] 1519 } 1520 }, 1521 { 1522 "tp-id": "1-1-0", 1523 "te-tp-id": 10100, 1524 "te": { 1525 "interface-switching-capability": [ 1526 { 1527 "switching-capability": "switching-otn", 1528 "encoding": "lsp-encoding-oduk" 1529 } 1530 ] 1531 } 1532 }, 1533 { 1534 "tp-id": "2-0-2", 1535 "te-tp-id": 20002, 1536 "te": { 1537 "interface-switching-capability": [ 1538 { 1539 "switching-capability": "switching-otn", 1540 "encoding": "lsp-encoding-oduk" 1541 } 1542 ] 1543 } 1544 }, 1545 { 1546 "tp-id": "2-2-0", 1547 "te-tp-id": 20200, 1548 "te": { 1549 "interface-switching-capability": [ 1550 { 1551 "switching-capability": "switching-otn", 1552 "encoding": "lsp-encoding-oduk" 1553 } 1554 ] 1555 } 1556 }, 1557 { 1558 "tp-id": "3-0-3", 1559 "te-tp-id": 30003, 1560 "te": { 1561 "interface-switching-capability": [ 1562 { 1563 "switching-capability": "switching-otn", 1564 "encoding": "lsp-encoding-oduk" 1565 } 1566 ] 1567 } 1568 }, 1569 { 1570 "tp-id": "3-3-0", 1571 "te-tp-id": 30300, 1572 "te": { 1573 "interface-switching-capability": [ 1574 { 1575 "switching-capability": "switching-otn", 1576 "encoding": "lsp-encoding-oduk" 1577 } 1578 ] 1579 } 1580 }, 1581 { 1582 "tp-id": "4-0-4", 1583 "te-tp-id": 40004, 1584 "te": { 1585 "interface-switching-capability": [ 1586 { 1587 "switching-capability": "switching-otn", 1588 "encoding": "lsp-encoding-oduk" 1589 } 1590 ] 1591 } 1592 }, 1593 { 1594 "tp-id": "4-4-0", 1595 "te-tp-id": 40400, 1596 "te": { 1597 "interface-switching-capability": [ 1598 { 1599 "switching-capability": "switching-otn", 1600 "encoding": "lsp-encoding-oduk" 1601 } 1602 ] 1603 } 1604 }, 1605 { 1606 "tp-id": "5-0-5", 1607 "te-tp-id": 50005, 1608 "te": { 1609 "interface-switching-capability": [ 1610 { 1611 "switching-capability": "switching-otn", 1612 "encoding": "lsp-encoding-oduk" 1613 } 1614 ] 1615 } 1616 }, 1617 { 1618 "tp-id": "5-5-0", 1619 "te-tp-id": 50500, 1620 "te": { 1621 "interface-switching-capability": [ 1622 { 1623 "switching-capability": "switching-otn", 1624 "encoding": "lsp-encoding-oduk" 1625 } 1626 ] 1627 } 1628 }, 1629 { 1630 "tp-id": "6-0-6", 1631 "te-tp-id": 60006, 1632 "te": { 1633 "interface-switching-capability": [ 1634 { 1635 "switching-capability": "switching-otn", 1636 "encoding": "lsp-encoding-oduk" 1637 } 1638 ] 1639 } 1640 }, 1641 { 1642 "tp-id": "6-6-0", 1643 "te-tp-id": 60600, 1644 "te": { 1645 "interface-switching-capability": [ 1646 { 1647 "switching-capability": "switching-otn", 1648 "encoding": "lsp-encoding-oduk" 1649 } 1650 ] 1651 } 1652 }, 1653 { 1654 "tp-id": "7-0-7", 1655 "te-tp-id": 70007, 1656 "te": { 1657 "interface-switching-capability": [ 1658 { 1659 "switching-capability": "switching-otn", 1660 "encoding": "lsp-encoding-oduk" 1661 } 1662 ] 1663 } 1664 }, 1665 { 1666 "tp-id": "7-7-0", 1667 "te-tp-id": 70700, 1668 "te": { 1669 "interface-switching-capability": [ 1670 { 1671 "switching-capability": "switching-otn", 1672 "encoding": "lsp-encoding-oduk" 1673 } 1674 ] 1675 } 1676 }, 1677 { 1678 "tp-id": "8-0-8", 1679 "te-tp-id": 80008, 1680 "te": { 1681 "interface-switching-capability": [ 1682 { 1683 "switching-capability": "switching-otn", 1684 "encoding": "lsp-encoding-oduk" 1685 } 1686 ] 1687 } 1688 }, 1689 { 1690 "tp-id": "8-8-0", 1691 "te-tp-id": 80800, 1692 "te": { 1693 "interface-switching-capability": [ 1694 { 1695 "switching-capability": "switching-otn", 1696 "encoding": "lsp-encoding-oduk" 1698 } 1699 ] 1700 } 1701 } 1702 ] 1703 } 1704 ] 1705 }, 1706 { 1707 "network-types": { 1708 "te-topology": {} 1709 }, 1710 "network-id": "abstract2", 1711 "provider-id": 201, 1712 "client-id": 600, 1713 "te-topology-id": "te-topology:abstract2", 1714 "node": [ 1715 { 1716 "node-id": "D2", 1717 "te-node-id": "2.0.1.2", 1718 "te": { 1719 "te-node-attributes": { 1720 "domain-id" : 1, 1721 "is-abstract": [null], 1722 "connectivity-matrices": { 1723 "is-allowed": true, 1724 "underlay": { 1725 "enabled": true 1726 }, 1727 "path-constraints": { 1728 "bandwidth-generic": { 1729 "te-bandwidth": { 1730 "generic": [ 1731 { 1732 "generic": "0x1p10" 1733 } 1734 ] 1735 } 1736 } 1737 }, 1738 "optimizations": { 1739 "objective-function": { 1740 "objective-function-type": "of-maximize-residual- 1741 bandwidth" 1742 } 1743 }, 1744 "connectivity-matrix": [ 1745 { 1746 "id": 105, 1747 "from": "1-0-1", 1748 "to": "5-5-0", 1749 "underlay": { 1750 "enabled": true, 1751 "primary-path": { 1752 "network-ref": "absolute", 1753 "path-element": [ 1754 { 1755 "path-element-id": 1, 1756 "index": 1, 1757 "numbered-hop": { 1758 "address": "4.4.4.4", 1759 "hop-type": "STRICT" 1760 } 1761 }, 1762 { 1763 "path-element-id": 2, 1764 "index": 2, 1765 "numbered-hop": { 1766 "address": "7.7.7.7", 1767 "hop-type": "STRICT" 1768 } 1769 } 1770 ] 1771 } 1772 } 1773 } 1774 ] 1775 } 1776 } 1777 }, 1778 "termination-point": [ 1779 { 1780 "tp-id": "1-0-1", 1781 "te-tp-id": 10001, 1782 "te": { 1783 "interface-switching-capability": [ 1784 { 1785 "switching-capability": "switching-otn", 1786 "encoding": "lsp-encoding-oduk" 1787 } 1788 ] 1789 } 1790 }, 1791 { 1792 "tp-id": "1-1-0", 1793 "te-tp-id": 10100, 1794 "te": { 1795 "interface-switching-capability": [ 1796 { 1797 "switching-capability": "switching-otn", 1798 "encoding": "lsp-encoding-oduk" 1799 } 1800 ] 1801 } 1802 }, 1803 { 1804 "tp-id": "2-0-2", 1805 "te-tp-id": 20002, 1806 "te": { 1807 "interface-switching-capability": [ 1808 { 1809 "switching-capability": "switching-otn", 1810 "encoding": "lsp-encoding-oduk" 1811 } 1812 ] 1813 } 1814 }, 1815 { 1816 "tp-id": "2-2-0", 1817 "te-tp-id": 20200, 1818 "te": { 1819 "interface-switching-capability": [ 1820 { 1821 "switching-capability": "switching-otn", 1822 "encoding": "lsp-encoding-oduk" 1823 } 1824 ] 1825 } 1826 }, 1827 { 1828 "tp-id": "3-0-3", 1829 "te-tp-id": 30003, 1830 "te": { 1831 "interface-switching-capability": [ 1832 { 1833 "switching-capability": "switching-otn", 1834 "encoding": "lsp-encoding-oduk" 1835 } 1836 ] 1837 } 1838 }, 1839 { 1840 "tp-id": "3-3-0", 1841 "te-tp-id": 30300, 1842 "te": { 1843 "interface-switching-capability": [ 1844 { 1845 "switching-capability": "switching-otn", 1846 "encoding": "lsp-encoding-oduk" 1847 } 1848 ] 1849 } 1850 }, 1851 { 1852 "tp-id": "4-0-4", 1853 "te-tp-id": 40004, 1854 "te": { 1855 "interface-switching-capability": [ 1856 { 1857 "switching-capability": "switching-otn", 1858 "encoding": "lsp-encoding-oduk" 1859 } 1860 ] 1861 } 1862 }, 1863 { 1864 "tp-id": "4-4-0", 1865 "te-tp-id": 40400, 1866 "te": { 1867 "interface-switching-capability": [ 1868 { 1869 "switching-capability": "switching-otn", 1870 "encoding": "lsp-encoding-oduk" 1871 } 1872 ] 1873 } 1874 }, 1875 { 1876 "tp-id": "5-0-5", 1877 "te-tp-id": 50005, 1878 "te": { 1879 "interface-switching-capability": [ 1880 { 1881 "switching-capability": "switching-otn", 1882 "encoding": "lsp-encoding-oduk" 1883 } 1884 ] 1885 } 1886 }, 1887 { 1888 "tp-id": "5-5-0", 1889 "te-tp-id": 50500, 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": "6-0-6", 1901 "te-tp-id": 60006, 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": "6-6-0", 1913 "te-tp-id": 60600, 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": "7-0-7", 1925 "te-tp-id": 70007, 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": "7-7-0", 1937 "te-tp-id": 70700, 1938 "te": { 1939 "interface-switching-capability": [ 1940 { 1941 "switching-capability": "switching-otn", 1942 "encoding": "lsp-encoding-oduk" 1944 } 1945 ] 1946 } 1947 }, 1948 { 1949 "tp-id": "8-0-8", 1950 "te-tp-id": 80008, 1951 "te": { 1952 "interface-switching-capability": [ 1953 { 1954 "switching-capability": "switching-otn", 1955 "encoding": "lsp-encoding-oduk" 1956 } 1957 ] 1958 } 1959 }, 1960 { 1961 "tp-id": "8-8-0", 1962 "te-tp-id": 80800, 1963 "te": { 1964 "interface-switching-capability": [ 1965 { 1966 "switching-capability": "switching-otn", 1967 "encoding": "lsp-encoding-oduk" 1968 } 1969 ] 1970 } 1971 } 1972 ] 1973 } 1974 ] 1975 }, 1976 { 1977 "network-types": { 1978 "te-topology": {} 1979 }, 1980 "network-id": "abstract3", 1981 "provider-id": 201, 1982 "client-id": 600, 1983 "te-topology-id": "te-topology:abstract3", 1984 "node": [ 1985 { 1986 "node-id": "D3", 1987 "te-node-id": "3.0.1.1", 1988 "te": { 1989 "te-node-attributes": { 1990 "domain-id" : 3, 1991 "is-abstract": [null], 1992 "connectivity-matrices": { 1993 "is-allowed": true, 1994 "path-constraints": { 1995 "bandwidth-generic": { 1996 "te-bandwidth": { 1997 "generic": [ 1998 { 1999 "generic": "0x1p10", 2000 } 2001 ] 2002 } 2003 } 2004 }, 2005 "connectivity-matrix": [ 2006 { 2007 "id": 107, 2008 "from": "1-0-1", 2009 "to": "7-7-0" 2010 }, 2011 { 2012 "id": 308, 2013 "from": "3-0-3", 2014 "to": "8-8-0" 2015 }, 2016 ] 2017 } 2018 } 2019 }, 2020 "termination-point": [ 2021 { 2022 "tp-id": "1-0-1", 2023 "te-tp-id": 10001, 2024 "te": { 2025 "interface-switching-capability": [ 2026 { 2027 "switching-capability": "switching-otn", 2028 "encoding": "lsp-encoding-oduk" 2029 } 2030 ] 2031 } 2032 }, 2033 { 2034 "tp-id": "1-1-0", 2035 "te-tp-id": 10100, 2036 "te": { 2037 "interface-switching-capability": [ 2038 { 2039 "switching-capability": "switching-otn", 2040 "encoding": "lsp-encoding-oduk" 2041 } 2043 ] 2044 } 2045 }, 2046 { 2047 "tp-id": "2-0-2", 2048 "te-tp-id": 20002, 2049 "te": { 2050 "interface-switching-capability": [ 2051 { 2052 "switching-capability": "switching-otn", 2053 "encoding": "lsp-encoding-oduk" 2054 } 2055 ] 2056 } 2057 }, 2058 { 2059 "tp-id": "2-2-0", 2060 "te-tp-id": 20200, 2061 "te": { 2062 "interface-switching-capability": [ 2063 { 2064 "switching-capability": "switching-otn", 2065 "encoding": "lsp-encoding-oduk" 2066 } 2067 ] 2068 } 2069 }, 2070 { 2071 "tp-id": "3-0-3", 2072 "te-tp-id": 30003, 2073 "te": { 2074 "interface-switching-capability": [ 2075 { 2076 "switching-capability": "switching-otn", 2077 "encoding": "lsp-encoding-oduk" 2078 } 2079 ] 2080 } 2081 }, 2082 { 2083 "tp-id": "3-3-0", 2084 "te-tp-id": 30300, 2085 "te": { 2086 "interface-switching-capability": [ 2087 { 2088 "switching-capability": "switching-otn", 2089 "encoding": "lsp-encoding-oduk" 2090 } 2091 ] 2093 } 2094 }, 2095 { 2096 "tp-id": "4-0-4", 2097 "te-tp-id": 40004, 2098 "te": { 2099 "interface-switching-capability": [ 2100 { 2101 "switching-capability": "switching-otn", 2102 "encoding": "lsp-encoding-oduk" 2103 } 2104 ] 2105 } 2106 }, 2107 { 2108 "tp-id": "4-4-0", 2109 "te-tp-id": 40400, 2110 "te": { 2111 "interface-switching-capability": [ 2112 { 2113 "switching-capability": "switching-otn", 2114 "encoding": "lsp-encoding-oduk" 2115 } 2116 ] 2117 } 2118 }, 2119 { 2120 "tp-id": "5-0-5", 2121 "te-tp-id": 50005, 2122 "te": { 2123 "interface-switching-capability": [ 2124 { 2125 "switching-capability": "switching-otn", 2126 "encoding": "lsp-encoding-oduk" 2127 } 2128 ] 2129 } 2130 }, 2131 { 2132 "tp-id": "5-5-0", 2133 "te-tp-id": 50500, 2134 "te": { 2135 "interface-switching-capability": [ 2136 { 2137 "switching-capability": "switching-otn", 2138 "encoding": "lsp-encoding-oduk" 2139 } 2140 ] 2141 } 2143 }, 2144 { 2145 "tp-id": "6-0-6", 2146 "te-tp-id": 60006, 2147 "te": { 2148 "interface-switching-capability": [ 2149 { 2150 "switching-capability": "switching-otn", 2151 "encoding": "lsp-encoding-oduk" 2152 } 2153 ] 2154 } 2155 }, 2156 { 2157 "tp-id": "6-6-0", 2158 "te-tp-id": 60600, 2159 "te": { 2160 "interface-switching-capability": [ 2161 { 2162 "switching-capability": "switching-otn", 2163 "encoding": "lsp-encoding-oduk" 2164 } 2165 ] 2166 } 2167 }, 2168 { 2169 "tp-id": "7-0-7", 2170 "te-tp-id": 70007, 2171 "te": { 2172 "interface-switching-capability": [ 2173 { 2174 "switching-capability": "switching-otn", 2175 "encoding": "lsp-encoding-oduk" 2176 } 2177 ] 2178 } 2179 }, 2180 { 2181 "tp-id": "7-7-0", 2182 "te-tp-id": 70700, 2183 "te": { 2184 "interface-switching-capability": [ 2185 { 2186 "switching-capability": "switching-otn", 2187 "encoding": "lsp-encoding-oduk" 2188 } 2189 ] 2190 } 2191 }, 2192 { 2193 "tp-id": "8-0-8", 2194 "te-tp-id": 80008, 2195 "te": { 2196 "interface-switching-capability": [ 2197 { 2198 "switching-capability": "switching-otn", 2199 "encoding": "lsp-encoding-oduk" 2200 } 2201 ] 2202 } 2203 }, 2204 { 2205 "tp-id": "8-8-0", 2206 "te-tp-id": 80800, 2207 "te": { 2208 "interface-switching-capability": [ 2209 { 2210 "switching-capability": "switching-otn", 2211 "encoding": "lsp-encoding-oduk" 2212 } 2213 ] 2214 } 2215 } 2216 ] 2217 } 2218 ] 2219 }, 2220 ] 2221 } 2222 } 2224 8. Security Considerations 2226 TDB 2228 9. IANA Considerations 2230 TDB 2232 10. Acknowledgments 2234 The authors would like to thank Igor Bryskin and Xufeng Liu for 2235 their helpful comments and valuable contributions. 2237 11. References 2239 11.1. Normative References 2241 [TE-TOPO] X. Liu, et al., "YANG Data Model for TE Topologies", work 2242 in progress: draft-ietf-teas-yang-te-topo. 2244 [TE-tunnel] T. Saad, et al., "A YANG Data Model for Traffic 2245 Engineering Tunnels and Interfaces", work in progress: 2246 draft-ietf-teas-yang-te. 2248 11.2. Informative References 2250 [RFC7926] A. Farrel (Ed.), "Problem Statement and Architecture for 2251 Information Exchange between Interconnected Traffic- 2252 Engineered Networks", RFC 7926, July 2016. 2254 [ACTN-REQ] Lee, et al., "Requirements for Abstraction and Control of 2255 TE Networks", draft-ietf-teas-actn-requirements, work in 2256 progress. 2258 [ACTN-FWK] D. Ceccarelli, Y. Lee [Editors], "Framework for 2259 Abstraction and Control of Traffic Engineered Networks", 2260 draft-ceccarelli-teas-actn-framework, work in progress. 2262 [TE-MAP] Y. Lee, D. Dhody, and D. Ceccarelli, "Traffic Engineering 2263 and Service Mapping Yang Model", draft-lee-teas-te- 2264 service-mapping-yang, work in progress. 2266 [SERVICE-YANG] Q. Wu, W. Liu and A. Farrel, "Service Models 2267 Explained", draft-wu-opsawg-service-model-explained, 2268 work in progress. 2270 [ACTN-PM] Y. Lee, et al., "YANG models for ACTN TE Performance 2271 Monitoring Telemetry and Network Autonomics", draft-lee- 2272 teas-actn-pm-telemetry-autonomics, work in progress. 2274 [OIF-VTNS] Virtual Transport Network Services 1.0 Specification, IA 2275 OIF-VTNS-1.0, April 2017. 2277 12. Contributors 2279 Contributor's Addresses 2281 Haomian Zheng 2282 Huawei Technologies 2283 Email: zhenghaomian@huawei.com 2285 Xian Zhang 2286 Huawei Technologies 2287 Email: zhang.xian@huawei.com 2289 Sergio Belotti 2290 Nokia 2291 Email: sergio.belotti@nokia.com 2293 Qin Wu 2294 Huawei Technologies 2295 Email: bill.wu@huawei.com 2297 Authors' Addresses 2299 Young Lee (ed.) 2300 Huawei Technologies 2301 Email: leeyoung@huawei.com 2303 Dhruv Dhody 2304 Huawei Technologies 2305 Email: dhruv.ietf@gmail.com 2307 Daniele Ceccarelli 2308 Ericsson 2309 Torshamnsgatan,48 2310 Stockholm, Sweden 2311 Email: daniele.ceccarelli@ericsson.com 2313 Takuya Miyasaka 2314 KDDI 2315 Email: ta-miyasaka@kddi.com 2316 Peter Park 2317 KT 2318 Email: peter.park@kt.com 2320 Bin Yeong Yoon 2321 ETRI 2322 Email: byyun@etri.re.kr