idnits 2.17.1 draft-ietf-ccamp-transport-nbi-app-statement-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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 1879: '... <=72-chars? MUST MAY...' RFC 2119 keyword, line 1881: '... valid JSON? MAY MUST ...' RFC 2119 keyword, line 1883: '... 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 (November 4, 2018) is 2000 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PKT' is mentioned on line 1087, but not defined == Missing Reference: 'ODU2' is mentioned on line 1086, but not defined == Missing Reference: 'ODU0' is mentioned on line 736, but not defined == Missing Reference: 'MAC' is mentioned on line 799, but not defined == Missing Reference: 'ODUflex' is mentioned on line 802, but not defined Summary: 1 error (**), 0 flaws (~~), 6 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 Lancaster University 5 H. Zheng 6 Huawei 7 Y. Xu 8 CAICT 10 Expires: May 2019 November 4, 2018 12 Transport Northbound Interface Applicability Statement 13 draft-ietf-ccamp-transport-nbi-app-statement-04 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on May 4, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 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 IETF (TEAS and CCAMP WGs in particular) to support OTN 70 single and multi-domain scenarios. 72 Table of Contents 74 1. Introduction...................................................4 75 1.1. The scope of this document................................4 76 1.2. Assumptions...............................................5 77 2. Terminology....................................................6 78 3. Conventions used in this document..............................7 79 3.1. Topology and traffic flow processing......................7 80 3.2. JSON code.................................................8 81 4. Scenarios Description..........................................9 82 4.1. Reference Network.........................................9 83 4.1.1. Single-Domain Scenario..............................12 84 4.2. Topology Abstractions....................................12 85 4.3. Service Configuration....................................14 86 4.3.1. ODU Transit.........................................15 87 4.3.2. EPL over ODU........................................16 88 4.3.3. Other OTN Clients Services..........................17 89 4.3.4. EVPL over ODU.......................................18 90 4.3.5. EVPLAN and EVPTree Services.........................19 91 4.3.6. Dynamic Service Configuration.......................20 92 4.4. Multi-function Access Links..............................21 93 4.5. Protection and Restoration Configuration.................22 94 4.5.1. Linear Protection (end-to-end)......................22 95 4.5.2. Segmented Protection................................23 96 4.5.3. End-to-End Dynamic restoration......................24 97 4.5.4. Segmented Dynamic Restoration.......................25 98 4.6. Service Modification and Deletion........................25 99 4.7. Notification.............................................25 100 4.8. Path Computation with Constraint.........................26 101 5. YANG Model Analysis...........................................27 102 5.1. YANG Models for Topology Abstraction.....................27 103 5.1.1. Domain 1 Black Topology Abstraction.................28 104 5.1.2. Domain 2 Black Topology Abstraction.................30 105 5.1.3. Domain 3 White Topology Abstraction.................30 106 5.1.4. Multi-domain Topology Stitching.....................31 107 5.1.5. Access Links........................................33 108 5.2. YANG Models for Service Configuration....................35 109 5.2.1. ODU Transit Service.................................37 110 5.2.1.1. Single Domain Example..........................39 111 5.2.2. EPL over ODU Service................................40 112 5.2.3. Other OTN Client Services...........................42 113 5.2.4. EVPL over ODU Service...............................42 114 5.3. YANG Models for Protection Configuration.................43 115 5.3.1. Linear Protection (end-to-end)......................43 116 5.3.2. Segmented Protection................................43 117 6. Security Considerations.......................................43 118 7. IANA Considerations...........................................44 119 8. References....................................................44 120 8.1. Normative References.....................................44 121 8.2. Informative References...................................45 122 9. Acknowledgments...............................................46 123 Appendix A. Validating a JSON fragment against a YANG Model...47 124 A.1. Manipulation of JSON fragments..........................47 125 A.2. Comments in JSON fragments..............................48 126 A.3. Validation of JSON fragments: DSDL-based approach.......48 127 A.4. Validation of JSON fragments: why not using a XSD-based 128 approach......................................................49 129 Appendix B. Detailed JSON Examples............................50 130 B.1. JSON Examples for Topology Abstractions.................50 131 B.1.1. JSON Code: mpi1-otn-topology.json.................50 132 B.2. JSON Examples for Service Configuration.................66 133 B.2.1. JSON Code: mpi1-odu2-service-config.json..........66 134 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json...........70 135 B.2.3. JSON Code: mpi1-epl-service-config.json...........70 137 1. Introduction 139 Transport of packet services are critical for a wide-range of 140 applications and services, including data center and LAN 141 interconnects, Internet service backhauling mobile backhaul and 142 enterprise Carrier Ethernet Services. These services are typically 143 setup using stovepipe NMS and EMS platforms, often requiring 144 propriety management platforms and legacy management interfaces. A 145 clear goal of operators will be to automate the setup of transport 146 services across multiple transport technology domains. 148 A common open interface (API) to each domain controller and or 149 management system is pre-requisite for network operators to control 150 multi-vendor and multi-domain networks and also enable service 151 provisioning coordination/automation. This can be achieved by using 152 standardized YANG models, used together with an appropriate protocol 153 (e.g., [RFC8040]). 155 This document analyses the applicability of the YANG models being 156 defined by IETF (TEAS and CCAMP WGs in particular) to support OTN 157 single and multi-domain scenarios. 159 1.1. The scope of this document 161 This document assumes a reference architecture, including interfaces, 162 based on the Abstraction and Control of Traffic-Engineered Networks 163 (ACTN), defined in [RFC8453]. 165 The focus of this document is on the MPI (interface between the Multi 166 Domain Service Coordinator (MDSC) and a Physical Network Controller 167 (PNC), controlling a transport network domain). 169 It is worth noting that the same MPI analyzed in this document could 170 be used between hierarchical MDSC controllers, as shown in Figure 4 171 of [RFC8453]. 173 Detailed analysis of the CMI (interface between the Customer Network 174 Controller (CNC) and the MDSC) as well as of the interface between 175 service and network orchestrators are outside the scope of this 176 document. However, some considerations and assumptions about the 177 information could be described when needed. 179 The relationship between the current IETF YANG models and the type of 180 ACTN interfaces can be found in [ACTN-YANG]. Therefore, it considers 181 the TE Topology YANG model defined in [TE-TOPO], with the OTN 182 Topology augmentation defined in [OTN-TOPO] and the TE Tunnel YANG 183 model defined in [TE-TUNNEL], with the OTN Tunnel augmentation 184 defined in [OTN-TUNNEL]. 186 The ONF Technical Recommendations for Functional Requirements for the 187 transport API in [ONF TR-527] and the ONF transport API multi-domain 188 examples in [ONF GitHub] have been considered as input for defining 189 the reference scenarios analyzed in this document. 191 1.2. Assumptions 193 This document is making the following assumptions, still to be 194 validated with TEAS WG: 196 1. The MDSC can request, at the MPI, a PNC to setup a Transit Tunnel 197 Segment using the TE Tunnel YANG model: in this case, since the 198 endpoints of the E2E Tunnel are outside the domain controlled by 199 that PNC, the MDSC would not specify any source or destination TTP 200 (i.e., it would leave the source, destination, src-tp-id and dst- 201 tp-id attributes empty) for the tunnel and it would use the 202 explicit-route-object/route-object-include-exclude list to specify 203 the ingress and egress links for each path of the Transit Tunnel 204 Segment. 206 2. Each PNC provides to the MDSC, at the MPI, the list of available 207 timeslots on the inter-domain links using the TE Topology YANG 208 model and OTN Topology augmentation. The TE Topology YANG model in 209 [TE-TOPO] is being updated to report the label set information. 211 This document is also making the following assumptions, still to be 212 validated with CCAMP WG: 214 1. The topology information for the Ethernet access links is modelled 215 using the YANG model defined in [CLIENT-TOPO]. 217 2. The service information for Ethernet and other OTN client layer 218 services are modelled using the YANG model defined in [Client- 219 Signal]. 221 Finally, the Network Elements (NEs) described in the scenarios used 222 in document are using ODU switching. It is assumed that the ODU links 223 are pre-configured and using mechanisms such as WDM wavelength, which 224 are outside the scope of this document. 226 2. Terminology 228 Domain: defined as a collection of network elements within a common 229 realm of address space or path computation responsibility [RFC5151] 231 E-LINE: Ethernet Line 233 EPL: Ethernet Private Line 235 EVPL: Ethernet Virtual Private Line 237 OTN: Optical Transport Network 239 Service: A service in the context of this document can be considered 240 as some form of connectivity between customer sites across the 241 network operator's network [RFC8309] 243 Service Model: As described in [RFC8309] it describes a service and 244 the parameters of the service in a portable way that can be used 245 uniformly and independent of the equipment and operating environment. 247 UNI: User Network Interface 249 MDSC: Multi-Domain Service Coordinator 251 CNC: Customer Network Controller 253 PNC: Provisioning Network Controller 255 MAC Bridging: Virtual LANs (VLANs) on IEEE 802.3 Ethernet network 257 3. Conventions used in this document 259 3.1. Topology and traffic flow processing 261 The traffic flow between different nodes is specified as an ordered 262 list of nodes, separated with commas, indicating within the brackets 263 the processing within each node: 265 (){, ()} 267 The order represents the order of traffic flow being forwarded 268 through the network. 270 The processing can be either an adaptation of a client layer into a 271 server layer "(client -> server)" or switching at a given layer 272 "([switching])". Multi-layer switching is indicated by two layer 273 switching with client/server adaptation: "([client] -> [server])". 275 For example, the following traffic flow: 277 R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), 278 R3 (ODU2 -> [PKT]) 280 Node R1 is switching at the packet (PKT) layer and mapping packets 281 into an ODU2 before transmission to node S3. Nodes S3, S5 and S6 are 282 switching at the ODU2 layer: S3 sends the ODU2 traffic to S5 which 283 then sends it to S6 which finally sends to R3. Node R3 terminates the 284 ODU2 from S6 before switching at the packet (PKT) layer. 286 The paths of working and protection transport entities are specified 287 as an ordered list of nodes, separated with commas: 289 {, } 291 The order represents the order of traffic flow being forwarded 292 through the network in the forward direction. In case of 293 bidirectional paths, the forward and backward directions are selected 294 arbitrarily, but the convention is consistent between 295 working/protection path pairs as well as across multiple domains. 297 3.2. JSON code 299 This document provides some detailed JSON code examples to describe 300 how the YANG models being developed by IETF (TEAS and CCAMP WG in 301 particular) can be used. 303 The examples are provided using JSON because JSON code is easier for 304 humans to read and write. 306 Different objects need to have an identifier. The convention used to 307 create mnemonic identifiers is to use the object name (e.g., S3 for 308 node S3), followed by its type (e.g., NODE), separated by an "-", 309 followed by "-ID". For example, the mnemonic identifier for node S3 310 would be S3-NODE-ID. 312 JSON language does not support the insertion of comments that have 313 been instead found to be useful when writing the examples. This 314 document will insert comments into the JSON code as JSON name/value 315 pair with the JSON name string starting with the "//" characters. For 316 example, when describing the example of a TE Topology instance 317 representing the ODU Abstract Topology exposed by the Transport PNC, 318 the following comment has been added to the JSON code: 320 "// comment": "ODU Abstract Topology @ MPI", 322 The JSON code examples provided in this document have been validated 323 against the YANG models following the validation process described in 324 Appendix A, which would not consider the comments. 326 In order to have successful validation of the examples, some 327 numbering scheme has been defined to assign identifiers to the 328 different entities which would pass the syntax checks. In that case, 329 to simplify the reading, another JSON name/value pair formatted as a 330 comment and using the mnemonic identifiers is also provided. For 331 example, the identifier of node S3 (S3-NODE-ID) has been assumed to 332 be "10.0.0.3" and would be shown in the JSON code example using the 333 two JSON name/value pair: 335 "// te-node-id": "S3-NODE-ID", 337 "te-node-id": "10.0.0.3", 339 The first JSON name/value pair will be automatically removed in the 340 first step of the validation process while the second JSON name/value 341 pair will be validated against the YANG model definitions. 343 4. Scenarios Description 345 4.1. Reference Network 347 The physical topology of the reference network is shown in Figure 1. 348 It represents an OTN network composed of three transport network 349 domains providing transport services to an IP customer network 350 through eight access links: 352 ........................ 353 .......... : : 354 : : Network domain 1 : ............. 355 Customer: : : : : 356 domain : : S1 -------+ : : Network : 357 : : / \ : : domain 3 : .......... 358 R1 ------- S3 ----- S4 \ : : : : 359 : : \ \ S2 --------+ : :Customer 360 : : \ \ | : : \ : : domain 361 : : S5 \ | : : \ : : 362 R2 ------+ / \ \ | : : S31 --------- R7 363 : : \ / \ \ | : : / \ : : 364 : : S6 ---- S7 ---- S8 ------ S32 S33 ------ R8 365 : : / | | : : / \ / : :....... 366 R3 ------+ | | : :/ S34 : : 367 : :..........|.......|...: / / : : 368 ........: | | /:.../.......: : 369 | | / / : 370 ...........|.......|..../..../... : 371 : | | / / : .............. 372 : Network | | / / : : 373 : domain 2 | | / / : :Customer 374 : S11 ---- S12 / : : domain 375 : / | \ / : : 376 : S13 S14 | S15 ------------- R4 377 : | \ / \ | \ : : 378 : | S16 \ | \ : : 379 : | / S17 -- S18 --------- R5 380 : | / \ / : : 381 : S19 ---- S20 ---- S21 ------------ R6 382 : : : 383 :...............................: :............. 385 Figure 1 - Reference network 387 This document assumes that all the transport network switching nodes 388 Si are OTN switching nodes capable of switching in the electrical 389 domain (ODU switching) and that all the Si-Sj OTN links within the 390 transport network (intra-domain or inter-domain) are 100G links while 391 the access Ri-Sj links are 10G links. Different technologies can be 392 used at the access links (e.g., Ethernet, STM-n, OTN). 394 It is also assumed that, within the transport network, the 395 physical/optical interconnections supporting the Si-Sj OTN links (up 396 to the OTU4 trail), are pre-configured using mechanisms which are 397 outside the scope of this document and are not exposed at the MPIs to 398 the MDSC. 400 The transport domain control architecture, shown in Figure 2, follows 401 the ACTN architecture and framework document [RFC8453], and 402 functional components: 404 -------------- 405 | | 406 | CNC | 407 | | 408 -------------- 409 | 410 ....................|....................... CMI 411 | 412 ---------------- 413 | | 414 | MDSC | 415 | | 416 ---------------- 417 / | \ 418 / | \ 419 ............../.....|......\................ MPIs 420 / | \ 421 / ---------- \ 422 / | PNC2 | \ 423 / ---------- \ 424 ---------- | \ 425 | PNC1 | ----- \ 426 ---------- ( ) ---------- 427 | ( ) | PNC3 | 428 ----- ( Network ) ---------- 429 ( ) ( Domain 2 ) | 430 ( ) ( ) ----- 431 ( Network ) ( ) ( ) 432 ( Domain 1 ) ----- ( ) 433 ( ) ( Network ) 434 ( ) ( Domain 3 ) 435 ----- ( ) 436 ( ) 437 ----- 439 Figure 2 - Controlling Hierarchy 441 The ACTN framework facilitates the detachment of the network and 442 service control from the underlying technology and helps the customer 443 express the network as desired by business needs. Therefore, care 444 must be taken to keep a minimal dependency on the CMI (or no 445 dependency at all) with respect to the network domain technologies. 446 The MPI instead requires some specialization according to the domain 447 technology. 449 This document assumes that the CNC controls the customer IP network 450 and requests, at the CMI, transport connectivity between IP routers. 451 The MDSC coordinates, via three MPIs, the control of a multi-domain 452 transport network through three PNCs. 454 The control interfaces within the scope of this document are the 455 three MPIs, while the control interface(s) between the CNC and the IP 456 routers is outside the scope of this document. It is also assumed 457 that the CMI allows the CNC to provide all the information that is 458 required by the MDSC to properly configure the transport connectivity 459 requested by the customer. 461 In case the CNC requests transport connectivity between IP routers 462 attached to different transport domains (e.g., between R1 and R5), 463 the MDSC coordinates the setup of a multi-domain end-to-end OTN 464 connection across multiple PNCs (e.g., PNC1, PNC2 and PNC3 in in 465 Figure 2) as well as the configuration of the client signal mapping 466 at the PNCs controlling the edge domains (e.g., PNC1 and PNC2 in 467 Figure 2). 469 4.1.1. Single-Domain Scenario 471 In case the CNC requests transport connectivity between IP routers 472 attached to the same transport domain (e.g., between R1 and R3 in 473 Figure 1), the MDSC can request the PNC controlling that domain 474 (e.g., PNC1 in Figure 2) to setup an intra-domain end-to-end OTN 475 connection and configure the client signal mapping. 477 Alternatively, the MDSC can just configure the client signal mapping 478 and let the PNC take decisions about how to implement the service 479 (e.g., setting up the intra-domain end-to-end OTN connection). 481 4.2. Topology Abstractions 483 Abstraction provides a selective method for representing connectivity 484 information within a domain. There are multiple methods to abstract a 485 network topology. This document assumes the abstraction method 486 defined in [RFC7926]: 488 "Abstraction is the process of applying the policy to the available 489 TE information within a domain, to produce selective information 490 that represents the potential ability to connect across the domain. 491 Thus, abstraction does not necessarily offer all possible 492 connectivity options, but presents a general view of potential 493 connectivity according to the policies that determine how the 494 domain's administrator wants to allow the domain resources to be 495 used." 497 [RFC8453] Provides the context of topology abstraction in the ACTN 498 architecture and discusses a few alternatives for the abstraction 499 methods for both packet and optical networks. This is an important 500 consideration since the choice of the abstraction method impacts 501 protocol design and the information it carries. According to 502 [RFC8453], there are three types of topology: 504 o White topology: This is a case where the PNC provides the actual 505 network topology to the MDSC without any hiding or filtering. In 506 this case, the MDSC has the full knowledge of the underlying 507 network topology; 509 o Black topology: The entire domain network is abstracted as a 510 single virtual node with the access/egress links without 511 disclosing any node internal connectivity information; 513 o Grey topology: This abstraction level is between black topology 514 and white topology from a granularity point of view. This is an 515 abstraction of TE tunnels for all pairs of border nodes. We may 516 further differentiate from a perspective of how to abstract 517 internal TE resources between the pairs of border nodes: 519 - Grey topology type A: border nodes with TE links between them 520 in a full mesh fashion; 522 - Grey topology type B: border nodes with some internal 523 abstracted nodes and abstracted links. 525 Each PNC should provide the MDSC with a topology abstraction of the 526 domain's network topology. 528 Each PNC provides topology abstraction of its own domain topology 529 independently from each other, and therefore it is possible that 530 different PNCs provide different types of topology abstractions. 532 The MPI operates on the abstract topology regardless of, and 533 independently from, the type of abstraction provided by the PNC. 535 To analyze how the MPI operates on abstract topologies independently 536 from the topology abstraction provided by each PNC and, therefore, 537 that different PNCs can provide different topology abstractions, that 538 the following examples are assumed: 540 o PNC1 provides a black topology abstraction which exposes at MPI1 a 541 single virtual node (representing the whole network domain 1). 543 o PNC2 provides a black topology abstraction which exposes at MPI2 a 544 single virtual node (representing the whole network domain 2). 546 o PNC3 provides a white topology abstraction which exposes at MPI3 547 all the physical nodes and links within network domain 3. 549 The MDSC should be capable of stitching together each abstracted 550 topology to build its own view of the multi-domain network topology. 551 The process may require suitable oversight, including administrative 552 configuration and trust models, but this is out of scope for this 553 document. 555 The MDSC can also provide topology abstraction of its own view of the 556 multi-domain network topology at its CMIs depending on the customers' 557 needs: it can provide different types of topology abstractions at 558 different CMIs. 560 4.3. Service Configuration 562 In the following scenarios, it is assumed that the CNC is capable of 563 requesting service connectivity from the MDSC to support IP routers 564 connectivity. 566 The type of services could depend on the type of physical links (e.g. 567 OTN link, ETH link or SDH link) between the routers and transport 568 network. 570 The control of different adaptations inside IP routers, Ri (PKT -> 571 foo) and Rj (foo -> PKT), are assumed to be performed by means that 572 are not under the control of, and not visible to, the MDSC nor to the 573 PNCs. Therefore, these mechanisms are outside the scope of this 574 document. 576 It is just assumed that the CNC is capable of requesting the proper 577 configuration of the different adaptation functions inside the 578 customer's IP routers, by means which are outside the scope of this 579 document. 581 4.3.1. ODU Transit 583 The physical links interconnecting the IP routers and the transport 584 network can be 10G OTN links. In this case, it is assumed that the 585 physical/optical interconnections below the ODU layer (up to the OTU2 586 trail) are pre-configured using mechanisms which are outside the 587 scope of this document and not exposed at the MPIs between the PNCs 588 and the MDSC. For simplicity of the description, it is also assumed 589 that these interfaces are not channelized (i.e., they can only 590 support one ODU2). 592 To setup a 10Gb IP link between R1 and R5, an ODU2 end-to-end 593 connection needs be created in the data plane between R1 and R5, 594 through transport nodes S3, S1, S2, S31, S33, S34, S15 and S18 which 595 belong to different PNC domains (multi-domain service request): 597 R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), 598 S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 599 S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT]) 601 It is assumed that, at the CMI, the CNC requests, using mechanisms 602 which are outside the scope of this document, the MDSC to setup of an 603 ODU2 transit service between the access links on S3 and S8 and that 604 the MDSC understands that it shall setup an ODU2 segment connection 605 between the access links on S3 and S18, which belongs to different 606 PNC domains (multi-domain service request). 608 To setup of a 10Gb IP link between R1 and R3, an ODU2 end-to-end 609 connection needs are created in the data plane between R1 and R3, 610 through transport nodes S3, S5 and S6 which belong to the same PNC 611 domain (single-domain service request): 613 R1 ([PKT] -> ODU2), S3 ([ODU2]), S5 ([ODU2]), S6 ([ODU2]), 614 R3 (ODU2 -> [PKT]) 616 Since the CNC is not aware of the transport network controlling 617 hierarchy, the mechanisms used by the CNC to request at the CMI the 618 MDSC to setup an ODU2 transit service are independent on whether the 619 service request is single-domain or multi-domain. 621 Based on the assumption above, the MDSC understands that it shall 622 setup an ODU2 segment connection between the access links on S3 and 623 S6, which belong to the same PNC domain (single-domain service 624 request) and it can just pass the request at the MPI to PNC1 to setup 625 a single-domain ODU2 segment connection between its access links on 626 S3 and S6. 628 4.3.2. EPL over ODU 630 The physical links interconnecting the IP routers and the transport 631 network can be Ethernet physical links. 633 To setup a 10Gb IP link between R1 and R5, an EPL service needs to be 634 created between R1 and R5, supported by an ODU2 end-to-end connection 635 in the data plane between transport nodes S3 and S18, through 636 transport nodes S1, S2, S31, S33, S34 and S15, which belong to 637 different PNC domains (multi-domain service request: 639 R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), 640 S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 641 S15 ([ODU2]), S18 ([ODU2] -> ETH), R5 (ETH -> [PKT]) 643 Based on the assumptions described in section 4.3.1, the CNC requests 644 at the CMI the MDSC to setup an EPL service between the access links 645 on S3 and S8 and the MDSC understands that it shall setup an ODU2 646 end-to-end connection between nodes S3 and S18, which belongs to 647 different PNC domains (multi-domain service request). The MDSC also 648 understands how the adaptation functions inside nodes S3 and S18 649 (i.e., S3 (ETH -> [ODU2]), S18 ([ODU2] -> ETH), S18 (ETH -> [ODU2]) 650 and S3 ([ODU2] -> ETH)) should be configured. 652 To setup a 10Gb IP link between R1 and R3, an EPL service needs to be 653 created between R1 and R3, supported by an ODU2 end-to-end connection 654 in the data plane between transport nodes S3 and S6, through the 655 transport node S5, which belong to the same PNC domain (single-domain 656 service request): 658 R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S5 ([ODU2]), 659 S6 ([ODU2] -> ETH), R3 (ETH-> [PKT]) 661 As described in section 4.3.1, the mechanisms used by the CNC at the 662 CMI are independent on whether the service request is single-domain 663 service or multi-domain. 665 Based on the assumption above, the MDSC understands that it shall 666 setup an EPL service between the access links on S3 and S6, which 667 belong to the same PNC domain (single-domain service request) and it 668 can just pass the request at the MPI to PNC1 to setup a single-domain 669 EPL service its access links on S3 and S6. In this case, PNC1 can 670 take care of setting up the single-domain ODU2 end-to-end connection 671 between nodes S3 and S6 as well as of configuring the adaptation 672 functions on these edge nodes. 674 4.3.3. Other OTN Clients Services 676 [ITU-T G.709] defines mappings of different client layers into ODU. 677 Most of them are used to provide Private Line services over an OTN 678 transport network supporting a variety of types of physical access 679 links (e.g., Ethernet, SDH STM-N, Fibre Channel, InfiniBand, etc.). 681 The physical links interconnecting the IP routers and the transport 682 network can be any of these types. 684 In order to setup a 10Gb IP link between R1 and R5 using, for example 685 SDH physical links between the IP routers and the transport network, 686 an STM-64 Private Line service needs to be created between R1 and R5, 687 supported by an ODU2 end-to-end connection in the data plane between 688 transport nodes S3 and S18, through transport nodes S1, S2, S31, S33, 689 S34 and S15, which belong to different PNC domains (multi-domain 690 service request): 692 R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), 693 S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 694 S15 ([ODU2]), S18 ([ODU2] -> STM-64), R5 (STM-64 -> [PKT]) 696 Based on the assumptions described in section 4.3.1, the CNC requests 697 the CMI the MDSC to setup an STM-64 Private Line service between the 698 access links on S3 and S8 and the MDSC understands what to do as 699 described in section 4.3.2 (multi-domain service request). 701 To setup a 10Gb IP link between R1 and R3), an STM-64 Private Line 702 service needs to be created between R1 and R3 (single-domain service 703 request): 705 R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S5 ([ODU2]), 706 S6 ([ODU2] -> STM-64), R3 (STM-64 -> [PKT]) 708 As described in section 4.3.1, the mechanisms used by the CNC at the 709 CMI are independent on whether the service request is single-domain 710 or multi-domain. 712 As described in section 4.3.2, the MDSC can just pass the request at 713 the MPI to PNC1 to setup a single-domain STM-64 Private Line service 714 between it access links on S3 and S6. 716 4.3.4. EVPL over ODU 718 When the physical links interconnecting the IP routers and the 719 transport network are Ethernet physical links, it is also possible 720 that different Ethernet services (e.g., EVPL) can share the same 721 physical access link using different VLANs. 723 To setup two 1Gb IP links between R1 to R3 and between R1 and R5, two 724 EVPL services need to be created, supported by two ODU0 end-to-end 725 connections in the data plane respectively between transport nodes S3 726 and S6, through transport node S5, which belong ot the same PNC 727 domain (single-domain service request) and between transport nodes S3 728 and S18, through transport nodes S1, S2, S31, S33, S34 and S15, which 729 belong to different PNC domains (multi-domain service request): 731 R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S1 ([ODU0]), 732 S2 ([ODU0]), S31 ([ODU0]), S33 ([ODU0]), S34 ([ODU0]), 733 S15 ([ODU0]), S18 ([ODU0] -> VLAN), R5 (VLAN -> [PKT]) 735 R1 ([PKT] -> VLAN), S3 (VLAN -> [ODU0]), S5 ([ODU0]), 736 S6 ([ODU0] -> VLAN), R3 (VLAN -> [PKT]) 738 Since the two EVPL services are sharing the same Ethernet physical 739 link between R1 and S3, different VLAN IDs are associated with 740 different EVPL services: for example, VLAN IDs 10 and 20 741 respectively. 743 Based on the assumptions described in section 4.3.1, the CNC requests 744 at the CMI the MDSC to setup these EVPL services and the MDSC 745 understands what to do as described in section 4.3.2. 747 4.3.5. EVPLAN and EVPTree Services 749 When the physical links interconnecting the IP routers and the 750 transport network are Ethernet links, multipoint Ethernet services 751 (e.g., EPLAN and EPTree) can also be supported. It is also possible 752 that multiple Ethernet services (e.g., EVPL, EVPLAN and EVPTree) 753 share the same physical link using different VLANs. 755 Note - it is assumed that EPLAN and EPTree services can be supported 756 by configuring EVPLAN and EVPTree with port mapping. 758 Since this EVPLAN/EVPTree service can share the same Ethernet 759 physical links between IP routers and transport nodes (e.g., with the 760 EVPL services described in section 4.3.4), a different VLAN ID (e.g., 761 30) can be associated with this EVPLAN/EVPTree service. 763 In order to setup an IP subnet between R1, R2, R3 and R5, an 764 EVPLAN/EVPTree service needs to be created, supported by two ODUflex 765 end-to-end connections respectively between S3 and S6, crossing 766 transport node S5, and between S3 and S18, crossing transport nodes 767 S1, S2, S31, S33, S34 and S15 which belong to different PNC domains. 769 Some MAC Bridging capabilities are also required on some nodes at the 770 edge of the transport network: for example, Ethernet Bridging 771 capabilities can be configured in nodes S3 and S6: 773 o MAC Bridging in node S3 is needed to select, based on the MAC 774 Destination Address, whether received Ethernet frames should be 775 forwarded to R1 or to the ODUflex terminating on node S6 or to the 776 other ODUflex terminating on node S18; 778 o MAC bridging function in node S6 is needed to select, based on the 779 MAC Destination Address, whether received Ethernet frames should 780 be sent to R2 or to R3 or to the ODUflex terminating on node S3. 782 In order to support an EVPTree service instead of an EVPLAN, 783 additional configuration of the Ethernet Bridging capabilities on the 784 nodes at the edge of the transport network is required. 786 The traffic flows between R1 and R3, between R3 and R5 and between R1 787 and R5 can be summarized as: 789 R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), 790 S5 ([ODUflex]), S6 ([ODUflex] -> [MAC] -> VLAN), 791 R3 (VLAN -> [PKT]) 793 R3 ([PKT] -> VLAN), S6 (VLAN -> [MAC] -> [ODUflex]), 794 S5 ([ODUflex]), S3 ([ODUflex] -> [MAC] -> [ODUflex]), 795 S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]), 796 S33 ([ODUflex]), S34 ([ODUflex]), 797 S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT]) 799 R1 ([PKT] -> VLAN), S3 (VLAN -> [MAC] -> [ODUflex]), 800 S1 ([ODUflex]), S2 ([ODUflex]), S31 ([ODUflex]), 801 S33 ([ODUflex]), S34 ([ODUflex]), 802 S15 ([ODUflex]), S18 ([ODUflex] -> VLAN), R5 (VLAN -> [PKT]) 804 As described in section 4.3.2, it is assumed that the CNC is capable, 805 via the CMI, to request the setup of this EVPLAN/EVPTree service, 806 providing all the information that the MDSC needs to understand that 807 it need to request PNC1 to setup an ODUflex connection between nodes 808 S3 and S6 (single-domain service request) and it also needs to 809 coordinate the setup of a multi-domain ODUflex connection between 810 nodes S3 and S16 as well as the MAC bridging and the adaptation 811 functions on these edge nodes. 813 In case the CNC needs the setup of an EVPLAN/EVPTree service only 814 between R1, R2 and R3 (single-domain service request), it would 815 request the setup of this service in the same way as before and the 816 information provided at the CMI is sufficient for the MDSC to 817 understand that this is a single-domain service request. 819 The MDSC can then just request PNC1 to setup a single-domain 820 EVPLAN/EVPTree service between nodes S3 and S6. PNC1 can take care of 821 setting up the single-domain ODUflex end-to-end connection between 822 nodes S3 and S6 as well as of configuring the MAC bridging and the 823 adaptation functions on these edge nodes. 825 4.3.6. Dynamic Service Configuration 827 Given the service established in the previous sections, there is a 828 demand for an update of some service characteristics. A 829 straightforward approach would be terminate the current service and 830 replace with a new one. Another more advanced approach would be a 831 dynamic configuration, in which case there will be no interruption 832 for the connection. 834 An example application would be updating the SLA information for a 835 certain connection. For example, an ODU transit connection is set up 836 according to section 4.3.1, with the corresponding SLA level of 'no 837 protection'. After the establishment of this connection, the user 838 would like to enhance this service by providing a restoration after 839 potential failure, and a request is generated on the CMI. In this 840 case, after receiving the request, the MDSC would need to send an 841 update message to the PNC, changing the SLA parameters in TE Tunnel 842 model. Then the connection characteristic would be changed by PNC, 843 and a notification would be sent to MDSC for acknowledgement. 845 4.4. Multi-function Access Links 847 Some physical links interconnecting the IP routers and the transport 848 network can be configured in different modes, e.g., as OTU2 or STM-64 849 or 10GE. 851 This configuration can be done a-priori by means outside the scope of 852 this document. In this case, these links will appear at the MPI 853 either as an ODU Link or as an STM-64 Link or as a 10GE Link 854 (depending on the a-priori configuration) and will be controlled at 855 the MPI as discussed in section 4.3. 857 It is also possible not to configure these links a-priori and give 858 the control to the MPI to decide, based on the service configuration, 859 how to configure it. 861 For example, if the physical link between R1 and S3 is a multi- 862 functional access link while the physical links between R7 and S31 863 and between R5 and S18 are STM-64 and 10GE physical links 864 respectively, it is possible to configure either an STM-64 Private 865 Line service between R1 and R7 or an EPL service between R1 and R5. 867 The traffic flow between R1 and R7 can be summarized as: 869 R1 ([PKT] -> STM-64), S3 (STM-64 -> [ODU2]), S1 ([ODU2]), 870 S2 ([ODU2]), S31 ([ODU2] -> STM-64), R3 (STM-64 -> [PKT]) 872 The traffic flow between R1 and R5 can be summarized as: 874 R1 ([PKT] -> ETH), S3 (ETH -> [ODU2]), S1 ([ODU2]), 875 S2 ([ODU2]), S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 876 S15 ([ODU2]), S18 ([ODU2] -> ETH), R5 (ETH -> [PKT]) 878 As described in section 4.3.2, it is assumed that the CNC is capable, 879 via the CMI, to request the setup either an STM-64 Private Line 880 service between R1 and R7 or an EPL service between R1 and R5, 881 providing all the information that the MDSC needs to understand that 882 it needs to coordinate the setup of a multi-domain ODU2 connection, 883 either between nodes S3 and S31, or between nodes S3 and S18, as well 884 as the adaptation functions on these edge nodes, and in particular 885 whether the multi-function access link on between R1 and S3 should 886 operate as an STM-64 or as a 10GE link. 888 4.5. Protection and Restoration Configuration 890 Protection switching provides a pre-allocated survivability 891 mechanism, typically provided via linear protection methods and would 892 be configured to operate as 1+1 unidirectional (the most common OTN 893 protection method), 1+1 bidirectional or 1:n bidirectional. This 894 ensures fast and simple service survivability. 896 Restoration methods would provide the capability to reroute and 897 restore connectivity traffic around network faults, without the 898 network penalty imposed with dedicated 1+1 protection schemes. 900 This section describes only services which are protected with linear 901 protection and with dynamic restoration. 903 The MDSC needs to be capable of coordinating different PNCs to 904 configure protection switching when requesting the setup of the 905 protected connectivity services described in section 4.3. 907 Since in these service examples, switching within the transport 908 network domain is performed only in the OTN ODU layer. Also 909 protection switching within the transport network domain can only be 910 provided at the OTN ODU layer. 912 4.5.1. Linear Protection (end-to-end) 914 In order to protect any service defined in section 4.3 from failures 915 within the OTN multi-domain transport network, the MDSC should be 916 capable of coordinating different PNCs to configure and control OTN 917 linear protection in the data plane between nodes S3 and node S18. 919 It is assumed that the OTN linear protection is configured to with 920 1+1 unidirectional protection switching type, as defined in [ITU-T 921 G.808.1] and [ITU-T G.873.1], as well as in [RFC4427]. 923 In these scenarios, a working transport entity and a protection 924 transport entity, as defined in [ITU-T G.808.1], (or a working LSP 925 and a protection LSP, as defined in [RFC4427]) should be configured 926 in the data plane. 928 Two cases can be considered: 930 o In one case, the working and protection transport entities pass 931 through the same PNC domains: 933 Working transport entity: S3, S1, S2, 934 S31, S33, S34, 935 S15, S18 937 Protection transport entity: S3, S4, S8, 938 S32, 939 S12, S17, S18 941 o In another case, the working and protection transport entities can 942 pass through different PNC domains: 944 Working transport entity: S3, S5, S7, 945 S11, S12, S17, S18 947 Protection transport entity: S3, S1, S2, 948 S31, S33, S34, 949 S15, S18 951 The PNCs should be capable to report to the MDSC which is the active 952 transport entity, as defined in [ITU-T G.808.1], in the data plane. 954 Given the fast dynamic of protection switching operations in the data 955 plane (50ms recovery time), this reporting is not expected to be in 956 real-time. 958 It is also worth noting that with unidirectional protection 959 switching, e.g., 1+1 unidirectional protection switching, the active 960 transport entity may be different in the two directions. 962 4.5.2. Segmented Protection 964 To protect any service defined in section 4.3 from failures within 965 the OTN multi-domain transport network, the MDSC should be capable of 966 requesting each PNC to configure OTN intra-domain protection when 967 requesting the setup of the ODU2 data plane connection segment. 969 If PNC1 provides linear protection, the working and protection 970 transport entities could be: 972 Working transport entity: S3, S1, S2 974 Protection transport entity: S3, S4, S8, S2 976 If PNC2 provides linear protection, the working and protection 977 transport entities could be: 979 Working transport entity: S15, S18 981 Protection transport entity: S15, S12, S17, S18 983 If PNC3 provides linear protection, the working and protection 984 transport entities could be: 986 Working transport entity: S31, S33, S34 988 Protection transport entity: S31, S32, S34 990 4.5.3. End-to-End Dynamic restoration 992 To restore any service defined in section 4.3 from failures within 993 the OTN multi-domain transport network, the MDSC should be capable of 994 coordinating different PNCs to configure and control OTN end-to-end 995 dynamic Restoration in the data plane between nodes S3 and node S18. 996 For example, the MDSC can request the PNC1, PNC2 and PNC3 to create a 997 service with no-protection, MDSC set the end-to-end service with the 998 dynamic restoration. 1000 Working transport entity: S3, S1, S2, 1001 S31, S33, S34, 1002 S15, S18 1004 When a link failure between S1 and s2 occurred in network domain 1, 1005 PNC1 does not restore the tunnel and send the alarm notification to 1006 the MDSC, MDSC will perform the end-to-end restoration. 1008 Restored transport entity: S3, S4, S8, 1009 S12, S15, S18 1011 4.5.4. Segmented Dynamic Restoration 1013 To restore any service defined in section 4.3 from failures within 1014 the OTN multi-domain transport network, the MDSC should be capable of 1015 coordinating different PNCs to configure and control OTN segmented 1016 dynamic Restoration in the data plane between nodes S3 and node S18. 1018 Working transport entity: S3, S1, S2, 1019 S31, S33, S34, 1020 S15, S18 1022 When a link failure between S1 and s2 occurred in network domain 1, 1023 PNC1 will restore the tunnel and send the alarm or tunnel update 1024 notification to the MDSC, MDSC will update the restored tunnel. 1026 Restored transport entity: S3, S4, S8, S2 1027 S31, S33, S34, 1028 S15, S18 1030 When a link failure between network domain 1 and network domain 2 1031 occurred, PNC1 and PNC2 will send the alarm notification to the MDSC, 1032 MDSC will update the restored tunnel. 1034 Restored transport entity: S3, S4, S8, 1035 S12, S15, S18 1037 In order to improve the efficiency of recovery, the controller can 1038 establish a recovery path in a concurrent way. When the recovery 1039 fails in one domain or one network element, the rollback operation 1040 should be supported. 1042 The creation of the recovery path by the controller can use the 1043 method of "make-before-break", in order to reduce the impact of the 1044 recovery operation on the services. 1046 4.6. Service Modification and Deletion 1048 To be discussed in future versions of this document. 1050 4.7. Notification 1052 To realize the topology update, service update and restoration 1053 function, following notification type should be supported. 1055 1. Object create 1057 2. Object delete 1059 3. Object state change 1061 4. Alarm 1063 Because there are three types of topology abstraction type defined in 1064 section 4.2, the notification should also be abstracted. The PNC and 1065 MDSC should coordinate together to determine the notification policy, 1066 such as when an intra-domain alarm occurred, the PNC may not report 1067 the alarm but the service state change notification to the MDSC. 1069 4.8. Path Computation with Constraint 1071 It is possible to have constraint during path computation procedure; 1072 typical cases include IRO/XRO and so on. This information is carried 1073 in the TE Tunnel model and used when there is a request with 1074 constraint. Consider the example in section 4.3.1. , the request can 1075 be a Tunnel from R1 to R5 with an IRO from S2 to S31, then qualified 1076 feedback would become: 1078 R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), 1079 S31 ([ODU2]), S33 ([ODU2]), S34 ([ODU2]), 1080 S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> [PKT]) 1082 If the request covers the IRO from S8 to S12, then the above path 1083 would not be qualified, while a possible computation result may be: 1085 R1 ([PKT] -> ODU2), S3 ([ODU2]), S1 ([ODU2]), S2 ([ODU2]), 1086 S8 ([ODU2]), S12 ([ODU2]), S15 ([ODU2]), S18 ([ODU2]), R5 (ODU2 -> 1087 [PKT]) 1089 Similarly, the XRO can be represented by the TE tunnel model as well. 1091 When there is a technology specific network (e.g., OTN), the 1092 corresponding technology (OTN) model should also be used to specify 1093 the tunnel information on MPI, with the constraint included in TE 1094 Tunnel model. 1096 5. YANG Model Analysis 1098 This section provides a high-level overview of how IETF YANG models 1099 can be used at the MPIs, between the MDSC and the PNCs, to support 1100 the scenarios described in section 4. 1102 Section 5.1 describes the different topology abstractions provided to 1103 the MDSC by each PNC via its own MPI. 1105 Section 5.2 describes how the MDSC can coordinate different requests 1106 to different PNCs, via their own MPIs, to setup the different 1107 services described in section 4.3. 1109 Section 5.3 describes how the protection scenarios can be deployed, 1110 including end-to-end protection and segment protection, for both 1111 intra-domain and inter-domain scenario. 1113 5.1. YANG Models for Topology Abstraction 1115 Each PNC reports its respective abstract topology to the MDSC, as 1116 described in section 4.2. 1118 5.1.1. Domain 1 Black Topology Abstraction 1120 PNC1 provides the required black topology abstraction, as described 1121 in section 4.2, to expose to the MDSC, at MPI1, one TE Topology 1122 instance for the ODU layer (MPI1 OTN Topology) containing only one 1123 abstract TE node (i.e., AN1) and only inter-domain and access 1124 abstract TE links (which represent the inter-domain and access 1125 physical links), as shown in Figure 3 below. 1127 ................................... 1128 : : 1129 : +-----------------+ : 1130 : | | : 1131 (R1)- - --------| |-------- - -(S31) 1132 : AN1-1 | | AN1-2 : 1133 : | | : 1134 (R2)- - --------| | : 1135 : AN1-3 | AN1 | : 1136 : | | : 1137 (R3)- - --------| |-------- - -(S32) 1138 : AN1-7 | | AN1-4 : 1139 : | | : 1140 : +-----------------+ : 1141 : | | : 1142 : AN1-6 | | AN1-5 : 1143 :..........|..........|...........: 1145 | | 1146 (S11) (S12) 1148 Figure 3 - Abstract Topology exposed at MPI1 (MPI1 OTN Topology) 1150 As described in section 4.1, it is assumed that the physical links 1151 between the physical nodes are pre-configured and therefore PNC1 1152 exports at MPI1 one abstract TE Link, within the MPI1 OTN topology, 1153 for each OTU2 or OTU4 trail which support an abstract TE link in the 1154 MPI1 ODU Topology. 1156 .................................. 1157 : : 1158 : ODU Abstract Topology @ MPI : 1159 : Gotham City Area : 1160 : Metro Transport Network : 1161 : : 1162 : +----+ +----+ : 1163 : | |S1-1 | |S2-1: 1164 : | S1 |--------| S2 |----- - -(S31) 1165 : +----+ S2-2+----+ : 1166 : S1-2/ |S2-3 : 1167 : S3-2/ Robinson Park | : 1168 : +----+ +----+ | : 1169 : | |3 1| | | : 1170 (R1)- - -----| S3 |---| S4 | | : 1171 :S3-1+----+ +----+ | : 1172 : S3-4 \ \S4-2 | : 1173 : \S5-1 \ | : 1174 : +----+ \ | : 1175 : | | \S8-3| : 1176 : | S5 | \ | : 1177 : +----+ Metro \ |S8-2 : 1178 (R2)- - ------ 2/ E \3 Main \ | : 1179 :S6-1 \ /3 a E \1 Ring \| : 1180 : +----+s-n+----+ +----+ : 1181 : | |t d| | | |S8-1: 1182 : | S6 |---| S7 |---| S8 |----- - -(S32) 1183 : +----+4 2+----+3 4+----+ : 1184 : / | | : 1185 (R3)- - ------ S7-4 | | S8-5 : 1186 :S6-2 | | : 1187 :...............|........|.......: 1189 | | 1190 (S11) (S12) 1192 Figure 4 - Physical Topology discovered by PNC1 1194 LTP mapping table: 1196 AN1-1 -> S3-1 1198 AN1-2 -> S2-1 1199 AN1-3 -> S6-1 1201 AN1-4 -> S8-1 1203 AN1-5 -> S8-5 1205 AN1-6 -> S7-4 1207 AN1-7 -> S6-2 1209 Appendix B.1.1 provides the detailed JSON code example ("mpi1-otn- 1210 topology.json") describing how this ODU Topology is reported by the 1211 PNC, using the [TE-TOPO] and [OTN-TOPO] YANG models at MPI1. 1213 It is worth noting that this JSON code example does not provide all 1214 the attributes defined in the relevant YANG models: 1216 o YANG attributes which are outside the scope of this document are 1217 not shown 1219 o The attributes describing the label restrictions are also not 1220 shown to simplify the JSON code example 1222 o The comments describing the rationale for not including some 1223 attributes in this JSON code example even if in the scope of this 1224 document are identified with the prefix "// __COMMENT__" and 1225 included only in the first object instance (e.g., in the Access 1226 Link from the AN1-1 description or in the AN1-1 LTP description) 1228 5.1.2. Domain 2 Black Topology Abstraction 1230 PNC2 provides the required black topology abstraction, as described 1231 in section 4.2, to expose to the MDSC, at MPI2, one TE Topology 1232 instance for the ODU layer (MPI2 OTN Topology) containing only one 1233 abstract node (i.e., AN2) and only inter-domain and access abstract 1234 TE links (which represent the inter-domain and access physical 1235 links). 1237 5.1.3. Domain 3 White Topology Abstraction 1239 PNC3 provides the required white topology abstraction, as described 1240 in section 4.2, to expose to the MDSC, at MPI3, one TE Topology 1241 instance for the ODU layer (MPI3 OTN Topology) containing one 1242 abstract TE node for each physical node and one abstract TE link for 1243 each physical link (internal links, inter-domain links or access 1244 links). 1246 5.1.4. Multi-domain Topology Stitching 1248 As assumed at the beginning of this section, MDSC does not have any 1249 knowledge of the topologies of each domain until each PNC reports its 1250 own abstraction topology, so the MDSC needs to merge together the 1251 abstract topologies provided by different PNCs, at the MPIs, to build 1252 its own topology view, as described in section 4.3 of [TE-TOPO]. 1254 Given the topologies reported from multiple PNCs, the MDSC need to 1255 stitch the multi-domain topology and obtain the full map of topology. 1256 The topology of each domain may be in an abstracted shape (refer to 1257 section 5.2 of [RFC8453] for a different level of abstraction), while 1258 the inter-domain link information must be complete and fully 1259 configured by the MDSC. 1261 The inter-domain link information is reported to the MDSC by the two 1262 PNCs, controlling the two ends of the inter-domain link. 1264 The MDSC needs to understand how to "stitch" together these inter- 1265 domain links. 1267 One possibility is to use the plug-id information, defined in [TE- 1268 TOPO]: two inter-domain links reporting the same plug-id value can be 1269 merged as a single intra-domain link within any MDSC native topology. 1270 The value of the reported plug-id information can be either assigned 1271 by a central network authority, and configured within the two PNC 1272 domains, or it can be discovered using automatic discovery mechanisms 1273 (e.g., LMP-based, as defined in [RFC6898]). 1275 In case the plug-id values are assigned by a central authority, it is 1276 under the central authority responsibility to assign unique values. 1278 In case the plug-id values are automatically discovered, the 1279 information discovered by the automatic discovery mechanisms needs to 1280 be encoded as a bit string within the plug-id value. This encoding is 1281 implementation specific, but the encoding rules need to be consistent 1282 across all the PNCs. 1284 In case of co-existence within the same network of multiple sources 1285 for the plug-id (e.g., central authority and automatic discovery or 1286 even different automatic discovery mechanisms), it is needed that the 1287 plug-id namespace is partitioned to avoid that different sources 1288 assign the same plug-id value to different inter-domain link. The 1289 encoding of the plug-id namespace within the plug-id value is 1290 implementation specific but needs to be consistent across all the 1291 PNCs. 1293 Another possibility is to pre-configure, either in the adjacent PNCs 1294 or in the MDSC, the association between the inter-domain link 1295 identifiers (topology-id, node-id and tp-id) assigned by the two 1296 adjacent PNCs to the same inter-domain link. 1298 This last scenario requires further investigation and will be 1299 discussed in a future version of this document. 1301 ........................ 1302 : : 1303 : Network domain 1 : ............. 1304 : Grey Topology : : : 1305 : Abstraction : : Network : 1306 : : : domain 3 : 1307 (R1)- - -------+ : : (White) : 1308 : \ +--------------+ : 1309 : \ / : : \ : 1310 : \ / : : \ : 1311 (R2)- - --------- AN1 --+ : : S31 ---- - (R7) 1312 : /|\ \ : : / \ : : 1313 : / | \ +--------- S32 S33 - - (R8) 1314 : / | \ : :/ \ / : 1315 (R3)- - -------+ | +---+ : / S34 : 1316 :..........|.......|...: /: / : 1317 | | / :../........: 1318 | | / / 1319 ...........|.......|.../..../.... 1320 : | | / / : 1321 : Network | + / / : 1322 : domain 2 | / / / : 1323 : | / / / : 1324 : | + / +--+ : 1325 : | |/ / +--- - -(R4) 1326 : Black +--- AN2 ---------+ : 1327 : Topology | | : 1328 : Abstraction | +-------------- - -(R5) 1329 : | : 1330 : +---------------- - -(R6) 1331 : : 1332 :...............................: 1334 Figure 5 - Multi-domain Abstract Topology discovered by MDSC 1336 5.1.5. Access Links 1338 Access links in Figure 3 are shown as ODU Links: the modeling of the 1339 access links for other access technologies is currently an open 1340 issue. 1342 The modeling of the access link in case of non-ODU access technology 1343 has also an impact on the need to model ODU TTPs and layer transition 1344 capabilities on the edge nodes (e.g., nodes S2, S3, S6 and S8 in 1345 Figure 3). 1347 If, for example, the physical NE S6 is implemented in a "pizza box", 1348 the data plane would have only set of ODU termination resources 1349 (where up to 2xODU4, 4xODU3, 20xODU2, 80xODU1, 160xODU0 and 1350 160xODUflex can be terminated). The traffic coming from each of the 1351 10GE access links can be mapped into any of these ODU terminations. 1353 Instead if, for example, the physical NE S6 can be implemented as a 1354 multi-board system where access links reside on different/dedicated 1355 access cards with a separated set of ODU termination resources (where 1356 up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 80xODUflex for 1357 each resource can be terminated). The traffic coming from one 10GE 1358 access links can be mapped only into the ODU terminations which 1359 reside on the same access card. 1361 The more generic implementation option for a physical NE (e.g., S6) 1362 would be the case is of a multi-board system with multiple access 1363 cards with separated sets of access links and ODU termination 1364 resources (where up to 1xODU4, 2xODU3, 10xODU2, 40xODU1, 80xODU0 and 1365 80xODUflex for each resource can be terminated). The traffic coming 1366 from each of the 10GE access links on one access card can be mapped 1367 only into any of the ODU terminations which reside on the same access 1368 card. 1370 In the last two cases, only the ODUs terminated on the same access 1371 card where the access links reside can carry the traffic coming from 1372 that 10GE access link. Terminated ODUs can instead be sent to any of 1373 the OTU4 interfaces 1375 In all these cases, terminated ODUs can be sent to any of the OTU4 1376 interfaces assuming the implementation is based on a non-blocking ODU 1377 cross-connect. 1379 If the access links are reported via MPI in some, still to be 1380 defined, client topology, it is possible to report each set of ODU 1381 termination resources as an ODU TTP within the ODU Topology of Figure 1382 3 and to use either the inter-layer lock-id or the transitional link, 1383 as described in sections 3.4 and 3.10 of [TE-TOPO], to correlate the 1384 access links, in the client topology, with the ODU TTPs, in the OTN 1385 topology, to which access link are connected to. 1387 5.2. YANG Models for Service Configuration 1389 The service configuration procedure is assumed to be initiated (step 1390 1 in Figure 6) at the CMI from CNC to MDSC. Analysis of the CMI 1391 models is (e.g., L1SM, L2SM, Transport-Service, VN, et al.) is 1392 outside the scope of this document. 1394 As described in section 4.3, it is assumed that the CMI YANG models 1395 provide all the information that allows the MDSC to understand that 1396 it needs to coordinate the setup of a multi-domain ODU connection (or 1397 connection segment) and, when needed, also the configuration of the 1398 adaptation functions in the edge nodes belonging to different 1399 domains. 1401 | 1402 | {1} 1403 V 1404 ---------------- 1405 | {2} | 1406 | {3} MDSC | 1407 | | 1408 ---------------- 1409 ^ ^ ^ 1410 {3.1} | | | 1411 +---------+ |{3.2} | 1412 | | +----------+ 1413 | V | 1414 | ---------- |{3.3} 1415 | | PNC2 | | 1416 | ---------- | 1417 | ^ | 1418 V | {4.2} | 1419 ---------- V | 1420 | PNC1 | ----- V 1421 ---------- (Network) ---------- 1422 ^ ( Domain 2) | PNC3 | 1423 | {4.1} ( _) ---------- 1424 V ( ) ^ 1425 ----- C==========D | {4.3} 1426 (Network) / ( ) \ V 1427 ( Domain 1) / ----- \ ----- 1428 ( )/ \ (Network) 1429 A===========B \ ( Domain 3) 1430 / ( ) \( ) 1431 AP-1 ( ) X===========Z 1432 ----- ( ) \ 1433 ( ) AP-2 1434 ----- 1436 Figure 6 - Multi-domain Service Setup 1438 As an example, the objective in this section is to configure a 1439 transport service between R1 and R5. The cross-domain routing is 1440 assumed to be R1 <-> S3 <-> S2 <-> S31 <-> S33 <-> S34 <->S15 <-> S18 1441 <-> R5. 1443 According to the different client signal type, there is different 1444 adaptation required. 1446 After receiving such request, MDSC determines the domain sequence, 1447 i.e., domain 1 <-> domain 2 <-> domain 3, with corresponding PNCs and 1448 inter-domain links (step 2 in Figure 6). 1450 As described in [PATH-COMPUTE], the domain sequence can be determined 1451 by running the MDSC own path computation on the MDSC internal 1452 topology, defined in section 5.1.4, if and only if the MDSC has 1453 enough topology information. Otherwise, the MDSC can send path 1454 computation requests to the different PNCs (steps 2.1, 2.2 and 2.3 in 1455 Figure 6) and use this information to determine the optimal path on 1456 its internal topology and therefore the domain sequence. 1458 The MDSC will then decompose the tunnel request into a few tunnel 1459 segments via tunnel model (including both TE tunnel model and OTN 1460 tunnel model), and request different PNCs to setup each intra-domain 1461 tunnel segment (steps 3, 3.1, 3.2 and 3.3 in Figure 6). 1463 Assume that each intra-domain tunnel segment can be set up 1464 successfully, and each PNC response to the MDSC respectively. Based 1465 on each segment, MDSC will take care of the configuration of both the 1466 intra-domain tunnel segment and inter-domain tunnel via corresponding 1467 MPI (via TE tunnel model and OTN tunnel model). More specifically, 1468 for the inter-domain configuration, the ts-bitmap and tpn attributes 1469 need to be configured using the OTN Tunnel model. Then the end-to-end 1470 OTN tunnel will be ready. 1472 In any case, the access link configuration is done only on the PNCs 1473 that control the access links (e.g., PNC-1 and PNC-3 in our example) 1474 and not on the PNCs of transit domain (e.g., PNC-2 in our example). 1475 An access link will be configured by MDSC after the OTN tunnel is set 1476 up. Access configuration is different and dependent on the different 1477 type of service. More details can be found in the following sections. 1479 5.2.1. ODU Transit Service 1481 In this scenario, described in section 4.3.1, the access links are 1482 configured as ODU Links. 1484 Since it is assumed that the physical access links are pre- 1485 configured, each PNC exposes, at its MPI, one TE Link (called "ODU 1486 Link") for each of these physical access link. These links are 1487 reported, together with any other ODU internal or inter-domain link, 1488 within the OTN abstract topology exposed by each PNC, at its own MPI. 1490 To setup this IP link, between R1 and R5, the CNC requests, at the 1491 CMI, the MDSC to setup an ODU transit service. 1493 From the topology information described in section 5.1 above, the 1494 MDSC understands that R1 is attached to the access link terminating 1495 on S3-1 LTP in the ODU Topology exposed by PNC1 and that R5 is 1496 attached to the access link terminating on AN2-1 LTP in the ODU 1497 Topology exposed by PNC2. 1499 MDSC would then request, at MPI1, the PNC1 to setup an ODU2 (Transit 1500 Segment) Tunnel with one primary path between S3-1 and S2-1 LTPs: 1502 o Source and Destination TTPs are not specified (since it is a 1503 Transit Tunnel) 1505 o Ingress and egress points are indicated in the route-object- 1506 include-exclude list of the explicit-route-objects of the primary 1507 path: 1509 o The first element references the access link terminating on 1510 S3-1 LTP 1512 o The last two element references respectively the inter-domain 1513 link terminating on S2-1 LTP and the data plane resources 1514 (i.e., the timeslots and the TPN, called "OTN Label") used by 1515 the ODU2 connection over that link. 1517 The configuration of the timeslots used by the ODU2 connection on the 1518 internal links within a PNC domain (i.e., on the internal links 1519 domain) is outside the scope of this document since it is a matter of 1520 the PNC domain internal implementation. 1522 However, the configuration of the timeslots used by the ODU2 1523 connection at the transport network domain boundaries (e.g., on the 1524 inter-domain links) needs to take into account the timeslots 1525 available on physical nodes belonging to different PNC domains (e.g., 1526 on node S2 within PNC1 domain and on node S31 within PNC3 domain). 1528 The MDSC, when coordinating the setup of a multi-domain ODU 1529 connection, also configures the data plane resources (i.e., the 1530 timeslots and the TPN) to be used on the inter-domain links. The MDSC 1531 can know the timeslots which are available on the physical OTN nodes 1532 terminating the inter-domain links (e.g., S2 and S31) from the OTN 1533 Topology information exposed, at the MPIs, by the PNCs controlling 1534 the OTN physical nodes (e.g., PNC1 and PNC3 controlling the physical 1535 nodes S2 and S31 respectively). 1537 Appendix B.2.1 provides the detailed JSON code ("mpi1-odu2-service- 1538 config.json") describing how the setup of this ODU2 (Transit Segment) 1539 Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN- 1540 TUNNEL] YANG models at MPI1. 1542 The Transport PNC performs path computation and sets up the ODU2 1543 cross-connections within the physical nodes S3, S5 and S6, as shown 1544 in section 4.3.1. 1546 5.2.1.1. Single Domain Example 1548 To setup an ODU2 end-to-end connection, supporting an IP link, 1549 between R1 and R3, the CNC requests, at the CMI, the MDSC to setup an 1550 ODU transit service. 1552 The Transport PNC reports the status of the created ODU2 (Transit 1553 Segment) Tunnel and its path within the ODU Topology as shown in 1554 Figure 7 below: 1556 .................................. 1557 : : 1558 : ODU Abstract Topology @ MPI : 1559 : : 1560 : +----+ +----+ : 1561 : | | | | : 1562 : | S1 |--------| S2 |- - - - -(R4) 1563 : +----+ +----+ : 1564 : / | : 1565 : / | : 1566 : +----+ +----+ | : 1567 : | | | | | : 1568 (R1)- - - - - S3 |---| S4 | | : 1569 :S3-1 <<= + +----+ | : 1570 : = \ | : 1571 : = \ \ | : 1572 : == ---+ \ | : 1573 : = | \ | : 1574 : = S5 | \ | : 1575 : == --+ \ | : 1576 (R2)- - - - - = \ \ | : 1577 :S6-1 \ / = \ \ | : 1578 : +--- = +----+ +----+ : 1579 : | = | | | | : 1580 : | S6 = --| S7 |---| S8 |- - - - -(R5) 1581 : +--- = +----+ +----+ : 1582 : / = : 1583 (R3)- - - - - <<== : 1584 :S6-2 : 1585 :................................: 1587 Figure 7 - ODU2 Transit Tunnel 1589 5.2.2. EPL over ODU Service 1591 In this scenario, described in section 4.3.2, the access links are 1592 configured as Ethernet Links. 1594 To setup this IP link, between R1 and R5, the CNC requests, at the 1595 CMI, the MDSC to setup an EPL service. 1597 As described in section 5.1.5 above, it is not clear in this case how 1598 the Ethernet access links between the transport network and the IP 1599 router, are reported by the PNC to the MDSC. 1601 If the 10GE physical links are not reported as ODU links within the 1602 OTN topology information, described in section 5.1.1 above than the 1603 MDSC will not have sufficient information to know that R1 and R5 are 1604 attached to the access links terminating on S3 and S6. 1606 Assuming that the MDSC knows how R1 and R3 are attached to the 1607 transport network, the MDSC would request the Transport PNC to setup 1608 an ODU2 end-to-end Tunnel between S3 and S6. 1610 This ODU Tunnel is setup between two TTPs of nodes S3 and S6. In case 1611 of nodes S3 and S6 support more than one TTP, the MDSC should decide 1612 which TTP to use. 1614 As discussed in 5.1.5, depending on the different hardware 1615 implementations of the physical nodes S3 and S6, not all the access 1616 links can be connected to all the TTPs. The MDSC should therefore 1617 select not only the optimal TTP but also a TTP that would allow the 1618 Tunnel to be used by the service. 1620 It is assumed that in case of node S3 or node S6 supports only one 1621 TTP, this TTP can be accessed by all the access links. 1623 Appendix B.2.2 provides the detailed JSON code ("mpi1-odu2-tunnel- 1624 config.json") describing how the setup of this ODU2 (Head Segment) 1625 Tunnel can be requested by the MDSC, using the [TE-TUNNEL] and [OTN- 1626 TUNNEL] YANG models at MPI1. 1628 Once the ODU2 Tunnel setup has been requested, unless there is a one- 1629 to-one relationship between the S3 and S6 TTPs and the Ethernet 1630 access links toward R1 and R3 (as in the case, described in section 1631 5.1.5, where the Ethernet access links reside on different/dedicated 1632 access card such that the ODU2 tunnel can only carry the Ethernet 1633 traffic from the only Ethernet access link on the same access card 1634 where the ODU2 tunnel is terminated), the MDSC also needs to request 1635 the setup of an EPL service from the access links on S3 and S6, 1636 attached to R1 and R3, and this ODU2 Tunnel. 1638 Appendix B.2.3 provides the detailed JSON code ("mpi1-epl-service- 1639 config.json") describing how the setup of this EPL service using the 1640 ODU2 Tunnel can be requested by the MDSC, using the [CLIENT-SVC] YANG 1641 model at MPI1. 1643 5.2.3. Other OTN Client Services 1645 In this scenario, the access links are configured as one of the OTN 1646 clients (e.g., STM-64) links. 1648 As described in section 4.3.3, the CNC needs to setup an STM-64 1649 Private Link service, supporting an IP link, between R1 and R3 and 1650 requests this service at the CMI to the MDSC. 1652 MDSC needs to setup an STM-64 Private Link service between R1 and R3 1653 supported by an ODU2 end-to-end connection between S3 and S6. 1655 As described in section 5.1.5 above, it is not clear in this case how 1656 the access links (e.g., the STM-N access links) between the transport 1657 network and the IP router, are reported by the PNC to the MDSC. 1659 The same issues, as described in section 5.2.2, apply here: 1661 o the MDSC needs to understand that R1 and R3 are connected, thought 1662 STM-64 access links, with S3 and S6 1664 o the MDSC needs to understand which TTPs in S3 and S6 can be 1665 accessed by these access links 1667 o the MDSC needs to configure the private line service from these 1668 access links through the ODU2 tunnel 1670 5.2.4. EVPL over ODU Service 1672 In this scenario, the access links are configured as Ethernet links, 1673 as described in section 5.2.2 above. 1675 As described in section 4.3.4, the CNC needs to setup EVPL services, 1676 supporting IP links, between R1 and R3, as well as between R1 and R4 1677 and requests these services at the CMI to the MDSC. 1679 MDSC needs to setup two EVPL services, between R1 and R3, as well as 1680 between R1 and R4, supported by ODU0 end-to-end connections between 1681 S3 and S6 and between S3 and S2 respectively. 1683 As described in section 5.1.5 above, it is not clear in this case how 1684 the Ethernet access links between the transport network and the IP 1685 router, are reported by the PNC to the MDSC. 1687 The same issues, as described in section 5.1.5 above, apply here: 1689 o the MDSC needs to understand that R1, R3 and R4 are connected, 1690 thought the Ethernet access links, with S3, S6 and S2 1692 o the MDSC needs to understand which TTPs in S3, S6 and S2 can be 1693 accessed by these access links 1695 o the MDSC needs to configure the EVPL services from these access 1696 links through the ODU0 tunnels 1698 In addition, the MDSC needs to get the information that the access 1699 links on S3, S6 and S2 are capable of supporting EVPL (rather than 1700 just EPL) as well as to coordinate the VLAN configuration, for each 1701 EVPL service, on these access links (this is a similar issue as the 1702 timeslot configuration on access links discussed in section 4.3.1 1703 above). 1705 5.3. YANG Models for Protection Configuration 1707 5.3.1. Linear Protection (end-to-end) 1709 To be discussed in future versions of this document. 1711 5.3.2. Segmented Protection 1713 To be discussed in future versions of this document. 1715 6. Security Considerations 1717 Inherently OTN networks ensure privacy and security via hard 1718 partitioning of traffic onto dedicated circuits. The separation of 1719 network traffic makes it difficult to intercept data transferred 1720 between nodes over OTN-channelized links. 1722 This document analyses the applicability of the YANG models being 1723 defined by the IETF to support OTN single and multi-domain scenarios 1724 There are no specific new security considerations introduced by this 1725 document. 1727 In OTN the (General Communication Channel) GCC is used for OAM 1728 functions such as performance monitoring, fault detection, and 1729 signaling. The GCC control channel should be secured using a suitable 1730 mechanism. 1732 7. IANA Considerations 1734 This document requires no IANA actions. 1736 8. References 1738 8.1. Normative References 1740 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 1741 Information Exchange between Interconnected Traffic- 1742 Engineered Networks", BCP 206, RFC 7926, July 2016. 1744 [RFC4427] Mannie, E., Papadimitriou, D., "Recovery (Protection and 1745 Restoration) Terminology for Generalized Multi-Protocol 1746 Label Switching (GMPLS)", RFC 4427, March 2006. 1748 [RFC8453] Ceccarelli, D., Lee, Y. et al., "Framework for Abstraction 1749 and Control of TE Networks (ACTN)", RFC8453, August 2018. 1751 [ITU-T G.709] ITU-T Recommendation G.709 (06/16), "Interfaces for the 1752 optical transport network", June 2016. 1754 [ITU-T G.808.1] ITU-T Recommendation G.808.1 (05/14), "Generic 1755 protection switching - Linear trail and subnetwork 1756 protection", May 2014. 1758 [ITU-T G.873.1] ITU-T Recommendation G.873.1 (05/14), "Optical 1759 transport network (OTN): Linear protection", May 2014. 1761 [TE-TOPO] Liu, X. et al., "YANG Data Model for TE Topologies", draft- 1762 ietf-teas-yang-te-topo, work in progress. 1764 [OTN-TOPO] Zheng, H. et al., "A YANG Data Model for Optical Transport 1765 Network Topology", draft-ietf-ccamp-otn-topo-yang, work in 1766 progress. 1768 [CLIENT-TOPO] Zheng, H. et al., "A YANG Data Model for Client-layer 1769 Topology", draft-zheng-ccamp-client-topo-yang, work in 1770 progress. 1772 [TE-TUNNEL] Saad, T. et al., "A YANG Data Model for Traffic 1773 Engineering Tunnels and Interfaces", draft-ietf-teas-yang- 1774 te, work in progress. 1776 [PATH-COMPUTE] Busi, I., Belotti, S. et al, "Yang model for 1777 requesting Path Computation", draft-ietf-teas-yang-path- 1778 computation, work in progress. 1780 [OTN-TUNNEL] Zheng, H. et al., "OTN Tunnel YANG Model", draft-ietf- 1781 ccamp-otn-tunnel-model, work in progress. 1783 [CLIENT-SVC] Zheng, H. et al., "A YANG Data Model for Optical 1784 Transport Network Client Signals", draft-zheng-ccamp-otn- 1785 client-signal-yang, work in progress. 1787 8.2. Informative References 1789 [RFC5151] Farrel, A. et al., "Inter-Domain MPLS and GMPLS Traffic 1790 Engineering --Resource Reservation Protocol-Traffic 1791 Engineering (RSVP-TE) Extensions", RFC 5151, February 2008. 1793 [RFC6898] Li, D. et al., "Link Management Protocol Behavior 1794 Negotiation and Configuration Modifications", RFC 6898, 1795 March 2013. 1797 [RFC8040] Bierman, A. et al., "RESTCONF Protocol", RFC 8040, January 1798 2017. 1800 [RFC8309] Wu, Q. et al., "Service Models Explained", RFC 8309, 1801 January 2018. 1803 [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for 1804 Abstraction and Control of Traffic Engineered Networks", 1805 draft-zhang-teas-actn-yang, work in progress. 1807 [RFC-FOLD] Watsen, K. et al., "Handling Long Lines in Artwork in 1808 Internet-Drafts and RFCs", work in progress 1810 [ONF TR-527] ONF Technical Recommendation TR-527, "Functional 1811 Requirements for Transport API", June 2016. 1813 [ONF GitHub] ONF Open Transport (SNOWMASS) 1814 https://github.com/OpenNetworkingFoundation/Snowmass- 1815 ONFOpenTransport 1817 9. Acknowledgments 1819 The authors would like to thank all members of the Transport NBI 1820 Design Team involved in the definition of use cases, gap analysis 1821 and guidelines for using the IETF YANG models at the Northbound 1822 Interface (NBI) of a Transport SDN Controller. 1824 The authors would like to thank Xian Zhang, Anurag Sharma, Sergio 1825 Belotti, Tara Cummings, Michael Scharf, Karthik Sethuraman, Oscar 1826 Gonzalez de Dios, Hans Bjursrom and Italo Busi for having initiated 1827 the work on gap analysis for transport NBI and having provided 1828 foundations work for the development of this document. 1830 The authors would like to thank the authors of the TE Topology and 1831 Tunnel YANG models [TE-TOPO] and [TE-TUNNEL], in particular Igor 1832 Bryskin, Vishnu Pavan Beeram, Tarek Saad and Xufeng Liu, for their 1833 support in addressing any gap identified during the analysis work. 1835 The authors would like to thank Henry Yu and Aihua Guo for their 1836 input and review of the URIs structures used within the JSON code 1837 examples. 1839 This document was prepared using 2-Word-v2.0.template.dot. 1841 Appendix A. Validating a JSON fragment against a YANG Model 1843 The objective is to have a tool that allows validating whether a 1844 piece of JSON code embedded in an Internet-Draft is compliant with a 1845 YANG model without using a client/server. 1847 A.1. Manipulation of JSON fragments 1849 This section describes the various ways JSON fragments are used in 1850 the I-D processing and how to manage them. 1852 Let's call "folded-JSON" the JSON embedded in the I-D: it fits the 72 1853 chars width and it is acceptable for it to be invalid JSON. 1855 We then define "unfolded-JSON" a valid JSON fragment having the same 1856 contents of the "folded-JSON " without folding, i.e. limits on the 1857 text width. The folding/unfolding operation may be done according to 1858 draft-kwatsen-netmod-artwork-folding. The "unfolded-JSON" can be 1859 edited by the authors using JSON editors with the advantages of 1860 syntax validation and pretty-printing. 1862 Both the "folded" and the "unfolded" JSON fragments can include 1863 comments having descriptive fields and directives we'll describe 1864 later to facilitate the reader and enable some automatic processing. 1866 The presence of comments in the "unfolded-JSON" fragment makes it an 1867 invalid JSON encoding of YANG data. Therefore we call "naked JSON" 1868 the JSON where the comments have been stripped out: not only it is 1869 valid JSON but it is a valid JSON encoding of YANG data. 1871 The following schema resumes these definitions: 1873 unfold_it --> stripper --> 1875 Folded-JSON Unfolded-JSON Naked JSON 1877 <-- fold_it <-- author edits 1879 <=72-chars? MUST MAY MAY 1881 valid JSON? MAY MUST MUST 1883 JSON-encoding MAY MAY MUST 1884 of YANG data 1886 Our validation toolchain has been designed to take a JSON in any of 1887 the three formats and validate it automatically against a set of 1888 relevant YANG modules using available open-source tools. It can be 1889 found at: https://github.com/GianmarcoBruno/json-yang/ 1891 A.2. Comments in JSON fragments 1893 We found useful to introduce two kinds of comments, both defined as 1894 key-value pairs where the key starts with "//": 1896 - free-form descriptive comments, e.g."// COMMENT" : "refine this" to 1897 describe properties of JSON fragments. 1899 - machine-usable directives e.g. "// __REFERENCES__DRAFTS__" : { 1900 "ietf-routing-types@2017-12-04": "rfc8294",} which can be used to 1901 automatically download from the network the relevant I-Ds or RFCs and 1902 extract from them the YANG models of interest. This is particularly 1903 useful to keep consistency when the drafting work is rapidly 1904 evolving. 1906 A.3. Validation of JSON fragments: DSDL-based approach 1908 The idea is to generate a JSON driver file (JTOX) from YANG, then use 1909 it to translate JSON to XML and validate it against the DSDL schemas, 1910 as shown in Figure 8. 1912 Useful link: https://github.com/mbj4668/pyang/wiki/XmlJson 1913 (2) 1914 YANG-module ---> DSDL-schemas (RNG,SCH,DSRL) 1915 | | 1916 | (1) | 1917 | | 1918 Config/state JTOX-file | (4) 1919 \ | | 1920 \ | | 1921 \ V V 1922 JSON-file------------> XML-file ----------------> Output 1923 (3) 1925 Figure 8 - DSDL-based approach for JSON code validation 1927 In order to allow the use of comments following the convention 1928 defined in section 3without impacting the validation process, these 1929 comments will be automatically removed from the JSON-file that will 1930 be validate. 1932 A.4. Validation of JSON fragments: why not using a XSD-based approach 1934 This approach has been analyzed and discarded because no longer 1935 supported by pyang. 1937 The idea is to convert YANG to XSD, JSON to XML and validate it 1938 against the XSD, as shown in Figure 9: 1940 (1) 1941 YANG-module ---> XSD-schema - \ (3) 1942 +--> Validation 1943 JSON-file------> XML-file ----/ 1944 (2) 1946 Figure 9 - XSD-based approach for JSON code validation 1948 The pyang support for the XSD output format was deprecated in 1.5 and 1949 removed in 1.7.1. However pyang 1.7.1 is necessary to work with YANG 1950 1.1 so the process shown in Figure 9 will stop just at step (1). 1952 Appendix B. Detailed JSON Examples 1954 The JSON code examples provided in this appendix have been validated 1955 using the tools in Appendix A and folded using the tool in [RFC- 1956 FOLD]. 1958 B.1. JSON Examples for Topology Abstractions 1960 B.1.1. JSON Code: mpi1-otn-topology.json 1962 This is the JSON code reporting the OTN Topology @ MPI: 1964 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 1966 { 1967 "// __TITLE__": "ODU Black Topology @ MPI1", 1968 "// __LAST_UPDATE__": "October 18, 2018", 1969 "// __MISSING_ATTRIBUTES__": true, 1970 "// __REFERENCE_DRAFTS__": { 1971 "ietf-routing-types@2017-12-04": "rfc8294", 1972 "ietf-otn-types@2017-10-30": "draft-ietf-ccamp-otn-tunnel-model-\ 1973 \01", 1974 "ietf-network@2018-02-26": "rfc8345", 1975 "ietf-network-topology@2018-02-26": "rfc8345", 1976 "ietf-te-types@2018-06-12": "draft-ietf-teas-yang-te-15", 1977 "ietf-te-topology@2018-06-15": "draft-ietf-teas-yang-te-topo-18", 1978 "ietf-otn-topology@2017-10-30": "draft-ietf-ccamp-otn-topo-yang-\ 1979 \02" 1980 }, 1981 "// __RESTCONF_OPERATION__": { 1982 "operation": "GET", 1983 "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-network:networks" 1984 }, 1985 "ietf-network:networks": { 1986 "network": [ 1987 { 1988 "network-id": "providerId/201/clientId/300/topologyId/otn-bl\ 1989 \ack-topology", 1990 "network-types": { 1991 "ietf-te-topology:te-topology": { 1992 "ietf-otn-topology:otn-topology": {} 1993 } 1994 }, 1995 "ietf-te-topology:provider-id": 201, 1996 "ietf-te-topology:client-id": 300, 1997 "ietf-te-topology:te-topology-id": "otn-black-topology", 1998 "// ietf-te-topology:te": "presence container requires: prov\ 1999 \ider, client and te-topology-id", 2000 "ietf-te-topology:te": { 2001 "name": "OTN Black Topology @ MPI1" 2002 }, 2003 "// ietf-network:node": "Access LTPs to be reviewed in a fut\ 2004 \ure update", 2005 "ietf-network:node": [ 2006 { 2007 "// __NODE__:__DESCRIPTION__": { 2008 "name": "AN1", 2009 "identifier": "10.0.0.1", 2010 "type": "Abstract Node", 2011 "physical node(s)": "whole network domain 1" 2012 }, 2013 "node-id": "10.0.0.1", 2014 "ietf-te-topology:te-node-id": "10.0.0.1", 2015 "ietf-te-topology:te": { 2016 "te-node-attributes": { 2017 "name": "AN11", 2018 "admin-status": "up", 2019 "// __DISCUSS__ is-abstract": "To be discussed with \ 2020 \TE Topology authors", 2021 "// __DISCUSS__ underlay-topology": "To be discussed\ 2022 \ with TE Topology authors" 2023 }, 2024 "oper-status": "up", 2025 "// __DISCUSS__ tunnel-termination-point": [] 2026 }, 2027 "ietf-network-topology:termination-point": [ 2028 { 2029 "// __DESCRIPTION__:__LTP__": { 2030 "name": "AN1-1 LTP", 2031 "link type(s)": "OTU-2", 2032 "physical node": "S3", 2033 "unnumberd/ifIndex": 1, 2034 "port type": "tributary port", 2035 "connected to": "R1" 2036 }, 2037 "tp-id": "1", 2038 "ietf-te-topology:te-tp-id": 1, 2039 "ietf-te-topology:te": { 2040 "name": "AN1-1 LTP", 2041 "admin-status": "up", 2042 "// __DISCUSS__ interface-switching-capability": "\ 2043 \See Link attributes (teNodeId/10.0.0.1/teLinkId/1)", 2044 "// __DISCUSS__ inter-domain-plug-id": "Access Lin\ 2045 \k", 2046 "// __COMMENT__ inter-layer-lock-id": "Empty: OTN \ 2047 \Links are pre-configured", 2048 "oper-status": "up", 2049 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2050 \d-types": "List of ODU clients?", 2051 "// __DISCUSS__ ietf-otn-topology:client-facing": \ 2053 \true 2054 } 2055 }, 2056 { 2057 "// __DESCRIPTION__:__LTP__": { 2058 "name": "AN1-2 LTP", 2059 "link type(s)": "OTU-4", 2060 "physical node": "S2", 2061 "unnumberd/ifIndex": 1, 2062 "port type": "inter-domain port", 2063 "connected to": "S31" 2064 }, 2065 "tp-id": "2", 2066 "ietf-te-topology:te-tp-id": 2, 2067 "ietf-te-topology:te": { 2068 "name": "AN1-2 LTP", 2069 "admin-status": "up", 2070 "// __DISCUSS__ interface-switching-capability": "\ 2071 \See Link attributes (teNodeId/10.0.0.1/teLinkId/2)", 2072 "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\ 2073 \in Link", 2074 "oper-status": "up", 2075 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2076 \d-types": "Empty? (inter-domain OTN link)", 2077 "// __DEFAULT__ ietf-otn-topology:client-facing": \ 2078 \false 2079 } 2080 }, 2081 { 2082 "// __DESCRIPTION__:__LTP__": { 2083 "name": "AN1-3 LTP", 2084 "link type(s)": "OTU-2", 2085 "physical node": "S6", 2086 "unnumberd/ifIndex": 1, 2087 "port type": "tributary port", 2088 "connected to": "R2" 2089 }, 2090 "tp-id": "3", 2091 "ietf-te-topology:te-tp-id": 3, 2092 "ietf-te-topology:te": { 2093 "name": "AN1-3 LTP", 2094 "admin-status": "up", 2095 "// __DISCUSS__ interface-switching-capability": "\ 2096 \See Link attributes (teNodeId/10.0.0.1/teLinkId/3)", 2097 "// __DISCUSS__ inter-domain-plug-id": "Access Lin\ 2098 \k", 2099 "oper-status": "up", 2100 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2101 \d-types": "List of ODU clients?", 2102 "// __DISCUSS__ ietf-otn-topology:client-facing": \ 2103 \true 2104 } 2105 }, 2106 { 2107 "// __DESCRIPTION__:__LTP__": { 2108 "name": "AN1-4 LTP", 2109 "link type(s)": "OTU-4", 2110 "physical node": "S8", 2111 "unnumberd/ifIndex": 1, 2112 "port type": "inter-domain port", 2113 "connected to": "S32" 2114 }, 2115 "tp-id": "4", 2116 "ietf-te-topology:te-tp-id": 4, 2117 "ietf-te-topology:te": { 2118 "name": "AN1-4 LTP", 2119 "admin-status": "up", 2120 "// __DISCUSS__ interface-switching-capability": "\ 2121 \See Link attributes (teNodeId/10.0.0.1/teLinkId/4)", 2122 "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\ 2123 \in Link", 2124 "oper-status": "up", 2125 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2126 \d-types": "Empty? (inter-domain OTN link)", 2127 "// __DEFAULT__ ietf-otn-topology:client-facing": \ 2128 \false 2129 } 2130 }, 2131 { 2132 "// __DESCRIPTION__:__LTP__": { 2133 "name": "AN1-5 LTP", 2134 "link type(s)": "OTU-4", 2135 "physical node": "S8", 2136 "unnumberd/ifIndex": 5, 2137 "port type": "inter-domain port", 2138 "connected to": "S12" 2139 }, 2140 "tp-id": "5", 2141 "ietf-te-topology:te-tp-id": 5, 2142 "ietf-te-topology:te": { 2143 "name": "AN1-5 LTP", 2144 "admin-status": "up", 2145 "// __DISCUSS__ interface-switching-capability": "\ 2146 \See Link attributes (teNodeId/10.0.0.1/teLinkId/5)", 2147 "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\ 2148 \in Link", 2149 "oper-status": "up", 2150 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2151 \d-types": "Empty? (inter-domain OTN link)", 2152 "// __DEFAULT__ ietf-otn-topology:client-facing": \ 2153 \false 2154 } 2155 }, 2156 { 2157 "// __DESCRIPTION__:__LTP__": { 2158 "name": "AN1-6 LTP", 2159 "link type(s)": "OTU-4", 2160 "physical node": "S7", 2161 "unnumberd/ifIndex": 4, 2162 "port type": "inter-domain port", 2163 "connected to": "S11" 2164 }, 2165 "tp-id": "6", 2166 "ietf-te-topology:te-tp-id": 6, 2167 "ietf-te-topology:te": { 2168 "name": "AN1-6 LTP", 2169 "admin-status": "up", 2170 "// __DISCUSS__ interface-switching-capability": "\ 2171 \See Link attributes (teNodeId/10.0.0.1/teLinkId/6)", 2172 "// __DISCUSS__ inter-domain-plug-id": "Inter-doma\ 2173 \in Link", 2174 "oper-status": "up", 2175 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2176 \d-types": "Empty? (inter-domain OTN link)", 2177 "// __DEFAULT__ ietf-otn-topology:client-facing": \ 2178 \false 2179 } 2180 }, 2181 { 2182 "// __DESCRIPTION__:__LTP__": { 2183 "name": "AN1-7 LTP", 2184 "link type(s)": "OTU-2", 2185 "physical node": "S6", 2186 "unnumberd/ifIndex": 2, 2187 "port type": "tributary port", 2188 "connected to": "R3" 2189 }, 2190 "tp-id": "7", 2191 "ietf-te-topology:te-tp-id": 7, 2192 "ietf-te-topology:te": { 2193 "name": "AN1-7 LTP", 2194 "admin-status": "up", 2195 "// __DISCUSS__ interface-switching-capability": "\ 2196 \See Link attributes (teNodeId/10.0.0.1/teLinkId/7)", 2197 "// __DISCUSS__ inter-domain-plug-id": "Access Lin\ 2198 \k", 2199 "oper-status": "up", 2200 "// __DISCUSS__ ietf-otn-topology:supported-payloa\ 2201 \d-types": "List of ODU clients?", 2202 "// __DISCUSS__ ietf-otn-topology:client-facing": \ 2203 \true 2204 } 2205 } 2206 ] 2207 } 2208 ], 2209 "// ietf-network-topology:link": "Access links to be reviewe\ 2210 \d in a future update", 2211 "ietf-network-topology:link": [ 2212 { 2213 "// __DESCRIPTION__:__LINK__": { 2214 "name": "Access Link from AN1-1", 2215 "type": "access link", 2216 "physical link": "Link from S3-1 to R1" 2217 }, 2218 "link-id": "teNodeId/10.0.0.1/teLinkId/1", 2219 "ietf-te-topology:te": { 2220 "te-link-attributes": { 2221 "name": "Access Link from AN1-1", 2222 "// __DISCUSS__ access-type": "Can we assume point-t\ 2223 \o-point as the default value?", 2224 "access-type": "point-to-point", 2225 "// __COMMENT__ external-domain": "Empty: the plug-i\ 2226 \d is used instead of this container", 2227 "// __DISCUSS__ is-abstract": "To be discussed with \ 2228 \TE Topology authors", 2229 "// __DISCUSS__ underlay": "To be discussed with TE \ 2230 \Topology authors", 2231 "admin-status": "up", 2232 "interface-switching-capability": [ 2233 { 2234 "switching-capability": "ietf-te-types:switching\ 2235 \-otn", 2236 "encoding": "ietf-te-types:lsp-encoding-oduk", 2237 "max-lsp-bandwidth": [ 2238 { 2239 "priority": 0, 2240 "// __DISCUSS__ te-bandwidth": "ODU2" 2241 } 2242 ] 2243 } 2244 ], 2245 "// __COMMENT__ label-restrictions": "Not described \ 2246 \in this JSON example", 2247 "// __DISCUSS__ link-protection-type": "Can we assum\ 2248 \e unprotected as the default value?", 2249 "link-protection-type": "unprotected", 2250 "max-link-bandwidth": { 2251 "// __DISCUSS__ te-bandwidth": "1xODU2" 2252 }, 2253 "max-resv-link-bandwidth": { 2254 "// __DISCUSS__ te-bandwidth": "1xODU2" 2255 }, 2256 "unreserved-bandwidth": [ 2257 { 2258 "priority": 0, 2259 "// __DISCUSS__ te-bandwidth": "1xODU2" 2260 } 2261 ] 2262 }, 2263 "oper-status": "up", 2264 "// __EMPTY__ is-transitional": "It is not a transitio\ 2265 \nal link", 2266 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2267 \opology authors" 2268 }, 2269 "source": { 2270 "source-node": "10.0.0.1", 2271 "source-tp": 1 2272 }, 2273 "// __EMPTY__ destination": "access link" 2274 }, 2275 { 2276 "// __DESCRIPTION__:__LINK__": { 2277 "name": "Inter-domain Link from AN1-2", 2278 "type": "inter-domain link", 2279 "physical link": "Link from S2-1 to S31" 2280 }, 2281 "link-id": "teNodeId/10.0.0.1/teLinkId/2", 2282 "ietf-te-topology:te": { 2283 "te-link-attributes": { 2284 "name": "Inter-domain Link from AN1-2", 2285 "// __DISCUSS__ access-type": "Can we assume point-t\ 2286 \o-point as the default value?", 2287 "access-type": "point-to-point", 2288 "// __DISCUSS__ is-abstract": "To be discussed with \ 2289 \TE Topology authors", 2290 "// __DISCUSS__ underlay": "To be discussed with TE \ 2291 \Topology authors", 2292 "admin-status": "up", 2293 "interface-switching-capability": [ 2294 { 2295 "switching-capability": "ietf-te-types:switching\ 2296 \-otn", 2297 "encoding": "ietf-te-types:lsp-encoding-oduk", 2298 "max-lsp-bandwidth": [ 2299 { 2300 "priority": 0, 2301 "// __DISCUSS__ te-bandwidth": "ODU4" 2302 } 2303 ], 2304 "// __DISCUSS__ label-restrictions": "To be adde\ 2305 \d?" 2306 } 2307 ], 2308 "// __DISCUSS__ link-protection-type": "Can we assum\ 2309 \e unprotected as the default value?", 2310 "link-protection-type": "unprotected", 2311 "max-link-bandwidth": { 2312 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2313 }, 2314 "max-resv-link-bandwidth": { 2315 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2316 }, 2317 "unreserved-bandwidth": [ 2318 { 2319 "priority": 0, 2320 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2321 } 2322 ] 2323 }, 2324 "oper-status": "up", 2325 "// __EMPTY__ is-transitional": "It is not a transitio\ 2326 \nal link", 2327 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2328 \opology authors" 2329 }, 2330 "source": { 2331 "source-node": "10.0.0.1", 2332 "source-tp": 2 2333 }, 2334 "// __EMPTY__ destination": "inter-domain link" 2335 }, 2336 { 2337 "// __DESCRIPTION__:__LINK__": { 2338 "name": "Access Link from AN1-3", 2339 "type": "access link", 2340 "physical link": "Link from S6-1 to R2" 2341 }, 2342 "link-id": "teNodeId/10.0.0.1/teLinkId/3", 2343 "ietf-te-topology:te": { 2344 "te-link-attributes": { 2345 "name": "Access Link from AN1-3", 2346 "// __DISCUSS__ access-type": "Can we assume point-t\ 2347 \o-point as the default value?", 2348 "access-type": "point-to-point", 2349 "// __DISCUSS__ is-abstract": "To be discussed with \ 2350 \TE Topology authors", 2351 "// __DISCUSS__ underlay": "To be discussed with TE \ 2352 \Topology authors", 2353 "admin-status": "up", 2354 "interface-switching-capability": [ 2355 { 2356 "switching-capability": "ietf-te-types:switching\ 2357 \-otn", 2358 "encoding": "ietf-te-types:lsp-encoding-oduk", 2359 "max-lsp-bandwidth": [ 2360 { 2361 "priority": 0, 2362 "// __DISCUSS__ te-bandwidth": "ODU2" 2363 } 2364 ], 2365 "// __DISCUSS__ label-restrictions": "To be adde\ 2366 \d?" 2367 } 2368 ], 2369 "// __DISCUSS__ link-protection-type": "Can we assum\ 2370 \e unprotected as the default value?", 2371 "link-protection-type": "unprotected", 2372 "max-link-bandwidth": { 2373 "// __DISCUSS__ te-bandwidth": "1xODU2" 2374 }, 2375 "unreserved-bandwidth": [ 2376 { 2377 "priority": 0, 2378 "// __DISCUSS__ te-bandwidth": "1xODU2" 2379 } 2380 ], 2381 "max-resv-link-bandwidth": { 2382 "// __DISCUSS__ te-bandwidth": "1xODU2" 2383 } 2384 }, 2385 "oper-status": "up", 2386 "// __EMPTY__ is-transitional": "It is not a transitio\ 2387 \nal link", 2388 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2389 \opology authors" 2390 }, 2391 "source": { 2392 "source-node": "10.0.0.1", 2393 "source-tp": 3 2394 }, 2395 "// __EMPTY__ destination": "access link" 2396 }, 2397 { 2398 "// __DESCRIPTION__:__LINK__": { 2399 "name": "Inter-domain Link from AN1-4", 2400 "type": "inter-domain link", 2401 "physical link": "Link from S8-1 to S32" 2402 }, 2403 "link-id": "teNodeId/10.0.0.1/teLinkId/4", 2404 "ietf-te-topology:te": { 2405 "te-link-attributes": { 2406 "name": "Inter-domain Link from AN1-4", 2407 "// __DISCUSS__ access-type": "Can we assume point-t\ 2408 \o-point as the default value?", 2409 "access-type": "point-to-point", 2410 "// __DISCUSS__ is-abstract": "To be discussed with \ 2411 \TE Topology authors", 2412 "// __DISCUSS__ underlay": "To be discussed with TE \ 2413 \Topology authors", 2414 "admin-status": "up", 2415 "interface-switching-capability": [ 2416 { 2417 "switching-capability": "ietf-te-types:switching\ 2418 \-otn", 2419 "encoding": "ietf-te-types:lsp-encoding-oduk", 2420 "max-lsp-bandwidth": [ 2421 { 2422 "priority": 0, 2423 "// __DISCUSS__ te-bandwidth": "ODU4" 2424 } 2425 ], 2426 "// __DISCUSS__ label-restrictions": "To be adde\ 2427 \d?" 2428 } 2429 ], 2430 "// __DISCUSS__ link-protection-type": "Can we assum\ 2431 \e unprotected as the default value?", 2432 "link-protection-type": "unprotected", 2433 "max-link-bandwidth": { 2434 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2435 }, 2436 "unreserved-bandwidth": [ 2437 { 2438 "priority": 0, 2439 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2440 } 2441 ], 2442 "max-resv-link-bandwidth": { 2443 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2444 } 2445 }, 2446 "oper-status": "up", 2447 "// __EMPTY__ is-transitional": "It is not a transitio\ 2448 \nal link", 2449 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2450 \opology authors" 2451 }, 2452 "source": { 2453 "source-node": "10.0.0.1", 2454 "source-tp": 4 2455 }, 2456 "// __EMPTY__ destination": "inter-domain link" 2457 }, 2458 { 2459 "// __DESCRIPTION__:__LINK__": { 2460 "name": "Inter-domain Link from AN1-5", 2461 "type": "inter-domain link", 2462 "physical link": "Link from S8-5 to S12" 2463 }, 2464 "link-id": "teNodeId/10.0.0.1/teLinkId/5", 2465 "ietf-te-topology:te": { 2466 "te-link-attributes": { 2467 "name": "Inter-domain Link from AN1-5", 2468 "// __DISCUSS__ access-type": "Can we assume point-t\ 2469 \o-point as the default value?", 2470 "access-type": "point-to-point", 2471 "// __DISCUSS__ is-abstract": "To be discussed with \ 2472 \TE Topology authors", 2473 "// __DISCUSS__ underlay": "To be discussed with TE \ 2474 \Topology authors", 2475 "admin-status": "up", 2476 "interface-switching-capability": [ 2477 { 2478 "switching-capability": "ietf-te-types:switching\ 2479 \-otn", 2480 "encoding": "ietf-te-types:lsp-encoding-oduk", 2481 "max-lsp-bandwidth": [ 2482 { 2483 "priority": 0, 2484 "// __DISCUSS__ te-bandwidth": "ODU4" 2485 } 2486 ], 2487 "// __DISCUSS__ label-restrictions": "To be adde\ 2488 \d?" 2489 } 2490 ], 2491 "// __DISCUSS__ link-protection-type": "Can we assum\ 2492 \e unprotected as the default value?", 2493 "link-protection-type": "unprotected", 2494 "max-link-bandwidth": { 2495 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2496 }, 2497 "max-resv-link-bandwidth": { 2498 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2499 }, 2500 "unreserved-bandwidth": [ 2501 { 2502 "priority": 0, 2503 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2504 } 2505 ] 2506 }, 2507 "oper-status": "up", 2508 "// __EMPTY__ is-transitional": "It is not a transitio\ 2509 \nal link", 2510 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2511 \opology authors" 2512 }, 2513 "source": { 2514 "source-node": "10.0.0.1", 2515 "source-tp": 5 2516 }, 2517 "// __EMPTY__ destination": "inter-domain link" 2518 }, 2519 { 2520 "// __DESCRIPTION__:__LINK__": { 2521 "name": "Inter-domain Link from AN1-6", 2522 "type": "inter-domain link", 2523 "physical link": "Link from S7-4 to S11" 2524 }, 2525 "link-id": "teNodeId/10.0.0.1/teLinkId/6", 2526 "ietf-te-topology:te": { 2527 "te-link-attributes": { 2528 "name": "Inter-domain Link from AN1-6", 2529 "// __DISCUSS__ access-type": "Can we assume point-t\ 2530 \o-point as the default value?", 2531 "access-type": "point-to-point", 2532 "// __DISCUSS__ is-abstract": "To be discussed with \ 2533 \TE Topology authors", 2534 "// __DISCUSS__ underlay": "To be discussed with TE \ 2535 \Topology authors", 2536 "admin-status": "up", 2537 "interface-switching-capability": [ 2538 { 2539 "switching-capability": "ietf-te-types:switching\ 2540 \-otn", 2541 "encoding": "ietf-te-types:lsp-encoding-oduk", 2542 "max-lsp-bandwidth": [ 2543 { 2544 "priority": 0, 2545 "// __DISCUSS__ te-bandwidth": "ODU4" 2546 } 2547 ], 2548 "// __DISCUSS__ label-restrictions": "To be adde\ 2549 \d?" 2550 } 2551 ], 2552 "// __DISCUSS__ link-protection-type": "Can we assum\ 2553 \e unprotected as the default value?", 2554 "link-protection-type": "unprotected", 2555 "max-link-bandwidth": { 2556 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2557 }, 2558 "max-resv-link-bandwidth": { 2559 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2560 }, 2561 "unreserved-bandwidth": [ 2562 { 2563 "priority": 0, 2564 "// __DISCUSS__ te-bandwidth": "1xODU4, ..." 2565 } 2566 ] 2567 }, 2568 "oper-status": "up", 2569 "// __EMPTY__ is-transitional": "It is not a transitio\ 2570 \nal link", 2571 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2572 \opology authors" 2573 }, 2574 "source": { 2575 "source-node": "10.0.0.1", 2576 "source-tp": 6 2577 }, 2578 "// __EMPTY__ destination": "inter-domain link" 2579 }, 2580 { 2581 "// __DESCRIPTION__:__LINK__": { 2582 "name": "Access Link from AN1-7", 2583 "type": "access link", 2584 "physical link": "Link from S6-2 to R3" 2585 }, 2586 "link-id": "teNodeId/10.0.0.1teLinkId/7", 2587 "ietf-te-topology:te": { 2588 "te-link-attributes": { 2589 "name": "Access Link from AN1-7", 2590 "// __DISCUSS__ access-type": "Can we assume point-t\ 2591 \o-point as the default value?", 2592 "access-type": "point-to-point", 2593 "// __DISCUSS__ is-abstract": "To be discussed with \ 2594 \TE Topology authors", 2595 "// __DISCUSS__ underlay": "To be discussed with TE \ 2596 \Topology authors", 2597 "admin-status": "up", 2598 "interface-switching-capability": [ 2599 { 2600 "switching-capability": "ietf-te-types:switching\ 2601 \-otn", 2602 "encoding": "ietf-te-types:lsp-encoding-oduk", 2603 "max-lsp-bandwidth": [ 2604 { 2605 "priority": 0, 2606 "// __DISCUSS__ te-bandwidth": "ODU2" 2607 } 2608 ], 2609 "// __DISCUSS__ label-restrictions": "To be adde\ 2610 \d?" 2611 } 2612 ], 2613 "// __DISCUSS__ link-protection-type": "Can we assum\ 2614 \e unprotected as the default value?", 2615 "link-protection-type": "unprotected", 2616 "max-link-bandwidth": { 2617 "// __DISCUSS__ te-bandwidth": "1xODU2" 2618 }, 2619 "max-resv-link-bandwidth": { 2620 "// __DISCUSS__ te-bandwidth": "1xODU2" 2621 }, 2622 "unreserved-bandwidth": [ 2623 { 2624 "priority": 0, 2625 "// __DISCUSS__ te-bandwidth": "1xODU2" 2626 } 2627 ] 2628 }, 2629 "oper-status": "up", 2630 "// __EMPTY__ is-transitional": "It is not a transitio\ 2631 \nal link", 2632 "// __DISCUSS__ underlay ": "To be discussed with TE T\ 2633 \opology authors" 2634 }, 2635 "source": { 2636 "source-node": "10.0.0.1", 2637 "source-tp": 7 2638 }, 2639 "// __EMPTY__ destination": "access link" 2640 } 2641 ] 2642 } 2643 ] 2644 } 2645 } 2647 B.2. JSON Examples for Service Configuration 2649 B.2.1. JSON Code: mpi1-odu2-service-config.json 2651 This is the JSON code reporting the ODU2 transit service 2652 configuration @ MPI: 2654 ========== NOTE: '\\' line wrapping per BCP XX (RFC XXXX) =========== 2656 { 2657 "// __TITLE__": "ODU2 Service Configuration @ MPI1", 2658 "// __LAST_UPDATE__": "October 22, 2018", 2659 "// __MISSING_ATTRIBUTES__": true, 2660 "// __REFERENCE_DRAFTS__": { 2661 "ietf-routing-types@2017-12-04": "rfc8294", 2662 "ietf-otn-types@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model-\ 2663 \02", 2664 "ietf-te-types@2018-07-01": "draft-ietf-teas-yang-te-16", 2665 "ietf-te@2018-07-01": "draft-ietf-teas-yang-te-16", 2666 "ietf-otn-tunnel@2018-06-07": "draft-ietf-ccamp-otn-tunnel-model\ 2667 \-02" 2668 }, 2669 "// __RESTCONF_OPERATION__": { 2670 "operation": "PUT", 2671 "url": "http://{{PNC1-ADDR}}/restconf/data/ietf-te:te" 2672 }, 2673 "ietf-te:te": { 2674 "tunnels": { 2675 "tunnel": [ 2676 { 2677 "name": "mpi1-odu2-service", 2678 "// identifier": "ODU2-SERVICE-TUNNEL-ID @ MPI1", 2679 "identifier": 1, 2680 "description": "ODU2 Service implemented by ODU2 OTN Tunne\ 2681 \l Segment @ MPI1", 2682 "// encoding and switching-type": "ODU", 2683 "encoding": "ietf-te-types:lsp-encoding-oduk ", 2684 "switching-type": "ietf-te-types:switching-otn", 2685 "// source": "None: transit tunnel segment", 2686 "// destination": "None: transit tunnel segment", 2687 "// src-tp-id": "None: transit tunnel segment", 2688 "// dst-tp-id": "None: transit tunnel segment", 2689 "// ietf-otn-tunnel:src-client-signal": "None: ODU transit\ 2690 \ tunnel segment", 2691 "// ietf-otn-tunnel:dst-client-signal": "None: ODU transit\ 2692 \ tunnel segment", 2693 "bidirectional": true, 2694 "// protection": "No protection", 2695 "// __ DEFAULT __ protection": { 2696 "// __ DEFAULT __ enable": false 2697 }, 2698 "// restoration": "No restoration", 2699 "// __ DEFAULT __ restoration": { 2700 "// __ DEFAULT __ enable": false 2701 }, 2702 "// te-topology-identifier": "ODU Black Topology @ MPI1", 2703 "te-topology-identifier": { 2704 "provider-id": 201, 2705 "client-id": 300, 2706 "topology-id": "otn-black-topology" 2707 }, 2708 "te-bandwidth": { 2709 "ietf-otn-tunnel:odu-type": "ietf-otn-types:prot-ODU2" 2710 }, 2711 "// hierarchical-link": "None: transit tunnel segment", 2712 "p2p-primary-paths": { 2713 "p2p-primary-path": [ 2714 { 2715 "name": "mpi1-odu2-service-primary-path", 2716 "path-scope": "ietf-te-types:path-scope-segment", 2717 "// te-bandwidth": "None: only the tunnel bandwidth \ 2718 \needs to be specified in transport applications", 2719 "explicit-route-objects": { 2720 "route-object-include-exclude": [ 2721 { 2722 "// comment": "Tunnel hand-off OTU2 ingress in\ 2723 \terface (S3-1)", 2724 "index": 1, 2725 "explicit-route-usage": "ietf-te-types:route-i\ 2726 \nclude-ero", 2727 "num-unnum-hop": { 2728 "// node-id": "AN1 Node", 2729 "node-id": "10.0.0.1", 2730 "// link-tp-id": "AN1-1 LTP", 2731 "link-tp-id": 1, 2732 "hop-type": "STRICT", 2733 "direction": "INCOMING" 2734 } 2735 }, 2736 { 2737 "// comment": "Tunnel hand-off ODU2 ingress la\ 2738 \bel (ODU2 over OTU2) at S3-1", 2739 "index": 2, 2740 "explicit-route-usage": "ietf-te-types:route-i\ 2741 \nclude-ero", 2742 "label-hop": { 2743 "te-label": { 2744 "// __ DISCUSS __ odu-label": "How are HO-\ 2745 \ODU (ODUk over OTUk) label represented?", 2746 "// __ DISCUSS __ direction": "Check with \ 2747 \TE Tunnel authors", 2748 "direction": "FORWARD " 2749 } 2750 } 2751 }, 2752 { 2753 "// comment": "Tunnel hand-off OTU4 egress int\ 2754 \erface (S2-1)", 2755 "index": 3, 2756 "explicit-route-usage": "ietf-te-types:route-i\ 2757 \nclude-ero", 2758 "num-unnum-hop": { 2759 "// node-id": "AN1 Node", 2760 "node-id": "10.0.0.1", 2761 "// link-tp-id": "AN1-2 LTP", 2762 "link-tp-id": 1, 2763 "hop-type": "STRICT", 2764 "direction": "OUTGOING" 2765 } 2766 }, 2767 { 2768 "// comment": "Tunnel hand-off ODU2 egress lab\ 2769 \el (ODU2 over OTU4) at S2-1", 2770 "index": 4, 2771 "explicit-route-usage": "ietf-te-types:route-i\ 2772 \nclude-ero", 2773 "label-hop": { 2774 "te-label": { 2775 "ietf-otn-tunnel:tpn": 1, 2776 "ietf-otn-tunnel:tsg": "ietf-otn-types:tsg\ 2777 \-1.25G", 2778 "ietf-otn-tunnel:ts-list": "1-8", 2779 "// __ DISCUSS __ direction": "Check with \ 2780 \TE Tunnel authors", 2781 "direction": "FORWARD " 2782 } 2783 } 2784 } 2785 ] 2787 } 2788 } 2789 ] 2790 } 2791 } 2792 ] 2793 } 2794 } 2795 } 2797 B.2.2. JSON Code: mpi1-odu2-tunnel-config.json 2799 The JSON code for this use case will be added in a future version of 2800 this document 2802 An incomplete version is located on GitHub at: 2804 https://github.com/danielkinguk/transport-nbi 2806 B.2.3. JSON Code: mpi1-epl-service-config.json 2808 The JSON code for this use case will be added in a future version of 2809 this document 2811 An incomplete version is located on GitHub at: 2813 https://github.com/danielkinguk/transport-nbi 2814 Authors' Addresses 2816 Italo Busi (Editor) 2817 Huawei 2819 Email: italo.busi@huawei.com 2821 Daniel King (Editor) 2822 Lancaster University 2824 Email: d.king@lancaster.ac.uk 2826 Haomian Zheng (Editor) 2827 Huawei 2829 Email: zhenghaomian@huawei.com 2831 Yunbin Xu (Editor) 2832 CAICT 2834 Email: xuyunbin@ritt.cn 2836 Yang Zhao 2837 China Mobile 2839 Email: zhaoyangyjy@chinamobile.com 2841 Sergio Belotti 2842 Nokia 2844 Email: sergio.belotti@nokia.com 2846 Gianmarco Bruno 2847 Ericsson 2849 Email: gianmarco.bruno@ericsson.com 2850 Young Lee 2851 Huawei 2853 Email: leeyoung@huawei.com 2855 Victor Lopez 2856 Telefonica 2858 Email: victor.lopezalvarez@telefonica.com 2860 Carlo Perocchio 2861 Ericsson 2863 Email: carlo.perocchio@ericsson.com 2865 Ricard Vilalta 2866 CTTC 2868 Email: ricard.vilalta@cttc.es