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