idnits 2.17.1 draft-bryskin-teas-te-topo-and-tunnel-modeling-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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...' == (12 more instances...) == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (June 29, 2017) is 2486 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: 'RFC7951' is mentioned on line 2369, but not defined == Unused Reference: 'I-D.ietf-teas-yang-te' is defined on line 2350, but no explicit reference was found in the text == Unused Reference: 'RFC2702' is defined on line 2359, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-ietf-teas-yang-te-topo-08 Summary: 2 errors (**), 0 flaws (~~), 12 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 Juniper Networks 5 Tarek Saad 6 Cisco Systems Inc 7 Xufeng Liu 8 Jabil 10 Expires: December 29, 2017 June 29, 2017 12 TE Topology and Tunnel Modeling for Transport Networks 13 draft-bryskin-teas-te-topo-and-tunnel-modeling-00 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on December 29, 2017. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 This document describes how to model TE topologies and tunnels for 56 transport networks, by using the TE topology YANG model [I-D.ietf- 57 teas-yang-te-topo] and the TE tunnel YANG model [I-D.ietf-teas-yang- 58 te]. 60 Conventions used in this document 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC-2119 [RFC2119]. 66 Table of Contents 68 1. Modeling Considerations........................................3 69 1.1. TE Topology Model.........................................3 70 1.2. TE Topology Modeling Constructs...........................5 71 1.3. Abstract TE Topology Calculation, Configuration and 72 Maintenance...................................................22 73 1.3.1. Single-Node Abstract TE Topology....................24 74 1.3.2. Full Mesh Link Abstract TE Topology.................26 75 1.3.3. Star-n-Spokes Abstract TE Topology..................28 76 1.3.4. Arbitrary Abstract TE Topology......................29 77 1.3.5. Customized Abstract TE Topologies...................30 78 1.3.6. Hierarchical Abstract TE Topologies.................31 79 1.4. Merging TE Topologies Provided By Multiple Providers.....32 80 1.4.1. Dealing With Multiple Abstract TE Topologies Provided By 81 The Same Provider..........................................35 82 1.5. Configuring Abstract TE Topologies.......................37 83 1.6. TE Tunnel Model..........................................38 84 1.7. TE Tunnel/Transport Service Modeling Constructs..........40 85 1.8. Transport Service Mapping................................51 86 1.9. Multi-Domain Transport Service Coordination..............52 87 2. Use Cases.....................................................56 88 2.1. Use Case 1. Transport service control on a single layer 89 multi-domain transport network................................56 90 2.2. Use Case 2. End-to-end TE tunnel control on a single layer 91 multi-domain transport network................................64 92 2.3. Use Case 3. Transport service control on a ODUk/Och multi- 93 domain transport network with Ethernet access links...........68 94 2.4. Use Case 4. Transport service control on a ODUk/Och multi- 95 domain transport network with multi-function access links.....75 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.).....................78 99 2.6. Use Case 6. Virtual Network Service......................79 100 3. Security Considerations.......................................82 101 4. IANA Considerations...........................................83 102 5. References....................................................83 103 5.1. Normative References.....................................83 104 5.2. Informative References...................................83 105 6. Acknowledgments...............................................83 106 Appendix A. Data Examples........................................84 107 A.1. Use Case 1...............................................84 108 A.1.1. Domain 1............................................84 109 A.1.2. Domain 2............................................91 110 A.1.3. Domain 3............................................98 111 Authors' Addresses..............................................104 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 alterative method of modeling client-server 663 adaptation relationship. Transitional link is a bi-directional 664 link connecting an LTP in a client layer to an LTP in a server 665 layer, which is associated (via TTP's LLCL) with a server layer 666 TTP capable of adopting of the client layer data onto a TE tunnel 667 terminated by the TTP. Important attributes pf a transitional link 668 are loca;/remote LTP IDs, TE metric and available adaptation 669 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 Potential TE tunnel/segment - a TE tunnel/segment configured in 1494 COMPUTE_ONLY mode. For such a TE tunnel/segment TE paths to be 1495 taken by supporting connection(s) is/are computed and monitored, 1496 but the connection(s) are not provisioned 1498 _____________________________________________________________________ 1500 | | | | +--rw path-computation-method? identityref 1501 | | | | +--rw path-computation-server? inet:ip- 1502 address 1503 | | | | +--rw compute-only? empty 1504 | | | | +--rw use-cspf? Boolean 1505 _____________________________________________________________________ 1506 Figure 20a. TE Tunnel Connections/LSPs 1508 o Layer network connection/connection/LSP - a layer network path 1509 supporting a TE tunnel by realizing its implied forwarding 1510 function. Said path is provisioned in a given layer network's data 1511 plane over a chain of links and cross-connected over switches 1512 terminating the links. It interconnects the supported TE tunnel's 1513 source and destination termination points (in the case of end-to- 1514 end connection) or TE tunnel's hand-off points (in the case of 1515 transport service connection) or the TE tunnel's two split-merge 1516 points (in the case of segment protection connection. 1518 Example: ODU2 connection supporting an ODU2 TE tunnel. 1520 _____________________________________________________________________ 1522 /* LSP (provisioned path) */ 1524 | | | | +--ro lsp* [source destination tunnel-id 1525 lsp-id extended-tunnel-id type] 1526 /* LSP parameters */ 1527 | | | | +--ro source leafref 1528 | | | | +--ro destination leafref 1529 | | | | +--ro tunnel-id leafref 1530 | | | | +--ro lsp-id leafref 1531 | | | | +--ro extended-tunnel-id leafref 1532 | | | | +--ro type leafref 1533 | | | | +--ro signaling-type? identityref 1534 .................................................................. 1535 | | | +--ro priority? uint16 1536 | | | +--ro path-setup-protocol? 1537 identityref 1538 | | | +--ro active? Boolean 1539 _____________________________________________________________________ 1541 o Working connection - the primary connection of the supported TE 1542 tunnel or transport service (see Figure 20a). 1544 o End-to-end protection connection - a secondary end-to-end 1545 connection of the supported TE tunnel (e.g. end-to-end 1+1 1546 protection connection, see Figure 20a). 1548 o Segment protection connection - a secondary connection of the 1549 supported transport service protecting the service over a given 1550 network domain (e.g. 1+1 segment protection connection, see Figure 1551 20a) 1553 o Unprotected TE tunnel/transport service - TE tunnel/transport 1554 service supported by a single (working/primary) connection/LSP 1556 o Protected TE tunnel/transport service - TE tunnel/transport 1557 service supported by one working connection/LSP and at least one 1558 protection/secondary connection/LSP 1560 o Connection configured path - a TE path (see 1.2) over a TE 1561 topology describing a layer network/domain that specifies (loosely 1562 or strictly) the client's requirements with respect to an ordered 1563 list of network nodes, links and resources on the links a given 1564 connection should go through 1566 _____________________________________________________________________ 1567 | | +--rw explicit-route-object* [index] 1568 | | +--rw index leafref 1569 | | +--rw explicit-route-usage? identityref 1570 (INCLUDE/EXCLUDE) 1571 | | | +--rw index? uint32 1572 | | | +--rw (type)? 1573 | | | +--:(numbered) 1574 | | | | +--rw numbered-hop 1575 | | | | +--rw address? te-types:te-tp- 1576 id 1577 | | | | +--rw hop-type? te-hop-type 1578 | | | +--:(as-number) 1579 | | | | +--rw as-number-hop 1580 | | | | +--rw as-number? binary 1581 | | | | +--rw hop-type? te-hop-type 1582 | | | +--:(unnumbered) 1583 | | | | +--rw unnumbered-hop 1584 | | | | +--rw node-id? te-types:te- 1585 node-id 1586 | | | | +--rw link-tp-id? te-types:te- 1587 tp-id 1588 | | | | +--rw hop-type? te-hop-type 1589 | | | +--:(label) 1590 | | | | +--rw label-hop 1591 | | | | +--rw value? rt- 1592 types:generalized-label 1593 | | | +--:(sid) 1594 | | | +--rw sid-hop 1595 | | | +--rw sid? rt- 1596 types:generalized-label 1597 _____________________________________________________________________ 1599 o Connection exclusion path - a TE path over a TE topology 1600 describing a layer network/domain that specifies the client's 1601 requirements with respect to an unordered list of network nodes, 1602 links and resources on the links to be avoided by a given 1603 connection 1605 _____________________________________________________________________ 1607 | | +--rw route-object-exclude-always* [index] 1608 | | | +--rw index leafref 1609 | | | | +--rw index? uint32 1610 | | | | +--rw (type)? 1611 | | | | +--:(numbered) 1612 | | | | | +--rw numbered-hop 1613 | | | | | +--rw address? te-types:te-tp- 1614 id 1615 | | | | +--:(as-number) 1616 | | | | | +--rw as-number-hop 1617 | | | | | +--rw as-number? binary 1618 | | | | +--:(unnumbered) 1619 | | | | | +--rw unnumbered-hop 1620 | | | | | +--rw node-id? te-types:te- 1621 node-id 1622 | | | | | +--rw link-tp-id? te-types:te- 1623 tp-id 1624 | | | | +--:(label) 1625 | | | | | +--rw label-hop 1626 | | | | | +--rw value? rt- 1627 types:generalized-label 1628 | | | | +--:(sid) 1629 | | | | +--rw sid-hop 1630 | | | | +--rw sid? rt- 1631 types:generalized-label 1632 _____________________________________________________________________ 1634 o Connection computed path - a TE path over a TE topology describing 1635 a layer network/domain as computed (subject to all configured 1636 constraints and optimization criteria) for a given connection to 1637 take. Computed connection path could be thought as the TE path 1638 intended to be taken by the connection 1640 _____________________________________________________________________ 1642 /* Computed path */ 1643 /* Computed path properties/metrics / 1644 | | | | +--ro computed-path-properties 1645 | | | | | +--ro path-metric* [metric-type] 1646 | | | | | | +--ro metric-type identityref 1647 | | | | | | +--ro accumulative-value? uint64 1648 /* Computed path affinities */ 1649 | | | | | +--ro path-affinities 1650 | | | | | | +--ro constraints* [usage] 1651 | | | | | | | +--ro usage? 1652 identityref 1653 | | | | | | | +--ro (style)? 1654 | | | | | | | +--:(value) 1655 | | | | | | | | +--ro value? te- 1656 types:admin-groups 1657 | | | | | | | +--:(named) 1658 | | | | | | | +--ro affinity-names* 1659 [name] 1660 | | | | | | | +--ro name string 1661 /* Computed path SRLGs */ 1662 | | | | | +--ro path-srlgs 1663 | | | | | | +--ro (style)? 1664 | | | | | | +--:(values) 1665 | | | | | | | +--ro usage? identityref 1666 | | | | | | | +--ro values* te- 1667 types:srlg 1668 | | | | | | +--:(named) 1669 | | | | | | +--ro constraints* [usage] 1670 | | | | | | +--ro usage 1671 identityref 1672 | | | | | | +--ro constraint 1673 | | | | | | +--ro srlg-names* [name] 1674 | | | | | | +--ro name string 1675 /* Computed path sub-objects */ 1676 | | | | | +--ro path-computed-route-objects 1677 .............................................................. 1678 _____________________________________________________________________ 1680 o Connection actual path - an active connection's path as 1681 provisioned in the layer network's data plane in the form of a TE 1682 path over a TE topology describing the layer network/domain 1684 1.8. Transport Service Mapping 1686 Figure 21. Transport Service Mapping 1688 Let's assume that a provider has exposed to a client its network 1689 domain in the form of an abstract TE topology, as shown on the left 1690 side of Figure 21. From then on, the provider should be prepared to 1691 receive from the client, a request to set up or manipulate a 1692 transport service with TE path(s) computed for the service 1693 connection(s) based on and expressed in terms of the provided 1694 abstract TE topology (as, for example, displayed in red broken line 1695 on the right side of Figure 21). When this happens, the provider is 1696 expected to set up the TE tunnels supporting all yet uncommitted 1697 abstract TE links (e. g, TE link S3'-S8' in the Figure). 1699 Furthermore, it is the responsibility of the provider to: 1701 o Perform all the necessary abstract-to-native translations for the 1702 specified TE paths (i.e. the transport service connection 1703 configured paths); 1705 o Provision working and protection connections supporting the 1706 transport service; as well as replace/modify/delete them in 1707 accordance with subsequent client's configuration requests; 1709 o Perform all the requested recovery operations upon detecting 1710 network failures affecting the transport service; 1712 o Notify the client about all parameter changes, events and other 1713 telemetry information the client has expressed an interest in, 1714 with respect to the transport service in question. 1716 1.9. Multi-Domain Transport Service Coordination 1718 A client of multiple TE network domains may need to 1719 orchestrate/coordinate its transport service setup/manipulation 1720 across some or all the domains. One example of such a client is a 1721 Hierarchical T-SDN Controller, HC, managing a connected multi-domain 1722 transport network where each of the domains is controlled by a 1723 separate Domain T-SDN Controller, DC. Said DCs are expected to expose 1724 TE Topology and TE Tunnel North Bound Interfaces, NBIs,, supported 1725 respectively by IETF TE Topology and TE Tunnel models (and their 1726 network layer specific augmentations). HC is assumed to establish 1727 client-provider relationship with each of the DCs and make use of 1728 said NBIs to extract from the domains various information (such as TE 1729 topologies and telemetry), as well as to convey instructions to 1730 coordinate across multiple domains its transport services set up and 1731 manipulation. 1733 Figure 22. Two-Domain Transport Network 1735 Let's consider, for example, a two-domain transport network as 1736 represented in Figure 22. Suppose that HC is requested to set up an 1737 unprotected transport service to provide connectivity between 1738 customer network elements C-R1 and C-R6. It is assumed that by the 1739 time the request has arrived, the two DCs have already provided 1740 abstract TE topologies describing their respective domains, and that 1741 HC has merged the provided TE topologies into one that homogeneously 1742 describes the entire transport network (as shown in Figure 23). 1744 Figure 23. Two-Domain Transport Network (Abstracted View) 1746 Consider that HC, using the merged TE topology, selected a TE path to 1747 be taken by the requested transport service connection as shown on 1748 the upper part of Figure 24. 1750 The multi-domain transport service set up coordination includes: 1752 o Splitting selected for the transport service TE path(s) into 1753 segments - one set of segments per each domain involved in the 1754 service setup; 1756 o Issuing a configuration request to each of the involved DCs to set 1757 up the transport service across the respective domain. Note that 1758 the connection configured paths are required to be expressed in 1759 terms of respective abstract TE topologies as exposed to HC by DCs 1760 (see lower part of Figure 24). 1762 o Waiting for the set up complete confirmation from each of the 1763 involved DCs. In case one of the DCs reports a failure, HC is 1764 responsible to carry out the cleanup/rollback procedures by 1765 requesting all involved DCs to tear down the successfully created 1766 segments 1768 Figure 24. Transport Service Placement Based on Abstract TE Topology 1770 While processing the received from HC configuration request to set up 1771 the transport service, each DC is expected to carry out the transport 1772 service mapping procedures (as described in 1.8) resulting in the set 1773 up of all the necessary underlay TE tunnels, as well as one or more 1774 connections supporting the transport service. As a result, the 1775 requested transport service will be provisioned as shown in Figure 1776 25. 1778 The multi-domain transport service tear down coordination entails 1779 issuing to each of the involved DCs a configuration request to delete 1780 the transport service in the controlled by the DC domain. DCs are 1781 expected in this case to release all network resources allocated for 1782 the transport service. 1784 The multi-domain transport service modify coordination implies 1785 issuing to each of the involved DCs a configuration request to 1786 replace the transport service connections according to the newly 1787 provided paths and/or modify the connection parameters according to 1788 the newly provided configuration. 1790 Figure 25. Multi-domain transport service is provisioned 1792 2. Use Cases 1794 2.1. Use Case 1. Transport service control on a single layer multi- 1795 domain transport network 1797 Configuration (Figure 26): 1799 o Three-domain multi-vendor ODUk/Och transport network; 1801 o The domains are interconnected via ODUk inter-domain links; 1803 o Each of the domains is comprised of ODUk/Och network elements 1804 (switches) from a separate vendor and is controlled by a single 1805 (vendor specific) T-SDN Domain Controller (DC); 1807 o All DCs expose IETF TE Topology and TE Tunnel model based NBIs; 1809 o The transport network as a whole is controlled by a single 1810 hierarchical T-SDN controller (HC); 1812 o HC makes use of the NBIs to set up client-provider relationship 1813 with each of the DCs and controls via the DCs their respective 1814 network domains; 1816 o Three customer IP/MPLS sites are connected to the transport 1817 network via ODUk access links; 1819 o The customer IP/MPLS routers and the router transport ports 1820 connecting the routers to the transport network are managed 1821 autonomously and independently from the transport network. 1823 Figure 26 Three-domain ODUk/Och transport network with ODUk access 1824 and inter-domain links 1826 Objective: Set up/manipulate/delete a shortest delay unprotected or 1827 protected transport service to provide connectivity between customer 1828 network elements C-R2 and C-R5 1830 1) TE Topology discovery 1832 All DCs provide to HC respective domain ODUk layer abstract TE 1833 topologies. Let's assume that each such topology is a single-node TE 1834 topology (as described in 1.3.1, abstract TE topology of this type 1835 represents the entire domain as a single asymmetrical/blocking TE 1836 node). Let's further assume that the abstract TE nodes representing 1837 the domains are attributed with detailed connectivity matrices 1838 optimized according to the shortest delay criterion. [Note: single- 1839 node abstract TE topologies are assumed for simplicity sake. 1840 Alternatively, any DC could have provided an abstract TE topology of 1841 any type described in 1.3]. 1843 HC merges the provided TE topologies into its own native TE topology 1844 (the TE topology merging procedures are discussed in 1.4). The merged 1845 TE topology, as well as the TE topologies provided by DCs, are 1846 depicted in Figure 27. The merged TE topology homogeneously describes 1847 the entire transport network and hence is suitable for path 1848 computations across the network. Note that the dotted lines in the 1849 Figure connecting the topology access TE links with customer devices 1850 illustrate that HC in this use case has neither control nor 1851 information on the customer devices/ports and, therefore, can only 1852 provide a connectivity between the requested transport service 1853 ingress and egress access links (on assumption that the customer 1854 transport ports are provisioned independently) 1856 Figure 27. Three-domain single layer transport network abstract TE 1857 topology 1859 2) Transport service path computation 1861 Using the merged TE topology (Figure 27, upper part) HC selects one 1862 or more optimal and sufficiently disjoint from each other TE path(s) 1863 for the requested transport service connection(s). Resulting TE paths 1864 for the requested end-to-end protected transport service, for 1865 example, could be as marked on the upper part of Figure 28. 1867 It is important to keep in mind that HC's path computer is capable of 1868 performing the necessary path selection only as long as the merged TE 1869 topology provides the necessary TE visibility for the path selection, 1870 both intra-domain (e.g. by virtue of provided by the abstract TE 1871 nodes detailed connectivity matrices) and inter-domain (because of 1872 provided inter-domain TE link attributes). In case one or more DCs 1873 is/are not capable of or willing to provide the detailed connectivity 1874 matrices (that is, DCs expose the respective domains as black boxes - 1875 unconstrained TE nodes terminating the inter-domain TE links), HC 1876 will not be able to select the end-to-end TE path(s) for the 1877 requested transport service on its own. In such a case HC may opt for 1878 making use of the Path Computation NBI, exposed by the DCs to 1879 explore/evaluate intra-domain TE path availability in real time. IETF 1880 TE Tunnel model supports the Path Computation NBI by allowing for the 1881 configuration of transport services in COMPUTE_ONLY mode. In this 1882 mode the provider is expected to compute TE paths for a requested 1883 transport service connections and return the paths in the request's 1884 response without triggering the connection provisioning in the 1885 network. 1887 Consider, for example, the case when none of the DCs has provided the 1888 detailed connectivity matrix attribute for the abstract TE nodes 1889 representing the respective domain. In such a case HC may: 1891 1. Request the ingress domain DC (i.e. DC1) to compute intra-domain 1892 TE paths connecting the ingress access TE link (i.e. the link 1893 facing C-R2) with each of the inter-domain TE links (i.e. links 1894 connecting Domain 1 to Domain 2 and Domain 3 respectively); 1896 2. Grow the TE paths returned by DC1 in (1) over the respective 1897 outbound inter-domain TE links; 1899 3. Request the neighboring DC(s) (e.g. DC3) to compute all intra- 1900 domain TE paths connecting across the domain all inbound into 1901 the domain inter-domain TE links reached by the path growing 1902 process in (2) with all other (outbound) domain's inter-domain 1903 TE links; 1905 4. Augment the TE paths produced in step (2) with the TE paths 1906 determined in step (3); 1908 5. Repeat steps (2), (3) and (4) until the resulting TE paths reach 1909 the egress domain (i.e. Domain 2); 1911 6. Request the egress domain DC (i.e. DC2) to grow each of the TE 1912 paths across the domain to connect them to the egress access TE 1913 link (i.e. the link facing C-R5); 1915 7. Select one (or more) most optimal and sufficiently disjoint from 1916 each other TE path(s) from the list produced in step (6). 1918 [Note: The transport service path selection method based on Path 1919 Computation NBIs exposed by DCs does not scale well and the more 1920 domains comprise the network and the more inter-domain links 1921 interconnect them, the worse the method works. Realistically, this 1922 approach will not work sufficiently well for the networks with more 1923 than 3 domains] 1924 Figure 28. TE paths computed for the protected transport service 1926 3) Transport service setup coordination 1928 HC carries out the multi-domain transport service setup coordination 1929 as described in 1.9. In particular, HC splits the computed TE path(s) 1930 into 3 sets of TE path segments - one set per domain (as shown on the 1931 lower part of Figure 28), and issues a TE tunnel configuration 1932 request to each of the DCs to set up the requested transport service 1933 across the domain under the DC's control. The primary (and 1934 secondary) connection explicit path(s) is/are specified in the 1935 requests in terms of respective domain abstract TE topologies. 1937 While processing the configuration request, each DC performs the 1938 transport service mapping (as described in 1.8). In particular, the 1939 DC translates the specified explicit path(s) from abstract into 1940 native TE topology terms, sets up supporting underlay TE tunnels 1941 (e.g. Och TE tunnels), and, then, allocates required ODUk containers 1942 on the selected links and provisions the ODUk cross-connects on the 1943 switches terminating the links. 1945 If the setup is successfully completed in all three domains, the 1946 transport service connection(s) will be provisioned as depicted in 1947 Figure 29. If one of the DCs fails to set up its part, all 1948 successfully provisioned segments will be asked by HC to be released. 1950 4) Transport service teardown coordination 1952 HC issues to each of DCs a configuration request to release the 1953 transport service over the controlled domain, as well as the server 1954 layer TE tunnels supporting dynamically created links. 1956 Figure 29. Transport service is provisioned 1958 2.2. Use Case 2. End-to-end TE tunnel control on a single layer multi- 1959 domain transport network 1961 Configuration (Figure 26): the same as in use case 1, except that HC 1962 in this use case controls customer devices/ports by extracting 1963 information from and pushing configuration to the customer site SDN 1964 controller(s) managing the customer devices directly. 1966 Objective: Set up//delete an unprotected shortest delay TE tunnel 1967 interconnecting end-to-end C-R2 and C-R5 1969 1) TE Topology discovery 1971 As in use case 1 all DCs provide to HC domain ODUk layer abstract TE 1972 topologies. Additionally in this use the three customer site 1973 controllers expose the TE Topology and Tunnel model based NBIs to HC. 1974 Using the TE Topology NBI each customer controller provides to HC the 1975 respective customer site domain abstract TE topology. Customer site 1976 abstract TE topologies contain abstract TE nodes representing the 1977 devices which are directly connected to the transport network. Said 1978 abstract TE nodes host TE tunnel termination points, TTPs, 1979 representing the ports over which the customer devices are connected 1980 to the transport network, and terminate access TE links the TTPs are 1981 accessible from (see Figure 30). 1983 Figure 30. Abstract TE topologies provided by all network domains and 1984 customer sites 1986 HC merges the provided topologies into its own native TE Topology 1987 (the TE topology merging procedures are discussed in 1.4). The merged 1988 TE topology is depicted in Figure 31. It homogeneously describes end- 1989 to-end not only the entire transport network, but also the customer 1990 sites connected to the network and hence is suitable for TE tunnel 1991 end to end path computations. 1993 Figure 31. Abstract TE topology describing transport network and 1994 connected to it customer sites 1996 2) TE tunnel path computation 1998 Using the merged TE topology (Figure 31) HC selects an optimal TE 1999 path for the requested TE tunnel connecting end-to-end the specified 2000 TE tunnel termination points, TTPs. The resulting TE path, for 2001 example, could be as marked on the upper part of Figure 32. 2003 Figure 32. TE path computed for the TE tunnel 2005 3) TE tunnel setup coordination 2007 HC carries out the multi-domain TE tunnel setup coordination as 2008 described for use case 1, except that in this use case HC 2009 additionally initiates and controls the setup of the TE tunnel's head 2010 and tail segments on the respective customer sites. Note that the 2011 customer site controllers behave exactly as transport network domain 2012 DCs. In particular, they receive issued by HC configuration requests 2013 to set up the TE tunnel's head and tail segments respectively. While 2014 processing the requests the customer site controllers perform the 2015 necessary provisioning of the TE tunnel's source and destination 2016 termination points, as well as of the local sides of the selected 2017 access links. If all segments are successfully provisioned on 2018 customer sites and network domains, the TE tunnel connection will be 2019 provisioned as marked in Figure 33. 2021 4) TE tunnel teardown coordination 2023 HC issues to each of DCs and customer site controllers a 2024 configuration request to release respective segments of the TE 2025 tunnel, as well as the server layer TE tunnels supporting dynamically 2026 created links. 2028 Figure 33. TE tunnel is provisioned 2030 2.3. Use Case 3. Transport service control on a ODUk/Och multi-domain 2031 transport network with Ethernet access links 2033 Configuration (Figure 34): the same as in use case 1, except that all 2034 access links in this use case are Ethernet layer links (depicted as 2035 blue lines in the Figure), while all inter-domain links remain to be 2036 ODUk layer links. 2038 Figure 34. Three-domain ODUk/Och transport network with Ethernet 2039 layer access links 2041 Objective: Set up//delete an unprotected shortest delay transport 2042 service supporting connectivity between C-R2 and C-R5 2044 1) TE Topology discovery 2046 In order to make possible for the necessary in this use case multi- 2047 layer path computation, each DC exposes to HC two (ODUk layer and 2048 Ethernet layer) abstract TE topologies, Additionally, the lower 2049 layer (ODUk) TE nodes announce hosted by them TE tunnel termination 2050 points, TTPs, capable of adopting the payload carried over the 2051 Ethernet layer access links, From the TE Topology model point of view 2052 this means that said TTPs are attributed with TE inter-layer locks 2053 matching ones attributed to Ethernet TE links (i.e. TE links provided 2054 within Ethernet layer abstract TE topologies). 2056 Ethernet and ODUk layer single node abstract TE topologies catered to 2057 HC by each of the DCs are presented in Figure 35. 2059 HC merges the provided TE topologies into its own native TE Topology 2060 (the merging procedures are described in 1.4). Importantly in this 2061 case HC locks the provided TE topologies not only horizontally, but 2062 vertically as well, thus producing a two-layer TE topology 2063 homogenously describing both layers of the entire transport network, 2064 as well as the client-server layer adaptation relationships between 2065 the two layers. This makes the merged TE topology suitable for multi- 2066 layer/inter-layer multi-domain transport service path computations. 2067 The merged TE topology is presented in Figure 36. 2069 Figure 35. ODUk and Ethernet layer abstract TE topologies exposed by 2070 DCs 2072 Figure 36. Two-layer three-domain transport network abstract TE 2073 topology 2075 2) Transport service path computation 2077 Using the merged TE topology (Figure 36) HC selects an optimal TE 2078 path for the requested transport service. 2080 Note that if HC's path computer considered only Ethernet layer TE 2081 nodes and links, the path computation would .fail. This is because 2082 the Ethernet layer TE nodes (i.e. D1-e, D2-e and D3-e in the Figure) 2083 are disconnected from each other. However, the inter-layer 2084 associations (in the form of the TE inter-layer locks) make possible 2085 for the path computer to select TE path(s) in the lower (ODUk) layer 2086 that can be used to set up hierarchy TE tunnel(s) supporting 2087 additional dynamic TE link(s) in the upper (Ethernet ) layer in order 2088 for the requested transport service path computation to succeed. 2090 Let's sssume that the resulting TE path is as marked in Figure 37. 2091 The red line in the Figure marks the TE path selected for the ODUk 2092 layer hierarchy TE tunnel supporting the required Ethernet layer 2093 dynamic TE link. 2095 Figure 37. Multi-layer TE path computed for the transport service 2097 3) Transport service setup coordination 2098 HC sets up the requested Ethernet layer transport service in two 2099 stages. First, it coordinates the end-to-end setup of the ODUk layer 2100 hierarchy TE tunnel between the selected TTPs. If this operation 2101 succeeds, a new Ethernet layer dynamic TE link (blue line connecting 2102 TE nodes D1-e and D2-e in Figure 38) is automatically added to the 2103 merged abstract TE topology. Importantly, as a part of the hierarchy 2104 transport service setup both DC1 and DC 2 add a new open-ended 2105 Ethernet layer inter-domain dynamic TE link to their respective 2106 abstract TE topologies. Second, HC coordinates the setup of the 2107 requested (Ethernet layer) transport service. The required TE path 2108 for the second stage is marked as fat blue line in the Figure. Note 2109 that DC3 controlling domain 3 is only involved in the first stage, 2110 but is oblivious to the second stage. 2112 Figure 38. A new Ethernet layer TE link supported by ODUk layer TE 2113 tunnel is added to the provided and merged abstract TE topologies 2115 IF all involved DCs confirm successful setup completion, the 2116 requested transport service, as well as the supporting server layer 2117 hierarchy TE tunnel, will be provisioned as depicted in Figure 39. If 2118 one of the DCs fails to set up its segment in either of the layers, 2119 all successfully provisioned segments will be requested by HC to be 2120 released. 2122 Figure 39. Ethernet transport service and supporting ODUk TE tunnel 2123 are provisioned 2125 4) Transport service teardown coordination 2127 First, HC issues to DC1 and DC2 a configuration request to release 2128 the Ethernet layer transport service in the respective domains. After 2129 that, all three DCs are requested to release the segments of the 2130 supporting ODUk layer hierarchy TE tunnel. While processing the 2131 request DC1 and DC2 also remove the dynamic Ethernet layer TE links 2132 supported by the respective hierarchy TE tunnel's segments, thus the 2133 network's abstract TE topologies are reverted back to the state as 2134 shown in Figures 35 and 36. 2136 2.4. Use Case 4. Transport service control on a ODUk/Och multi-domain 2137 transport network with multi-function access links 2139 Configuration (Figure 40): the same as in use case 3, except that all 2140 access links in this use case are multi-function links (depicted in 2141 the Figure as blue compound lines). Let's assume that, depending on 2142 configuration, the multi-function access links in this use case can 2143 carry either Ethernet or SDH/STM16 layer payload. 2145 Objective: Set up//delete an unprotected shortest delay SDH/STM16 2146 layer transport service interconnecting C-R2 and C-R5 2148 Figure 40. Three-domain ODUk/Och transport network with multi- 2149 function access links 2151 1) TE Topology discovery 2153 The TE Topology model considers multi-function links as parallel 2154 mutually exclusive TE links each belonging to a separate layer 2155 network. For this use case each DC exposes to HC three (ODUk-, 2156 Ethernet- and SDH/STM16-layer) abstract TE topologies (generally 2157 speaking, one abstract TE topology per each layer network supported 2158 by at least one access or inter-domain link). Like in use case 3, 2159 the lower layer (ODUk) TE nodes announce hosted by them TE tunnel 2160 termination points, TTPs, capable in this case of adopting Ethernet, 2161 SDH/STM16 or both layer payloads, The TTPs are attributed with TE 2162 inter-layer locks matching ones specified for Ethernet and/or 2163 SDH/STM16 TE links. 2165 Ethernet, SDH/STM16 and ODUk layer single-node abstract TE topologies 2166 catered to HC by each of the DCs are presented in Figure 41. 2168 HC merges the provided topologies into its own native TE Topology 2169 (the merging procedures are described in 1.4). As in use case 3 HC 2170 locks the provided TE topologies not only horizontally (i.e. between 2171 domains), but vertically (between layers) as well, thus producing a 2172 three-layer TE topology homogenously describing the three layers of 2173 the entire transport network, as well as the client-server layer 2174 adaptation relationships between the layers. This makes the merged TE 2175 topology suitable for multi-layer/inter-layer multi-domain transport 2176 service path computations. The merged TE topology is presented in 2177 Figure 42. 2179 Figure 41. ODUk, Ethernet and SDH/STM16 layer abstract TE topologies 2180 exposed by DCs 2182 Figure 42. Three-layer three-domain transport network abstract TE 2183 topology 2185 2) Transport service path computation 2187 Using the merged TE topology (Figure 42) HC's path computer selects a 2188 TE path for the requested transport service. For example, for the 2189 SDH/STM16 layer unprotected transport service the resulting TE path 2190 could be determined as marked in Figure 43. 2192 Figure 43. Multi-layer TE path computed for SDH/STM16 layer transport 2193 service 2195 3) Transport service setup coordination 2197 Same as in use case 3. 2199 4) Transport service teardown coordination 2201 Same as in use case 3. 2203 2.5. Use Case 5. Real time updates of IP/MPLS layer TE link attributes 2204 that depend on supporting transport connectivity (e.g. transport 2205 SRLGs, propagation delay, etc.) 2207 Configuration (Figure 26): the same as in use case 1, 2209 Objective: A transport service interconnecting transport ports of two 2210 IP routers across a transport network is likely to serve a link in 2211 IP/MPLS layer network, which is usually controlled by a client of the 2212 transport network, such as IP/MPLS Controller. Performance of TE 2213 applications (e.g. path computer) running on the IP/MPLS Controller 2214 depends on the accuracy of IP/MPLS layer TE link attributes. Some of 2215 these attributes can change over time and are known real-time only to 2216 a transport network controller, such as HC. Examples of said 2217 attributes are transport SRLGs, propagation delay metric, protection 2218 capacities and status, etc. The objective of this use case is to 2219 ensure up-to-date state of said attributes in the IP/MPLS 2220 Controller's internal TED via necessary updates provided in a timely 2221 manner by the controller (e.g. HC) managing transport connectivity 2222 supporting IP/MPLS layer links. 2224 Realization: 2226 o HC exposes and supports IETF TE Topology and TE Tunnel model based 2227 NBIs (the same NBIs that are exposed by DCs serving HC); 2229 o IP/MPLS Controller makes use of the exposed NBIs to set up the 2230 respective client-provider relationships with HC; 2232 o IP/MPLS Controller uses the TE Tunnel NBI to configure with HC a 2233 transport service interconnecting transport ports of a pair of IP 2234 routers desired to be adjacent in the IP/MPLS layer network. The 2235 TE Tunnel model allows for specifying in the transport service 2236 configuration request the TE topology and link IDs of the IP/MPLS 2237 TE link the requested transport service will be serving; 2239 o IP/MPLS Controller uses the TE Topology NBI to subscribe with HC 2240 on the IP/MPLS TE link notifications with respect to changes in 2241 the TE link's attributes, such as SRLGs, propagation delay, 2242 protection capabilities/status, etc.; 2244 o HC uses the TE Topology NBI to convey the requested notifications 2245 when HC learns the attributes IP/MPLS has expressed interest in or 2246 detects any changes since previous notifications (for example, due 2247 to network failure restoration/reversion procedures happened to 2248 the transport connectivity that supports the failure affected 2249 IP/MPLS links) 2251 2.6. Use Case 6. Virtual Network Service 2253 Configuration (Figure 26): the same as in use case 1, 2255 Objective: Set up two Virtual Networks for the client, with Virtual 2256 Network 1 interconnecting customer IP routers C-R1, C-R7 and C-R4 2257 over a single-node abstract TE topology, and Virtual Network 2 2258 interconnecting customer IP routers C-R2, C-R3, C-R8, C-R5 and C-R6 2259 over a full mesh link abstract TE topology as depicted in Figure 44. 2261 [Note: A client of a transport network may want to limit the 2262 transport network connectivity of a particular type and quality 2263 within distinct subsets of its network elements interconnected across 2264 the transport network. Furthermore, a given transport network may 2265 serve more than one client. In this case some or all clients may want 2266 to ensure the availability of transport network resources in case 2267 dynamic (re-)connecting of their network elements across the 2268 transport network is envisioned. In all such cases a client may want 2269 to set up one or more Virtual Networks over provided transport 2270 network] 2272 1) Virtual Network setup 2274 From the client's point of view a Virtual Network setup includes the 2275 following procedures: 2277 o Identifying the Virtual Network membership - a subset of the 2278 client's network elements/ports to be interconnected over the 2279 abstract TE topology configured for the Virtual Network. Note that 2280 from the transport network provider's point of view this 2281 effectively determines the list of abstract TE topology's open- 2282 ended access TE links; 2284 o Deciding on the Virtual Network's abstract TE topology type (e.g. 2285 single-node vs. link mesh), optimization criterion (e.g. shortest 2286 delay vs. smallest cost), bandwidth, link disjointedness, 2287 adaptation capabilities and other requirements/constraints, as 2288 well as, whether the TE tunnels supporting the abstract TE 2289 topology need to be pre-established or established on demand (i.e. 2290 when respective abstract TE topology elements are selected for a 2291 client transport service); 2293 o Using the IETF TE Topology model based NBI exposed by the 2294 transport network controller (i.e. HC), configure the Virtual 2295 Network's abstract TE topology. Let's assume that in this use case 2296 the abstract TE topology for Virtual Network 1 is configured as a 2297 single-node abstract TE topology (see section 1.3.1) with the 2298 abstract TE node's detailed connectivity matrix optimized 2299 according to the shortest delay criteria. Likewise, the abstract 2300 TE topology for Virtual Network 2 is configured as a full-mesh 2301 link abstract TE topology (see section 1.3.2) optimized according 2302 to the smallest cost criteria with each of the abstract TE links 2303 to be supported by pre-established end-to-end protected TE 2304 tunnels. 2306 [Note: Virtual Network's abstract TE topology (re- 2307 )configuration/negotiation process is no different from one that 2308 happens, for example, between HC and its providers, DCs, and is 2309 described in section 1.5] 2311 Figure 44. Virtual Networks provided for a transport network client 2313 2) Using Virtual Network 2315 Recall that use case 1 was about setting up a transport service 2316 interconnecting customer network elements C-R2 and C-R5 across the 2317 transport network. With the Virtual Network 2 in place, the client 2318 could have used the Virtual Network's TE topology to select a TE path 2319 for the service. The TE Tunnel model based NBI allows for the client 2320 to specify the Virtual Network's TE topology ID, as well, as the 2321 selected TE path (for example, as marked in Figure 45) as a 2322 configured path attribute in the transport service configuration 2323 request to ensure that the intended transport network resources are 2324 used for the service. 2326 Figure 45. Transport service TE path is selected on Virtual Network's 2327 TE topology 2329 3. Security Considerations 2331 This document does not define networking protocols and data, hence 2332 are not directly responsible for security risks. 2334 4. IANA Considerations 2336 This document has no actions for IANA. 2338 5. References 2340 5.1. Normative References 2342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2343 Requirement Levels", BCP 14, RFC 2119, March 1997. 2345 [I-D.ietf-teas-yang-te-topo] 2346 Liu, X., Bryskin, I., Beeram, V., Saad, T., Shah, H., and 2347 O. Dios, "YANG Data Model for TE Topologies", draft-ietf- 2348 teas-yang-te-topo-08 (work in progress), March 2017. 2350 [I-D.ietf-teas-yang-te] 2352 Saad, T., Gandhi, R., Liu, X., Beeram, V., Shah, H., and I. 2353 Bryskin, "A YANG Data Model for Traffic Engineering Tunnels 2354 and Interfaces", draft-ietf-teas-yang-te-06 (work in 2355 progress), March 2017. 2357 5.2. Informative References 2359 [RFC2702] Awduche, D., "Requirements for Traffic Engineering Over 2360 MPLS", RFC 2702, September 1999. 2362 6. Acknowledgments 2364 TBD. 2366 Appendix A. Data Examples 2368 This section contains examples of an instance data in the JSON 2369 encoding [RFC7951]. 2371 A.1. Use Case 1 2373 In the use case described in Section 2.1. , there are three provider 2374 network domains, each of them is represented as an abstract TE 2375 topology. The JSON encoded example data configurations for the three 2376 domains are: 2378 A.1.1. Domain 1 2380 { 2381 "networks": { 2382 "network": [ 2383 { 2384 "network-types": { 2385 "te-topology": {} 2386 }, 2387 "network-id": "otn-domain1-abs", 2388 "provider-id": 201, 2389 "client-id": 300, 2390 "te-topology-id": "te-topology:otn-domain1-abs", 2391 "node": [ 2392 { 2393 "node-id": "D1", 2394 "te-node-id": "2.0.1.1", 2395 "te": { 2396 "config": { 2397 "te-node-attributes": { 2398 "domain-id" : 1, 2399 "is-abstract": [null], 2400 "underlay-topology": "domain1-och", 2401 "connectivity-matrices": { 2402 "is-allowed": true, 2403 "max-link-bandwidth": "1,2", 2404 "te-default-metric": 10, 2405 "connectivity-matrix": [ 2406 { 2407 "id": 10302, 2408 "from": "1-0-3", 2409 "to": "1-2-0" 2410 }, 2411 { 2412 "id": 10203, 2413 "from": "1-0-2", 2414 "to": "1-3-0" 2415 }, 2416 { 2417 "id": 10311, 2418 "from": "1-0-3", 2419 "to": "1-11-0" 2420 }, 2421 { 2422 "id": 11103, 2423 "from": "1-0-11", 2424 "to": "1-3-0" 2425 }, 2426 { 2427 "id": 10903, 2428 "from": "1-0-9", 2429 "to": "1-3-0" 2430 }, 2431 { 2432 "id": 10309, 2433 "from": "1-0-3", 2434 "to": "1-9-0" 2435 }, 2436 { 2437 "id": 10910, 2438 "from": "1-0-9", 2439 "to": "1-10-0" 2440 }, 2441 { 2442 "id": 11009, 2443 "from": "1-0-10", 2444 "to": "1-9-0" 2445 }, 2446 { 2447 "id": 20910, 2448 "from": "1-1-9", 2449 "to": "1-10-0" 2451 }, 2452 { 2453 "id": 21009, 2454 "from": "1-0-10", 2455 "to": "1-9-1" 2456 }, 2457 { 2458 "id": 20911, 2459 "from": "1-1-9", 2460 "to": "1-11-0" 2461 }, 2462 { 2463 "id": 21109, 2464 "from": "1-0-11", 2465 "to": "1-9-1" 2466 } 2467 ] 2468 } 2469 } 2470 } 2471 }, 2472 "termination-point": [ 2473 { 2474 "tp-id": "1-0-3", 2475 "te-tp-id": 10003 2476 "te": { 2477 "config": { 2478 "interface-switching-capability": [ 2479 { 2480 "switching-capability": "switching-otn", 2481 "encoding": "lsp-encoding-oduk" 2482 } 2483 ], 2484 } 2485 } 2486 }, 2487 { 2488 "tp-id": "1-3-0", 2489 "te-tp-id": 10300 2490 "te": { 2491 "config": { 2492 "interface-switching-capability": [ 2493 { 2494 "switching-capability": "switching-otn", 2495 "encoding": "lsp-encoding-oduk" 2496 } 2497 ], 2498 } 2499 } 2500 }, 2501 { 2502 "tp-id": "1-0-9", 2503 "te-tp-id": 10009 2504 "te": { 2505 "config": { 2506 "interface-switching-capability": [ 2507 { 2508 "switching-capability": "switching-otn", 2509 "encoding": "lsp-encoding-oduk" 2510 } 2511 ], 2512 } 2513 } 2514 }, 2515 { 2516 "tp-id": "1-9-0", 2517 "te-tp-id": 10900 2518 "te": { 2519 "config": { 2520 "interface-switching-capability": [ 2521 { 2522 "switching-capability": "switching-otn", 2523 "encoding": "lsp-encoding-oduk" 2524 } 2525 ], 2526 } 2527 } 2528 }, 2529 { 2530 "tp-id": "1-1-9", 2531 "te-tp-id": 10109 2532 "te": { 2533 "config": { 2534 "interface-switching-capability": [ 2535 { 2536 "switching-capability": "switching-otn", 2537 "encoding": "lsp-encoding-oduk" 2538 } 2539 ], 2540 } 2541 } 2542 }, 2543 { 2544 "tp-id": "1-9-1", 2545 "te-tp-id": 10901 2546 "te": { 2547 "config": { 2548 "interface-switching-capability": [ 2549 { 2550 "switching-capability": "switching-otn", 2551 "encoding": "lsp-encoding-oduk" 2552 } 2553 ], 2554 } 2555 } 2556 }, 2557 { 2558 "tp-id": "1-0-2", 2559 "te-tp-id": 10002 2560 "te": { 2561 "config": { 2562 "interface-switching-capability": [ 2563 { 2564 "switching-capability": "switching-otn", 2565 "encoding": "lsp-encoding-oduk" 2566 } 2567 ], 2568 } 2569 } 2570 }, 2571 { 2572 "tp-id": "1-2-0", 2573 "te-tp-id": 10200 2574 "te": { 2575 "config": { 2576 "interface-switching-capability": [ 2577 { 2578 "switching-capability": "switching-otn", 2579 "encoding": "lsp-encoding-oduk" 2580 } 2581 ], 2582 } 2583 } 2584 }, 2585 { 2586 "tp-id": "1-0-10", 2587 "te-tp-id": 10010 2588 "te": { 2589 "config": { 2590 "interface-switching-capability": [ 2591 { 2592 "switching-capability": "switching-otn", 2593 "encoding": "lsp-encoding-oduk" 2594 } 2595 ], 2596 } 2597 } 2598 }, 2599 { 2600 "tp-id": "1-10-0", 2601 "te-tp-id": 11000 2602 "te": { 2603 "config": { 2604 "interface-switching-capability": [ 2605 { 2606 "switching-capability": "switching-otn", 2607 "encoding": "lsp-encoding-oduk" 2608 } 2609 ], 2610 } 2611 } 2612 }, 2613 { 2614 "tp-id": "1-0-11", 2615 "te-tp-id": 10011 2616 "te": { 2617 "config": { 2618 "interface-switching-capability": [ 2619 { 2620 "switching-capability": "switching-otn", 2621 "encoding": "lsp-encoding-oduk" 2622 } 2623 ], 2624 } 2625 } 2626 }, 2627 { 2628 "tp-id": "1-11-0", 2629 "te-tp-id": 11100 2630 "te": { 2631 "config": { 2632 "interface-switching-capability": [ 2633 { 2634 "switching-capability": "switching-otn", 2635 "encoding": "lsp-encoding-oduk" 2636 } 2637 ], 2638 } 2639 } 2640 }, 2641 { 2642 "tp-id": "1-1-11", 2643 "te-tp-id": 10111 2644 "te": { 2645 "config": { 2646 "interface-switching-capability": [ 2647 { 2648 "switching-capability": "switching-otn", 2649 "encoding": "lsp-encoding-oduk" 2650 } 2651 ], 2652 } 2653 } 2654 }, 2655 { 2656 "tp-id": "1-11-1", 2657 "te-tp-id": 11101 2658 "te": { 2659 "config": { 2660 "interface-switching-capability": [ 2661 { 2662 "switching-capability": "switching-otn", 2663 "encoding": "lsp-encoding-oduk" 2664 } 2665 ], 2666 } 2667 } 2668 } 2669 ] 2670 } 2671 ] 2672 } 2673 ] 2674 } 2675 } 2677 A.1.2. Domain 2 2679 { 2680 "networks": { 2681 "network": [ 2682 { 2683 "network-types": { 2684 "te-topology": {} 2685 }, 2686 "network-id": "otn-domain2-abs", 2687 "provider-id": 202, 2688 "client-id": 300, 2689 "te-topology-id": "te-topology:otn-domain2-abs", 2690 "node": [ 2691 { 2692 "node-id": "D2", 2693 "te-node-id": "2.0.2.2", 2694 "te": { 2695 "config": { 2696 "te-node-attributes": { 2697 "is-abstract": [null], 2698 "underlay-topology": "domain2-och", 2699 "connectivity-matrices": { 2700 "is-allowed": true, 2701 "max-link-bandwidth": "1,2", 2702 "te-default-metric": 10, 2703 "connectivity-matrix": [ 2704 { 2705 "id": 12125, 2706 "from": "1-0-21", 2707 "to": "1-25-0" 2708 }, 2709 { 2710 "id": 12521, 2711 "from": "1-0-25", 2712 "to": "1-21-0" 2713 }, 2714 { 2715 "id": 12128, 2716 "from": "1-0-21", 2717 "to": "1-28-0" 2718 }, 2719 { 2720 "id": 12821, 2721 "from": "1-0-28", 2722 "to": "1-21-0" 2723 }, 2724 { 2725 "id": 12231, 2726 "from": "1-0-22", 2727 "to": "1-31-0" 2728 }, 2729 { 2730 "id": 13122, 2731 "from": "1-0-31", 2732 "to": "1-22-0" 2733 }, 2734 { 2735 "id": 22228, 2736 "from": "1-1-22", 2737 "to": "1-28-0" 2739 }, 2740 { 2741 "id": 22822, 2742 "from": "1-0-28", 2743 "to": "1-22-1" 2744 }, 2745 { 2746 "id": 12528, 2747 "from": "1-0-25", 2748 "to": "1-28-0" 2749 }, 2750 { 2751 "id": 12825, 2752 "from": "1-0-28", 2753 "to": "1-25-0" 2754 } 2755 ] 2756 } 2757 } 2758 } 2759 }, 2760 "termination-point": [ 2761 { 2762 "tp-id": "1-0-21", 2763 "te-tp-id": 10021 2764 "te": { 2765 "config": { 2766 "interface-switching-capability": [ 2767 { 2768 "switching-capability": "switching-otn", 2769 "encoding": "lsp-encoding-oduk" 2770 } 2771 ], 2772 } 2773 } 2774 }, 2775 { 2776 "tp-id": "1-21-0", 2777 "te-tp-id": 12100 2778 "te": { 2779 "config": { 2780 "interface-switching-capability": [ 2781 { 2782 "switching-capability": "switching-otn", 2783 "encoding": "lsp-encoding-oduk" 2784 } 2785 ], 2786 } 2787 } 2788 }, 2789 { 2790 "tp-id": "1-0-22", 2791 "te-tp-id": 10022 2792 "te": { 2793 "config": { 2794 "interface-switching-capability": [ 2795 { 2796 "switching-capability": "switching-otn", 2797 "encoding": "lsp-encoding-oduk" 2798 } 2799 ], 2800 } 2801 } 2802 }, 2803 { 2804 "tp-id": "1-22-0", 2805 "te-tp-id": 12200 2806 "te": { 2807 "config": { 2808 "interface-switching-capability": [ 2809 { 2810 "switching-capability": "switching-otn", 2811 "encoding": "lsp-encoding-oduk" 2812 } 2813 ], 2814 } 2815 } 2816 }, 2817 { 2818 "tp-id": "1-1-22", 2819 "te-tp-id": 10122 2820 "te": { 2821 "config": { 2822 "interface-switching-capability": [ 2823 { 2824 "switching-capability": "switching-otn", 2825 "encoding": "lsp-encoding-oduk" 2826 } 2827 ], 2828 } 2829 } 2830 }, 2831 { 2832 "tp-id": "1-22-1", 2833 "te-tp-id": 12201 2834 "te": { 2835 "config": { 2836 "interface-switching-capability": [ 2837 { 2838 "switching-capability": "switching-otn", 2839 "encoding": "lsp-encoding-oduk" 2840 } 2841 ], 2842 } 2843 } 2844 }, 2845 { 2846 "tp-id": "1-0-25", 2847 "te-tp-id": 10025 2848 "te": { 2849 "config": { 2850 "interface-switching-capability": [ 2851 { 2852 "switching-capability": "switching-otn", 2853 "encoding": "lsp-encoding-oduk" 2854 } 2855 ], 2856 } 2857 } 2858 }, 2859 { 2860 "tp-id": "1-25-0", 2861 "te-tp-id": 12500 2862 "te": { 2863 "config": { 2864 "interface-switching-capability": [ 2865 { 2866 "switching-capability": "switching-otn", 2867 "encoding": "lsp-encoding-oduk" 2868 } 2869 ], 2870 } 2871 } 2872 }, 2873 { 2874 "tp-id": "1-1-25", 2875 "te-tp-id": 10125 2876 "te": { 2877 "config": { 2878 "interface-switching-capability": [ 2879 { 2880 "switching-capability": "switching-otn", 2881 "encoding": "lsp-encoding-oduk" 2882 } 2883 ], 2884 } 2885 } 2886 }, 2887 { 2888 "tp-id": "1-25-1", 2889 "te-tp-id": 12501 2890 "te": { 2891 "config": { 2892 "interface-switching-capability": [ 2893 { 2894 "switching-capability": "switching-otn", 2895 "encoding": "lsp-encoding-oduk" 2896 } 2897 ], 2898 } 2899 } 2900 }, 2901 { 2902 "tp-id": "1-0-28", 2903 "te-tp-id": 10028 2904 "te": { 2905 "config": { 2906 "interface-switching-capability": [ 2907 { 2908 "switching-capability": "switching-otn", 2909 "encoding": "lsp-encoding-oduk" 2910 } 2911 ], 2912 } 2913 } 2914 }, 2915 { 2916 "tp-id": "1-28-0", 2917 "te-tp-id": 12800 2918 "te": { 2919 "config": { 2920 "interface-switching-capability": [ 2921 { 2922 "switching-capability": "switching-otn", 2923 "encoding": "lsp-encoding-oduk" 2924 } 2925 ], 2926 } 2927 } 2928 }, 2929 { 2930 "tp-id": "1-0-31", 2931 "te-tp-id": 10031 2932 "te": { 2933 "config": { 2934 "interface-switching-capability": [ 2935 { 2936 "switching-capability": "switching-otn", 2937 "encoding": "lsp-encoding-oduk" 2938 } 2939 ], 2940 } 2941 } 2942 }, 2943 { 2944 "tp-id": "1-31-0", 2945 "te-tp-id": 13100 2946 "te": { 2947 "config": { 2948 "interface-switching-capability": [ 2949 { 2950 "switching-capability": "switching-otn", 2951 "encoding": "lsp-encoding-oduk" 2952 } 2953 ], 2954 } 2955 } 2956 } 2957 ] 2958 } 2959 ] 2960 } 2961 ] 2962 } 2963 } 2965 A.1.3. Domain 3 2967 { 2968 "networks": { 2969 "network": [ 2970 { 2971 "network-types": { 2972 "te-topology": {} 2973 }, 2974 "network-id": "otn-domain3-abs", 2975 "provider-id": 203, 2976 "client-id": 300, 2977 "te-topology-id": "te-topology:otn-domain3-abs", 2978 "node": [ 2979 { 2980 "node-id": "D3", 2981 "te-node-id": "2.0.3.3", 2982 "te": { 2983 "config": { 2984 "te-node-attributes": { 2985 "is-abstract": [null], 2986 "underlay-topology": "domain3-och", 2987 "connectivity-matrices": { 2988 "is-allowed": true, 2989 "max-link-bandwidth": "1,2", 2990 "te-default-metric": 10, 2991 "connectivity-matrix": [ 2992 { 2993 "id": 13638, 2994 "from": "1-0-38", 2995 "to": "1-38-0" 2996 }, 2997 { 2998 "id": 13836, 2999 "from": "1-0-38", 3000 "to": "1-36-0" 3001 }, 3002 { 3003 "id": 13639, 3004 "from": "1-0-36", 3005 "to": "1-39-0" 3006 }, 3007 { 3008 "id": 13936, 3009 "from": "1-0-39", 3010 "to": "1-36-0" 3011 }, 3012 { 3013 "id": 23636, 3014 "from": "1-0-36", 3015 "to": "1-36-1" 3016 }, 3017 { 3018 "id": 33636, 3019 "from": "1-1-36", 3020 "to": "1-36-0" 3021 }, 3022 { 3023 "id": 13739, 3024 "from": "1-0-37", 3025 "to": "1-39-0" 3027 }, 3028 { 3029 "id": 13937, 3030 "from": "1-0-39", 3031 "to": "1-37-0" 3032 }, 3033 { 3034 "id": 23737, 3035 "from": "1-0-37", 3036 "to": "1-37-1" 3037 }, 3038 { 3039 "id": 33737, 3040 "from": "1-1-37", 3041 "to": "1-37-0" 3042 } 3043 ] 3044 } 3045 } 3046 } 3047 }, 3048 "termination-point": [ 3049 { 3050 "tp-id": "1-0-36", 3051 "te-tp-id": 10036 3052 "te": { 3053 "config": { 3054 "interface-switching-capability": [ 3055 { 3056 "switching-capability": "switching-otn", 3057 "encoding": "lsp-encoding-oduk" 3058 } 3059 ], 3060 } 3061 } 3062 }, 3063 { 3064 "tp-id": "1-36-0", 3065 "te-tp-id": 13600 3066 "te": { 3067 "config": { 3068 "interface-switching-capability": [ 3069 { 3070 "switching-capability": "switching-otn", 3071 "encoding": "lsp-encoding-oduk" 3072 } 3073 ], 3074 } 3075 } 3076 }, 3077 { 3078 "tp-id": "1-0-37", 3079 "te-tp-id": 10037 3080 "te": { 3081 "config": { 3082 "interface-switching-capability": [ 3083 { 3084 "switching-capability": "switching-otn", 3085 "encoding": "lsp-encoding-oduk" 3086 } 3087 ], 3088 } 3089 } 3090 }, 3091 { 3092 "tp-id": "1-37-0", 3093 "te-tp-id": 13700 3094 "te": { 3095 "config": { 3096 "interface-switching-capability": [ 3097 { 3098 "switching-capability": "switching-otn", 3099 "encoding": "lsp-encoding-oduk" 3100 } 3101 ], 3102 } 3103 } 3104 }, 3105 { 3106 "tp-id": "1-1-37", 3107 "te-tp-id": 10137 3108 "te": { 3109 "config": { 3110 "interface-switching-capability": [ 3111 { 3112 "switching-capability": "switching-otn", 3113 "encoding": "lsp-encoding-oduk" 3114 } 3115 ], 3116 } 3117 } 3118 }, 3119 { 3120 "tp-id": "1-37-1", 3121 "te-tp-id": 13701 3122 "te": { 3123 "config": { 3124 "interface-switching-capability": [ 3125 { 3126 "switching-capability": "switching-otn", 3127 "encoding": "lsp-encoding-oduk" 3128 } 3129 ], 3130 } 3131 } 3132 }, 3133 { 3134 "tp-id": "1-0-39", 3135 "te-tp-id": 10039 3136 "te": { 3137 "config": { 3138 "interface-switching-capability": [ 3139 { 3140 "switching-capability": "switching-otn", 3141 "encoding": "lsp-encoding-oduk" 3142 } 3143 ], 3144 } 3145 } 3146 }, 3147 { 3148 "tp-id": "1-39-0", 3149 "te-tp-id": 13900 3150 "te": { 3151 "config": { 3152 "interface-switching-capability": [ 3153 { 3154 "switching-capability": "switching-otn", 3155 "encoding": "lsp-encoding-oduk" 3156 } 3157 ], 3158 } 3159 } 3160 }, 3161 { 3162 "tp-id": "1-0-36", 3163 "te-tp-id": 10036 3164 "te": { 3165 "config": { 3166 "interface-switching-capability": [ 3167 { 3168 "switching-capability": "switching-otn", 3169 "encoding": "lsp-encoding-oduk" 3170 } 3171 ], 3172 } 3173 } 3174 }, 3175 { 3176 "tp-id": "1-36-0", 3177 "te-tp-id": 13600 3178 "te": { 3179 "config": { 3180 "interface-switching-capability": [ 3181 { 3182 "switching-capability": "switching-otn", 3183 "encoding": "lsp-encoding-oduk" 3184 } 3185 ], 3186 } 3187 } 3188 }, 3189 { 3190 "tp-id": "1-0-38", 3191 "te-tp-id": 10038 3192 "te": { 3193 "config": { 3194 "interface-switching-capability": [ 3195 { 3196 "switching-capability": "switching-otn", 3197 "encoding": "lsp-encoding-oduk" 3198 } 3199 ], 3200 } 3201 } 3202 }, 3203 { 3204 "tp-id": "1-38-0", 3205 "te-tp-id": 13800 3206 "te": { 3207 "config": { 3208 "interface-switching-capability": [ 3209 { 3210 "switching-capability": "switching-otn", 3211 "encoding": "lsp-encoding-oduk" 3212 } 3213 ], 3214 } 3215 } 3216 } 3217 ] 3218 } 3219 ] 3220 } 3221 ] 3222 } 3223 } 3225 Authors' Addresses 3227 Igor Bryskin 3228 Huawei Technologies 3229 Email: Igor.Bryskin@huawei.com 3231 Vishnu Pavan Beeram 3232 Juniper Networks 3233 Email: vbeeram@juniper.net 3235 Tarek Saad 3236 Cisco Systems Inc 3237 Email: tsaad@cisco.com 3239 Xufeng Liu 3240 Jabil 3241 Email: Xufeng_Liu@jabil.com