idnits 2.17.1 draft-rokui-5g-transport-slice-00.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 == Line 543 has weird spacing: '...Midhaul netwo...' == Line 581 has weird spacing: '...Midhaul netwo...' == Line 632 has weird spacing: '... tp termi...' -- The document date (July 2, 2019) is 1760 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Mbps' is mentioned on line 324, but not defined == Missing Reference: 'Optional' is mentioned on line 370, but not defined == Unused Reference: 'I-D.boucadair-connectivity-provisioning-protocol' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-network-topo' is defined on line 1052, but no explicit reference was found in the text == Unused Reference: 'RFC7297' is defined on line 1078, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-15 == Outdated reference: A later version (-02) exists of draft-homma-slice-provision-models-00 == Outdated reference: A later version (-24) exists of draft-ietf-teas-actn-vn-yang-04 == Outdated reference: A later version (-10) exists of draft-king-teas-applicability-actn-slicing-04 -- Obsolete informational reference (is this intentional?): RFC 8049 (Obsoleted by RFC 8299) Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual R. Rokui 3 Internet-Draft Nokia 4 Intended status: Informational S. Homma 5 Expires: January 3, 2020 NTT 6 D. Lopez 7 Telefonica I+D 8 X. de Foy 9 InterDigital Inc. 10 L. Contreras-Murillo 11 J. Ordonez-Lucena 12 Telefonica I+D 13 P. Martinez-Julia 14 NICT 15 M. Boucadair 16 Orange 17 P. Eardley 18 BT 19 K. Makhijani 20 Futurewei Networks 21 H. Flinck 22 Nokia 23 July 2, 2019 25 5G Transport Slice Connectivity Interface 26 draft-rokui-5g-transport-slice-00 28 Abstract 30 The 5G Network slicing is an approach to provide separate independent 31 E2E logical network from user equipment (UE) to applications where 32 each network slice has different SLA requirements. Each E2E network 33 slice consists of multitude of RAN-slice, Core-slice and Transport- 34 slices, each with its own controller. To provide automation, 35 assurance and optimization of the network slices, an E2E network 36 slice controller is needed which interacts with controller in RAN, 37 Core and Transport slices. The interfaces between the E2E network 38 slice controller and RAN and Core controllers are defined in various 39 3GPP technical specifications. However, 3GPP has not defined the 40 same interface for transport slices. 42 The aim of this document is to provide the clarification of this 43 interface and to provide the information model of this interface for 44 automation, monitoring and optimization of the transport slices. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on January 3, 2020. 63 Copyright Notice 65 Copyright (c) 2019 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 82 2. High level architecture of 5G end-to-end network slicing . . 5 83 3. Logical flow cross layers for automation of an end-to-end 84 network slices . . . . . . . . . . . . . . . . . . . . . . . 8 85 4. Definition of Transport Slice . . . . . . . . . . . . . . . . 11 86 4.1. Transport Slices in Distributed RAN . . . . . . . . . . . 11 87 4.2. Transport Slices in Centralized RAN (C-RAN) . . . . . . . 12 88 4.3. Transport Slices in cloud RAN . . . . . . . . . . . . . . 13 89 4.4. Transport Slice as a set of networks . . . . . . . . . . 14 90 5. Transport Slice Connectivity Interface (TSCi) . . . . . . . . 16 91 5.1. Relationship between TSCi and various IETF data models . 17 92 5.2. Realization (aka Implementation) of transport slices . . 18 93 6. Transport slice connectivity interface (TSCi) information 94 model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 6.1. transport-slice-info . . . . . . . . . . . . . . . . . . 22 96 6.2. network-slice-info . . . . . . . . . . . . . . . . . . . 22 97 6.3. transport-slice-networks . . . . . . . . . . . . . . . . 22 98 6.4. node . . . . . . . . . . . . . . . . . . . . . . . . . . 22 99 6.5. connection-link . . . . . . . . . . . . . . . . . . . . . 23 100 6.6. transport-slice-policy . . . . . . . . . . . . . . . . . 23 101 6.6.1. transport-slice-sla-policy . . . . . . . . . . . . . 23 102 6.6.2. transport-slice-selection-policy . . . . . . . . . . 23 103 6.6.3. transport-slice-assurance-policy . . . . . . . . . . 23 104 6.7. IETF models . . . . . . . . . . . . . . . . . . . . . . . 24 105 6.7.1. ACTN model . . . . . . . . . . . . . . . . . . . . . 24 106 6.7.2. i2rs model . . . . . . . . . . . . . . . . . . . . . 24 107 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 108 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 109 9. Informative References . . . . . . . . . . . . . . . . . . . 24 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 112 1. Introduction 114 Network Slicing is a mechanism which a network operator can use to 115 allocate dedicated infrastructures and services to a customer (aka 116 tenant) from shared operator's network. In particular a 5G network 117 slice is inherently an E2E concept and is composed of multiple 118 logical independent networks are created in a common operator's 119 network from an user equipement to applications. In specific, the 120 network slicing receives attention due to factors such as diversity 121 of services and devices in 5G each with its own SLA requirements. 122 Each E2E network slice consists of multitude of RAN-slice, Core-slice 123 and Transport-slices each with its own controller. 125 To provide automation, assurance and optimization of the network 126 slices, an E2E network slice orchestrator is needed which interacts 127 with controller of RAN, Core and Transport slices. The interfaces 128 between the E2E network slice controller and RAN and Core controllers 129 are defined in various 3GPP technical specifications. However, 3GPP 130 has not defined the same interface for transport slices. The aim of 131 this document is to provide the clarification of this interface and 132 to provide the information model of this interface for automation, 133 monitoring and optimization of the transport slices. 135 1.1. Definition of Terms 137 Please refer to [I-D.homma-slice-provision-models] as well. 139 Customer: Also known as Tenant. Any application, client network, or 140 customer of a network provider, i.e. an NS tenant is a person or 141 group that rents and occupies NSIs from network provider. 143 E2E Network Slice: A E2E network slice is a virtual network provided 144 by a Slice Provider that has the functionality and performance to 145 support a specific industry sector and/or service. This 146 capability will be the subject of a commercial agreement between 147 the Slice Provider and Slice Buyer, and although it may well 148 support dynamic scale-in/out, the Slice capability will normally 149 be long-lasting i.e. only change on commercial timescales, 150 although this may become more dynamic over time. 152 In specific, E2E 5G network slices are separate independent 153 logical network E2E from user equipment (UE) to applications in a 154 common infrastructure where each logical network has dedicated 155 SLA. It is an E2E concept which spans multiple network domains 156 (e.g. radio, transport and core), and in some cases more than one 157 administrative domain. 159 Network Slice Instance (NSI): Also known as Network slice profile 160 (NS profile), NSI is an E2E instance of a network slice blueprint 161 which is instantiated in service provider's network for specific 162 customer and specific service type. Note that customer and 163 service type can be wildcard. 165 Transport Slice: It is also called Transport Sub-Slice. A set of 166 connections between various network functions (VNF or PNF) with 167 deterministic SLAs. They can be implemented (aka realized) with 168 various technologies (e.g. IP, Optics, FN, Microwave) and various 169 transport (e.g. RSVP, Segment routing, ODU, OCH etc). 171 RAN Slice: It is also called RAN Sub-Slice. The context and 172 personality created on RAN network functions for each E2E network 173 slice. 175 Core Slice: It is also called Core Sub-Slice. The context and 176 personality created on Core network (CN) functions for each e2e 177 network slice. 179 S-NSSAI: Single Network Slice Selection Assistance Information, 180 defined by 3GPP and is the identification of a Network Slice 182 Sub-Slice: The RAN, Transport or Core Slices are also called Sub- 183 Slice or Subnet; i.e. RAN, Transport and Core Sub-slices or 184 Subnets 186 Service Level Agreement (SLA): An agreement between a customer (aka 187 tenant) and network provider that describes the quality with which 188 features and functions are to be delivered. It may include 189 information on target KPIs (such as min guaranteed throughput, max 190 tolerable latency, max tolerable packet loss rate); the types of 191 service (such as the network service functions or billing) to be 192 executed; the location, nature, and quantities of services (such 193 as the amount and location of compute resources and the 194 accelerators require) 196 gNB: gNB incorporates two major modules; Centralized Unit (CU) and 197 Distribute Unit (DU) 199 UE: UE: User Equipment such as vehicle Infotainment, Cell phone, IoT 200 sensor etc 202 2. High level architecture of 5G end-to-end network slicing 204 To demonstrate the concept of 5G E2E network slicing and the role of 205 various controllers consider a typical 5G network shown in Figure 1 206 where a mobile network operator Y has two customers (tenants) C1 and 207 Public Safety. The boundaries of administrative domain of the 208 operator includes RAN, Transport, Core and Application domains. Each 209 customer requests to have several logical independent E2E networks 210 from UEs (e.g. vehicle infotainment, mobile phone, IoT meters etc.) 211 to the application, each with distinct SLAs. In 5G, each of these 212 independent networks called an E2E network slice, which consists of 213 RAN, Transport and Core slices (or RAN, Transport and Core Sub- 214 slices). 216 In Figure 1 there are four E2E network slices, NS1 to NS4, each with 217 its own RAN, Core and Transport slices. To create RAN slice, the RAN 218 network functions such as eNB and gNB should be programmed to have a 219 context for each E2E network slice. This context means that the RAN 220 network functions should allocate certain resources for each E2E 221 network slice such as air interface, various schedulers, policies and 222 profiles to guarantee the SLA requirement for that specific network 223 slice. By the same token, the Core slice means to create the context 224 for each E2E network slice on Core network functions. This means 225 that the RAN and Core network functions are aware of multiple E2E 226 network slices. 228 When both RAN and Core slices are created, they should be connected 229 together using a set of connections to have an E2E network slice. 230 These set of connections are called Transport Slices, i.e. the 231 transport slices are a group of connections with specific SLAs. The 232 following factors dictate the number of transport slices. The 233 details on transport slices will be discussed in see Section 4: 235 o The RAN deployment (i.e. distributed RAN, Centralized RAN or Cloud 236 RAN). For example, in Cloud RAN, the RAN network function (i.e. 237 gNB) is decomposed into two network functions (called CU and DU) 238 where one or both will be VNFs and there is a Midhaul network 239 between them. In this case, there will be a transport slice in 240 RAN to connect DUs to CU 242 o The location of the mobile applications. If there is a network 243 between the mobile applications and the 5G Core, another transport 244 slice is needed to connect the 5G Core to Applications. 246 o Mobile network policy on how to allow creation of the E2E network 247 slices and if the sharing of transport slices between multiple E2E 248 network slices are desirable and allowed. 250 At the end when RAN, Core and Transport slices are created, they 251 should be bind or associated together to form a working E2E network 252 slice. Since the nature of an E2E network slice is dynamic and the 253 life cycle of each network slice might be a few hours or few months, 254 various controllers are needed to perform the life cycle of various 255 E2E network slices in their respective domains. As shown in 256 Figure 1, each RAN, Core and Transport slice needs a controller. 257 Also an E2E network slice controller is needed to provide the 258 coordination and control of network slices from an E2E perspective. 260 In summary, an E2E network slice will involve several domains, each 261 with its own controller: 5G RAN domain, transport domain, and 5G core 262 domain. These need to be coordinated in order to deliver an E2E 263 service. Note that in this context a service is not necessarily an 264 IP/MPLS service but rather customer (aka tenant) facing services such 265 as CCTV service, eMBB service and Infotainment service etc. 267 <-------------- End to End Network Slices ----------------> 269 <----- RAN -----> <----- Transport ----> <----- Core -----> 270 Slice Slice Slice 272 |---------------------------------------------------------| 273 | E2E Network Slice Controller | 274 |---------------------------------------------------------| 276 |----------------| |-------------------| |----------------| 277 | RAN | | Transport | | Core | 278 | Controller | | Controller | | Controller | 279 |----------------| |-------------------| |----------------| 281 ................ .................... ......... ....... 282 : : : : : : : : 283 : : : : : : : : 284 ------------------------------------------------------------- NS1 285 ============================================================= NS2 286 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ NS3 287 : : : : : : : : 288 : : : : : : : : 289 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - NS4 290 : : : : : : : : 291 : : : : : : : : 292 :..............: :..................: :.......: :.....: 294 RAN Transport Core Mobile 295 Network Network Network Application 297 Customers (aka Tenants): Public Safety and C1 298 MNO (Mobile Network Operator): Operator Y 300 Legend: 301 ----- NS1: E2E network slice 1 for customer C1, 302 service type Infotainment 303 ===== NS2: E2E network slice 2 for customer C1, 304 service type Autonomous Driving 305 +++++ NS3: E2E network slice 3 for customer C1, 306 service type HD Map (NS3) 307 - - - NS4: E2E network slice 4 for customer Public Safety, 308 service type Video Surveillance 310 Figure 1: High level architecture of 5G end-to-end network slicing 312 3. Logical flow cross layers for automation of an end-to-end network 313 slices 315 Figure 2 provides the logical flow cross layers to achieve the 316 automatic creation of each E2E network slices such as NS1 mentioned 317 in Figure 1. Below are the logical flow among various controllers to 318 achieve this. It is important to note that these steps are logical 319 and in practice some of them can be combined. For example, step 3 320 can be combined with steps 4 or 5. 322 1. The customer C1 will request the Operator Y for creation of an 323 E2E network slice for Infotainment service type and SLA of 10 324 [Mbps] 326 2. The E2E network slice controller receives this request and using 327 its pre-defined network slice blueprints (aka network slice 328 templates) creates a network slice profile (aka network slice 329 instance) which contains all the network functions in RAN and 330 core which should be part of this E2E network slice. It then 331 goes through decomposition of this profile and triggers various 332 actions. Steps 3 to 7 shows these actions. 334 3. A request for creation of the RAN slice will be triggered to RAN 335 Controller. 337 4. If RAN network functions are virtual, the RAN Slice controller 338 triggers the creation of VNFs in RAN (using for example ETSI 339 interface Os-Ma-nfvo) 341 5. NFVO manages the life cycle of virtual RAN network functions 343 6. Since both physical and virtual RAN network functions which are 344 part of the E2E network functions are known to RAN controller, 345 it then triggers the creation of RAN slice by programming RAN 346 network functions 348 7. Similar to previous steps, a request for creation of the Core 349 slice will be triggered to Core Controller. 351 8. If Core network functions are virtual, the Core Slice controller 352 triggers the creation of VNFs (using for example ETSI interface 353 Os-Ma-nfvo) and NFVO manages the life cycle of virtual Core 354 network functions 356 9. Since both physical and virtual Core network functions which are 357 part of the E2E network functions are known to Core controller, 358 it then triggers the creation of Core slice by programming Core 359 network functions 361 10. In this step, various transport slices (i.e. various 362 connections) need to be created between various network 363 functions, e.g. transport slices between RAN and Core slices, 364 transport slices between RAN network functions or transport 365 slices between core and applications 367 11. The transport slices will be implemented (aka realized) in the 368 network 370 12. [Optional] If the creation of transport slice involves creation 371 of VNFs (e.g. Firewall, security gateway etc.), triggers the 372 creation of these VNFs (using for example ETSI interface Os-Ma- 373 nfvo) 375 13. The E2E network slice controller binds (or associates) all these 376 slices together to form a single E2E network slice for specific 377 customer and specific service type. 379 14. At the end, when the E2E network slice is created, the E2E 380 network slice controller will allocate a unique network slice id 381 (called S-NSSAI) and eventually during the UE network attach, 382 all the UEs will be informed about the existence of this newly 383 created E2E network slice and then they can request it using the 384 3GPP 5G signaling procedures. 386 Note that the interfaces 3 and 7 between the E2E network slice 387 Controller and RAN and Core controllers and their information models 388 are defined in various 3GPP technical specifications. However, 3GPP 389 has not defined the same interface for transport slices, i.e. 390 interface 10. The aim of this document is to define this interface. 391 More details will be provided in Section 5. 393 |----------------------------------------------------| 394 | Customer (aka Tenant) portal | 395 |----------------------------------------------------| 396 |(1) 397 V 398 |----------------------------------------------------| 399 | Generate NS Profile (aka NSI) using NS Blueprints | 400 | |(2) | E2E NS 401 | V | Controller 402 | Decompose NS Profile and trigger various actions | 403 |----------------------------------------------------| 404 |(3) |(10) |(7) 405 | |--------| | |------| | 406 V | V V V | V 407 --------------- | ----------------- | ---------------- 408 | RAN | | | Transport | | | Core | Domain 409 | Slice |-| | Slice | |-| Slice | Controllers 410 | Controller | | Controller | | Controller | 411 --------------- ----------------- ---------------- 412 (6)| |(4) (11)| |(12) (8)| |(9) 413 | | | |--------| | | 414 | |-------------- | --------| | |------| | 415 | | V V V | 416 | | |----------| | 417 | | | NFVO | | 418 | | |----------| | 419 V V |(5) V 420 .............. ................. | ................. 421 : RAN Slice : :Transport slice: | : Core Slice : 422 :............: :...............: | :...............: 423 .................................. | .................. 424 : E2E Network Slice | : (13) 425 :................................. | .................: 426 | 427 V 428 |-----------------------------------------------------| 429 | ,--------. ,-------------. ,--------. | 430 | / RAN \ / Transport \ / Core \ | Operator "Y" 431 | \ Domain / \ Domain / \ Domain / | 432 | `--------' `-------------' `--------' | 433 |-----------------------------------------------------| 435 Figure 2: Logical flow cross layers for automation of an end-to-end 436 network slices 438 4. Definition of Transport Slice 440 Since the transport slice is an important concept throughout this 441 document, this section describes this concept in more detail. To 442 this end, consider Figure 3 where a group of physical or virtual 443 network functions (PNF, VNF or both) are connected together. In 444 particular, a single transport slice is defined as: 446 o A distinct set of connections between multiple VNFs and PNFs each 447 with its own deterministic SLA which is implemented (aka realized) 448 in the network using any technology (e.g IP, Optics, Microwave and 449 PON), any tunnel types (e.g. IP, MPLS, SR, ODU/OCH) and any 450 L0/L1/L2/L3 service types 452 |-----| (---------------------) 453 | NF11| ( ) 454 |-----| ( Transport Slice ) |-----| 455 ( ) | NF21| 456 |-----| ( ) |-----| 457 | NF12| ( A set of distinct ) . 458 |-----| ( connetions connecting ) . 459 . ( physical or virtul ) |-----| 460 . ( network functions (PNF/VNF)) | NF2m| 461 . ( NF11, NF12, ..., NF1n to ) |-----| 462 |-----| ( NF21, ..., NF2m ) 463 | NF1n| ( ) 464 |-----| ( ) 465 (---------------------) 467 Figure 3: Definition of transport slice 469 For clarity, in next three sections, a few examples of the transport 470 slices will be provided for following RAN deployments: 472 o Distributed RAN 474 o Centralized RAN (C-RAN) 476 o Cloud RAN 478 4.1. Transport Slices in Distributed RAN 480 Distributed RAN is the most common deployment of 4G and 5G RAN 481 networks where as shown in Figure 4, the RAN network is connected to 482 Core network using the transport network. Optionally the mobile 483 applications can be also connected to the Core network using another 484 overlay network (e.g. Internet where the mobile applications are 485 virtualized in another data center). 487 In this case, for a single E2E network slice, in addition to RAN and 488 Core slices, there are two sets of transport slices; TS_1 and TS_2. 489 TS_1 is connecting the RAN to Core and TS_2 is connecting Core to 490 Applications. 492 <----------- End to End Network Slice ----------> 493 <--- RS --> <-- CS --> 494 <--- TS_1 ---> <--- TS_2 ---> 495 .................. 496 : RAN : 497 : : ............. ........... 498 : |----| |-----| : : : |------| : : |-----| 499 : | RU | | BBU | : : Transport : | Core | : Other : | App | 500 : |----| |-----| : : Network : |------| : Network : |-----| 501 : : :...........: :.........: 502 :................: 504 Legend 505 TS: Transport Slice 506 RS: RAN Slice 507 CS: Core Slice 509 Figure 4: Transport slices in distributed RAN 511 4.2. Transport Slices in Centralized RAN (C-RAN) 513 The RAN consists of two functional units, the baseband unit (BBU) and 514 the radio unit (RU). The BBU processes the signal and is connected 515 to the transport network. The RU transmits and receives the carrier 516 signal that is transmitted over the air to the end user equipment 517 (UE). In Centralized RAN (aka C-RAN) as depicted in Figure 5, the RU 518 and BBU are separated by a network called fronthaul network. In this 519 case a single E2E network slice contains three set of transport 520 slices TS_1, TS_2 and TS_3 where TS_1 and TS_2 are identical to 521 distributed RAN case (see Figure 4) and the new TS_3 connects the 522 Radio Units (RU) to the BBUs. 524 <------------------ End to End Network Slices ---------------> 525 <-------- RS --------> <-- CS --> 526 <--- TS_3 ---> <--- TS_1 ---> <---- TS_2 ----> 528 ........................... 529 : RAN : 530 : ........ : ............. ............. 531 : |----| : : |-----| : : : |------| : : |-----| 532 : | RU | : FN : | BBU | : : Transport : | Core | : Other : | App | 533 : |----| : : |-----| : : Network : |------| : Network : |-----| 534 : :......: : :...........: :...........: 535 : : 536 :.........................: 538 Legend 539 TS: Transport Slice 540 RS: RAN Slice 541 CS: Core Slice 542 FN: Fronthaul network 543 MN: Midhaul network 545 Figure 5: Transport slices in centralized RAN 547 4.3. Transport Slices in cloud RAN 549 In new cloud-RAN architecture, the baseband unit functionality is 550 further divided into real-time and non-real-time. The former is 551 deployed close to antenna to manages the real-time air interface 552 resources while the non-real-time control functions are hosted 553 centrally in the cloud. In 5G, BBU is split into two parts called CU 554 (Central Unit) and DU (Distributed Unit) as shown in Figure 6 where 555 these entities are connected by new network called Midhaul. 557 In this deployment for a single E2E network slice, there are four 558 sets of transport slices TS_1, TS_2, TS_3 and TS_4 where TS_1 and 559 TS_2 and TS_3 are identical to distributed and centralized RAN (see 560 Figure 4 and Figure 5). The new transport slice TS_4 will connect 561 DUs to CUs. 563 <-------------------- End to End Network Slices ------------------> 564 <-------------- RS ---------------> <- CS -> 565 <--- TS_3 ---> <-- TS_4 --> <-- TS_1 --> <--- TS_2 ---> 566 ...................................... 567 : RAN : 568 : ...... ...... : ........ ...... 569 :|----| : : |----| : : |----| : : : |------| : : |-----| 570 :| RU | : FN : | DU | : MN : | CU | : : TN : | Core | : ON : | App | 571 :|----| : : |----| : : |----| : : : |------| : : |-----| 572 : :....: :....: : :......: :....: 573 : : 574 :....................................: 576 Legend 577 TS: Transport Slice 578 RS: RAN Slice 579 CS: Core Slice 580 FN: Fronthaul network 581 MN: Midhaul network 582 TN: Transport network 583 ON: Other network 585 Figure 6: Transport slices in cloud RAN 587 4.4. Transport Slice as a set of networks 589 To further explore the content of a transport slice, lets focus on 590 transport slice TS_1 between RAN and Core. Note that the following 591 discussion is also applicable to any other transport slices TS_2, 592 TS_3 or TS_4. As shown in Figure 7 for an individual E2E network 593 slice belongs to a specific customer for a specific service type, the 594 RAN domain is connected to Core domain through the transport network. 595 In this example, the E2E network slice is identified by n-nssai=10 596 for customer C1 and service type Infotainment. Two RAN network 597 elements BBU1 and BBU2 and two Core network elements AMF1 and UPF1 598 are all part of the E2E network slice. There are two sets of 599 distinct connections between RAN and Core domains; 601 o Network-C which connects BBU1 and BBU2 to AMF1 with SLA-C 603 o Network-U which connects BBU1 and BBU2 to UPF1 with SLA-U 604 Customer: C1 605 Service type: Infotainment 606 S-NSSAI: 10 607 Network-C {from BBU-1.tp1, BBU-2.tp1 to AMF1.tp1 with SLA-C} 608 Network-U {from BBU-1.tp2, BBU-2.tp2 to UPF1.tp2 with SLA-U} 610 Transport slice TS_1: { Network-C and Network-U } 612 .................... .................... .................. 613 : : : : : : 614 : --------- tp1 : : : : tp1 --------- : 615 : | | <------------------------------------> | | : 616 : | BBU1 | <+++ : : /-----------> | AMF1 | : 617 : | | tp2 + : : / : : | | : 618 : --------- +: : / : : --------- : 619 : :+ : / : : : 620 : : + : / : : : 621 : --------- tp1 : + / : : : 622 : | | <---------+--------/ : : tp2 --------- : 623 : | BBU2 | : ++++++++++++++++++++++++++> | | : 624 : | | <++++++++++++++++++++++++++++++++++++> | UPF1 | : 625 : --------- tp2 : : : : | | : 626 : : : : : --------- : 627 :..................: ...................: :................: 628 RAN Transport Core 629 Network Network Network 631 Legend 632 tp termination point 633 ----- Network-C 634 +++++ Network-U 636 Figure 7: Transport Slice as a set of networks 638 Note that the SLA-C and SLA-U can be different. The combination of 639 these two networks is called a single transport slice TS_1. Note 640 that the definition of the transport slice does not specifies how 641 these connections should be realized (or implemented). It also does 642 not specify which technology (e.g. IP, MPLS, Optics etc.) or tunnel 643 type (e.g. MPLS, Segment Routing etc.) should be used during the 644 realization. Those are part of realization of the transport slice 645 done by transport slice controller. With this approach the 646 definition is logically separated from implementation of transport 647 slices. This gives a tremendous programmability and flexibility 648 during the realization of transport slices using any type of 649 technologies and tunnel types. 651 In summary, a transport slice is a distinct set of technology- 652 agnostics connections each with its own deterministic SLA which can 653 be implemented (aka realized) using any technology, tunnel type and 654 service type. 656 5. Transport Slice Connectivity Interface (TSCi) 658 As shown in Figure 2, the interfaces 3 and 7 between the E2E network 659 slice Controller and RAN and Core controllers, respectively and their 660 information models are defined in various 3GPP technical 661 specifications [TS.28.530-3GPP], [TS.28.531-3GPP], [TS.28.540-3GPP] 662 and [TS.28.541-3GPP]. However, 3GPP has not defined the same 663 interface for transport slices, i.e. interface 10. The aim of this 664 document is to provide the clarification of this interface and to 665 provide the information model of this interface. The interface is 666 called the Transport Slice Connectivity interface (TSCi) which 667 provides some means for automation, monitoring and optimization of 668 the transport slices. 670 This new interface is needed in order to simplify the creation of the 671 Transport slices and hides all the complexity of implementation (aka 672 realization) from higher E2E network slice controller similar to 673 their RAN and Core counterparts defined by 3GPP. 675 The aim of this document is to define a new interface and its 676 information model between the E2E network slice controller and the 677 transport slice controller. The characteristics on this new 678 interface are: 680 a. The interface allows a request and response about resources. It 681 should not allow negotiation, as this would be complex and not 682 have a clear benefit 684 b. This interface is needed by the same layer that configures 3GPP 685 RAN and Core slices to support the E2E path management in 5G 686 networks. The provider of this interface is the higher layer 687 controller which needs to create a connectivity between two 688 network functions. The provider of this interface is the lower 689 layer controller which provide the implementation (aka 690 realization) of this connectivity (i.e. transport slice). 692 c. This interface is needed in industry to achieve true standard 693 based automation of 5G E2E network slices. It provides a 694 technology-agnostic intent-based interface to the E2E network 695 slice controller similar to interfaces defined by 3GPP for RAN 696 and Core slices 698 d. This interface is independent of type of network functions which 699 needs to be connected, i.e. it is independent of any specific 700 repository, software usage, protocol, or platform which realizes 701 the physical or virtual network functions. 703 e. The interface standardizes a way to learn about what resources 704 are available in the network which impact the creation of the 705 transport slices 707 f. This technology independent interface simplifies the creation of 708 the transports slices by describing it in a standard way along 709 with all the network functions (such as eNB, gNB, CU, DU, Core, 710 Mobile application server, etc.) that compose a transport slice, 711 their properties, attributes and their SLA requirements, i.e. the 712 connectivity resources requested from an E2E network slice 713 controller to transport slice controller with their corresponding 714 SLA requirements 716 g. This interface provides capabilities for transport slice 717 monitoring and analytics. It means that the TSCi interface 718 allows enabling/disabling the collection of the transport slices 719 telemetry, assurance and Threshold Crossing Alert (TCA) data and 720 providing them to the E2E network slice controller 722 h. This interface provides capabilities for optimization of the 723 transport slices. Since the nature of an E2E network slice is 724 dynamic, it is important to make sure the transport slice SLA are 725 valid and in case any SLA violation happens, the transport slice 726 controller performs the closed-loop action and informe the upper 727 layer E2E network slice controller for the violation and closed- 728 loop action. This interface allows this fucntionality. 730 i. This interface allows binding and association between RAN to 731 Transport slices and between Core to Transport slices 733 j. This interface complements various IETF service, tunnel, path 734 models by providing an abstract layer on top of these models 736 5.1. Relationship between TSCi and various IETF data models 738 The transport slice connectivity interface and its relationship to 739 various IETF data models are not addressed in any IETF WGs as it has 740 very unique characteristics of the 5G E2E network slicing. The new 741 interface complements various IETF service, tunnel, path data models 742 by providing an abstract layer on top of these models. 744 ^ 745 | (1) Transport Slice Connectivity 746 | Interface (TSCi) 747 v 748 ------------------------ 749 | Transport slice | (2) Find the resource (e.g. 750 | Controller | boarder routers, ip addresses, 751 ------------------------ VLAN etc) 752 ^ ^ ^ 753 | | | 754 |-------| | |-------| (3) Trigger various IETF service, 755 | | | path and tunnel APIs 756 v v v 757 (---------------------------) 758 ( ) 759 ( Transport Network ) 760 ( ) 761 (---------------------------) 763 Figure 8: Relationship between transport slice interface and IETF 764 Service/Tunnels/Path data models 766 Figure 8 shows more details on how the new transport slice 767 connectivity interface (TSCi) relates to various IETF 768 service/tunnels/path models. The transport slice controller receives 769 a request for creation of a transport slice. This request is an 770 abstract intent-based request which contains the required connections 771 between various network functions in RAN and Core. The transport 772 slice controller will then realize or implement those connections 773 using various IETF models. 775 In a sense, the new transport slice connectivity interface provides 776 an abstract layer on top of IETF models. The IETF service, path and 777 tunnel data models can be any existing IETF service models such as 778 L3SM or L2SM ([RFC8049] and [RFC8466]). It also can be any future 779 data models. 781 5.2. Realization (aka Implementation) of transport slices 783 Since the transport slice connectivity interface describes the 784 connections not the services, it is essential to make a distinction 785 between connections and implemented services. Referring to Figure 9, 786 assume using the new transport slice interface, the E2E network slice 787 controller requests the creation of a transport slice which has 788 multiple connections between RAN and Core. One of these connections 789 is shown below between RAN1 and UPF1. The E2E network slice 790 controller can request a connection between RAN1 to UPF1 for a 791 specific tenant, specific service type and specific SLA (e.g. 792 customer Public Safety for service CCTV with latency of 5 [ms] or 793 better). 795 (-----------------------) 796 ( Transport Network ) 797 ( ) 798 -------- UNI1 -------- -------- UNI2 -------- 799 | RAN1 |-------| BR1 | | BR2 |--------| UPF1 | 800 -------- -------- -------- -------- 801 ( ) 802 ( ) 803 (-----------------------) 805 <=========================> 806 IP/MPLS service, path and 807 tunnel between BR1 & BR2 809 <-------------------------------------------------> 810 Connectivity between RAN1 and UPF1 811 (which is part of a Transport Slice) 813 Legend: 814 <---> Connection part of the transport slice 815 <===> Implementation (aka realization) of the transport slice 817 Figure 9: Distinction between Connections and Services 819 To realize (aka implement) this connection, the transport slice 820 controller, will find the endpoint for the L0/L1/L2/L3 services, find 821 the best path and create a service between these endpoints. In this 822 example, in order to implement the connection between RAN1 and UPF1, 823 the transport slice controller will first find the best boarder 824 routers BR1 and BR2, find the best path between them and finally 825 creates a Service/path from BR1 to BR2. It is important to note 826 that: 828 o The endpoints of the Connection are different from the endpoints 829 of the Services, paths and tunnels. This is the unique 830 characteristic of transport slices where the endpoints of the 831 connections are different from endpoints of the Services (i.e. 832 endpoint of the transport slices are RAN1 and UPF1 whereas the 833 endpoint of services are BR1 and BR2 835 o The Service/path API can be any existing IETF service models such 836 as L3SM or L2SM ([RFC8049] and [RFC8466]). It also can be any 837 future service model 839 o In order to have the connectivity between RAN1 and UPF1, the RAN 840 and Core slices should be associated to Transport slice. This is 841 also a by-product of the Transport slice connectivity interface 842 when all allocated resources for access points (such as allocated 843 VLAN IDs, IP addresses etc) are conveyed to RAN and Core Slices. 844 This will be done by cordiantion between transport slice 845 controller and E2E network slice controller. 847 6. Transport slice connectivity interface (TSCi) information model 849 Based on the definition of a transport slice (see Section 4), the 850 high-level information model of a transport slice connectivity 851 interface should conform with Figure 10: 853 module: transport-slice-connectivity 854 +--rw transport-slice 855 +--rw transport-slice-info 856 +--rw ts-id 857 +--rw ts-name 858 +--... 859 +--rw network-slice-info [ns-id] 860 +--rw list of s-nnsai (i.e. E2E network slice id) 861 +--rw customer (aka tenant) 862 +--rw service type (e.g. CCTV, infotainment etc) 863 +--rw NS IDs (i.e. list of S-NSSAI) 864 +--... 865 +--rw transport-slice-networks* [network-id] 866 +--rw network-id 867 +--... 868 +--rw node* [node-id] 869 +--rw node-id 870 +--... 871 +--rw connection-link* [link-id] 872 +--rw link-id 873 +--rw endpoint-A 874 +--rw endpoint-B 875 +--... 876 +--rw transport-slice-policy* [policy-id] 877 +--rw policy-id 878 +--rw policy-type (e.g. sla-policy, selection-policy, 879 assurance-policy) 880 +--... 882 Figure 10: High-level information model of transport slice 883 connectivity interface 885 The proposed transport slice information model should include the 886 following building blocks: 888 o transport-slice-info: Information related to transport slice 890 o network-slice-info: A list of all E2E network slices mapped to 891 transport slice 893 o transport-slice-networks: Each transport slice is a set of 894 networks. Each network contains: 896 * list of nodes (i.e. list of RAN and Core network functions) 898 * list of connection-links (i.e. list of connections between 899 nodes) 901 * list of transport-slice-policies (i.e. various SLA, Selection 902 and Monitoring policies) 904 6.1. transport-slice-info 906 It contains information such as transport slice name, transport slice 907 ID etc. The details will be provided in next version of this draft. 909 6.2. network-slice-info 911 As discussed in Section 3, a request for creation of a transport 912 slice starts with the fact that a customer (aka tenant) will request 913 an E2E network slice from an operator for a certain service type 914 (e.g. CCTV, Infotainment, URLLC, etc.). So, there is a mapping 915 between transport slice and the E2E network slice. Depending on the 916 deployment, it is possible to map multiple E2E network slice to a 917 transport slice, i.e. the mapping between transport slice to E2E 918 network slice is one to many. 920 The network-slice-info contains the list of E2E network slices which 921 are mapped to the transport slice with all relevant information such 922 as S-NSSAI, name of customer, service type etc. The details will be 923 provided in next version of this draft. 925 6.3. transport-slice-networks 927 As per Section 4, a transport slice will contain one or more 928 transport-slice-networks. 930 6.4. node 932 As discussed in Section 4, the transport slice comprises one or more 933 connectivity networks between RAN and Core network elements. It is 934 also possible to have the connectivity networks between RAN and RAN 935 network elements for some RAN deployments (example for midhaul 936 network). As discussed in section 2.2, when the transport slice is 937 realized (implemented), the network elements which are the endpoints 938 of realization of the transport slice might be different. As a 939 result, the nodes in this model represent RAN or Core network 940 elements. However, the model is flexible where nodes might represent 941 the routers or switches which are the endpoints of the transport 942 slice realization. 944 The attributes of the node are IP address, node name, domain ID and 945 termination points. The details will be provided in next version of 946 this draft. 948 6.5. connection-link 950 Each transport-slice-networks contain one or more connections between 951 various nodes described in Section 6.4. The connection-link is a 952 list of links which are represented by endpoint-A, endpoint-B etc. 953 The details will be provided in next version of this draft. 955 6.6. transport-slice-policy 957 To establish a transport slice, one or more transport-slice-networks 958 will be created each with certain SLA requirement which is 959 represented by transport-slice-policy. This draft proposes three 960 types of transport slice policies to be supported: 962 o transport-slice-sla-policy 964 o transport-slice-selection-policy 966 o transport-slice-assurance-policy 968 The summary of these policies will be provided here. The details 969 will be provided in next version of this draft. 971 6.6.1. transport-slice-sla-policy 973 This is a mandatory policy. The transport-slice-policy represents in 974 a generic and technology-agnostics way the SLA requirement needed to 975 realize a group of connections which are part of a transport slice. 976 It is defined per transport-slice-network. It contains the bounded 977 latency, bandwidth, reliability, security etc. 979 6.6.2. transport-slice-selection-policy 981 This is an optional policy. In some deployment, the E2E network 982 slice controller might want to assist the transport slice controller 983 on how to realize a transport slice by providing some information 984 regarding the type of technologies and tunnels. This information 985 will be provided in transport-slice-selection-policy. 987 6.6.3. transport-slice-assurance-policy 989 This is a mandatory policy. The E2E network slice controller shall 990 influence the transport slice controller for transport slice 991 assurance on how to perform monitoring, analytics and optimization. 992 To this end, the transport-slice-assurance-policy will be used. It 993 contains, the type of assurance needed, time interval, how often 994 inform the E2E network slice controller etc. 996 6.7. IETF models 998 Currently none of the IETF data models address the modeling of 999 transport slice connectivity as shown in Figure 6. However, the 1000 various IETF data models might be augmented to address the 1001 information model of the transport slice connectivity interface. 1002 Following is the list of candidates IETF YANG models. This is not an 1003 extensive list and the next version of the draft will provide a more 1004 comprehensive list. 1006 6.7.1. ACTN model 1008 As defined in [RFC8453], [I-D.king-teas-applicability-actn-slicing] 1009 and [I-D.ietf-teas-actn-vn-yang] a VN (Virtual Network) is the 1010 abstract customer view of the TE network. The VN can be seen as a 1011 set of edge-to-edge abstract links (a Type 1 VN). Each abstract link 1012 is referred to as a VN member and is formed as an E2E tunnel across 1013 the underlying networks. 1015 This definition is very similar to definition of the transport slice 1016 which means that the VN YANG model can be augmented to address the 1017 modeling of the transport slice shown in Figure 6. This is work in 1018 progress for next version of this document. 1020 6.7.2. i2rs model 1022 Similar to [I-D.qiang-coms-netslicing-information-model], the data 1023 model for network topologies developed in 1024 [[I-D.ietf-i2rs-yang-network-topo] can be augmented to address the 1025 modeling of the transport slice. This is work in progress for next 1026 version of this document 1028 7. IANA Considerations 1030 This memo includes no request to IANA. 1032 8. Security Considerations 1034 TBD 1036 9. Informative References 1038 [I-D.boucadair-connectivity-provisioning-protocol] 1039 Boucadair, M., Jacquenet, C., Zhang, D., and P. 1040 Georgatsos, "Connectivity Provisioning Negotiation 1041 Protocol (CPNP)", draft-boucadair-connectivity- 1042 provisioning-protocol-15 (work in progress), December 1043 2017. 1045 [I-D.homma-slice-provision-models] 1046 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 1047 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 1048 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 1049 Foy, "Network Slice Provision Models", draft-homma-slice- 1050 provision-models-00 (work in progress), February 2019. 1052 [I-D.ietf-i2rs-yang-network-topo] 1053 Clemm, A., Medved, J., Varga, R., Bahadur, N., 1054 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 1055 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 1056 progress), December 2017. 1058 [I-D.ietf-teas-actn-vn-yang] 1059 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., Yoon, B., 1060 Wu, Q., and P. Park, "A Yang Data Model for VN Operation", 1061 draft-ietf-teas-actn-vn-yang-04 (work in progress), 1062 February 2019. 1064 [I-D.king-teas-applicability-actn-slicing] 1065 King, D. and Y. Lee, "Applicability of Abstraction and 1066 Control of Traffic Engineered Networks (ACTN) to Network 1067 Slicing", draft-king-teas-applicability-actn-slicing-04 1068 (work in progress), October 2018. 1070 [I-D.qiang-coms-netslicing-information-model] 1071 Qiang, L., Galis, A., Geng, L., 1072 kiran.makhijani@huawei.com, k., Martinez-Julia, P., 1073 Flinck, H., and X. Foy, "Technology Independent 1074 Information Model for Network Slicing", draft-qiang-coms- 1075 netslicing-information-model-02 (work in progress), 1076 January 2018. 1078 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1079 Connectivity Provisioning Profile (CPP)", RFC 7297, 1080 DOI 10.17487/RFC7297, July 2014, 1081 . 1083 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 1084 Model for L3VPN Service Delivery", RFC 8049, 1085 DOI 10.17487/RFC8049, February 2017, 1086 . 1088 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1089 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1090 DOI 10.17487/RFC8453, August 2018, 1091 . 1093 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1094 Data Model for Layer 2 Virtual Private Network (L2VPN) 1095 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1096 2018, . 1098 [TS.28.530-3GPP] 1099 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 1100 V15.1.0 Technical Specification Group Services and System 1101 Aspects; Management and orchestration; Concepts, use cases 1102 and requirements (Release 15)", December 2018, 1103 . 1106 [TS.28.531-3GPP] 1107 3rd Generation Partnership Project (3GPP), "3GPP TS 28.531 1108 V16.2.0 Technical Specification Group Services and System 1109 Aspects; Management and orchestration; Provisioning; 1110 (Release 16)", June 2019, . 1113 [TS.28.540-3GPP] 1114 3rd Generation Partnership Project (3GPP), "3GPP TS 28.540 1115 V16.0.0 Technical Specification Group Services and System 1116 Aspects; Management and orchestration; 5G Network Resource 1117 Model (NRM); Stage 1 (Release 16)", June 2019, 1118 . 1121 [TS.28.541-3GPP] 1122 3rd Generation Partnership Project (3GPP), "3GPP TS 28.541 1123 V16.1.0 Technical Specification Group Services and System 1124 Aspects; Management and orchestration; 5G Network Resource 1125 Model (NRM); Stage 2 and stage 3 (Release 16)", June 2019, 1126 . 1129 Authors' Addresses 1131 Reza Rokui 1132 Nokia 1133 Canada 1135 Email: reza.rokui@nokia.com 1136 Shunsuke Homma 1137 NTT 1138 3-9-11, Midori-cho 1139 Musashino-shi, Tokyo 180-8585 1140 Japan 1142 Email: homma.shunsuke@lab.ntt.co.jp 1144 Diego R. Lopez 1145 Telefonica I+D 1146 Spain 1148 Email: diego.r.lopez@telefonica.com 1150 Xavier de Foy 1151 InterDigital Inc. 1152 Canada 1154 Email: Xavier.Defoy@InterDigital.com 1156 Luis M. Contreras-Murillo 1157 Telefonica I+D 1158 Spain 1160 Email: luismiguel.contrerasmurillo@telefonica.com 1162 Jose J. Ordonez-Lucena 1163 Telefonica I+D 1164 Spain 1166 Email: joseantonio.ordonezlucena@telefonica.com 1168 Pedro Martinez-Julia 1169 NICT 1170 Japan 1172 Email: pedro@nict.go.jp 1173 Mohamed Boucadair 1174 Orange 1175 France 1177 Email: mohamed.boucadair@orange.com 1179 Philip Eardley 1180 BT 1181 UK 1183 Email: philip.eardley@bt.com 1185 Kiran Makhijani 1186 Futurewei Networks 1187 US 1189 Email: kiranm@futurewei.com 1191 Hannu Flinck 1192 Nokia 1193 Finland 1195 Email: hannu.flinck@nokia-bell-labs.com