idnits 2.17.1 draft-ietf-teas-te-topo-and-tunnel-modeling-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([I-D.ietf-teas-yang-te-topo], [I-D.ietf-teas-yang-te]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 378 has weird spacing: '...ability ide...' == Line 465 has weird spacing: '...clusive enu...' == Line 509 has weird spacing: '...ability ide...' == Line 544 has weird spacing: '...clusive enu...' == Line 593 has weird spacing: '...ment-id uin...' == (13 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 22, 2019) is 1802 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'ITU-T G.800' is mentioned on line 1594, but not defined == Missing Reference: 'RFC 4427' is mentioned on line 1594, but not defined == Missing Reference: 'ITU-T G.808' is mentioned on line 1606, but not defined == Missing Reference: 'RFC7951' is mentioned on line 2639, but not defined == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 2620, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 2629, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-15 Summary: 2 errors (**), 0 flaws (~~), 15 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TEAS Working Group Igor Bryskin 2 Internet Draft Huawei Technologies 3 Intended status: Informational Vishnu Pavan Beeram 4 Tarek Saad 5 Juniper Networks 6 Xufeng Liu 7 Volta Networks 9 Expires: October 22, 2019 April 22, 2019 11 TE Topology and Tunnel Modeling for Transport Networks 12 draft-ietf-teas-te-topo-and-tunnel-modeling-04 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 This Internet-Draft will expire on October 22, 2019. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Abstract 54 This document describes how to model TE topologies and tunnels for 55 transport networks, by using the TE topology YANG model [I-D.ietf- 56 teas-yang-te-topo] and the TE tunnel YANG model [I-D.ietf-teas-yang- 57 te]. 59 Conventions used in this document 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC-2119 [RFC2119]. 65 Table of Contents 67 1. Modeling Considerations........................................3 68 1.1. TE Topology Model.........................................3 69 1.2. TE Topology Modeling Constructs...........................5 70 1.3. Abstract TE Topology Calculation, Configuration and 71 Maintenance...................................................22 72 1.3.1. Single-Node Abstract TE Topology....................23 73 1.3.2. Full Mesh Link Abstract TE Topology.................25 74 1.3.3. Star-n-Spokes Abstract TE Topology..................27 75 1.3.4. Arbitrary Abstract TE Topology......................28 76 1.3.5. Customized Abstract TE Topologies...................29 77 1.3.6. Hierarchical Abstract TE Topologies.................30 78 1.4. Merging TE Topologies Provided By Multiple Providers.....31 79 1.4.1. Dealing With Multiple Abstract TE Topologies Provided By 80 The Same Provider..........................................34 81 1.5. Configuring Abstract TE Topologies.......................36 82 1.6. TE Tunnel Model..........................................37 83 1.7. TE Tunnel/Transport Service Modeling Constructs..........39 84 1.7.1. Bidirectional Tunnels...............................53 85 1.8. Transport Service Mapping................................55 86 1.9. Multi-Domain Transport Service Coordination..............56 87 2. Use Cases.....................................................61 88 2.1. Use Case 1. Transport service control on a single layer 89 multi-domain transport network................................61 90 2.2. Use Case 2. End-to-end TE tunnel control on a single layer 91 multi-domain transport network................................69 92 2.3. Use Case 3. Transport service control on a ODUk/Och multi- 93 domain transport network with Ethernet access links...........73 94 2.4. Use Case 4. Transport service control on a ODUk/Och multi- 95 domain transport network with multi-function access links.....80 96 2.5. Use Case 5. Real time updates of IP/MPLS layer TE link 97 attributes that depend on supporting transport connectivity (e.g. 98 transport SRLGs, propagation delay, etc.).....................83 99 2.6. Use Case 6. Virtual Network Service......................84 100 3. Security Considerations.......................................87 101 4. IANA Considerations...........................................87 102 5. References....................................................88 103 5.1. Normative References.....................................88 104 5.2. Informative References...................................88 105 6. Acknowledgments...............................................88 106 Appendix A. Data Examples........................................89 107 A.1. Use Case 1...............................................89 108 A.1.1. Domain 1............................................89 109 A.1.2. Domain 2............................................96 110 A.1.3. Domain 3...........................................102 111 Authors' Addresses..............................................108 113 1. Modeling Considerations 115 1.1. TE Topology Model 117 The TE Topology Model is written in YANG modeling language. It is 118 defined and developed by the IETF TEAS WG and is documented as "YANG 119 Data Model for TE Topologies" [I-D.ietf-teas-yang-te-topo]. The model 120 describes a TE network provider's Traffic Engineering data store as 121 it is seen by a client. It allows for the provider to convey to each 122 of its clients: 124 o information on network resources available to the client in the 125 form of one or several native TE topologies (for example, one for 126 each layer network supported by the provider); 128 o one or several abstract TE topologies, customized on per-client 129 basis and sorted according to the provider's preference as to how 130 the abstract TE topologies are to be used by the client; 132 o updates with incremental changes happened to the previously 133 provided abstract/native TE topology elements; 135 o updates on telemetry/state information the client has expressed 136 interest in; 138 o overlay/underlay relationships between the TE topologies provided 139 to the client (e.g. TE path computed in an underlay TE topology 140 supporting a TE link in an overlay TE topology); 142 o client/server inter-layer adaptation relationships between the TE 143 topologies provided to the client in the form of TE inter-layer 144 locks or transitional links; 146 The TE Topology Model allows a network client to: 148 o (Re-)configure/negotiate abstract TE topologies provided to the 149 client by a TE network provider, so that said abstract TE 150 topologies optimally satisfy the client's needs, constraints and 151 optimization criteria, based on the client's network planning, 152 service forecasts, telemetry information extracted from the 153 network, previous history of service provisioning and performance 154 monitoring, etc.; 156 o Obtain abstract/native TE topologies from multiple providers and 157 lock them horizontally (inter-domain) and vertically (inter-layer) 158 into the client's own native TE topologies; 160 o Configure, with each provider the trigger, frequency and contents 161 of the TE topology update notifications; 163 o Configure, with each provider the trigger, frequency and contents 164 of the TE topology telemetry (e.g. statistics counters) update 165 notifications. 167 1.2. TE Topology Modeling Constructs 169 Figure 1. TE Topology 171 o TE domain - a multi-layer traffic engineered network under direct 172 and complete control of a single authority, network provider. TE 173 domain can be described by one or more TE topologies. For example, 174 separate TE topologies can describe each of the domain's layer 175 networks. TE domain can hierarchically encompass/parent other 176 (child) TE domains, and can be encompassed by its own parent. 178 o TE topology - a graphical representation of a TE domain. TE 179 topology is comprised of TE nodes (TE graph vertices) 180 interconnected via TE links (TE graph edges). 182 _____________________________________________________________________ 184 /* TE topology */ 185 augment /nw:networks/nw:network: 186 /* TE topology global ID */ 187 +--rw provider-id? te-types:te-global-id 188 +--rw client-id? te-types:te-global-id 189 +--rw te-topology-id? te-types:te-topology-id 190 .................................................................. 191 /* TE topology general parameters */ 192 | +--rw preference? uint8 193 | +--rw optimization-criterion? identityref 194 .................................................................. 196 /* TE topology list of TE nodes */ 197 augment /nw:networks/nw:network/nw:node: 198 +--rw te-node-id? te-types:te-node-id 199 .................................................................. 200 /* TE topology list of TE links */ 201 augment /nw:networks/nw:network/nt:link: 202 .................................................................. 203 /* TE topology list of TE link termination points */ 204 augment /nw:networks/nw:network/nw:node/nt:termination-point: 205 +--rw te-tp-id? te-types:te-tp-id 206 .................................................................. 207 _____________________________________________________________________ 209 Figure 2. TE Node 211 o TE node - an element of a TE topology (appears as a vertex on TE 212 graph). A TE node represents one or several nodes (physical 213 switches), or a fraction of a node. A TE node belongs to and is 214 fully defined in exactly one TE topology. A TE node is assigned a 215 TE topology scope-unique ID. TE node attributes include 216 information related to the data plane aspects of the associated 217 node(s) (e.g. TE node's connectivity matrix), as well as 218 configuration data (such as TE node name). A given TE node can be 219 reached on the TE graph, representing the TE topology, over one of 220 TE links terminated by the TE node. 222 _____________________________________________________________________ 224 /* TE node */ 225 augment /nw:networks/nw:network/nw:node: 226 /* TE node ID */ 227 +--rw te-node-id? te-types:te-node-id 228 .................................................................. 229 /* TE node general attributes */ 230 | +--rw te-node-attributes */ 231 .................................................................. 232 /* TE node connectivity matrices */ 233 | +--rw connectivity-matrices 234 .................................................................. 235 /* TE node underlay TE topology */ 236 | +--rw underlay-topology {te-topology-hierarchy}? 237 | +--rw network-ref? leafref 238 .................................................................. 239 /* TE node information sources*/ 240 | +--ro information-source-entry* [information-source] 241 .................................................................. 242 /* TE node statistics */ 243 +--ro statistics 244 .................................................................. 245 /* TE node TTP list */ 246 +--rw tunnel-termination-point* [tunnel-tp-id] 247 .................................................................. 248 _____________________________________________________________________ 249 o TE link - an element of a TE topology (appears as an edge on TE 250 graph), TE link is unidirectional and its arrow indicates the TE 251 link's direction. Edges with two arrows on the TE topology graph 252 (see Figure 1) represent bi-directional combinations of two 253 parallel oppositely directed TE links. A TE link represents one or 254 several physical links or a fraction of a physical link. A TE 255 link belongs to and is fully defined in exactly one TE topology. A 256 TE link is assigned a TE topology scope-unique ID. TE link 257 attributes include parameters related to the data plane aspects of 258 the associated link(s) (e.g. unreserved bandwidth, resource 259 maps/pools, etc.), as well as the configuration data (such as 260 remote node/link IDs, SRLGs, administrative colors, etc.) A TE 261 link is connected to a TE node, terminating the TE link via 262 exactly one TE link termination point (LTP). 264 _____________________________________________________________________ 266 /* TE link */ 267 augment /nw:networks/nw:network/nt:link: 268 /* TE link bundle information */ 269 | +--rw (bundle-stack-level)? 270 | | | +--rw bundled-links 271 | | +--rw component-links 272 .................................................................. 273 /* TE link general attributes */ 274 | +--rw te-link-attributes 276 .................................................................. 277 /* TE link underlay TE topology */ 278 | +--rw underlay! {te-topology-hierarchy}? 279 | | +--rw primary-path 280 | | +--rw backup-path* [index] 282 .................................................................. 283 /* TE link layer network */ 284 | +--rw interface-switching-capability* [switching- 285 capability encoding] 287 .................................................................. 288 /* TE link protection type */ 289 | | +--rw protection-type? uint16 291 .................................................................. 293 /* TE link supporting TE tunnels */ 294 | | +--rw tunnels 296 .................................................................. 297 /* TE link transitional link flag */ 298 | +--ro is-transitional? empty 300 .................................................................. 301 /* TE link information sources */ 302 | +--ro information-source? te-info-source 304 .................................................................. 305 /* TE link statistics */ 306 +--ro statistics 308 .................................................................. 309 _____________________________________________________________________ 311 o Intra-domain TE link - TE link connecting two TE nodes within the 312 same TE topology representing a TE network domain (e.g. L14 in 313 Figure 1). From the point of view of the TE topology where the 314 intra-domain TE link is defined, the TE link is close-ended, that 315 is, both local and remote TE nodes of the link are defined in the 316 same TE topology. 318 o Inter-domain TE link - TE link connecting two border TE nodes 319 that belong to separate TE topologies describing neighboring TE 320 network domains (e.g. L3x in Figure 1). From the point of view of 321 the TE topology where the inter-domain TE link is defined, the TE 322 link is open-ended, that is, the remote TE node of the link is not 323 defined in the TE topology where the local TE node and the TE link 324 itself are defined. 326 [Note: from the point of view of a TE node terminating an inter- 327 domain TE link there is no difference between inter-domain and 328 access TE links] 330 o Access TE link - TE link connecting a border TE node of a TE 331 topology describing a TE network domain to a TE node of a TE 332 topology describing a customer network site (e.g. L1x in Figure 1) 333 From the point of view of the TE topology where the access TE link 334 is defined, the TE link is open-ended, that is, the remote TE node 335 of the link (t.e. TE node representing customer network 336 element(s)) is not defined in the TE topology where the local TE 337 node and the TE link itself are defined. 339 [Note: from the point of view of a TE node terminating an access 340 TE link there is no difference between access and inter-domain TE 341 links] 343 o Dynamic TE link - a TE link that shows up in (and disappears 344 from) a TE topology as a result of multi-layer traffic 345 engineering. Dynamic TE link (supported by a hierarchy TE tunnel 346 dynamically set up in a server layer network) is automatically 347 (i.e. without explicit configuration request) added to a client 348 layer network TE topology to augment the topology with additional 349 flexibility to ensure successful completion of the path 350 computation for and provisioning of a client layer network 351 connection/LSP. For example, an ODUk hierarchy TE tunnel can 352 support a dynamic Ethernet layer TE link to enable provisioning of 353 an Ethernet layer connection on a network that does not have 354 sufficient static Ethernet layer connectivity. Likewise, dynamic 355 TE link is automatically removed from the TE topology (and its 356 supporting hierarchy TE tunnel released) as soon as the TE link 357 stops carrying client layer connections/LSPs. 359 o TE link termination point (LTP) - a conceptual point of connection 360 of a TE node to one of the TE links terminated by the TE node (see 361 Figure 2a). Unlike TE link, LTP is bi-directional - an inbound TE 362 link and an oppositely directed outbound TE link have to be 363 connected to the TE node via the same LTP to constitute a bi- 364 directional TE link combination. 366 Figure 2a. Bi-directional TE link combination (left), independent 367 uni-directional TE links (right) 369 _____________________________________________________________________ 371 /* LTP */ 372 augment /nw:networks/nw:network/nw:node/nt:termination-point: 373 /* LTP ID */ 374 +--rw te-tp-id? te-types:te-tp-id 375 /* LTP network layer ID */ 376 | +--rw interface-switching-capability* [switching- 377 capability encoding] 378 | | +--rw switching-capability identityref 379 | | +--rw encoding identityref 380 /* LTP bandwidth information */ 381 | | +--rw max-lsp-bandwidth* [priority] 382 | | +--rw priority uint8 383 | | +--rw bandwidth? te-bandwidth 384 /* LTP inter-layer locks */ 385 | +--rw inter-layer-lock-id? uint32 387 .................................................................. 388 _____________________________________________________________________ 390 o TE tunnel termination point (TTP) - an element of TE topology 391 representing one or several potential TE tunnel 392 termination/adaptation points (e.g. OCh layer transponder). A TTP 393 is hosted by exactly one TE node (see Figure 2). A TTP is assigned 394 a TE node scope-unique ID. Depending on the TE node's internal 395 constraints, a given TTP hosted by the TE node could be accessed 396 via one, several or all TE links originated/terminated from/by the 397 TE node. TTP's important attributes include Local Link 398 Connectivity List, Adaptation Client Layer List, TE inter-layer 399 locks (see below), Unreserved Adaptation Bandwidth (announcing the 400 TTP's remaining adaptation resources sharable between all 401 potential client LTPs), and Property Flags (indicating 402 miscellaneous properties of the TTP, such as capability to support 403 1+1 protection for a TE tunnel terminated on the TTP). 405 _____________________________________________________________________ 407 /* TTP */ 408 +--rw tunnel-termination-point* [tunnel-tp-id] 409 /* TTP ID */ 410 +--rw tunnel-tp-id binary 411 /* TTP layer network ID */ 412 | +--rw switching-capability? identityref 413 | +--rw encoding? identityref 414 //* Inter-layer-locks supported by TTP */ 415 | +--rw inter-layer-lock-id? uint32 416 /* TTP's protection capabilities */ 417 | +--rw protection-type? identityref 418 /* TTP's list of client layer users */ 419 | +--rw client-layer-adaptation 421 .................................................................. 422 /* TTP's Local Link Connectivity List (LLCL) */ 423 | +--rw local-link-connectivities 425 .................................................................. 426 _____________________________________________________________________ 428 o Label - in the context of circuit switched layer networks 429 identifies a particular resource on a TE link (e.g. Och 430 wavelength, ODUk container) 432 +--:(label) 433 +--rw value? rt-types:generalized-label 435 Figure 3. TTP Local Link Connectivity List 437 o TTP basic local link connectivity list (basic LLCL) - a list of TE 438 link/label combinations terminated by the TTP-hosting TE node 439 (effectively the same as LTP/label pairs), which the TTP could be 440 connected to (see Figure 3, upper left). From the point of view of 441 a potential TE path, basic LLCL provides a list of permissible 442 LTP/label pairs the TE path needs to start/stop on for a 443 connection, taking the TE path, to be successfully terminated on 444 the TTP in question. 446 o TTP detailed local link connectivity list (detailed LLCL) - basic 447 LLCL extended to provide a set of costs (such as intra-node 448 summary TE metric, delay, SRLGs, etc.) associated with each LLCL 449 entry (see Figure 3, upper right) 451 _____________________________________________________________________ 453 /* TTP LLCL */ 454 | +--rw local-link-connectivities 455 | +--rw number-of-entries? uint16 456 /* LLCL entry */ 458 /* LLCL entry LTP */ 459 | +--rw link-tp-ref leafref 461 .................................................................. 463 /* LLC entry label range */ 464 | +--rw label-restriction* [inclusive-exclusive label-start] 465 | | +--rw inclusive-exclusive enumeration 466 | | +--rw label-start rt-types:generalized-label 467 | | +--rw label-end? rt-types:generalized- 468 label 469 | | +--rw range-bitmap? binary 471 /* LLCL entry underlay TE path(s) */ 472 | +--rw underlay! {te-topology-hierarchy}? 473 | | +--rw primary-path 474 | | +--rw backup-path* [index] 475 /* LLCL entry protection type */ 476 | | +--rw protection-type? uint16 477 /* LLCL entry supporting TE tunnels */ 478 | | +--rw tunnels 479 /* LLCL entry bandwidth parameters */ 480 | +--rw max-lsp-bandwidth* [priority] 482 .................................................................. 484 /* LLCL entry metrics (vector of costs) */ 485 | +--rw te-default-metric? uint32 486 | +--rw te-delay-metric? uint32 487 | +--rw te-srlgs 488 | | +--rw value* te-types:srlg 489 | +--rw te-nsrlgs {nsrlg}? 491 .................................................................. 492 /* LLCL entry ID */ 493 | | +--rw id* uint32 494 _____________________________________________________________________ 496 o TTP adaptation client layer list - a list of client layers that 497 could be directly adopted by the TTP. This list is necessary to 498 describe complex multi-layer (more than two layer) client-server 499 layer hierarchies and, in particular, to identify the position of 500 the TTP in said hierarchies. 502 _____________________________________________________________________ 504 /* TTP adaptation client layer list */ 505 | +--rw client-layer-adaptation 506 | | +--rw switching-capability* [switching-capability 507 encoding] 508 /* Client layer ID */ 509 | | +--rw switching-capability identityref 510 | | +--rw encoding identityref 511 /* Adaptation bandwidth available for the client layer */ 512 | | +--rw bandwidth? te-bandwidth 513 _____________________________________________________________________ 514 Figure 4. TE Node Connectivity Matrix 516 o TE node basic connectivity matrix - a TE node attribute describing 517 the TE node's switching capabilities/limitations in the form of 518 permissible switching combinations of the TE node's LTP/label 519 pairs (see Figure 4, upper left). From the point of view of a 520 potential TE path arriving at the TE node at a given inbound 521 LTP/label, the node's basic connectivity matrix describes 522 permissible outbound LTP/label pairs for the TE path to leave the 523 TE node. 525 o TE node detailed connectivity matrix - TE node basic connectivity 526 matrix extended to provide a set of costs (such as intra-node 527 summary TE metric, delay, SRLGs, etc.) associated with each 528 connectivity matrix entry (see Figure 4, upper right). 530 _____________________________________________________________________ 532 /* TE node connectivity matrix */ 533 | +--rw connectivity-matrix* [id] 534 | +--rw id uint32 535 | +--rw from /* left LTP */ 536 | | +--rw tp-ref? leafref 537 | +--rw to /* right LTP */ 538 | | +--rw tp-ref? leafref 539 | +--rw is-allowed? boolean 541 /* Connectivity matrix entry label range */ 542 | +--rw label-restriction* [inclusive-exclusive 543 label-start] 544 | | +--rw inclusive-exclusive enumeration 545 | | +--rw label-start rt- 546 types:generalized-label 547 | | +--rw label-end? rt- 548 types:generalized-label 549 | | +--rw range-bitmap? binary 551 /* Connectivity matrix entry underlay TE path(s) */ 552 | +--rw underlay! {te-topology-hierarchy}? 553 | | +--rw primary-path 554 | | +--rw backup-path* [index] 555 /* Connectivity matrix entry protection type */ 556 | | +--rw protection-type? uint16 557 /* Connectivity matrix entry supporting TE tunnels */ 558 | | +--rw tunnels 559 /* Connectivity matrix entry bandwidth parameters */ 560 | +--rw max-lsp-bandwidth* [priority] 562 .................................................................. 563 /* Connectivity matrix entry metrics (vector of costs) */ 564 | +--rw te-default-metric? uint32 565 | +--rw te-delay-metric? uint32 566 | +--rw te-srlgs 567 | | +--rw value* te-types:srlg 568 | +--rw te-nsrlgs {nsrlg}? 570 .................................................................. 571 /* Connectivity matrix entry ID */ 572 | | +--rw id* uint32 573 _____________________________________________________________________ 574 Figure 5. TE Path 576 o TE path - an ordered list of TE node/link IDs (each possibly 577 augmented with labels) that interconnects over a TE topology a 578 pair of TTPs and could be used by a connection (see Figure 5). A 579 TE path could, for example, be a product of a successful path 580 computation performed for a given TE tunnel 582 _____________________________________________________________________ 584 /* TE path */ 586 /* TE topology the path is defined in */ 587 | | | +--rw network-ref? leafref 588 /* Path type (IRO, XRO, ERO, RRO) */ 589 | | | +--rw path-type? identityref 591 /* TE path elements */ 592 | | | +--rw path-element* [path-element-id] 593 | | | +--rw path-element-id uint32 594 | | | +--rw index? uint32 595 | | | +--rw (type)? 596 /* Numbered TE link path element */ 597 | | | +--:(ip-address) 598 | | | | +--rw ip-address-hop 599 | | | | +--rw address? inet:ip-address 600 | | | | +--rw hop-type? te-hop-type 601 /* AS number path element */ 602 | | | +--:(as-number) 603 | | | | +--rw as-number-hop 604 | | | | +--rw as-number? binary 605 | | | | +--rw hop-type? te-hop-type 606 /* Unnumbered TE link path element */ 607 | | | +--:(unnumbered-link) 608 | | | | +--rw unnumbered-hop 609 | | | | +--rw te-node-id? inet:ip-address 610 | | | | +--rw tp-id? uint32 611 | | | | +--rw hop-type? te-hop-type 612 /* Label path element */ 613 | | | +--:(label) 614 | | | | +--rw label-hop 615 | | | | +--rw value? rt-types:generalized-label 616 | | | | +--rw direction? boolean 617 | | | +--:(sid) 618 | | | +--rw sid-hop 619 | | | +--rw sid? rt-types:generalized-label 620 _____________________________________________________________________ 622 o TE path segment - a contiguous fragment of a TE path 624 Figure 6. TE Inter-Layer Lock 626 o TE inter-layer lock - a modeling concept describing client-server 627 layer adaptation relationships important for multi-layer traffic 628 engineering. It is an association of M client layer LTPs and N 629 server layer TTPs, within which data arriving at any of the client 630 layer LTPs could be adopted onto any of the server layer TTPs. A 631 TE inter-layer lock is identified by inter-layer lock ID, which is 632 unique across all TE topologies provided by the same provider. The 633 client layer LTPs and the server layer TTPs associated by a given 634 TE inter-layer lock share the same inter-layer lock ID value. 636 In Figure 6 a TE inter-layer lock IL_1 associates six client layer 637 LTPs (C_LTP_1 - C_LTP_6) with two server layer TTPs (S_TTP_1 and 638 S_TTP_2). As mentioned, they all have the same attribute -inter- 639 layer lock ID: IL_1, which is the only parameter/value indicating 640 the association. A given LTP may have zero, one or more inter- 641 layer lock IDs. In the case of multiple inter-layer lock IDs, 642 this implies that the data arriving at the LTP can be adopted onto 643 any of TTPs associated with all specified inter-layer locks. For 644 example, C_LTP_1 may be attributed with two inter-layer locks- 645 IL_1 and IL_2. This would mean that C_LTP_1 for adaptation 646 purposes can use not just TTPs associated with inter-layer lock 647 IL_1 (i.e. S_TTP_1 and S_TTP_2 in the Figure), but any of TTPs 648 associated with inter-layer lock IL_2. Likewise, a given TTP may 649 have one or more inter-layer locks, meaning that it can offer the 650 adaptation service to any client layer LTP having an inter-layer 651 lock matching one of its own. 653 LTPs and TTPs associated within the same TE inter-layer lock may 654 be hosted by the same (hybrid, multi-layer) TE node or by multiple 655 TE nodes defined in the same or separate TE topologies. The latter 656 case is especially important because TE topologies of different 657 layer networks could be modeled by separate augmentations of the 658 basic (common to all layers) TE topology model. 660 | +--rw inter-layer-lock-id? uint32 662 o Transitional link - an alternative method of modeling of client- 663 server adaptation relationship. Transitional link is a bi- 664 directional link connecting an LTP in a client layer to an LTP in 665 a server layer, which is associated (via TTP's LLCL) with a server 666 layer TTP capable of adopting of the client layer data onto a TE 667 tunnel terminated by the TTP. Important attributes pf a 668 transitional link are loca;/remote LTP IDs, TE metric and 669 available adaptation bandwidth. 671 Figure 7. Native and Abstract TE Topologies 673 o Native TE topology - a TE topology as it is known (to full extent 674 and unmodified) to the TE topology provider (see lower part of 675 Figure 7.). A native TE topology might be discovered via various 676 routing protocols and/or subscribe/publish techniques. For 677 example, a first-level TE topology provider (such as a T-SDN 678 Domain Controller, DC) may auto-discover its native TE 679 topology(ies) by participating in the domain's OSPF-TE protocol 680 instance; while a second-level TE topology provider (such as a 681 Hierarchical T-SDN Controller. HC) normally builds its native TE 682 topology(ies) based on TE topologies exposed by each of the 683 subordinate, first- level TE topology providers. 685 o Underlay TE topology - a TE topology that serves as a base for 686 constructing overlay TE topologies. 688 o Overlay TE topology - a TE topology constructed based on one or 689 more underlay TE topologies. Each TE node of the overlay TE 690 topology represents a separate underlay TE topology (that could be 691 mapped onto an arbitrary segment of a native TE topology). Each TE 692 link of the overlay TE topology represents, generally speaking, an 693 arbitrary TE path in one of the underlay TE topologies. The 694 overlay TE topology and the supporting underlay TE topologies may 695 represent separate layer networks (e.g. OTN/ODUk and WDM/OCh 696 respectively) or the same layer network. 698 o Abstract TE topology - an overlay TE topology created by a 699 provider to describe its network in some abstract way. An abstract 700 TE topology contains at least one abstract TE topology element, 701 such as TE node or TE link. An abstract TE topology is built based 702 on contents of one or more of the provider's native TE topologies 703 (serving as underlay(s)), the provider's policies and the client's 704 preferences (see upper part of Figure 7). 706 o Customized TE topology - a TE topology tailored for a given 707 provider's client. A customized TE topology is usually but not 708 always an abstract TE topology. For example, a given abstract TE 709 topology could be exposed to a group or all provider's clients (in 710 which case the abstract TE topology is not a customized TE 711 topology). Likewise, a given naive TE topology could be customized 712 for a given client (for example, by removing high delay TE links 713 the client does not care about). So customized TE topology is not 714 an abstract TE topology, because it does not contain abstract TE 715 topology elements 717 o TE inter-domain plug - a TE link attribute meaningful for open- 718 ended inter-domain/access TE links. It contains a network-wide 719 unique value (inter-domain plug ID) that identifies in the network 720 a connectivity supporting the inter-domain/access TE link in 721 question. It is expected that a given pair of neighboring domain 722 TE topologies (provided by separate providers) will have each at 723 least one open-ended inter-domain/access TE link with a TE inter- 724 domain plug matching to one provided by its neighbor, thus 725 allowing for a client of both domains to identify adjacent nodes 726 in the separate neighboring TE topologies and resolve the open- 727 ended inter-domain/access TE links by connecting them regardless 728 of the links respective local/remote node ID/link ID attributes. 729 Inter-domain plug IDs may be assigned and managed by a central 730 network authority. Alternatively, inter-domain plug IDs could be 731 dynamically auto-discovered (e.g. via LMP protocol). 733 _____________________________________________________________________ 734 +--rw external-domain 735 | +--rw network-ref? leafref 736 | +--rw remote-te-node-id? te-types:te-node-id 737 | +--rw remote-te-link-tp-id? te-types:te-tp-id 738 | +--rw plug-id? uint32 739 _____________________________________________________________________ 741 1.3. Abstract TE Topology Calculation, Configuration and Maintenance 743 The TE Topology Model does not prescribe what and how abstract TE 744 topologies are computed, configured, manipulated and supported by a 745 TE network (e.g. transport network) provider. However, it is assumed 746 that: 748 o All TE topologies, native or abstract, conveyed to the same or 749 different clients, are largely independent one from another. This 750 implies that each TE topology, generally speaking, has an 751 independent name space for TE node and link IDs, SRLGs, etc. 752 (possibly overlapping with the name spaces of other TE 753 topologies); 755 o All abstract TE topologies are bound to the respective underlay 756 native or abstract TE topologies only by the overlay/underlay 757 relationships defined by the TE Topology Model, but, otherwise, 758 the abstract TE topologies are decoupled from their respective 759 underlay TE topologies. 761 It is envisioned that an original set of abstract TE topologies is 762 produced by a TE network provider for each of its clients based on 763 the provider's local configurations and/or policies, as well as the 764 client-specific profiles. The original set of abstract TE topologies 765 offered to a client may be accepted by the client as-is. 766 Alternatively, the client may choose to negotiate/re-configure the 767 abstract TE topologies, so that the latter optimally satisfy the 768 client's needs. In particular, for each of the abstract TE topologies 769 the client may request adding/removing TE nodes, TE links, TTPs 770 and/or modifying re-configurable parameters of the existing 771 components. The client may also request different optimization 772 criteria as compared to those used for the original abstract TE 773 topology optimization, or/and specify various topology-level 774 constraints. The provider may accept or reject all or some abstract 775 TE topology re-configuration requests. Hence, the abstract TE 776 topology negotiation process may take multiple iterations before the 777 provider and each of its clients agree upon a set of abstract TE 778 topologies and their contents. Furthermore, the negotiation process 779 could be repeated over time to produce new abstract TE topologies 780 optimal to best suit evolving circumstances. 782 Figure 8. Native Transport Network Domain TE Topology as an Underlay 783 for Abstract TE Topologies 785 Let's assume that a native transport network domain TE topology to be 786 as depicted in Figure 8. The popular types of abstract TE topologies 787 based on this native TE topology as an underlay are described in the 788 following sections. 790 1.3.1. Single-Node Abstract TE Topology 792 Figure 9. Blocking/Asymmetrical TE Node with Basic Connectivity 793 Matrix Attribute 795 In Figure 9, the transport network domain is presented to a client as 796 a one-node abstract TE topology, where the single TE node (AN1) 797 represents the entire domain and terminates all of the inter- 798 domain/access TE links connecting the domain to its adjacent domains 799 (i.e. TE links L1...L8). Because AN1 represents the entire domain the 800 node's Underlay TE Topology attribute matches the ID of one of the 801 domain's native TE topologies (e.g. one presented in Figure 8). 802 [Note: all or some of the underlay TE topologies a given abstract TE 803 topology depends on could be catered to the client by the provider 804 along with the abstract TE topology in question or upon separate 805 request(s) issued by the client.] 807 One important caveat about abstract TE node AN1 is that it should be 808 considered as an asymmetrical/blocking switch, because, generally 809 speaking, it is not guaranteed that a suitable TE path exists between 810 any given pair of inter-domain TE links into/out of the domain. This 811 means from the TE Topology model point of view that there are certain 812 limitations as to how AN1's LTPs could be interconnected 813 inside/across the TE node. The model allows for asymmetrical/blocking 814 switches by specifying for the associated TE nodes a non-empty basic 815 connectivity matrix attribute describing permissible inbound-outbound 816 TE link/label switching combinations. It is assumed that the 817 provider's path computer can compute a set of optimal TE paths, 818 connecting inbound TE link/label_x <=> outbound TE link/label_y 819 combinations inside the abstract TE node over the TE node's underlay 820 TE topology. Based on the results of such computations, AN1's 821 connectivity matrix can be (re-)generated and (re-)conveyed to the 822 abstract TE topology client. 824 A richer version of the basic connectivity matrix is the detailed 825 connectivity matrix. The latter not only describes permissible 826 inbound TE link/label_x <=> TE link/label TE link/label_y switching 827 combinations, but also provides connectivity matrix entry specific 828 vectors of various costs/metrics (in terms of delay, bandwidth, 829 intra-node SRLGs and summary TE metrics) that a potential TE path 830 will accrue, should a given connectivity matrix entry be selected by 831 the path for crossing the TE node (see Figure 10). 833 Figure 10. Blocking/Asymmetrical TE Node with Detailed Connectivity 834 Matrix Attribute 836 1.3.2. Full Mesh Link Abstract TE Topology 838 Figure 11. Full Mesh Link Abstract TE Topology 840 In Figure 11, the transport network domain is abstracted in the 841 following way. 843 o Each of the underlay native TE topology border TE nodes (i.e., the 844 TE nodes terminating at least one inter-domain/access TE link, 845 such as TE nodes S3 or S11 in Figure 8) is represented in the 846 abstract TE topology as a separate abstract TE node, matching one- 847 for-one to the respective border TE node of the underlay TE 848 topology. For example, S3' of the abstract TE topology represents 849 S3 of the underlay TE topology in Figure 8. [Note that such a 850 relationship is modeled via Supporting Node attribute of TE node 851 S3' specifying the ID of S3, as well as the ID of the TE topology 852 where S3 is defined (i.e. TE topology in Figure 8)]. Likewise, S9' 853 represents S9, S11' represents S11 and so forth; 855 o TE nodes S3', S5', S8', S9' and S11' are interconnected via a full 856 mesh of abstract TE links. It is assumed that the provider's path 857 computer can compute a set of optimal TE paths over one or more of 858 underlay TE topologies (such as presented in Figure 8)- one for 859 each of said abstract TE links; and the provider can set up the TE 860 tunnels in the network supporting each of the abstract TE links, 861 either during the abstract TE topology configuration (in the case 862 of committed/pre-established abstract TE links), or at the time 863 the first client's connection is placed on the abstract TE link in 864 question (the case of uncommitted abstract TE links). [Note that 865 so (re-)computed TE paths, as well as the IDs of respective 866 underlay TE topologies used for their computation are normally 867 catered to the client in the Underlay TE path attribute of the 868 associated abstract TE links] 870 The configuration parameters of each of the abstract TE links (such 871 as layer ID, bandwidth and protection requirements, preferred TE 872 paths across the underlay TE topology for the primary and backup 873 connections, etc.) are expected to be found in the abstract TE 874 topology profiles/templates locally configured with the provider or 875 pushed to the provider by the client via the policy NBI. Each of the 876 abstract TE links may be later re-configured or removed by direct 877 configuration requests issued by the client via TE Topology NBI. 878 Likewise, additional abstract TE links may be requested by the client 879 at any time. 881 Some possible variants/flavors of the Full Mesh Link Abstract TE 882 Topology described above are: 884 o Partial Mesh Link Abstract TE Topology (where some of the abstract 885 TE links from the full mesh are missing); 887 o Double Mesh Link Abstract TE Topology (where each pair of abstract 888 TE nodes is connected via two diverse abstract TE links). 890 1.3.3. Star-n-Spokes Abstract TE Topology 892 Figure 12. Star-n-Spoke Abstract TE Topology 894 The Full Mesh Link Abstract TE Topology suffers from the n-squared 895 problem; that is, the number of required abstract TE links is 896 proportional to square of the number of native TE topology border TE 897 nodes. This problem can be mitigated (i.e., the number of required 898 abstract TE links may be significantly reduced) by adding, to the 899 abstract TE topology, an additional abstract TE node (the star) 900 representing one or several interconnected non-border TE nodes from 901 the native TE topology. Abstract TE links in the Star-n-Spokes 902 Topology connect the star with all other TE nodes of the topology 903 (the spokes). For example, abstract TE node AN1 in Figure 12 could 904 represent collectively TE nodes S7, S10 and S4 of the native TE 905 topology (see Figure 8) with abstract TE links connecting AN1 with 906 all other TE nodes in the Star-n-Spokes Abstract TE Topology in 907 Figure 12. 909 In order to introduce a composite abstract TE node, (e.g. AN1 in 910 Figure 12) representing in a given abstract TE topology an arbitrary 911 segment of another TE topology (e.g. TE nodes S7, S12 and S4 of the 912 TE topology in Figure 8) the TE topology provider is expected to 913 perform the following operations: 915 o Copy the TE topology segment to be represented by the abstract TE 916 node (i.e. TE nodes S7, S10 and S4 in Figure 8, as well as the TE 917 links interconnecting them) into a separate auxiliary TE topology 918 (with a separate TE topology ID); 920 o Set for each TE node and TE link of the auxiliary TE topology the 921 Supporting Node/Link attribute matching the original TE topology 922 ID, as well as the ID of the respective original TE node/link of 923 the original TE topology. For example, if S7" of the auxiliary TE 924 topology is a copy of S7 of the original TE topology, the 925 Supporting Node attribute of S7" will specify the ID of the 926 original TE topology (presented in figure 8) and the ID of S7; 928 o Set for the abstract TE node AN1 the Underlay TE Topology 929 attribute matching the auxiliary TE Topology ID 931 Furthermore, the Star-n-Spokes Abstract TE topology provider is 932 expected to: 934 o Compute/provision TE paths/tunnels supporting each of the abstract 935 TE links in Figure 12 (i.e. abstract TE links connecting the 936 spokes to the star, AN1) as described in 1.3.2; 938 o Generate the AN1's Basic/Detailed Connectivity Matrix attribute 939 based on intra-node path computations performed on the AN1's 940 underlay (i.e. auxiliary) TE topology and describing permissible 941 inbound TE link/label_x. outbound TE link/label_y switching 942 combinations as described in 1.3.1 944 1.3.4. Arbitrary Abstract TE Topology 946 Figure 13. Arbitrary Abstract TE Topology 948 To achieve an optimal tradeoff between the number of components, the 949 amount of information exposed by a transport network provider and the 950 amount of path computations required to keep said information up-to- 951 date, the provider may present the TE network domain as an arbitrary 952 abstract TE topology comprised of any number of abstract TE nodes 953 interconnected by abstract TE links (see Figure 13). Each of the 954 abstract TE nodes can represent a single or several interconnected TE 955 nodes from the domain's underlay (native or lower level abstract) TE 956 topology, or a fraction of an underlay TE node. [Note that each of 957 the abstract TE nodes of the TE topology in Figure 13 is expected to 958 be introduced and maintained by the provider following the 959 instructions as described in 1.3.3; likewise, each of the abstract TE 960 links of the topology is expected to be computed, provisioned and 961 maintained as described in 1.3.2] 963 1.3.5. Customized Abstract TE Topologies 965 Figure 14. Customized Abstract TE Topology(ies) 967 A transport network/domain provider may serve more than one client. 968 In such a case, the provider "slices" the network/domain resources 969 and exposes a slice for each of the clients in the form of a 970 customized abstract TE topology. In Figure 14, the provider serves 971 two clients (Blue and Red). Client Blue is provided with the Blue 972 abstract TE topology supported by the blue TE tunnels or paths in the 973 underlay (native) TE topology (depicted in the Figure with blue 974 broken lines). Likewise, client Red is provided with the Red abstract 975 TE topology supported by the red TE tunnels or paths in the underlay 976 TE topology. 978 1.3.6. Hierarchical Abstract TE Topologies 980 Figure 15. Hierarchy of Abstract TE Topologies 982 As previously mentioned, an underlay TE topology for a given abstract 983 TE topology component does not have to be one of the domain's native 984 TE topologies - another (lower level) domain's abstract TTE topology 985 can be used instead. This means that abstract TE topologies are 986 hierarchical in nature. 988 Figure 15 provides an example of abstract TE topology hierarchy. In 989 this Figure the blue topology is a top level abstract TE topology 990 catered to by the provider to one of the domain's clients. One of the 991 TE links of the blue topology - link EF - is supported by a TE path 992 E'-M-P-Q-N-F' computed in the underlay TE topology (red topology), 993 which happens to be domain's (lower level) abstract TE topology.. 994 Furthermore, as shown, the TE link PQ - one of the TE links 995 comprising the E'-M-P-Q-N-F' path - is supported by its own underlay 996 TE path, P'-X-Q' - computed on one of the domain's native TE 997 topologies. 999 Importantly, each TE link and TE node of a given abstract TE topology 1000 has, generally speaking, its individual stack/hierarchy of underlay 1001 TE topologies. 1003 1.4. Merging TE Topologies Provided By Multiple Providers 1005 A client may receive TE topologies provided by multiple providers, 1006 each of which managing a separate domain of an interconnected multi- 1007 domain transport network. In order to make use of said topologies, 1008 the client is expected to merge (inter-connect) the provided TE 1009 topologies into one or more client's native TE topologies, each of 1010 which homogeneously representing the multi-domain transport network. 1011 This makes it possible for the client to select end-to-end TE paths 1012 for its TE tunnel connections traversing multiple domains. 1014 In particular, the process of merging TE topologies includes: 1016 o Identifying neighboring TE domains and locking their TE topologies 1017 horizontally by connecting their inter-domain open-ended TE links; 1019 o Renaming TE node, link, and SRLG IDs into ones allocated from a 1020 separate name space; this is necessary because all TE topologies 1021 are considered to be, generally speaking, independent with a 1022 possibility of clashes among TE node, link or SRLG IDs. Original 1023 TE node/link IDs along with the original TE topology ID are stored 1024 in the Source attribute of the respective TE nodes/links of the 1025 merged TE topology; 1027 o Locking, TE topologies associated with different layer networks 1028 vertically according to provided TE inter-layer locks; this is to 1029 facilitate inter-layer path computations across multiple TE 1030 topologies provided by the same topology provider. 1032 Figure 16. Merging Domain TE Topologies 1034 Figure 16 illustrates the process of merging, by the client, of TE 1035 topologies provided by the client's providers. 1037 In the Figure, each of the two providers caters to the client a TE 1038 topology (abstract or native), describing the network domain under 1039 the respective provider's control. The client, by consulting the 1040 attributes of the open-ended inter-domain/access TE links - such as 1041 TE inter-domain plugs or remote TE node/link IDs - is able to 1042 determine that: 1044 1. the two domains are adjacent and are interconnected via three 1045 inter-domain TE links, and; 1047 2. each domain is connected to a separate customer site, connecting 1048 the left domain in the Figure to customer devices C-11 and C-12, 1049 and the right domain to customer devices C-21, C-22 and C-23. 1051 Therefore, the client interconnects the open-ended TE links, as shown 1052 on the upper part of the Figure. 1054 As mentioned, one way to interconnect the open-ended inter- 1055 domain/access TE links of neighboring domains is to mandate the 1056 providers to specify remote nodeID/linkID attributes in the provided 1057 inter-domain/access TE links. This, however, may prove to be not 1058 flexible. For example, the providers may not be aware of the 1059 respective remote nodeID/linked values. More importantly, this option 1060 does not allow for the client to mix-n-match multiple (more than one) 1061 TE topologies catered by the same providers (see the next section). 1062 Another, more flexible, option to resolve the open-ended inter- 1063 domain/access TE links is by decorating them with the TE inter-domain 1064 plug attribute. The attribute specifies inter-domain plug ID - a 1065 network-wide unique value that identifies on the network connectivity 1066 supporting a given inter-domain/access TE link. Instead of specifying 1067 remote node ID/link ID, an inter-domain/access TE link may provide a 1068 non-zero inert-domain plug ID. It is expected that two neighboring 1069 domain TE topologies (provided by separate providers) will have each 1070 at least one open-ended inter-domain/access TE link with a TE inter- 1071 domain plug matching to one provided by its neighbor. For example, 1072 the inter-domain TE link originating from node S5 of the Domain 1 TE 1073 topology (Figure 8) and the inter-domain TE link coming from node S3 1074 of Domain2 TE topology may specify matching TE inter-domain plugs 1075 (i.e. carrying the same inter-domain plug ID). This would allow for 1076 the client to identify adjacent nodes in the separate neighboring TE 1077 topologies and resolve the inter-domain/access TE links connecting 1078 them regardless of their respective nodeIDs/linkIDs (which, as 1079 mentioned, could be allocated from independent name spaces). 1081 Inter-domain plug IDs may be assigned and managed by a central 1082 network authority. Alternatively, inter-domain plug IDs could be 1083 dynamically auto-discovered (e.g. via LMP protocol). 1085 Furthermore, the client renames the TE nodes, links and SRLGs offered 1086 in the abstract TE topologies by assigning to them IDs allocated from 1087 a separate name space managed by the client. Such renaming is 1088 necessary, because the two abstract TE topologies may have their own 1089 name spaces, generally speaking, independent one from another; hence, 1090 ID overlaps/clashes are possible. For example, both TE topologies 1091 have TE nodes named S7, which, after renaming, appear in the merged 1092 TE topology as S17 and S27 respectively. IDs of the original (i.e. 1093 abstract TE topology) TE nodes/links along with the ID of the 1094 abstract TE topology they belong to are stored in the Source 1095 attribute of the respective TE nodes/links of the merged TE topology. 1096 For example, the Source attribute of S27 will contain S7 and the TE 1097 topology ID of the abstract TE topology describing domain 2. 1099 Once the merging process is complete, the client can use the merged 1100 TE topology for path computations across both domains, for example, 1101 to compute a TE path connecting C-11 to C-23. 1103 1.4.1. Dealing With Multiple Abstract TE Topologies Provided By The Same 1104 Provider 1106 Figure 17. Multiple Abstract TE Topologies Provided By TE Topology 1107 Providers 1109 A given provider may expose more than one abstract TE topology to the 1110 client. For example, one abstract TE topology could be optimized 1111 based on a lowest-cost criterion, while another one could be based on 1112 best possible delay metrics, while yet another one could be based on 1113 maximum bandwidth availability for the client connections. 1114 Furthermore, the client may request all or some providers to expose 1115 additional abstract TE topologies, possibly of a different type 1116 and/or optimized differently, as compared to already-provided TE 1117 topologies. In any case, the client should be prepared for a provider 1118 to offer to the client more than one abstract TE topology. 1120 It should be up to the client to decide how to mix-and-match multiple 1121 abstract TE topologies provided by each of the providers, as well as 1122 how to merge them into the client's native TE topologies. The client 1123 also decides how many such merged TE topologies it needs to produce 1124 and maintain. For example, in addition to the merged TE topology 1125 depicted on the upper part of Figure 16, the client may merge the 1126 abstract TE topologies received from the two providers, as shown in 1127 Figure 17, into the client's additional native TE topologies, as 1128 shown in Figure 18. 1130 [Note: allowing for the client mix-n-matching of multiple TE 1131 topologies assumes that TE inter-domain plugs (rather than remote 1132 nodeID/linked) option is used for identifying neighboring domains and 1133 inter-domain/access TE link resolution.] 1135 Figure 18. Multiple Native (Merged) Client's TE Topologies 1137 It is important to keep in mind that each of the three native 1138 (merged) TE topologies could be used by the client for computing TE 1139 paths for any of the multi-domain connections. The choice as to which 1140 topology to use for a given connection depends on the 1141 connection/tunnel parameters/requirements and the topology's style 1142 and optimization criteria. 1144 1.5. Configuring Abstract TE Topologies 1146 When a client receives one or more abstract TE topologies from one of 1147 its providers, it may accept the topologies as-is and merge then into 1148 one or more of its own native TE topologies. Alternatively, the 1149 client may choose to request a re-configuration of one, some or all 1150 abstract TE topologies provided by the providers. Specifically, with 1151 respect to a given abstract TE topology, some of its TE nodes/links 1152 may be requested to be removed, while additional ones may be 1153 requested to be added. It is also possible that existing TE 1154 nodes/links may be asked to be re-configured. For example, a set of 1155 TE links may be requested to be disjoint from each other by 1156 configuring the same Non Sharing Risk Link Group (NSRLG) attribute 1157 for all links from the set. Such a configuration would force the 1158 provider to place TE tunnels supporting the TE links from the set 1159 onto sufficiently disjoint TE paths computed in the tunnels underlay 1160 TE topology. Furthermore, the topology-wide optimization criteria may 1161 be requested to be changed. For example, underlay TE paths supporting 1162 the abstract TE links, currently optimized to be shortest (least- 1163 cost) paths, may be requested to be re-optimized based on the minimal 1164 delay criteria. Additionally, the client may request the providers to 1165 configure entirely new abstract TE topologies and/or to remove 1166 existing ones. Furthermore, future periodic or one time additions, 1167 removals and/or re-configurations of abstract TE topology elements 1168 and/or their attributes could be (re-)scheduled by the client ahead 1169 of time. 1171 It is the responsibility of the client to implement the logic behind 1172 the above-described abstract TE topology negotiation. It is expected 1173 that the logic is influenced by the client's local 1174 configuration/templates, policies conveyed by client's clients, input 1175 from the network planning process, telemetry processor, analytics 1176 systems and/or direct human operator commands. Figure 19 exemplifies 1177 the abstract TE topology negotiation process. As shown in the Figure, 1178 the original abstract TE topology exposed by a provider was requested 1179 to be re-configured. Specifically, one of the abstract TE links was 1180 asked to be removed, while three new ones were asked to be added to 1181 the abstract TE topology. 1183 Figure 19. Provider. Client Abstract TE Topology Negotiation 1185 1.6. TE Tunnel Model 1187 The TE Tunnel Model is written in YANG modeling language. It is 1188 defined and developed by the IETF TEAS WG and is documented as "YANG 1189 Data Model for Traffic Engineering Tunnels and Interfaces" [I-D.ietf- 1190 teas-yang-te]. Among other things the model describes a TE network 1191 provider's TE Tunnel data store as it is seen and influenced by a 1192 client. 1194 The TE Tunnel Model allows for the provider to convey to each of its 1195 clients: 1197 o information on TE tunnels provided to the client that are fully 1198 contained within the controlled network domain, 1200 o information on multi-domain TE tunnel segments across the network 1201 domain controlled by the provider; 1203 o information on connections/LSPs, supporting TE tunnels and TE 1204 tunnel segments; 1206 o updates in response to changes to the client's active TE 1207 tunnels/segments and the connections supporting them, 1209 o updates in response to the TE tunnel/segment telemetry/state 1210 information the client has expressed an interest in. 1212 The TE Tunnel Model allows for a TE network client to: 1214 o Issue configuration requests to set up, tear down, replace, modify 1215 and manipulate end-to-end TE tunnels, as well as segments of 1216 multi-domain TE tunnels across the network controlled by the 1217 provider; 1219 o Request and obtain information on active TE tunnels/segments and 1220 connections supporting them; 1222 o Subscribe to and configure with the provider triggers, pace and 1223 contents of the TE tunnel/segment change update notifications; 1225 o Subscribe to and configure with the provider triggers, pace and 1226 contents of the TE tunnel/segment event notifications, such as 1227 detected alarms, faults, protection/restoration actions, etc.. 1229 o Subscribe to and configure with the provider triggers, pace and 1230 contents of TE tunnel/segment telemetry (e.g. statistics counters) 1231 update notifications. 1233 1.7. TE Tunnel/Transport Service Modeling Constructs 1235 Figure 20. TE tunnel 1237 o TE tunnel - a connection-oriented service provided by a layer 1238 network of delivery of a client's data between source and 1239 destination tunnel termination points. A TE tunnel in a server 1240 layer network may support a link in a client layer network (e.g. 1241 OCh layer TE tunnel supporting ODU4 link). In Figure 20, a TE 1242 tunnel interconnects tunnel termination points resident on 1243 switches C-R2 and C-R3. A TE tunnel is realized via (supported by, 1244 mapped onto) one or more layer network connections/LSPs 1246 _____________________________________________________________________ 1248 /* TE tunnel */ 1249 | +--rw tunnel* [name] 1250 | | +--rw name leafref 1251 | | +--rw identifier? leafref 1252 /* TE tunnel configuration parameters */ 1253 | | +--rw config 1254 | | | +--rw name? string 1255 | | | +--rw type? identityref 1256 | | | +--rw identifier? uint16 1257 | | | +--rw description? string 1258 | | | +--rw switchcap? identityref 1259 | | | +--rw encoding? identityref 1260 | | | +--rw protection-type? identityref 1261 | | | +--rw admin-status? identityref 1262 | | | +--rw preference? uint8 1263 | | | +--rw reoptimize-timer? uint16 1264 | | | +--rw source? inet:ip-address 1265 | | | +--rw destination? inet:ip-address 1266 | | | +--rw src-tp-id? binary 1267 | | | +--rw dst-tp-id? binary 1268 | | | +--rw topology-id? te-types:te-topology- 1269 id 1270 | | | +--rw ignore-overload? boolean 1271 | | | +--rw bandwidth-generic? te-types:te-bandwidth 1272 | | | +--rw disjointness? te-types:te-path- 1273 disjointness 1274 | | | +--rw setup-priority? uint8 1275 | | | +--rw hold-priority? uint8 1276 | | | +--rw signaling-type? identityref 1277 /* Hierarchy TE tunnel parameters */ 1278 | | | +--rw hierarchical-link-id 1279 | | | | +--rw local-te-node-id? te-types:te-node-id 1280 | | | | +--rw local-te-link-tp-id? te-types:te-tp-id 1281 | | | | +--rw remote-te-node-id? te-types:te-node-id 1282 | | | | +--rw te-topology-id? te-types:te- 1283 topology-id 1284 /* Bidirectional TE tunnel parameters */ 1285 | | | +--rw bidirectional 1286 | | | +--rw association 1287 | | | +--rw id? uint16 1288 | | | +--rw source? inet:ip-address 1289 | | | +--rw global-source? inet:ip-address 1290 | | | +--rw type? identityref 1291 | | | +--rw provisioing? identityref 1292 /* TE tunnel state */ 1293 | | +--ro state 1294 | | | +--ro name? string 1295 | | | +--ro type? identityref 1296 | | | +--ro identifier? uint16 1297 .............................................................. 1299 | | | +--ro oper-status? identityref 1300 /* TE tunnel primary path and LSP container */ 1301 | | +--rw p2p-primary-paths 1302 | | | +--rw p2p-primary-path* [name] 1303 | | | +--rw name 1304 /* Configuration */ 1305 leafref 1306 | | | +--rw config 1307 | | | | +--rw name? string 1308 | | | | +--rw preference? uint8 1309 | | | | +--rw path-setup-protocol? identityref 1310 | | | | +--rw path-computation-method? identityref 1311 | | | | +--rw path-computation-server? inet:ip- 1312 address 1313 | | | | +--rw compute-only? empty 1314 | | | | +--rw use-cspf? boolean 1315 | | | | +--rw verbatim? empty 1316 | | | | +--rw lockdown? empty 1317 | | | | +--rw named-explicit-path? leafref 1318 | | | | +--rw named-path-constraint? leafref {te- 1319 types:named-path-constraints}? 1320 /* state */ 1321 | | | +--ro state 1322 | | | | +--ro name? string 1323 | | | | +--ro preference? uint8 1324 | | | | +--ro path-setup-protocol? identityref 1325 | | | | +--ro path-computation-method? identityref 1326 | | | | +--ro path-computation-server? inet:ip- 1327 address 1328 | | | | +--ro compute-only? empty 1329 | | | | +--ro use-cspf? boolean 1330 | | | | +--ro verbatim? empty 1331 | | | | +--ro lockdown? empty 1332 | | | | +--ro named-explicit-path? leafref 1333 | | | | +--ro named-path-constraint? leafref 1334 {te-types:named-path-constraints}? 1335 /* Computed path */ 1336 /* Computed path properties/metrics / 1337 | | | | +--ro computed-path-properties 1338 | | | | | +--ro path-metric* [metric-type] 1339 | | | | | | +--ro metric-type identityref 1340 | | | | | | +--ro accumulative-value? uint64 1341 /* Computed path affinities */ 1342 | | | | | +--ro path-affinities 1343 | | | | | | +--ro constraints* [usage] 1344 | | | | | | | +--ro usage? 1345 identityref 1346 | | | | | | | +--ro (style)? 1347 | | | | | | | +--:(value) 1348 | | | | | | | | +--ro value? te- 1349 types:admin-groups 1350 | | | | | | | +--:(named) 1351 | | | | | | | +--ro affinity-names* 1352 [name] 1353 | | | | | | | +--ro name string 1354 /* Computed path SRLGs */ 1355 | | | | | +--ro path-srlgs 1356 | | | | | | +--ro (style)? 1357 | | | | | | +--:(values) 1358 | | | | | | | +--ro usage? identityref 1359 | | | | | | | +--ro values* te- 1360 types:srlg 1361 | | | | | | +--:(named) 1362 | | | | | | +--ro constraints* [usage] 1363 | | | | | | +--ro usage 1364 identityref 1365 | | | | | | +--ro constraint 1366 | | | | | | +--ro srlg-names* [name] 1367 | | | | | | +--ro name string 1368 /* Computed path sub-objects */ 1369 | | | | | +--ro path-computed-route-objects 1370 .............................................................. 1371 /* LSP (provisioned path) */ 1372 | | | | +--ro lsp* [source destination tunnel-id 1373 lsp-id extended-tunnel-id type] 1374 /* LSP parameters */ 1375 | | | | +--ro source leafref 1376 | | | | +--ro destination leafref 1377 | | | | +--ro tunnel-id leafref 1378 | | | | +--ro lsp-id leafref 1379 | | | | +--ro extended-tunnel-id leafref 1380 | | | | +--ro type leafref 1381 | | | | +--ro signaling-type? identityref 1382 | | | +--rw candidate-p2p-secondary-paths 1383 | | | +--rw candidate-p2p-secondary-path* 1384 [secondary-path] 1385 | | | +--rw secondary-path leafref 1386 | | | +--rw config 1387 | | | | +--rw secondary-path? leafref 1388 | | | | +--rw priority? uint16 1389 | | | | +--rw path-setup-protocol? 1390 identityref 1391 | | | +--ro state 1392 | | | +--ro secondary-path? leafref 1393 | | | +--ro priority? uint16 1394 | | | +--ro path-setup-protocol? 1395 identityref 1396 | | | +--ro active? boolean 1398 /* TE tunnel secondary path and LSP container */ 1400 | | +--rw p2p-secondary-paths 1401 | | | +--rw p2p-secondary-path* [name] 1402 ...................................................... 1403 | | | +--rw name leafref 1404 | | | +--rw config (same as for primary path ) 1405 ..................................................... 1406 | | | +--ro state (same as for primary, except for 1407 disjointedness_state ) 1408 | | +--ro disjointness_state? te-types:te-path- 1409 disjointness..................................................... 1410 | | | +--ro computed-path-properties (same as for 1411 primary path) 1412 .......................................................... 1413 | | | | +--ro path-affinities (same as for primary 1414 path) 1415 .......................................................... 1416 | | | | +--ro path-srlgs (same as for primary 1417 path) 1418 .......................................................... 1419 | | | | +--ro path-computed-route-objects 1420 ......................................................... 1421 /* LSP (provisioned path) */ 1422 | | | +--ro lsp (same as for the primary LSP) 1423 ........................................................ 1424 _____________________________________________________________________ 1425 o Tunnel termination point (TTP) - a physical device inside a given 1426 node/switch realizing a TE tunnel termination function in a given 1427 layer network, as well as the TE tunnel's adaptation function 1428 provided for client layer network(s). One example of tunnel 1429 termination point is an OCh layer transponder. [Note: Tunnel 1430 termination points are not to be confused with TE tunnel 1431 termination points, which are TE representations of physical 1432 tunnel termination points. Similar to physical switches and links 1433 of the network, such as depicted in Figure 20, being represented 1434 on a TE topology describing the network as TE nodes and TE links, 1435 (physical) tunnel termination points (TTPs) are represented as TE 1436 tunnel termination points (TE TTPs, see 1.2) hosted by the TE 1437 nodes. For example, a provisioned connection/LSP starts on a 1438 source TTP, goes through a chain of physical links and stops on a 1439 destination TTP. In contrast, TE path (e.g. result of a path 1440 computation) starts on a source TE TTP, goes through a chain of TE 1441 links and stops on a destination TE TTP.] 1443 _____________________________________________________________________ 1445 | | | +--rw source? inet:ip-address 1446 | | | +--rw destination? inet:ip-address 1447 | | | +--rw src-tp-id? binary 1448 | | | +--rw dst-tp-id? binary 1449 _____________________________________________________________________ 1451 o TE tunnel hand-off point - an access link or inter-domain link by 1452 which a multi-domain TE tunnel enters or exits a given network 1453 domain, in conjunction with a layer network resource (such as a 1454 wavelength channel or ODUk container) allocated on the 1455 access/inter-domain link for the TE tunnel. 1457 o TE tunnel segment - a part of a multi-domain TE tunnel that spans 1458 a given network domain and is directly and fully controlled by the 1459 domain's controller, DC. TE tunnel segment is a fragment of a 1460 multi-domain TE tunnel between 1462 1. the source tunnel termination point and the TE tunnel hand-off 1463 point outbound from the TE tunnel's first domain (head TE tunnel 1464 segment); 1466 2. inbound and outbound TE tunnel hand-off points into/from a given 1467 domain (transit TE tunnel segment); 1469 3. inbound TE tunnel hand-off point into the TE tunnel's last 1470 domain and the destination tunnel termination point (tail TE 1471 tunnel segment); 1473 o Transport service - the same as TE tunnel segment 1475 o Hierarchy TE tunnel - a server layer TE tunnel that supports a 1476 dynamically created TE link in the client layer network topology 1477 (e.g. see 1.2) 1479 _____________________________________________________________________ 1481 /* Hierarchy TE tunnel parameters */ 1482 | | | +--rw hierarchical-link-id 1483 | | | | +--rw local-te-node-id? te-types:te-node-id 1484 | | | | +--rw local-te-link-tp-id? te-types:te-tp-id 1485 | | | | +--rw remote-te-node-id? te-types:te-node-id 1486 | | | | +--rw te-topology-id? te-types:te- 1487 topology-id 1488 _____________________________________________________________________ 1490 o Hierarchy transport service - the first or the last segment of a 1491 multi-domain hierarchy TE tunnel 1493 o Dependency TE tunnel - a hierarchical TE tunnel provisioned or to 1494 be provisioned in an immediayely adjacent server layer a given 1495 client layer TE tunnel depends on (i.e. carried or to be carried 1496 within) 1498 o Potential TE tunnel/segment - a TE tunnel/segment configured in 1499 COMPUTE_ONLY mode. For such a TE tunnel/segment TE paths to be 1500 taken by supporting connection(s) is/are computed and monitored, 1501 but the connection(s) are not provisioned 1503 _____________________________________________________________________ 1505 | | | | +--rw path-computation-method? identityref 1506 | | | | +--rw path-computation-server? inet:ip- 1507 address 1508 | | | | +--rw compute-only? empty 1509 | | | | +--rw use-cspf? Boolean 1510 _____________________________________________________________________ 1511 Figure 20a. TE Tunnel Connections/LSPs 1513 o Layer network connection/connection/LSP - a layer network path 1514 supporting a TE tunnel by realizing its implied forwarding 1515 function. Said path is provisioned in a given layer network's data 1516 plane over a chain of links and cross-connected over switches 1517 terminating the links. It interconnects the supported TE tunnel's 1518 source and destination termination points (in the case of end-to- 1519 end connection) or TE tunnel's hand-off points (in the case of 1520 transport service connection) or the TE tunnel's two split-merge 1521 points (in the case of segment protection connection. 1523 Example: ODU2 connection supporting an ODU2 TE tunnel. 1525 _____________________________________________________________________ 1526 /* LSP (provisioned path) */ 1527 | | | | +--ro lsp* [source destination tunnel-id 1528 lsp-id extended-tunnel-id type] 1529 /* LSP parameters */ 1530 | | | | +--ro source leafref 1531 | | | | +--ro destination leafref 1532 | | | | +--ro tunnel-id leafref 1533 | | | | +--ro lsp-id leafref 1534 | | | | +--ro extended-tunnel-id leafref 1535 | | | | +--ro type leafref 1536 | | | | +--ro signaling-type? identityref 1537 .................................................................. 1538 | | | +--ro priority? uint16 1539 | | | +--ro path-setup-protocol? 1540 identityref 1541 | | | +--ro active? Boolean 1542 _____________________________________________________________________ 1544 o Working connection - the primary connection of the supported TE 1545 tunnel or transport service (see Figure 20a). 1547 o End-to-end protection connection - a secondary end-to-end 1548 connection of the supported TE tunnel (e.g. end-to-end 1+1 1549 protection connection, see Figure 20a). 1551 o Segment protection connection - a secondary connection of the 1552 supported transport service protecting the service over a given 1553 network domain (e.g. 1+1 segment protection connection, see Figure 1554 20a) 1556 o Restored connection - a connection after successful network 1557 failure restorationrestoration procedures 1559 o Current connection - the same as restored connection 1561 o Nominal connection - a connection as (re-)provisioned upon a 1562 client configuration request (i.e. a connection before any 1563 automatic network failure restoration re-configurations are 1564 carroed out, also a connection after restoration reversion 1565 procedures are successfully completed) 1567 o Unprotected TE tunnel/transport service - TE tunnel/transport 1568 service supported by a single (working/primary) connection/LSP 1570 o Protected TE tunnel/transport service - TE tunnel/transport 1571 service supported by one working connection/LSP and at least one 1572 protection/secondary connection/LSP 1574 o Restorable TE tunnel/transport service - TE tunnel/transport 1575 service with pre-configured automatic network failure restoration 1576 capabilities 1578 o TE tunnel/transport service automatic protection switchover - a 1579 process of switching of carrying user payload from the 1580 tunnel's/service's affected by a network failure working 1581 connection onto one of the tunnel's/service's healthy protection 1582 connection 1584 o TE tunnel/transport service automatic protection reversion - a 1585 process of switching of carrying user payload from the 1586 tunnel's/service's protection connection back onto the 1587 tunnel's/service's working connection after the latter was 1588 repaired from network failure 1590 o TE tunnel/transport service protection external command - a 1591 command, typically issued by an operator, which influences the 1592 automatic protection switchover and reversion. 1594 External commands are defined in [ITU-T G.800] and [RFC 4427]: 1596 . Freeze: A temporary configuration action that prevents any 1597 switch action to be taken and as such freezes the current 1598 state. 1600 . Clear Freeze: An action that clears the active Freeze state. 1602 . Lockout of Normal: A temporary configuration action that 1603 ensures that the normal traffic is not allowed to use the 1604 protection transport entity. 1606 As described in [ITU-T G.808], this command should be issued 1607 at both ends. 1609 . Clear Lockout of Normal: An action that clears the active 1610 Lockout of Normal state. 1612 . Lockout of Protection: A temporary configuration action that 1613 ensures that the protection transport entity is temporarily 1614 not available to transport a traffic signal (either normal or 1615 extra traffic). 1617 . Forced Switch: A switch action that swithes the extra traffic 1618 signal, the normal traffic signal, or the null signal to the 1619 protection transport entity, unless an equal or higher 1620 priority switch command is in effect. 1622 . Manual Switch: A switch action that switches the extra 1623 traffic signal, the normal traffic signal #i, or the null 1624 signal to the protection transport entity, unless a fault 1625 condition exists on other transport entities or an equal or 1626 higher priority switch command is in effect. 1628 . Exercise: An action to start testing if the APS communication 1629 is operating correctly. It is lower priority than any other 1630 state or command. 1632 . Clear: An action that clears the active near-end lockout of 1633 protection, forced switch, manual switch, WTR state, or 1634 exercise command 1636 o TE tunnel/transport service protection Hold-off time - a 1637 configured period of time to expire between the moment of 1638 detecting of the first network failure affecting the 1639 tunnel's/service's working connection and the begining of the 1640 tunnel's/service's automatic protection switchover procedures 1642 o TE tunnel/transport service protection WTR time - a configured 1643 period of time to expire between the moment of repairing the last 1644 network failure affecting the tunnel's/service's working 1645 connection and the begining of the tunnel's/service's automatic 1646 protection reversion procedures 1648 o TE tunnel/transport service automatic network failure restoration 1649 - a process of replacing of the tunnel's/service's connection(s) 1650 affected by one or more network failures away from the point(s) of 1651 failue 1653 o TE tunnel/transport service restoration reversion- a process of 1654 replacing of the tunnel's/service's connection(s) back onto the 1655 nominal connection paths after all network failures affecting the 1656 tunnel's/service's nominal connection(s) are repaired 1658 o TE tunnel/transport service restoration Hold-off time - a 1659 configured period of time to expire between the moment of 1660 detecting of the first network failure affecting the 1661 tunnel's/service's nominal or current connection and the beginning 1662 of the automatic connection restoration procedures 1664 o TE tunnel/transport service restoration WTR time - a configured 1665 period of time to expire between the moment of repairing the last 1666 network failure affecting the tunnel's/service's nominal 1667 connection and the begining of the connection automatic 1668 restoration reversion procedures 1670 o Configured restoration path - a TE path specified by the client to 1671 be used during the automatic network failure restoration operation 1672 on one of the TE tunnel's/transport service's nominal or current 1673 connections 1675 o Pre-computed restoration path - a configured restoration path to 1676 be validated by a path computer during the TE tunnel/transport 1677 service setup or client triggered modification 1679 o Pre-provisioned restoration path - a pre-computed restoration path 1680 to be pre-provisioned/pre-signaled in the network (with all 1681 associated network resources allocated but not necessarily bound 1682 into cross-connects) during the TE tunnel/transport service setup 1683 or client triggered modification 1685 o Connection configured path - a TE path (see 1.2) over a TE 1686 topology describing a layer network/domain that specifies (loosely 1687 or strictly) the client's requirements with respect to an ordered 1688 list of network nodes, links and resources on the links a given 1689 connection should go through 1691 _____________________________________________________________________ 1693 | | +--rw explicit-route-object* [index] 1694 | | +--rw index leafref 1695 | | +--rw explicit-route-usage? identityref 1696 (INCLUDE/EXCLUDE) 1697 | | | +--rw index? uint32 1698 | | | +--rw (type)? 1699 | | | +--:(numbered) 1700 | | | | +--rw numbered-hop 1701 | | | | +--rw address? te-types:te-tp- 1702 id 1703 | | | | +--rw hop-type? te-hop-type 1704 | | | +--:(as-number) 1705 | | | | +--rw as-number-hop 1706 | | | | +--rw as-number? binary 1707 | | | | +--rw hop-type? te-hop-type 1708 | | | +--:(unnumbered) 1709 | | | | +--rw unnumbered-hop 1710 | | | | +--rw node-id? te-types:te- 1711 node-id 1712 | | | | +--rw link-tp-id? te-types:te- 1713 tp-id 1714 | | | | +--rw hop-type? te-hop-type 1715 | | | +--:(label) 1716 | | | | +--rw label-hop 1717 | | | | +--rw value? rt- 1718 types:generalized-label 1719 | | | +--:(sid) 1720 | | | +--rw sid-hop 1721 | | | +--rw sid? rt- 1722 types:generalized-label 1723 _____________________________________________________________________ 1725 o Connection exclusion path - a TE path over a TE topology 1726 describing a layer network/domain that specifies the client's 1727 requirements with respect to an unordered list of network nodes, 1728 links and resources on the links to be avoided by a given 1729 connection 1731 _____________________________________________________________________ 1733 | | +--rw route-object-exclude-always* [index] 1734 | | | +--rw index leafref 1735 | | | | +--rw index? uint32 1736 | | | | +--rw (type)? 1737 | | | | +--:(numbered) 1738 | | | | | +--rw numbered-hop 1739 | | | | | +--rw address? te-types:te-tp- 1740 id 1741 | | | | +--:(as-number) 1742 | | | | | +--rw as-number-hop 1743 | | | | | +--rw as-number? binary 1744 | | | | +--:(unnumbered) 1745 | | | | | +--rw unnumbered-hop 1746 | | | | | +--rw node-id? te-types:te- 1747 node-id 1748 | | | | | +--rw link-tp-id? te-types:te- 1749 tp-id 1750 | | | | +--:(label) 1751 | | | | | +--rw label-hop 1752 | | | | | +--rw value? rt- 1753 types:generalized-label 1754 | | | | +--:(sid) 1755 | | | | +--rw sid-hop 1756 | | | | +--rw sid? rt- 1757 types:generalized-label 1758 _____________________________________________________________________ 1760 o Connection computed path - a TE path over a TE topology describing 1761 a layer network/domain as computed (subject to all configured 1762 constraints and optimization criteria) for a given connection to 1763 take. Computed connection path could be thought as the TE path 1764 intended to be taken by the connection 1766 _____________________________________________________________________ 1768 /* Computed path */ 1769 /* Computed path properties/metrics / 1770 | | | | +--ro computed-path-properties 1771 | | | | | +--ro path-metric* [metric-type] 1772 | | | | | | +--ro metric-type identityref 1773 | | | | | | +--ro accumulative-value? uint64 1774 /* Computed path affinities */ 1775 | | | | | +--ro path-affinities 1776 | | | | | | +--ro constraints* [usage] 1777 | | | | | | | +--ro usage? 1778 identityref 1779 | | | | | | | +--ro (style)? 1780 | | | | | | | +--:(value) 1781 | | | | | | | | +--ro value? te- 1782 types:admin-groups 1783 | | | | | | | +--:(named) 1784 | | | | | | | +--ro affinity-names* 1785 [name] 1786 | | | | | | | +--ro name string 1787 /* Computed path SRLGs */ 1788 | | | | | +--ro path-srlgs 1789 | | | | | | +--ro (style)? 1790 | | | | | | +--:(values) 1791 | | | | | | | +--ro usage? identityref 1792 | | | | | | | +--ro values* te- 1793 types:srlg 1794 | | | | | | +--:(named) 1795 | | | | | | +--ro constraints* [usage] 1796 | | | | | | +--ro usage 1797 identityref 1798 | | | | | | +--ro constraint 1799 | | | | | | +--ro srlg-names* [name] 1800 | | | | | | +--ro name string 1801 /* Computed path sub-objects */ 1802 | | | | | +--ro path-computed-route-objects 1803 .............................................................. 1804 _____________________________________________________________________ 1806 o Connection actual path - an active connection's path as 1807 provisioned in the layer network's data plane in the form of a TE 1808 path over a TE topology describing the layer network/domain 1810 1.7.1. Bidirectional Tunnels 1812 The TE Tunnel model supports the setup of unidirectional connections 1813 as well as multiple types of bidirectional connections. 1815 The bidirectional flag is used to indicate whether the TE Tunnel is 1816 unidirectional or bidirectional. In case of bidirectional TE Tunnels, 1817 the p2p-reverse-primary-path presense container is used to indicate 1818 whether the bidirectional TE Tunnel is native or not. This presense 1819 container cannot be instantiated for unidirectional TE Tunnels. 1821 Unidirectional TE Tunnel: the bidirectional flag is set to "False". 1823 The unidirectional path constraints are configured in the p2p- 1824 primary-path container (the p2p-reverse-primary-path presense 1825 container is not created). 1827 The server computes one unidirectional path and report it and its 1828 properties within the p2p-primary-path container. 1830 The server setup unidirectional LSPs and reports them under the p2p- 1831 primary-path container. 1833 Native bidirectional TE Tunnel: the bidirectional flag is set to 1834 "True" and the p2p-reverse-primary-path container is not created. 1836 The path constraints, applicable to both directions, are configured 1837 in the p2p-primary-path container. 1839 The server computes one bidirectional path and report it and its 1840 properties within the p2p-primary-path container. 1842 The server setup bidirectional LSPs and reports them under the p2p- 1843 primary-path container. 1845 Note that asymmetric bandwdith configuration is not supported with 1846 native bidirectional tunnels. 1848 Bidirectional (non-courouted) TE Tunnel: the bidirectional flag is 1849 set to "True" and the p2p-reverse-primary-path container is created. 1851 The path constraints, applicable to the forward direction, are 1852 configured in the p2p-primary-path container, while the path 1853 constraints applicable to the reverse direction are configured in the 1854 p2p-reverse-primary-path container. It is therefore possible to 1855 configure different set of path constraints, including different 1856 bandwdith, in the two directions. If there are no path constraints 1857 applicable to the backward direction, the p2p-reverse-primary-path 1858 container can be empty (but it shall be present). 1860 The server computes two indepedent paths in the forward and reverse 1861 direction: the computed path in the forward direction and its 1862 properties are reported within the p2p-primary-path container, while 1863 the computed path in the reverse direction and its properties 1864 reported within the p2p-reverse-primary-path container. 1866 The server setup associated unidirectional LSPs in both directions: 1867 unidirectional LSPs setup in the forward direction are reported 1868 within the p2p-primary-path container, while unidirectional LSPs 1869 setup in the backward direction are reported within the p2p-reverse- 1870 primary-path container. 1872 Bidirectional courouted TE Tunnel with asymmetric constraints: the 1873 bidirectional flag is set to "True" and the p2p-reverse-primary-path 1874 container is created. 1876 The path constraints, applicable to the forward direction, are 1877 configured in the p2p-primary-path container. The p2p-reverse- 1878 primary-path container is configured with use-path-computation flag 1879 set to False and an empty route-object-exclude-always container (to 1880 indicate that the directions should be corouted). It is possible to 1881 configure different bandwdiths in the two directions but no different 1882 path constraints. 1884 Note that in case of a bidirectional (non-courouted) TE Tunnel it is 1885 also possible to configure the p2p-reverse-primary-path container 1886 with the use-path-computation flag set to False, when the reverse 1887 path is configured by the client and not computed by the server: in 1888 this case route-object-exclude-always container is not empty but 1889 specifies the complete explicit-path within the. 1891 The server computes one bidirectional path and report it and its 1892 properties within the p2p-primary-path container. No path properties 1893 are reported within the p2p-reverse-primary-path container. 1895 The server setup associated unidirectional LSPs in both directions: 1896 unidirectional LSPs setup in the forward direction are reported 1897 within the p2p-primary-path container, while unidirectional LSPs 1898 setup in the backward direction are reported within the p2p-reverse- 1899 primary-path container. 1901 The label hops used in bidirectional routers (either for path 1902 constraints or for path routes or for LSP routes) should report the 1903 labels used in the two directions (forward and backward): 1905 o in case the same label is used in both direction, there will be 1906 only one label hop with an empty direction leaf; 1908 o in case different labels are used in the two directions, there 1909 will be two label hops, one specifying the label in the forward 1910 direction and another for the label in the reverse direction. 1912 Associated unidirectional TE Tunnels: two unidirectional TE Tunnels 1913 (with the bidirectional flag is set to "False") are configured in the 1914 forward and reverse direction and associated for bidirectionality 1915 using the association container. 1917 1.8. Transport Service Mapping 1919 Figure 21. Transport Service Mapping 1921 Let's assume that a provider has exposed to a client its network 1922 domain in the form of an abstract TE topology, as shown on the left 1923 side of Figure 21. From then on, the provider should be prepared to 1924 receive from the client, a request to set up or manipulate a 1925 transport service with TE path(s) computed for the service 1926 connection(s) based on and expressed in terms of the provided 1927 abstract TE topology (as, for example, displayed in red broken line 1928 on the right side of Figure 21). When this happens, the provider is 1929 expected to set up the TE tunnels supporting all yet uncommitted 1930 abstract TE links (e. g, TE link S3'-S8' in the Figure). 1932 Furthermore, it is the responsibility of the provider to: 1934 o Perform all the necessary abstract-to-native translations for the 1935 specified TE paths (i.e. the transport service connection 1936 configured paths); 1938 o Provision working and protection connections supporting the 1939 transport service; as well as replace/modify/delete them in 1940 accordance with subsequent client's configuration requests; 1942 o Perform all the requested recovery operations upon detecting 1943 network failures affecting the transport service; 1945 o Notify the client about all parameter changes, events and other 1946 telemetry information the client has expressed an interest in, 1947 with respect to the transport service in question. 1949 1.9. Multi-Domain Transport Service Coordination 1951 A client of multiple TE network domains may need to 1952 orchestrate/coordinate its transport service setup/manipulation 1953 across some or all the domains. One example of such a client is a 1954 Hierarchical T-SDN Controller, HC, managing a connected multi-domain 1955 transport network where each of the domains is controlled by a 1956 separate Domain T-SDN Controller, DC. Said DCs are expected to expose 1957 TE Topology and TE Tunnel North Bound Interfaces, NBIs,, supported 1958 respectively by IETF TE Topology and TE Tunnel models (and their 1959 network layer specific augmentations). HC is assumed to establish 1960 client-provider relationship with each of the DCs and make use of 1961 said NBIs to extract from the domains various information (such as TE 1962 topologies and telemetry), as well as to convey instructions to 1963 coordinate across multiple domains its transport services set up and 1964 manipulation. 1966 Figure 22. Two-Domain Transport Network 1968 Let's consider, for example, a two-domain transport network as 1969 represented in Figure 22. Suppose that HC is requested to set up an 1970 unprotected transport service to provide connectivity between 1971 customer network elements C-R1 and C-R6. It is assumed that by the 1972 time the request has arrived, the two DCs have already provided 1973 abstract TE topologies describing their respective domains, and that 1974 HC has merged the provided TE topologies into one that homogeneously 1975 describes the entire transport network (as shown in Figure 23). 1977 Figure 23. Two-Domain Transport Network (Abstracted View) 1979 Consider that HC, using the merged TE topology, selected a TE path to 1980 be taken by the requested transport service connection as shown on 1981 the upper part of Figure 24. 1983 The multi-domain transport service set up coordination includes: 1985 o Splitting selected for the transport service TE path(s) into 1986 segments - one set of segments per each domain involved in the 1987 service setup; 1989 o Issuing a configuration request to each of the involved DCs to set 1990 up the transport service across the respective domain. Note that 1991 the connection configured paths are required to be expressed in 1992 terms of respective abstract TE topologies as exposed to HC by DCs 1993 (see lower part of Figure 24). 1995 o Waiting for the set up complete confirmation from each of the 1996 involved DCs. In case one of the DCs reports a failure, HC is 1997 responsible to carry out the cleanup/rollback procedures by 1998 requesting all involved DCs to tear down the successfully created 1999 segments 2001 Figure 24. Transport Service Placement Based on Abstract TE Topology 2003 While processing the received from HC configuration request to set up 2004 the transport service, each DC is expected to carry out the transport 2005 service mapping procedures (as described in 1.8) resulting in the set 2006 up of all the necessary underlay TE tunnels, as well as one or more 2007 connections supporting the transport service. As a result, the 2008 requested transport service will be provisioned as shown in Figure 2009 25. 2011 o In the example above the TE tunnel segments that each DC has to 2012 set up are the head TE tunnel segment (for domain 1) and the tail 2013 TE tunnel segment (for domain 2). For head TE tunnel segment HC 2014 can specify in the configuration request only the source TTP 2015 (located in node s3 in the example), but not the tunnel's 2016 destination TTP, because it is outside of the domain controlled by 2017 the DC. 2019 Therefore, the outbound hand-off point (in the form of outbound 2020 inter-domain TE link ID/label pair) of each connection segment 2021 supporting a TE tunnel non-tail segment (such as head or transit 2022 tunnel segment) is expected to be found at the end of the route- 2023 object-include-exclude list of the explicit-route-objects 2024 configured for that connection segment. 2026 o Likewise, the inbound hand-off point (in the form of inbound 2027 inter-domain TE link ID/label pair) of each connection segment 2028 supporting a TE tunnel non-head segment (such as tail or transit 2029 tunnel segment) is expected to be found at the beginning of the 2030 route-object-include-exclude list of the explicit-route-objects 2031 configured for that connection segments. 2033 o For example, in the figure above the HC can specify the outbound 2034 hand-off point of the primary path supporting the head TE tunnel 2035 segment. The configuration is to be the in the form of the pair of 2036 the TE link ID, identifying the inter domain link terminating on 2037 node s7, and of the TE label used on that link. 2039 o In case (not present in this example) we need to setup a Transit 2040 Tunnel Segment since the endpoints of the E2E Tunnel are both 2041 outside the domain controlled by that DC, the HC would not specify 2042 any source or destination TTP (i.e., it would leave the source, 2043 destination, src-tp-id and dst-tp-id attributes empty)and it would 2044 use the the route-object-include-exclude list of the explicit- 2045 route-objects to specify the inbound and outbound hand-off points 2046 of each connection segment supporting the Transit Tunnel Segment. 2048 The multi-domain transport service tear down coordination entails 2049 issuing to each of the involved DCs a configuration request to delete 2050 the transport service in the controlled by the DC domain. DCs are 2051 expected in this case to release all network resources allocated for 2052 the transport service. 2054 The multi-domain transport service modify coordination implies 2055 issuing to each of the involved DCs a configuration request to 2056 replace the transport service connections according to the newly 2057 provided paths and/or modify the connection parameters according to 2058 the newly provided configuration. 2060 Figure 25. Multi-domain transport service is provisioned 2062 2. Use Cases 2064 2.1. Use Case 1. Transport service control on a single layer multi- 2065 domain transport network 2067 Configuration (Figure 26): 2069 o Three-domain multi-vendor ODUk/Och transport network; 2071 o The domains are interconnected via ODUk inter-domain links; 2072 o Each of the domains is comprised of ODUk/Och network elements 2073 (switches) from a separate vendor and is controlled by a single 2074 (vendor specific) T-SDN Domain Controller (DC); 2076 o All DCs expose IETF TE Topology and TE Tunnel model based NBIs; 2078 o The transport network as a whole is controlled by a single 2079 hierarchical T-SDN controller (HC); 2081 o HC makes use of the NBIs to set up client-provider relationship 2082 with each of the DCs and controls via the DCs their respective 2083 network domains; 2085 o Three customer IP/MPLS sites are connected to the transport 2086 network via ODUk access links; 2088 o The customer IP/MPLS routers and the router transport ports 2089 connecting the routers to the transport network are managed 2090 autonomously and independently from the transport network. 2092 Figure 26 Three-domain ODUk/Och transport network with ODUk access 2093 and inter-domain links 2095 Objective: Set up/manipulate/delete a shortest delay unprotected or 2096 protected transport service to provide connectivity between customer 2097 network elements C-R2 and C-R5 2099 1) TE Topology discovery 2101 All DCs provide to HC respective domain ODUk layer abstract TE 2102 topologies. Let's assume that each such topology is a single-node TE 2103 topology (as described in 1.3.1, abstract TE topology of this type 2104 represents the entire domain as a single asymmetrical/blocking TE 2105 node). Let's further assume that the abstract TE nodes representing 2106 the domains are attributed with detailed connectivity matrices 2107 optimized according to the shortest delay criterion. [Note: single- 2108 node abstract TE topologies are assumed for simplicity sake. 2109 Alternatively, any DC could have provided an abstract TE topology of 2110 any type described in 1.3]. 2112 HC merges the provided TE topologies into its own native TE topology 2113 (the TE topology merging procedures are discussed in 1.4). The merged 2114 TE topology, as well as the TE topologies provided by DCs, are 2115 depicted in Figure 27. The merged TE topology homogeneously describes 2116 the entire transport network and hence is suitable for path 2117 computations across the network. Note that the dotted lines in the 2118 Figure connecting the topology access TE links with customer devices 2119 illustrate that HC in this use case has neither control nor 2120 information on the customer devices/ports and, therefore, can only 2121 provide a connectivity between the requested transport service 2122 ingress and egress access links (on assumption that the customer 2123 transport ports are provisioned independently) 2125 Figure 27. Three-domain single layer transport network abstract TE 2126 topology 2128 2) Transport service path computation 2130 Using the merged TE topology (Figure 27, upper part) HC selects one 2131 or more optimal and sufficiently disjoint from each other TE path(s) 2132 for the requested transport service connection(s). Resulting TE paths 2133 for the requested end-to-end protected transport service, for 2134 example, could be as marked on the upper part of Figure 28. 2136 It is important to keep in mind that HC's path computer is capable of 2137 performing the necessary path selection only as long as the merged TE 2138 topology provides the necessary TE visibility for the path selection, 2139 both intra-domain (e.g. by virtue of provided by the abstract TE 2140 nodes detailed connectivity matrices) and inter-domain (because of 2141 provided inter-domain TE link attributes). In case one or more DCs 2142 is/are not capable of or willing to provide the detailed connectivity 2143 matrices (that is, DCs expose the respective domains as black boxes - 2144 unconstrained TE nodes terminating the inter-domain TE links), HC 2145 will not be able to select the end-to-end TE path(s) for the 2146 requested transport service on its own. In such a case HC may opt for 2147 making use of the Path Computation NBI, exposed by the DCs to 2148 explore/evaluate intra-domain TE path availability in real time. IETF 2149 TE Tunnel model supports the Path Computation NBI by allowing for the 2150 configuration of transport services in COMPUTE_ONLY mode. In this 2151 mode the provider is expected to compute TE paths for a requested 2152 transport service connections and return the paths in the request's 2153 response without triggering the connection provisioning in the 2154 network. 2156 Consider, for example, the case when none of the DCs has provided the 2157 detailed connectivity matrix attribute for the abstract TE nodes 2158 representing the respective domain. In such a case HC may: 2160 1. Request the ingress domain DC (i.e. DC1) to compute intra-domain 2161 TE paths connecting the ingress access TE link (i.e. the link 2162 facing C-R2) with each of the inter-domain TE links (i.e. links 2163 connecting Domain 1 to Domain 2 and Domain 3 respectively); 2165 2. Grow the TE paths returned by DC1 in (1) over the respective 2166 outbound inter-domain TE links; 2168 3. Request the neighboring DC(s) (e.g. DC3) to compute all intra- 2169 domain TE paths connecting across the domain all inbound into 2170 the domain inter-domain TE links reached by the path growing 2171 process in (2) with all other (outbound) domain's inter-domain 2172 TE links; 2174 4. Augment the TE paths produced in step (2) with the TE paths 2175 determined in step (3); 2177 5. Repeat steps (2), (3) and (4) until the resulting TE paths reach 2178 the egress domain (i.e. Domain 2); 2180 6. Request the egress domain DC (i.e. DC2) to grow each of the TE 2181 paths across the domain to connect them to the egress access TE 2182 link (i.e. the link facing C-R5); 2184 7. Select one (or more) most optimal and sufficiently disjoint from 2185 each other TE path(s) from the list produced in step (6). 2187 [Note: The transport service path selection method based on Path 2188 Computation NBIs exposed by DCs does not scale well and the more 2189 domains comprise the network and the more inter-domain links 2190 interconnect them, the worse the method works. Realistically, this 2191 approach will not work sufficiently well for the networks with more 2192 than 3 domains] 2193 Figure 28. TE paths computed for the protected transport service 2195 3) Transport service setup coordination 2197 HC carries out the multi-domain transport service setup coordination 2198 as described in 1.9. In particular, HC splits the computed TE path(s) 2199 into 3 sets of TE path segments - one set per domain (as shown on the 2200 lower part of Figure 28), and issues a TE tunnel configuration 2201 request to each of the DCs to set up the requested transport service 2202 across the domain under the DC's control. The primary (and 2203 secondary) connection explicit path(s) is/are specified in the 2204 requests in terms of respective domain abstract TE topologies. 2206 While processing the configuration request, each DC performs the 2207 transport service mapping (as described in 1.8). In particular, the 2208 DC translates the specified explicit path(s) from abstract into 2209 native TE topology terms, sets up supporting underlay TE tunnels 2210 (e.g. Och TE tunnels), and, then, allocates required ODUk containers 2211 on the selected links and provisions the ODUk cross-connects on the 2212 switches terminating the links. 2214 If the setup is successfully completed in all three domains, the 2215 transport service connection(s) will be provisioned as depicted in 2216 Figure 29. If one of the DCs fails to set up its part, all 2217 successfully provisioned segments will be asked by HC to be released. 2219 4) Transport service teardown coordination 2221 HC issues to each of DCs a configuration request to release the 2222 transport service over the controlled domain, as well as the server 2223 layer TE tunnels supporting dynamically created links. 2225 Figure 29. Transport service is provisioned 2227 2.2. Use Case 2. End-to-end TE tunnel control on a single layer multi- 2228 domain transport network 2230 Configuration (Figure 26): the same as in use case 1, except that HC 2231 in this use case controls customer devices/ports by extracting 2232 information from and pushing configuration to the customer site SDN 2233 controller(s) managing the customer devices directly. 2235 Objective: Set up//delete an unprotected shortest delay TE tunnel 2236 interconnecting end-to-end C-R2 and C-R5 2238 1) TE Topology discovery 2240 As in use case 1 all DCs provide to HC domain ODUk layer abstract TE 2241 topologies. Additionally in this use the three customer site 2242 controllers expose the TE Topology and Tunnel model based NBIs to HC. 2243 Using the TE Topology NBI each customer controller provides to HC the 2244 respective customer site domain abstract TE topology. Customer site 2245 abstract TE topologies contain abstract TE nodes representing the 2246 devices which are directly connected to the transport network. Said 2247 abstract TE nodes host TE tunnel termination points, TTPs, 2248 representing the ports over which the customer devices are connected 2249 to the transport network, and terminate access TE links the TTPs are 2250 accessible from (see Figure 30). 2252 Figure 30. Abstract TE topologies provided by all network domains and 2253 customer sites 2255 HC merges the provided topologies into its own native TE Topology 2256 (the TE topology merging procedures are discussed in 1.4). The merged 2257 TE topology is depicted in Figure 31. It homogeneously describes end- 2258 to-end not only the entire transport network, but also the customer 2259 sites connected to the network and hence is suitable for TE tunnel 2260 end to end path computations. 2262 Figure 31. Abstract TE topology describing transport network and 2263 connected to it customer sites 2265 2) TE tunnel path computation 2267 Using the merged TE topology (Figure 31) HC selects an optimal TE 2268 path for the requested TE tunnel connecting end-to-end the specified 2269 TE tunnel termination points, TTPs. The resulting TE path, for 2270 example, could be as marked on the upper part of Figure 32. 2272 Figure 32. TE path computed for the TE tunnel 2274 3) TE tunnel setup coordination 2276 HC carries out the multi-domain TE tunnel setup coordination as 2277 described for use case 1, except that in this use case HC 2278 additionally initiates and controls the setup of the TE tunnel's head 2279 and tail segments on the respective customer sites. Note that the 2280 customer site controllers behave exactly as transport network domain 2281 DCs. In particular, they receive issued by HC configuration requests 2282 to set up the TE tunnel's head and tail segments respectively. While 2283 processing the requests the customer site controllers perform the 2284 necessary provisioning of the TE tunnel's source and destination 2285 termination points, as well as of the local sides of the selected 2286 access links. If all segments are successfully provisioned on 2287 customer sites and network domains, the TE tunnel connection will be 2288 provisioned as marked in Figure 33. 2290 4) TE tunnel teardown coordination 2292 HC issues to each of DCs and customer site controllers a 2293 configuration request to release respective segments of the TE 2294 tunnel, as well as the server layer TE tunnels supporting dynamically 2295 created links. 2297 Figure 33. TE tunnel is provisioned 2299 2.3. Use Case 3. Transport service control on a ODUk/Och multi-domain 2300 transport network with Ethernet access links 2302 Configuration (Figure 34): the same as in use case 1, except that all 2303 access links in this use case are Ethernet layer links (depicted as 2304 blue lines in the Figure), while all inter-domain links remain to be 2305 ODUk layer links. 2307 Figure 34. Three-domain ODUk/Och transport network with Ethernet 2308 layer access links 2310 Objective: Set up//delete an unprotected shortest delay transport 2311 service supporting connectivity between C-R2 and C-R5 2313 1) TE Topology discovery 2315 In order to make possible for the necessary in this use case multi- 2316 layer path computation, each DC exposes to HC two (ODUk layer and 2317 Ethernet layer) abstract TE topologies, Additionally, the lower 2318 layer (ODUk) TE nodes announce hosted by them TE tunnel termination 2319 points, TTPs, capable of adopting the payload carried over the 2320 Ethernet layer access links, From the TE Topology model point of view 2321 this means that said TTPs are attributed with TE inter-layer locks 2322 matching ones attributed to Ethernet TE links (i.e. TE links provided 2323 within Ethernet layer abstract TE topologies). 2325 Ethernet and ODUk layer single node abstract TE topologies catered to 2326 HC by each of the DCs are presented in Figure 35. 2328 HC merges the provided TE topologies into its own native TE Topology 2329 (the merging procedures are described in 1.4). Importantly in this 2330 case HC locks the provided TE topologies not only horizontally, but 2331 vertically as well, thus producing a two-layer TE topology 2332 homogenously describing both layers of the entire transport network, 2333 as well as the client-server layer adaptation relationships between 2334 the two layers. This makes the merged TE topology suitable for multi- 2335 layer/inter-layer multi-domain transport service path computations. 2336 The merged TE topology is presented in Figure 36. 2338 Figure 35. ODUk and Ethernet layer abstract TE topologies exposed by 2339 DCs 2341 Figure 36. Two-layer three-domain transport network abstract TE 2342 topology 2344 2) Transport service path computation 2346 Using the merged TE topology (Figure 36) HC selects an optimal TE 2347 path for the requested transport service. 2349 Note that if HC's path computer considered only Ethernet layer TE 2350 nodes and links, the path computation would .fail. This is because 2351 the Ethernet layer TE nodes (i.e. D1-e, D2-e and D3-e in the Figure) 2352 are disconnected from each other. However, the inter-layer 2353 associations (in the form of the TE inter-layer locks) make possible 2354 for the path computer to select TE path(s) in the lower (ODUk) layer 2355 that can be used to set up hierarchy TE tunnel(s) supporting 2356 additional dynamic TE link(s) in the upper (Ethernet ) layer in order 2357 for the requested transport service path computation to succeed. 2359 Let's sssume that the resulting TE path is as marked in Figure 37. 2360 The red line in the Figure marks the TE path selected for the ODUk 2361 layer hierarchy TE tunnel supporting the required Ethernet layer 2362 dynamic TE link. 2364 Figure 37. Multi-layer TE path computed for the transport service 2366 3) Transport service setup coordination 2368 HC sets up the requested Ethernet layer transport service in two 2369 stages. First, it coordinates the end-to-end setup of the ODUk layer 2370 hierarchy TE tunnel between the selected TTPs. If this operation 2371 succeeds, a new Ethernet layer dynamic TE link (blue line connecting 2372 TE nodes D1-e and D2-e in Figure 38) is automatically added to the 2373 merged abstract TE topology. Importantly, as a part of the hierarchy 2374 transport service setup both DC1 and DC 2 add a new open-ended 2375 Ethernet layer inter-domain dynamic TE link to their respective 2376 abstract TE topologies. Second, HC coordinates the setup of the 2377 requested (Ethernet layer) transport service. The required TE path 2378 for the second stage is marked as fat blue line in the Figure. Note 2379 that DC3 controlling domain 3 is only involved in the first stage, 2380 but is oblivious to the second stage. 2382 Figure 38. A new Ethernet layer TE link supported by ODUk layer TE 2383 tunnel is added to the provided and merged abstract TE topologies 2385 IF all involved DCs confirm successful setup completion, the 2386 requested transport service, as well as the supporting server layer 2387 hierarchy TE tunnel, will be provisioned as depicted in Figure 39. If 2388 one of the DCs fails to set up its segment in either of the layers, 2389 all successfully provisioned segments will be requested by HC to be 2390 released. 2392 Figure 39. Ethernet transport service and supporting ODUk TE tunnel 2393 are provisioned 2395 4) Transport service teardown coordination 2397 First, HC issues to DC1 and DC2 a configuration request to release 2398 the Ethernet layer transport service in the respective domains. After 2399 that, all three DCs are requested to release the segments of the 2400 supporting ODUk layer hierarchy TE tunnel. While processing the 2401 request DC1 and DC2 also remove the dynamic Ethernet layer TE links 2402 supported by the respective hierarchy TE tunnel's segments, thus the 2403 network's abstract TE topologies are reverted back to the state as 2404 shown in Figures 35 and 36. 2406 2.4. Use Case 4. Transport service control on a ODUk/Och multi-domain 2407 transport network with multi-function access links 2409 Configuration (Figure 40): the same as in use case 3, except that all 2410 access links in this use case are multi-function links (depicted in 2411 the Figure as blue compound lines). Let's assume that, depending on 2412 configuration, the multi-function access links in this use case can 2413 carry either Ethernet or SDH/STM16 layer payload. 2415 Objective: Set up//delete an unprotected shortest delay SDH/STM16 2416 layer transport service interconnecting C-R2 and C-R5 2418 Figure 40. Three-domain ODUk/Och transport network with multi- 2419 function access links 2421 1) TE Topology discovery 2423 The TE Topology model considers multi-function links as parallel 2424 mutually exclusive TE links each belonging to a separate layer 2425 network. For this use case each DC exposes to HC three (ODUk-, 2426 Ethernet- and SDH/STM16-layer) abstract TE topologies (generally 2427 speaking, one abstract TE topology per each layer network supported 2428 by at least one access or inter-domain link). Like in use case 3, 2429 the lower layer (ODUk) TE nodes announce hosted by them TE tunnel 2430 termination points, TTPs, capable in this case of adopting Ethernet, 2431 SDH/STM16 or both layer payloads, The TTPs are attributed with TE 2432 inter-layer locks matching ones specified for Ethernet and/or 2433 SDH/STM16 TE links. 2435 Ethernet, SDH/STM16 and ODUk layer single-node abstract TE topologies 2436 catered to HC by each of the DCs are presented in Figure 41. 2438 HC merges the provided topologies into its own native TE Topology 2439 (the merging procedures are described in 1.4). As in use case 3 HC 2440 locks the provided TE topologies not only horizontally (i.e. between 2441 domains), but vertically (between layers) as well, thus producing a 2442 three-layer TE topology homogenously describing the three layers of 2443 the entire transport network, as well as the client-server layer 2444 adaptation relationships between the layers. This makes the merged TE 2445 topology suitable for multi-layer/inter-layer multi-domain transport 2446 service path computations. The merged TE topology is presented in 2447 Figure 42. 2449 Figure 41. ODUk, Ethernet and SDH/STM16 layer abstract TE topologies 2450 exposed by DCs 2452 Figure 42. Three-layer three-domain transport network abstract TE 2453 topology 2455 2) Transport service path computation 2457 Using the merged TE topology (Figure 42) HC's path computer selects a 2458 TE path for the requested transport service. For example, for the 2459 SDH/STM16 layer unprotected transport service the resulting TE path 2460 could be determined as marked in Figure 43. 2462 Figure 43. Multi-layer TE path computed for SDH/STM16 layer transport 2463 service 2465 3) Transport service setup coordination 2467 Same as in use case 3. 2469 4) Transport service teardown coordination 2471 Same as in use case 3. 2473 2.5. Use Case 5. Real time updates of IP/MPLS layer TE link attributes 2474 that depend on supporting transport connectivity (e.g. transport 2475 SRLGs, propagation delay, etc.) 2477 Configuration (Figure 26): the same as in use case 1, 2479 Objective: A transport service interconnecting transport ports of two 2480 IP routers across a transport network is likely to serve a link in 2481 IP/MPLS layer network, which is usually controlled by a client of the 2482 transport network, such as IP/MPLS Controller. Performance of TE 2483 applications (e.g. path computer) running on the IP/MPLS Controller 2484 depends on the accuracy of IP/MPLS layer TE link attributes. Some of 2485 these attributes can change over time and are known real-time only to 2486 a transport network controller, such as HC. Examples of said 2487 attributes are transport SRLGs, propagation delay metric, protection 2488 capacities and status, etc. The objective of this use case is to 2489 ensure up-to-date state of said attributes in the IP/MPLS 2490 Controller's internal TED via necessary updates provided in a timely 2491 manner by the controller (e.g. HC) managing transport connectivity 2492 supporting IP/MPLS layer links. 2494 Realization: 2496 o HC exposes and supports IETF TE Topology and TE Tunnel model based 2497 NBIs (the same NBIs that are exposed by DCs serving HC); 2499 o IP/MPLS Controller makes use of the exposed NBIs to set up the 2500 respective client-provider relationships with HC; 2502 o IP/MPLS Controller uses the TE Tunnel NBI to configure with HC a 2503 transport service interconnecting transport ports of a pair of IP 2504 routers desired to be adjacent in the IP/MPLS layer network. The 2505 TE Tunnel model allows for specifying in the transport service 2506 configuration request the TE topology and link IDs of the IP/MPLS 2507 TE link the requested transport service will be serving; 2509 o IP/MPLS Controller uses the TE Topology NBI to subscribe with HC 2510 on the IP/MPLS TE link notifications with respect to changes in 2511 the TE link's attributes, such as SRLGs, propagation delay, 2512 protection capabilities/status, etc.; 2514 o HC uses the TE Topology NBI to convey the requested notifications 2515 when HC learns the attributes IP/MPLS has expressed interest in or 2516 detects any changes since previous notifications (for example, due 2517 to network failure restoration/reversion procedures happened to 2518 the transport connectivity that supports the failure affected 2519 IP/MPLS links) 2521 2.6. Use Case 6. Virtual Network Service 2523 Configuration (Figure 26): the same as in use case 1, 2525 Objective: Set up two Virtual Networks for the client, with Virtual 2526 Network 1 interconnecting customer IP routers C-R1, C-R7 and C-R4 2527 over a single-node abstract TE topology, and Virtual Network 2 2528 interconnecting customer IP routers C-R2, C-R3, C-R8, C-R5 and C-R6 2529 over a full mesh link abstract TE topology as depicted in Figure 44. 2531 [Note: A client of a transport network may want to limit the 2532 transport network connectivity of a particular type and quality 2533 within distinct subsets of its network elements interconnected across 2534 the transport network. Furthermore, a given transport network may 2535 serve more than one client. In this case some or all clients may want 2536 to ensure the availability of transport network resources in case 2537 dynamic (re-)connecting of their network elements across the 2538 transport network is envisioned. In all such cases a client may want 2539 to set up one or more Virtual Networks over provided transport 2540 network] 2542 1) Virtual Network setup 2544 From the client's point of view a Virtual Network setup includes the 2545 following procedures: 2547 o Identifying the Virtual Network membership - a subset of the 2548 client's network elements/ports to be interconnected over the 2549 abstract TE topology configured for the Virtual Network. Note that 2550 from the transport network provider's point of view this 2551 effectively determines the list of abstract TE topology's open- 2552 ended access TE links; 2554 o Deciding on the Virtual Network's abstract TE topology type (e.g. 2555 single-node vs. link mesh), optimization criterion (e.g. shortest 2556 delay vs. smallest cost), bandwidth, link disjointedness, 2557 adaptation capabilities and other requirements/constraints, as 2558 well as, whether the TE tunnels supporting the abstract TE 2559 topology need to be pre-established or established on demand (i.e. 2560 when respective abstract TE topology elements are selected for a 2561 client transport service); 2563 o Using the IETF TE Topology model based NBI exposed by the 2564 transport network controller (i.e. HC), configure the Virtual 2565 Network's abstract TE topology. Let's assume that in this use case 2566 the abstract TE topology for Virtual Network 1 is configured as a 2567 single-node abstract TE topology (see section 1.3.1) with the 2568 abstract TE node's detailed connectivity matrix optimized 2569 according to the shortest delay criteria. Likewise, the abstract 2570 TE topology for Virtual Network 2 is configured as a full-mesh 2571 link abstract TE topology (see section 1.3.2) optimized according 2572 to the smallest cost criteria with each of the abstract TE links 2573 to be supported by pre-established end-to-end protected TE 2574 tunnels. 2576 [Note: Virtual Network's abstract TE topology (re- 2577 )configuration/negotiation process is no different from one that 2578 happens, for example, between HC and its providers, DCs, and is 2579 described in section 1.5] 2581 Figure 44. Virtual Networks provided for a transport network client 2583 2) Using Virtual Network 2585 Recall that use case 1 was about setting up a transport service 2586 interconnecting customer network elements C-R2 and C-R5 across the 2587 transport network. With the Virtual Network 2 in place, the client 2588 could have used the Virtual Network's TE topology to select a TE path 2589 for the service. The TE Tunnel model based NBI allows for the client 2590 to specify the Virtual Network's TE topology ID, as well, as the 2591 selected TE path (for example, as marked in Figure 45) as a 2592 configured path attribute in the transport service configuration 2593 request to ensure that the intended transport network resources are 2594 used for the service. 2596 Figure 45. Transport service TE path is selected on Virtual Network's 2597 TE topology 2599 3. Security Considerations 2601 This document does not define networking protocols and data, hence 2602 are not directly responsible for security risks. 2604 4. IANA Considerations 2606 This document has no actions for IANA. 2608 5. References 2610 5.1. Normative References 2612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2613 Requirement Levels", BCP 14, RFC 2119, March 1997. 2615 [I-D.ietf-teas-yang-te-topo] 2616 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2617 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 2618 teas-yang-te-topo-15 (work in progress), February 2018. 2620 [I-D.ietf-teas-yang-te] 2622 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and I. 2623 Bryskin, "A YANG Data Model for Traffic Engineering Tunnels 2624 and Interfaces", draft-ietf-teas-yang-te-13 (work in 2625 progress), March 2018. 2627 5.2. Informative References 2629 [RFC2702] Awduche, D., "Requirements for Traffic Engineering Over 2630 MPLS", RFC 2702, September 1999. 2632 6. Acknowledgments 2634 TBD. 2636 Appendix A. Data Examples 2638 This section contains examples of an instance data in the JSON 2639 encoding [RFC7951]. 2641 A.1. Use Case 1 2643 In the use case described in Section 2.1. , there are three provider 2644 network domains, each of them is represented as an abstract TE 2645 topology. The JSON encoded example data configurations for the three 2646 domains are: 2648 A.1.1. Domain 1 2650 { 2651 "networks": { 2652 "network": [ 2653 { 2654 "network-types": { 2655 "te-topology": {} 2656 }, 2657 "network-id": "otn-domain1-abs", 2658 "provider-id": 201, 2659 "client-id": 300, 2660 "te-topology-id": "te-topology:otn-domain1-abs", 2661 "node": [ 2662 { 2663 "node-id": "D1", 2664 "te-node-id": "2.0.1.1", 2665 "te": { 2666 "te-node-attributes": { 2667 "domain-id" : 1, 2668 "is-abstract": [null], 2669 "underlay-topology": "domain1-och", 2670 "connectivity-matrices": { 2671 "is-allowed": true, 2672 "path-constraints": { 2673 "bandwidth-generic": { 2674 "te-bandwidth": { 2675 "otn": [ 2676 { 2677 "rate-type": "odu1", 2678 "counter": 2 2680 } 2681 ] 2682 } 2683 } 2684 } 2685 "connectivity-matrix": [ 2686 { 2687 "id": 10302, 2688 "from": "1-0-3", 2689 "to": "1-2-0" 2690 }, 2691 { 2692 "id": 10203, 2693 "from": "1-0-2", 2694 "to": "1-3-0" 2695 }, 2696 { 2697 "id": 10311, 2698 "from": "1-0-3", 2699 "to": "1-11-0" 2700 }, 2701 { 2702 "id": 11103, 2703 "from": "1-0-11", 2704 "to": "1-3-0" 2705 }, 2706 { 2707 "id": 10903, 2708 "from": "1-0-9", 2709 "to": "1-3-0" 2710 }, 2711 { 2712 "id": 10309, 2713 "from": "1-0-3", 2714 "to": "1-9-0" 2715 }, 2716 { 2717 "id": 10910, 2718 "from": "1-0-9", 2719 "to": "1-10-0" 2720 }, 2721 { 2722 "id": 11009, 2723 "from": "1-0-10", 2724 "to": "1-9-0" 2725 }, 2726 { 2727 "id": 20910, 2728 "from": "1-1-9", 2729 "to": "1-10-0" 2730 }, 2731 { 2732 "id": 21009, 2733 "from": "1-0-10", 2734 "to": "1-9-1" 2735 }, 2736 { 2737 "id": 20911, 2738 "from": "1-1-9", 2739 "to": "1-11-0" 2740 }, 2741 { 2742 "id": 21109, 2743 "from": "1-0-11", 2744 "to": "1-9-1" 2745 } 2746 ] 2747 } 2748 } 2749 }, 2750 "termination-point": [ 2751 { 2752 "tp-id": "1-0-3", 2753 "te-tp-id": 10003 2754 "te": { 2755 "interface-switching-capability": [ 2756 { 2757 "switching-capability": "switching-otn", 2758 "encoding": "lsp-encoding-oduk" 2759 } 2760 ] 2761 } 2763 }, 2764 { 2765 "tp-id": "1-3-0", 2766 "te-tp-id": 10300 2767 "te": { 2768 "interface-switching-capability": [ 2769 { 2770 "switching-capability": "switching-otn", 2771 "encoding": "lsp-encoding-oduk" 2772 } 2773 ] 2774 } 2775 }, 2776 { 2777 "tp-id": "1-0-9", 2778 "te-tp-id": 10009 2779 "te": { 2780 "interface-switching-capability": [ 2781 { 2782 "switching-capability": "switching-otn", 2783 "encoding": "lsp-encoding-oduk" 2784 } 2785 ] 2786 } 2787 }, 2788 { 2789 "tp-id": "1-9-0", 2790 "te-tp-id": 10900 2791 "te": { 2792 "interface-switching-capability": [ 2793 { 2794 "switching-capability": "switching-otn", 2795 "encoding": "lsp-encoding-oduk" 2796 } 2797 ] 2798 } 2799 }, 2800 { 2801 "tp-id": "1-1-9", 2802 "te-tp-id": 10109 2803 "te": { 2804 "interface-switching-capability": [ 2805 { 2806 "switching-capability": "switching-otn", 2807 "encoding": "lsp-encoding-oduk" 2808 } 2809 ] 2810 } 2811 }, 2812 { 2813 "tp-id": "1-9-1", 2814 "te-tp-id": 10901 2815 "te": { 2816 "interface-switching-capability": [ 2817 { 2818 "switching-capability": "switching-otn", 2819 "encoding": "lsp-encoding-oduk" 2820 } 2821 ] 2822 } 2823 }, 2824 { 2825 "tp-id": "1-0-2", 2826 "te-tp-id": 10002 2827 "te": { 2828 "interface-switching-capability": [ 2829 { 2830 "switching-capability": "switching-otn", 2831 "encoding": "lsp-encoding-oduk" 2832 } 2833 ] 2834 } 2835 }, 2836 { 2837 "tp-id": "1-2-0", 2838 "te-tp-id": 10200 2839 "te": { 2840 "interface-switching-capability": [ 2841 { 2842 "switching-capability": "switching-otn", 2843 "encoding": "lsp-encoding-oduk" 2844 } 2846 ] 2847 } 2848 }, 2849 { 2850 "tp-id": "1-0-10", 2851 "te-tp-id": 10010 2852 "te": { 2853 "interface-switching-capability": [ 2854 { 2855 "switching-capability": "switching-otn", 2856 "encoding": "lsp-encoding-oduk" 2857 } 2858 ] 2859 } 2860 }, 2861 { 2862 "tp-id": "1-10-0", 2863 "te-tp-id": 11000 2864 "te": { 2865 "interface-switching-capability": [ 2866 { 2867 "switching-capability": "switching-otn", 2868 "encoding": "lsp-encoding-oduk" 2869 } 2870 ] 2871 } 2872 }, 2873 { 2874 "tp-id": "1-0-11", 2875 "te-tp-id": 10011 2876 "te": { 2877 "interface-switching-capability": [ 2878 { 2879 "switching-capability": "switching-otn", 2880 "encoding": "lsp-encoding-oduk" 2881 } 2882 ] 2883 } 2884 }, 2885 { 2886 "tp-id": "1-11-0", 2887 "te-tp-id": 11100 2888 "te": { 2889 "interface-switching-capability": [ 2890 { 2891 "switching-capability": "switching-otn", 2892 "encoding": "lsp-encoding-oduk" 2893 } 2894 ] 2895 } 2896 }, 2897 { 2898 "tp-id": "1-1-11", 2899 "te-tp-id": 10111 2900 "te": { 2901 "interface-switching-capability": [ 2902 { 2903 "switching-capability": "switching-otn", 2904 "encoding": "lsp-encoding-oduk" 2905 } 2906 ] 2907 } 2908 }, 2909 { 2910 "tp-id": "1-11-1", 2911 "te-tp-id": 11101 2912 "te": { 2913 "interface-switching-capability": [ 2914 { 2915 "switching-capability": "switching-otn", 2916 "encoding": "lsp-encoding-oduk" 2917 } 2918 ] 2919 } 2920 } 2921 ] 2922 } 2923 ] 2924 } 2925 ] 2926 } 2927 } 2929 A.1.2. Domain 2 2931 { 2932 "networks": { 2933 "network": [ 2934 { 2935 "network-types": { 2936 "te-topology": {} 2937 }, 2938 "network-id": "otn-domain2-abs", 2939 "provider-id": 202, 2940 "client-id": 300, 2941 "te-topology-id": "te-topology:otn-domain2-abs", 2942 "node": [ 2943 { 2944 "node-id": "D2", 2945 "te-node-id": "2.0.2.2", 2946 "te": { 2947 "te-node-attributes": { 2948 "is-abstract": [null], 2949 "underlay-topology": "domain2-och", 2950 "connectivity-matrices": { 2951 "is-allowed": true, 2952 "path-constraints": { 2953 "bandwidth-generic": { 2954 "te-bandwidth": { 2955 "otn": [ 2956 { 2957 "rate-type": "odu1", 2958 "counter": 2 2959 } 2960 ] 2961 } 2962 } 2963 } 2964 "connectivity-matrix": [ 2965 { 2966 "id": 12125, 2967 "from": "1-0-21", 2968 "to": "1-25-0" 2969 }, 2970 { 2971 "id": 12521, 2972 "from": "1-0-25", 2973 "to": "1-21-0" 2974 }, 2975 { 2976 "id": 12128, 2977 "from": "1-0-21", 2978 "to": "1-28-0" 2979 }, 2980 { 2981 "id": 12821, 2982 "from": "1-0-28", 2983 "to": "1-21-0" 2984 }, 2985 { 2986 "id": 12231, 2987 "from": "1-0-22", 2988 "to": "1-31-0" 2989 }, 2990 { 2991 "id": 13122, 2992 "from": "1-0-31", 2993 "to": "1-22-0" 2994 }, 2995 { 2996 "id": 22228, 2997 "from": "1-1-22", 2998 "to": "1-28-0" 2999 }, 3000 { 3001 "id": 22822, 3002 "from": "1-0-28", 3003 "to": "1-22-1" 3004 }, 3005 { 3006 "id": 12528, 3007 "from": "1-0-25", 3008 "to": "1-28-0" 3009 }, 3010 { 3011 "id": 12825, 3012 "from": "1-0-28", 3013 "to": "1-25-0" 3014 } 3015 ] 3016 } 3017 } 3018 }, 3019 "termination-point": [ 3020 { 3021 "tp-id": "1-0-21", 3022 "te-tp-id": 10021 3023 "te": { 3024 "interface-switching-capability": [ 3025 { 3026 "switching-capability": "switching-otn", 3027 "encoding": "lsp-encoding-oduk" 3028 } 3029 ] 3030 } 3031 }, 3032 { 3033 "tp-id": "1-21-0", 3034 "te-tp-id": 12100 3035 "te": { 3036 "interface-switching-capability": [ 3037 { 3038 "switching-capability": "switching-otn", 3039 "encoding": "lsp-encoding-oduk" 3040 } 3041 ] 3042 } 3043 }, 3044 { 3045 "tp-id": "1-0-22", 3046 "te-tp-id": 10022 3047 "te": { 3048 "interface-switching-capability": [ 3049 { 3050 "switching-capability": "switching-otn", 3051 "encoding": "lsp-encoding-oduk" 3053 } 3054 ] 3055 } 3056 }, 3057 { 3058 "tp-id": "1-22-0", 3059 "te-tp-id": 12200 3060 "te": { 3061 "interface-switching-capability": [ 3062 { 3063 "switching-capability": "switching-otn", 3064 "encoding": "lsp-encoding-oduk" 3065 } 3066 ] 3067 } 3068 }, 3069 { 3070 "tp-id": "1-1-22", 3071 "te-tp-id": 10122 3072 "te": { 3073 "interface-switching-capability": [ 3074 { 3075 "switching-capability": "switching-otn", 3076 "encoding": "lsp-encoding-oduk" 3077 } 3078 ] 3079 } 3080 }, 3081 { 3082 "tp-id": "1-22-1", 3083 "te-tp-id": 12201 3084 "te": { 3085 "interface-switching-capability": [ 3086 { 3087 "switching-capability": "switching-otn", 3088 "encoding": "lsp-encoding-oduk" 3089 } 3090 ] 3091 } 3092 }, 3093 { 3094 "tp-id": "1-0-25", 3095 "te-tp-id": 10025 3096 "te": { 3097 "interface-switching-capability": [ 3098 { 3099 "switching-capability": "switching-otn", 3100 "encoding": "lsp-encoding-oduk" 3101 } 3102 ] 3103 } 3104 }, 3105 { 3106 "tp-id": "1-25-0", 3107 "te-tp-id": 12500 3108 "te": { 3109 "interface-switching-capability": [ 3110 { 3111 "switching-capability": "switching-otn", 3112 "encoding": "lsp-encoding-oduk" 3113 } 3114 ] 3115 } 3116 }, 3117 { 3118 "tp-id": "1-1-25", 3119 "te-tp-id": 10125 3120 "te": { 3121 "interface-switching-capability": [ 3122 { 3123 "switching-capability": "switching-otn", 3124 "encoding": "lsp-encoding-oduk" 3125 } 3126 ] 3127 } 3128 }, 3129 { 3130 "tp-id": "1-25-1", 3131 "te-tp-id": 12501 3132 "te": { 3133 "interface-switching-capability": [ 3134 { 3135 "switching-capability": "switching-otn", 3136 "encoding": "lsp-encoding-oduk" 3137 } 3138 ] 3139 } 3140 }, 3141 { 3142 "tp-id": "1-0-28", 3143 "te-tp-id": 10028 3144 "te": { 3145 "interface-switching-capability": [ 3146 { 3147 "switching-capability": "switching-otn", 3148 "encoding": "lsp-encoding-oduk" 3149 } 3150 ] 3151 } 3152 }, 3153 { 3154 "tp-id": "1-28-0", 3155 "te-tp-id": 12800 3156 "te": { 3157 "interface-switching-capability": [ 3158 { 3159 "switching-capability": "switching-otn", 3160 "encoding": "lsp-encoding-oduk" 3161 } 3162 ] 3163 } 3164 }, 3165 { 3166 "tp-id": "1-0-31", 3167 "te-tp-id": 10031 3168 "te": { 3169 "interface-switching-capability": [ 3170 { 3171 "switching-capability": "switching-otn", 3172 "encoding": "lsp-encoding-oduk" 3173 } 3174 ] 3175 } 3177 }, 3178 { 3179 "tp-id": "1-31-0", 3180 "te-tp-id": 13100 3181 "te": { 3182 "interface-switching-capability": [ 3183 { 3184 "switching-capability": "switching-otn", 3185 "encoding": "lsp-encoding-oduk" 3186 } 3187 ] 3188 } 3189 } 3190 ] 3191 } 3192 ] 3193 } 3194 ] 3195 } 3196 } 3198 A.1.3. Domain 3 3200 { 3201 "networks": { 3202 "network": [ 3203 { 3204 "network-types": { 3205 "te-topology": {} 3206 }, 3207 "network-id": "otn-domain3-abs", 3208 "provider-id": 203, 3209 "client-id": 300, 3210 "te-topology-id": "te-topology:otn-domain3-abs", 3211 "node": [ 3212 { 3213 "node-id": "D3", 3214 "te-node-id": "2.0.3.3", 3215 "te": { 3216 "te-node-attributes": { 3217 "is-abstract": [null], 3218 "underlay-topology": "domain3-och", 3219 "connectivity-matrices": { 3220 "is-allowed": true, 3221 "path-constraints": { 3222 "bandwidth-generic": { 3223 "te-bandwidth": { 3224 "otn": [ 3225 { 3226 "rate-type": "odu1", 3227 "counter": 2 3228 } 3229 ] 3230 } 3231 } 3232 } 3233 "connectivity-matrix": [ 3234 { 3235 "id": 13638, 3236 "from": "1-0-38", 3237 "to": "1-38-0" 3238 }, 3239 { 3240 "id": 13836, 3241 "from": "1-0-38", 3242 "to": "1-36-0" 3243 }, 3244 { 3245 "id": 13639, 3246 "from": "1-0-36", 3247 "to": "1-39-0" 3248 }, 3249 { 3250 "id": 13936, 3251 "from": "1-0-39", 3252 "to": "1-36-0" 3253 }, 3254 { 3255 "id": 23636, 3256 "from": "1-0-36", 3257 "to": "1-36-1" 3258 }, 3259 { 3260 "id": 33636, 3261 "from": "1-1-36", 3262 "to": "1-36-0" 3263 }, 3264 { 3265 "id": 13739, 3266 "from": "1-0-37", 3267 "to": "1-39-0" 3268 }, 3269 { 3270 "id": 13937, 3271 "from": "1-0-39", 3272 "to": "1-37-0" 3273 }, 3274 { 3275 "id": 23737, 3276 "from": "1-0-37", 3277 "to": "1-37-1" 3278 }, 3279 { 3280 "id": 33737, 3281 "from": "1-1-37", 3282 "to": "1-37-0" 3283 } 3284 ] 3285 } 3286 } 3287 }, 3288 "termination-point": [ 3289 { 3290 "tp-id": "1-0-36", 3291 "te-tp-id": 10036 3292 "te": { 3293 "interface-switching-capability": [ 3294 { 3295 "switching-capability": "switching-otn", 3296 "encoding": "lsp-encoding-oduk" 3297 } 3298 ] 3299 } 3301 }, 3302 { 3303 "tp-id": "1-36-0", 3304 "te-tp-id": 13600 3305 "te": { 3306 "interface-switching-capability": [ 3307 { 3308 "switching-capability": "switching-otn", 3309 "encoding": "lsp-encoding-oduk" 3310 } 3311 ] 3312 } 3313 }, 3314 { 3315 "tp-id": "1-0-37", 3316 "te-tp-id": 10037 3317 "te": { 3318 "interface-switching-capability": [ 3319 { 3320 "switching-capability": "switching-otn", 3321 "encoding": "lsp-encoding-oduk" 3322 } 3323 ] 3324 } 3325 }, 3326 { 3327 "tp-id": "1-37-0", 3328 "te-tp-id": 13700 3329 "te": { 3330 "interface-switching-capability": [ 3331 { 3332 "switching-capability": "switching-otn", 3333 "encoding": "lsp-encoding-oduk" 3334 } 3335 ] 3336 } 3337 }, 3338 { 3339 "tp-id": "1-1-37", 3340 "te-tp-id": 10137 3341 "te": { 3342 "interface-switching-capability": [ 3343 { 3344 "switching-capability": "switching-otn", 3345 "encoding": "lsp-encoding-oduk" 3346 } 3347 ] 3348 } 3349 }, 3350 { 3351 "tp-id": "1-37-1", 3352 "te-tp-id": 13701 3353 "te": { 3354 "interface-switching-capability": [ 3355 { 3356 "switching-capability": "switching-otn", 3357 "encoding": "lsp-encoding-oduk" 3358 } 3359 ] 3360 } 3361 }, 3362 { 3363 "tp-id": "1-0-39", 3364 "te-tp-id": 10039 3365 "te": { 3366 "interface-switching-capability": [ 3367 { 3368 "switching-capability": "switching-otn", 3369 "encoding": "lsp-encoding-oduk" 3370 } 3371 ] 3372 } 3373 }, 3374 { 3375 "tp-id": "1-39-0", 3376 "te-tp-id": 13900 3377 "te": { 3378 "interface-switching-capability": [ 3379 { 3380 "switching-capability": "switching-otn", 3381 "encoding": "lsp-encoding-oduk" 3382 } 3384 ] 3385 } 3386 }, 3387 { 3388 "tp-id": "1-0-36", 3389 "te-tp-id": 10036 3390 "te": { 3391 "interface-switching-capability": [ 3392 { 3393 "switching-capability": "switching-otn", 3394 "encoding": "lsp-encoding-oduk" 3395 } 3396 ] 3397 } 3398 }, 3399 { 3400 "tp-id": "1-36-0", 3401 "te-tp-id": 13600 3402 "te": { 3403 "interface-switching-capability": [ 3404 { 3405 "switching-capability": "switching-otn", 3406 "encoding": "lsp-encoding-oduk" 3407 } 3408 ] 3409 } 3410 }, 3411 { 3412 "tp-id": "1-0-38", 3413 "te-tp-id": 10038 3414 "te": { 3415 "interface-switching-capability": [ 3416 { 3417 "switching-capability": "switching-otn", 3418 "encoding": "lsp-encoding-oduk" 3419 } 3420 ] 3421 } 3422 }, 3423 { 3424 "tp-id": "1-38-0", 3425 "te-tp-id": 13800 3426 "te": { 3427 "interface-switching-capability": [ 3428 { 3429 "switching-capability": "switching-otn", 3430 "encoding": "lsp-encoding-oduk" 3431 } 3432 ] 3433 } 3434 } 3435 ] 3436 } 3437 ] 3438 } 3439 ] 3440 } 3441 } 3443 Contributors 3445 Italo Busi 3446 Huawei 3447 Email: italo.busi@huawei.com 3449 Sergio Belotti 3450 Nokia 3451 Email: sergio.belotti@nokia.com 3453 Authors' Addresses 3455 Igor Bryskin 3456 Huawei Technologies 3457 Email: Igor.Bryskin@huawei.com 3459 Vishnu Pavan Beeram 3460 Juniper Networks 3461 Email: vbeeram@juniper.net 3463 Tarek Saad 3464 Juniper Networks 3465 Email: tsaad@juniper.net 3466 Xufeng Liu 3467 Volta Networks 3468 Email: xufeng.liu.ietf@gmail.com