idnits 2.17.1 draft-liu-netmod-yang-abstract-topo-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1295: '...sending the topology data MUST support...' RFC 2119 keyword, line 1296: '...thentication and SHOULD support encryp...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 97 has weird spacing: '...elected to ha...' == Line 179 has weird spacing: '...from-tp nt:...' == Line 185 has weird spacing: '...-prefix ine...' == Line 205 has weird spacing: '...ment-id uin...' == Line 219 has weird spacing: '...ment-id uin...' == (6 more instances...) -- The document date (July 1, 2014) is 3579 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'GMPL-UNI' is mentioned on line 103, but not defined == Missing Reference: 'GMPLS-ENNI' is mentioned on line 108, but not defined == Missing Reference: 'RFC2119' is mentioned on line 145, but not defined == Unused Reference: 'RFC6021' is defined on line 1307, but no explicit reference was found in the text == Unused Reference: 'RFC6241' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: 'RFC2234' is defined on line 1314, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 1318, but no explicit reference was found in the text == Unused Reference: 'RFC3811' is defined on line 1322, but no explicit reference was found in the text == Unused Reference: 'RFC3812' is defined on line 1326, but no explicit reference was found in the text == Unused Reference: 'RFC3813' is defined on line 1331, but no explicit reference was found in the text == Unused Reference: 'RFC4208' is defined on line 1336, but no explicit reference was found in the text == Unused Reference: 'RFC4220' is defined on line 1342, but no explicit reference was found in the text == Unused Reference: 'RFC4801' is defined on line 1345, but no explicit reference was found in the text == Unused Reference: 'RFC4802' is defined on line 1349, but no explicit reference was found in the text == Unused Reference: 'G.8080' is defined on line 1355, but no explicit reference was found in the text == Unused Reference: 'I-D.clemm-netmod-yang-network-topo' is defined on line 1361, but no explicit reference was found in the text == Unused Reference: 'I-D.beeram-ccamp-melg' is defined on line 1367, but no explicit reference was found in the text == Unused Reference: 'I-D.beeram-ccamp-srclg' is defined on line 1372, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) -- No information found for draft-clemm-netmod-yang-network-topo - is the name correct? Summary: 4 errors (**), 0 flaws (~~), 25 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group X. Liu 2 Internet-Draft Ericsson 3 Intended status: Experimental I. Bryskin 4 Expires: January 2015 ADVA Optical Networking 5 A. Clemm 6 Cisco 7 V. P. Beeram 8 Juniper Networks 9 July 1, 2014 11 A YANG Data Model for Abstract Network Topologies 12 draft-liu-netmod-yang-abstract-topo-00.txt 14 Abstract 16 This document describes a concept, a methodology and a YANG data 17 model to (re-)configure abstract topologies, retrieve their states 18 and thus to automate the abstract topology manipulation. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html 41 This Internet-Draft will expire on January 1, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. 55 Table of Contents 57 1. Introduction...................................................2 58 1.1. Terminology...............................................4 59 2. Abstract network topology model overview.......................4 60 3. Usage Example..................................................9 61 4. Abstract Network Topology YANG module.........................24 62 5. Security Considerations.......................................32 63 6. References....................................................32 64 6.1. Normative References.....................................32 65 6.2. Informative References...................................33 67 1. Introduction 69 Clients of a transport network normally have no visibility into the 70 network's actual topology and resource availability information. 71 There are numerous reasons for this, such as: 73 a) Security considerations: network operators are usually reluctant 74 to expose the network's actual topology to its clients; 76 b) Transport network, generally speaking, is comprised of network 77 elements that belong to a different layer network that the client 78 devices. Also the internal network routing and traffic engineering 79 advertisements usually contain proprietary information, which the 80 clients cannot interpret, but discarding of which would lead to 81 incorrect assumptions and decisions. This means that the clients 82 cannot use actual network topology and traffic engineering 83 information even if said information is available; 85 c) Scalability considerations: clients do not want to know any 86 transport network information that is not related to the services 87 provided to the clients. 89 On the other hand the clients need to influence to certain extent on 90 the way the services provided to them are routed across the transport 91 network: some services, for example, need to be as disjoint from each 92 other as possible because they support various network failure 93 protection schemes provisioned in the client layer network; others, 94 on the contrary, need to be co-routed and share fate as much as 95 possible; placement of some services needs to be optimized based on 96 the lowest cost criteria, while other service paths need to be 97 selected to have best optical signal quality or delay 98 characteristics, and so forth. 100 Different approaches exist to allow for the clients to affect the 101 placement of provided for them services on the transport network 102 under conditions of no visibility into the actual transport network 103 topology and resource availability information. For example, [GMPL- 104 UNI] architecture allows for clients signaling their service routing 105 policies/preferences within the service setup and modify messages and 106 mandates the network path computers to honor said 107 policies/preferences during the service path selection. There are 108 also control plane based (e.g. [GMPLS-ENNI]) and SDN architectures 109 that require the network to expose abstract topologies. Such 110 topologies are decoupled from the network actual topologies and are 111 provided on per client group/VPN/tenant basis. The abstract 112 topologies are supposed to be fully understandable by the clients and 113 contain sufficient information for the client path computers to 114 select service paths according to the client policies. The service 115 paths so selected in terms of abstract topology elements could be 116 signaled or otherwise conveyed within service setup/modify requests 117 to the transport network system responsible for the service 118 provisioning. 120 One problem with the abstract topologies exposed to the clients is 121 their static nature. The abstract topologies are usually manually 122 configured based on the transport network operator policies. This 123 entails tedious error-prone configuration. This also does not allow 124 for the clients to have a say as to how the abstract topologies 125 exposed to them should look like, which elements (nodes, links) it 126 should contain, what the parameters (e.g. link bandwidth, SRLGs, 127 etc.) are, and so forth. The problem becomes especially profound in 128 case the clients requirements with respect to the abstract topologies 129 change over time and/or depend on particular week, day, time of the 130 day, etc. It is highly desirable to have a data model understood and 131 supported by the transport network and all its potential clients that 132 would allow for the clients to dynamically (re-)configure the 133 abstract topologies exposed to them in real time. This document 134 introduces a data model written in YANG, that allows for the clients 135 using NETCONF and/or RESTCONF protocols to (re-)configure abstract 136 topologies, retrieve their data state and, thus, to automate the 137 abstract topology manipulation. 139 1.1. Terminology 141 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14, [RFC2119]. 146 The following terms are defined in [RFC6020] and are not redefined 147 here: 149 o augment 151 o data model 153 o data node 155 2. Abstract network topology model overview 157 This document defines the YANG module "abstract-topology", which has 158 the following structure: 160 module: abstract-topology 161 augment /nt:network-topology/nt:topology/nt:topology-types/l3t:l3- 162 unicast-igp-topology: 163 +--rw abstract! 164 augment /nt:network-topology/nt:topology/nt:node/nt:termination- 165 point/l3t:igp-termination-point-attributes: 166 +--rw abstract-tp-attributes 167 +--rw node-ref? nt:node-ref 168 augment /nt:network-topology/nt:topology/nt:node/l3t:igp-node- 169 attributes: 170 +--rw abstract-node-attributes 171 +--rw schedules* [schedule-id] 172 | +--rw schedule-id uint32 173 | +--rw start? yang:date-and-time 174 | +--rw schedule-duration? string 175 | +--rw repeat-interval? string 176 +--rw is-virtual? boolean 177 +--rw underlay-topology? nt:topology-ref 178 +--rw connectivity-matrix* [from-tp to-tp] 179 | +--rw from-tp nt:tp-ref 180 | +--rw to-tp nt:tp-ref 181 +--rw ted 182 +--rw te-router-id-ipv4? inet:ipv4-address 183 +--rw te-router-id-ipv6? inet:ipv6-address 184 +--rw ipv4-local-address* [ipv4-prefix] 185 | +--rw ipv4-prefix inet:ipv4-prefix 186 +--rw ipv6-local-address* [ipv6-prefix] 187 | +--rw ipv6-prefix inet:ipv6-prefix 188 | +--rw prefix-option? uint8 189 +--rw pcc-capabilities? pcc-capabilities 190 augment /nt:network-topology/nt:topology/nt:link/l3t:igp-link- 191 attributes: 192 +--rw abstract-link-attributes 193 +--rw schedules* [schedule-id] 194 | +--rw schedule-id uint32 195 | +--rw start? yang:date-and-time 196 | +--rw schedule-duration? string 197 | +--rw repeat-interval? string 198 +--rw advertising-node-src? nt:node-id 199 +--rw advertising-node-des? nt:node-id 200 +--rw is-virtual? boolean 201 +--ro melg* uint32 202 +--ro srclg* uint32 203 +--rw server-path 204 | +--rw path-element* [path-element-id] 205 | +--rw path-element-id uint32 206 | +--rw loose? boolean 207 | +--rw (element-type)? 208 | +--:(numbered-link) 209 | | +--rw link-ipv4? uint32 210 | +--:(unnumbered-link) 211 | | +--rw link-node-id? uint32 212 | | +--rw link-id? uint32 213 | +--:(node) 214 | | +--rw node-id? uint32 215 | +--:(label) 216 | +--rw label? uint32 217 +--rw server-backup-path 218 | +--rw path-element* [path-element-id] 219 | +--rw path-element-id uint32 220 | +--rw loose? boolean 221 | +--rw (element-type)? 222 | +--:(numbered-link) 223 | | +--rw link-ipv4? uint32 224 | +--:(unnumbered-link) 225 | | +--rw link-node-id? uint32 226 | | +--rw link-id? uint32 227 | +--:(node) 228 | | +--rw node-id? uint32 229 | +--:(label) 230 | +--rw label? uint32 231 +--rw server-protection-type? uint16 232 +--rw server-trail-src? nt:tp-ref 233 +--rw server-trail-des? nt:tp-ref 234 +--rw ted 235 +--rw color? uint32 236 +--rw max-link-bandwidth? decimal64 237 +--rw max-resv-link-bandwidth? decimal64 238 +--rw unreserved-bandwidth* [priority] 239 | +--rw priority uint8 240 | +--rw bandwidth? decimal64 241 +--rw te-default-metric? uint32 242 +--rw srlg 243 +--rw interface-switching-capabilities* [switching- 244 capability] 245 | +--rw switching-capability 246 ted:switching-capabilities 247 | +--rw encoding? uint8 248 | +--rw max-lsp-bandwidth* [priority] 249 | | +--rw priority uint8 250 | | +--rw bandwidth? decimal64 251 | +--rw packet-switch-capable 252 | | +--rw minimum-lsp-bandwidth? decimal64 253 | | +--rw interface-mtu? uint16 254 | +--rw time-division-multiplex-capable 255 | +--rw minimum-lsp-bandwidth? decimal64 256 | +--rw indication? uint16 257 +--rw srlg-values* [srlg-value] 258 | +--rw srlg-value uint32 259 +--rw link-protection-type? uint16 260 augment /l3t:igp-node-event: 261 +--ro abstract! 262 +--ro abstract-node-attributes 263 +--ro schedules* [schedule-id] 264 | +--ro schedule-id uint32 265 | +--ro start? yang:date-and-time 266 | +--ro schedule-duration? string 267 | +--ro repeat-interval? string 268 +--ro is-virtual? boolean 269 +--ro underlay-topology? nt:topology-ref 270 +--ro connectivity-matrix* [from-tp to-tp] 271 | +--ro from-tp nt:tp-ref 272 | +--ro to-tp nt:tp-ref 273 +--ro ted 274 +--ro te-router-id-ipv4? inet:ipv4-address 275 +--ro te-router-id-ipv6? inet:ipv6-address 276 +--ro ipv4-local-address* [ipv4-prefix] 277 | +--ro ipv4-prefix inet:ipv4-prefix 278 +--ro ipv6-local-address* [ipv6-prefix] 279 | +--ro ipv6-prefix inet:ipv6-prefix 280 | +--ro prefix-option? uint8 281 +--ro pcc-capabilities? pcc-capabilities 282 augment /l3t:igp-link-event: 283 +--ro abstract! 284 +--ro abstract-link-attributes 285 +--ro schedules* [schedule-id] 286 | +--ro schedule-id uint32 287 | +--ro start? yang:date-and-time 288 | +--ro schedule-duration? string 289 | +--ro repeat-interval? string 290 +--ro advertising-node-src? nt:node-id 291 +--ro advertising-node-des? nt:node-id 292 +--ro is-virtual? boolean 293 +--ro melg* uint32 294 +--ro srclg* uint32 295 +--ro server-path 296 | +--ro path-element* [path-element-id] 297 | +--ro path-element-id uint32 298 | +--ro loose? boolean 299 | +--ro (element-type)? 300 | +--:(numbered-link) 301 | | +--ro link-ipv4? uint32 302 | +--:(unnumbered-link) 303 | | +--ro link-node-id? uint32 304 | | +--ro link-id? uint32 305 | +--:(node) 306 | | +--ro node-id? uint32 307 | +--:(label) 308 | +--ro label? uint32 309 +--ro server-backup-path 310 | +--ro path-element* [path-element-id] 311 | +--ro path-element-id uint32 312 | +--ro loose? boolean 313 | +--ro (element-type)? 314 | +--:(numbered-link) 315 | | +--ro link-ipv4? uint32 316 | +--:(unnumbered-link) 317 | | +--ro link-node-id? uint32 318 | | +--ro link-id? uint32 319 | +--:(node) 320 | | +--ro node-id? uint32 321 | +--:(label) 322 | +--ro label? uint32 323 +--ro server-protection-type? uint16 324 +--ro server-trail-src? nt:tp-ref 325 +--ro server-trail-des? nt:tp-ref 326 +--ro ted 327 +--ro color? uint32 328 +--ro max-link-bandwidth? decimal64 329 +--ro max-resv-link-bandwidth? decimal64 330 +--ro unreserved-bandwidth* [priority] 331 | +--ro priority uint8 332 | +--ro bandwidth? decimal64 333 +--ro te-default-metric? uint32 334 +--ro srlg 335 +--ro interface-switching-capabilities* [switching- 336 capability] 337 | +--ro switching-capability 338 ted:switching-capabilities 339 | +--ro encoding? uint8 340 | +--ro max-lsp-bandwidth* [priority] 341 | | +--ro priority uint8 342 | | +--ro bandwidth? decimal64 343 | +--ro packet-switch-capable 344 | | +--ro minimum-lsp-bandwidth? decimal64 345 | | +--ro interface-mtu? uint16 346 | +--ro time-division-multiplex-capable 347 | +--ro minimum-lsp-bandwidth? decimal64 348 | +--ro indication? uint16 349 +--ro srlg-values* [srlg-value] 350 | +--ro srlg-value uint32 351 +--ro link-protection-type? uint16 353 3. Usage Example 355 Figure 1 shows an example of abstract network topology. This topology 356 consists of four nodes at the physical layer: E, F, H, and H, which 357 are connected by four physical links: , , , and . Nodes E and F are grouped into a virtual node VN1; nodes G and H 359 are grouped into a virtual node VN2. There is a virtual link from 360 node E in VN1 to node G in VN2. 362 ............... ............... 363 .. ........ VN1 ... 364 .. .. 365 . +-----+ +-----+ .. 366 .. | F +----------------+ E | . 367 . +--+--+ +--+--+ .. 368 .. | ... | ... 369 ...... | ............. ... .. | ....... 370 | ... | 371 | ... | 372 | ... | 373 | ... | 374 .....|... ... ..... |..... 375 .... | ... ........ | ..... 376 .. | ... | .. 377 .. +--+--+ +--+--+ .. 378 .. | G +----------------+ H | .. 379 . +-----+ +-----+ . 380 . . 381 ... .. 382 ..... ...... VN2 .. 383 .............. ................ 385 Figure 1 Example of Abstract Network Topology 387 The JSON encoded configuration example for such a topology can be as 388 following: 390 { 391 "network-topology": { 392 "topology": [ 393 { 394 "topology-id": "ODUk", 395 "topology-types": { 396 "l3-unicast-igp-topology": { 397 "abstract": {} 398 } 399 }, 400 "node": [ 401 { 402 "node-id": "VN1", 403 "termination-point": [ 404 { 405 "tp-id": "E#CH-1-5-NE", 406 "igp-termination-point-attributes": { 407 "unnumbered-id": 101, 408 "abstract-tp-attributes": { 409 "node-ref": "E" 410 } 411 } 412 } 413 ], 414 "igp-node-attributes": { 415 "name": "VN1", 416 "abstract-node-attributes": { 417 "is-virtual": true, 418 "underlay-topology": "/network- 419 topology/topology[topology-id='VN1']" 420 } 421 } 422 }, // VN1 423 { 424 "node-id": "VN2", 425 "termination-point": [ 426 { 427 "tp-id": "G#CH-1-6-NE", 428 "igp-termination-point-attributes": { 429 "unnumbered-id": 102, 430 "abstract-tp-attributes": { 431 "node-ref": "G" 432 } 433 } 434 } 435 ], 436 "igp-node-attributes": { 437 "name": "VN2", 438 "abstract-node-attributes": { 439 "is-virtual": true, 440 "underlay-topology": "/network- 441 topology/topology[topology-id='VN2']" 442 } 443 } 444 } // VN2 445 ], 446 "link": [ 447 { 448 "link-id": "VN1#101-VN2#102", 449 "source": { 450 "source-node": "/network-topology/topology[topology- 451 id='ODUk']/node[node-id='VN1']", 452 "source-tp": "/network-topology/topology[topology- 453 id='ODUk']/node[node-id='VN1']/termination-point[tp-id='E#CH-1-5- 454 NE']" 455 } 456 "destination": { 457 "dest-node": "/network-topology/topology[topology- 458 id='ODUk']/node[node-id='VN2']", 459 "dest-tp": "/network-topology/topology[topology- 460 id='ODUk']/node[node-id='VN2']/termination-point[tp-id='G#CH-1-6- 461 NE']" 462 } 463 "supporting-link": [], 464 "igp-link-attributes": { 465 "abstract-link-attributes": { 466 "srlg": { 467 "interface-switching-capabilities": [ 468 { 469 "switching-capability": "OTN-TDM", // 110, 470 RFC7138 471 "encoding": 12, // G.709 OKUk, RFC4328 472 "max-lsp-bandwidth": [ 473 { 474 "priority": 7, 475 "bandwidth": 1254659200.0 // ODU2 RFC7138 476 } 477 ] // max-lsp-bandwidth 478 } 479 ] // interface-switching-capabilities 480 } 481 "is-virtual": true, 482 "advertising-node-src": "E", 483 "advertising-node-des": "G" 484 } // abstract-link-attributes 485 } // igp-link-attributes 486 }, // link "VN1#101-VN2#102" 487 { 488 "link-id": "VN2#102-VN1#101", 489 "source": { 490 "source-node": "/network-topology/topology[topology- 491 id='ODUk']/node[node-id='VN2']", 492 "source-tp": "/network-topology/topology[topology- 493 id='ODUk']/node[node-id='VN2']/termination-point[tp-id='G#CH-1-6- 494 NE']" 495 } 496 "destination": { 497 "dest-node": "/network-topology/topology[topology- 498 id='ODUk']/node[node-id='VN1']", 499 "dest-tp": "/network-topology/topology[topology- 500 id='ODUk']/node[node-id='VN1']/termination-point[tp-id='E#CH-1-5- 501 NE']" 502 } 503 "supporting-link": [], 504 "igp-link-attributes": { 505 "abstract-link-attributes": { 506 "srlg": { 507 "interface-switching-capabilities": [ 508 { 509 "switching-capability": "OTN-TDM", // 110, 510 RFC7138 511 "encoding": 12, // G.709 OKUk, RFC4328 512 "max-lsp-bandwidth": [ 513 { 514 "priority": 7, 515 "bandwidth": 1254659200.0 // ODU2 RFC7138 516 } 517 ] // max-lsp-bandwidth 518 } 519 ] // interface-switching-capabilities 520 } 521 "is-virtual": true, 522 "advertising-node-src": "G", 523 "advertising-node-des": "E" 524 } // abstract-link-attributes 525 } // igp-link-attributes 526 } // "VN2#102-VN1#101" 527 ] // link 528 }, // topoloty "ODUk" 529 { 530 "topology-id": "WDM", 531 "topology-types": { 532 "l3-unicast-igp-topology": { 533 "abstract": {} 534 } 535 }, 536 "node": [ 537 { 538 "node-id": "E", 539 "termination-point": [ 540 { 541 "tp-id": "OL-1", 542 "igp-termination-point-attributes": { 543 "unnumbered-id": 101 544 } 545 }, 546 { 547 "tp-id": "OL-2", 548 "igp-termination-point-attributes": { 549 "unnumbered-id": 102 551 } 552 }, 553 { 554 "tp-id": "CH-1-5-NE", 555 "igp-termination-point-attributes": { 556 "unnumbered-id": 103 557 } 558 } 559 ], 560 "igp-node-attributes": { 561 "name": "E", 562 "abstract-node-attributes": { 563 "is-virtual": false 564 } 565 } 566 }, // node E 567 { 568 "node-id": "F", 569 "termination-point": [ 570 { 571 "tp-id": "OL-1", 572 "igp-termination-point-attributes": { 573 "unnumbered-id": 101 574 } 575 }, 576 { 577 "tp-id": "OL-2", 578 "igp-termination-point-attributes": { 579 "unnumbered-id": 102 580 } 581 } 582 ], 583 "igp-node-attributes": { 584 "name": "F", 585 "abstract-node-attributes": { 586 "is-virtual": false 587 } 588 } 589 }, // node F 590 { 591 "node-id": "G", 592 "termination-point": [ 593 { 594 "tp-id": "OL-1", 595 "igp-termination-point-attributes": { 596 "unnumbered-id": 101 597 } 598 }, 599 { 600 "tp-id": "OL-2", 601 "igp-termination-point-attributes": { 602 "unnumbered-id": 102 603 } 604 }, 605 { 606 "tp-id": "CH-1-6-NE", 607 "igp-termination-point-attributes": { 608 "unnumbered-id": 103 609 } 610 } 611 ], 612 "igp-node-attributes": { 613 "name": "G", 614 "abstract-node-attributes": { 615 "is-virtual": false 616 } 617 } 618 }, // node G 619 { 620 "node-id": "H", 621 "termination-point": [ 622 { 623 "tp-id": "OL-1", 624 "igp-termination-point-attributes": { 625 "unnumbered-id": 101 626 } 627 }, 628 { 629 "tp-id": "OL-2", 630 "igp-termination-point-attributes": { 631 "unnumbered-id": 102 632 } 634 } 635 ], 636 "igp-node-attributes": { 637 "name": "H", 638 "abstract-node-attributes": { 639 "is-virtual": false 640 } 641 } 642 }, // node H 643 ], 644 "link": [ 645 { 646 "link-id": "E#101-F#102", 647 "source": { 648 "source-node": "/network-topology/topology[topology- 649 id='WDM']/node[node-id='E']", 650 "source-tp": "/network-topology/topology[topology- 651 id='WDM']/node[node-id='E']/termination-point[tp-id='OL-1']" 652 } 653 "destination": { 654 "dest-node": "/network-topology/topology[topology- 655 id='WDM']/node[node-id='F']", 656 "dest-tp": "/network-topology/topology[topology- 657 id='WDM']/node[node-id='F']/termination-point[tp-id='OL-2']" 658 } 659 "supporting-link": [], 660 "igp-link-attributes": { 661 "abstract-link-attributes": { 662 "srlg": { 663 "interface-switching-capabilities": [ 664 { 665 "switching-capability": "LSC", 666 "encoding": 12, // G.709 OKUk, RFC4328 667 "max-lsp-bandwidth": [ 668 { 669 "priority": 7, 670 "bandwidth": 1254659200.0 // ODU2 RFC7138 671 } 672 ] // max-lsp-bandwidth 673 } 674 ] // interface-switching-capabilities 676 } 677 "is-virtual": false 678 } // abstract-link-attributes 679 } // igp-link-attributes 680 }, // link E-F 681 { 682 "link-id": "F#102-E#101", 683 "source": { 684 "source-node": "/network-topology/topology[topology- 685 id='WDM']/node[node-id='F']", 686 "source-tp": "/network-topology/topology[topology- 687 id='WDM']/node[node-id='F']/termination-point[tp-id='OL-2']" 688 } 689 "destination": { 690 "dest-node": "/network-topology/topology[topology- 691 id='WDM']/node[node-id='E']", 692 "dest-tp": "/network-topology/topology[topology- 693 id='WDM']/node[node-id='E']/termination-point[tp-id='OL-1']" 694 } 695 "supporting-link": [], 696 "igp-link-attributes": { 697 "abstract-link-attributes": { 698 "srlg": { 699 "interface-switching-capabilities": [ 700 { 701 "switching-capability": "LSC", 702 "encoding": 12, // G.709 OKUk, RFC4328 703 "max-lsp-bandwidth": [ 704 { 705 "priority": 7, 706 "bandwidth": 1254659200.0 // ODU2 RFC7138 707 } 708 ] // max-lsp-bandwidth 709 } 710 ] // interface-switching-capabilities 711 } 712 "is-virtual": false 713 } // abstract-link-attributes 714 } // igp-link-attributes 715 }, // link F-E 716 { 717 "link-id": "E#102-H#101", 718 "source": { 719 "source-node": "/network-topology/topology[topology- 720 id='WDM']/node[node-id='E']", 721 "source-tp": "/network-topology/topology[topology- 722 id='WDM']/node[node-id='E']/termination-point[tp-id='OL-2']" 723 } 724 "destination": { 725 "dest-node": "/network-topology/topology[topology- 726 id='WDM']/node[node-id='H']", 727 "dest-tp": "/network-topology/topology[topology- 728 id='WDM']/node[node-id='H']/termination-point[tp-id='OL-1']" 729 } 730 "supporting-link": [], 731 "igp-link-attributes": { 732 "abstract-link-attributes": { 733 "srlg": { 734 "interface-switching-capabilities": [ 735 { 736 "switching-capability": "LSC", 737 "encoding": 12, // G.709 OKUk, RFC4328 738 "max-lsp-bandwidth": [ 739 { 740 "priority": 7, 741 "bandwidth": 1254659200.0 // ODU2 RFC7138 742 } 743 ] // max-lsp-bandwidth 744 } 745 ] // interface-switching-capabilities 746 } 747 "is-virtual": false 748 } // abstract-link-attributes 749 } // igp-link-attributes 750 }, // link E-H 751 { 752 "link-id": "H#101-E#102", 753 "source": { 754 "source-node": "/network-topology/topology[topology- 755 id='WDM']/node[node-id='H']", 756 "source-tp": "/network-topology/topology[topology- 757 id='WDM']/node[node-id='H']/termination-point[tp-id='OL-1']" 758 } 759 "destination": { 760 "dest-node": "/network-topology/topology[topology- 761 id='WDM']/node[node-id='E']", 762 "dest-tp": "/network-topology/topology[topology- 763 id='WDM']/node[node-id='E']/termination-point[tp-id='OL-2']" 764 } 765 "supporting-link": [], 766 "igp-link-attributes": { 767 "abstract-link-attributes": { 768 "srlg": { 769 "interface-switching-capabilities": [ 770 { 771 "switching-capability": "LSC", 772 "encoding": 12, // G.709 OKUk, RFC4328 773 "max-lsp-bandwidth": [ 774 { 775 "priority": 7, 776 "bandwidth": 1254659200.0 // ODU2 RFC7138 777 } 778 ] // max-lsp-bandwidth 779 } 780 ] // interface-switching-capabilities 781 } 782 "is-virtual": false 783 } // abstract-link-attributes 784 } // igp-link-attributes 785 }, // link H-E 786 { 787 "link-id": "F#101-G#102", 788 "source": { 789 "source-node": "/network-topology/topology[topology- 790 id='WDM']/node[node-id='F']", 791 "source-tp": "/network-topology/topology[topology- 792 id='WDM']/node[node-id='F']/termination-point[tp-id='OL-1']" 793 } 794 "destination": { 795 "dest-node": "/network-topology/topology[topology- 796 id='WDM']/node[node-id='G']", 797 "dest-tp": "/network-topology/topology[topology- 798 id='WDM']/node[node-id='G']/termination-point[tp-id='OL-2']" 799 } 800 "supporting-link": [], 801 "igp-link-attributes": { 802 "abstract-link-attributes": { 803 "srlg": { 804 "interface-switching-capabilities": [ 805 { 806 "switching-capability": "LSC", 807 "encoding": 12, // G.709 OKUk, RFC4328 808 "max-lsp-bandwidth": [ 809 { 810 "priority": 7, 811 "bandwidth": 1254659200.0 // ODU2 RFC7138 812 } 813 ] // max-lsp-bandwidth 814 } 815 ] // interface-switching-capabilities 816 } 817 "is-virtual": false 818 } // abstract-link-attributes 819 } // igp-link-attributes 820 }, // link F-G 821 { 822 "link-id": "G#102-F#101", 823 "source": { 824 "source-node": "/network-topology/topology[topology- 825 id='WDM']/node[node-id='G']", 826 "source-tp": "/network-topology/topology[topology- 827 id='WDM']/node[node-id='G']/termination-point[tp-id='OL-2']" 828 } 829 "destination": { 830 "dest-node": "/network-topology/topology[topology- 831 id='WDM']/node[node-id='F']", 832 "dest-tp": "/network-topology/topology[topology- 833 id='WDM']/node[node-id='F']/termination-point[tp-id='OL-1']" 834 } 835 "supporting-link": [], 836 "igp-link-attributes": { 837 "abstract-link-attributes": { 838 "srlg": { 839 "interface-switching-capabilities": [ 840 { 841 "switching-capability": "LSC", 842 "encoding": 12, // G.709 OKUk, RFC4328 843 "max-lsp-bandwidth": [ 844 { 845 "priority": 7, 846 "bandwidth": 1254659200.0 // ODU2 RFC7138 847 } 848 ] // max-lsp-bandwidth 849 } 850 ] // interface-switching-capabilities 851 } 852 "is-virtual": false 853 } // abstract-link-attributes 854 } // igp-link-attributes 855 }, // link G-F 856 { 857 "link-id": "G#101-H#102", 858 "source": { 859 "source-node": "/network-topology/topology[topology- 860 id='WDM']/node[node-id='G']", 861 "source-tp": "/network-topology/topology[topology- 862 id='WDM']/node[node-id='G']/termination-point[tp-id='OL-1']" 863 } 864 "destination": { 865 "dest-node": "/network-topology/topology[topology- 866 id='WDM']/node[node-id='H']", 867 "dest-tp": "/network-topology/topology[topology- 868 id='WDM']/node[node-id='H']/termination-point[tp-id='OL-2']" 869 } 870 "supporting-link": [], 871 "igp-link-attributes": { 872 "abstract-link-attributes": { 873 "srlg": { 874 "interface-switching-capabilities": [ 875 { 876 "switching-capability": "LSC", 877 "encoding": 12, // G.709 OKUk, RFC4328 878 "max-lsp-bandwidth": [ 879 { 880 "priority": 7, 881 "bandwidth": 1254659200.0 // ODU2 RFC7138 882 } 883 ] // max-lsp-bandwidth 884 } 885 ] // interface-switching-capabilities 886 } 887 "is-virtual": false 888 } // abstract-link-attributes 889 } // igp-link-attributes 890 }, // link G-H 891 { 892 "link-id": "H#102-G#101", 893 "source": { 894 "source-node": "/network-topology/topology[topology- 895 id='WDM']/node[node-id='H']", 896 "source-tp": "/network-topology/topology[topology- 897 id='WDM']/node[node-id='H']/termination-point[tp-id='OL-2']" 898 } 899 "destination": { 900 "dest-node": "/network-topology/topology[topology- 901 id='WDM']/node[node-id='G']", 902 "dest-tp": "/network-topology/topology[topology- 903 id='WDM']/node[node-id='G']/termination-point[tp-id='OL-1']" 904 } 905 "supporting-link": [], 906 "igp-link-attributes": { 907 "abstract-link-attributes": { 908 "srlg": { 909 "interface-switching-capabilities": [ 910 { 911 "switching-capability": "LSC", 912 "encoding": 12, // G.709 OKUk, RFC4328 913 "max-lsp-bandwidth": [ 914 { 915 "priority": 7, 916 "bandwidth": 1254659200.0 // ODU2 RFC7138 917 } 918 ] // max-lsp-bandwidth 919 } 920 ] // interface-switching-capabilities 921 } 922 "is-virtual": false 923 } // abstract-link-attributes 924 } // igp-link-attributes 925 } // link H-G 926 ], 927 }, // topology "WDM" 928 { 929 "topology-id": "VN1", 930 "topology-types": { 931 "l3-unicast-igp-topology": { 932 "abstract": {} 933 } 934 }, 935 "node": [ 936 { 937 "node-id": "E", 938 "supporting-node": [ 939 { 940 "node-ref": "E" 941 } 942 ] 943 }, // ref to E 944 { 945 "node-id": "F", 946 "supporting-node": [ 947 { 948 "node-ref": "F" 949 } 950 ] 951 } // ref to F 952 ] 953 }, // topoloty "VN1" 954 { 955 "topology-id": "VN2", 956 "topology-types": { 957 "l3-unicast-igp-topology": { 958 "abstract": {} 959 } 960 }, 961 "node": [ 962 { 963 "node-id": "G", 964 "supporting-node": [ 965 { 966 "node-ref": "G" 967 } 968 ] 969 }, // ref to G 970 { 971 "node-id": "H", 972 "supporting-node": [ 973 { 974 "node-ref": "H" 975 } 976 ] 977 } // ref to H 978 ] 979 } // topoloty "VN2" 980 ] 981 } // network-topology 982 } 984 4. Abstract Network Topology YANG module 986 file "abstract-topology@2014-07-01.yang" 988 module abstract-topology { 989 yang-version 1; 990 namespace "urn:ietf:params:xml:ns:yang:abstract-topology"; 991 // replace with IANA namespace when assigned 993 prefix "abst"; 995 import ietf-yang-types { 996 prefix "yang"; 997 } 999 import network-topology { 1000 prefix "nt"; 1001 } 1003 import l3-unicast-igp-topology { 1004 prefix "l3t"; 1005 } 1007 import ted { 1008 prefix "ted"; 1009 } 1011 organization "TBD"; 1012 contact "TBD"; 1013 description "Abstract topology model"; 1015 revision "2014-07-01" { 1016 description "Initial revision"; 1017 reference "TBD"; 1018 } 1020 grouping abstract-topology-type { 1021 description 1022 "Identifies the abstract topology type."; 1023 container abstract { 1024 presence "indicates abstract topology"; 1025 description 1026 "Its presence identifies the abstract topology type."; 1027 } 1028 } 1030 augment "/nt:network-topology/nt:topology/nt:topology-types/" 1031 + "l3t:l3-unicast-igp-topology" { 1032 description 1033 "Defines the abstract topology type."; 1034 uses abstract-topology-type; 1035 } 1037 grouping te-path-element { 1038 description 1039 "A group of attributes defining an element in a TE path"; 1040 leaf loose { 1041 type boolean; 1042 description "true if the element is loose."; 1043 } 1044 choice element-type { 1045 description "Attributes for various element types."; 1046 case numbered-link { 1047 leaf link-ipv4 { 1048 type uint32; 1049 description "IPv4 address in 4 byte integer format."; 1050 } 1051 } 1052 case unnumbered-link { 1053 leaf link-node-id { 1054 type uint32; 1055 description 1056 "Node ID of the node where the link end point resides."; 1057 } 1058 leaf link-id { 1059 type uint32; 1060 description "Identifies the link end point"; 1061 } 1062 } 1063 case node { 1064 leaf node-id { 1065 type uint32; 1066 description "Identifies the node."; 1067 } 1068 } 1069 case label { 1070 leaf label { 1071 type uint32; 1072 description "Identifies the label"; 1073 } 1074 } 1075 } 1076 } // te-path-element 1078 grouping config-schedule-attributes { 1079 description 1080 "A list of schedules defining when a particullar 1081 configuration takes effect."; 1082 list schedules { 1083 key "schedule-id"; 1084 description "A list of schedule elements."; 1085 leaf schedule-id { 1086 type uint32; 1087 description "Identifies the schedule element."; 1088 } 1089 leaf start { 1090 type yang:date-and-time; 1091 description "Start time."; 1092 } 1093 leaf schedule-duration { 1094 type string { 1095 pattern 1096 'P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?(\d+S)?'; 1097 } 1098 description "Schedule duration in ISO 8601 format."; 1099 } 1100 leaf repeat-interval { 1101 type string { 1102 pattern 1103 'R\d*/P(\d+Y)?(\d+M)?(\d+W)?(\d+D)?T(\d+H)?(\d+M)?' 1104 + '(\d+S)?'; 1105 } 1106 description "Repeat interval in ISO 8601 format."; 1107 } 1108 } 1109 } 1111 grouping abstract-node-attributes { 1112 description "Node attributes in an abstract topology."; 1113 container abstract-node-attributes { 1114 description "Node attributes in an abstract topology."; 1115 uses config-schedule-attributes; 1116 leaf is-virtual { 1117 type boolean; 1118 description "true if the node is virtual."; 1119 } 1120 leaf underlay-topology { 1121 type nt:topology-ref; 1122 description 1123 "When a node contains a topology, such as a virtual node, 1124 this reference points to the topology that defines the 1125 topology inside this node."; 1127 } 1128 list connectivity-matrix { 1129 key "from-tp to-tp"; 1130 description 1131 "Representation of the limit to the connectivity within 1132 the node"; 1133 leaf from-tp { 1134 type nt:tp-ref; 1135 description 1136 "Reference to source connectivity point."; 1137 } 1138 leaf to-tp { 1139 type nt:tp-ref; 1140 description 1141 "Reference to destination connectivity point."; 1142 } 1143 } 1144 container ted { 1145 description "Includes TE node attributes."; 1146 uses ted:ted-node-attributes; 1147 } 1148 } 1149 } // abstract-node-attributes 1151 grouping abstract-tp-attributes { 1152 description 1153 "Termination point attributes in an abstract topology."; 1154 container abstract-tp-attributes { 1155 description 1156 "Termination point attributes in an abstract topology."; 1157 leaf node-ref { 1158 type nt:node-ref; 1159 description "Node where this termination point resides."; 1160 } 1161 } 1162 } // abstract-tp-attributes 1164 grouping abstract-link-attributes { 1165 description "Link attributes in an abstract topology."; 1166 container abstract-link-attributes { 1167 description "Link attributes in an abstract topology."; 1168 uses config-schedule-attributes; 1169 leaf advertising-node-src { 1170 type nt:node-id; 1171 description 1172 "The node that advertises the source link end point"; 1173 } 1174 leaf advertising-node-des { 1175 type nt:node-id; 1176 description 1177 "The node that advertises the destination link end point"; 1178 } 1179 leaf is-virtual { 1180 type boolean; 1181 description "truel if the link is virtual."; 1182 } 1183 leaf-list melg { 1184 type uint32; 1185 config false; 1186 description "A list of MELG values of the link."; 1187 } 1188 leaf-list srclg { 1189 type uint32; 1190 config false; 1191 description "A list of SRcLG values of the link."; 1192 } 1193 container server-path { 1194 description 1195 "The service path on the server layer that supports this 1196 link."; 1197 list path-element { 1198 key "path-element-id"; 1199 description 1200 "A list of path elements describing the service path"; 1201 leaf path-element-id { 1202 type uint32; 1203 description "To identify the element in a path."; 1204 } 1205 uses te-path-element; 1206 } 1207 } // server-path 1208 container server-backup-path { 1209 description 1210 "The backup service path on the server layer that 1211 supports this link."; 1212 list path-element { 1213 key "path-element-id"; 1214 description 1215 "A list of path elements describing the backup service 1216 path"; 1217 leaf path-element-id { 1218 type uint32; 1219 description "To identify the element in a path."; 1220 } 1221 uses te-path-element; 1222 } 1223 } // server-backup-path 1224 leaf server-protection-type { 1225 type uint16; 1226 description 1227 "Server layer protection type desired for this link"; 1228 } 1229 leaf server-trail-src { 1230 type nt:tp-ref; 1231 description 1232 "Source termination point of the server layer trail."; 1233 } 1234 leaf server-trail-des { 1235 type nt:tp-ref; 1236 description 1237 "Destination termination point of the server layer 1238 trail."; 1239 } 1240 container ted { 1241 description "Includes TE link attributes."; 1242 uses ted:ted-link-attributes; 1243 } 1244 } 1245 } // abstract-link-attributes 1247 augment "/nt:network-topology/nt:topology/nt:node/" 1248 + "nt:termination-point/" 1249 + "l3t:igp-termination-point-attributes" { 1251 when "../../../topology-types/abstract-topology" { 1252 description 1253 "The augment is valid only for abstract topology."; 1254 } 1255 description "Augments attributes on a termination point."; 1256 uses abstract-tp-attributes; 1257 } 1259 augment "/nt:network-topology/nt:topology/nt:node/" 1260 + "l3t:igp-node-attributes" { 1261 when "../../topology-types/abstract-topology" { 1262 description 1263 "The augment is valid only for abstract topology."; 1264 } 1265 description "Augments attributes on a node."; 1266 uses abstract-node-attributes; 1267 } 1269 augment "/nt:network-topology/nt:topology/nt:link/" 1270 + "l3t:igp-link-attributes" { 1271 when "../../topology-types/abstract-topology" { 1272 description 1273 "The augment is valid only for abstract topology."; 1274 } 1275 description "Augments attributes on a link."; 1276 uses abstract-link-attributes; 1277 } 1279 augment "/l3t:igp-node-event" { 1280 description "Augments node event."; 1281 uses abstract-topology-type; 1282 uses abst:abstract-node-attributes; 1283 } 1285 augment "/l3t:igp-link-event" { 1286 description "Augments link event."; 1287 uses abstract-topology-type; 1288 uses abst:abstract-link-attributes; 1289 } 1290 } 1291 1293 5. Security Considerations 1295 The abstract protocol used for sending the topology data MUST support 1296 authentication and SHOULD support encryption. The data-model by 1297 itself does not create any security implications. 1299 6. References 1301 6.1. Normative References 1303 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 1304 Network Configuration Protocol (NETCONF)", RFC 6020, 1305 October 2010. 1307 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 1308 October 2010. 1310 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. Bierman, 1311 "Network Configuration Protocol (NETCONF)", RFC 6241, June 1312 2011. 1314 [RFC2234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 1315 Syntax Specifications: ABNF", RFC 2234, Internet Mail 1316 Consortium and Demon Internet Ltd., November 1997. 1318 [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching 1319 (GMPLS) Signaling Functional Description", RFC 3471, 1320 January 2003. 1322 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual 1323 Conventions (TCs) for Multiprotocol Label Switching (MPLS) 1324 Management", RFC 3811, June 2004. 1326 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1327 "Multiprotocol Label Switching (MPLS) Traffic Engineering 1328 (TE) Management Information Base (MIB)", RFC 3812, June 1329 2004. 1331 [RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau, 1332 "Multiprotocol Label Switching (MPLS) Label Switching 1333 Router (LSR) Management Information Base (MIB)", RFC 3813, 1334 June 2004. 1336 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Rekhter, Y., 1337 "Generalized Multiprotocol Label Switching (GMPLS) User- 1338 Network Interface (UNI): Resource ReserVation Protocol- 1339 Traffic Engineering (RSVP-TE) Support for the Overlay 1340 Model", RFC4208, October 2005. 1342 [RFC4220] Dubuc, M., Nadeau, T., and Lang, J., " Traffic Engineering 1343 Link Management Information Base", RFC 4220, November 2005. 1345 [RFC4801] Nadeau, T., Ed. and A. Farrel, Ed., "Definitions of 1346 Textual Conventions for Multiprotocol Label Switching 1347 (MPLS) Management", RFC 4801, February 2007. 1349 [RFC4802] Nadeau, T., Ed. and A. Farrel, Ed., "Generalized 1350 Multiprotocol Label Switching (GMPLS) Traffic Engineering 1351 Management Information Base", RFC 4802, February 2007. 1353 6.2. Informative References 1355 [G.8080] ITU-T Rec. G.8080/Y.1304, "Architecture for the 1356 Automatically Switched Optical Network (ASON)," November 1357 2001 (and Revision, January 2003). For information on the 1358 availability of this document, please see 1359 http://www.itu.int. 1361 [I-D.clemm-netmod-yang-network-topo] 1363 A. Clemm, H. Ananthakrishnan, J. Medved, T. Tkacik, R. 1364 Varga, and N. Bahadur, "A YANG Data Model for Network 1365 Topologies", draft-clemm-i2rs-yang-network-topo-00 1367 [I-D.beeram-ccamp-melg] 1369 V. P. Beeram, I. Bryskin, "Mutually Exclusive Link Group 1370 (MELG)", draft-beeram-ccamp-melg-03 1372 [I-D.beeram-ccamp-srclg] 1374 V. P. Beeram, I. Bryskin, "Shared Resource Link Group 1375 (SRcLG)", draft-beeram-ccamp-srclg-01 1377 Authors' Addresses 1379 Xufeng Liu 1380 Ericsson 1382 Email: xufeng.liu@ericsson.com 1384 Igor Bryskin 1385 ADVA Optical Networking 1387 Email: ibryskin@advaoptical.com 1389 Alexander Clemm 1390 Cisco 1392 Email: alex@cisco.com 1394 Vishnu Pavan Beeram 1395 Juniper Networks 1397 Email: vbeeram@juniper.net