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