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