idnits 2.17.1 draft-ietf-ccamp-transport-nbi-app-statement-07.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 : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 31, 2019) is 1632 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group I. Busi 2 Internet Draft Huawei 3 Intended status: Informational D. King 4 Old Dog Consulting 5 H. Zheng 6 Huawei 7 Y. Xu 8 CAICT 10 Expires: April 2020 October 31, 2019 12 Transport Northbound Interface Applicability Statement 13 draft-ietf-ccamp-transport-nbi-app-statement-07 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 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference 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 31, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 This document provides an analysis of the applicability of the YANG 56 models defined by the IETF (Traffic Engineering Architecture and 57 Signaling (TEAS) moreover, Common Control and Measurement Plane 58 (CCAMP) WGs in particular) to support ODU transit services, 59 Transparent client services and EPL/EVPL Ethernet services over OTN 60 single and multi-domain network scenarios. 62 This document also describes how existing YANG models can be used 63 through a number of worked examples and JSON fragments. 65 Table of Contents 67 1. Introduction...................................................4 68 1.1. The Scope of this Document................................4 69 2. Terminology....................................................5 70 3. Conventions Used in this Document..............................8 71 3.1. Topology and Traffic Flow Processing......................8 72 3.2. JSON code.................................................9 73 4. Scenarios Description.........................................10 74 4.1. Reference Network........................................10 75 4.2. Topology Abstractions....................................15 76 4.3. Service Configuration....................................16 77 4.3.1. ODU Transit.........................................17 78 4.3.2. EPL over ODU........................................18 79 4.3.3. Transparent Client Services.........................19 80 4.3.4. EVPL over ODU.......................................20 81 4.4. Multi-function Access Links..............................21 82 4.5. Protection and Restoration Configuration.................22 83 4.5.1. Linear Protection (end-to-end)......................23 84 4.5.2. Segmented Protection................................24 85 4.6. Notification.............................................25 86 4.7. Path Computation with Constraints........................25 87 5. YANG Model Analysis...........................................26 88 5.1. YANG Models for Topology Abstraction.....................26 89 5.1.1. Domain 1 Black Topology Abstraction.................28 90 5.1.2. Domain 2 Black Topology Abstraction.................32 91 5.1.3. Domain 3 White Topology Abstraction.................33 92 5.1.4. Multi-domain Topology Merging.......................34 93 5.2. YANG Models for Service Configuration....................36 94 5.2.1. ODU Transit Service.................................40 95 5.2.1.1. Single Domain Example..........................42 96 5.2.2. EPL over ODU Service................................42 97 5.2.2.1. Single Domain Example..........................45 98 5.2.3. Other OTN Client Services...........................45 99 5.2.3.1. Single Domain Example..........................46 100 5.2.4. EVPL over ODU Service...............................47 101 5.3. YANG Models for Protection Configuration.................48 102 5.3.1. Linear Protection (end-to-end)......................48 103 5.3.2. Segmented Protection................................50 104 5.4. Notifications............................................51 105 5.5. Path Computation with Constraints........................52 106 6. Security Considerations.......................................52 107 6.1. OTN Security.............................................52 108 7. IANA Considerations...........................................53 109 8. References....................................................53 110 8.1. Normative References.....................................53 111 8.2. Informative References...................................54 112 9. Acknowledgments...............................................55 113 Appendix A. Validating a JSON fragment against a YANG Model...57 114 A.1. Manipulation of JSON fragments..........................57 115 A.2. Comments in JSON fragments..............................58 116 A.3. Validation of JSON fragments: DSDL-based approach.......58 117 A.4. Validation of JSON fragments: why not using an XSD-based 118 approach......................................................59 119 Appendix B. Detailed JSON Examples............................60 120 B.1. JSON Examples for Topology Abstractions.................61 121 B.1.1. JSON Code: mpi1-otn-topology.json.................61 122 B.1.2. JSON Code: mpi1-eth-topology.json.................85 123 B.2. JSON Examples for Service Configuration.................90 124 B.2.1. JSON Code: mpi1-odu2-service-config.json..........90 125 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json...........93 126 B.2.3. JSON Code: mpi1-epl-service-config.json...........96 128 1. Introduction 130 Transport network domains, including Optical Transport Network (OTN) 131 and Wavelength Division Multiplexing (WDM) networks, are typically 132 deployed based on a single vendor or technology platforms. They are 133 often managed using proprietary interfaces to dedicated Element 134 Management Systems (EMS), Network Management Systems (NMS) and 135 increasingly Software Defined Network (SDN) controllers. 137 Support of packet connectivity services over transport network 138 domains are critical for a wide range of applications and services, 139 including data center and LAN interconnects, Internet service 140 backhauling, mobile backhaul and enterprise Carrier Ethernet 141 services. A clear goal of operators is to automate the setup of 142 these connectivity services across multiple transport network 143 domains, that may utilize different technologies. 145 A well-defined common open interface to each domain controller or a 146 management system is required for network operators to control 147 multi-vendor and multi-domain networks and also enable coordination 148 and automation of service provisioning. This is facilitated by using 149 standardized data models (e.g., YANG models), and an appropriate 150 protocol (e.g., RESTCONF [RFC8040]). 152 This document examines the applicability of the YANG models being 153 defined by IETF (Traffic Engineering Architecture and Signaling 154 (TEAS) moreover, Common Control and Measurement Plane (CCAMP) WGs in 155 particular) to support Optical Transport Networks (OTN) single and 156 multi-domain scenarios. 158 1.1. The Scope of this Document 160 This document assumes a reference architecture, including 161 interfaces, based on the Abstraction and Control of Traffic- 162 Engineered Networks (ACTN), defined in [RFC8453]. 164 The focus of this document is on the interface between the Multi 165 Domain Service Coordinator (MDSC) and a Provisioning Network 166 Controller (PNC), controlling a transport network domain, called 167 MDSC-PNC Interface (MPI) in [RFC8453]. 169 It is worth noting that the same MPI analyzed in this document could 170 be used between hierarchical MDSC controllers, as shown in Figure 4 171 of [RFC8453]. 173 Detailed analysis of the interface between the Customer Network 174 Controller (CNC) and the MDSC, called CNC-MDSC Interface (CMI) in 175 [RFC8453], as well as of the interface between service and network 176 orchestrators are outside the scope of this document. However, when 177 needed, this document describes some considerations and assumptions 178 about the information which needs to be provided at these 179 interfaces. 181 The list of the IETF YANG models which are applicable to the ACTN 182 MPI can be found in [ACTN-YANG]. 184 The Functional Requirements for the transport API as described in 185 the Optical Networking Foundation (ONF) document [ONF TR-527] have 186 been taken as input for defining the reference scenarios analyzed in 187 this document. 189 The analysis provided in this document confirms that the IETF YANG 190 models defined in [RFC8345], [TE-TOPO], [OTN-TOPO], [CLIENT-TOPO], 191 [TE-TUNNEL], [PATH-COMPUTE], [OTN-TUNNEL] and [CLIENT-SIGNAL] can be 192 used together to control a multi-domain OTN network to support 193 different types of multi-domain services, such as ODU transit 194 services, Transparent client services and EPL/EVPL Ethernet 195 services, over a multi-domain OTN connection, satisfying also the 196 requirements in [ONF TR-527]. 198 2. Terminology 200 Domain: A domain, as defined in [RFC4655], is "any collection of 201 network elements within a common sphere of address management or 202 path computation responsibility". Specifically, within this 203 document, we mean a part of an operator's network that is under 204 common management (i.e., under shared operational management using 205 the same instances of a tool and the same policies). Network 206 elements will often be grouped into domains based on technologies, 207 vendor profiles, or geographic proximity. 209 CNC: Customer Network Controller 211 Connection: The data plane configuration of an LSP, within this 212 document it is typically an ODU LSP. An end-to-end connection/LSP 213 represents an entire connection/LSP between the connection/LSP node 214 end-points. A connection/LSP segment represents a portion of the 215 end-to-end connection/LSP. 217 Connectivity Service: A service, or connectivity service, in the 218 context of this document can be considered as some form of 219 connectivity service between customer sites across the network 220 operator's network [RFC8309]. 222 E-LINE: Ethernet Line 224 EPL: Ethernet Private Line 226 EVPL: Ethernet Virtual Private Line 228 ILL: Inter-Layer Lock 230 Link: A link, or a physical link, is used to reprent the adjacency 231 between two physical nodes. The term OTN link represents a link 232 between two OTN switching physical nodes. 234 LSP: Label Switched Path 236 LTP: Link Termination Point 238 MDSC: Multi-Domain Service Coordinator 240 Network Configuration: As described in [RFC8309] it describes the 241 instructions provided to a controller on how to configure parts of a 242 network. 244 ODU: Optical Channel Data Unit 246 OTU: Optical Channel Transport Unit 248 OTN: Optical Transport Network 250 PNC: Provisioning Network Controller 252 Protection Switching: Protection switching, as defined in [ITU-T 253 G.808.1] and [RFC4427], provides the capability to swith the traffic 254 in case of network failurs over pre-allocated networks resourse. 255 Typically linear protection methods would be used and configured to 256 operate as 1+1 unidirectional, 1+1 bidirectional or 1:n 257 bidirectional. This ensures fast and simple service survivability. 259 Protection Transport Entity/LSP: A protection transport entity/LSP, 260 as defined in [ITU-T G.808.1] and [RFC4427], represents the path 261 where the "normal" user traffic is transported during protection 262 switching events (e.g., when the working transport entity/LSP 263 fails). 265 Restoration: Restoration methods, as defined in [RFC4427], provide 266 the capability to reroute and restore traffic around network 267 failures without the necessity to allocate network resources as 268 required for dedicated 1+1 protection schemes. On the other hand, 269 restoration times are typically longer than protection switching 270 times. 272 Service Model: As described in [RFC8309] it describes a service and 273 the parameters of the service in a portable way that can be used 274 uniformly and independent of the equipment and operating 275 environment. 277 TE Link: As defined in [TE-TOPO], it is an element of a TE topology, 278 presented as an edge on TE graph. 280 TE Tunnel: As defined in [TE-TUTORIAL], it is a connection-oriented 281 service provided by a layer network of delivery of a client's data 282 between source and destination tunnel termination points. 284 TE Tunnel Segment: As defined in [TE-TUTORIAL], it is a part of a 285 multi-domain TE tunnel that spans. 287 TE Tunnel Hand-off: As defined in [TE-TUTORIAL], it is an access 288 link or inter-domain link by which a multi-domain TE tunnel enters 289 or exits a given network domain. 291 Note - The three definitions above are currently in [TE-TUTORIAL] 292 but it is expected that they will be moved to [TE-TUNNEL]. When this 293 happens, the reference will be updated and the [TE-TUTORIAL] 294 reference will be downgraded to Informative. 296 TPN: Tributary Port Number 298 TTP: Tunnel Termination Point 299 Termination and Adaptation: It represents the termination of a 300 server-layer connection at the node edge-point and the 301 adaptation/mapping of the client layer traffic over the terminated 302 server-layer connection. 304 Transparent Client: As defined in [CLIENT-SIGNAL], it represents a 305 client-layer signal, such as Ethernet physical interfaces, FC, STM- 306 n, that cannot be switched but only mapped over a server-layer TE 307 Tunnel. 309 Working Transport Entity/LSP: A working transport entity/LSP, as 310 defined in [ITU-T G.808.1] and [RFC4427], represents the path where 311 the "normal" user traffic is transported. 313 UNI: User Network Interface 315 3. Conventions Used in this Document 317 3.1. Topology and Traffic Flow Processing 319 The traffic flow between different nodes is specified as an ordered 320 list of nodes, separated with commas, indicating within the brackets 321 the processing within each node: 323 []{, []} 325 The order represents the order of traffic flow being forwarded 326 through the network. 328 The represents the type of processing performed by the 329 node, which can be just switching at a given layer 330 "(switching-layer)" or it can also include an adaptation of a client 331 layer into a server layer: "(client-layer) -> server-layer" or 332 "client-layer -> (server-layer)", where the round brackets are used 333 to represent at which layer (client layer or server layer) the node 334 is switching. 336 For example, the following traffic flow: 338 R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)], 339 R3 [ODU2 -> (PKT)] 341 Node R1 is switching at the packet (PKT) layer and mapping packets 342 into an ODU2 before transmission to node S3. Nodes S3, S5 and S6, 343 are switching at the ODU2 layer: S3 sends the ODU2 traffic to S5, 344 which then sends it to S6 which finally sends to R3. Node R3 345 terminates the ODU2 from S6 before switching at the packet (PKT) 346 layer. 348 The paths of working and protection transport entities are specified 349 as an ordered list of nodes, separated with commas: 351 {, } 353 The order represents the order of traffic flow being forwarded 354 through the network in the forward direction. In the case of 355 bidirectional paths, the forward and backward directions are 356 selected arbitrarily, but the convention is consistent between 357 working/protection path pairs, as well as across multiple domains. 359 3.2. JSON code 361 This document provides some detailed JSON code examples to describe 362 how the YANG models being developed by the IETF (TEAS and CCAMP WG 363 in particular) may be used. The scenario examples are provided using 364 JSON to facilitate readability. 366 Different objects need to have an identifier. The convention used to 367 create mnemonic identifiers is to use the object name (e.g., S3 for 368 node S3), followed by its type (e.g., NODE), separated by an "-", 369 followed by "-ID". For example, the mnemonic identifier for node S3 370 would be S3-NODE-ID. 372 The JSON language does not support the insertion of comments that 373 have been instead found to be useful when writing the examples. This 374 document will insert comments into the JSON code as JSON name/value 375 pair with the JSON name string starting with the "//" characters. 376 For example, when describing the example of a TE Topology instance 377 representing the ODU Abstract Topology exposed by the Transport PNC, 378 the following comment has been added to the JSON code: 380 "// comment": "ODU Abstract Topology @ MPI", 382 The JSON code examples provided in this document have been validated 383 against the YANG models following the validation process described 384 in Appendix A, which would not consider the comments. 386 To have successful validation of the examples, some numbering scheme 387 has been defined to assign identifiers to the different entities 388 which would pass the syntax checks. In that case, to simplify the 389 reading, another JSON name/value pair formatted as a comment and 390 using the mnemonic identifiers is also provided. For example, the 391 identifier of node S3 (S3-NODE-ID) has been assumed to be "10.0.0.3" 392 and would be shown in the JSON code example using the two JSON 393 name/value pair: 395 "// te-node-id": "S3-NODE-ID", 397 "te-node-id": "10.0.0.3", 399 The first JSON name/value pair will be automatically removed in the 400 first step of the validation process, while the second JSON 401 name/value pair will be validated against the YANG model 402 definitions. 404 4. Scenarios Description 406 4.1. Reference Network 408 The physical topology of the reference network is shown in Figure 1. 409 It represents an OTN network composed of three transport network 410 domains which provide connectivity services to an IP customer 411 network through nine access links: 413 ........................ 414 ......... : : 415 : : Network domain 1 : ............. 416 Customer: : : : : 417 domain : : S1 -------+ : : Network : 418 : : / \ : : domain 3 : .......... 419 R1 ------- S3 ----- S4 \ : : : : 420 : : \ \ S2 --------+ : :Customer 421 : : \ \ | : : \ : : domain 422 : : S5 \ | : : \ : : 423 R2 ------+ / \ \ | : : S31 --------- R5 424 : : \ / \ \ | : : / \ : : 425 R3 ------- S6 ---- S7 ---- S8 ------ S32 S33 ------ R6 426 : : / | | : : / \ / : :....... 427 R4 ------+ | | : :/ S34 : : 428 : :..........|.......|...: / / : : 429 ........: | | /:.../.......: : 430 | | / / : 431 ...........|.......|..../..../... : 432 : | | / / : .............. 433 : Network | | / / : : 434 : domain 2 | | / / : :Customer 435 : S11 ---- S12 / : : domain 436 : / | \ / : : 437 : S13 S14 | S15 ------------- R7 438 : | \ / \ | \ : : 439 : | S16 \ | \ : : 440 : | / S17 -- S18 --------- R8 441 : | / \ / : : 442 : S19 ---- S20 ---- S21 ------------ R9 443 : : : 444 :...............................: :............. 446 Figure 1 - Reference network 448 This document assumes that all the Si transport network switching 449 nodes are capable of switching in the electrical domain (ODU 450 switching) moreover, that all the Si-Sj OTN links within the 451 transport network (intra-domain or inter-domain) are 100G links 452 while the access Ri-Sj links are 10G links. 454 This document also assumes that within the transport network, the 455 physical/optical connections supporting the Si-Sj OTN links (up to 456 the OTU4 trail), are pre-provisioned using mechanisms which are 457 outside the scope of this document and are not exposed at the MPIs 458 to the MDSC. 460 Different transmission technologies can be used on the access links 461 (e.g., Ethernet, STM-N and OTU). Section 4.3 provides more details 462 about the different assumptions on the access links for different 463 types of connectivity services and section 4.4 describes the control 464 of access links which can support different technology 465 configurations (e.g., STM-64, 10GE or OTU2) depending on the type of 466 service being configured (multi-function access links). 468 To carry client signals (e.g., Ethernet or STM-N) over OTN, some ODU 469 termination and adaptation resources need to be available on the 470 physical edge nodes (e.g., node S3 and S18). The location of these 471 resources within the physical node is implementation specific and 472 outside the scope of standardization. This document assumes that 473 these termination and adaptation resources are located on the 474 physical interfaces of the edge nodes terminating the access links. 475 In other words, each physical access link has a set dedicated ODU 476 termination and adaptation resources. 478 The transport network control architecture, shown in Figure 2, 479 follows the ACTN architecture as defined in the ACTN framework 480 document [RFC8453], and uses the same functional components: 482 -------------- 483 | | 484 | CNC | 485 | | 486 -------------- 487 | 488 ....................|....................... CMI 489 | 490 ---------------- 491 | | 492 | MDSC | 493 | | 494 ---------------- 495 / | \ 496 / | \ 497 ............../.....|......\................ MPIs 498 / | \ 499 / ---------- \ 500 / | PNC2 | \ 501 / ---------- \ 502 ---------- | \ 503 | PNC1 | ----- \ 504 ---------- ( ) ---------- 505 | ( ) | PNC3 | 506 ----- ( Network ) ---------- 507 ( ) ( Domain 2 ) | 508 ( ) ( ) ----- 509 ( Network ) ( ) ( ) 510 ( Domain 1 ) ----- ( ) 511 ( ) ( Network ) 512 ( ) ( Domain 3 ) 513 ----- ( ) 514 ( ) 515 ----- 517 Figure 2 - Controlling Hierarchies 519 The NEs within network domains 1, 2 and 3 of Figure 1 are 520 controlled, respectively, by PNC1, PNC2 and PNC3 of Figure 2. The 521 MDSC control the end-to-end network through the MPIs toward the 522 underlying PNCs. 524 The ACTN framework facilitates the separation of the network and 525 service control from the underlying technology. It helps the 526 customer to define the network as desired by business needs. The CMI 527 is defined to keep a minimal level of dependency (or no dependency 528 at all) from the underlying network technologies. The MPI instead 529 requires some specialization according to the domain technology. 531 The control interfaces within the scope of this document are the 532 three MPIs, as shown in Figure 2. 534 The split of functionality at the MPI in the ACTN architecture 535 between the MDSC (multi-domain controller) and the PNCs (domain 536 controllers), is equivalent to separation functionality assumed in 537 the ONF T-API interface, as described in the ONF T-API multi-domain 538 use cases [ONF TR-527]. Furthermore, this functional separation is 539 similarly defined in the MEF PRESTO interface between the Service 540 Orchestration Functionality (SOF) and the Infrastructure Control and 541 Management (ICM) in the MEF LSO Architecture [MEF 55]. 543 This document does not make any assumption about the control 544 architecture of the customer IP network: in line with [RFC8453], the 545 CNC is just a functional component within the customer control 546 architecture which is capable of requesting connectivity services on 547 demand between IP routers at the CMI. 549 The CNC can request connectivity services between IP routers which 550 can be attached to different transport network domains (e.g., 551 between R1 and R8 in Figure 1) or to the same transport network 552 domain (e.g., between R1 and R3 in Figure 1). Since the CNC is not 553 aware of the transport network controller hierarchy, the mechanisms 554 used by the CNC to request connectivity services at the CMI is also 555 unaware whether the requested service spans a single-domain or 556 multi-domains. 558 It is assumed that the CMI allows the CNC to provide all the 559 necessary information needed by the MDSC to understand the 560 connectivity service request and to determine the network 561 configurations to be requested, at the MPIs, to its underlying PNCs 562 to support the requested connectivity service. 564 The MDSC, after having received a single-domain service request from 565 the CNC at the CMI (e.g., between R1 and R3 in Figure 1), can follow 566 the same procedures, described above for the multi-domain service, 567 and decide the network configuration to request only at the MPI of 568 the PNC controlling that domain (e.g., MPI1 of PNC1 in Figure 2). 570 4.2. Topology Abstractions 572 Abstraction provides a selective method for representing 573 connectivity information within a domain. There are multiple methods 574 to abstract a network topology. This document assumes the 575 abstraction method defined in [RFC7926]: 577 "Abstraction is the process of applying the policy to the 578 available TE information within a domain, to produce selective 579 information that represents the potential ability to connect 580 across the domain. Thus, abstraction does not necessarily offer 581 all possible connectivity options, but presents a general view of 582 potential connectivity according to the policies that determine 583 how the domain's administrator wants to allow the domain resources 584 to be used." 586 [RFC8453] Provides the context of topology abstraction in the ACTN 587 architecture and discusses a few alternatives for the abstraction 588 methods for both packet and optical networks. This is an important 589 consideration since the choice of the abstraction method impacts 590 protocol design and the information it carries. According to 591 [RFC8453], there are three types of topologies: 593 o White topology: This is a case where the PNC provides the actual 594 network topology to the MDSC without any hiding or filtering. In 595 this case, the MDSC has the full knowledge of the underlying 596 network topology; 598 o Black topology: The entire domain network is abstracted as a 599 single virtual node with the access links and inter-domain links 600 without disclosing any node internal connectivity information; 602 o Grey topology: This abstraction level is between black topology 603 and white topology from a granularity point of view. 605 Each PNC should provide the MDSC a network topology abstraction 606 hiding the internal details of the physical domain network topology 607 controlled by the PNC. As described in section 3 of [RFC8453], the 608 level of abstraction provided by each PNC is based on the PNC 609 configuration parameters and it is independent of the abstractions 610 provided by other PNCs. Therefore, it is possible that different 611 PNCs provide different types of topology abstractions. The MDSC can 612 operate on each MPI abstract topology regardless of, and 613 independently from, the type of abstraction provided by its 614 underlying PNC. 616 For analyzing how the MDSC can operate on an abstract topology 617 provided by several PNcs that independently applied different 618 abstraction policies and therefore provided different types of 619 abstract topologies, the following assumptions are made for the 620 reference network in Figure 1: 622 o PNC1 and PNC2 provide black topology abstractions which expose at 623 MPI1, and MPI2 respectively, a single virtual node (representing 624 the whole network domain 1, and domain 2 respectively). 626 o PNC3 provides a white topology abstraction which exposes at MPI3 627 all the physical nodes and links within network domain 3. 629 The MDSC should be capable of stitching together the abstracted 630 topologies provided by each PNC to build its view of the multi- 631 domain network topology. This topology knowledge may require proper 632 oversight, including the application of local policy, configuration 633 methods, and the application of a trust model. Methods of how to 634 manage these aspects are out of scope for this document, but 635 recomandations are provided in the Security section of this 636 document. 638 The MDSC can also provide topology abstraction of its view of the 639 multi-domain network topology at its CMIs depending on the 640 customers' needs and policies: it can provide different types of 641 topology abstractions at different CMIs. Analyzing the topology 642 abstractions provided by the MDSC to its CMIs is outside the scope 643 of this document. 645 4.3. Service Configuration 647 In the following scenarios, it is assumed that the CNC is capable of 648 requesting connectivity services from the MDSC, for example to 649 interconnect IP routers. 651 The type of connectivity services depends on the type of physical 652 links (e.g. OTN link, ETH link or SDH link) between the routers and 653 transport network. 655 The packet processing inside IP routers, including packet 656 encapsualation and decapsulation, Ri (PKT -> foo) and Rj (foo -> 657 PKT), are assumed to be performed by means that are not under the 658 control of, and not visible to, the MDSC nor to the PNCs. Therefore, 659 these mechanisms are outside the scope of this document. 661 4.3.1. ODU Transit 663 The physical links interconnecting the IP routers and the transport 664 network can be 10G OTN links. 666 In this case, it is assumed that the physical/optical 667 interconnections below the ODU layer (up to the OTU2 trail) are 668 pre-provisioned using mechanisms which are outside the scope of this 669 document and not exposed at the MPIs between the PNCs and the MDSC. 671 For simplicity of the description, it is also assumed that these 672 interfaces are not channelized (i.e., they can only support one 673 ODU2). 675 When a 10Gb IP link between R1 and R8 is needed, an ODU2 end-to-end 676 connection needs to be created, passing through transport network 677 nodes S3, S1, S2, S31, S33, S34, S15 and S18 which belong to 678 different PNC domains (multi-domain service request): 680 R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]), 681 S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)], 682 S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)] 684 The MDSC receives, at the CMI,the request to create an ODU2 transit 685 service between the access links on S3 and S18, which belong to 686 different PNC domains (multi-domain service request). The MDSC also 687 determines the network configuration requests to be sent to its 688 underlying PNCs, at the MPIs, to coordinate the setup of a multi- 689 domain ODU2 connection segment between the access links on S3 and 690 S18. 692 When a 10Gb IP link between R1 and R3 is needed, an ODU2 end-to-end 693 connection needs to be created, passing through transport network 694 nodes S3, S5 and S6 which belong to the same PNC domain (single- 695 domain service request): 697 R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)], 698 R3 [ODU2 -> (PKT)] 700 As described in section 4.1, the mechanisms, used by the CNC at the 701 CMI, are independent on whether the service request is single-domain 702 service or multi-domain. 704 The MDSC can figure out that it needs to setup an ODU2 transit 705 service between the access links on S3 and S6, which belong to the 706 same PNC domain (single-domain service request) and it decides the 707 proper network configuration to request PNC1. 709 4.3.2. EPL over ODU 711 The physical links interconnecting the IP routers and the transport 712 network can be 10G Ethernet physical links (10GE). 714 In this case, it is assumed that the Ethernet physical interfaces 715 (up to the MAC layer) are pre-provisioned using mechanisms which are 716 outside the scope of this document and not exposed at the MPIs 717 between the PNCs and the MDSC. 719 When a 10Gb IP link between between R1 and R8 is needed, an EPL 720 service needs to be created, supported by an ODU2 end-to-end 721 connection, between transport network nodes S3 and S18, passing 722 through transport network nodes S1, S2, S31, S33, S34 and S15, which 723 belong to different PNC domains (multi-domain service request): 725 R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)], 726 S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)], 727 S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)] 729 The MDSC receives, at the CMI, the request to create an EPL service 730 between the access links on S3 and S18, which belong to different 731 PNC domains (multi-domain service request). The MDSC determines the 732 network configurations to request, at the MPIs, to its underlying 733 PNCs, to coordinate the setup of an end-to-end ODU2 connection 734 between the nodes S3 and S8, including the configuration of the 735 adaptation functions inside these edge nodes, such as S3 [ETH -> 736 (ODU2)] and S18 [(ODU2) -> ETH]. 738 When a 10Gb IP link between R1 and R2 is needed, an EPL service 739 needs to be created, supported by an ODU2 end-to-end connection 740 between transport network nodes S3 and S6, passing through the 741 transport network node S5, which belong to the same PNC domain 742 (single-domain service request): 744 R1 [(PKT) -> ETH], S3 [ETH -> (PKT)] S5 [(ODU2)], 745 S6 [(ODU2) -> ETH], R2 [ETH -> (PKT)] 747 As described in section 4.1, the mechanisms used by the CNC at the 748 CMI are independent on whether the service request is single-domain 749 service or multi-domain. 751 Based on the assumption above, in this case, the MDSC can figure out 752 that it needs to setup an EPL service between the access links on S3 753 and S6, which belong to the same PNC domain (single-domain service 754 request) and it decides the proper network configuration to request 755 PNC1. 757 4.3.3. Transparent Client Services 759 [ITU-T G.709] defines mappings of different Transparent Client 760 layers into ODU. Most of them are used to provide Private Line 761 services over an OTN transport network supporting a variety of types 762 of physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel, 763 InfiniBand, etc.) interconnecting the IP routers and the transport 764 network. 766 When a 10Gb IP link between R1 and R8 is needed, using, for example 767 SDH physical links between the IP routers and the transport network, 768 an STM-64 Private Line service needs to be created, supported by an 769 ODU2 end-to-end connection, between transport network nodes S3 and 770 S18, passing through transport network nodes S1, S2, S31, S33, S34 771 and S15, which belong to different PNC domains (multi-domain service 772 request): 774 R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S1 [(ODU2)], 775 S2 [(ODU2)], S31 [(ODU2)], S33 [(ODU2)], S34[(ODU2)], 776 S15 [(ODU2)], S18 [(ODU2) -> STM-64], R8 [STM-64 -> (PKT)] 778 As described (section 4.1) the CNC provides the essential 779 information to permit the MDSC to compute which type of service is 780 needed, in this case, an STM-64 Private Line Service between the 781 access links on S3 and S8, and it also decides the network 782 configurations, including the configuration of the adaptation 783 functions inside these edge nodes, such as S3 [STM-64 -> (ODU2)] and 784 S18 [(ODU2) -> STM-64]. 786 When a 10Gb IP link between R1 and R3 is needed, an STM-64 Private 787 Line service needs to be created between R1 and R3 (single-domain 788 service request): 790 R1 [(PKT) -> STM-64], S3[STM-64 -> (ODU2)], S5 [(ODU2)], 791 S6 [(ODU2) -> STM-64], R3[STM-64 -> (PKT)] 793 As described in section 4.1, the mechanisms, used by the CNC at the 794 CMI, are independent on whether the service request is single-domain 795 service or multi-domain. 797 Based on the assumption above, in this case, the MDSC can figure out 798 that it needs to setup an STM-64 Private Line service between the 799 access links on S3 and S6, which belong to the same PNC domain 800 (single-domain service request) and it decides the proper network 801 configuration to request PNC1. 803 4.3.4. EVPL over ODU 805 When the physical links interconnecting the IP routers and the 806 transport network are Ethernet physical links, it is also possible 807 that different Ethernet services (e.g., EVPL) can share the same 808 physical access link using different VLANs. 810 As described in section 4.3.2, it is assumed that the Ethernet 811 physical interfaces (up to the MAC layer) are pre-provisioned. 813 When two 1Gb IP links between R1 to R2 and between R1 and R8 are 814 needed, two EVPL services need to be created, supported by two ODU0 815 end-to-end connections: 817 R1 [(PKT) -> VLAN], S3 [VLAN -> (ODU0)], S5 [(ODU0)], 818 S6 [(ODU0) -> VLAN], R2 [VLAN -> (PKT)] 820 R1 [(PKT) -> VLAN], S3[VLAN -> (ODU0)], S1 [(ODU0)], 821 S2 [(ODU0)], S31 [(ODU0)], S33 [(ODU0)], S34 [(ODU0)], 822 S15 [(ODU0)], S18 [(ODU0) -> VLAN], R8[VLAN -> (PKT)] 824 It is worth noting that the first EVPL service is required between 825 access links which belong to the same PNC domain (single-domain 826 service request) while the second EVPL service is required between 827 access links which belong to different PNC domains (multi-domain 828 service request). 830 Since the two EVPL services are sharing the same Ethernet physical 831 link between R1 and S3, different VLAN IDs are associated with 832 different EVPL services: for example, VLAN IDs 10 and 20 833 respectively. 835 Based on the assumptions described in section 4.3.2, the CNC sends a 836 request to the MDSC, at the CMI, to setup these EVPL services. The 837 MDSC will determine the network configurations to request to the 838 underlying PNCs, as described in section 4.3.2. 840 4.4. Multi-function Access Links 842 Some physical links interconnecting the IP routers and the transport 843 network can be configured in different modes, e.g., as OTU2 trail or 844 STM-64 or 10GE physical links. 846 This configuration can be pre-provisioned by means which are outside 847 the scope of this document. In this case, these links will appear at 848 the MPI as links supporting only one mode (depending on how the link 849 has been pre-provisioned) and will be controlled at the MPI as 850 discussed in section 4.3: for example, a 10G multi-function access 851 link can be pre-provisioned as an OTU2 trail (section 4.3.1), a 10GE 852 physical link (section 4.3.2) or an STM-64 physical link (section 853 4.3.3). 855 It is also possible not to configure these links a-priori and let 856 the MDSC (or, in case of a single-domain service request, the PNC) 857 decide how to configure these links, based on the service 858 configuration. 860 For example, if the physical link between R1 and S3 is a 861 multi-functional access link while the physical links between R4 and 862 S6 and between R8 and S18 are STM-64 and 10GE physical links 863 respectively, it is possible to configure either an STM-64 Private 864 Line service between R1 and R4 or an EPL service between R1 and R8. 866 The traffic flow between R1 and R4 can be summarized as: 868 R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S5 [(ODU2)], 869 S6 [(ODU2) -> STM-64], R4 [STM-64 -> (PKT)] 871 The traffic flow between R1 and R8 can be summarized as: 873 R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)], 874 S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)], 875 S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)] 877 The CNC is capable of requesting, via the CMI, the setup either an 878 STM-64 Private Line service, between R1 and R4, or an EPL service, 879 between R1 and R8. 881 The MDSC, based on the service being request, decides the network 882 configurations to request, at the MPIs, to its underlying PNCs, to 883 coordinate the setup of an end-to-end ODU2 connection, either 884 between nodes S3 and S6, or between nodes S3 and S18, including the 885 configuration of the adaptation functions on these edge nodes, and 886 in particular whether the multi-function access link between R1 and 887 S3 should operate as an STM-64 or as a 10GE physical link. 889 Assumptions used in this example, as well as the service scenarios 890 of sections 4.3, include: 892 o the R1-S3 and R8-S18 access links will be multi-function access 893 links, which can be configured as an OTU2 trail or as an STM-64 894 or a 10GE physical link; 896 o the R3-S6 access link will be a multi-function access link which 897 can be configured as an OTU2 trail or as an STM-64 physical link; 899 o the R4-S6 access link is pre-provisioned as an STM-64 physical 900 link; 902 o all the other access links (and, in particular, the R2-S6 access 903 links) are pre-provisioned as 10GE physical links, up to the MAC 904 layer. 906 4.5. Protection and Restoration Configuration 908 As described in [RFC4427], recovery can be performed by either 909 protection switching or restoration mechanisms. This section 910 describes only services which are protected with linear protection, 911 considering both end-to-end and segment protection, as defined in 912 [ITU-T G.808.1] and [RFC4427]. The description of services using 913 dynamic restoration is outside the scope of this document. 915 The MDSC needs to be capable of determining the network 916 configurations to request different PNCs to coordinate the 917 protection switching configuration to support protected connectivity 918 services described in section 4.3. 920 In the service examples described in section 4.3, switching within 921 the transport network domain is only performed at the OTN ODU layer. 922 Therefore, it is also assumed that protection switching within the 923 transport network also occurs at the OTN ODU layer, using the 924 mechanisms defined in [ITU-T G.873.1]. 926 4.5.1. Linear Protection (end-to-end) 928 To protect the connectivity services described in section 4.3 from 929 failures within the OTN multi-domain transport network, the MDSC can 930 decide to request its underlying PNCs to configure ODU2 linear 931 protection between the transport network edge nodes (e.g., nodes S3 932 and S18 for the services setup between R1 and R8). 934 It is assumed that the OTN linear protection is configured as 1+1 935 unidirectional protection switching type according to the definition 936 in [ITU-T G.808.1] and [ITU-T G.873.1], as well as in [RFC4427]. 938 In these scenarios, a working transport entity and a protection 939 transport entity, as defined in [ITU-T G.808.1], (or a working LSP 940 and a protection LSP, as defined in [RFC4427]) should be configured 941 in the data plane. 943 Two cases can be considered: 945 o In one case, the working and protection transport entities pass 946 through the same PNC domains: 948 Working transport entity: S3, S1, S2, 949 S31, S33, S34, 950 S15, S18 952 Protection transport entity: S3, S4, S8, 953 S32, 954 S12, S17, S18 956 o In another case, the working and protection transport entities 957 can pass through different PNC domains: 959 Working transport entity: S3, S5, S7, 960 S11, S12, S17, S18 962 Protection transport entity: S3, S1, S2, 963 S31, S33, S34, 964 S15, S18 966 The PNCs should be capable of reporting to the MDSC which is the 967 active transport entity, as defined in [ITU-T G.808.1], in the data 968 plane. 970 Given the fast dynamic of protection switching operations in the 971 data plane (e.g., 50ms switching time), this reporting is not 972 expected to be in real-time. 974 It is also worth noting that with unidirectional protection 975 switching, e.g., 1+1 unidirectional protection switching, the active 976 transport entity may be different in the two directions. 978 4.5.2. Segmented Protection 980 To protect the connectivity services defined in section 4.3 from 981 failures within the OTN multi-domain transport network, the MDSC can 982 decide to request its underlying PNCs to configure ODU2 linear 983 protection between the edge nodes of each domain. 985 For example, MDSC can request PNC1 to configure linear protection 986 between its edge nodes S3 and S2: 988 Working transport entity: S3, S1, S2 990 Protection transport entity: S3, S4, S8, S2 992 MDSC can also request PNC2 to configure linear protection between 993 its edge nodes S15 and S18: 995 Working transport entity: S15, S18 997 Protection transport entity: S15, S12, S17, S18 999 MDSC can also request PNC3 to configure linear protection between 1000 its edge nodes S31 and S34: 1002 Working transport entity: S31, S33, S34 1004 Protection transport entity: S31, S32, S34 1006 4.6. Notification 1008 To realize the topology update, service update and restoration 1009 function, following notification types should be supported: 1011 1. Object create 1013 2. Object delete 1015 3. Object state change 1017 4. Alarm 1019 There are three types of topology abstraction types defined in 1020 section 4.2, and the notifications should also be abstracted. The 1021 PNC and MDSC should coordinate together to determine the 1022 notification policy. This will include information such as when an 1023 intra-domain alarm occurred. The PNC may not report the alarm, but 1024 it should provide notification of the service state change to the 1025 MDSC. 1027 Analysis and methods of how event alarms are triggered, managed and 1028 propagated are outside the scope of this document. 1030 4.7. Path Computation with Constraints 1032 It is possible to define constraints to be taken into account during 1033 path computation procedures (e.g., IRO/XRO). 1035 For example, the CNC can request, at the CMI, an ODU transit 1036 service, as described in section 4.3.1, between R1 and R8 with the 1037 constraint to pass through the link from S2 to S31 (IRO), such that 1038 a qualified path could be: 1040 R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]), 1041 S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)], 1042 S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)] 1044 If the CNC instead requested to pass through the link from S8 to 1045 S12, then the above path would not be qualified, while the following 1046 would be: 1048 R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]), 1049 S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 -> 1050 (PKT)] 1052 The mechanisms, used by the CNC to provide path constraints at the 1053 CMI, are outside the scope of this document. It is assumed that the 1054 MDSC can satisfy these constraints and take them into account in its 1055 path computation procedures (which would decide at least which 1056 domains and inter-domain links) and in the path computation 1057 constraints to provide to its underlying PNCs, to be taken into 1058 account in the path computation procedures implemented by the PNCs 1059 (with a more detailed view of topology). 1061 Further detailed analysis is outside the scope of this document. 1063 5. YANG Model Analysis 1065 This section analyses how the IETF YANG models can be used at the 1066 MPIs, between the MDSC and the PNCs, to support the scenarios 1067 described in section 4. 1069 The YANG models described in [ACTN-YANG] are assumed to be used at 1070 the MPI. 1072 Section 5.1 describes the different topology abstractions provided 1073 to the MDSC by each PNC via its own MPI. 1075 Section 5.2 describes how the MDSC can request different PNCs, via 1076 their own MPIs, the network configuration needed to setup the 1077 different services described in section 4.3. 1079 Section 5.3 describes how the protection scenarios can be deployed, 1080 including end-to-end protection and segment protection, for both 1081 intra-domain and inter-domain scenario. 1083 5.1. YANG Models for Topology Abstraction 1085 This section analyses how each PNC can report its respective 1086 abstract topology to the MDSC, as described in section 4.2, using 1087 the Topology YANG models, defined in [RFC8345], with the TE Topology 1088 YANG augmentations, provided in [TE-TOPO], and the OTN 1089 technology-specific YANG augmentations, defined in [OTN-TOPO] or the 1090 Ethernet client technology-specific YANG augmentations, defined in 1091 [CLIENT-TOPO]. 1093 As described in section 4.1, the OTU4 trails on inter-domain and 1094 intra-domain physical links are pre-provisioned and therefore not 1095 exposed at the MPIs. Only the TE Links they support can be exposed 1096 at the MPI, depending on the topology abstraction performed by the 1097 PNC. 1099 The access links can be multi-function access links, as described in 1100 section 4.4. 1102 As described in section 4.1, each physical access link has a 1103 dedicated set of ODU termination and adaptation resources. 1105 The [OTN-TOPO] model allows reporting within the OTN abstract 1106 topology also the access links which are capable of supporting the 1107 transparent client layers, defined in section 4.3.3 and in 1108 [CLIENT-SIGNAL]. These links can also be multi-function access links 1109 that can be configured as a transparent client physical links (e.g., 1110 STM-64 physical link) or as an OTUk trail. 1112 In order to support the EPL and EVPL services, described in sections 1113 4.3.2 and 4.3.4, the access links, which are capable of being 1114 configured as Ethernet physical links, are reported by each PNC 1115 within its respective Ethernet abstract topology, using the Topology 1116 YANG models, defined in [RFC8345], with the TE Topology YANG 1117 augmentations, defined in [TE-TOPO], and the Ethernet client 1118 technology-specific YANG augmentations, defined in [CLIENT-TOPO]. 1119 These links can also be multi-function access links that can be 1120 configured as an Ethernet physical link, an OTUk trail, or as a 1121 transparent client physical links (e.g., STM-64 physical link). In 1122 this case, these physical access links are represented in both the 1123 OTN and Ethernet abstract topologies. 1125 The PNC reports the capabilities of the access or inter-domain link 1126 ends it can control. It is the MDSC responsibility to request 1127 configuration of these links matching the capabilities of both link 1128 ends. 1130 It is worth noting that in the network scenarios analyzed in this 1131 document (where switching is performed only at the ODU layer), the 1132 Ethernet abstract topologies reported by the PNCs describes only the 1133 Ethernet client access links: no Ethernet TE switching capabilities 1134 are reported in these Ethernet abstract topologies, to report that 1135 the underlying networt domain is not capable to support Ethernet TE 1136 Tunnels/LSPs. 1138 5.1.1. Domain 1 Black Topology Abstraction 1140 PNC1 provides the required black topology abstraction, as described 1141 in section 4.2. It exposes at MPI1 to the MDSC, two TE Topology 1142 instances with only one TE node each. 1144 The first TE Topology instance reports the domain 1 OTN abstract 1145 topology view (MPI1 OTN Topology), using the OTN technology-specific 1146 augmentations [OTN-TOPO], with only one abstract TE node (i.e., AN1) 1147 moreover, only inter-domain and access abstract TE links (which 1148 represent the inter-domain physical links and the access physical 1149 links which can support ODU, or transparent client layers, both), as 1150 shown in Figure 3 below. 1152 ................................... 1153 : : 1154 : +-----------------+ : 1155 : | | : 1156 (R1)- - --------| |-------- - -(S31) 1157 : AN1-1 | | AN1-7 : 1158 : | | : 1159 (R3)- - --------| | : 1160 : AN1-2 | AN1 | : 1161 : | | : 1162 (R4)- - --------| |-------- - -(S32) 1163 : AN1-3 | | AN1-6 : 1164 : | | : 1165 : +-----------------+ : 1166 : | | : 1167 : AN1-4 | | AN1-5 : 1168 :..........|..........|...........: 1170 | | 1171 (S11) (S12) 1173 Figure 3 - OTN Abstract Topology exposed at MPI1 (MPI1 OTN Topology) 1175 The second TE Topology instance reports the domain 1 Ethernet 1176 abstract topology view (MPI1 ETH Topology), using the Ethernet 1177 technology-specific augmentations [CLIENT-TOPO], with only one 1178 abstract TE node (i.e., AN1) and only access abstract TE links 1179 (which represent the access physical links which can support 1180 Ethernet client layers), as shown in Figure 4 below. 1182 ................................... 1183 : : 1184 : +-----------------+ : 1185 : | | : 1186 (R1)- - --------| | : 1187 : AN1-1 | | : 1188 : | | : 1189 (R2)- - --------| | : 1190 : AN1-8 | AN1 | : 1191 : | | : 1192 : | | : 1193 : | | : 1194 : | | : 1195 : +-----------------+ : 1196 : : 1197 :.................................: 1199 Figure 4 - ETH Abstract Topology exposed at MPI1 (MPI1 ETH Topology) 1201 The OTU4 trails on the inter-domain physical links (e.g., the link 1202 between S2 and S31) are pre-provisioned and exposed as external TE 1203 Links, within the MPI1 OTN topology (e.g., the external TE Link 1204 terminating on AN1-7 TE Link Termination Point (LTP) abstracting the 1205 OTU4 trail between S2 and S31). 1207 The PNC1 exports at MPI1 the following external TE Links, within the 1208 MPI1 OTN topology, representing the multi-function access links 1209 under its control: 1211 o two abstract TE Links, terminating on LTP AN1-1 and AN1-2 1212 respectively, abstracting the physical access link between S3 and 1213 R1 and the access link between S6 and R3 respectively, reporting 1214 that they can support STM-64 client signals as well as ODU2 1215 connections; 1217 o one abstract TE Link, terminating on LTP AN1-3, abstracting the 1218 physical access link between S6 and R4, reporting that it can 1219 support STM-64 client signals but no ODU2 connections. 1221 The information about the 10GE access link between S6 and R2 as well 1222 as the fact that the access link between S3 and R1 can also be 1223 configured as a 10GE link cannot be exposed by PNC1 within the MPI1 1224 OTN topology. 1226 Therefore, PNC1 exports at MPI1, within the MPI1 ETH topology, two 1227 abstract TE Links, terminating on LTP AN1-1 and AN1-8 respectively, 1228 abstracting the physical access link between S3 and R1 and the 1229 access link between S6 and R2 respectively, reporting that they can 1230 support Ethernet client signal with port-based and VLAN-based 1231 classifications. 1233 PNC1 should expose at MPI1 also the ODU termination and adaptation 1234 resources which are available to carry client signals (e.g., 1235 Ethernet or STM-N) over OTN. This information is reported by the 1236 Tunnel Termination Points (TTPs) within the MPI1 OTN Topology. 1238 In particular, PNC1 will report, within the MPI1 OTN Topology, one 1239 TTP for each access link (i.e., AN1-1, AN1-2, AN1-3 and AN1-8) and 1240 will assign a transition link or an inter-layer lock identifier, 1241 which is unique across all the TE Topologies PNC1 is exposing at 1242 MPI1, to each TTP and access link's LTP pair. 1244 For simplicity purposes, this document assigns the same number to 1245 the LTP-ID, TTP-ID and ILL-ID that corresponds to the same access 1246 link (i.e., 1, 2, 3 and 8 respectively for the LTP, TTP and 1247 Inter-Layer Lock (IIL) corresponding with the access links AN1-1, 1248 AN1-2, AN1-3 and AN1-8). 1250 The PNC1 native topology would represent the physical network 1251 topology of the domain controlled by the PNC, as shown in Figure 5. 1253 .................................. 1254 : : 1255 : Physical Topology @ PNC1 : 1256 : : 1257 : +----+ +----+ : 1258 : | |S1-1 | |S2-3: 1259 : | S1 |--------| S2 |----- - -(S31) 1260 : +----+ S2-1+----+ : 1261 : S1-2/ |S2-2 : 1262 : S3-4/ | : 1263 : +----+ +----+ | : 1264 : | |3 1| | | : 1265 (R1)- - -----| S3 |---| S4 | | : 1266 :S3-1+----+ +----+ | : 1267 : S3-2 \ \S4-2 | : 1268 : \S5-1 \ | : 1269 : +----+ \ | : 1270 : | | \S8-2| : 1271 : | S5 | \ | : 1272 : +----+ \ |S8-1 : 1273 (R2)- - ------ 2/ \3 \ | : 1274 :S6-1 \ /5 \1 \| : 1275 : +----+ +----+ +----+ : 1276 : | | | | | |S8-5: 1277 (R3)- - -----| S6 |---| S7 |---| S8 |----- - -(S32) 1278 :S6-2+----+4 2+----+4 3+----+ : 1279 : / | | : 1280 (R3)- - ------ S7-3 | | S8-4 : 1281 :S6-3 | | : 1282 :...............|........|.......: 1284 | | 1285 (S11) (S12) 1287 Figure 5 - Physical Topology controlled by PNC1 1289 The PNC1 native topology is not exposed and therefore it under PNC 1290 responsibility to abstract the whole domain physical topology as a 1291 single TE node and to maintain a mapping between the LTPs exposed at 1292 MPI abstract topologies and the associated physical interfaces 1293 controlled by the PNC: 1295 Physical Interface OTN Topology LTP ETH Topology LTP 1296 (Figure 5) (Figure 3) (Figure 4) 1297 S2-3 AN1-7 1298 S3-1 AN1-1 AN1-1 1299 S6-1 AN1-8 1300 S6-2 AN1-2 1301 S6-3 AN1-3 1302 S7-3 AN1-4 1303 S8-4 AN1-5 1304 S8-5 AN1-6 1306 Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn- 1307 topology.json") describing how the MPI1 ODU Topology is reported by 1308 the PNC1, using the [RFC8345], [TE-TOPO] and [OTN-TOPO] YANG models, 1309 at MPI1. 1311 Appendix B.1.2 provides the detailed JSON code example ("mpi1-eth- 1312 topology.json") describing how the MPI1 ETH Topology is reported by 1313 the PNC1, using the [RFC8345], [TE-TOPO] and [CLIENT-TOPO] YANG 1314 models, at MPI1. 1316 It is worth noting that this JSON code example does not provide all 1317 the attributes defined in the relevant YANG models, including: 1319 o YANG attributes which are outside the scope of this document are 1320 not shown; 1322 o The attributes describing the set of label values that are 1323 available at the inter-domain links (label-restriction container) 1324 are also not shown to simplify the JSON code example; 1326 o The comments describing the rationale for not including some 1327 attributes in this JSON code example even if in the scope of this 1328 document are identified with the prefix "// __COMMENT" and 1329 included only in the first object instance (e.g., in the Access 1330 Link from the AN1-1 description or in the AN1-1 LTP description). 1332 5.1.2. Domain 2 Black Topology Abstraction 1334 PNC2 provides the required black topology abstraction, as described 1335 in section 4.2, to expose to the MDSC, at MPI2, two TE Topology 1336 instances with only one TE node each: 1338 o the first instance reports the domain 2 OTN abstract topology 1339 view (MPI2 OTN Topology), with only one abstract node (i.e., AN2) 1340 and only inter-domain and access abstract TE links (which 1341 represent the inter-domain physical links and the access physical 1342 links which can support ODU, or transparent client layers or 1343 both); 1345 o the instance reports the domain 2 Ethernet abstract topology view 1346 (MPI2 ETH Topology), with only one abstract TE node (i.e., AN2) 1347 and only access abstract TE links (which represent the access 1348 physical links which can support Ethernet client layers). 1350 PNC2 also reports the ODU termination and adaptation resources which 1351 are available to carry client signals (e.g., Ethernet or STM-N) over 1352 OTN in the TTPs within the MPI2 OTN Topology. 1354 In particular, PNC2 reports in both the MPI2 OTN Topology and MPI2 1355 ETH Topology an AN2-1 access link which abstracts the multi-function 1356 physical access link between S18 and R8, which is assumed to 1357 correspond to the S18-3 LTP, within the PNC2 native topology. It 1358 also reports in the MPI2 ETH Topology a TTP which abstracts the ODU 1359 termination and adaptation resources dedicated to this physical 1360 access link and the inter-layer lock between this TTP, and the AN2-1 1361 LTPs reported within the MPI2 OTN Topology and the MPI2 ETH 1362 Topology. 1364 5.1.3. Domain 3 White Topology Abstraction 1366 PNC3 provides the required white topology abstraction, as described 1367 in section 4.2, to expose to the MDSC, at MPI3, two TE Topology 1368 instances with multiple TE nodes, one for each physical node: 1370 o the first instance reports the domain 3 OTN topology view (MPI3 1371 OTN Topology), with four TE nodes, which represent the four 1372 physical nodes (i.e. S31, S32, S33 and S34), and abstract TE 1373 links, which represent the inter-domain and internal physical 1374 links; 1376 o the second instance reports the domain 3 Ethernet abstract 1377 topology view (MPI3 ETH Topology), with only two TE nodes, which 1378 represent the two edge physical nodes (i.e., S31 and S33) and 1379 only the two access TE links which represent the access physical 1380 links. 1382 PNC3 also reports the ODU termination and adaptation resources which 1383 are available to carry client signals (e.g., Ethernet or STM-N) over 1384 OTN in the TTPs within the MPI3 OTN Topology. 1386 5.1.4. Multi-domain Topology Merging 1388 MDSC does not have any knowledge of the topologies of each domain 1389 until each PNC reports its own abstract topologies, so the MDSC 1390 needs to merge these abstract topologies, provided by different 1391 PNCs, to build its own topology view of the multi-domain network 1392 (MDSC multi-domain native topology), as described in section 4.3 of 1393 [TE-TOPO]. 1395 The topology of each domain may be in an abstracted shape (refer to 1396 section 5.2 of [RFC8453] for a different level of abstraction), 1397 while the inter-domain link information must be complete and fully 1398 configured by the MDSC. 1400 The inter-domain link information is reported to the MDSC by the two 1401 PNCs, controlling the two ends of the inter-domain link. 1403 The MDSC needs to know how to merge these inter-domain links. One 1404 possibility is to use the plug-id information, defined in [TE-TOPO]: 1405 two inter-domain TE links, within two different MPI abstract 1406 topologies, terminating on two LTPs reporting the same plug-id value 1407 can be merged as a single intra-domain link, within any MDSC native 1408 topology. 1410 The value of the reported plug-id information can be either assigned 1411 by a central network authority and configured within the two PNC 1412 domains. Alternatively, it may be discovered using an automatic 1413 discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). 1415 In case the plug-id values are assigned by a central authority, it 1416 is under the central authority responsibility to assign unique 1417 values. 1419 In case the plug-id values are automatically discovered, the 1420 information discovered by the automatic discovery mechanisms needs 1421 to be encoded as a bit string within the plug-id value. This 1422 encoding is implementation-specific, but the encoding rules need to 1423 be consistent across all the PNCs. 1425 In case of co-existence within the same network of multiple sources 1426 for the plug-id (e.g., central authority and automatic discovery or 1427 even different automatic discovery mechanisms), it is needed that 1428 the plug-id namespace is partitioned to avoid that different sources 1429 assign the same plug-id value to different inter-domain links. Also, 1430 the encoding of the plug-id namespace within the plug-id value is 1431 implementation specific and will need to be consistent across all 1432 the PNCs. 1434 This document assumes that the plug-id is assigned by a central 1435 authority, with the first octet set to 0x00 to represent the central 1436 authority namespace. The configuration method used, within each PNC 1437 domain, are outside the scope of this document. 1439 For example, this document assumes that the following plug-id values 1440 are assigned, by administrative configuration, to the inter-domain 1441 links shown in Figure 1: 1443 Inter-Domain Link Plug-ID Value 1445 S2-S31 0x000231 1446 S7-S11 0x000711 1447 S8-S12 0x000812 1448 S8-S32 0x000832 1449 S12-S32 0x001232 1450 S15-S34 0x001534 1452 Based on the plug-id values, the MDSC can merge the abstract 1453 topologies exposed by the underlying PNCs, as described in sections 1454 5.1.1, 5.1.2 and 5.1.3 above, into its multi-domain native TE 1455 topology, as shown in Figure 6. 1457 ........................ 1458 : : 1459 : Network domain 1 : ............. 1460 : Black Topology : : : 1461 : Abstraction : : Network : 1462 : AN1-1 : : domain 3 : 1463 (R1)- - ----------+ : : (White) : 1464 : \ +--------------+ : 1465 (R2)- - ---------+ + / : : \ : 1466 : \| / : : \ : 1467 (R3)- - --------- AN1 --+ : : S31 ---- - (R5) 1468 : /|\ \ : : / \ : : 1469 (R4)- - ---------+ | \ +--------- S32 S33 - - (R6) 1470 : | \ : :/ \ / : 1471 : | +---+ : / S34 : 1472 :..........|.......|...: /: / : 1473 | | / :../........: 1474 | | / / 1475 ...........|.......|.../..../.... 1476 : | | / / : 1477 : Network | + / / : 1478 : domain 2 | / / / : 1479 : | / / / : 1480 : | + / +--+ : 1481 : | |/ / : 1482 : Black +--- AN2 ------------- - -(R7) 1483 : Topology | | AN2-1 : 1484 : Abstraction | +-------------- - -(R8) 1485 : | : 1486 : +---------------- - -(R9) 1487 : : 1488 :...............................: 1490 Figure 6 - Multi-domain Abstract Topology controlled by an MDSC 1492 5.2. YANG Models for Service Configuration 1494 This section analyses how the MDSC can request the different PNCs to 1495 setup different multi-domains services, as described in section 4.3, 1496 using the TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN 1497 technology-specific augmentations, defined in [OTN-TUNNEL] with the 1498 client service YANG model defined in [CLIENT-SIGNAL]. 1500 The service configuration procedure is assumed to be initiated (step 1501 1 in Figure 7) at the CMI from CNC to MDSC. Analysis of the CMI 1502 models is (e.g., L1CSM, L2SM, VN) is outside the scope of this 1503 document, but it is assumed that the CMI YANG models provide all the 1504 information that allows the MDSC to understand that it needs to 1505 coordinate the setup of a multi-domain ODU data plane connection 1506 (which can be either an end-to-end connection or a segment 1507 connection) and, when needed, also the configuration of the 1508 adaptation functions in the edge nodes belonging to different 1509 domains. 1511 | 1512 | {1} 1513 V 1514 ---------------- 1515 | {2} | 1516 | {3} MDSC | 1517 | | 1518 ---------------- 1519 ^ ^ ^ 1520 {3.1} | | | 1521 +---------+ |{3.2} | 1522 | | +----------+ 1523 | V | 1524 | ---------- |{3.3} 1525 | | PNC2 | | 1526 | ---------- | 1527 | ^ | 1528 V | {4.2} | 1529 ---------- V | 1530 | PNC1 | ----- V 1531 ---------- (Network) ---------- 1532 ^ ( Domain 2) | PNC3 | 1533 | {4.1} ( _) ---------- 1534 V ( ) ^ 1535 ----- C==========D | {4.3} 1536 (Network) / ( ) \ V 1537 ( Domain 1) / ----- \ ----- 1538 ( )/ \ (Network) 1539 A===========B \ ( Domain 3) 1540 / ( ) \( ) 1541 AP-1 ( ) X===========Z 1542 ----- ( ) \ 1543 ( ) AP-2 1544 ----- 1546 Figure 7 - Multi-domain Service Setup 1548 As an example, the objective in this section is to configure a 1549 connectivity service between R1 and R8, such as one of the services 1550 described in section 4.3. The inter-domain path is assumed to be R1 1551 <-> S3 <-> S1 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 <-> R8 1552 (see the physical topology in Figure 1). 1554 According to the different client signal types, different 1555 adaptations can be required to be configured at the edge nodes 1556 (i.e., S3 and S18). 1558 After receiving such request, MDSC determines the domain sequence, 1559 i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs 1560 and the inter-domain links (step 2 in Figure 7). 1562 As described in [PATH-COMPUTE], the domain sequence can be 1563 determined by running the MDSC own path computation on the MDSC 1564 native topology, defined in section 5.1.4, if and only if the MDSC 1565 has enough topology information. Otherwise, the MDSC can send path 1566 computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 1567 in Figure 7) and use this information to determine the optimal path 1568 on its internal topology and therefore the domain sequence. 1570 The MDSC will then decompose the tunnel request into a few TE tunnel 1571 segments and request different PNCs to setup each intra-domain TE 1572 tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 7). 1574 The MDSC will take care of the configuration of both the intra- 1575 domain TE tunnel segments and inter-domain TE tunnel hand-off via 1576 corresponding MPI (using the TE tunnel YANG model defined in 1577 [TE-TUNNEL] and the OTN tunnel YANG model augmentations defined in 1578 [OTN-TUNNEL]) through all the PNCs controlling the domains selected 1579 during path computation. More specifically, for the inter-domain TE 1580 tunnel hand-off, taking into account that the inter-domain links are 1581 all OTN links, the list of timeslots and the TPN value assigned to 1582 that ODUk connection at the inter-domain link needs to be configured 1583 by the MDSC. 1585 The configuration of the timeslots and the TPN value used by the 1586 ODU2 connection on the internal links within a PNC domain (i.e., on 1587 the internal links within domain1) is outside the scope of this 1588 document, since it is a matter of the PNC domain internal 1589 implementation. 1591 However, the configuration of the timeslots used by the ODU2 1592 connection at the transport network domain boundaries (e.g., on the 1593 inter-domain links) needs to take into account the timeslots 1594 available on physical nodes belonging to different PNC domains 1595 (e.g., on node S2 within PNC1 domain and node S31 within PNC3 1596 domain). Each PNC provides to the MDSC, at the MPI, the list of 1597 available timeslots on the inter-domain links using the TE Topology 1598 YANG model and OTN Topology augmentation. The TE Topology YANG model 1599 in [TE-TOPO] is being updated to report the label set information. 1600 See section 1.7 of [TE-TUTORIAL] for more details. 1602 The MDSC, when coordinating the setup of a multi-domain ODU 1603 connection, also configures the data plane resources (i.e., the list 1604 of timeslots and the TPN) to be used on the inter-domain links. The 1605 MDSC can know the timeslots which are available on the physical OTN 1606 nodes terminating the inter-domain links (e.g., S2 and S31) from the 1607 OTN Topology information exposed, at the MPIs, by the PNCs 1608 controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling 1609 the physical nodes S2 and S31 respectively). 1611 In any case, the access link configuration is done only on the PNCs 1612 that control the access links (e.g., PNC-1 and PNC-3) and not on the 1613 PNCs of transit domain(s) (e.g., PNC-2). An access link will be 1614 configured by MDSC after the OTN tunnel is set up. 1616 Access configuration will vary and will be dependent on each type of 1617 service. Further discussion and examples are provided in the 1618 following sub-sections. 1620 5.2.1. ODU Transit Service 1622 In this scenario, described in section 4.3.1, the physical access 1623 links are configured as 10G OTN links and, as described in section 1624 5.1, reported by each PNC as TE Links within the OTN abstract 1625 topologies they expose to the MDSC. 1627 When an IP link, between R1 and R8 is needed, the CNC requests, at 1628 the CMI, the MDSC to setup an ODU transit service. 1630 From its native topology, shown in Figure 6, the MDSC understands, 1631 by means which are outside the scope of this document, that R1 is 1632 attached to the access link terminating on AN1-1 LTP in the MPI1 OTN 1633 Abstract Topology (Figure 3), exposed by PNC1, and that R8 is 1634 attached to the access link terminating on AN2-1 LTP in the MPI2 1635 Abstract Topology, exposed by PNC2. 1637 MDSC then performs multi-domain path computation (step 2 in Figure 1638 7) and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3 1639 respectively, to setup ODU2 (Transit Segment) Tunnels within the OTN 1640 Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2 1641 OTN Abstract Topology and MPI3 OTN Abstract Topology, respectively). 1643 MDSC requests, at MPI1, PNC1 to setup an ODU2 (Transit Segment) 1644 Tunnel with one primary path between AN-1 and AN1-7 LTPs, within the 1645 MPI1 OTN Abstract Topology (Figure 4), using the TE Tunnel YANG 1646 model, defined in [TE-TUNNEL], with the OTN technology-specific 1647 augmentations, defined in [OTN-TUNNEL]: 1649 o Source and Destination TTPs are not specified (since it is a 1650 Transit Tunnel): i.e., the source, src-tp-id, destination and 1651 dst-tp-id attributes of the TE tunnel instance are empty 1653 o Ingress and egress points are indicated in the route-object- 1654 include-exclude list of the explicit-route-objects of the primary 1655 path: 1657 o The first element references the access link terminating on 1658 AN1-1 LTP 1660 o The last two element reference respectively the inter-domain 1661 link terminating on AN1-7 LTP and the data plane resources 1662 (i.e., the list of timeslots and the TPN) used by the ODU2 1663 connection over that link. 1665 Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service- 1666 config.json") describing how the setup of this ODU2 (Transit 1667 Segment) Tunnel can be requested by the MDSC, using the [TE-TUNNEL] 1668 and [OTN-TUNNEL] YANG models at MPI1. 1670 PNC1 knows, as described in the mapping table in Section 5.1.1, that 1671 AN-1 and AN1-7 LTPs within the MPI1 OTN Abstract Topology it exposes 1672 at MPI1 correspond to the S3-1 and S2-3 LTPs, respectively, within 1673 its native topology. Therefore it performs path computation, for an 1674 ODU2 connection between these LTPs within its native topology, and 1675 sets up the ODU2 cross-connections within the physical nodes S3, S1 1676 and S2. 1678 Since the R1-S3 access link is a multi-function access link, PNC1 1679 also configures the OTU2 trail before setting up the ODU2 1680 cross-connection in node S3. 1682 As part of the OUD2 cross-connection configuration in node S2, PNC1 1683 configures the data plane resources (i.e., the list of timeslots and 1684 the TPN), to be used by this ODU2 connection on the S2-S31 inter- 1685 domain link, as requested by the MDSC. 1687 Following similar requests from MDSC to setup ODU2 (Transit Segment) 1688 Tunnels within the OTN Abstract Topologies they expose, PNC2 then 1689 sets up ODU2 cross-connections on nodes S31 and S33 while PNC3 sets 1690 up ODU2 cross-connections on nodes S15 and S18. PNC2 also configures 1691 the OTU2 trail on the S18-R8 multi-function access link. 1693 5.2.1.1. Single Domain Example 1695 To setup an ODU2 end-to-end connection, supporting an IP link, 1696 between R1 and R3, the CNC requests, at the CMI, the MDSC to setup 1697 an ODU transit service. 1699 Following the procedures described in section 5.2.1, MDSC requests 1700 only PCN1 to setup the ODU2 (Transit Segment) Tunnel between the 1701 access links terminating on AN-1 and AN1-2 LTPs within the MPI1 1702 Abstract Topology and PNC1 sets up ODU2 cross-connections on nodes 1703 S3, S5 and S6. PNC1 also configures the OTU2 trails on the R1-S3 and 1704 R3-S6 multi-function access links. 1706 5.2.2. EPL over ODU Service 1708 In this scenario, described in section 4.3.2, the access links are 1709 configured as 10GE Links and, as described in section 5.1, reported 1710 by each PNC as TE Links within the ETH abstract topologies they 1711 expose to the MDSC. 1713 When this IP link, between R1 and R8, is needed, the CNC requests, 1714 at the CMI, the MDSC to setup an EPL service. 1716 From its native topology, shown in Figure 6, the MDSC understands, 1717 by means which are outside the scope of this document, that R1 is 1718 attached to the access link terminating on AN1-1 LTP in the MPI1 ETH 1719 Abstract Topology, exposed by PNC1, and that R8 is attached to the 1720 access link terminating on AN2-1 LTP in the MPI2 ETH Abstract 1721 Topology, exposed by PNC2. 1723 As described in sections 5.1.1 and 5.1.2: 1725 o the AN1-1 LTP, within the MPI1 ETH Abstract Topology, and the 1726 AN1-1 TTP, within the MPI1 OTN Abstract Topology, have the same 1727 IIL identifier (within the scope of MPI1); 1729 o the AN2-1 LTP, within the MPI2 ETH Abstract Topology, and the 1730 AN2-1 TTP, within the MPI2 OTN Abstract Topology, have the same 1731 IIL identifier (within the scope of MPI2). 1733 Therefore, the MDSC also understands that it needs to coordinate the 1734 setup of a multi-domain ODU2 Tunnel between AN1-1 and AN2-1 TTPs, 1735 abstracting S3-1 and S18-3 TTPs, within the OTN Abstract Topologies 1736 exposed by PNC1 and PNC2, respectively. 1738 MDSC then performs multi-domain path computation (step 2 in Figure 1739 7) and then requests: 1741 o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the 1742 MPI1 OTN Abstract Topology; 1744 o PNC1, at MPI1, to steer the Ethernet client traffic from/to AN1-1 1745 LTP, within the MPI1 ETH Abstract Topology, thought that ODU2 1746 (Head Segment) Tunnel; 1748 o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within 1749 the MPI3 OTN Abstract Topology; 1751 o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the 1752 MPI2 OTN Abstract Topology; 1754 o PNC2, at MPI2, to steer the Ethernet client traffic to/from AN2-1 1755 LTP, within the MPI2 ETH Abstract Topology, through that ODU2 1756 (Tail Segment) Tunnel. 1758 MDSC requests, at MPI1, PNC1 to setup an ODU2 (Head Segment) Tunnel 1759 with one primary path between the AN1-1 TTP and AN1-7 LTP, within 1760 the MPI1 OTN Abstract Topology (Figure 4), using the TE Tunnel YANG 1761 model, defined in [TE-TUNNEL], with the OTN technology-specific 1762 augmentations, defined in [OTN-TUNNEL]: 1764 o Only the Source TTP (i.e., AN1 TE-Node and AN1-1 TTP) is 1765 specified (since it is a Head Segment Tunnel): therefore the 1766 Destination TTP is not specified 1768 o The egress point in indicated in the route-object-include-exclude 1769 list of the explicit-route-objects of the primary path: 1771 o The last two element reference respectively the inter-domain 1772 link terminating on AN1-7 LTP and the data plane resources 1773 (i.e., the list of timeslots and the TPN) used by the ODU2 1774 connection over that link. 1776 Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel- 1777 config.json") describing how the setup of this ODU2 (Head Segment) 1778 Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN- 1779 TUNNEL] YANG models at MPI1. 1781 MDSC requests, at MPI1, PNC1 to steer the Ethernet client traffic 1782 from/to AN1-2 LTP, within the MPI1 ETH Abstract Topology (Figure 4), 1783 thought the MPI1 ODU2 (Head Segment) Tunnel, using the Ethernet 1784 Client YANG model, defined in [CLIENT-SIGNAL]. 1786 Appendix Error! Reference source not found. provides the detailed 1787 JSON code ("mpi1-epl-service-config.json") describing how the setup 1788 of this EPL service using the ODU2 Tunnel can be requested by the 1789 MDSC, using the [CLIENT-SIGNAL] YANG model at MPI1. 1791 PNC1 knows, as described in the table in section 5.1.1, that the 1792 AN1-1 TTP and the AN1-7 LTP, within the MPI1 OTN Abstract Topology 1793 it exposes at MPI1, correspond to S3-1 TTP and S2-3 LTP, 1794 respectively, within its native topology. Therefore it performs path 1795 computation, for an ODU2 connection between S3-1 TTP and S2-3 LTP 1796 within its native topology, and sets up the ODU2 cross-connections 1797 within the physical nodes S3, S1 and S2, as shown in section 4.3.2. 1799 As part of the OUD2 cross-connection configuration in node S2, PNC1 1800 configures the data plane resources (i.e., the list of timeslots and 1801 the TPN), to be used by this ODU2 connection on the S2-S31 inter- 1802 domain link, as requested by the MDSC. 1804 After the configuration of the ODU2 cross-connection in node S3, 1805 PNC1 also configures the [ETH -> (ODU)] and [(ODU2) -> ETH] 1806 adaptation functions, within node S3, as shown in section 4.3.2. 1808 Since the R1-S3 access link is a multi-function access link, PNC1 1809 also configures the 10GE link before this step. 1811 Following similar requests from MDSC to setup ODU2 (Segment) Tunnels 1812 within the OTN Abstract Topologies they expose as well as the 1813 steering of the Ethernet client traffic, PNC3 then sets up ODU2 1814 cross-connections on nodes S31 and S33 while PNC2 sets up ODU2 1815 cross-connections on nodes S15 and S18 as well as the [ETH -> 1816 (ODU2)] and [(ODU2) -> ETH] adaptation functions in node S18, as 1817 shown in section 4.3.2. PNC2 also configures the 10GE link on the 1818 S18-R8 multi-function access link. 1820 5.2.2.1. Single Domain Example 1822 When this IP link, between R1 and R2, is needed, the CNC requests, 1823 at the CMI, the MDSC to setup an EPL service. 1825 Following the procedures described in section 5.2.2, the MDSC 1826 requests PCN1 to: 1828 o Setup an ODU2 (end-to-end) Tunnel between the AN1-1 and AN1-2 1829 TTPs, abstracting S3-1 and S6-1 TTPs, within the MPI1 OTN 1830 Abstract Topology exposed by PNC1 at MPI1; 1832 o Steer the Ethernet client traffic between the AN1-1 and AN1-8 1833 LTPs, exposed by PNC1 within MPI1 ETH Abstract Topology, through 1834 that ODU2 (end-to-end) Tunnel. 1836 Then PNC1 sets up ODU2 cross-connections on nodes S3, S5 and S6 as 1837 well as the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation functions 1838 in nodes S3 and S6, as shown in section 4.3.2. PNC1 also configures 1839 the 10GE link on the R1-S3 multi-function access link (the R2-S6 1840 access link has been pre-provisioned as a 10GE link, as described in 1841 section 4.4). 1843 5.2.3. Other OTN Client Services 1845 In this scenario, described in section 4.3.3, the access links are 1846 configured as STM-64 links and, as described in section 5.1, 1847 reported by each PNC as TE Links within the OTN Abstract Topologies 1848 they expose to the MDSC. 1850 The CNC requests, at the CMI, MDSC to setup an STM-64 Private Line 1851 service between R1 and R8. 1853 Following similar procedures as described in section 5.2.2, MDSC 1854 understands that: 1856 o R1 is attached to the access link terminating on AN1-1 LTP in the 1857 MPI1 OTN Abstract Topology, exposed by PNC1, and that R8 is 1858 attached to the access link terminating on AN2-1 LTP in the MPI2 1859 OTN Abstract Topology, exposed by PNC2; 1861 o it needs to coordinate the setup of a multi-domain ODU2 Tunnel 1862 between the AN1-1 and AN2-1 TTPs, abstracting S3-1 and S18-3 1863 TTPs, within the OTN Abstract Topologies exposed by PNC1 and 1864 PNC2, respectively. 1866 The MDSC then performs multi-domain path computation (step 2 in 1867 Figure 7) and then requests: 1869 o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the 1870 MPI1 OTN Abstract Topology; 1872 o PNC1, at MPI1, to steer the STM-64 transparent client traffic 1873 from/to AN1-1 LTP, within the MPI1 OTN Abstract Topology, thought 1874 that ODU2 (Head Segment) Tunnel; 1876 o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within 1877 the MPI3 OTN Abstract Topology; 1879 o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the 1880 MPI2 OTN Abstract Topology; 1882 o PNC2, at MPI2, to steer the STM-64 transparent client traffic 1883 to/from AN2-1 LTP, within the MPI2 ETH Abstract Topology, through 1884 that ODU2 (Tail Segment) Tunnel. 1886 PNC1, PNC2 and PNC3 then sets up the ODU2 cross-connections within 1887 the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the 1888 [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation functions in 1889 nodes S3 and S18, as shown in section 4.3.3. PNC1 and PNC2 also 1890 configure the STM-64 links on the R1-S3 and R8-S18 multi-function 1891 access links, respectively. 1893 5.2.3.1. Single Domain Example 1895 When this IP link, between R1 and R3, is needed, the CNC requests, 1896 at the CMI, the MDSC to setup an STM-64 Private Line service. 1898 The MDSC and PNC1 follows similar procedures as described in section 1899 5.2.2.1 to set up ODU2 cross-connections on nodes S3, S5 and S6 as 1900 well as the [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation 1901 functions in nodes S3 and S6, as shown in section 4.3.3. PNC1 also 1902 configures the STM-64 links on the R1-S3 and R3-S6 multi-function 1903 access links. 1905 5.2.4. EVPL over ODU Service 1907 In this scenario, described in section 4.3.4, the access links are 1908 configured as 10GE links, as described in section 5.2.2 above. 1910 The CNC requests, at the CMI, the MDSC to setup two EVPL services: 1911 one between R1 and R2, and another between R1 and R8. 1913 Following similar procedures as described in section 5.2.2 and 1914 5.2.2.1, MDSC understands that: 1916 o R1 and R2 are attached to the access links terminating 1917 respectively on AN1-1 and AN1-8 LTPs in the MPI1 ETH Abstract 1918 Topology, exposed by PNC1, and that R8 is attached to the access 1919 link terminating on AN2-1 LTP in the MPI2 ETH Abstract Topology, 1920 exposed by PNC2; 1922 o To setup the first (single-domain) EVPL service, between R1 and 1923 R2, it needs to coordinate the setup of a single-domain ODU0 1924 Tunnel between the AN1-1 and AN1-8 TTPs, abstracting S3-1 and 1925 S6-1 TTPs, within the OTN Abstract Topology exposed by PNC1; 1927 o To setup the second (multi-domain) EPVL service, between R1 and 1928 R8, it needs to coordinate the setup of a multi-domain ODU0 1929 Tunnel between the AN1-1 and AN2-1 TTPs, abstracting nodes S3-1 1930 and S18-3 TTPs, within the OTN Abstract Topologies exposed by 1931 PNC1 and PNC2, respectively. 1933 To setup the first (single-domain) EVPL service between R1 and R2, 1934 the MDSC and PNC1 follows similar procedures as described in section 1935 5.2.2.1 to set up ODU0 cross-connections on nodes S3, S5 and S6 as 1936 well as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation 1937 functions, in nodes S3 and S6, as shown in section 4.3.4. PNC1 also 1938 configures the 10GE link on the R1-S3 multi-function access link. 1940 As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation 1941 functions configurations in nodes S2 and S6, PNC1 configures also 1942 the classification rules required to associated only the Ethernet 1943 client traffic received with VLAN ID 10 on the R1-S3 and R2-S6 1944 access links with this EVPL service. The MDSC provides this 1945 information to PNC1 using the [CLIENT-SIGNAL] model. 1947 To setup the second (multi-domain) EVPL service between R1 and R8, 1948 the MDSC, PNC1, PNC2 and PNC3 follows similar procedures as 1949 described in section 5.2.2 to setup the ODU0 cross-connections 1950 within the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well 1951 as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation functions in 1952 nodes S3 and S18, as shown in section 4.3.4. PNC2 also configures 1953 the 10GE link on the R8-S18 multi-function access link (the R1-S3 1954 10GE link has been already configured when the first EVPL service 1955 has been setup). 1957 As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation 1958 functions configurations in nodes S3 and S18, PNC1 and, 1959 respectively, PNC2 configure also the classification rules required 1960 to associated only the Ethernet client traffic received with VLAN ID 1961 20 on the R1-S3 and R8-S18 access links with this EVPL service. The 1962 MDSC provides this information to PNC1 and PNC2 using the 1963 [CLIENT-SIGNAL] model. 1965 5.3. YANG Models for Protection Configuration 1967 5.3.1. Linear Protection (end-to-end) 1969 As described in section 4.5.1, the MDSC can decide to protect a 1970 multi-domain connectivity service by setting up ODU linear 1971 protection switching between edge nodes controlled by different PNCs 1972 (e.g., nodes S3 and S8, controlled by PNC1 and PNC2 respectively, to 1973 protect services between R1 and R8). 1975 MDSC performs path computation, as described in section 5.2, to 1976 compute both the paths for working and protection transport 1977 entities: the computed paths can pass through these same PNC domains 1978 or through different transit PNC domains. 1980 Considering the case, described in section 4.5.1, where the working 1981 and protection transport entities pass through the same domain, MDSC 1982 would perform the same steps described in section 5.2 to setup the 1983 ODU Tunnel and to configure the steering of the client traffic 1984 between the access links and the ODU Tunnel. The only differences 1985 are in the configuration of the ODU Tunnels. 1987 MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment) 1988 Tunnel within the MPI1 OTN Abstract Topology (Figure 4), using the 1989 TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN 1990 technology-specific augmentations, defined in [OTN-TUNNEL], with one 1991 primary path and one secondary path with1+1 protection switching 1992 enabled: 1994 o Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a 1995 Head Segment Tunnel), as described in section 5.2.2; 1997 o The egress point for the working transport entity in indicated in 1998 the route-object-include-exclude list of the explicit-route- 1999 objects of the primary path, as described in section 5.2.2; 2001 o The protection switching end-point in indicated in the route- 2002 object-include-exclude list of the explicit-route-objects of the 2003 secondary path: 2005 o The first element references the TE-Node of the Source TTP 2006 (i.e., AN1 TE-Node); 2008 o The egress point for the protection transport entity in indicated 2009 in the route-object-include-exclude list of the explicit-route- 2010 objects of the secondary path: 2012 o The last two element reference respectively the inter-domain 2013 link terminating on AN1-6 LTP and the data plane resources 2014 (i.e., the list of timeslots and the TPN) used by the ODU2 2015 connection over that link. 2017 PNC1 knows, as described in the table in section 5.1.1, that the 2018 AN1-1 TTP, AN1-7 LTP and the AN1-6 LTP, within the MPI1 OTN Abstract 2019 Topology it exposes at MPI1, correspond to S3-1 TTP, S2-3 LTP and 2020 the S8-5 LTP, respectively, within its native topology. It also 2021 understands, from the route-object-include-exclude list of the 2022 explicit-route-objects of the secondary path configuration (whose 2023 last two elements represent an inter-domain link), that node S3 is 2024 the end-point of the protection group while the other end-point is 2025 outside of its control domain. 2027 PNC1 can performs path computation within its native topology and 2028 setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as 2029 configure the protection group in node S3. 2031 5.3.2. Segmented Protection 2033 Under specific policies, it is possible to deploy a segmented 2034 protection for multi-domain services. The configuration of the 2035 segmented protection can be divided into a few steps, considering 2036 the example in section 4.5.2, the following steps would be used. 2038 MDSC performs path computation, as described in section 5.2, to 2039 compute all the paths for working and protection transport entities, 2040 which pass through the same PNC domains and inter-domain links: the 2041 MDSC would perform the same steps described in section 5.2 to setup 2042 the ODU Tunnel and to configure the steering of the client traffic 2043 between the access links and the ODU Tunnel. The only differences 2044 are in the configuration of the ODU Tunnels. 2046 MDSC requests at the MPI1, PNC1 to setup an ODU2 (Head Segment) 2047 Tunnel within the MPI1 OTN Abstract Topology (Figure 4), using the 2048 TE Tunnel YANG model, defined in [TE-TUNNEL], with the OTN 2049 technology-specific augmentations, defined in [OTN-TUNNEL], with one 2050 primary path and one secondary path with 1+1 protection switching 2051 enabled: 2053 o Only the Source TTP (i.e., AN1-1 TTP) is specified (since it is a 2054 Head Segment Tunnel), as described in section 5.2.2; 2056 o The egress point (i.e., AN1-7 LTP) is indicated in the route- 2057 object-include-exclude list of the explicit-route-objects of the 2058 primary path, as described in section 5.2.2; 2060 o The protection switching end-points are indicated in the route- 2061 object-include-exclude list of the explicit-route-objects of the 2062 secondary path: 2064 o The first element references the TE-Node of the Source TTP 2065 (i.e., AN1 TE-Node); 2067 o The last element references the TE-Node of the egress point 2068 (i.e., AN1 TE-Node). 2070 As described in section 5.2.2, PNC1 knows that the AN1-1 TTP and the 2071 AN1-7 LTP, within the MPI1 OTN Abstract Topology it exposes at MPI1, 2072 correspond to S3-1 TTP and the S2-3 LTP, respectively, within its 2073 native topology. It also understands, from the route-object-include- 2074 exclude list of the explicit-route-objects of the secondary path 2075 configuration (whole last element represent an abstract node 2076 terminating the inter-domain link used for the primary path), that 2077 the protection group should be terminated in nodes S3 and S2. 2079 PNC1 will perform path computations using its native topology and 2080 setup the ODU connections in nodes S3, S1, S2, S4 and S8 as well as 2081 configure the protection group in nodes S3 and S2. 2083 Following similar requests from MDSC to setup ODU2 (Segment) 2084 Tunnels, with segment protection, within the OTN Abstract Topologies 2085 they expose. PNC3 then sets up ODU2 cross-connections on nodes S31, 2086 S32, S33 and S34 and segment protection between nodes S31 and D34. 2087 PNC2 sets up ODU2 cross-connections on nodes S15, S12, S17 and S18 2088 and segment protection between nodes S15 and S18. 2090 MDSC stitch the configuration above to form its internal view of the 2091 end-to-end tunnel with segmented protection. 2093 Given the configuration above, the protection capability has been 2094 deployed on the tunnels. The head-end node of each domain can do the 2095 switching once there is a failure on one the tunnel segment. For 2096 example, in Network domain 1, when there is a failure on the S1-S2 2097 lin, the head-end nodes S2 and S3 will automatically do the 2098 switching to S3-S4-S8-S2. This switching will be reported to the 2099 corresponding PNC (PNC1 in this example) and then MDSC. Other PNCs 2100 (PNC2 and PNC3 in this example) will not be aware of the failure and 2101 switching, nor do the nodes in Network domain 2 and 3. 2103 5.4. Notifications 2105 Notification mechanisms are required for the scenarios analyzed in 2106 this draft, as described in section 4.6. 2108 The notification mechanisms are protocol-dependent. It is assumed 2109 that the RESTCONF protocol, defined in [RFC8040], is used at the 2110 MPIs mentioned in this document. 2112 On the perspective of MPI, the MDSC is the client while the PNC is 2113 acting as the server of the notification. The essential event 2114 streams, subscription and processing rules after receiving 2115 notification can be found in section 6 of [RFC8040]. 2117 5.5. Path Computation with Constraints 2119 The path computation constraints that can be supported at the MPI 2120 using the IETF YANG models defined in [TE-TUNNEL] and [PATH- 2121 COMPUTE]. 2123 When there is a technology-specific network (e.g., OTN), the 2124 corresponding technology (e.g., OTN) model should also be used to 2125 specify the tunnel information on MPI, with the constraint included 2126 in TE Tunnel model. 2128 Further detailed analysis is outside the scope of this document 2130 6. Security Considerations 2132 This document analyses the applicability of the YANG models being 2133 defined by the IETF to support OTN single and multi-domain 2134 scenarios. 2136 When deploying ACTN functional components the securing of external 2137 interfaces and hardening of resource datastores, the protection of 2138 confidential information, and limiting the access of function, 2139 should all be carefully considered. Section 9 of [RFC8453] 2140 highlights that implementations should consider encrypting data that 2141 flows between key components, especially when they are implemented 2142 at remote node. Further discussion on securing the interface between 2143 the MDSC and PNCs via the MDSC-PNC Interface (MPI) is discussed in 2144 section 9.2 of [RFC8453]. 2146 The YANG modules highlighted in this document are designed to be 2147 accessed via network configuration protocols such as NETCONF 2148 [RFC6241] or RESTCONF [RFC8040]. When using NETCONF, utilizing a 2149 secure transport via Secure Shell (SSH) [RFC6242] is mandatory. If 2150 using RESTCONF, then secure transport via TLS [RFC8446] is 2151 mandatory. When using either NETCONF or RESTCONF, the use of Network 2152 Configuration Access Control Model (NACM) [RFC8341] may be used to 2153 restrict access to specific protocol operations and content. 2155 6.1. OTN Security 2157 Inherently OTN networks ensure privacy and security via hard 2158 partitioning of traffic onto dedicated circuits. The separation of 2159 network traffic makes it difficult to intercept data transferred 2160 between nodes over OTN-channelized links. 2162 In OTN the (General Communication Channel) GCC is used for OAM 2163 functions such as performance monitoring, fault detection, and 2164 signaling. The GCC control channel should be secured using a 2165 suitable mechanism. 2167 7. IANA Considerations 2169 This document requires no IANA actions. 2171 8. References 2173 8.1. Normative References 2175 [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and 2176 Restoration) Terminology for Generalized Multi-Protocol 2177 Label Switching (GMPLS)", RFC 4427, March 2006. 2179 [RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based 2180 Architecture", RFC4655, August 2006. 2182 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 2183 Information Exchange between Interconnected Traffic- 2184 Engineered Networks", BCP 206, RFC 7926, July 2016. 2186 [RFC8345] Clemm, A.,Medved, J. et al., "A Yang Data Model for 2187 Network Topologies", RFC8345, March 2018. 2189 [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction 2190 and Control of TE Networks (ACTN)", RFC8453, August 2018. 2192 [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for 2193 the optical transport network", June 2016. 2195 [ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic 2196 protection switching - Linear trail and subnetwork 2197 protection", May 2014. 2199 [ITU-T G.873.1] ITU-T Recommendation G.873.1 (10/17), "Optical 2200 transport network (OTN): Linear protection", October 2017. 2202 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 2203 draft-ietf-teas-yang-te-topo, work in progress. 2205 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical 2206 Transport Network Topology", draft-ietf-ccamp-otn-topo- 2207 yang, work in progress. 2209 [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer 2210 Topology", draft-zheng-ccamp-client-topo-yang, work in 2211 progress. 2213 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 2214 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 2215 te, work in progress. 2217 [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for 2218 requesting Path Computation", draft-ietf-teas-yang-path- 2219 computation, work in progress. 2221 [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft- 2222 ietf-ccamp-otn-tunnel-model, work in progress. 2224 [CLIENT-SIGNAL] Zheng, H. et al., "A YANG Data Model for Transport 2225 Network Client Signals", draft-ietf-ccamp-client-signal- 2226 yang, work in progress. 2228 8.2. Informative References 2230 [RFC6241] Enns, R. et al., "Network Configuration Protocol 2231 (NETCONF)", RFC 6241, June 2011. 2233 [RFC6242] Wasserman, W., "Using the NETCONF Protocol over Secure 2234 Shell (SSH)", RFC 6242, June 2011. 2236 [RFC6898] Li, D. et al., "Link Management Protocol Behavior 2237 Negotiation and Configuration Modifications", RFC 6898, 2238 March 2013. 2240 [RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January 2241 2017. 2243 [RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309, 2244 January 2018. 2246 [RFC8341] Bierman, A., Bjorklund, M., "Network Configuration Access 2247 Control Model", RFC 8341, March 2018. 2249 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 2250 Version 1.3", RFC 8446, August 2018. 2252 [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for 2253 Abstraction and Control of Traffic Engineered Networks", 2254 draft-zhang-teas-actn-yang, work in progress. 2256 [RFC-FOLD] Watsen, K. et al., "Handling Long Lines in Artwork in 2257 Internet-Drafts and RFCs", draft-ietf-netmod-artwork- 2258 folding, work in progress 2260 [TE-TUTORIAL] Bryskin, I. et al., "TE Topology and Tunnel Modeling 2261 for Transport Networks", draft-ietf-teas-te-topo-and- 2262 tunnel-modeling, work in progress 2264 [ONF TR-527] ONF Technical Recommendation TR-527, "Functional 2265 Requirements for Transport API", June 2016. 2267 [MEF 55] Metro Ethernet Forum, "Lifecycle Service Orchestration 2268 (LSO): Reference Architecture and Framework", Technical 2269 Specification MEF 55, March 2016, 2270 2273 9. Acknowledgments 2275 The authors would like to thank all members of the Transport NBI 2276 Design Team involved in the definition of use cases, gap analysis 2277 and guidelines for using the IETF YANG models at the Northbound 2278 Interface (NBI) of a Transport SDN Controller. 2280 The authors would like to thank Xian Zhang, Anurag Sharma, Sergio 2281 Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar 2282 Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated 2283 the work on gap analysis for transport NBI and having provided 2284 foundations work for the development of this document. 2286 The authors would like to thank the authors of the TE Topology and 2287 Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular, Igor 2288 Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their 2289 support in addressing any gap identified during the analysis work. 2291 The authors would like to thank Henry Yu and Aihua Guo for their 2292 input and review of the URIs structures used within the JSON code 2293 examples. 2295 This work was supported in part by the European Commission funded 2296 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). 2298 This document was prepared using 2-Word-v2.0.template.dot. 2300 Appendix A. Validating a JSON fragment against a YANG Model 2302 The objective is to have a tool that allows validating whether a 2303 piece of JSON code embedded in an Internet-Draft is compliant with a 2304 YANG model without using a client/server. 2306 A.1. Manipulation of JSON fragments 2308 This section describes the various ways JSON fragments are used in 2309 the I-D processing and how to manage them. 2311 Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 2312 72 chars width and it is acceptable for it to be invalid JSON. 2314 We then define "unfolded-JSON" a valid JSON fragment having the same 2315 contents of the "folded-JSON " without folding, i.e. limits on the 2316 text width. The folding/unfolding operation may be done according to 2317 [RFC-FOLD]. The "unfolded-JSON" can be edited by the authors using 2318 JSON editors with the advantages of syntax validation and pretty- 2319 printing. 2321 Both the "folded" and the "unfolded" JSON fragments can include 2322 comments having descriptive fields and directives we'll describe 2323 later to facilitate the reader and enable some automatic processing. 2325 The presence of comments in the "unfolded-JSON" fragment makes it an 2326 invalid JSON encoding of YANG data. Therefore we call "naked JSON" 2327 the JSON where the comments have been stripped out: not only it is 2328 valid JSON but it is a valid JSON encoding of YANG data. 2330 The following schema resumes these definitions: 2332 unfold_it --> stripper --> 2334 Folded-JSON Unfolded-JSON Naked JSON 2336 <-- fold_it <-- author edits 2338 <=72-chars? must may may 2340 valid JSON? may must must 2342 JSON-encoding 2343 of YANG data? may may must 2345 Our validation toolchain has been designed to take a JSON in any of 2346 the three formats and validate it automatically against a set of 2347 relevant YANG modules using available open-source tools. It can be 2348 found at: https://github.com/GianmarcoBruno/json-yang/ 2350 A.2. Comments in JSON fragments 2352 We found useful to introduce two kinds of comments, both defined as 2353 key-value pairs where the key starts with "//": 2355 - free-form descriptive comments, e.g."// COMMENT" : "refine this" 2356 to describe properties of JSON fragments. 2358 - machine-usable directives e.g. "// __REFERENCES__DRAFTS__" : { 2359 "ietf-routing-types@2017-12-04": "rfc8294",} which can be used to 2360 automatically download from the network the relevant I-Ds or RFCs 2361 and extract from them the YANG models of interest. This is 2362 particularly useful to keep consistency when the drafting work is 2363 rapidly evolving. 2365 A.3. Validation of JSON fragments: DSDL-based approach 2367 The idea is to generate a JSON driver file (JTOX) from YANG, then 2368 use it to translate JSON to XML and validate it against the DSDL 2369 schemas, as shown in Figure 8. 2371 Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson 2372 (2) 2373 YANG-module ---> DSDL-schemas (RNG,SCH,DSRL) 2374 | | 2375 | (1) | 2376 | | 2377 Config/state JTOX-file | (4) 2378 \ | | 2379 \ | | 2380 \ V V 2381 JSON-file------------> XML-file ----------------> Output 2382 (3) 2384 Figure 8 - DSDL-based approach for JSON code validation 2386 In order to allow the use of comments following the convention 2387 defined in section 3, without impacting the validation process, 2388 these comments will be automatically removed from the JSON-file that 2389 will be validate. 2391 A.4. Validation of JSON fragments: why not using an XSD-based approach 2393 This approach has been analyzed and discarded because no longer 2394 supported by pyang. 2396 The idea is to convert YANG to XSD, JSON to XML and validate it 2397 against the XSD, as shown in Figure 9: 2399 (1) 2400 YANG-module ---> XSD-schema - \ (3) 2401 +--> Validation 2402 JSON-file------> XML-file ----/ 2403 (2) 2405 Figure 9 - XSD-based approach for JSON code validation 2407 The pyang support for the XSD output format was deprecated in 1.5 2408 and removed in 1.7.1. However pyang 1.7.1 is necessary to work with 2409 YANG 1.1 so the process shown in Figure 9 will stop just at step 2410 (1). 2412 Appendix B. Detailed JSON Examples 2414 The JSON code examples provided in this appendix have been validated 2415 using the tools in Appendix A and folded using the tool in [RFC- 2416 FOLD]. 2418 B.1. JSON Examples for Topology Abstractions 2420 B.1.1. JSON Code: mpi1-otn-topology.json 2422 This is the JSON code reporting the OTN Topology @ MPI1: 2424 ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== 2426 { 2427 "// __LAST_UPDATE__": "October 21, 2019", 2428 "// __TITLE__": "ODU Black Topology @ MPI1", 2429 "// __REFERENCE_DRAFTS__": { 2430 "ietf-routing-types@2017-12-04": "rfc8294", 2431 "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", 2432 "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\ 2433 \2", 2434 "ietf-network@2018-02-26": "rfc8345", 2435 "ietf-network-topology@2018-02-26": "rfc8345", 2436 "ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22", 2437 "ietf-otn-topology@2019-07-07": "draft-ietf-ccamp-otn-topo-yang-\ 2438 \08" 2439 }, 2440 "// __MISSING_ATTRIBUTES__": true, 2441 "ietf-network:networks": { 2442 "network": [ 2443 { 2444 "network-id": "providerId/201/clientId/300/topologyId/otn-bl\ 2445 \ack-topology", 2446 "network-types": { 2447 "ietf-te-topology:te-topology": { 2448 "ietf-otn-topology:otn-topology": {} 2449 } 2450 }, 2451 "ietf-te-topology:te-topology-identifier": { 2452 "provider-id": 201, 2453 "client-id": 300, 2454 "topology-id": "otn-black-topology" 2455 }, 2456 "// __COMMENT__ ietf-te-topology:te": "presence container re\ 2457 \quires: provider-id, client-id and te-topology-id", 2458 "ietf-te-topology:te": { 2459 "name": "OTN Black Topology @ MPI1" 2460 }, 2461 "ietf-network:node": [ 2462 { 2463 "// __NODE__:__DESCRIPTION__": { 2464 "name": "AN1", 2465 "identifier": "10.0.0.1", 2466 "type": "Abstract Node", 2467 "physical node(s)": "The whole network domain 1" 2468 }, 2469 "node-id": "10.0.0.1", 2470 "ietf-te-topology:te-node-id": "10.0.0.1", 2471 "ietf-te-topology:te": { 2472 "te-node-attributes": { 2473 "name": "AN11", 2474 "is-abstract": "", 2475 "admin-status": "up" 2476 }, 2477 "oper-status": "up", 2478 "tunnel-termination-point": [ 2479 { 2480 "// __COMMENT__ tunnel-tp-id": "AN1-1 TTP-ID (1 ->\ 2481 \ 0x01 -> 'AQ==')", 2482 "tunnel-tp-id": "AQ==", 2483 "name": "AN1-1 OTN TTP", 2484 "// __COMMENT__ encoding and switching-capability"\ 2485 \: "OTN (ODU)", 2486 "switching-capability": "ietf-te-types:switching-o\ 2487 \tn", 2488 "encoding": "ietf-te-types:lsp-encoding-oduk", 2489 "// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\ 2490 \-ID (1) }", 2491 "inter-layer-lock-id": [ 2492 1 2493 ], 2494 "admin-status": "up", 2495 "oper-status": "up" 2496 }, 2497 { 2498 "// __COMMENT__ tunnel-tp-id": "AN1-2 TTP-ID (2 ->\ 2499 \ 0x02 -> 'Ag==')", 2500 "tunnel-tp-id": "Ag==", 2501 "name": "AN1-2 OTN TTP", 2502 "// __COMMENT__ encoding and switching-capability"\ 2503 \: "OTN (ODU)", 2504 "switching-capability": "ietf-te-types:switching-o\ 2505 \tn", 2506 "encoding": "ietf-te-types:lsp-encoding-oduk", 2507 "// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\ 2508 \-ID (2) }", 2509 "inter-layer-lock-id": [ 2510 2 2511 ], 2512 "admin-status": "up", 2513 "oper-status": "up" 2514 }, 2515 { 2516 "// __COMMENT__ tunnel-tp-id": "AN1-3 TTP-ID (3 ->\ 2517 \ 0x03 -> 'Awo=')", 2518 "tunnel-tp-id": "Awo=", 2519 "name": "AN1-3 OTN TTP", 2520 "// __COMMENT__ encoding and switching-capability"\ 2521 \: "OTN (ODU)", 2522 "switching-capability": "ietf-te-types:switching-o\ 2523 \tn", 2524 "encoding": "ietf-te-types:lsp-encoding-oduk", 2525 "// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\ 2526 \-ID (3) }", 2527 "inter-layer-lock-id": [ 2528 3 2529 ], 2530 "admin-status": "up", 2531 "oper-status": "up" 2532 }, 2533 { 2534 "// __COMMENT__ tunnel-tp-id": "AN1-8 TTP-ID (8 ->\ 2535 \ 0x08 -> 'CA==')", 2536 "tunnel-tp-id": "CA==", 2537 "name": "AN1-8 OTN TTP", 2538 "// __COMMENT__ encoding and switching-capability"\ 2539 \: "OTN (ODU)", 2540 "switching-capability": "ietf-te-types:switching-o\ 2541 \tn", 2542 "encoding": "ietf-te-types:lsp-encoding-oduk", 2543 "// __COMMENT__ inter-layer-lock-id": "{ AN1-8 ILL\ 2544 \-ID (1) }", 2545 "inter-layer-lock-id": [ 2546 8 2547 ], 2548 "admin-status": "up", 2549 "oper-status": "up" 2551 } 2552 ] 2553 }, 2554 "ietf-network-topology:termination-point": [ 2555 { 2556 "// __DESCRIPTION__:__LTP__": { 2557 "name": "AN1-1 LTP", 2558 "link type(s)": "Multi-function (OTU2, STM-64 and \ 2559 \10GE)", 2560 "physical node": "S3", 2561 "unnumberd/ifIndex": 1, 2562 "port type": "tributary port", 2563 "connected to": "R1" 2564 }, 2565 "tp-id": "1", 2566 "ietf-te-topology:te-tp-id": 1, 2567 "ietf-te-topology:te": { 2568 "name": "AN1-1 LTP", 2569 "interface-switching-capability": [ 2570 { 2571 "// __COMMENT__ encoding and switching-capabil\ 2572 \ity": "OTN (ODU)", 2573 "switching-capability": "ietf-te-types:switchi\ 2574 \ng-otn", 2575 "encoding": "ietf-te-types:lsp-encoding-oduk", 2576 "max-lsp-bandwidth": [ 2577 { 2578 "priority": 0, 2579 "te-bandwidth": { 2580 "ietf-otn-topology:odu-type": "ietf-laye\ 2581 \r1-types:ODU2" 2582 } 2583 } 2584 ] 2585 } 2586 ], 2587 "// __NOT-PRESENT__ inter-domain-plug-id": "Use of\ 2588 \ plug-id for access Link is outside the scope of this document", 2589 "// __COMMENT__ inter-layer-lock-id": "{ AN1-1 ILL\ 2590 \-ID (1) }", 2591 "inter-layer-lock-id": [ 2592 1 2593 ], 2594 "admin-status": "up", 2595 "oper-status": "up", 2596 "ietf-otn-topology:client-svc": { 2597 "client-facing": true, 2598 "supported-client-signal": [ 2599 "ietf-layer1-types:STM-64" 2600 ] 2601 } 2602 } 2603 }, 2604 { 2605 "// __DESCRIPTION__:__LTP__": { 2606 "name": "AN1-2 LTP", 2607 "link type(s)": "Multi-function (OTU2 and STM-64)", 2608 "physical node": "S6", 2609 "unnumberd/ifIndex": 2, 2610 "port type": "tributary port", 2611 "connected to": "R3" 2612 }, 2613 "tp-id": "2", 2614 "ietf-te-topology:te-tp-id": 2, 2615 "ietf-te-topology:te": { 2616 "name": "AN1-2 LTP", 2617 "interface-switching-capability": [ 2618 { 2619 "// __COMMENT__ encoding and switching-capabil\ 2620 \ity": "OTN (ODU)", 2621 "switching-capability": "ietf-te-types:switchi\ 2622 \ng-otn", 2623 "encoding": "ietf-te-types:lsp-encoding-oduk", 2624 "max-lsp-bandwidth": [ 2625 { 2626 "priority": 0, 2627 "te-bandwidth": { 2628 "ietf-otn-topology:odu-type": "ietf-laye\ 2629 \r1-types:ODU2" 2630 } 2631 } 2632 ] 2633 } 2634 ], 2635 "// __NOT-PRESENT__ inter-domain-plug-id": "Use of\ 2636 \ plug-id for access Link is outside the scope of this document", 2637 "// __COMMENT__ inter-layer-lock-id": "{ AN1-2 ILL\ 2638 \-ID (2) }", 2639 "inter-layer-lock-id": [ 2640 2 2641 ], 2642 "admin-status": "up", 2643 "oper-status": "up", 2644 "ietf-otn-topology:client-svc": { 2645 "client-facing": true, 2646 "supported-client-signal": [ 2647 "ietf-layer1-types:STM-64" 2648 ] 2649 } 2650 } 2651 }, 2652 { 2653 "// __DESCRIPTION__:__LTP__": { 2654 "name": "AN1-3 LTP", 2655 "link type(s)": "STM-64", 2656 "physical node": "S6", 2657 "unnumberd/ifIndex": 3, 2658 "port type": "tributary port", 2659 "connected to": "R4" 2660 }, 2661 "tp-id": "3", 2662 "ietf-te-topology:te-tp-id": 3, 2663 "ietf-te-topology:te": { 2664 "name": "AN1-3 LTP", 2665 "// __NOT-PRESENT__ interface-switching-capability\ 2666 \": "STM-64 Access Link only (no ODU switching)", 2667 "// __NOT-PRESENT__ inter-domain-plug-id": "Use of\ 2668 \ plug-id for access Link is outside the scope of this document", 2669 "// __COMMENT__ inter-layer-lock-id": "{ AN1-3 ILL\ 2670 \-ID (3) }", 2671 "inter-layer-lock-id": [ 2672 3 2673 ], 2674 "admin-status": "up", 2675 "oper-status": "up", 2676 "ietf-otn-topology:client-svc": { 2677 "client-facing": true, 2678 "supported-client-signal": [ 2679 "ietf-layer1-types:STM-64" 2680 ] 2681 } 2682 } 2684 }, 2685 { 2686 "// __DESCRIPTION__:__LTP__": { 2687 "name": "AN1-4 LTP", 2688 "link type(s)": "OTU4", 2689 "physical node": "S7", 2690 "unnumberd/ifIndex": 3, 2691 "port type": "inter-domain port", 2692 "connected to": "S11" 2693 }, 2694 "tp-id": "4", 2695 "ietf-te-topology:te-tp-id": 4, 2696 "ietf-te-topology:te": { 2697 "name": "AN1-4 LTP", 2698 "interface-switching-capability": [ 2699 { 2700 "// __COMMENT__ encoding and switching-capabil\ 2701 \ity": "OTN (ODU)", 2702 "switching-capability": "ietf-te-types:switchi\ 2703 \ng-otn", 2704 "encoding": "ietf-te-types:lsp-encoding-oduk", 2705 "max-lsp-bandwidth": [ 2706 { 2707 "priority": 0, 2708 "te-bandwidth": { 2709 "ietf-otn-topology:odu-type": "ietf-laye\ 2710 \r1-types:ODU4" 2711 } 2712 } 2713 ] 2714 } 2715 ], 2716 "// __COMMENT__ inter-domain-plug-id": "S7-S11 Plu\ 2717 \g-id (0x000711 -> AAcR)", 2718 "inter-domain-plug-id": "AAcR", 2719 "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ 2720 \ver Layer topology not exposed", 2721 "admin-status": "up", 2722 "oper-status": "up", 2723 "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ 2724 \ "OTN inter-domain link" 2725 } 2726 }, 2727 { 2728 "// __DESCRIPTION__:__LTP__": { 2729 "name": "AN1-5 LTP", 2730 "link type(s)": "OTU4", 2731 "physical node": "S8", 2732 "unnumberd/ifIndex": 4, 2733 "port type": "inter-domain port", 2734 "connected to": "S12" 2735 }, 2736 "tp-id": "5", 2737 "ietf-te-topology:te-tp-id": 5, 2738 "ietf-te-topology:te": { 2739 "name": "AN1-5 LTP", 2740 "interface-switching-capability": [ 2741 { 2742 "// __COMMENT__ encoding and switching-capabil\ 2743 \ity": "OTN (ODU)", 2744 "switching-capability": "ietf-te-types:switchi\ 2745 \ng-otn", 2746 "encoding": "ietf-te-types:lsp-encoding-oduk", 2747 "max-lsp-bandwidth": [ 2748 { 2749 "priority": 0, 2750 "te-bandwidth": { 2751 "ietf-otn-topology:odu-type": "ietf-laye\ 2752 \r1-types:ODU4" 2753 } 2754 } 2755 ] 2756 } 2757 ], 2758 "// __COMMENT__ inter-domain-plug-id": "S8.S12 Plu\ 2759 \g-id (0x000812 -> AAgS)", 2760 "inter-domain-plug-id": "AAgS", 2761 "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ 2762 \ver Layer topology not exposed", 2763 "admin-status": "up", 2764 "oper-status": "up", 2765 "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ 2766 \ "OTN inter-domain link" 2767 } 2768 }, 2769 { 2770 "// __DESCRIPTION__:__LTP__": { 2771 "name": "AN1-6 LTP", 2772 "link type(s)": "OTU4", 2773 "physical node": "S8", 2774 "unnumberd/ifIndex": 5, 2775 "port type": "inter-domain port", 2776 "connected to": "S32" 2777 }, 2778 "tp-id": "6", 2779 "ietf-te-topology:te-tp-id": 6, 2780 "ietf-te-topology:te": { 2781 "name": "AN1-6 LTP", 2782 "interface-switching-capability": [ 2783 { 2784 "// __COMMENT__ encoding and switching-capabil\ 2785 \ity": "OTN (ODU)", 2786 "switching-capability": "ietf-te-types:switchi\ 2787 \ng-otn", 2788 "encoding": "ietf-te-types:lsp-encoding-oduk", 2789 "max-lsp-bandwidth": [ 2790 { 2791 "priority": 0, 2792 "te-bandwidth": { 2793 "ietf-otn-topology:odu-type": "ietf-laye\ 2794 \r1-types:ODU4" 2795 } 2796 } 2797 ] 2798 } 2799 ], 2800 "// __COMMENT__ inter-domain-plug-id": "S8.S32 Plu\ 2801 \g-id (0x000832 -> AAgy)", 2802 "inter-domain-plug-id": "AAgy", 2803 "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ 2804 \ver Layer topology not exposed", 2805 "admin-status": "up", 2806 "oper-status": "up", 2807 "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ 2808 \ "OTN inter-domain link" 2809 } 2810 }, 2811 { 2812 "// __DESCRIPTION__:__LTP__": { 2813 "name": "AN1-7 LTP", 2814 "link type(s)": "OTU4", 2815 "physical node": "S2", 2816 "unnumberd/ifIndex": 3, 2817 "port type": "inter-domain port", 2818 "connected to": "S31" 2819 }, 2820 "tp-id": "7", 2821 "ietf-te-topology:te-tp-id": 7, 2822 "ietf-te-topology:te": { 2823 "name": "AN1-7 LTP", 2824 "interface-switching-capability": [ 2825 { 2826 "// __COMMENT__ encoding and switching-capabil\ 2827 \ity": "OTN (ODU)", 2828 "switching-capability": "ietf-te-types:switchi\ 2829 \ng-otn", 2830 "encoding": "ietf-te-types:lsp-encoding-oduk", 2831 "max-lsp-bandwidth": [ 2832 { 2833 "priority": 0, 2834 "te-bandwidth": { 2835 "ietf-otn-topology:odu-type": "ietf-laye\ 2836 \r1-types:ODU4" 2837 } 2838 } 2839 ] 2840 } 2841 ], 2842 "// __COMMENT__ inter-domain-plug-id": "S2-S31 Plu\ 2843 \g-id (0x000231 -> AAIx)", 2844 "inter-domain-plug-id": "AAIx", 2845 "// __NOT-PRESENT__ inter-layer-lock-id": "ODU Ser\ 2846 \ver Layer topology not exposed", 2847 "admin-status": "up", 2848 "oper-status": "up", 2849 "// __NOT-PRESENT__ ietf-otn-topology:client-svc":\ 2850 \ "OTN inter-domain link" 2851 } 2852 } 2853 ] 2854 } 2855 ], 2856 "ietf-network-topology:link": [ 2857 { 2858 "// __DESCRIPTION__:__LINK__": { 2859 "name": "Access Link from AN1-1", 2860 "type": "Multi-function access link (OTU2, STM-64 and \ 2861 \10GE)", 2862 "physical link": "Link from S3-1 to R1" 2863 }, 2864 "link-id": "teNodeId/10.0.0.1/teLinkId/1", 2865 "source": { 2866 "source-node": "10.0.0.1", 2867 "source-tp": 1 2868 }, 2869 "// __NOT-PRESENT__ destination": "access link", 2870 "ietf-te-topology:te": { 2871 "te-link-attributes": { 2872 "name": "Access Link from AN1-1", 2873 "// __NOT-PRESENT__ external-domain": "The plug-id i\ 2874 \s used instead of this container", 2875 "// __NOT-PRESENT__ is-abstract": "The access link i\ 2876 \s not abstract", 2877 "interface-switching-capability": [ 2878 { 2879 "// __COMMENT__ encoding and switching-capabilit\ 2880 \y": "OTN (ODU)", 2881 "switching-capability": "ietf-te-types:switching\ 2882 \-otn", 2883 "encoding": "ietf-te-types:lsp-encoding-oduk", 2884 "max-lsp-bandwidth": [ 2885 { 2886 "priority": 0, 2887 "te-bandwidth": { 2888 "ietf-otn-topology:odu-type": "ietf-layer1\ 2889 \-types:ODU2" 2890 } 2891 } 2892 ] 2893 } 2894 ], 2895 "// __COMMENT__ label-restrictions": "Outside the sc\ 2896 \ope of this JSON example", 2897 "max-link-bandwidth": { 2898 "te-bandwidth": { 2899 "ietf-otn-topology:odulist": [ 2900 { 2901 "odu-type": "ietf-layer1-types:ODU2", 2902 "number": 1 2903 } 2905 ] 2906 } 2907 }, 2908 "max-resv-link-bandwidth": { 2909 "te-bandwidth": { 2910 "ietf-otn-topology:odulist": [ 2911 { 2912 "odu-type": "ietf-layer1-types:ODU2", 2913 "number": 1 2914 } 2915 ] 2916 } 2917 }, 2918 "unreserved-bandwidth": [ 2919 { 2920 "priority": 0, 2921 "te-bandwidth": { 2922 "ietf-otn-topology:odulist": [ 2923 { 2924 "odu-type": "ietf-layer1-types:ODU2", 2925 "number": 1 2926 } 2927 ] 2928 } 2929 } 2930 ], 2931 "// __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \ 2932 \Link with no HO-ODU termination and LO-ODU switching", 2933 "admin-status": "up" 2934 }, 2935 "oper-status": "up", 2936 "// __NOT-PRESENT__ is-transitional": "It is not a tra\ 2937 \nsitional link" 2938 } 2939 }, 2940 { 2941 "// __DESCRIPTION__:__LINK__": { 2942 "name": "Access Link from AN1-2", 2943 "type": "Multi-function access link (OTU2 and STM-64)", 2944 "physical link": "Link from S6-2 to R3" 2945 }, 2946 "link-id": "teNodeId/10.0.0.1/teLinkId/2", 2947 "source": { 2948 "source-node": "10.0.0.1", 2949 "source-tp": 2 2950 }, 2951 "// __NOT-PRESENT__ destination": "access link", 2952 "ietf-te-topology:te": { 2953 "te-link-attributes": { 2954 "name": "Access Link from AN1-2", 2955 "// __NOT-PRESENT__ external-domain": "The plug-id i\ 2956 \s used instead of this container", 2957 "// __NOT-PRESENT__ is-abstract": "The access link i\ 2958 \s not abstract", 2959 "interface-switching-capability": [ 2960 { 2961 "// __COMMENT__ encoding and switching-capabilit\ 2962 \y": "OTN (ODU)", 2963 "switching-capability": "ietf-te-types:switching\ 2964 \-otn", 2965 "encoding": "ietf-te-types:lsp-encoding-oduk", 2966 "max-lsp-bandwidth": [ 2967 { 2968 "priority": 0, 2969 "te-bandwidth": { 2970 "ietf-otn-topology:odu-type": "ietf-layer1\ 2971 \-types:ODU2" 2972 } 2973 } 2974 ] 2975 } 2976 ], 2977 "// __COMMENT__ label-restrictions": "Outside the sc\ 2978 \ope of this JSON example", 2979 "max-link-bandwidth": { 2980 "te-bandwidth": { 2981 "ietf-otn-topology:odulist": [ 2982 { 2983 "odu-type": "ietf-layer1-types:ODU2", 2984 "number": 1 2985 } 2986 ] 2987 } 2988 }, 2989 "max-resv-link-bandwidth": { 2990 "te-bandwidth": { 2991 "ietf-otn-topology:odulist": [ 2992 { 2993 "odu-type": "ietf-layer1-types:ODU2", 2994 "number": 1 2995 } 2996 ] 2997 } 2998 }, 2999 "unreserved-bandwidth": [ 3000 { 3001 "priority": 0, 3002 "te-bandwidth": { 3003 "ietf-otn-topology:odulist": [ 3004 { 3005 "odu-type": "ietf-layer1-types:ODU2", 3006 "number": 1 3007 } 3008 ] 3009 } 3010 } 3011 ], 3012 "// __NOT-PRESENT__ ietf-otn-topology:tsg": "Access \ 3013 \Link with no HO-ODU termination and LO-ODU switching", 3014 "admin-status": "up" 3015 }, 3016 "oper-status": "up", 3017 "// __NOT-PRESENT__ is-transitional": "It is not a tra\ 3018 \nsitional link" 3019 } 3020 }, 3021 { 3022 "// __DESCRIPTION__:__LINK__": { 3023 "name": "Access Link from AN1-3", 3024 "type": "STM-64 Access link", 3025 "physical link": "Link from S6-3 to R4" 3026 }, 3027 "link-id": "teNodeId/10.0.0.1/teLinkId/3", 3028 "source": { 3029 "source-node": "10.0.0.1", 3030 "source-tp": 3 3031 }, 3032 "// __NOT-PRESENT__ destination": "access link", 3033 "ietf-te-topology:te": { 3034 "te-link-attributes": { 3035 "name": "Access Link from AN1-3", 3036 "// __NOT-PRESENT__ external-domain": "The plug-id i\ 3038 \s used instead of this container", 3039 "// __NOT-PRESENT__ is-abstract": "The access link i\ 3040 \s not abstract", 3041 "// __NOT-PRESENT__ interface-switching-capability":\ 3042 \ "STM-64 Access Link only (no ODU switching)", 3043 "// __NOT-PRESENT__ max-link-bandwidth": "STM-64 Acc\ 3044 \ess Link only (no ODU switching)", 3045 "// __NOT-PRESENT__ max-resv-link-bandwidth": "STM-6\ 3046 \4 Access Link only (no ODU switching)", 3047 "// __NOT-PRESENT__ unreserved-bandwidth": "STM-64 A\ 3048 \ccess Link only (no ODU switching)", 3049 "// __NOT-PRESENT__ ietf-otn-topology:tsg": "STM-64 \ 3050 \Access Link only (no HO-ODU termination and LO-ODU switching)", 3051 "admin-status": "up" 3052 }, 3053 "oper-status": "up", 3054 "// __NOT-PRESENT__ is-transitional": "It is not a tra\ 3055 \nsitional link" 3056 } 3057 }, 3058 { 3059 "// __DESCRIPTION__:__LINK__": { 3060 "name": "Inter-domain Link from AN1-4", 3061 "type": "OTU4 inter-domain link", 3062 "physical link": "Link from S7-3 to S11" 3063 }, 3064 "link-id": "teNodeId/10.0.0.1/teLinkId/4", 3065 "source": { 3066 "source-node": "10.0.0.1", 3067 "source-tp": 4 3068 }, 3069 "// __NOT-PRESENT__ destination": "inter-domain link", 3070 "ietf-te-topology:te": { 3071 "te-link-attributes": { 3072 "name": "Inter-domain Link from AN1-4", 3073 "// __NOT-PRESENT__ external-domain": "The plug-id i\ 3074 \s used instead of this container", 3075 "// __NOT-PRESENT__ is-abstract": "The access link i\ 3076 \s not abstract", 3077 "interface-switching-capability": [ 3078 { 3079 "// __COMMENT__ encoding and switching-capabilit\ 3080 \y": "OTN (ODU)", 3081 "switching-capability": "ietf-te-types:switching\ 3083 \-otn", 3084 "encoding": "ietf-te-types:lsp-encoding-oduk", 3085 "max-lsp-bandwidth": [ 3086 { 3087 "priority": 0, 3088 "te-bandwidth": { 3089 "ietf-otn-topology:odu-type": "ietf-layer1\ 3090 \-types:ODU4" 3091 } 3092 } 3093 ] 3094 } 3095 ], 3096 "// __COMMENT__ label-restrictions": "Outside the sc\ 3097 \ope of this JSON example", 3098 "max-link-bandwidth": { 3099 "te-bandwidth": { 3100 "ietf-otn-topology:odulist": [ 3101 { 3102 "odu-type": "ietf-layer1-types:ODU4", 3103 "number": 1 3104 }, 3105 { 3106 "odu-type": "ietf-layer1-types:ODU2", 3107 "number": 10 3108 }, 3109 { 3110 "odu-type": "ietf-layer1-types:ODU0", 3111 "number": 80 3112 } 3113 ] 3114 } 3115 }, 3116 "max-resv-link-bandwidth": { 3117 "te-bandwidth": { 3118 "ietf-otn-topology:odulist": [ 3119 { 3120 "odu-type": "ietf-layer1-types:ODU4", 3121 "number": 1 3122 }, 3123 { 3124 "odu-type": "ietf-layer1-types:ODU2", 3125 "number": 10 3126 }, 3127 { 3128 "odu-type": "ietf-layer1-types:ODU0", 3129 "number": 80 3130 } 3131 ] 3132 } 3133 }, 3134 "unreserved-bandwidth": [ 3135 { 3136 "priority": 0, 3137 "te-bandwidth": { 3138 "ietf-otn-topology:odulist": [ 3139 { 3140 "odu-type": "ietf-layer1-types:ODU4", 3141 "number": 1 3142 }, 3143 { 3144 "odu-type": "ietf-layer1-types:ODU2", 3145 "number": 10 3146 }, 3147 { 3148 "odu-type": "ietf-layer1-types:ODU0", 3149 "number": 80 3150 } 3151 ] 3152 } 3153 } 3154 ], 3155 "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ 3156 \G", 3157 "admin-status": "up" 3158 }, 3159 "oper-status": "up", 3160 "// __NOT-PRESENT__ is-transitional": "It is not a tra\ 3161 \nsitional link" 3162 } 3163 }, 3164 { 3165 "// __DESCRIPTION__:__LINK__": { 3166 "name": "Inter-domain Link from AN1-5", 3167 "type": "OTU4 inter-domain link", 3168 "physical link": "Link from S8-4 to S12" 3169 }, 3170 "link-id": "teNodeId/10.0.0.1/teLinkId/5", 3171 "source": { 3172 "source-node": "10.0.0.1", 3173 "source-tp": 5 3174 }, 3175 "// __NOT-PRESENT__ destination": "inter-domain link", 3176 "ietf-te-topology:te": { 3177 "te-link-attributes": { 3178 "name": "Inter-domain Link from AN1-5", 3179 "// __NOT-PRESENT__ external-domain": "The plug-id i\ 3180 \s used instead of this container", 3181 "// __NOT-PRESENT__ is-abstract": "The access link i\ 3182 \s not abstract", 3183 "interface-switching-capability": [ 3184 { 3185 "// __COMMENT__ encoding and switching-capabilit\ 3186 \y": "OTN (ODU)", 3187 "switching-capability": "ietf-te-types:switching\ 3188 \-otn", 3189 "encoding": "ietf-te-types:lsp-encoding-oduk", 3190 "max-lsp-bandwidth": [ 3191 { 3192 "priority": 0, 3193 "te-bandwidth": { 3194 "ietf-otn-topology:odu-type": "ietf-layer1\ 3195 \-types:ODU4" 3196 } 3197 } 3198 ] 3199 } 3200 ], 3201 "// __COMMENT__ label-restrictions": "Outside the sc\ 3202 \ope of this JSON example", 3203 "max-link-bandwidth": { 3204 "te-bandwidth": { 3205 "ietf-otn-topology:odulist": [ 3206 { 3207 "odu-type": "ietf-layer1-types:ODU4", 3208 "number": 1 3209 }, 3210 { 3211 "odu-type": "ietf-layer1-types:ODU2", 3212 "number": 10 3213 }, 3214 { 3215 "odu-type": "ietf-layer1-types:ODU0", 3216 "number": 80 3217 } 3218 ] 3219 } 3220 }, 3221 "max-resv-link-bandwidth": { 3222 "te-bandwidth": { 3223 "ietf-otn-topology:odulist": [ 3224 { 3225 "odu-type": "ietf-layer1-types:ODU4", 3226 "number": 1 3227 }, 3228 { 3229 "odu-type": "ietf-layer1-types:ODU2", 3230 "number": 10 3231 }, 3232 { 3233 "odu-type": "ietf-layer1-types:ODU0", 3234 "number": 80 3235 } 3236 ] 3237 } 3238 }, 3239 "unreserved-bandwidth": [ 3240 { 3241 "priority": 0, 3242 "te-bandwidth": { 3243 "ietf-otn-topology:odulist": [ 3244 { 3245 "odu-type": "ietf-layer1-types:ODU4", 3246 "number": 1 3247 }, 3248 { 3249 "odu-type": "ietf-layer1-types:ODU2", 3250 "number": 10 3251 }, 3252 { 3253 "odu-type": "ietf-layer1-types:ODU0", 3254 "number": 80 3255 } 3256 ] 3257 } 3258 } 3260 ], 3261 "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ 3262 \G", 3263 "admin-status": "up" 3264 }, 3265 "oper-status": "up", 3266 "// __NOT-PRESENT__ is-transitional": "It is not a tra\ 3267 \nsitional link" 3268 } 3269 }, 3270 { 3271 "// __DESCRIPTION__:__LINK__": { 3272 "name": "Inter-domain Link from AN1-6", 3273 "type": "OTU4 inter-domain link", 3274 "physical link": "Link from S8-5 to S32" 3275 }, 3276 "link-id": "teNodeId/10.0.0.1/teLinkId/6", 3277 "source": { 3278 "source-node": "10.0.0.1", 3279 "source-tp": 6 3280 }, 3281 "// __NOT-PRESENT__ destination": "inter-domain link", 3282 "ietf-te-topology:te": { 3283 "te-link-attributes": { 3284 "name": "Inter-domain Link from AN1-6", 3285 "// __NOT-PRESENT__ external-domain": "The plug-id i\ 3286 \s used instead of this container", 3287 "// __NOT-PRESENT__ is-abstract": "The access link i\ 3288 \s not abstract", 3289 "interface-switching-capability": [ 3290 { 3291 "// __COMMENT__ encoding and switching-capabilit\ 3292 \y": "OTN (ODU)", 3293 "switching-capability": "ietf-te-types:switching\ 3294 \-otn", 3295 "encoding": "ietf-te-types:lsp-encoding-oduk", 3296 "max-lsp-bandwidth": [ 3297 { 3298 "priority": 0, 3299 "te-bandwidth": { 3300 "ietf-otn-topology:odu-type": "ietf-layer1\ 3301 \-types:ODU4" 3302 } 3303 } 3305 ] 3306 } 3307 ], 3308 "// __COMMENT__ label-restrictions": "Outside the sc\ 3309 \ope of this JSON example", 3310 "max-link-bandwidth": { 3311 "te-bandwidth": { 3312 "ietf-otn-topology:odulist": [ 3313 { 3314 "odu-type": "ietf-layer1-types:ODU4", 3315 "number": 1 3316 }, 3317 { 3318 "odu-type": "ietf-layer1-types:ODU2", 3319 "number": 10 3320 }, 3321 { 3322 "odu-type": "ietf-layer1-types:ODU0", 3323 "number": 80 3324 } 3325 ] 3326 } 3327 }, 3328 "max-resv-link-bandwidth": { 3329 "te-bandwidth": { 3330 "ietf-otn-topology:odulist": [ 3331 { 3332 "odu-type": "ietf-layer1-types:ODU4", 3333 "number": 1 3334 }, 3335 { 3336 "odu-type": "ietf-layer1-types:ODU2", 3337 "number": 10 3338 }, 3339 { 3340 "odu-type": "ietf-layer1-types:ODU0", 3341 "number": 80 3342 } 3343 ] 3344 } 3345 }, 3346 "unreserved-bandwidth": [ 3347 { 3348 "priority": 0, 3349 "te-bandwidth": { 3350 "ietf-otn-topology:odulist": [ 3351 { 3352 "odu-type": "ietf-layer1-types:ODU4", 3353 "number": 1 3354 }, 3355 { 3356 "odu-type": "ietf-layer1-types:ODU2", 3357 "number": 10 3358 }, 3359 { 3360 "odu-type": "ietf-layer1-types:ODU0", 3361 "number": 80 3362 } 3363 ] 3364 } 3365 } 3366 ], 3367 "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ 3368 \G", 3369 "admin-status": "up" 3370 }, 3371 "oper-status": "up", 3372 "// __NOT-PRESENT__ is-transitional": "It is not a tra\ 3373 \nsitional link" 3374 } 3375 }, 3376 { 3377 "// __DESCRIPTION__:__LINK__": { 3378 "name": "Inter-domain Link from AN1-7", 3379 "type": "OTU4 inter-domain link", 3380 "physical link": "Link from S2-3 to S31" 3381 }, 3382 "link-id": "teNodeId/10.0.0.1teLinkId/7", 3383 "source": { 3384 "source-node": "10.0.0.1", 3385 "source-tp": 7 3386 }, 3387 "// __NOT-PRESENT__ destination": "inter-domain link", 3388 "ietf-te-topology:te": { 3389 "te-link-attributes": { 3390 "name": "Inter-domain Link from AN1-7", 3391 "// __NOT-PRESENT__ external-domain": "The plug-id i\ 3392 \s used instead of this container", 3393 "// __NOT-PRESENT__ is-abstract": "The access link i\ 3394 \s not abstract", 3395 "interface-switching-capability": [ 3396 { 3397 "// __COMMENT__ encoding and switching-capabilit\ 3398 \y": "OTN (ODU)", 3399 "switching-capability": "ietf-te-types:switching\ 3400 \-otn", 3401 "encoding": "ietf-te-types:lsp-encoding-oduk", 3402 "max-lsp-bandwidth": [ 3403 { 3404 "priority": 0, 3405 "te-bandwidth": { 3406 "ietf-otn-topology:odu-type": "ietf-layer1\ 3407 \-types:ODU4" 3408 } 3409 } 3410 ] 3411 } 3412 ], 3413 "// __COMMENT__ label-restrictions": "Outside the sc\ 3414 \ope of this JSON example", 3415 "max-link-bandwidth": { 3416 "te-bandwidth": { 3417 "ietf-otn-topology:odulist": [ 3418 { 3419 "odu-type": "ietf-layer1-types:ODU4", 3420 "number": 1 3421 }, 3422 { 3423 "odu-type": "ietf-layer1-types:ODU2", 3424 "number": 10 3425 }, 3426 { 3427 "odu-type": "ietf-layer1-types:ODU0", 3428 "number": 80 3429 } 3430 ] 3431 } 3432 }, 3433 "max-resv-link-bandwidth": { 3434 "te-bandwidth": { 3435 "ietf-otn-topology:odulist": [ 3436 { 3437 "odu-type": "ietf-layer1-types:ODU4", 3438 "number": 1 3439 }, 3440 { 3441 "odu-type": "ietf-layer1-types:ODU2", 3442 "number": 10 3443 }, 3444 { 3445 "odu-type": "ietf-layer1-types:ODU0", 3446 "number": 80 3447 } 3448 ] 3449 } 3450 }, 3451 "unreserved-bandwidth": [ 3452 { 3453 "priority": 0, 3454 "te-bandwidth": { 3455 "ietf-otn-topology:odulist": [ 3456 { 3457 "odu-type": "ietf-layer1-types:ODU4", 3458 "number": 1 3459 }, 3460 { 3461 "odu-type": "ietf-layer1-types:ODU2", 3462 "number": 10 3463 }, 3464 { 3465 "odu-type": "ietf-layer1-types:ODU0", 3466 "number": 80 3467 } 3468 ] 3469 } 3470 } 3471 ], 3472 "ietf-otn-topology:tsg": "ietf-layer1-types:tsg-1.25\ 3473 \G", 3474 "admin-status": "up" 3475 }, 3476 "oper-status": "up", 3477 "// __NOT-PRESENT__ is-transitional": "It is not a tra\ 3478 \nsitional link" 3479 } 3480 } 3482 ] 3483 } 3484 ] 3485 } 3486 } 3488 B.1.2. JSON Code: mpi1-eth-topology.json 3490 This is the JSON code reporting the ETH Topology @ MPI1: 3492 ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== 3494 { 3495 "// __LAST_UPDATE__": "October 16, 2019", 3496 "// __TITLE__": "ETH Black Topology @ MPI1", 3497 "// __REFERENCE_DRAFTS__": { 3498 "ietf-routing-types@2017-12-04": "rfc8294", 3499 "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", 3500 "ietf-network@2018-02-26": "rfc8345", 3501 "ietf-network-topology@2018-02-26": "rfc8345", 3502 "ietf-te-topology@2019-02-07": "draft-ietf-teas-yang-te-topo-22", 3503 "ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\ 3504 \l-yang-00", 3505 "ietf-eth-te-topology@2019-07-08": "draft-zheng-ccamp-client-top\ 3506 \o-yang-06" 3507 }, 3508 "// __MISSING_ATTRIBUTES__": true, 3509 "ietf-network:networks": { 3510 "network": [ 3511 { 3512 "network-id": "providerId/201/clientId/300/topologyId/eth-bl\ 3513 \ack-topology", 3514 "network-types": { 3515 "ietf-te-topology:te-topology": { 3516 "ietf-eth-te-topology:eth-tran-topology": {} 3517 } 3518 }, 3519 "ietf-te-topology:te-topology-identifier": { 3520 "provider-id": 201, 3521 "client-id": 300, 3522 "te-topology-id": "eth-black-topology" 3523 }, 3524 "// __COMMENT__ ietf-te-topology:te": "presence container re\ 3525 \quires: provider-id, client-id and te-topology-id", 3526 "ietf-te-topology:te": { 3527 "name": "ETH Black Topology @ MPI1" 3528 }, 3529 "ietf-network:node": [ 3530 { 3531 "// __NODE__:__DESCRIPTION__": { 3532 "name": "AN1", 3533 "identifier": "10.0.0.1", 3534 "type": "Abstract Node", 3535 "physical node(s)": "The whole network domain 1" 3536 }, 3537 "node-id": "10.0.0.1", 3538 "ietf-te-topology:te-node-id": "10.0.0.1", 3539 "// __COMMENT__ supporting-node": "Not used because topo\ 3540 \logy hierarchy is outside the scope of this JSON example", 3541 "ietf-te-topology:te": { 3542 "te-node-attributes": { 3543 "name": "AN11", 3544 "is-abstract": {}, 3545 "admin-status": "up" 3546 }, 3547 "oper-status": "up", 3548 "// __NOT-PRESENT__ tunnel-termination-point": "ETH Ac\ 3549 \cess Links only (no ETH TE switching)" 3550 }, 3551 "ietf-network-topology:termination-point": [ 3552 { 3553 "// __DESCRIPTION__:__LTP__": { 3554 "name": "AN1-1 LTP", 3555 "link type(s)": "Multi-function (OTU2, STM-64 and \ 3556 \10GE)", 3557 "physical node": "S3", 3558 "unnumberd/ifIndex": 1, 3559 "port type": "tributary port", 3560 "connected to": "R1" 3561 }, 3562 "tp-id": "1", 3563 "ietf-te-topology:te-tp-id": 1, 3564 "ietf-te-topology:te": { 3565 "name": "AN1-1 LTP", 3566 "// __NOT-PRESENT__ interface-switching-capability\ 3567 \": "ETH Access Link only (no ETH TE switching)", 3568 "// __COMMENT__ inter-domain-plug-id": "Use of plu\ 3569 \g-id for access Link is outside the scope of this document", 3570 "// __COMMENT__ inter-layer-lock-id": "AN1-1 ILL-I\ 3571 \D (1)", 3572 "inter-layer-lock-id": [ 3573 1 3574 ], 3575 "admin-status": "up", 3576 "oper-status": "up" 3577 }, 3578 "// __COMMENT__ ingress-bandwidth-profile": "Outside\ 3579 \ the scope of this JSON example", 3580 "ietf-eth-te-topology:eth-svc": { 3581 "client-facing": true, 3582 "supported-classification": { 3583 "port-classification": true, 3584 "vlan-classification": { 3585 "vlan-tag-classification": true, 3586 "outer-tag": { 3587 "supported-tag-types": [ 3588 "ietf-eth-tran-types:classify-c-vlan" 3589 ], 3590 "vlan-range": "1-4094" 3591 } 3592 } 3593 }, 3594 "supported-vlan-operations": { 3595 "transparent-vlan-operations": true 3596 } 3597 } 3598 }, 3599 { 3600 "// __DESCRIPTION__:__LTP__": { 3601 "name": "AN1-8 LTP", 3602 "link type(s)": "10GE", 3603 "physical node": "S6", 3604 "unnumberd/ifIndex": 1, 3605 "port type": "tributary port", 3606 "connected to": "R2" 3607 }, 3608 "tp-id": "8", 3609 "ietf-te-topology:te-tp-id": 8, 3610 "ietf-te-topology:te": { 3611 "name": "AN1-8 LTP", 3612 "// __COMMENT__ inter-layer-lock-id": "AN1-8 ILL-I\ 3613 \D (8)", 3614 "// __NOT-PRESENT__ interface-switching-capability\ 3615 \": "ETH Access Link only (no ETH TE switching)", 3616 "// __COMMENT__ inter-domain-plug-id": "Use of plu\ 3617 \g-id for access Link is outside the scope of this document", 3618 "inter-layer-lock-id": [ 3619 8 3620 ], 3621 "admin-status": "up", 3622 "oper-status": "up" 3623 }, 3624 "// __COMMENT__ ingress-bandwidth-profile": "Outside\ 3625 \ the scope of this JSON example", 3626 "ietf-eth-te-topology:eth-svc": { 3627 "client-facing": true, 3628 "supported-classification": { 3629 "port-classification": true, 3630 "vlan-classification": { 3631 "vlan-tag-classification": true, 3632 "outer-tag": { 3633 "supported-tag-types": [ 3634 "ietf-eth-tran-types:classify-c-vlan" 3635 ], 3636 "vlan-range": "1-4094" 3637 } 3638 } 3639 }, 3640 "supported-vlan-operations": { 3641 "transparent-vlan-operations": true 3642 } 3643 } 3644 } 3645 ] 3646 } 3647 ], 3648 "ietf-network-topology:link": [ 3649 { 3650 "// __DESCRIPTION__:__LINK__": { 3651 "name": "Access Link from AN1-1", 3652 "type": "Multi-function access link (OTU2, STM-64 and \ 3653 \10GE)", 3654 "physical link": "Link from S3-1 to R1" 3655 }, 3656 "link-id": "teNodeId/10.0.0.1/teLinkId/1", 3657 "source": { 3658 "source-node": "10.0.0.1", 3659 "source-tp": 1 3660 }, 3661 "// __NOT-PRESENT__ destination": "access link", 3662 "ietf-te-topology:te": { 3663 "te-link-attributes": { 3664 "name": "Access Link from AN1-1", 3665 "// __NOT-PRESENT__ external-domain": "The plug-id i\ 3666 \s used instead of this container", 3667 "// __NOT-PRESENT__ is-abstract": "The access link i\ 3668 \s not abstract", 3669 "// __NOT-PRESENT__ interface-switching-capability":\ 3670 \ "ETH Access Link only (no ETH TE switching)", 3671 "// __NOT-PRESENT__ label-restrictions": "ETH Access\ 3672 \ Link only (no ETH TE switching)", 3673 "// __NOT-PRESENT__ max-link-bandwidth": "ETH Access\ 3674 \ Link only (no ETH TE switching)", 3675 "// __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\ 3676 \ccess Link only (no ETH TE switching)", 3677 "// __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\ 3678 \ss Link only (no ETH TE switching)", 3679 "admin-status": "up" 3680 }, 3681 "oper-status": "up", 3682 "// __NOT-PRESENT__ is-transitional": "It is not a tra\ 3683 \nsitional link" 3684 } 3685 }, 3686 { 3687 "// __DESCRIPTION__:__LINK__": { 3688 "name": "Access Link from AN1-8", 3689 "type": "10GE access link", 3690 "physical link": "Link from S6-1 to R2" 3691 }, 3692 "link-id": "teNodeId/10.0.0.1/teLinkId/8", 3693 "source": { 3694 "source-node": "10.0.0.1", 3695 "source-tp": 8 3696 }, 3697 "// __NOT-PRESENT__ destination": "access link", 3698 "ietf-te-topology:te": { 3699 "te-link-attributes": { 3700 "name": "Access Link from AN1-8", 3701 "// __NOT-PRESENT__ external-domain": "The plug-id i\ 3703 \s used instead of this container", 3704 "// __NOT-PRESENT__ is-abstract": "The access link i\ 3705 \s not abstract", 3706 "// __NOT-PRESENT__ interface-switching-capability":\ 3707 \ "ETH Access Link only (no ETH TE switching)", 3708 "// __NOT-PRESENT__ label-restrictions": "ETH Access\ 3709 \ Link only (no ETH TE switching)", 3710 "// __NOT-PRESENT__ max-link-bandwidth": "ETH Access\ 3711 \ Link only (no ETH TE switching)", 3712 "// __NOT-PRESENT__ max-resv-link-bandwidth": "ETH A\ 3713 \ccess Link only (no ETH TE switching)", 3714 "// __NOT-PRESENT__ unreserved-bandwidth": "ETH Acce\ 3715 \ss Link only (no ETH TE switching)", 3716 "admin-status": "up" 3717 }, 3718 "oper-status": "up", 3719 "// __NOT-PRESENT__ is-transitional": "It is not a tra\ 3720 \nsitional link" 3721 } 3722 } 3723 ] 3724 } 3725 ] 3726 } 3727 } 3729 B.2. JSON Examples for Service Configuration 3731 B.2.1. JSON Code: mpi1-odu2-service-config.json 3733 This is the JSON code reporting the ODU2 transit service 3734 configuration @ MPI1: 3736 ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== 3738 { 3739 "// __LAST_UPDATE__": "October 23, 2019", 3740 "// __TITLE__": "ODU2 Service Configuration @ MPI1", 3741 "// __REFERENCE_DRAFTS__": { 3742 "ietf-routing-types@2017-12-04": "rfc8294", 3743 "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", 3744 "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\ 3745 \2", 3746 "ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21", 3747 "ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\ 3748 \-08" 3749 }, 3750 "// __MISSING_ATTRIBUTES__": true, 3751 "// __RESTCONF_OPERATION__": { 3752 "operation": "POST", 3753 "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels" 3754 }, 3755 "ietf-te:te": { 3756 "tunnels": { 3757 "tunnel": [ 3758 { 3759 "name": "mpi1-odu2-service", 3760 "// __COMMENT__ identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI\ 3761 \1", 3762 "identifier": 1, 3763 "description": "ODU2 Service implemented by ODU2 OTN Tunne\ 3764 \l Segment @ MPI1", 3765 "// __COMMENT__ encoding and switching-type": "OTN (ODU)", 3766 "encoding": "ietf-te-types:lsp-encoding-oduk", 3767 "switching-type": "ietf-te-types:switching-otn", 3768 "// __NOT-PRESENT__ source": "Transit tunnel segment", 3769 "// __NOT-PRESENT__ src-tp-id": "Transit tunnel segment", 3770 "// __NOT-PRESENT__ destination": "Transit tunnel segment", 3771 "// __NOT-PRESENT__ dst-tp-id": "Transit tunnel segment", 3772 "bidirectional": true, 3773 "// __ DEFAULT __ protection": { 3774 "// __ DEFAULT __ enable": false 3775 }, 3776 "// __ DEFAULT __ restoration": { 3777 "// __ DEFAULT __ enable": false 3778 }, 3779 "// __COMMENT__ te-topology-identifier": "ODU Black Topolo\ 3780 \gy @ MPI1", 3781 "te-topology-identifier": { 3782 "provider-id": 201, 3783 "client-id": 300, 3784 "topology-id": "otn-black-topology" 3785 }, 3786 "te-bandwidth": { 3787 "ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2" 3788 }, 3789 "provisioning-state": "ietf-te-types:tunnel-state-up", 3790 "p2p-primary-paths": { 3791 "p2p-primary-path": [ 3792 { 3793 "name": "mpi1-odu2-service-primary-path", 3794 "// __NOT-PRESENT__ te-bandwidth": "The tunnel bandw\ 3795 \idth is used", 3796 "explicit-route-objects-always": { 3797 "route-object-include-exclude": [ 3798 { 3799 "// __COMMENT__": "Tunnel hand-off OTU2 ingres\ 3800 \s interface (S3-1 -> AN1-1)", 3801 "index": 1, 3802 "explicit-route-usage": "ietf-te-types:route-i\ 3803 \nclude-object", 3804 "unnumbered-link-hop": { 3805 "// __COMMENT__ node-id": "AN1 NODE-ID", 3806 "node-id": "10.0.0.1", 3807 "// __COMMENT__ link-tp-id": "AN1-1 LTP", 3808 "link-tp-id": 1, 3809 "// __DEFAULT__ hop-type": "strict", 3810 "// __DEFAULT__ direction": "outgoing" 3811 } 3812 }, 3813 { 3814 "// __COMMENT__": "Tunnel hand-off ODU2 ingres\ 3815 \s label (ODU2 over OTU2) at S3-1 (AN1-1)", 3816 "index": 2, 3817 "explicit-route-usage": "ietf-te-types:route-i\ 3818 \nclude-object", 3819 "label-hop": { 3820 "te-label": { 3821 "ietf-otn-tunnel:tpn": 1, 3822 "// __NOT-PRESENT__ ietf-otn-tunnel:tsg": \ 3823 \"Not applicable for ODUk over OTUk", 3824 "// __NOT-PRESENT__ ietf-otn-tunnel:ts-lis\ 3825 \t": "Not applicable for ODUk over OTUk", 3826 "// __DEFAULT__ direction": "forward" 3827 } 3828 } 3829 }, 3830 { 3831 "// __COMMENT__": "Tunnel hand-off OTU4 egress\ 3832 \ interface (S2-3 -> AN1-7)", 3833 "index": 3, 3834 "explicit-route-usage": "ietf-te-types:route-i\ 3836 \nclude-object", 3837 "unnumbered-link-hop": { 3838 "// __COMMENT__ node-id": "AN1 Node", 3839 "node-id": "10.0.0.1", 3840 "// __COMMENT__ link-tp-id": "AN1-7 LTP", 3841 "link-tp-id": 7, 3842 "// __DEFAULT__ hop-type": "strict", 3843 "// __DEFAULT__ direction": "outgoing" 3844 } 3845 }, 3846 { 3847 "// __COMMENT__": "Tunnel hand-off ODU2 egress\ 3848 \ label (ODU2 over OTU4) at S2-3 (AN1-7)", 3849 "index": 4, 3850 "explicit-route-usage": "ietf-te-types:route-i\ 3851 \nclude-object", 3852 "label-hop": { 3853 "te-label": { 3854 "ietf-otn-tunnel:tpn": 1, 3855 "ietf-otn-tunnel:tsg": "ietf-layer1-types:\ 3856 \tsg-1.25G", 3857 "ietf-otn-tunnel:ts-list": "1-8", 3858 "// __DEFAULT__ direction": "forward" 3859 } 3860 } 3861 } 3862 ] 3863 } 3864 } 3865 ] 3866 } 3867 } 3868 ] 3869 } 3870 } 3871 } 3873 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json 3875 This is the JSON code reporting the ODU2 head tunnel segment 3876 configuration @ MPI1: 3878 ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== 3879 { 3880 "// __LAST_UPDATE__": "October 23, 2019", 3881 "// __TITLE__": "ODU2 Tunnel Configuration @ MPI1", 3882 "// __REFERENCE_DRAFTS__": { 3883 "ietf-routing-types@2017-12-04": "rfc8294", 3884 "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", 3885 "ietf-layer1-types@2019-09-09": "draft-ietf-ccamp-layer1-types-0\ 3886 \2", 3887 "ietf-te@2019-04-09": "draft-ietf-teas-yang-te-21", 3888 "ietf-otn-tunnel@2019-10-23": "draft-ietf-ccamp-otn-tunnel-model\ 3889 \-08" 3890 }, 3891 "// __MISSING_ATTRIBUTES__": true, 3892 "// __RESTCONF_OPERATION__": { 3893 "operation": "POST", 3894 "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te/tunnels" 3895 }, 3896 "ietf-te:te": { 3897 "tunnels": { 3898 "tunnel": [ 3899 { 3900 "name": "mpi1-odu2-tunnel", 3901 "// __COMMENT__ identifier": "ODU2-TUNNEL-ID @ MPI1", 3902 "identifier": 2, 3903 "description": "TNBI Example for an ODU2 Head Tunnel Segme\ 3904 \nt @ MPI1", 3905 "// __COMMENT__ encoding and switching-type": "OTN (ODU)", 3906 "encoding": "ietf-te-types:lsp-encoding-oduk", 3907 "switching-type": "ietf-te-types:switching-otn", 3908 "// __COMMENT__ source": "AN1 Node-ID", 3909 "source": "10.0.0.1", 3910 "// __COMMENT__ src-tp-id": "AN1-1 TTP-ID (1 -> 0x01 -> '0\ 3911 \1')", 3912 "src-tp-id": "01", 3913 "// __NOT-PRESENT__ destination": "Head tunnel segment", 3914 "// __NOT-PRESENT__ dst-tp-id": "Head tunnel segment", 3915 "bidirectional": true, 3916 "// __ DEFAULT __ protection": { 3917 "// __ DEFAULT __ enable": false 3918 }, 3919 "// __ DEFAULT __ restoration": { 3920 "// __ DEFAULT __ enable": false 3921 }, 3922 "// __COMMENT__ te-topology-identifier": "ODU Black Topolo\ 3924 \gy @ MPI1", 3925 "te-topology-identifier": { 3926 "provider-id": 201, 3927 "client-id": 300, 3928 "topology-id": "otn-black-topology" 3929 }, 3930 "te-bandwidth": { 3931 "ietf-otn-tunnel:odu-type": "ietf-layer1-types:ODU2" 3932 }, 3933 "provisioning-state": "ietf-te-types:tunnel-state-down", 3934 "p2p-primary-paths": { 3935 "p2p-primary-path": [ 3936 { 3937 "name": "mpi1-odu2-tunnel-primary-path", 3938 "// __NOT-PRESENT__ te-bandwidth": "The tunnel bandw\ 3939 \idth is used", 3940 "explicit-route-objects-always": { 3941 "route-object-include-exclude": [ 3942 { 3943 "// __COMMENT__": "Tunnel hand-off OTU4 egress\ 3944 \ interface (AN1-7 LTP)", 3945 "index": 1, 3946 "explicit-route-usage": "ietf-te-types:route-i\ 3947 \nclude-object", 3948 "unnumbered-link-hop": { 3949 "// __COMMENT__ node-id": "AN1 NODE-ID", 3950 "node-id": "10.0.0.1", 3951 "// __COMMENT__ link-tp-id": "AN1-7 LTP-ID", 3952 "link-tp-id": 7, 3953 "// __DEFAULT__ hop-type": "strict", 3954 "// __DEFAULT__ direction": "outgoing" 3955 } 3956 }, 3957 { 3958 "// __COMMENT__": "Tunnel hand-off ODU2 egress\ 3959 \ label (ODU2 over OTU4)", 3960 "index": 2, 3961 "explicit-route-usage": "ietf-te-types:route-i\ 3962 \nclude-object", 3963 "label-hop": { 3964 "te-label": { 3965 "ietf-otn-tunnel:tpn": 2, 3966 "ietf-otn-tunnel:tsg": "ietf-layer1-types:\ 3967 \tsg-1.25G", 3968 "ietf-otn-tunnel:ts-list": "9-16", 3969 "// __DEFAULT__ direction": "forward" 3970 } 3971 } 3972 } 3973 ] 3974 } 3975 } 3976 ] 3977 } 3978 } 3979 ] 3980 } 3981 } 3982 } 3984 B.2.3. JSON Code: mpi1-epl-service-config.json 3986 This is the JSON code reporting the EPL service configuration @ MPI: 3988 ========== NOTE: '\\' line wrapping per BCP XXX (RFC XXXX) ========== 3990 { 3991 "// __LAST_UPDATE__": "October 16, 2019", 3992 "// __TITLE__": "EPL Configuration @ MPI1", 3993 "// __REFERENCE_DRAFTS__": { 3994 "ietf-routing-types@2017-12-04": "rfc8294", 3995 "ietf-te-types@2019-07-05": "draft-ietf-teas-yang-te-types-10", 3996 "ietf-eth-tran-types@2019-03-27": "draft-ietf-ccamp-client-signa\ 3997 \l-yang-00", 3998 "ietf-eth-tran-service@2019-03-27": "draft-ietf-ccamp-client-sig\ 3999 \nal-yang-00" 4000 }, 4001 "// __MISSING_ATTRIBUTES__": true, 4002 "// __RESTCONF_OPERATION__": { 4003 "operation": "POST", 4004 "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-eth-tran-service\ 4005 \:etht-svc/etht-svc-instances" 4006 }, 4007 "ietf-eth-tran-service:etht-svc": { 4008 "etht-svc-instances": [ 4009 { 4010 "etht-svc-name": "mpi1-epl-service", 4011 "etht-svc-descr": "TNBI Example for an EPL over ODU2 Service\ 4013 \ @ MPI1", 4014 "// __DEFAULT__ etht-svc-type": "ietf-eth-tran-types:p2p-svc\ 4015 \", 4016 "// __COMMENT__ te-topology-identifier": "ETH Black Topology\ 4017 \ @ MPI1", 4018 "te-topology-identifier": { 4019 "provider-id": 201, 4020 "client-id": 300, 4021 "topology-id": "eth-black-topology" 4022 }, 4023 "etht-svc-end-points": [ 4024 { 4025 "// __COMMENT__": "10GE Service End-Point at the access \ 4026 \interface (S3-1 -> AN1-1)", 4027 "etht-svc-end-point-name": "mpi1-epl-an1-1-service-end-p\ 4028 \oint", 4029 "etht-svc-end-point-descr": "Ethernet Service End-Point \ 4030 \at S3-1 (AN1-1) access link", 4031 "etht-svc-access-points": [ 4032 { 4033 "// __COMMENT__": "10GE Service Access Point at the \ 4034 \access interface (S3-1 -> AN1-1)", 4035 "etht-svc-end-point-name": "mpi-epl-an1-1-service-ac\ 4036 \cess-point", 4037 "// __COMMENT__ access-node-id": "AN1 NODE-ID", 4038 "access-node-id": "10.0.0.1", 4039 "// __COMMENT__ access-ltp-id": "AN1-1 LTP-ID", 4040 "access-ltp-id": 1 4041 } 4042 ] 4043 } 4044 ], 4045 "service-classification-type": "ietf-eth-tran-types:port-cla\ 4046 \ssification", 4047 "// __COMMENT__ ingress-egress-bandwidth-profile": "Outside \ 4048 \the scope of this JSON example", 4049 "// __NOT-PRESENT__ vlan-operations": "Transparent VLAN oper\ 4050 \ations", 4051 "etht-svc-tunnels": [ 4052 { 4053 "// __COMMENT__ tunnel-name": "ODU2 Head Tunnel Segment \ 4054 \@ MPI1", 4055 "tunnel-name": "mpi1-odu2-tunnel" 4056 } 4058 ], 4059 "admin-status": "ietf-te-types:tunnel-admin-state-up" 4060 } 4061 ] 4062 } 4063 } 4064 Authors' Addresses 4066 Italo Busi (Editor) 4067 Huawei 4069 Email: italo.busi@huawei.com 4071 Daniel King (Editor) 4072 Old Dog Consulting 4074 Email: daniel@olddog.co.uk 4076 Haomian Zheng (Editor) 4077 Huawei 4079 Email: zhenghaomian@huawei.com 4081 Yunbin Xu (Editor) 4082 CAICT 4084 Email: xuyunbin@ritt.cn 4086 Yang Zhao 4087 China Mobile 4089 Email: zhaoyangyjy@chinamobile.com 4091 Sergio Belotti 4092 Nokia 4094 Email: sergio.belotti@nokia.com 4096 Gianmarco Bruno 4097 Ericsson 4099 Email: gianmarco.bruno@ericsson.com 4100 Young Lee 4101 Huawei 4103 Email: leeyoung@huawei.com 4105 Victor Lopez 4106 Telefonica 4108 Email: victor.lopezalvarez@telefonica.com 4110 Carlo Perocchio 4111 Ericsson 4113 Email: carlo.perocchio@ericsson.com 4115 Ricard Vilalta 4116 CTTC 4118 Email: ricard.vilalta@cttc.es 4120 Michael Scharf 4121 Hochschule Esslingen - University of Applied Sciences 4123 Email: michael.scharf@hs-esslingen.de 4125 Dieter Beller 4126 Nokia 4128 Email: dieter.beller@nokia.com