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