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