idnits 2.17.1 draft-ietf-ccamp-transport-nbi-app-statement-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 2017: '... <=72-chars? MUST MAY...' RFC 2119 keyword, line 2019: '... valid JSON? MAY MUST ...' RFC 2119 keyword, line 2021: '... JSON-encoding MAY MAY ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 12, 2019) is 1687 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5151' is defined on line 1912, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group I. Busi 2 Internet Draft Huawei 3 Intended status: Informational D. King 4 Old Dog Consulting 5 H. Zheng 6 Huawei 7 Y. Xu 8 CAICT 10 Expires: March 2020 September 12, 2019 12 Transport Northbound Interface Applicability Statement 13 draft-ietf-ccamp-transport-nbi-app-statement-06 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on March 12, 2020. 38 Copyright Notice 40 Copyright (c) 2019 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Abstract 55 Transport network domains, including Optical Transport Network (OTN) 56 and Wavelength Division Multiplexing (WDM) networks, are typically 57 deployed based on a single vendor or technology platforms. They are 58 often managed using proprietary interfaces to dedicated Element 59 Management Systems (EMS), Network Management Systems (NMS) and 60 increasingly Software Defined Network (SDN) controllers. 62 A well-defined open interface to each domain management system or 63 controller is required for network operators to facilitate control 64 automation and orchestrate end-to-end services across multi-domain 65 networks. These functions may be enabled using standardized data 66 models (e.g. YANG), and appropriate protocol (e.g., RESTCONF). 68 This document analyses the applicability of the YANG models being 69 defined by the IETF (Traffic Engineering Architecture and Signaling 70 (TEAS) and Common Control and Measurement Plane (CCAMP) WGs in 71 particular) to support OTN single and multi-domain scenarios. 73 Table of Contents 75 1. Introduction...................................................4 76 1.1. The scope of this document................................4 77 1.2. Assumptions...............................................5 78 2. Terminology....................................................6 79 3. Conventions used in this document..............................7 80 3.1. Topology and traffic flow processing......................7 81 3.2. JSON code.................................................8 83 4. Scenarios Description..........................................9 84 4.1. Reference Network.........................................9 85 4.2. Topology Abstractions....................................13 86 4.3. Service Configuration....................................15 87 4.3.1. ODU Transit.........................................16 88 4.3.2. EPL over ODU........................................17 89 4.3.3. Other OTN Clients Services..........................18 90 4.3.4. EVPL over ODU.......................................19 91 4.4. Multi-function Access Links..............................20 92 4.5. Protection and Restoration Configuration.................21 93 4.5.1. Linear Protection (end-to-end)......................21 94 4.5.2. Segmented Protection................................23 95 4.6. Notification.............................................23 96 4.7. Path Computation with Constraint.........................24 97 5. YANG Model Analysis...........................................24 98 5.1. YANG Models for Topology Abstraction.....................25 99 5.1.1. Domain 1 Black Topology Abstraction.................26 100 5.1.2. Domain 2 Black Topology Abstraction.................30 101 5.1.3. Domain 3 White Topology Abstraction.................31 102 5.1.4. Multi-domain Topology Merging.......................31 103 5.2. YANG Models for Service Configuration....................33 104 5.2.1. ODU Transit Service.................................36 105 5.2.1.1. Single Domain Example..........................38 106 5.2.2. EPL over ODU Service................................38 107 5.2.2.1. Single Domain Example..........................40 108 5.2.3. Other OTN Client Services...........................41 109 5.2.3.1. Single Domain Example..........................42 110 5.2.4. EVPL over ODU Service...............................42 111 5.3. YANG Models for Protection Configuration.................44 112 5.3.1. Linear Protection (end-to-end)......................44 113 5.4. Notifications............................................44 114 5.5. Path Computation with Constraints........................44 115 6. Security Considerations.......................................44 116 7. IANA Considerations...........................................45 117 8. References....................................................45 118 8.1. Normative References.....................................45 119 8.2. Informative References...................................46 120 9. Acknowledgments...............................................47 121 Appendix A. Validating a JSON fragment against a YANG Model...49 122 A.1. Manipulation of JSON fragments..........................49 123 A.2. Comments in JSON fragments..............................50 124 A.3. Validation of JSON fragments: DSDL-based approach.......50 125 A.4. Validation of JSON fragments: why not using a XSD-based 126 approach......................................................51 128 Appendix B. Detailed JSON Examples............................52 129 B.1. JSON Examples for Topology Abstractions.................52 130 B.1.1. JSON Code: mpi1-otn-topology.json.................52 131 B.2. JSON Examples for Service Configuration.................68 132 B.2.1. JSON Code: mpi1-odu2-service-config.json..........68 133 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json...........72 134 B.2.3. JSON Code: mpi1-epl-service-config.json...........72 136 1. Introduction 138 Transport of packet services are critical for a wide-range of 139 applications and services, including data center and LAN 140 interconnects, Internet service backhauling mobile backhaul and 141 enterprise Carrier Ethernet services. These services are typically 142 setup using stovepipe NMS and EMS platforms, often requiring 143 propriety management platforms and legacy management interfaces. A 144 clear goal of operators is to automate the setup of transport 145 services across multiple transport technology domains. 147 A common open interface (API) to each domain controller and or 148 management system is pre-requisite for network operators to control 149 multi-vendor and multi-domain networks and also enable service 150 provisioning coordination/automation. This can be achieved by using 151 standardized YANG models, used together with an appropriate protocol 152 (e.g., RESTCONF [RFC8040]). 154 This document analyses the applicability of the YANG models being 155 defined by IETF (Traffic Engineering Architecture and Signaling 156 (TEAS) and Common Control and Measurement Plane (CCAMP) WGs in 157 particular) to support Optical Transport Networks (OTN) single and 158 multi-domain scenarios. 160 1.1. The scope of this document 162 This document assumes a reference architecture, including 163 interfaces, based on the Abstraction and Control of Traffic- 164 Engineered Networks (ACTN), defined in [RFC8453]. 166 The focus of this document is on the MPI (interface between the 167 Multi Domain Service Coordinator (MDSC) and a Physical Network 168 Controller (PNC), controlling a transport network domain). 170 It is worth noting that the same MPI analyzed in this document could 171 be used between hierarchical MDSC controllers, as shown in Figure 4 172 of [RFC8453]. 174 Detailed analysis of the CMI (interface between the Customer Network 175 Controller (CNC) and the MDSC) as well as of the interface between 176 service and network orchestrators are outside the scope of this 177 document. However, some considerations and assumptions about the 178 information are described when needed. 180 The relationship between the current IETF YANG models and the type 181 of ACTN interfaces can be found in [ACTN-YANG]. Therefore, it 182 considers the TE Topology YANG model defined in [TE-TOPO], with the 183 OTN Topology augmentation defined in [OTN-TOPO] and the TE Tunnel 184 YANG model defined in [TE-TUNNEL], with the OTN Tunnel augmentation 185 defined in [OTN-TUNNEL]. It also considers the Ethernet Client 186 Topology augmentation defined in [CLIENT-TOPO] as well as the Client 187 Signal YANG models defined in [CLIENT-SIGNAL] for both Transparent 188 and Ethernet clients. 190 The ONF Technical Recommendations for Functional Requirements for 191 the transport API in [ONF TR-527] and the ONF transport API multi- 192 domain examples in [ONF GitHub] have been considered as input for 193 defining the reference scenarios analyzed in this document. 195 1.2. Assumptions 197 This document is making the following assumptions: 199 1. The MDSC can request, at the MPI, a PNC to setup a Transit Tunnel 200 Segment using the TE Tunnel YANG model: in this case, since the 201 endpoints of the E2E Tunnel are outside the domain controlled by 202 that PNC, the MDSC would not specify any source or destination TE 203 Tunnel Termination Point (TTP), i.e., it would leave empty the 204 source, destination, src-tp-id and dst-tp-id attributes of the TE 205 tunnel instance, and it would use the explicit-route-object (ERO) 206 or route-object-include-exclude list to specify the ingress and 207 egress links for each path of the Transit Tunnel Segment. 209 2. Each PNC provides to the MDSC, at the MPI, the list of available 210 timeslots on the inter-domain links using the TE Topology YANG 211 model and OTN Topology augmentation. The TE Topology YANG model 212 in [TE-TOPO] is being updated to report the label set 213 information. 215 See section 1.7 of [TE-TUTORIAL] for more details. 217 This document has made the following assumptions: 219 1. The topology information for the Ethernet Client access links is 220 modelled using the YANG model defined in [CLIENT-TOPO]; 222 2. The topology information for the OTN and Transparent Client 223 access links is modelled using the YANG model defined in [OTN- 224 TOPO]; 226 3. The mapping information for Ethernet and Transparent Client 227 signals are modelled using the YANG model defined in [CLIENT- 228 SIGNAL]. 230 Finally, the Network Elements (NEs) described in the scenarios used 231 in the document are using ODU switching. It is assumed that the ODU 232 links are pre-configured and using mechanisms such as WDM 233 wavelength, which are outside the scope of this document. 235 2. Terminology 237 Domain: A domain as defined by [RFC4655] is "any collection of 238 network elements within a common sphere of address management or 239 path computation responsibility". Specifically, within this 240 document we mean a part of an operator's network that is under 241 common management (i.e., under shared operational management using 242 the same instances of a tool and the same policies). Network 243 elements will often be grouped into domains based on technology 244 types, vendor profiles, and geographic proximity. 246 E-LINE: Ethernet Line 248 EPL: Ethernet Private Line 250 EVPL: Ethernet Virtual Private Line 252 OTN: Optical Transport Network 254 Service: A service in the context of this document can be considered 255 as some form of connectivity between customer sites across the 256 network operator's network [RFC8309]. 258 Service Model: As described in [RFC8309] it describes a service and 259 the parameters of the service in a portable way that can be used 260 uniformly and independent of the equipment and operating 261 environment. 263 UNI: User Network Interface 265 MDSC: Multi-Domain Service Coordinator 267 CNC: Customer Network Controller 269 PNC: Provisioning Network Controller 271 3. Conventions used in this document 273 3.1. Topology and traffic flow processing 275 The traffic flow between different nodes is specified as an ordered 276 list of nodes, separated with commas, indicating within the brackets 277 the processing within each node: 279 []{, []} 281 The order represents the order of traffic flow being forwarded 282 through the network. 284 The processing can be just switching at a given layer 285 "[(switching)]" or also having an adaptation of a client layer into 286 a server layer "[(client) -> server]" or [client -> (server)], 287 depending on whether the node is switching in the client or in the 288 server layer. 290 For example, the following traffic flow: 292 R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)], 293 R3 [ODU2 -> (PKT)] 295 Node R1 is switching at the packet (PKT) layer and mapping packets 296 into an ODU2 before transmission to node S3. Nodes S3, S5 and S6 are 297 switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which 298 then sends it to S6 which finally sends to R3. Node R3 terminates 299 the ODU2 from S6 before switching at the packet (PKT) layer. 301 The paths of working and protection transport entities are specified 302 as an ordered list of nodes, separated with commas: 304 {, } 306 The order represents the order of traffic flow being forwarded 307 through the network in the forward direction. In the case of 308 bidirectional paths, the forward and backward directions are 309 selected arbitrarily, but the convention is consistent between 310 working/protection path pairs, as well as across multiple domains. 312 3.2. JSON code 314 This document provides some detailed JSON code examples to describe 315 how the YANG models being developed by the IETF (TEAS and CCAMP WG 316 in particular) may be used. The scenario examples are provided using 317 JSON to facilitate readability. 319 Different objects need to have an identifier. The convention used to 320 create mnemonic identifiers is to use the object name (e.g., S3 for 321 node S3), followed by its type (e.g., NODE), separated by an "-", 322 followed by "-ID". For example, the mnemonic identifier for node S3 323 would be S3-NODE-ID. 325 The JSON language does not support the insertion of comments that 326 have been instead found to be useful when writing the examples. This 327 document will insert comments into the JSON code as JSON name/value 328 pair with the JSON name string starting with the "//" characters. 329 For example, when describing the example of a TE Topology instance 330 representing the ODU Abstract Topology exposed by the Transport PNC, 331 the following comment has been added to the JSON code: 333 "// comment": "ODU Abstract Topology @ MPI", 335 The JSON code examples provided in this document have been validated 336 against the YANG models following the validation process described 337 in Appendix A, which would not consider the comments. 339 In order to have successful validation of the examples, some 340 numbering scheme has been defined to assign identifiers to the 341 different entities which would pass the syntax checks. In that case, 342 to simplify the reading, another JSON name/value pair formatted as a 343 comment and using the mnemonic identifiers is also provided. For 344 example, the identifier of node S3 (S3-NODE-ID) has been assumed to 345 be "10.0.0.3" and would be shown in the JSON code example using the 346 two JSON name/value pair: 348 "// te-node-id": "S3-NODE-ID", 350 "te-node-id": "10.0.0.3", 352 The first JSON name/value pair will be automatically removed in the 353 first step of the validation process while the second JSON 354 name/value pair will be validated against the YANG model 355 definitions. 357 4. Scenarios Description 359 4.1. Reference Network 361 The physical topology of the reference network is shown in Figure 1. 362 It represents an OTN network composed of three transport network 363 domains which provide transport connectivity services to an IP 364 customer network through eight access links: 366 ........................ 367 ......... : : 368 : : Network domain 1 : ............. 369 Customer: : : : : 370 domain : : S1 -------+ : : Network : 371 : : / \ : : domain 3 : .......... 372 R1 ------- S3 ----- S4 \ : : : : 373 : : \ \ S2 --------+ : :Customer 374 : : \ \ | : : \ : : domain 375 : : S5 \ | : : \ : : 376 R2 ------+ / \ \ | : : S31 --------- R5 377 : : \ / \ \ | : : / \ : : 378 R3 ------- S6 ---- S7 ---- S8 ------ S32 S33 ------ R6 379 : : / | | : : / \ / : :....... 380 R4 ------+ | | : :/ S34 : : 381 : :..........|.......|...: / / : : 382 ........: | | /:.../.......: : 383 | | / / : 384 ...........|.......|..../..../... : 385 : | | / / : .............. 386 : Network | | / / : : 387 : domain 2 | | / / : :Customer 388 : S11 ---- S12 / : : domain 389 : / | \ / : : 390 : S13 S14 | S15 ------------- R7 391 : | \ / \ | \ : : 392 : | S16 \ | \ : : 393 : | / S17 -- S18 --------- R8 394 : | / \ / : : 395 : S19 ---- S20 ---- S21 ------------ R9 396 : : : 397 :...............................: :............. 399 Figure 1 - Reference network 401 This document assumes that all the transport network switching nodes 402 Si are capable of switching in the electrical domain (ODU switching) 403 and that all the Si-Sj OTN links within the transport network 404 (intra-domain or inter-domain) are 100G links while the access Ri-Sj 405 links are 10G links. 407 It is also assumed that, within the transport network, the 408 physical/optical interconnections supporting the Si-Sj OTN links (up 409 to the OTU4 trail), are pre-configured using mechanisms which are 410 outside the scope of this document and are not exposed at the MPIs 411 to the MDSC. 413 Different technologies can be used on the access links (e.g., 414 Ethernet, STM-N and OTU). Section 4.3 provides more details about 415 the different assumptions on the access links for different services 416 types and section 4.4 describes the control of access links which 417 can support different technology configuration (e.g., STM-64, 10GE 418 or OTU2) depending on the type of service being configured (multi- 419 function access links). 421 The transport domain control architecture, shown in Figure 2, 422 follows the ACTN architecture and framework document [RFC8453], and 423 functional components: 425 -------------- 426 | | 427 | CNC | 428 | | 429 -------------- 430 | 431 ....................|....................... CMI 432 | 433 ---------------- 434 | | 435 | MDSC | 436 | | 437 ---------------- 438 / | \ 439 / | \ 440 ............../.....|......\................ MPIs 441 / | \ 442 / ---------- \ 443 / | PNC2 | \ 444 / ---------- \ 445 ---------- | \ 446 | PNC1 | ----- \ 447 ---------- ( ) ---------- 448 | ( ) | PNC3 | 449 ----- ( Network ) ---------- 450 ( ) ( Domain 2 ) | 451 ( ) ( ) ----- 452 ( Network ) ( ) ( ) 453 ( Domain 1 ) ----- ( ) 454 ( ) ( Network ) 455 ( ) ( Domain 3 ) 456 ----- ( ) 457 ( ) 458 ----- 460 Figure 2 - Controlling Hierarchies 462 The ACTN framework facilitates the detachment of the network and 463 service control from the underlying technology. It helps the 464 customer define the network as desired by business needs. Therefore, 465 care must be taken to keep a minimal level of dependency on the CMI 466 (or no dependency at all) with respect to the network domain 467 technologies. The MPI instead requires some specialization according 468 to the domain technology. 470 The control interfaces within the scope of this document are the 471 three MPIs shown in Figure 2. 473 It is worth noting that the split of functionality at the MPI in the 474 ACTN architecture between the MDSC and the PNCs is 475 equivalent/analogous to the split of functionality which is assumed 476 for the ONF T-API interface when used between a multi-domain 477 controller and domain controllers, as described in the ONF T-API 478 multi-domain use cases [ONF TR-527], as well as at the MEF PRESTO 479 interface between the Service Orchestration Functionality (SOF) and 480 the Infrastructure Control and Management (ICM) in the MEF LSO 481 Architecture [MEF 55]. 483 This document does not make any assumption about the control 484 architecture of the customer IP network: in line with [RFC8453], the 485 CNC is just a functional component within the customer control 486 architecture which is capable of requesting, at the CMI, transport 487 connectivity between IP routers, when needed. 489 The CNC can request transport connectivity services between IP 490 routers which can be attached to different transport domains (e.g., 491 between R1 and R8 in Figure 1) or to the same transport domain 492 (e.g., between R1 and R3 in Figure 1). Since the CNC is not aware of 493 the transport network controlling hierarchy, the mechanisms used by 494 the CNC to request, at the CMI, transport connectivity services are 495 independent on whether the service request is single-domain or 496 multi-domain. 498 It is assumed that the CMI allows the CNC to provide all the 499 information that is required by the MDSC to understand the 500 connectivity service request and to decide the network 501 configurations to be requested, at the MPIs, to its underlying PNCs 502 to support the requested connectivity service. 504 When a single-domain service is requested by the CNC at the CMI 505 (e.g., between R1 and R3 in Figure 1), the MDSC can follow the same 506 procedures, described above for the multi-domain service, and decide 507 the network configuration to request only at the MPI of the PNC 508 controlling that domain (e.g., MPI1 of PNC1 in Figure 2). 510 4.2. Topology Abstractions 512 Abstraction provides a selective method for representing 513 connectivity information within a domain. There are multiple methods 514 to abstract a network topology. This document assumes the 515 abstraction method defined in [RFC7926]: 517 "Abstraction is the process of applying the policy to the 518 available TE information within a domain, to produce selective 519 information that represents the potential ability to connect 520 across the domain. Thus, abstraction does not necessarily offer 521 all possible connectivity options, but presents a general view of 522 potential connectivity according to the policies that determine 523 how the domain's administrator wants to allow the domain resources 524 to be used." 526 [RFC8453] Provides the context of topology abstraction in the ACTN 527 architecture and discusses a few alternatives for the abstraction 528 methods for both packet and optical networks. This is an important 529 consideration since the choice of the abstraction method impacts 530 protocol design and the information it carries. According to 531 [RFC8453], there are three types of topology: 533 o White topology: This is a case where the PNC provides the actual 534 network topology to the MDSC without any hiding or filtering. In 535 this case, the MDSC has the full knowledge of the underlying 536 network topology; 538 o Black topology: The entire domain network is abstracted as a 539 single virtual node with the access/egress links without 540 disclosing any node internal connectivity information; 542 o Grey topology: This abstraction level is between black topology 543 and white topology from a granularity point of view. This is an 544 abstraction of TE tunnels for all pairs of border nodes. We may 545 further differentiate from a perspective of how to abstract 546 internal TE resources between the pairs of border nodes: 548 - Grey topology type A: border nodes with TE links between them 549 in a full mesh fashion; 551 - Grey topology type B: border nodes with some internal 552 abstracted nodes and abstracted links. 554 Each PNC should provide the MDSC with a network topology 555 abstractions hiding the internal details of the physical domain 556 network topology controlled by the PNC and this abstraction is 557 independent of the abstractions provided by other PNCs. Therefore it 558 is possible that different PNCs provide different types of topology 559 abstractions and each MPI operates on the abstract topology 560 regardless of, and independently from, the type of abstraction 561 provided by the PNC. 563 To analyze how the MDSC can operate on abstract topologies 564 independently from the topology abstraction provided by each PNC 565 and, therefore, that different PNCs can provide different topology 566 abstractions, that the following examples are assumed: 568 o PNC1 and PNC2 provide black topology abstractions which expose at 569 MPI1, and MPI2 respectively, a single virtual node (representing 570 the whole network domain 1, and domain 2 respectively). 572 o PNC3 provides a white topology abstraction which exposes at MPI3 573 all the physical nodes and links within network domain 3. 575 The MDSC should be capable of stitching together the abstracted 576 topologies provided by each PNC to build its own view of the 577 multi-domain network topology. The process may require suitable 578 oversight, including administrative configuration and trust models, 579 a method of how to achieve this is out of scope for this document. 581 The MDSC can also provide topology abstraction of its own view of 582 the multi-domain network topology at its CMIs depending on the 583 customers' needs: it can provide different types of topology 584 abstractions at different CMIs. Analyzing the topology abstractions 585 provided by the MDSC to its CMIs is outside the scope of this 586 document. 588 4.3. Service Configuration 590 In the following scenarios, it is assumed that the CNC is capable of 591 requesting service connectivity from the MDSC to support IP routers 592 connectivity. 594 The type of services could depend on the type of physical links 595 (e.g. OTN link, ETH link or SDH link) between the routers and 596 transport network. 598 The control of different adaptations inside IP routers, Ri (PKT -> 599 foo) and Rj (foo -> PKT), are assumed to be performed by means that 600 are not under the control of, and not visible to, the MDSC nor to 601 the PNCs. Therefore, these mechanisms are outside the scope of this 602 document. 604 4.3.1. ODU Transit 606 The physical links interconnecting the IP routers and the transport 607 network can be 10G OTN links. 609 In this case, it is assumed that the physical/optical 610 interconnections below the ODU layer (up to the OTU2 trail) are 611 pre-configured using mechanisms which are outside the scope of this 612 document and not exposed at the MPIs between the PNCs and the MDSC. 614 For simplicity of the description, it is also assumed that these 615 interfaces are not channelized (i.e., they can only support one 616 ODU2). 618 To setup a 10Gb IP link between R1 and R8, an ODU2 end-to-end 619 connection needs to be created, passing through transport nodes S3, 620 S1, S2, S31, S33, S34, S15 and S18 which belong to different PNC 621 domains (multi-domain service request): 623 R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]), 624 S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)], 625 S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)] 627 The MDSC understands that it needs to establish an ODU2 transit 628 service between the access links on S3 and S18, which belong to 629 different PNC domains (multi-domain service request). It also 630 decides the network configurations to request, at the MPIs, to its 631 underlying PNCs, to coordinate the setup of a multi-domain ODU2 632 segment connection between the access links on S3 and S18. 634 To setup of a 10Gb IP link between R1 and R3, an ODU2 end-to-end 635 connection needs to be created, passing through transport nodes S3, 636 S5 and S6 which belong to the same PNC domain (single-domain service 637 request): 639 R1 [(PKT) -> ODU2], S3 [(ODU2)], S5 [(ODU2)], S6 [(ODU2)], 640 R3 [ODU2 -> (PKT)] 642 As described in section 4.1, the mechanisms used by the CNC at the 643 CMI are independent on whether the service request is single-domain 644 service or multi-domain. 646 The MDSC can understand that it needs to setup an ODU2 transit 647 service between the access links on S3 and S6, which belong to the 648 same PNC domain (single-domain service request) and it decides the 649 proper network configuration to request PNC1. 651 4.3.2. EPL over ODU 653 The physical links interconnecting the IP routers and the transport 654 network can be 10G Ethernet physical links (10GE). 656 In this case, it is assumed that the Ethernet physical interfaces 657 (up to the MAC layer) are pre-configured using mechanisms which are 658 outside the scope of this document and not exposed at the MPIs 659 between the PNCs and the MDSC. 661 To setup a 10Gb IP link between R1 and R8, an EPL service needs to 662 be created, supported by an ODU2 end-to-end connection, between 663 transport nodes S3 and S18, passing through transport nodes S1, S2, 664 S31, S33, S34 and S15, which belong to different PNC domains (multi- 665 domain service request): 667 R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)], 668 S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)], 669 S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)] 671 The MDSC understands that it needs to setup an EPL service between 672 the access links on S3 and S18, which belong to different PNC 673 domains (multi-domain service request). It also decides the network 674 configurations to request, at the MPIs, to its underlying PNCs, to 675 coordinate the setup of an end-to-end ODU2 connection between the 676 nodes S3 and S8, including the configuration of the adaptation 677 functions inside these edge nodes, such as S3 [ETH -> (ODU2)] and 678 S18 [(ODU2) -> ETH]. 680 To setup a 10Gb IP link between R1 and R2, an EPL service needs to 681 be created, supported by an ODU2 end-to-end connection between 682 transport nodes S3 and S6, passing through the transport node S5, 683 which belong to the same PNC domain (single-domain service request): 685 R1 [(PKT) -> ETH], S3 [ETH -> (PKT)] S5 [(ODU2)], 686 S6 [(ODU2) -> ETH], R2 [ETH -> (PKT)] 688 As described in section 4.1, the mechanisms used by the CNC at the 689 CMI are independent on whether the service request is single-domain 690 service or multi-domain. 692 Based on the assumption above, in this case, the MDSC can understand 693 that it needs to setup an EPL service between the access links on S3 694 and S6, which belong to the same PNC domain (single-domain service 695 request) and it decides the proper network configuration to request 696 PNC1. 698 4.3.3. Other OTN Clients Services 700 [ITU-T G.709] defines mappings of different Transparent Client 701 layers into ODU. Most of them are used to provide Private Line 702 services over an OTN transport network supporting a variety of types 703 of physical access links (e.g., Ethernet, SDH STM-N, Fibre Channel, 704 InfiniBand, etc.) interconnecting the IP routers and the transport 705 network. 707 In order to setup a 10Gb IP link between R1 and R8 using, with for 708 example SDH physical links between the IP routers and the transport 709 network, an STM-64 Private Line service needs to be created, 710 supported by an ODU2 end-to-end connection, between transport nodes 711 S3 and S18, passing through transport nodes S1, S2, S31, S33, S34 712 and S15, which belong to different PNC domains (multi-domain service 713 request): 715 R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S1 [(ODU2)], 716 S2 [(ODU2)], S31 [(ODU2)], S33 [(ODU2)], S34[(ODU2)], 717 S15 [(ODU2)], S18 [(ODU2) -> STM-64], R8 [STM-64 -> (PKT)] 719 As already described (section 4.1) CNC provides the essential 720 information to permit the MDSC to understand which type of service 721 is needed, in this case, an STM-64 Private Line service between the 722 access links on S3 and S8, and it also decides the network 723 configurations, including the configuration of the adaptation 724 functions inside these edge nodes, such as S3 [STM-64 -> (ODU2)] and 725 S18 [(ODU2) -> STM-64]. 727 To setup a 10Gb IP link between R1 and R3), an STM-64 Private Line 728 service needs to be created between R1 and R3 (single-domain service 729 request): 731 R1 [(PKT) -> STM-64], S3[STM-64 -> (ODU2)], S5 [(ODU2)], 732 S6 [(ODU2) -> STM-64], R3[STM-64 -> (PKT)] 734 As described in section 4.1, the mechanisms used by the CNC at the 735 CMI are independent on whether the service request is single-domain 736 service or multi-domain. 738 Based on the assumption above, in this case, the MDSC can understand 739 that it needs to setup an STM-64 Private Line service between the 740 access links on S3 and S6, which belong to the same PNC domain 741 (single-domain service request) and it decides the proper network 742 configuration to request PNC1. 744 4.3.4. EVPL over ODU 746 When the physical links interconnecting the IP routers and the 747 transport network are Ethernet physical links, it is also possible 748 that different Ethernet services (e.g., EVPL) can share the same 749 physical access link using different VLANs. 751 As described in section 4.3.2, it is assumed that the Ethernet 752 physical interfaces (up to the MAC layer) are pre-configured. 754 To setup two 1Gb IP links between R1 to R2 and between R1 and R8, 755 two EVPL services need to be created, supported by two ODU0 end-to- 756 end connections: 758 R1 [(PKT) -> VLAN], S3 [VLAN -> (ODU0)], S5 [(ODU0)], 759 S6 [(ODU0) -> VLAN], R2 [VLAN -> (PKT)] 761 R1 [(PKT) -> VLAN], S3[VLAN -> (ODU0)], S1 [(ODU0)], 762 S2 [(ODU0)], S31 [(ODU0)], S33 [(ODU0)], S34 [(ODU0)], 763 S15 [(ODU0)], S18 [(ODU0) -> VLAN], R8[VLAN -> (PKT)] 765 It is worth noting that the fist EVPL service is required between 766 access links which belong to the same PNC domain (single-domain 767 service request) while the second EVPL service is required between 768 access links which belong to different PNC domains (multi-domain 769 service request). 771 Since the two EVPL services are sharing the same Ethernet physical 772 link between R1 and S3, different VLAN IDs are associated with 773 different EVPL services: for example, VLAN IDs 10 and 20 774 respectively. 776 Based on the assumptions described in section 4.3.2, the CNC 777 requests at the CMI the MDSC to setup these EVPL services and the 778 MDSC understands the network configurations to request to the 779 underlying PNCs, as described in section 4.3.2. 781 4.4. Multi-function Access Links 783 Some physical links interconnecting the IP routers and the transport 784 network can be configured in different modes, e.g., as OTU2 trail or 785 STM-64 or 10GE physical links. 787 This configuration can be done a-priori by means which are outside 788 the scope of this document. In this case, these links will appear at 789 the MPI as links supporting only one mode (depending on the a-priori 790 configuration) and will be controlled at the MPI as discussed in 791 section 4.3: for example, a 10G multi-function access link can be 792 pre-configured as an OTU2 trail (section 4.3.1), a 10GE physical 793 link (section 4.3.2) or an STM-64 physical link (section 4.3.3). 795 It is also possible not to configure these links a-priori and let 796 the MDSC (or, in case of a single-domain service request, the PNC) 797 decide how to configure these links, based on the service 798 configuration. 800 For example, if the physical link between R1 and S3 is a 801 multi-functional access link while the physical links between R4 and 802 S6 and between R8 and S18 are STM-64 and 10GE physical links 803 respectively, it is possible to configure either an STM-64 Private 804 Line service between R1 and R4 or an EPL service between R1 and R8. 806 The traffic flow between R1 and R4 can be summarized as: 808 R1 [(PKT) -> STM-64], S3 [STM-64 -> (ODU2)], S5 [(ODU2)], 809 S6 [(ODU2) -> STM-64], R4 [STM-64 -> (PKT)] 811 The traffic flow between R1 and R8 can be summarized as: 813 R1 [(PKT) -> ETH], S3 [ETH -> (ODU2)], S1 [(ODU2)], 814 S2 [(ODU2)], S31 [(ODU2)), S33 [(ODU2)], S34 [(ODU2)], 815 S15 [(ODU2)], S18 [(ODU2) -> ETH], R8 [ETH -> (PKT)] 817 The CNC is capable to request at the CMI the setup either an STM-64 818 Private Line service, between R1 and R4, or an EPL service, between 819 R1 and R8. 821 The MDSC, based on the service being request, decides the network 822 configurations to request, at the MPIs, to its underlying PNCs, to 823 coordinate the setup of an end-to-end ODU2 connection, either 824 between nodes S3 and S6, or between nodes S3 and S18, including the 825 configuration of the adaptation functions on these edge nodes, and 826 in particular whether the multi-function access link between R1 and 827 S3 should operate as an STM-64 or as a 10GE physical link. 829 4.5. Protection and Restoration Configuration 831 Protection switching provides a pre-allocated survivability 832 mechanism, typically provided via linear protection methods and 833 would be configured to operate as 1+1 unidirectional (the most 834 common OTN protection method), 1+1 bidirectional or 1:n 835 bidirectional. This ensures fast and simple service survivability. 837 Restoration methods would provide the capability to reroute and 838 restore connectivity traffic around network faults, without the 839 network penalty imposed with dedicated 1+1 protection schemes. 841 This section describes only services which are protected with linear 842 protection. The description of services using dynamic restoration is 843 outside the scope of this document. 845 The MDSC needs to be capable of deciding the network configuration 846 to request different PNCs to coordinate the protection switching 847 configuration to support protected connectivity services described 848 in section 4.3. 850 Since in these service examples, switching within the transport 851 network domain is performed only in the OTN ODU layer. It may also 852 be assumed that protection switching within the transport network 853 domain is provided at the OTN ODU layer. 855 4.5.1. Linear Protection (end-to-end) 857 In order to protect the connectivity services described in section 858 4.3 from failures within the OTN multi-domain transport network, the 859 MDSC can decide to request its underlying PNCs to configure ODU2 860 linear protection between the access nodes (e.g., nodes S3 and S18 861 for the services setup between R1 and R8). 863 It is assumed that the OTN linear protection is configured to with 864 1+1 unidirectional protection switching type, as defined in [ITU-T 865 G.808.1] and [ITU-T G.873.1], as well as in [RFC4427]. 867 In these scenarios, a working transport entity and a protection 868 transport entity, as defined in [ITU-T G.808.1], (or a working LSP 869 and a protection LSP, as defined in [RFC4427]) should be configured 870 in the data plane. 872 Two cases can be considered: 874 o In one case, the working and protection transport entities pass 875 through the same PNC domains: 877 Working transport entity: S3, S1, S2, 878 S31, S33, S34, 879 S15, S18 881 Protection transport entity: S3, S4, S8, 882 S32, 883 S12, S17, S18 885 o In another case, the working and protection transport entities 886 can pass through different PNC domains: 888 Working transport entity: S3, S5, S7, 889 S11, S12, S17, S18 891 Protection transport entity: S3, S1, S2, 892 S31, S33, S34, 893 S15, S18 895 The PNCs should be capable to report to the MDSC which is the active 896 transport entity, as defined in [ITU-T G.808.1], in the data plane. 898 Given the fast dynamic of protection switching operations in the 899 data plane (50ms recovery time), this reporting is not expected to 900 be in real-time. 902 It is also worth noting that with unidirectional protection 903 switching, e.g., 1+1 unidirectional protection switching, the active 904 transport entity may be different in the two directions. 906 4.5.2. Segmented Protection 908 To protect the connectivity services defined in section 4.3 from 909 failures within the OTN multi-domain transport network, the MDSC can 910 decide to request its underlying PNCs to configure ODU2 linear 911 protection between the edge nodes of each domain. 913 For example, MDSC can request PNC1 to configure linear protection 914 between its edge nodes S3 and S2: 916 Working transport entity: S3, S1, S2 918 Protection transport entity: S3, S4, S8, S2 920 MDSC can also request PNC2 to configure linear protection between 921 its edge nodes S15 and S18: 923 Working transport entity: S15, S18 925 Protection transport entity: S15, S12, S17, S18 927 MDSC can also request PNC3 to configure linear protection between 928 its edge nodes S31 and S34: 930 Working transport entity: S31, S33, S34 932 Protection transport entity: S31, S32, S34 934 4.6. Notification 936 To realize the topology update, service update and restoration 937 function, following notification type should be supported: 939 1. Object create 941 2. Object delete 943 3. Object state change 945 4. Alarm 947 There are three types of topology abstraction type defined in 948 section 4.2, the notification should also be abstracted. The PNC and 949 MDSC should coordinate together to determine the notification 950 policy, such as when an intra-domain alarm occurred, the PNC may not 951 report the alarm but the service state change notification to the 952 MDSC. 954 4.7. Path Computation with Constraint 956 It is possible to define constraints to be taken into account during 957 path computation procedures (e.g., IRO/XRO). 959 For example, the CNC can request, at the CMI, an ODU transit 960 service, as described in section 4.3.1, between R1 and R8 with the 961 constraint to pass through the link from S2 to S31 (IRO), such that 962 a qualified path could be: 964 R1 [(PKT) -> ODU2], S3 [(ODU2]), S1 [(ODU2]), S2 [(ODU2]), 965 S31 [(ODU2)], S33 [(ODU2)], S34 [(ODU2)], 966 S15 [(ODU2)], S18 [(ODU2)], R8 [ODU2 -> (PKT)] 968 If the CNC instead requested to pass through the link from S8 to 969 S12, then the above path would not be qualified, while the following 970 would be: 972 R1 [(PKT) -> ODU2], S3[(ODU2]), S1 [(ODU2]), S2[(ODU2]), 973 S8 [(ODU2]), S12[(ODU2]), S15 [(ODU2]), S18[(ODU2]), R8 [ODU2 -> 974 (PKT)] 976 The mechanisms used by the CNC to provide path constraints at the 977 CMI are outside the scope of this document. It is assumed that the 978 MDSC can understand these constraints and take them into account in 979 its path computation procedures (which would decide at least which 980 domains and inter-domain links) and in the path constraints to 981 provide to its underlying PNCs, to be taken into account in the path 982 computation procedures implemented by the PNCs (with a more detailed 983 view of topology). 985 5. YANG Model Analysis 987 This section analyses how the IETF YANG models can be used at the 988 MPIs, between the MDSC and the PNCs, to support the scenarios 989 described in section 4. 991 The YANG models described in [ACTN-YANG] are assumed to be used at 992 the MPI. 994 Section 5.1 describes the different topology abstractions provided 995 to the MDSC by each PNC via its own MPI. 997 Section 5.2 describes how the MDSC can request different PNCs, via 998 their own MPIs, the network configuration needed to setup the 999 different services described in section 4.3. 1001 Section 5.3 describes how the protection scenarios can be deployed, 1002 including end-to-end protection and segment protection, for both 1003 intra-domain and inter-domain scenario. 1005 5.1. YANG Models for Topology Abstraction 1007 Each PNC reports its respective OTN abstract topology to the MDSC, 1008 as described in section 4.2, using the Topology YANG models, defined 1009 in [RFC8345], with the TE Topology YANG augmentations, provided in 1010 [TE-TOPO], and the OTN technology-specific YANG augmentations, 1011 defined in [OTN-TOPO]. 1013 The [OTN-TOPO] model allows reporting within the OTN abstract 1014 topology also the access links which are capable of supporting the 1015 transparent client layers, defined in section 4.3.3 and in 1016 [CLIENT-SIGNAL]. These links can also be multi-function access links 1017 that can be configured as a transparent client physical links (e.g., 1018 STM-64 physical link) as an OTUk trail. 1020 In order to support the EPL and EVPL services, described in sections 1021 4.3.2 and 4.3.4, the access links, which are capable to be 1022 configured as Ethernet physical links, are reported by each PNC 1023 within its respective Ethernet abstract topology, using the Topology 1024 YANG models, defined in [RFC8345], with the TE Topology YANG 1025 augmentations, defined in [TE-TOPO], and the Ethernet client 1026 technology-specific YANG augmentations, defined in [CLIENT-TOPO]. 1027 These links can also be multi-function access links that can be 1028 configured as an Ethernet physical link or as an OTUk trail and/or 1029 as transparent client physical links (e.g., STM-64 physical link). 1030 In this case, these physical access links are represented in both 1031 the OTN and Ethernet abstract topologies. 1033 It is worth noting that in the network scenarios analyzed in this 1034 document (where switching is performed only in the ODU layer), the 1035 Ethernet abstract topologies reported by the PNCs describes only the 1036 Ethernet client access links: no Ethernet TE switching capabilities 1037 are reported in these Ethernet abstract topologies. 1039 5.1.1. Domain 1 Black Topology Abstraction 1041 PNC1 provides the required black topology abstraction, as described 1042 in section 4.2. It exposes at MPI1 to the MDSC, two TE Topology 1043 instances with only one TE node each. 1045 The first TE Topology instance reports the domain 1 OTN abstract 1046 topology view (MPI1 OTN Topology), using the OTN technology-specific 1047 augmentations [OTN-TOPO], with only one abstract TE node (i.e., AN1) 1048 and only inter-domain and access abstract TE links (which represent 1049 the inter-domain physical links and the access physical links which 1050 can support ODU and/or transparent client layers), as shown in 1051 Figure 3 below. 1053 ................................... 1054 : : 1055 : +-----------------+ : 1056 : | | : 1057 (R1)- - --------| |-------- - -(S31) 1058 : AN1-1 | | AN1-7 : 1059 : | | : 1060 (R3)- - --------| | : 1061 : AN1-2 | AN1 | : 1062 : | | : 1063 (R4)- - --------| |-------- - -(S32) 1064 : AN1-3 | | AN1-6 : 1065 : | | : 1066 : +-----------------+ : 1067 : | | : 1068 : AN1-4 | | AN1-5 : 1069 :..........|..........|...........: 1071 | | 1072 (S11) (S12) 1074 Figure 3 - OTN Abstract Topology exposed at MPI1 (MPI1 OTN Topology) 1076 The second TE Topology instance reports the domain 1 Ethernet 1077 abstract topology view (MPI1 ETH Topology), using the Ethernet 1078 technology-specific augmentations [CLIENT-TOPO], with only one 1079 abstract TE node (i.e., AN1) and only access abstract TE links 1080 (which represent the access physical links which can support 1081 Ethernet client layers), as shown in Figure 4 below. 1083 ................................... 1084 : : 1085 : +-----------------+ : 1086 : | | : 1087 (R1)- - --------| | : 1088 : AN1-1 | | : 1089 : | | : 1090 (R2)- - --------| | : 1091 : AN1-8 | AN1 | : 1092 : | | : 1093 : | | : 1094 : | | : 1095 : | | : 1096 : +-----------------+ : 1097 : : 1098 :.................................: 1100 Figure 4 - ETH Abstract Topology exposed at MPI1 (MPI1 ETH Topology) 1102 As described in section 4.1, it is assumed that the OTU4 trails on 1103 the inter-domain physical links (e.g., the link between S2 and S31) 1104 are pre-configured and exposed as external TE Links, within the MPI1 1105 OTN topology (e.g., the external TE Link terminating on AN1-7 TE 1106 Link Termination Point (LTP) abstracting the OTU4 trail between S2 1107 and S31). 1109 In order to analyze the service scenarios of sections 4.3 and 4.4: 1111 o the access link between S3 and R1 is assumed to be a 1112 multi-function access link, which can be configured as an OTU2 1113 trail or as an STM-64 or a 10GE physical link; 1115 o the access link between S6 and R2 is assumed to be pre-configured 1116 as a 10GE physical link, up to the MAC layer; 1118 o the access link between S6 and R3 is assumed to be a 1119 multi-function access link which can be configured as an OTU2 1120 trail or as an STM-64 physical link; 1122 o the access link connected to router R4 is assumed to be 1123 pre-configured as an STM-64 physical link. 1125 Therefore PNC1 exports at MPI1 the following external TE Links, 1126 within the MPI1 OTN topology: 1128 o two abstract TE Links, terminating on LTP AN1-1 and AN1-2 1129 respectively, abstracting the physical access link between S3 and 1130 R1 and the access link between S6 and R3 respectively, reporting 1131 that they can support STM-64 client signals as well as ODU2 1132 connections; 1134 o one abstract TE Link, terminating on LTP AN1-3, abstracting the 1135 physical access link between S6 and R4, reporting that it can 1136 support STM-64 client signals but no ODU2 connections. 1138 The information about the 10GE access link between S6 and R2 as well 1139 as the fact that the access link between S3 and R1 can also be 1140 configured as a 10GE link cannot be exposed by PNC1 within the MPI1 1141 OTN topology. 1143 Therefore, PNC1 exports at MPI1, within the MPI1 ETH topology, two 1144 abstract TE Links, terminating on LTP AN1-1 and AN1-8 respectively, 1145 abstracting the physical access link between S3 and R1 and the 1146 access link between S6 and R2 respectively, reporting that they can 1147 support Ethernet client signal with port-based and VLAN-based 1148 classifications. The PNC1 native topology would represent the 1149 physical network topology of the domain controlled by the PNC, as 1150 shown in Figure 5. 1152 .................................. 1153 : : 1154 : Physical Topology @ PNC1 : 1155 : : 1156 : +----+ +----+ : 1157 : | |S1-1 | |S2-3: 1158 : | S1 |--------| S2 |----- - -(S31) 1159 : +----+ S2-1+----+ : 1160 : S1-2/ |S2-2 : 1161 : S3-4/ | : 1162 : +----+ +----+ | : 1163 : | |3 1| | | : 1164 (R1)- - -----| S3 |---| S4 | | : 1165 :S3-1+----+ +----+ | : 1166 : S3-2 \ \S4-2 | : 1167 : \S5-1 \ | : 1168 : +----+ \ | : 1169 : | | \S8-2| : 1170 : | S5 | \ | : 1171 : +----+ \ |S8-1 : 1172 (R2)- - ------ 2/ \3 \ | : 1173 :S6-1 \ /5 \1 \| : 1174 : +----+ +----+ +----+ : 1175 : | | | | | |S8-5: 1176 (R3)- - -----| S6 |---| S7 |---| S8 |----- - -(S32) 1177 :S6-2+----+4 2+----+4 3+----+ : 1178 : / | | : 1179 (R3)- - ------ S7-3 | | S8-4 : 1180 :S6-3 | | : 1181 :...............|........|.......: 1183 | | 1184 (S11) (S12) 1186 Figure 5 - Physical Topology controlled by PNC1 1188 The PNC1 native topology is not exposed and therefore it under PNC 1189 responsibility to abstract the whole domain physical topology as a 1190 single TE node and to maintain a mapping between the LTPs exposed at 1191 MPI abstract topologies and the associated physical interfaces 1192 controlled by the PNC: 1194 Physical Interface OTN Topology LTP ETH Topology LTP 1195 (Figure 5) (Figure 3) (Figure 4) 1196 S2-3 AN1-7 1197 S3-1 AN1-1 AN1-1 1198 S6-1 AN1-8 1199 S6-2 AN1-2 1200 S6-3 AN1-3 1201 S7-3 AN1-4 1202 S8-4 AN1-5 1203 S8-5 AN1-6 1205 Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn- 1206 topology.json") describing how the MPI1 ODU Topology is reported by 1207 the PNC1, using the [RFC8345], [TE-TOPO] and [OTN-TOPO] YANG models, 1208 at MPI1. 1210 It is worth noting that this JSON code example does not provide all 1211 the attributes defined in the relevant YANG models, including: 1213 o YANG attributes which are outside the scope of this document are 1214 not shown; 1216 o The attributes describing the set of label values that are 1217 available at the inter-domain links (label-restriction container) 1218 are also not shown to simplify the JSON code example; 1220 o The comments describing the rationale for not including some 1221 attributes in this JSON code example even if in the scope of this 1222 document are identified with the prefix "// __COMMENT" and 1223 included only in the first object instance (e.g., in the Access 1224 Link from the AN1-1 description or in the AN1-1 LTP description). 1226 5.1.2. Domain 2 Black Topology Abstraction 1228 PNC2 provides the required black topology abstraction, as described 1229 in section 4.2, to expose to the MDSC, at MPI2, two TE Topology 1230 instances with only one TE node each: 1232 o the first instance reports the domain 2 OTN abstract topology 1233 view (MPI2 OTN Topology), with only one abstract node (i.e., AN2) 1234 and only inter-domain and access abstract TE links (which 1235 represent the inter-domain physical links and the access physical 1236 links which can support ODU and/or transparent client layers); 1238 o the instance reports the domain 2 Ethernet abstract topology view 1239 (MPI2 ETH Topology), with only one abstract TE node (i.e., AN2) 1240 and only access abstract TE links (which represent the access 1241 physical links which can support Ethernet client layers). 1243 5.1.3. Domain 3 White Topology Abstraction 1245 PNC3 provides the required white topology abstraction, as described 1246 in section 4.2, to expose to the MDSC, at MPI3, two TE Topology 1247 instances with multiple TE nodes, one for each physical node: 1249 o the first instance reports the domain 3 OTN topology view (MPI3 1250 OTN Topology), with four TE nodes, which represent the four 1251 physical nodes (i.e. S31, S32, S33 and S34), and abstract TE 1252 links, which represent the inter-domain and internal physical 1253 links; 1255 o the second instance reports the domain 3 Ethernet abstract 1256 topology view (MPI3 ETH Topology), with only two TE nodes, which 1257 represent the two edge physical nodes (i.e., S31 and S33) and 1258 only the two access TE links which represent the access physical 1259 links. 1261 5.1.4. Multi-domain Topology Merging 1263 As assumed at the beginning of this section, MDSC does not have any 1264 knowledge of the topologies of each domain until each PNC reports 1265 its own abstract topologies, so the MDSC needs to merge together 1266 these abstract topologies, provided by different PNCs, to build its 1267 own topology view of the multi-domain network (MDSC multi-domain 1268 native topology), as described in section 4.3 of [TE-TOPO]. 1270 Given the topologies reported from multiple PNCs, the MDSC need to 1271 merge them into its multi-domain native topology. The topology of 1272 each domain may be in an abstracted shape (refer to section 5.2 of 1273 [RFC8453] for a different level of abstraction), while the inter- 1274 domain link information must be complete and fully configured by the 1275 MDSC. 1277 The inter-domain link information is reported to the MDSC by the two 1278 PNCs, controlling the two ends of the inter-domain link. 1280 The MDSC needs to understand how to merge together these inter- 1281 domain links. 1283 One possibility is to use the plug-id information, defined in [TE- 1284 TOPO]: two inter-domain TE links, within two different MPI abstract 1285 topologies, terminating on two LTPs reporting the same plug-id value 1286 can be merged as a single intra-domain link, within any MDSC native 1287 topology. 1289 The value of the reported plug-id information can be either assigned 1290 by a central network authority, and configured within the two PNC 1291 domains. Alternatively, it may be discovered using an automatic 1292 discovery mechanisms (e.g., LMP-based, as defined in [RFC6898]). 1294 In case the plug-id values are assigned by a central authority, it 1295 is under the central authority responsibility to assign unique 1296 values. 1298 In case the plug-id values are automatically discovered, the 1299 information discovered by the automatic discovery mechanisms needs 1300 to be encoded as a bit string within the plug-id value. This 1301 encoding is implementation specific, but the encoding rules need to 1302 be consistent across all the PNCs. 1304 In case of co-existence within the same network of multiple sources 1305 for the plug-id (e.g., central authority and automatic discovery or 1306 even different automatic discovery mechanisms), it is needed that 1307 the plug-id namespace is partitioned to avoid that different sources 1308 assign the same plug-id value to different inter-domain links. Also, 1309 the encoding of the plug-id namespace within the plug-id value is 1310 implementation specific and will need to be consistent across all 1311 the PNCs. 1313 This document assumes that the plug-id is assigned by a central 1314 authority, with the first octet set to 0x00 to represent the central 1315 authority namespace. The configuration method used, within each PNC 1316 domain, are outside the scope of this document. 1318 Based on the plug-id values, the MDSC can merge together the 1319 abstract topologies exposed by the underlying PNCs, as described in 1320 sections 5.1.1, 5.1.2 and 5.1.3 above, into its multi-domain native 1321 TE topology as shown in Figure 6. 1323 ........................ 1324 : : 1325 : Network domain 1 : ............. 1326 : Black Topology : : : 1327 : Abstraction : : Network : 1328 : AN1-1 : : domain 3 : 1329 (R1)- - ----------+ : : (White) : 1330 : \ +--------------+ : 1331 (R2)- - ---------+ + / : : \ : 1332 : \| / : : \ : 1333 (R3)- - --------- AN1 --+ : : S31 ---- - (R5) 1334 : /|\ \ : : / \ : : 1335 (R4)- - ---------+ | \ +--------- S32 S33 - - (R6) 1336 : | \ : :/ \ / : 1337 : | +---+ : / S34 : 1338 :..........|.......|...: /: / : 1339 | | / :../........: 1340 | | / / 1341 ...........|.......|.../..../.... 1342 : | | / / : 1343 : Network | + / / : 1344 : domain 2 | / / / : 1345 : | / / / : 1346 : | + / +--+ : 1347 : | |/ / : 1348 : Black +--- AN2 ------------- - -(R7) 1349 : Topology | | AN2-1 : 1350 : Abstraction | +-------------- - -(R8) 1351 : | : 1352 : +---------------- - -(R9) 1353 : : 1354 :...............................: 1356 Figure 6 - Multi-domain Abstract Topology controlled by an MDSC 1358 5.2. YANG Models for Service Configuration 1360 The service configuration procedure is assumed to be initiated (step 1361 1 in Figure 7) at the CMI from CNC to MDSC. Analysis of the CMI 1362 models is (e.g., L1CSM, L2SM, VN) is outside the scope of this 1363 document. 1365 As described in section 4.3, it is assumed that the CMI YANG models 1366 provide all the information that allows the MDSC to understand that 1367 it needs to coordinate the setup of a multi-domain ODU data plane 1368 connection (which can be either an end-to-end connection or a 1369 segment connection) and, when needed, also the configuration of the 1370 adaptation functions in the edge nodes belonging to different 1371 domains. 1373 | 1374 | {1} 1375 V 1376 ---------------- 1377 | {2} | 1378 | {3} MDSC | 1379 | | 1380 ---------------- 1381 ^ ^ ^ 1382 {3.1} | | | 1383 +---------+ |{3.2} | 1384 | | +----------+ 1385 | V | 1386 | ---------- |{3.3} 1387 | | PNC2 | | 1388 | ---------- | 1389 | ^ | 1390 V | {4.2} | 1391 ---------- V | 1392 | PNC1 | ----- V 1393 ---------- (Network) ---------- 1394 ^ ( Domain 2) | PNC3 | 1395 | {4.1} ( _) ---------- 1396 V ( ) ^ 1397 ----- C==========D | {4.3} 1398 (Network) / ( ) \ V 1399 ( Domain 1) / ----- \ ----- 1400 ( )/ \ (Network) 1401 A===========B \ ( Domain 3) 1402 / ( ) \( ) 1403 AP-1 ( ) X===========Z 1404 ----- ( ) \ 1405 ( ) AP-2 1406 ----- 1408 Figure 7 - Multi-domain Service Setup 1410 As an example, the objective in this section is to configure a 1411 transport service between R1 and R8, such as one of the services 1412 described in section 4.3. The inter-domain path is assumed to be R1 1413 <-> S3 <-> S1 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 <-> R8 1414 (see the physical topology in Figure 1). 1416 According to the different client signal types, different 1417 adaptations can be required to be configured at the edge nodes 1418 (i.e., S3 and S18). 1420 After receiving such request, MDSC determines the domain sequence, 1421 i.e., domain 1 <-> domain 3 <-> domain 2, with corresponding PNCs 1422 and the inter-domain links (step 2 in Figure 7). 1424 As described in [PATH-COMPUTE], the domain sequence can be 1425 determined by running the MDSC own path computation on the MDSC 1426 native topology, defined in section 5.1.4, if and only if the MDSC 1427 has enough topology information. Otherwise, the MDSC can send path 1428 computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 1429 in Figure 7) and use this information to determine the optimal path 1430 on its internal topology and therefore the domain sequence. 1432 The MDSC will then decompose the tunnel request into a few tunnel 1433 segments via tunnel models (both technology agnostic TE tunnel model 1434 and OTN tunnel model), and request different PNCs to setup each 1435 intra-domain tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 7). 1437 The MDSC will take care of the configuration of both the intra- 1438 domain tunnel segment and inter-domain tunnel via corresponding MPI 1439 (via TE tunnel model and OTN tunnel model) through all the PNCs 1440 controlling the domains selected during path computation. More 1441 specifically, for the inter-domain tunnel hand-off, taking into 1442 account that the inter-domain links are all OTN links, the list of 1443 timeslots and the TPN value assigned to that ODUk connection at the 1444 inter-domain link needs to be configured by the MDSC. 1446 In any case, the access link configuration is done only on the PNCs 1447 that control the access links (e.g., PNC-1 and PNC-3) and not on the 1448 PNCs of transit domain(s) (e.g., PNC-2). An access link will be 1449 configured by MDSC after the OTN tunnel is set up. 1451 Access configuration will vary and will be dependent on each type of 1452 service. Further discussion and examples are provided in the 1453 following sub-sections. 1455 5.2.1. ODU Transit Service 1457 In this scenario, described in section 4.3.1, the physical access 1458 links are configured as 10G OTN links and, as described in section 1459 5.1, reported by each PNC as TE Links within the OTN abstract 1460 topologies they expose to the MDSC. 1462 To setup this IP link, between R1 and R8, the CNC requests, at the 1463 CMI, the MDSC to setup an ODU transit service. 1465 From its native topology, shown in Figure 6, the MDSC understands, 1466 by means which are outside the scope of this document, that R1 is 1467 attached to the access link terminating on AN1-1 LTP in the MPI1 OTN 1468 Abstract Topology (Figure 3), exposed by PNC1, and that R8 is 1469 attached to the access link terminating on AN2-1 LTP in the MPI2 1470 Abstract Topology, exposed by PNC2. 1472 MDSC then performs multi-domain path computation (step 2 in Figure 1473 7) and requests PNC1, PNC2 and PNC3, at MPI1, MPI2 and MPI3 1474 respectively, to setup ODU2 (Transit Segment) Tunnels within the OTN 1475 Abstract Topologies they expose (MPI1 OTN Abstract Topology, MPI2 1476 OTN Abstract Topology and MPI3 OTN Abstract Topology, respectively). 1478 MDSC requests, at MPI1, PNC1 to setup an ODU2 (Transit Segment) 1479 Tunnel with one primary path between AN-1 and AN1-7 LTPs, within the 1480 MPI1 OTN Abstract Topology (Figure 4), using the TE Tunnel YANG 1481 model, defined in [TE-TUNNEL], with the OTN technology-specific 1482 augmentations, defined in [OTN-TUNNEL]: 1484 o Source and Destination TTPs are not specified (since it is a 1485 Transit Tunnel) 1487 o Ingress and egress points are indicated in the route-object- 1488 include-exclude list of the explicit-route-objects of the primary 1489 path: 1491 o The first element references the access link terminating on 1492 AN1-1 LTP 1494 o The last two element reference respectively the inter-domain 1495 link terminating on AN1-7 LTP and the data plane resources 1496 (i.e., the list of timeslots and the TPN) used by the ODU2 1497 connection over that link. 1499 The configuration of the timeslots used by the ODU2 connection on 1500 the internal links within a PNC domain (i.e., on the internal links 1501 within domain1) is outside the scope of this document since it is a 1502 matter of the PNC domain internal implementation. 1504 However, the configuration of the timeslots used by the ODU2 1505 connection at the transport network domain boundaries (e.g., on the 1506 inter-domain links) needs to take into account the timeslots 1507 available on physical nodes belonging to different PNC domains 1508 (e.g., on node S2 within PNC1 domain and on node S31 within PNC3 1509 domain). 1511 The MDSC, when coordinating the setup of a multi-domain ODU 1512 connection, also configures the data plane resources (i.e., the list 1513 of timeslots and the TPN) to be used on the inter-domain links. The 1514 MDSC can know the timeslots which are available on the physical OTN 1515 nodes terminating the inter-domain links (e.g., S2 and S31) from the 1516 OTN Topology information exposed, at the MPIs, by the PNCs 1517 controlling the OTN physical nodes (e.g., PNC1 and PNC3 controlling 1518 the physical nodes S2 and S31 respectively). 1520 Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service- 1521 config.json") describing how the setup of this ODU2 (Transit 1522 Segment) Tunnel can be requested by the MDSC, using the [TE-TUNNEL] 1523 and [OTN-TUNNEL] YANG models at MPI1. 1525 PNC1 knows, as described in the mapping table in Section 5.1.1, that 1526 AN-1 and AN1-7 LTPs within the MPI1 OTN Abstract Topology it exposes 1527 at MPI1 correspond to the S3-1 and S2-3 LTPs, respectively, within 1528 its native topology. Therefore it performs path computation, for an 1529 ODU2 connection between these LTPs within its native topology, and 1530 sets up the ODU2 cross-connections within the physical nodes S3, S1 1531 and S2, as shown in section 4.3.1. 1533 Since the R1-S3 access link is a multi-function access link, PNC1 1534 also configures the OTU2 trail before setting up the ODU2 1535 cross-connection in node S3. 1537 As part of the OUD2 cross-connection configuration in node S2, PNC1 1538 configures the data plane resources (i.e., the list of timeslots and 1539 the TPN), to be used by this ODU2 connection on the S2-S31 1540 inter-domain link, as requested by the MDSC. 1542 Following similar requests from MDSC to setup ODU2 (Transit Segment) 1543 Tunnels within the OTN Abstract Topologies they expose, PNC2 then 1544 sets up ODU2 cross-connections on nodes S31 and S33 while PNC3 sets 1545 up ODU2 cross-connections on nodes S15 and S18, as shown in section 1546 4.3.1. PNC2 also configures the OTU2 trail on the S18-R8 1547 multi-function access link. 1549 5.2.1.1. Single Domain Example 1551 To setup an ODU2 end-to-end connection, supporting an IP link, 1552 between R1 and R3, the CNC requests, at the CMI, the MDSC to setup 1553 an ODU transit service. 1555 Following the procedures described in section 5.2.1, MDSC requests 1556 only PCN1 to setup the ODU2 (Transit Segment) Tunnel between the 1557 access links terminating on AN-1 and AN1-2 LTPs within the MPI1 1558 Abstract Topology and PNC1 sets up ODU2 cross-connections on nodes 1559 S3, S5 and S6, as shown in section 4.3.1. PNC1 also configures the 1560 OTU2 trails on the R1-S3 and R3-S6 multi-function access links. 1562 5.2.2. EPL over ODU Service 1564 In this scenario, described in section 4.3.2, the access links are 1565 configured as 10GE Links and, as described in section 5.1, reported 1566 by each PNC as TE Links within the ETH abstract topologies they 1567 expose to the MDSC. 1569 To setup this IP link, between R1 and R8, the CNC requests, at the 1570 CMI, the MDSC to setup an EPL service. 1572 From its native topology, shown in Figure 6, the MDSC understands, 1573 by means which are outside the scope of this document, that R1 is 1574 attached to the access link terminating on AN1-1 LTP in the MPI1 ETH 1575 Abstract Topology, exposed by PNC1, and that R8 is attached to the 1576 access link terminating on AN2-1 LTP in the MPI2 ETH Abstract 1577 Topology, exposed by PNC2. 1579 The MDSC also understands that it needs to coordinate the setup of a 1580 multi-domain ODU2 Tunnel between the TTPs, abstracting nodes S3 and 1581 S18 within the OTN Abstract Topologies exposed by PNC1 and PNC2, 1582 respectively. 1584 MDSC then performs multi-domain path computation (step 2 in Figure 1585 7) and then requests: 1587 o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the 1588 MPI1 OTN Abstract Topology; 1590 o PNC1, at MPI1, to steer the Ethernet client traffic from/to AN1-1 1591 LTP, within the MPI1 ETH Abstract Topology, thought that ODU2 1592 (Head Segment) Tunnel; 1594 o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within 1595 the MPI3 OTN Abstract Topology; 1597 o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the 1598 MPI2 OTN Abstract Topology; 1600 o PNC2, at MPI2, to steer the Ethernet client traffic to/from AN2-1 1601 LTP, within the MPI2 ETH Abstract Topology, through that ODU2 1602 (Tail Segment) Tunnel. 1604 MDSC requests, at MPI1, PNC1 to setup an ODU2 (Head Segment) Tunnel 1605 with one primary path between the source TTP and AN1-7 LTP, within 1606 the MPI1 OTN Abstract Topology (Figure 4), using the TE Tunnel YANG 1607 model, defined in [TE-TUNNEL], with the OTN technology-specific 1608 augmentations, defined in [OTN-TUNNEL]: 1610 o Only the Source TTP is specified (since it is a Head Segment 1611 Tunnel): therefore the Destination TTP is not specified 1613 o The egress point in indicated in the route-object-include-exclude 1614 list of the explicit-route-objects of the primary path: 1616 o The last two element reference respectively the inter-domain 1617 link terminating on AN1-7 LTP and the data plane resources 1618 (i.e., the list of timeslots and the TPN) used by the ODU2 1619 connection over that link. 1621 Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel- 1622 config.json") describing how the setup of this ODU2 (Head Segment) 1623 Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN- 1624 TUNNEL] YANG models at MPI1. 1626 MDSC requests, at MPI1, PNC1 to steer the Ethernet client traffic 1627 from/to AN1-2 LTP, within the MPI1 ETH Abstract Topology (Figure 4), 1628 thought the MPI1 ODU2 (Head Segment) Tunnel, using the Ethernet 1629 Client YANG model, defined in [CLIENT-SIGNAL]. 1631 Appendix B.2.3 provides the detailed JSON code ("mpi1-epl-service- 1632 config.json") describing how the setup of this EPL service using the 1633 ODU2 Tunnel can be requested by the MDSC, using the [CLIENT-SIGNAL] 1634 YANG model at MPI1. 1636 PNC1 knows, as described in the table in section 5.1.1, that the 1637 tunnel source TTP and AN1-7 LTP, within the MPI1 OTN Abstract 1638 Topology it exposes at MPI1, correspond to node S3 and S2-3 LTP, 1639 respectively, within its native topology. Therefore it performs path 1640 computation, for an ODU2 connection between node S3 and S2-3 LTP 1641 within its native topology, and sets up the ODU2 cross-connections 1642 within the physical nodes S3, S1 and S2, as shown in section 4.3.2. 1644 As part of the OUD2 cross-connection configuration in node S2, PNC1 1645 configures the data plane resources (i.e., the list of timeslots and 1646 the TPN), to be used by this ODU2 connection on the S2-S31 1647 inter-domain link, as requested by the MDSC. 1649 After the configuration of the ODU2 cross-connection in node S3, 1650 PNC1 also configures the [ETH -> (ODU)] and [(ODU2) -> ETH] 1651 adaptation functions, within node S3, as shown in section 4.3.2. 1653 Since the R1-S3 access link is a multi-function access link, PNC1 1654 also configures the 10GE link before this step. 1656 Following similar requests from MDSC to setup ODU2 (Segment) Tunnels 1657 within the OTN Abstract Topologies they expose as well as the 1658 steering of the Ethernet client traffic, PNC3 then sets up ODU2 1659 cross-connections on nodes S31 and S33 while PNC2 sets up ODU2 1660 cross-connections on nodes S15 and S18 as well as the [ETH -> 1661 (ODU2)] and [(ODU2) -> ETH] adaptation functions in node S18, as 1662 shown in section 4.3.2. PNC2 also configures the 10GE link on the 1663 S18-R8 multi-function access link. 1665 5.2.2.1. Single Domain Example 1667 To setup this IP link, between R1 and R2, the CNC requests, at the 1668 CMI, the MDSC to setup an EPL service. 1670 Following the procedures described in section 5.2.2, the MDSC 1671 requests PCN1 to: 1673 o setup an ODU2 (end-to-end) Tunnel between the TTPs, abstracting 1674 nodes S3 and S6 within MPI1 OTN Abstract Topology exposed by PNC1 1675 at MPI1; 1677 o steer the Ethernet client traffic between the AN1-1 and AN1-8 1678 LTPs, exposed by PNC1 within MPI1 ETH Abstract Topology, through 1679 that ODU2 (end-to-end) Tunnel. 1681 Then PNC1 sets up ODU2 cross-connections on nodes S3, S5 and S6 as 1682 well as the [ETH -> (ODU)] and [(ODU2) -> ETH] adaptation functions 1683 in nodes S3 and S6, as shown in section 4.3.2. PNC1 also configures 1684 the 10GE link on the R1-S3 multi-function access link (the R2-S6 1685 access link has been pre-configured as a 10GE link). 1687 5.2.3. Other OTN Client Services 1689 In this scenario, described in section 4.3.3, the access links are 1690 configured as STM-64 links and, as described in section 5.1, 1691 reported by each PNC as TE Links within the OTN Abstract Topologies 1692 they expose to the MDSC. 1694 The CNC requests, at the CMI, MDSC to setup an STM-64 Private Line 1695 service between R1 and R8. 1697 Following similar procedures as described in section 5.2.2, MDSC 1698 understands that: 1700 o R1 is attached to the access link terminating on AN1-1 LTP in the 1701 MPI1 OTN Abstract Topology, exposed by PNC1, and that R8 is 1702 attached to the access link terminating on AN2-1 LTP in the MPI2 1703 OTN Abstract Topology, exposed by PNC2; 1705 o it needs to coordinate the setup of a multi-domain ODU2 Tunnel 1706 between the TTPs, abstracting nodes S3 and S18 within the OTN 1707 Abstract Topologies exposed by PNC1 and PNC2, respectively. 1709 The MDSC then performs multi-domain path computation (step 2 in 1710 Figure 7) and then requests: 1712 o PNC1, at MPI1, to setup an ODU2 (Head Segment) Tunnel within the 1713 MPI1 OTN Abstract Topology; 1715 o PNC1, at MPI1, to steer the STM-64 transparent client traffic 1716 from/to AN1-1 LTP, within the MPI1 OTN Abstract Topology, thought 1717 that ODU2 (Head Segment) Tunnel; 1719 o PNC3, at MPI3, to setup an ODU2 (Transit Segment) Tunnel within 1720 the MPI3 OTN Abstract Topology; 1722 o PNC2, at MPI2, to setup ODU2 (Tail Segment) Tunnel within the 1723 MPI2 OTN Abstract Topology; 1725 o PNC2, at MPI2, to steer the STM-64 transparent client traffic 1726 to/from AN2-1 LTP, within the MPI2 ETH Abstract Topology, through 1727 that ODU2 (Tail Segment) Tunnel. 1729 PNC1, PNC2 and PNC3 then sets up the ODU2 cross-connections within 1730 the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well as the 1731 [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation functions in 1732 nodes S3 and S18, as shown in section 4.3.3. PNC1 and PNC2 also 1733 configure the STM-64 links on the R1-S3 and R8-S18 multi-function 1734 access links, respectively. 1736 5.2.3.1. Single Domain Example 1738 To setup this IP link, between R1 and R3, the CNC requests, at the 1739 CMI, the MDSC to setup an STM-64 Private Line service. 1741 The MDSC and PNC1 follows similar procedures as described in section 1742 5.2.2.1 to set up ODU2 cross-connections on nodes S3, S5 and S6 as 1743 well as the [STM-64 -> (ODU)] and [(ODU2) -> STM-64] adaptation 1744 functions in nodes S3 and S6, as shown in section 4.3.3. PNC1 also 1745 configures the STM-64 links on the R1-S3 and R3-S6 multi-function 1746 access links. 1748 5.2.4. EVPL over ODU Service 1750 In this scenario, described in section 4.3.4, the access links are 1751 configured as 10GE links, as described in section 5.2.2 above. 1753 The CNC requests, at the CMI, the MDSC to setup two EVPL services: 1754 one between R1 and R2, and another between R1 and R8. 1756 Following similar procedures as described in section 5.2.2 and 1757 5.2.2.1, MDSC understands that: 1759 o R1 and R2 are attached to the access links terminating 1760 respectively on AN1-1 and AN1-8 LTPs in the MPI1 ETH Abstract 1761 Topology, exposed by PNC1, and that R8 is attached to the access 1762 link terminating on AN2-1 LTP in the MPI2 ETH Abstract Topology, 1763 exposed by PNC2; 1765 o to setup the first (single-domain) EVPL service, between R1 and 1766 R2, it needs to coordinate the setup of a single-domain ODU0 1767 Tunnel between the TTPs, abstracting nodes S3 and S6 within the 1768 OTN Abstract Topology exposed by PNC1; 1770 o to setup the second (multi-domain) EPVL service, between R1 and 1771 R8, it needs to coordinate the setup of a multi-domain ODU0 1772 Tunnel between the TTPs, abstracting nodes S3 and S18 within the 1773 OTN Abstract Topologies exposed by PNC1 and PNC2, respectively. 1775 To setup the first (single-domain) EVPL service between R1 and R2, 1776 the MDSC and PNC1 follows similar procedures as described in section 1777 5.2.2.1 to set up ODU0 cross-connections on nodes S3, S5 and S6 as 1778 well as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation 1779 functions, in nodes S3 and S6, as shown in section 4.3.4. PNC1 also 1780 configures the 10GE link on the R1-S3 multi-function access link. 1782 As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation 1783 functions configurations in nodes S2 and S6, PNC1 configures also 1784 the classification rules required to associated only the Ethernet 1785 client traffic received with VLAN ID 10 on the R1-S3 and R2-S6 1786 access links with this EVPL service. The MDSC provides this 1787 information to PNC1 using the [CLIENT-SIGNAL] model. 1789 To setup the second (multi-domain) EVPL service between R1 and R8, 1790 the MDSC, PNC1, PNC2 and PNC3 follows similar procedures as 1791 described in section 5.2.2 to setup the ODU0 cross-connections 1792 within the physical nodes S3, S1, S2, S31, S33, S15 and S18 as well 1793 as the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation functions in 1794 nodes S3 and S18, as shown in section 4.3.4. PNC2 also configures 1795 the 10GE link on the R8-S18 multi-function access link (the R1-S3 1796 10GE link has been already configured when the first EVPL service 1797 has been setup). 1799 As part of the [VLAN -> (ODU0)] and [(ODU0) -> VLAN] adaptation 1800 functions configurations in nodes S3 and S18, PNC1 and, 1801 respectively, PNC2 configure also the classification rules required 1802 to associated only the Ethernet client traffic received with VLAN ID 1803 20 on the R1-S3 and R8-S18 access links with this EVPL service. The 1804 MDSC provides this information to PNC1 and PNC2 using the 1805 [CLIENT-SIGNAL] model. 1807 5.3. YANG Models for Protection Configuration 1809 5.3.1. Linear Protection (end-to-end) 1811 To be discussed in future versions of this document. 1813 5.4. Notifications 1815 Further detailed analysis is outside the scope of this document 1817 5.5. Path Computation with Constraints 1819 The path computation constraints that can be supported at the MPI 1820 using the IETF YANG models defined in [TE-TUNNEL] and [PATH- 1821 COMPUTE]. 1823 When there is a technology specific network (e.g., OTN), the 1824 corresponding technology (e.g., OTN) model should also be used to 1825 specify the tunnel information on MPI, with the constraint included 1826 in TE Tunnel model. 1828 Further detailed analysis is outside the scope of this document 1830 6. Security Considerations 1832 This document analyses the applicability of the YANG models being 1833 defined by the IETF to support OTN single and multi-domain 1834 scenarios. 1836 Inherently OTN networks ensure privacy and security via hard 1837 partitioning of traffic onto dedicated circuits. The separation of 1838 network traffic makes it difficult to intercept data transferred 1839 between nodes over OTN-channelized links. 1841 In OTN the (General Communication Channel) GCC is used for OAM 1842 functions such as performance monitoring, fault detection, and 1843 signaling. The GCC control channel should be secured using a 1844 suitable mechanism. 1846 There are no additional or new security considerations introduced by 1847 this document. 1849 7. IANA Considerations 1851 This document requires no IANA actions. 1853 8. References 1855 8.1. Normative References 1857 [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and 1858 Restoration) Terminology for Generalized Multi-Protocol 1859 Label Switching (GMPLS)", RFC 4427, March 2006. 1861 [RFC4655] Farrel, A. et al., "A Path Computation Element (PCE)-Based 1862 Architecture", RFC4655, August 2006. 1864 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 1865 Information Exchange between Interconnected Traffic- 1866 Engineered Networks", BCP 206, RFC 7926, July 2016. 1868 [RFC8345] Clemm, A.,Medved, J. et al., "A Yang Data Model for 1869 Network Topologies", RFC8345, March 2018. 1871 [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction 1872 and Control of TE Networks (ACTN)", RFC8453, August 2018. 1874 [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for 1875 the optical transport network", June 2016. 1877 [ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic 1878 protection switching - Linear trail and subnetwork 1879 protection", May 2014. 1881 [ITU-T G.873.1] ITU-T Recommendation G.873.1 (05/14), "Optical 1882 transport network (OTN): Linear protection", May 2014. 1884 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", 1885 draft-ietf-teas-yang-te-topo, work in progress. 1887 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical 1888 Transport Network Topology", draft-ietf-ccamp-otn-topo- 1889 yang, work in progress. 1891 [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer 1892 Topology", draft-zheng-ccamp-client-topo-yang, work in 1893 progress. 1895 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 1896 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1897 te, work in progress. 1899 [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for 1900 requesting Path Computation", draft-ietf-teas-yang-path- 1901 computation, work in progress. 1903 [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft- 1904 ietf-ccamp-otn-tunnel-model, work in progress. 1906 [CLIENT-SIGNAL] Zheng, H. et al., "A YANG Data Model for Optical 1907 Transport Network Client Signals", draft-zheng-ccamp-otn- 1908 client-signal-yang, work in progress. 1910 8.2. Informative References 1912 [RFC5151] Farrel, A. et al., "Inter-Domain MPLS and GMPLS Traffic 1913 Engineering --Resource Reservation Protocol-Traffic 1914 Engineering (RSVP-TE) Extensions", RFC 5151, February 1915 2008. 1917 [RFC6898] Li, D. et al., "Link Management Protocol Behavior 1918 Negotiation and Configuration Modifications", RFC 6898, 1919 March 2013. 1921 [RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January 1922 2017. 1924 [RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309, 1925 January 2018. 1927 [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for 1928 Abstraction and Control of Traffic Engineered Networks", 1929 draft-zhang-teas-actn-yang, work in progress. 1931 [RFC-FOLD] Watsen, K. et al., "Handling Long Lines in Artwork in 1932 Internet-Drafts and RFCs", draft-ietf-netmod-artwork- 1933 folding, work in progress 1935 [TE-TUTORIAL] Bryskin, I. et al., "TE Topology and Tunnel Modeling 1936 for Transport Networks", draft-ietf-teas-te-topo-and- 1937 tunnel-modeling, work in progress 1939 [ONF TR-527] ONF Technical Recommendation TR-527, "Functional 1940 Requirements for Transport API", June 2016. 1942 [ONF GitHub] ONF Open Transport (SNOWMASS), 1943 1946 [MEF 55] Metro Ethernet Forum, "Lifecycle Service Orchestration 1947 (LSO): Reference Architecture and Framework", Technical 1948 Specification MEF 55, March 2016, 1949 1952 9. Acknowledgments 1954 The authors would like to thank all members of the Transport NBI 1955 Design Team involved in the definition of use cases, gap analysis 1956 and guidelines for using the IETF YANG models at the Northbound 1957 Interface (NBI) of a Transport SDN Controller. 1959 The authors would like to thank Xian Zhang, Anurag Sharma, Sergio 1960 Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar 1961 Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated 1962 the work on gap analysis for transport NBI and having provided 1963 foundations work for the development of this document. 1965 The authors would like to thank the authors of the TE Topology and 1966 Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular, Igor 1967 Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their 1968 support in addressing any gap identified during the analysis work. 1970 The authors would like to thank Henry Yu and Aihua Guo for their 1971 input and review of the URIs structures used within the JSON code 1972 examples. 1974 This work was supported in part by the European Commission funded 1975 H2020-ICT-2016-2 METRO-HAUL project (G.A. 761727). 1977 This document was prepared using 2-Word-v2.0.template.dot. 1979 Appendix A. Validating a JSON fragment against a YANG Model 1981 The objective is to have a tool that allows validating whether a 1982 piece of JSON code embedded in an Internet-Draft is compliant with a 1983 YANG model without using a client/server. 1985 A.1. Manipulation of JSON fragments 1987 This section describes the various ways JSON fragments are used in 1988 the I-D processing and how to manage them. 1990 Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 1991 72 chars width and it is acceptable for it to be invalid JSON. 1993 We then define "unfolded-JSON" a valid JSON fragment having the same 1994 contents of the "folded-JSON " without folding, i.e. limits on the 1995 text width. The folding/unfolding operation may be done according to 1996 [RFC-FOLD]. The "unfolded-JSON" can be edited by the authors using 1997 JSON editors with the advantages of syntax validation and pretty- 1998 printing. 2000 Both the "folded" and the "unfolded" JSON fragments can include 2001 comments having descriptive fields and directives we'll describe 2002 later to facilitate the reader and enable some automatic processing. 2004 The presence of comments in the "unfolded-JSON" fragment makes it an 2005 invalid JSON encoding of YANG data. Therefore we call "naked JSON" 2006 the JSON where the comments have been stripped out: not only it is 2007 valid JSON but it is a valid JSON encoding of YANG data. 2009 The following schema resumes these definitions: 2011 unfold_it --> stripper --> 2013 Folded-JSON Unfolded-JSON Naked JSON 2015 <-- fold_it <-- author edits 2017 <=72-chars? MUST MAY MAY 2019 valid JSON? MAY MUST MUST 2021 JSON-encoding MAY MAY MUST 2022 of YANG data 2024 Our validation toolchain has been designed to take a JSON in any of 2025 the three formats and validate it automatically against a set of 2026 relevant YANG modules using available open-source tools. It can be 2027 found at: https://github.com/GianmarcoBruno/json-yang/ 2029 A.2. Comments in JSON fragments 2031 We found useful to introduce two kinds of comments, both defined as 2032 key-value pairs where the key starts with "//": 2034 - free-form descriptive comments, e.g."// COMMENT" : "refine this" 2035 to describe properties of JSON fragments. 2037 - machine-usable directives e.g. "// __REFERENCES__DRAFTS__" : { 2038 "ietf-routing-types@2017-12-04": "rfc8294",} which can be used to 2039 automatically download from the network the relevant I-Ds or RFCs 2040 and extract from them the YANG models of interest. This is 2041 particularly useful to keep consistency when the drafting work is 2042 rapidly evolving. 2044 A.3. Validation of JSON fragments: DSDL-based approach 2046 The idea is to generate a JSON driver file (JTOX) from YANG, then 2047 use it to translate JSON to XML and validate it against the DSDL 2048 schemas, as shown in Figure 8. 2050 Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson 2052 (2) 2053 YANG-module ---> DSDL-schemas (RNG,SCH,DSRL) 2054 | | 2055 | (1) | 2056 | | 2057 Config/state JTOX-file | (4) 2058 \ | | 2059 \ | | 2060 \ V V 2061 JSON-file------------> XML-file ----------------> Output 2062 (3) 2064 Figure 8 - DSDL-based approach for JSON code validation 2066 In order to allow the use of comments following the convention 2067 defined in section 3, without impacting the validation process, 2068 these comments will be automatically removed from the JSON-file that 2069 will be validate. 2071 A.4. Validation of JSON fragments: why not using a XSD-based approach 2073 This approach has been analyzed and discarded because no longer 2074 supported by pyang. 2076 The idea is to convert YANG to XSD, JSON to XML and validate it 2077 against the XSD, as shown in Figure 9: 2079 (1) 2080 YANG-module ---> XSD-schema - \ (3) 2081 +--> Validation 2082 JSON-file------> XML-file ----/ 2083 (2) 2085 Figure 9 - XSD-based approach for JSON code validation 2087 The pyang support for the XSD output format was deprecated in 1.5 2088 and removed in 1.7.1. However pyang 1.7.1 is necessary to work with 2089 YANG 1.1 so the process shown in Figure 9 will stop just at step 2090 (1). 2092 Appendix B. Detailed JSON Examples 2094 The JSON code examples provided in this appendix have been validated 2095 using the tools in Appendix A and folded using the tool in [RFC- 2096 FOLD]. 2098 B.1. JSON Examples for Topology Abstractions 2100 B.1.1. JSON Code: mpi1-otn-topology.json 2102 This is the JSON code reporting the OTN Topology @ MPI: 2104 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 2106 { 2107 "// __TITLE__": "ODU Black Topology @ MPI1", 2108 "// __LAST_UPDATE__": "October 18, 2018", 2109 "// __MISSING_ATTRIBUTES__": true, 2110 "// __REFERENCE_DRAFTS__": { 2111 "ietf-routing-types@2017-12-04": "rfc8294", 2112 "ietf-otn-types@2017-10-30": "draft-ietf-ccamp-otn-tunnel-model-\ 2113 \01", 2114 "ietf-network@2018-02-26": "rfc8345", 2115 "ietf-network-topology@2018-02-26": "rfc8345", 2116 "ietf-te-types@2018-06-12": "draft-ietf-teas-yang-te-15", 2117 "ietf-te-topology@2018-06-15": "draft-ietf-teas-yang-te-topo-18", 2118 "ietf-otn-topology@2017-10-30": "draft-ietf-ccamp-otn-topo-yang-\ 2119 \02" 2120 }, 2121 "// __RESTCONF_OPERATION__": { 2122 "operation": "GET", 2123 "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-network:networks" 2124 }, 2125 "ietf-network:networks": { 2126 "network": [ 2127 { 2128 "network-id": "providerId/201/clientId/300/topologyId/otn-bl\ 2129 \ack-topology", 2130 "network-types": { 2131 "ietf-te-topology:te-topology": { 2132 "ietf-otn-topology:otn-topology": {} 2133 } 2134 }, 2135 "ietf-te-topology:provider-id": 201, 2136 "ietf-te-topology:client-id": 300, 2137 "ietf-te-topology:te-topology-id": "otn-black-topology", 2138 "// ietf-te-topology:te": "presence container requires: prov\ 2139 \ider, client and te-topology-id", 2140 "ietf-te-topology:te": { 2141 "name": "OTN Black Topology @ MPI1" 2142 }, 2143 "// ietf-network:node": "Access LTPs to be reviewed in a fut\ 2144 \ure update", 2145 "ietf-network:node": [ 2146 { 2147 "// __NODE__:__DESCRIPTION__": { 2148 "name": "AN1", 2149 "identifier": "10.0.0.1", 2150 "type": "Abstract Node", 2151 "physical node(s)": "whole network domain 1" 2152 }, 2153 "node-id": "10.0.0.1", 2154 "ietf-te-topology:te-node-id": "10.0.0.1", 2155 "ietf-te-topology:te": { 2156 "te-node-attributes": { 2157 "name": "AN11", 2158 "admin-status": "up", 2159 "// __DISCUSS__ is-abstract": "To be discussed with \ 2160 \TE Topology authors", 2161 "// __DISCUSS__ underlay-topology": "To be discussed\ 2162 \ with TE Topology authors" 2163 }, 2164 "oper-status": "up", 2165 "// __DISCUSS__ tunnel-termination-point": [] 2166 }, 2167 "ietf-network-topology:termination-point": [ 2168 { 2169 "// __DESCRIPTION__:__LTP__": { 2170 "name": "AN1-1 LTP", 2171 "link type(s)": "OTU-2", 2172 "physical node": "S3", 2173 "unnumberd/ifIndex": 1, 2174 "port type": "tributary port", 2175 "connected to": "R1" 2176 }, 2177 "tp-id": "1", 2178 "ietf-te-topology:te-tp-id": 1, 2179 "ietf-te-topology:te": { 2180 "name": "AN1-1 LTP", 2181 "admin-status": "up", 2182 "// __DISCUSS__ interface-switching-capability": "\ 2183 \See Link attributes (teNodeId/10.0.0.1/teLinkId/1)", 2184 "// __DISCUSS__ inter-domain-plug-id": "Access Lin\ 2185 \k", 2186 "// __COMMENT__ inter-layer-lock-id": "Empty: OTN \ 2187 \Links are pre-configured", 2188 "oper-status": "up", 2189 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2190 \d-types": "List of ODU clients?", 2191 "// __DISCUSS__ ietf-otn-topology:client-facing": \ 2193 \true 2194 } 2195 }, 2196 { 2197 "// __DESCRIPTION__:__LTP__": { 2198 "name": "AN1-2 LTP", 2199 "link type(s)": "OTU-4", 2200 "physical node": "S2", 2201 "unnumberd/ifIndex": 1, 2202 "port type": "inter-domain port", 2203 "connected to": "S31" 2204 }, 2205 "tp-id": "2", 2206 "ietf-te-topology:te-tp-id": 2, 2207 "ietf-te-topology:te": { 2208 "name": "AN1-2 LTP", 2209 "admin-status": "up", 2210 "// __DISCUSS__ interface-switching-capability": "\ 2211 \See Link attributes (teNodeId/10.0.0.1/teLinkId/2)", 2212 "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\ 2213 \in Link", 2214 "oper-status": "up", 2215 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2216 \d-types": "Empty? (inter-domain OTN link)", 2217 "// __DEFAULT__ ietf-otn-topology:client-facing": \ 2218 \false 2219 } 2220 }, 2221 { 2222 "// __DESCRIPTION__:__LTP__": { 2223 "name": "AN1-3 LTP", 2224 "link type(s)": "OTU-2", 2225 "physical node": "S6", 2226 "unnumberd/ifIndex": 1, 2227 "port type": "tributary port", 2228 "connected to": "R2" 2229 }, 2230 "tp-id": "3", 2231 "ietf-te-topology:te-tp-id": 3, 2232 "ietf-te-topology:te": { 2233 "name": "AN1-3 LTP", 2234 "admin-status": "up", 2235 "// __DISCUSS__ interface-switching-capability": "\ 2236 \See Link attributes (teNodeId/10.0.0.1/teLinkId/3)", 2237 "// __DISCUSS__ inter-domain-plug-id": "Access Lin\ 2238 \k", 2239 "oper-status": "up", 2240 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2241 \d-types": "List of ODU clients?", 2242 "// __DISCUSS__ ietf-otn-topology:client-facing": \ 2243 \true 2244 } 2245 }, 2246 { 2247 "// __DESCRIPTION__:__LTP__": { 2248 "name": "AN1-4 LTP", 2249 "link type(s)": "OTU-4", 2250 "physical node": "S8", 2251 "unnumberd/ifIndex": 1, 2252 "port type": "inter-domain port", 2253 "connected to": "S32" 2254 }, 2255 "tp-id": "4", 2256 "ietf-te-topology:te-tp-id": 4, 2257 "ietf-te-topology:te": { 2258 "name": "AN1-4 LTP", 2259 "admin-status": "up", 2260 "// __DISCUSS__ interface-switching-capability": "\ 2261 \See Link attributes (teNodeId/10.0.0.1/teLinkId/4)", 2262 "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\ 2263 \in Link", 2264 "oper-status": "up", 2265 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2266 \d-types": "Empty? (inter-domain OTN link)", 2267 "// __DEFAULT__ ietf-otn-topology:client-facing": \ 2268 \false 2269 } 2270 }, 2271 { 2272 "// __DESCRIPTION__:__LTP__": { 2273 "name": "AN1-5 LTP", 2274 "link type(s)": "OTU-4", 2275 "physical node": "S8", 2276 "unnumberd/ifIndex": 5, 2277 "port type": "inter-domain port", 2278 "connected to": "S12" 2279 }, 2280 "tp-id": "5", 2281 "ietf-te-topology:te-tp-id": 5, 2282 "ietf-te-topology:te": { 2283 "name": "AN1-5 LTP", 2284 "admin-status": "up", 2285 "// __DISCUSS__ interface-switching-capability": "\ 2286 \See Link attributes (teNodeId/10.0.0.1/teLinkId/5)", 2287 "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\ 2288 \in Link", 2289 "oper-status": "up", 2290 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2291 \d-types": "Empty? (inter-domain OTN link)", 2292 "// __DEFAULT__ ietf-otn-topology:client-facing": \ 2293 \false 2294 } 2295 }, 2296 { 2297 "// __DESCRIPTION__:__LTP__": { 2298 "name": "AN1-6 LTP", 2299 "link type(s)": "OTU-4", 2300 "physical node": "S7", 2301 "unnumberd/ifIndex": 4, 2302 "port type": "inter-domain port", 2303 "connected to": "S11" 2304 }, 2305 "tp-id": "6", 2306 "ietf-te-topology:te-tp-id": 6, 2307 "ietf-te-topology:te": { 2308 "name": "AN1-6 LTP", 2309 "admin-status": "up", 2310 "// __DISCUSS__ interface-switching-capability": "\ 2311 \See Link attributes (teNodeId/10.0.0.1/teLinkId/6)", 2312 "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\ 2313 \in Link", 2314 "oper-status": "up", 2315 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2316 \d-types": "Empty? (inter-domain OTN link)", 2317 "// __DEFAULT__ ietf-otn-topology:client-facing": \ 2318 \false 2319 } 2320 }, 2321 { 2322 "// __DESCRIPTION__:__LTP__": { 2323 "name": "AN1-7 LTP", 2324 "link type(s)": "OTU-2", 2325 "physical node": "S6", 2326 "unnumberd/ifIndex": 2, 2327 "port type": "tributary port", 2328 "connected to": "R3" 2329 }, 2330 "tp-id": "7", 2331 "ietf-te-topology:te-tp-id": 7, 2332 "ietf-te-topology:te": { 2333 "name": "AN1-7 LTP", 2334 "admin-status": "up", 2335 "// __DISCUSS__ interface-switching-capability": "\ 2336 \See Link attributes (teNodeId/10.0.0.1/teLinkId/7)", 2337 "// __DISCUSS__ inter-domain-plug-id": "Access Lin\ 2338 \k", 2339 "oper-status": "up", 2340 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2341 \d-types": "List of ODU clients?", 2342 "// __DISCUSS__ ietf-otn-topology:client-facing": \ 2343 \true 2344 } 2345 } 2346 ] 2347 } 2348 ], 2349 "// ietf-network-topology:link": "Access links to be reviewe\ 2350 \d in a future update", 2351 "ietf-network-topology:link": [ 2352 { 2353 "// __DESCRIPTION__:__LINK__": { 2354 "name": "Access Link from AN1-1", 2355 "type": "access link", 2356 "physical link": "Link from S3-1 to R1" 2357 }, 2358 "link-id": "teNodeId/10.0.0.1/teLinkId/1", 2359 "ietf-te-topology:te": { 2360 "te-link-attributes": { 2361 "name": "Access Link from AN1-1", 2362 "// __DISCUSS__ access-type": "Can we assume point-t\ 2363 \o-point as the default value?", 2364 "access-type": "point-to-point", 2365 "// __COMMENT__ external-domain": "Empty: the plug-i\ 2366 \d is used instead of this container", 2367 "// __DISCUSS__ is-abstract": "To be discussed with \ 2368 \TE Topology authors", 2369 "// __DISCUSS__ underlay": "To be discussed with TE \ 2370 \Topology authors", 2371 "admin-status": "up", 2372 "interface-switching-capability": [ 2373 { 2374 "switching-capability": "ietf-te-types:switching\ 2375 \-otn", 2376 "encoding": "ietf-te-types:lsp-encoding-oduk", 2377 "max-lsp-bandwidth": [ 2378 { 2379 "priority": 0, 2380 "// __DISCUSS__ te-bandwidth": "ODU2" 2381 } 2382 ] 2383 } 2384 ], 2385 "// __COMMENT__ label-restrictions": "Not described \ 2386 \in this JSON example", 2387 "// __DISCUSS__ link-protection-type": "Can we assum\ 2388 \e unprotected as the default value?", 2389 "link-protection-type": "unprotected", 2390 "max-link-bandwidth": { 2391 "// __DISCUSS__ te-bandwidth": "1xODU2" 2392 }, 2393 "max-resv-link-bandwidth": { 2394 "// __DISCUSS__ te-bandwidth": "1xODU2" 2395 }, 2396 "unreserved-bandwidth": [ 2397 { 2398 "priority": 0, 2399 "// __DISCUSS__ te-bandwidth": "1xODU2" 2400 } 2401 ] 2402 }, 2403 "oper-status": "up", 2404 "// __EMPTY__ is-transitional": "It is not a transitio\ 2405 \nal link", 2406 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2407 \opology authors" 2408 }, 2409 "source": { 2410 "source-node": "10.0.0.1", 2411 "source-tp": 1 2412 }, 2413 "// __EMPTY__ destination": "access link" 2414 }, 2415 { 2416 "// __DESCRIPTION__:__LINK__": { 2417 "name": "Inter-domain Link from AN1-2", 2418 "type": "inter-domain link", 2419 "physical link": "Link from S2-1 to S31" 2420 }, 2421 "link-id": "teNodeId/10.0.0.1/teLinkId/2", 2422 "ietf-te-topology:te": { 2423 "te-link-attributes": { 2424 "name": "Inter-domain Link from AN1-2", 2425 "// __DISCUSS__ access-type": "Can we assume point-t\ 2426 \o-point as the default value?", 2427 "access-type": "point-to-point", 2428 "// __DISCUSS__ is-abstract": "To be discussed with \ 2429 \TE Topology authors", 2430 "// __DISCUSS__ underlay": "To be discussed with TE \ 2431 \Topology authors", 2432 "admin-status": "up", 2433 "interface-switching-capability": [ 2434 { 2435 "switching-capability": "ietf-te-types:switching\ 2436 \-otn", 2437 "encoding": "ietf-te-types:lsp-encoding-oduk", 2438 "max-lsp-bandwidth": [ 2439 { 2440 "priority": 0, 2441 "// __DISCUSS__ te-bandwidth": "ODU4" 2442 } 2443 ], 2444 "// __DISCUSS__ label-restrictions": "To be adde\ 2445 \d?" 2446 } 2447 ], 2448 "// __DISCUSS__ link-protection-type": "Can we assum\ 2449 \e unprotected as the default value?", 2450 "link-protection-type": "unprotected", 2451 "max-link-bandwidth": { 2452 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2453 }, 2454 "max-resv-link-bandwidth": { 2455 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2456 }, 2457 "unreserved-bandwidth": [ 2458 { 2459 "priority": 0, 2460 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2461 } 2462 ] 2463 }, 2464 "oper-status": "up", 2465 "// __EMPTY__ is-transitional": "It is not a transitio\ 2466 \nal link", 2467 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2468 \opology authors" 2469 }, 2470 "source": { 2471 "source-node": "10.0.0.1", 2472 "source-tp": 2 2473 }, 2474 "// __EMPTY__ destination": "inter-domain link" 2475 }, 2476 { 2477 "// __DESCRIPTION__:__LINK__": { 2478 "name": "Access Link from AN1-3", 2479 "type": "access link", 2480 "physical link": "Link from S6-1 to R2" 2481 }, 2482 "link-id": "teNodeId/10.0.0.1/teLinkId/3", 2483 "ietf-te-topology:te": { 2484 "te-link-attributes": { 2485 "name": "Access Link from AN1-3", 2486 "// __DISCUSS__ access-type": "Can we assume point-t\ 2487 \o-point as the default value?", 2488 "access-type": "point-to-point", 2489 "// __DISCUSS__ is-abstract": "To be discussed with \ 2490 \TE Topology authors", 2491 "// __DISCUSS__ underlay": "To be discussed with TE \ 2492 \Topology authors", 2493 "admin-status": "up", 2494 "interface-switching-capability": [ 2495 { 2496 "switching-capability": "ietf-te-types:switching\ 2497 \-otn", 2498 "encoding": "ietf-te-types:lsp-encoding-oduk", 2499 "max-lsp-bandwidth": [ 2500 { 2501 "priority": 0, 2502 "// __DISCUSS__ te-bandwidth": "ODU2" 2503 } 2504 ], 2505 "// __DISCUSS__ label-restrictions": "To be adde\ 2506 \d?" 2507 } 2508 ], 2509 "// __DISCUSS__ link-protection-type": "Can we assum\ 2510 \e unprotected as the default value?", 2511 "link-protection-type": "unprotected", 2512 "max-link-bandwidth": { 2513 "// __DISCUSS__ te-bandwidth": "1xODU2" 2514 }, 2515 "unreserved-bandwidth": [ 2516 { 2517 "priority": 0, 2518 "// __DISCUSS__ te-bandwidth": "1xODU2" 2519 } 2520 ], 2521 "max-resv-link-bandwidth": { 2522 "// __DISCUSS__ te-bandwidth": "1xODU2" 2523 } 2524 }, 2525 "oper-status": "up", 2526 "// __EMPTY__ is-transitional": "It is not a transitio\ 2527 \nal link", 2528 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2529 \opology authors" 2530 }, 2531 "source": { 2532 "source-node": "10.0.0.1", 2533 "source-tp": 3 2534 }, 2535 "// __EMPTY__ destination": "access link" 2536 }, 2537 { 2538 "// __DESCRIPTION__:__LINK__": { 2539 "name": "Inter-domain Link from AN1-4", 2540 "type": "inter-domain link", 2541 "physical link": "Link from S8-1 to S32" 2542 }, 2543 "link-id": "teNodeId/10.0.0.1/teLinkId/4", 2544 "ietf-te-topology:te": { 2545 "te-link-attributes": { 2546 "name": "Inter-domain Link from AN1-4", 2547 "// __DISCUSS__ access-type": "Can we assume point-t\ 2548 \o-point as the default value?", 2549 "access-type": "point-to-point", 2550 "// __DISCUSS__ is-abstract": "To be discussed with \ 2551 \TE Topology authors", 2552 "// __DISCUSS__ underlay": "To be discussed with TE \ 2553 \Topology authors", 2554 "admin-status": "up", 2555 "interface-switching-capability": [ 2556 { 2557 "switching-capability": "ietf-te-types:switching\ 2558 \-otn", 2559 "encoding": "ietf-te-types:lsp-encoding-oduk", 2560 "max-lsp-bandwidth": [ 2561 { 2562 "priority": 0, 2563 "// __DISCUSS__ te-bandwidth": "ODU4" 2564 } 2565 ], 2566 "// __DISCUSS__ label-restrictions": "To be adde\ 2567 \d?" 2568 } 2569 ], 2570 "// __DISCUSS__ link-protection-type": "Can we assum\ 2571 \e unprotected as the default value?", 2572 "link-protection-type": "unprotected", 2573 "max-link-bandwidth": { 2574 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2575 }, 2576 "unreserved-bandwidth": [ 2577 { 2578 "priority": 0, 2579 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2580 } 2581 ], 2582 "max-resv-link-bandwidth": { 2583 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2584 } 2585 }, 2586 "oper-status": "up", 2587 "// __EMPTY__ is-transitional": "It is not a transitio\ 2588 \nal link", 2589 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2590 \opology authors" 2591 }, 2592 "source": { 2593 "source-node": "10.0.0.1", 2594 "source-tp": 4 2595 }, 2596 "// __EMPTY__ destination": "inter-domain link" 2597 }, 2598 { 2599 "// __DESCRIPTION__:__LINK__": { 2600 "name": "Inter-domain Link from AN1-5", 2601 "type": "inter-domain link", 2602 "physical link": "Link from S8-5 to S12" 2603 }, 2604 "link-id": "teNodeId/10.0.0.1/teLinkId/5", 2605 "ietf-te-topology:te": { 2606 "te-link-attributes": { 2607 "name": "Inter-domain Link from AN1-5", 2608 "// __DISCUSS__ access-type": "Can we assume point-t\ 2609 \o-point as the default value?", 2610 "access-type": "point-to-point", 2611 "// __DISCUSS__ is-abstract": "To be discussed with \ 2612 \TE Topology authors", 2613 "// __DISCUSS__ underlay": "To be discussed with TE \ 2614 \Topology authors", 2615 "admin-status": "up", 2616 "interface-switching-capability": [ 2617 { 2618 "switching-capability": "ietf-te-types:switching\ 2619 \-otn", 2620 "encoding": "ietf-te-types:lsp-encoding-oduk", 2621 "max-lsp-bandwidth": [ 2622 { 2623 "priority": 0, 2624 "// __DISCUSS__ te-bandwidth": "ODU4" 2625 } 2626 ], 2627 "// __DISCUSS__ label-restrictions": "To be adde\ 2628 \d?" 2629 } 2630 ], 2631 "// __DISCUSS__ link-protection-type": "Can we assum\ 2632 \e unprotected as the default value?", 2633 "link-protection-type": "unprotected", 2634 "max-link-bandwidth": { 2635 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2636 }, 2637 "max-resv-link-bandwidth": { 2638 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2639 }, 2640 "unreserved-bandwidth": [ 2641 { 2642 "priority": 0, 2643 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2644 } 2645 ] 2646 }, 2647 "oper-status": "up", 2648 "// __EMPTY__ is-transitional": "It is not a transitio\ 2649 \nal link", 2650 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2651 \opology authors" 2652 }, 2653 "source": { 2654 "source-node": "10.0.0.1", 2655 "source-tp": 5 2656 }, 2657 "// __EMPTY__ destination": "inter-domain link" 2658 }, 2659 { 2660 "// __DESCRIPTION__:__LINK__": { 2661 "name": "Inter-domain Link from AN1-6", 2662 "type": "inter-domain link", 2663 "physical link": "Link from S7-4 to S11" 2664 }, 2665 "link-id": "teNodeId/10.0.0.1/teLinkId/6", 2666 "ietf-te-topology:te": { 2667 "te-link-attributes": { 2668 "name": "Inter-domain Link from AN1-6", 2669 "// __DISCUSS__ access-type": "Can we assume point-t\ 2670 \o-point as the default value?", 2671 "access-type": "point-to-point", 2672 "// __DISCUSS__ is-abstract": "To be discussed with \ 2673 \TE Topology authors", 2674 "// __DISCUSS__ underlay": "To be discussed with TE \ 2675 \Topology authors", 2676 "admin-status": "up", 2677 "interface-switching-capability": [ 2678 { 2679 "switching-capability": "ietf-te-types:switching\ 2680 \-otn", 2681 "encoding": "ietf-te-types:lsp-encoding-oduk", 2682 "max-lsp-bandwidth": [ 2683 { 2684 "priority": 0, 2685 "// __DISCUSS__ te-bandwidth": "ODU4" 2686 } 2687 ], 2688 "// __DISCUSS__ label-restrictions": "To be adde\ 2689 \d?" 2690 } 2691 ], 2692 "// __DISCUSS__ link-protection-type": "Can we assum\ 2693 \e unprotected as the default value?", 2694 "link-protection-type": "unprotected", 2695 "max-link-bandwidth": { 2696 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2697 }, 2698 "max-resv-link-bandwidth": { 2699 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2700 }, 2701 "unreserved-bandwidth": [ 2702 { 2703 "priority": 0, 2704 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2705 } 2706 ] 2707 }, 2708 "oper-status": "up", 2709 "// __EMPTY__ is-transitional": "It is not a transitio\ 2710 \nal link", 2711 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2712 \opology authors" 2713 }, 2714 "source": { 2715 "source-node": "10.0.0.1", 2716 "source-tp": 6 2717 }, 2718 "// __EMPTY__ destination": "inter-domain link" 2719 }, 2720 { 2721 "// __DESCRIPTION__:__LINK__": { 2722 "name": "Access Link from AN1-7", 2723 "type": "access link", 2724 "physical link": "Link from S6-2 to R3" 2725 }, 2726 "link-id": "teNodeId/10.0.0.1teLinkId/7", 2727 "ietf-te-topology:te": { 2728 "te-link-attributes": { 2729 "name": "Access Link from AN1-7", 2730 "// __DISCUSS__ access-type": "Can we assume point-t\ 2731 \o-point as the default value?", 2732 "access-type": "point-to-point", 2733 "// __DISCUSS__ is-abstract": "To be discussed with \ 2734 \TE Topology authors", 2735 "// __DISCUSS__ underlay": "To be discussed with TE \ 2736 \Topology authors", 2737 "admin-status": "up", 2738 "interface-switching-capability": [ 2739 { 2740 "switching-capability": "ietf-te-types:switching\ 2741 \-otn", 2742 "encoding": "ietf-te-types:lsp-encoding-oduk", 2743 "max-lsp-bandwidth": [ 2744 { 2745 "priority": 0, 2746 "// __DISCUSS__ te-bandwidth": "ODU2" 2747 } 2748 ], 2749 "// __DISCUSS__ label-restrictions": "To be adde\ 2750 \d?" 2751 } 2752 ], 2753 "// __DISCUSS__ link-protection-type": "Can we assum\ 2754 \e unprotected as the default value?", 2755 "link-protection-type": "unprotected", 2756 "max-link-bandwidth": { 2757 "// __DISCUSS__ te-bandwidth": "1xODU2" 2758 }, 2759 "max-resv-link-bandwidth": { 2760 "// __DISCUSS__ te-bandwidth": "1xODU2" 2761 }, 2762 "unreserved-bandwidth": [ 2763 { 2764 "priority": 0, 2765 "// __DISCUSS__ te-bandwidth": "1xODU2" 2766 } 2767 ] 2768 }, 2769 "oper-status": "up", 2770 "// __EMPTY__ is-transitional": "It is not a transitio\ 2771 \nal link", 2772 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2773 \opology authors" 2774 }, 2775 "source": { 2776 "source-node": "10.0.0.1", 2777 "source-tp": 7 2778 }, 2779 "// __EMPTY__ destination": "access link" 2780 } 2781 ] 2782 } 2783 ] 2784 } 2785 } 2787 B.2. JSON Examples for Service Configuration 2789 B.2.1. JSON Code: mpi1-odu2-service-config.json 2791 This is the JSON code reporting the ODU2 transit service 2792 configuration @ MPI: 2794 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 2796 { 2797 "// __TITLE__": "ODU2 Service Configuration @ MPI1", 2798 "// __LAST_UPDATE__": "October 22, 2018", 2799 "// __MISSING_ATTRIBUTES__": true, 2800 "// __REFERENCE_DRAFTS__": { 2801 "ietf-routing-types@2017-12-04": "rfc8294", 2802 "ietf-otn-types@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model-\ 2803 \02", 2804 "ietf-te-types@2018-07-01": "draft-ietf-teas-yang-te-16", 2805 "ietf-te@2018-07-01": "draft-ietf-teas-yang-te-16", 2806 "ietf-otn-tunnel@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model\ 2807 \-02" 2808 }, 2809 "// __RESTCONF_OPERATION__": { 2810 "operation": "PUT", 2811 "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te" 2812 }, 2813 "ietf-te:te": { 2814 "tunnels": { 2815 "tunnel": [ 2816 { 2817 "name": "mpi1-odu2-service", 2818 "// identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI1", 2819 "identifier": 1, 2820 "description": "ODU2 Service implemented by ODU2 OTN Tunne\ 2821 \l Segment @ MPI1", 2822 "// encoding and switching-type": "ODU", 2823 "encoding": "ietf-te-types:lsp-encoding-oduk ", 2824 "switching-type": "ietf-te-types:switching-otn", 2825 "// source": "None: transit tunnel segment", 2826 "// destination": "None: transit tunnel segment", 2827 "// src-tp-id": "None: transit tunnel segment", 2828 "// dst-tp-id": "None: transit tunnel segment", 2829 "// ietf-otn-tunnel:src-client-signal": "None: ODU transit\ 2830 \ tunnel segment", 2831 "// ietf-otn-tunnel:dst-client-signal": "None: ODU transit\ 2832 \ tunnel segment", 2833 "bidirectional": true, 2834 "// protection": "No protection", 2835 "// __ DEFAULT __ protection": { 2836 "// __ DEFAULT __ enable": false 2837 }, 2838 "// restoration": "No restoration", 2839 "// __ DEFAULT __ restoration": { 2840 "// __ DEFAULT __ enable": false 2841 }, 2842 "// te-topology-identifier": "ODU Black Topology @ MPI1", 2843 "te-topology-identifier": { 2844 "provider-id": 201, 2845 "client-id": 300, 2846 "topology-id": "otn-black-topology" 2847 }, 2848 "te-bandwidth": { 2849 "ietf-otn-tunnel:odu-type": "ietf-otn-types:prot-ODU2" 2850 }, 2851 "// hierarchical-link": "None: transit tunnel segment", 2852 "p2p-primary-paths": { 2853 "p2p-primary-path": [ 2854 { 2855 "name": "mpi1-odu2-service-primary-path", 2856 "path-scope": "ietf-te-types:path-scope-segment", 2857 "// te-bandwidth": "None: only the tunnel bandwidth \ 2858 \needs to be specified in transport applications", 2859 "explicit-route-objects": { 2860 "route-object-include-exclude": [ 2861 { 2862 "// comment": "Tunnel hand-off OTU2 ingress in\ 2863 \terface (S3-1)", 2864 "index": 1, 2865 "explicit-route-usage": "ietf-te-types:route-i\ 2866 \nclude-ero", 2867 "num-unnum-hop": { 2868 "// node-id": "AN1 Node", 2869 "node-id": "10.0.0.1", 2870 "// link-tp-id": "AN1-1 LTP", 2871 "link-tp-id": 1, 2872 "hop-type": "STRICT", 2873 "direction": "INCOMING" 2874 } 2875 }, 2876 { 2877 "// comment": "Tunnel hand-off ODU2 ingress la\ 2878 \bel (ODU2 over OTU2) at S3-1", 2879 "index": 2, 2880 "explicit-route-usage": "ietf-te-types:route-i\ 2881 \nclude-ero", 2883 Internet-Draft Transport NBI Applicability-Statement September 20199 2885 "label-hop": { 2886 "te-label": { 2887 "// __ DISCUSS __ odu-label": "How are HO-\ 2888 \ODU (ODUk over OTUk) label represented?", 2889 "// __ DISCUSS __ direction": "Check with \ 2890 \TE Tunnel authors", 2891 "direction": "FORWARD " 2892 } 2893 } 2894 }, 2895 { 2896 "// comment": "Tunnel hand-off OTU4 egress int\ 2897 \erface (S2-1)", 2898 "index": 3, 2899 "explicit-route-usage": "ietf-te-types:route-i\ 2900 \nclude-ero", 2901 "num-unnum-hop": { 2902 "// node-id": "AN1 Node", 2903 "node-id": "10.0.0.1", 2904 "// link-tp-id": "AN1-2 LTP", 2905 "link-tp-id": 1, 2906 "hop-type": "STRICT", 2907 "direction": "OUTGOING" 2908 } 2909 }, 2910 { 2911 "// comment": "Tunnel hand-off ODU2 egress lab\ 2912 \el (ODU2 over OTU4) at S2-1", 2913 "index": 4, 2914 "explicit-route-usage": "ietf-te-types:route-i\ 2915 \nclude-ero", 2916 "label-hop": { 2917 "te-label": { 2918 "ietf-otn-tunnel:tpn": 1, 2919 "ietf-otn-tunnel:tsg": "ietf-otn-types:tsg\ 2920 \-1.25G", 2921 "ietf-otn-tunnel:ts-list": "1-8", 2922 "// __ DISCUSS __ direction": "Check with \ 2923 \TE Tunnel authors", 2924 "direction": "FORWARD " 2925 } 2926 } 2927 } 2928 ] 2930 } 2931 } 2932 ] 2933 } 2934 } 2935 ] 2936 } 2937 } 2938 } 2940 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json 2942 The JSON code for this use case will be added in a future version of 2943 this document 2945 An incomplete version is located on GitHub at: 2947 https://github.com/danielkinguk/transport-nbi 2949 B.2.3. JSON Code: mpi1-epl-service-config.json 2951 The JSON code for this use case will be added in a future version of 2952 this document 2954 An incomplete version is located on GitHub at: 2956 https://github.com/danielkinguk/transport-nbi 2957 Authors' Addresses 2959 Italo Busi (Editor) 2960 Huawei 2962 Email: italo.busi@huawei.com 2964 Daniel King (Editor) 2965 Old Dog Consulting 2967 Email: daniel@olddog.co.uk 2969 Haomian Zheng (Editor) 2970 Huawei 2972 Email: zhenghaomian@huawei.com 2974 Yunbin Xu (Editor) 2975 CAICT 2977 Email: xuyunbin@ritt.cn 2979 Yang Zhao 2980 China Mobile 2982 Email: zhaoyangyjy@chinamobile.com 2984 Sergio Belotti 2985 Nokia 2987 Email: sergio.belotti@nokia.com 2989 Gianmarco Bruno 2990 Ericsson 2992 Email: gianmarco.bruno@ericsson.com 2993 Young Lee 2994 Sung Kyun Kwan University 2996 Email: younglee.tx@gmail.com 2998 Victor Lopez 2999 Telefonica 3001 Email: victor.lopezalvarez@telefonica.com 3003 Carlo Perocchio 3004 Ericsson 3006 Email: carlo.perocchio@ericsson.com 3008 Ricard Vilalta 3009 CTTC 3011 Email: ricard.vilalta@cttc.es 3013 Michael Scharf 3014 Hochschule Esslingen - University of Applied Sciences 3016 Email: michael.scharf@hs-esslingen.de