idnits 2.17.1 draft-tnbidt-ccamp-transport-nbi-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 13, 2017) is 2593 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group I. Busi (Ed.) 2 Internet-Draft Huawei 3 Intended status: Informational D. King (Ed.) 4 Expires: September 14, 2017 Lancaster University 5 March 13, 2017 7 Transport Northbound Interface Use Cases 8 draft-tnbidt-ccamp-transport-nbi-use-cases-01 10 Abstract 12 Transport network domains, including Optical Transport Network (OTN) 13 and Wavelength Division Multiplexing (WDM) networks, are typically 14 deployed based on a single vendor or technology platforms. They are 15 often managed using proprietary interfaces to dedicated Element 16 Management Systems (EMS), Network Management Systems (NMS) and 17 increasingly Software Defined Network (SDN) controllers. 19 A well-defined open interface to each domain management system or 20 controller is required for network operators to facilitate control 21 automation and orchestrate end-to-end services across multi-domain 22 networks. These functions may be enabled using standardized data 23 models (e.g. YANG), and appropriate protocol (e.g., RESTCONF). 25 This document describes the key use cases and requirements for 26 transport network control and management. It reviews proposed and 27 existing IETF transport network data models, their applicability, 28 and highlights gaps and requirements. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 14, 2017. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. This document is subject 51 to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 52 Documents (http://trustee.ietf.org/license-info) in effect on the 53 date of publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. 57 Table of Contents 59 1. Introduction.................................................1 60 2. Conventions used in this document............................3 61 3. Use Case 1: Single-domain with single-layer..................3 62 3.1. Reference Network.......................................3 63 3.1.1. Single Transport Domain - OTN Network..............6 64 3.1.2. Single Domain - ROADM Network......................6 65 3.2. Topology Abstractions...................................6 66 3.3. Service Configuration...................................7 67 3.3.1. ODU Transit........................................7 68 3.3.2. EPL over ODU.......................................8 69 3.3.3. Other OTN Client Services..........................8 70 3.3.4. EVPL over ODU......................................9 71 3.3.5. EVPLAN and EVPTree Services........................9 72 3.3.6. Virtual Network Services...........................9 73 3.4. Multi-functional Access Links...........................9 74 4. Use Case 2: Single-domain with multi-layer...................9 75 5. Use Case 3: Multi-domain with single-layer...................9 76 6. Use Case 4: Multi-domain and multi-layer.....................9 77 7. Security Considerations......................................9 78 8. IANA Considerations..........................................9 79 9. References...................................................10 80 9.1. Normative References....................................10 81 9.2. Informative References..................................10 82 10. Acknowledgments.............................................10 83 Authors' Addresses..............................................11 85 1. Introduction 87 A common open interface to each domain controller/management system 88 is pre-requisite for network operators to control multi-vendor and 89 multi-domain networks and enable also service provisioning 90 coordination/automation. This can be achieved by using standardized 91 YANG models, used together with an appropriate protocol (e.g., 92 RESTCONF). 94 This document assumes a reference architecture, including interfaces, 95 based on the Abstraction and Control of Traffic-Engineered Networks 96 (ACTN), defined in [ACTN-Frame]. 98 The focus of the current version is on the MPI (interface between 99 the Multi Domain Service Coordinator (MDSC) and a Physical Network 100 Controller (PNC), controlling a transport network domain). 102 The relationship between the current IETF YANG models and the type of 103 ACTN interfaces can be found in [ACTN-YANG]. 105 The ONF Technical Recommendations for Functional Requirements 106 for the transport API, may be found in [ONF TR-527]. 107 Furthermore, ONF transport API multi-layer examples may be 108 found in [ONF GitHub]. 110 This document describes use cases that could be used for analyzing 111 the applicability of the existing models defined by the IETF for 112 transport networks 114 Considerations about the CMI (interface between the Customer Network 115 Controller (CNC) and the MDSC) are for further study. 117 2. Conventions used in this document 119 For discussion in future revisions of this document. 121 3. Use Case 1: Single-domain with single-layer 123 3.1. Reference Network 125 The current considerations discussed in this document are 126 based on the following reference networks: 128 - single transport domain: OTN network 130 It is expected that future revisions of the document will 131 include additional reference networks. 133 3.1.1. Single Transport Domain - OTN Network 135 Figure 1 shows the network physical topology composed of a 136 single-domain transport network providing transport services to an 137 IP network through five access links. 139 ................................................ 140 : IP domain : 141 : .............................. : 142 : : ........................ : : 143 : : : : : : 144 : : : S1 -------- S2 ------ C-R4 : 145 : : : / | : : : 146 : : : / | : : : 147 : C-R1 ------ S3 ----- S4 | : : : 148 : : : \ \ | : : : 149 : : : \ \ | : : : 150 : : : S5 \ | : : : 151 : C-R2 -----+ / \ \ | : : : 152 : : : \ / \ \ | : : : 153 : : : S6 ---- S7 ---- S8 ------ C-R5 : 154 : : : / : : : 155 : C-R3 -----+ : : : 156 : : : Transport domain : : : 157 : : : : : : 158 :........: :......................: :........: 160 Figure 1 Reference network for Use Case 1 162 The IP and transport (OTN) domains are respectively composed by five 163 routers C-R1 to C-R5 and by eight ODU switches S1 to S8. The 164 transport domain acts as a transit domain providing connectivity to 165 the IP layer. 167 The behavior of the transport domain is the same whether the 168 ingress/egress nodes in the IP domain, supporting an IP service, are 169 directly attached to the transport domain or there are other routers 170 in between the ingress/egress nodes of the IP domain and the routers 171 directly attached to the transport network. 173 +-----+ 174 | CNC | 175 +-----+ 176 | 177 |CMI I/F 178 | 179 +-----------------------+ 180 | MDSC | 181 +-----------------------+ 182 | 183 |MPI I/F 184 | 185 +-------+ 186 | PNC | 187 +-------+ 188 | 189 ----- 190 ( ) 191 ( OTN ) 192 ( Physical ) 193 ( Network ) 194 ( ) 195 ----- 197 Figure 2 Controlling Hierarchy for Use Case 1 199 The mapping of the client IP traffic on the physical link between the 200 routers and the transport network is made in the IP routers only and 201 is not controlled by the transport PNC and is transparent to the 202 transport nodes. 204 The control plane architecture follows the ACTN architecture and 205 framework document [ACTN-Frame]. The Client Controller act as a 206 client with respect to the Multi-Domain Service Coordinator (MDSC) 207 via the Controller-MDSC Interface (CMI). The MDSC is connected to a 208 plurality of Physical Network Controllers (PNCs), one for each 209 domain, via a MDSC-PNC Interface (MPI). Each PNC is responsible 210 only for the control of its domain and the MDSC is the only entity 211 capable of multi-domain functionalities as well as of managing the 212 inter-domain links. The key point of the whole ACTN framework is 213 detaching the network and service control from the underlying 214 technology and help the customer express the network as desired 215 by business needs. Therefore, care must be taken to keep minimal 216 dependency on the CMI (or no dependency at all) with respect to 217 the network domain technologies. The MPI instead requires some 218 specialization according to the domain technology. 220 In this section, we address the case of an IP and a Transport PNC 221 having respectively an IP a Transport MPI. The interface within 222 the scope of this document is the Transport MPI while the IP 223 Network MPI is out of its scope and considerations about the CMI 224 are for further study. 226 3.2. Topology Abstractions 228 There are multiple methods to abstract a network topology. This 229 document assumes the abstraction method defined in [RFC7926]: 231 Abstraction is the process of applying policy to the available TE 232 information within a domain, to produce selective information that 233 represents the potential ability to connect across the domain. 234 Thus, abstraction does not necessarily offer all possible 235 connectivity options, but presents a general view of potential 236 connectivity according to the policies that determine how the 237 domain's administrator wants to allow the domain resources to be 238 used. 240 [TE-Topo] describes a YANG base model for TE topology without any 241 technology specific parameters. Moreover, it defines how to abstract 242 for TE-network topologies. 244 [ACTN-Abstraction] provides the context of topology abstraction in 245 the ACTN architecture and discusses a few alternatives for the 246 abstraction methods for both packet and optical networks. This is an 247 important consideration since the choice of the abstraction method 248 impacts protocol design and the information it carries. According to 249 [ACTN-Abstraction], there are three types of topology: 251 o White topology: This is a case where the Physical Network 252 Controller (PNC) provides the actual network topology to the 253 Multi-domain Service Coordinator (MDSC) without any hiding or 254 filtering. In this case, the MDSC has the full knowledge of the 255 underlying network topology. 257 o Black topology: The entire domain network is abstracted as a 258 single virtual node with the access/egress links without 259 disclosing any node internal connectivity information. 261 o Grey topology: This abstraction level is between black topology 262 and white topology from a granularity point of view. This is 263 abstraction of TE tunnels for all pairs of border nodes. We may 264 further differentiate from a perspective of how to abstract 265 internal TE resources between the pairs of border nodes: 267 - Grey topology type A: border nodes with a TE links between 268 them in a full mesh fashion. 270 - Grey topology type B: border nodes with some internal 271 abstracted nodes and abstracted links. 273 For single-domain with single-layer use-case, the white topology may 274 be disseminated from the PNC to the MDSC in most cases. There may be 275 some exception to this in the case where the underlay network may 276 have complex optical parameters, which do not warrant the 277 distribution of such details to the MDSC. In such case, the topology 278 disseminated from the PNC to the MDSC may not have the entire TE 279 information but a streamlined TE information. This case would for 280 single-domain with single-layer use-case, the white topology may be 281 disseminated from the PNC to the MDSC in most cases. There may be 282 some exception to this in the case where the underlay network may 283 have complex optical parameters, which do not warrant the 284 distribution of such details to the MDSC. In such case, the topology 285 disseminated from the PNC to the MDSC may not have the entire TE 286 information but a streamlined TE information. This case would incur 287 another action from the MDSC's standpoint when provisioning a path. 288 The MDSC may make a path compute request to the PNC to verify the 289 feasibility of the estimated path before making the final 290 provisioning request to the PNC, as outlined in [Path-Compute]. 292 Topology abstraction for the CMI is for further study (to be 293 addressed in future revisions of this document). 295 3.3. Service Configuration 297 In the following use cases, the Multi Domain Service Coordinator 298 (MDSC) needs to be capable to request service connectivity from the 299 transport Physical Network Controller (PNC) to support IP routers 300 connectivity. The type of services could depend of the type of 301 physical links (e.g. OTN link, ETH link or SDH link) between the 302 routers and transport network. 304 As described in section 3.1.1, the control of different adaptations 305 inside IP routers, C-Ri (PKT -> foo) and C-Rj (foo -> PKT), are 306 assumed to be performed by means that are not under the control of, 307 and not visible to, transport PNC. Therefore, these mechanisms are 308 outside the scope of this document. 310 3.3.1. ODU Transit 312 This use case assumes that the physical link interconnecting IP 313 routers and transport network is an OTN link. 315 The physical/optical interconnection is supposed to be a 316 pre-configured and not exposed via MPI to MDSC. 318 If we consider the case of a 10Gb IP link between C-R1 to C-R3, 319 we need to instantiate an ODU2 end-to-end connection between C-R1 320 and C-R3, crossing transport nodes S3, S5, and S6. 322 The traffic flow between C-R1 and C-R3 can be summarized as: 324 C-R1 (PKT -> ODU2), S3 (ODU2), S5 (ODU2), S6 (ODU2), 325 C-R3 (ODU2 -> PKT) 327 The MDSC should be capable via MPI interface to request the setup of 328 ODU2 transit service with enough information that can permit 329 transport PNC to instantiate and control the ODU2 segment through 330 nodes S3, S5, S6. 332 3.3.2. EPL over ODU 334 This use case assumes that the physical link interconnecting IP 335 routers and transport network is an Ethernet link. 337 If we consider the case of a 10Gb IP link between C-R1 to C-R3, we 338 need to instantiate an EPL service between C-R1 and C-R3 supported 339 by an ODU2 end-to-end connection between S3 and S6, crossing 340 transport node S5. 342 The traffic flow between C-R1 and C-R3 can be summarized as: 344 C-R1 (PKT -> ETH), S3 (ETH -> ODU2), S5 (ODU2), 345 S6 (ODU2 -> ETH), C-R3 (ETH-> PKT) 347 The MDSC should be capable via MPI i/f to request the setup of EPL 348 service with enough information that can permit transport PNC to 349 instantiate and control the ODU2 end-to-end connection through nodes 350 S3, S5, S6, as well as the adaptation functions inside S3 and S6: 351 S3&S6 (ETH -> ODU2) and S9&S6 (ODU2 -> ETH). 353 3.3.3. Other OTN Client Services 355 [ITU-T G.709-2016] defines mappings of different client layers into 356 ODU. Most of them are used to provide Private Line services over 357 an OTN transport network supporting a variety of types of physical 358 access links (e.g., Ethernet, SDH STM-N, Fibre Channel, 359 InfiniBand,). 361 This use case assumes that the physical links interconnecting IP 362 routers and transport network are any one of these possible 363 options. 365 If we consider the case of a 10Gb IP link between C-R1 to C-R3 366 using SDH physical links, we need to instantiate an STM-64 Private 367 Line service between C-R1 and C-R3 supported by an ODU2 end-to-end 368 connection between S3 and S6, crossing transport node S5. 370 The traffic flow between C-R1 and C-R3 can be summarized as: 372 C-R1 (PKT -> STM-64), S3 (STM-64 -> ODU2), S5 (ODU2), 373 S6 (ODU2 -> STM-64), C-R3 (STM-64 -> PKT) 375 The MDSC should be capable via MPI i/f to request the setup of an 376 STM-64 Private Line service with enough information that can permit 377 transport PNC to instantiate and control the ODU2 end-to-end 378 connection through nodes S3, S5, S6, as well as the adaptation 379 functions inside S3 and S6: S3&S6 (STM-64 -> ODU2) and S9&S3 380 (STM-64 -> PKT). 382 3.3.4. EVPL over ODU 384 For future revision. 386 3.3.5. EVPLAN and EVPTree Services 388 For future revision. 390 3.3.6. Virtual Network Services 392 For future revision 394 3.4. Multi-functional Access Links 396 For future revision 398 4. Use Case 2: Single-domain with multi-layer 400 For future revision 402 5. Use Case 3: Multi-domain with single-layer 404 For future revision 406 6. Use Case 4: Multi-domain and multi-layer 408 For future revision 410 7. Security Considerations 412 For further study 414 8. IANA Considerations 416 This document requires no IANA actions. 418 9. References 420 9.1. Normative References 422 [RFC7926] Farrel, A. et al., "Problem Statement and Architecture for 423 Information Exchange between Interconnected Traffic-Engineered 424 Networks", BCP 206, RFC 7926, July 2016. 426 [ITU-T G.709-2016] ITU-T Recommendation G.709 (06/16), "Interfaces 427 for the optical transport network", June 2016. 429 [ACTN-Frame] Ceccarelli, D., Lee, Y. et al., "Framework for 430 Abstraction and Control of Transport Networks", 431 draft-ietf-teas-actn-framework, work in progress. 433 [ACTN-Abstraction] Lee, Y. et al., " Abstraction and Control of 434 TE Networks (ACTN) Abstraction Methods", 435 draft-lee-teas-actn-abstraction, work in progress. 437 9.2. Informative References 439 [TE-Topo] Liu, X. et al., "YANG Data Model for TE Topologies", 440 draft-ietf-teas-yang-te-topo, work in progress. 442 [ACTN-YANG] Zhang, X. et al., "Applicability of YANG models for 443 Abstraction and Control of Traffic Engineered Networks", 444 draft-zhang-teas-actn-yang, work in progress. 446 [Path-Compute] Busi, I., Belotti, S. et al., " Yang model for 447 requesting Path Computation", draft-busibel-teas-yang-path- 448 computation, work in progress. 450 [ONF TR-527] ONF Technical Recommendation TR-527, "Functional 451 Requirements for Transport API", June 2016 453 [ONF GitHub] ONF Open Transport (SNOWMASS) 454 https://github.com/OpenNetworkingFoundation/Snowmass- 455 ONFOpenTransport 457 10. Acknowledgments 459 The authors would like to thank all members of the Transport NBI 460 Design Team involved in the definition of use cases, gap analysis 461 and guidelines for using the IETF YANG models at the Northbound 462 Interface (NBI) of a Transport SDN Controller. 464 The authors would like to thank Xian Zhang, Anurag Sharma, Michael 465 Scharf, Karthik Sethuraman, Oscar Gonzalez de Dios, Tara Cummings 466 and Hans Bjursrom, for having initiated work on gap analysis for 467 transport NBI and having provided foundations work for the 468 development of this document. 470 Authors' Addresses 472 Italo Busi (Editor) 473 Huawei 474 Email: italo.busi@huawei.com 476 Daniel King 477 Lancaster University 478 Email: d.king@lancaster.ac.uk 480 Sergio Belotti 481 Nokia 482 Email: sergio.belotti@nokia.com 484 Gianmarco Bruno 485 Ericsson 486 Email: gianmarco.bruno@ericsson.com 488 Young Lee 489 Huawei 490 Email: leeyoung@huawei.com 492 Victor Lopez 493 Telefonica 494 Email: victor.lopezalvarez@telefonica.com 496 Carlo Perocchio 497 Ericsson 498 Email: carlo.perocchio@ericsson.com 500 Haomian Zheng 501 Huawei 502 Email: zhenghaomian@huawei.com