idnits 2.17.00 (12 Aug 2021) /tmp/idnits33598/draft-rokui-5g-ietf-network-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 -- The document date (November 2, 2020) is 558 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Mbps' is mentioned on line 344, but not defined == Missing Reference: 'Optional' is mentioned on line 391, but not defined == Unused Reference: 'I-D.boucadair-connectivity-provisioning-protocol' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-i2rs-yang-network-topo' is defined on line 986, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-teas-actn-vn-yang' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'I-D.king-teas-applicability-actn-slicing' is defined on line 998, but no explicit reference was found in the text == Unused Reference: 'I-D.qiang-coms-netslicing-information-model' is defined on line 1015, but no explicit reference was found in the text == Unused Reference: 'RFC7297' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC8049' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'RFC8453' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: 'RFC8466' is defined on line 1043, but no explicit reference was found in the text == Outdated reference: draft-boucadair-connectivity-provisioning-protocol has been published as RFC 8921 == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-03 == Outdated reference: A later version (-02) exists of draft-homma-slice-provision-models-00 == Outdated reference: draft-ietf-i2rs-yang-network-topo has been published as RFC 8345 == Outdated reference: A later version (-14) exists of draft-ietf-teas-actn-vn-yang-04 == Outdated reference: A later version (-10) exists of draft-king-teas-applicability-actn-slicing-04 == Outdated reference: A later version (-02) exists of draft-nsdt-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 -- Obsolete informational reference (is this intentional?): RFC 8049 (Obsoleted by RFC 8299) Summary: 0 errors (**), 0 flaws (~~), 20 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: May 6, 2021 NTT 6 X. de Foy 7 InterDigital Inc. 8 LM. Contreras 9 Telefonica 10 P. Eardley 11 BT 12 K. Makhijani 13 Futurewei Networks 14 H. Flinck 15 Nokia 16 R. Schatzmayr 17 Deutsche Telekom 18 A. Tizghadam 19 TELUS Communications Inc 20 C. Janz 21 H. Yu 22 Huawei Canada 23 November 2, 2020 25 IETF Network Slice for 5G and its characteristics 26 draft-rokui-5g-ietf-network-slice-00 28 Abstract 30 5G Network slicing is an approach to provide separate independent 31 end-to-end logical network from User Equipment (UE) to various mobile 32 applications where each network slice has its own Service Level 33 Agreement (SLA) and Objectives (SLO) requirements. Each end-to-end 34 network slice consists of a multitude of contexts across RAN, Core 35 and transport domains each with its own controller. To provide 36 automation, assurance and optimization of the 5G the network slices, 37 a 5G E2E network slice orchestrator is needed which interacts with 38 controllers in RAN, Core and Transport network domains. The 39 interfaces between the 5G E2E network slice orchestrator and RAN and 40 Core controllers are defined in various 3GPP technical 41 specifications. However, 3GPP has not defined a similar interface 42 for transport network. 44 The aim of this document is to describe E2E network slicing and its 45 relation to "IETF network slice" for 5G use-case. It also provides 46 an information model for control and mangement of IETF network slices 47 for 5G. 49 Status of This Memo 51 This Internet-Draft is submitted in full conformance with the 52 provisions of BCP 78 and BCP 79. 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF). Note that other groups may also distribute 56 working documents as Internet-Drafts. The list of current Internet- 57 Drafts is at https://datatracker.ietf.org/drafts/current/. 59 Internet-Drafts are draft documents valid for a maximum of six months 60 and may be updated, replaced, or obsoleted by other documents at any 61 time. It is inappropriate to use Internet-Drafts as reference 62 material or to cite them other than as "work in progress." 64 This Internet-Draft will expire on May 6, 2021. 66 Copyright Notice 68 Copyright (c) 2020 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (https://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with respect 76 to this document. Code Components extracted from this document must 77 include Simplified BSD License text as described in Section 4.e of 78 the Trust Legal Provisions and are provided without warranty as 79 described in the Simplified BSD License. 81 Table of Contents 83 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 1.1. Definition of Terms . . . . . . . . . . . . . . . . . . . 4 85 2. Architecture of a 5G end-to-end network slice . . . . . . . . 5 86 3. Typical flow for fulfillment of a 5G E2E network slice . . . 8 87 4. Definition of 5G IETF Network Slice . . . . . . . . . . . . . 11 88 4.1. 5G IETF Network Slices in Distributed RAN deployment . . 12 89 4.2. 5G IETF Network Slices in Centralized RAN deployment . . 13 90 4.3. 5G IETF Network Slices in Cloud RAN (C-RAN) . . . . . . . 13 91 4.4. 5G IETF Network Slice as a set of Connection Groups . . . 14 92 5. IETF Network Slice Controller NBI for 5G . . . . . . . . . . 16 93 5.1. Relationship between 5G IETF Network Slice NBI and 94 various IETF data models . . . . . . . . . . . . . . . . 17 95 6. 5G IETF Network Slice NBI Information Model . . . . . . . . . 18 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 98 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 99 10. Informative References . . . . . . . . . . . . . . . . . . . 23 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 102 1. Introduction 104 Network slicing offers network operators a mechanism to allocate 105 dedicated infrastructure, resources and services from a shared 106 operator's network to a customer for specific use-case. As discussed 107 in draft [I-D.nsdt-teas-ietf-network-slice-definition], there are a 108 number of use-cases benefiting from network slicing including: 110 o 5G network slicing (See [TS.23.501-3GPP]) 112 o Network wholesale services 114 o Network sharing among operators 116 o NFV connectivity and Data Center Interconnect 118 It is important to note that the concept of network slicing is not 119 only limited to 5G but other use-cases can also benefit from it as 120 shown above. However, the 5G use case is one of the important use 121 cases for network slicing. This memo will discuss the 5G use-case in 122 more details. In specific, 5G network slicing is a mechanism which a 123 mobile network operator can use to allocate dedicated 124 infrastructures, resources and services from a shared mobile and 125 transport network to a 5G customer for specific 5G use-case. 127 A 5G network slice is inherently an E2E concept and is composed of 128 multiple logical independent networks in a common operator's network 129 from a user equipment to various 5G applications. In particular, 5G 130 network slicing receives attention due to factors such as diversity 131 of services and devices in 5G each with its own SLA requirements. 132 Each 5G E2E network slice consists of multiple 5G RAN, 5G Core and 133 transport network domains each with its own controller (See 134 [TS.28.531-3GPP]. 136 To enable automation, assurance and optimization of 5G network 137 slices, an E2E network slice orchestrator is needed which interacts 138 with 5G RAN, 5G Core and Transport network controllers. The 139 interfaces between the E2E network slice orchestrator and RAN and 140 Core slice controllers are defined in various 3GPP technical 141 specifications. However, 3GPP has not defined the same interface 142 towards the transport network. Draft 143 [I-D.wd-teas-transport-slice-yang] addresses the object model of such 144 interface for all network slice use-cases. However, for 5G network 145 slicing, the current model shall be augmented to address the specific 146 characteristics of the 5G network slices. The aim of this document 147 is to provide characteristics of 5G network slices and how it relares 148 to "IETF network slice". It also provides the IETF network slice 149 interface specifications and its information model to be used for 150 automation, monitoring and optimization of IETF network slices for 151 5G. See [I-D.contreras-teas-slice-nbi]. 153 1.1. Definition of Terms 155 Please refer to [I-D.nsdt-teas-ietf-network-slice-definition] and 156 [I-D.homma-slice-provision-models] as well. 158 Tenant: Also known as Customer. A network slice tenant is a person 159 or group that rents and occupies an instance of the network slice 160 from network provider. 162 5G End-to-end Network Slice: A logical end-to-end network provided 163 by a 5G network slice provider that has the functionality and 164 performance to support a specific 5G service. It spans multiple 165 network domains (e.g. radio, transport and core) and in some cases 166 more than one administrative domain. It may well support dynamic 167 modification or it might be long-lasting i.e. only change on 168 commercial timescales. 170 5G IETF Network Slice: We will use the term "5G IETF network slice" 171 throughout this draft. It simply refers to IETF network slice 172 define in [I-D.nsdt-teas-ietf-network-slice-definition] applicable 173 to 5G. 175 RAN Slice: Also known in 3GPP as RAN Sub-Slice or RAN Slice-Subnet. 176 The context and personality created on RAN network functions to 177 address the 5G radio portion of a 5G E2E network slice. 179 Core Slice: Also known in 3GPP as Core Sub-Slice or Core Slice- 180 Subnet. The context and personality created on Core network 181 functions to address the 5G Core portion of a 5G E2E network 182 slice. 184 S-NSSAI: Single-Network Slice Selection Assistance Information, 185 defined by 3GPP which is the identification of a 5G E2E Network 186 Slice 188 gNB: The radio portion of a 5G E2E network slice and in a 189 distributed radio deployment (called Cloud-RAN), it incorporates 190 two major modules; Central Unit (CU) and Distribute Unit (DU) 192 DU: Distributed Unit: This logical unit includes a subset of gNB 193 real-time functions. Its operation is controlled by the CU. 195 CU: Central Unit: It is a logical unit that includes the gNB non- 196 realtime functions. 198 UE: User Equipment such as vehicle infotainment unit, cell phone, 199 IoT sensor and etc. 201 RAN: Radio Access Network is the part of a mobile system that 202 connects individual devices to other parts of a network through 203 radio connections. It provides connection between user equipment 204 (UE) and mobile core network. 206 Transport Domain: Transport domain is a network domain implemented 207 by the deployment of IETF network technologies. 209 2. Architecture of a 5G end-to-end network slice 211 To demonstrate the concept of 5G E2E network slice and the role of 212 various controllers, consider a typical 5G network shown in Figure 1 213 where a mobile network operator Y has two customers C1 and C2. The 214 boundaries of administrative domain of the operator includes RAN, 215 transport, Core and mobile application domains. Customer C1 and C2 216 request to have one or more logical independent E2E networks from UEs 217 (e.g. vehicle infotainment, mobile phone, IoT meters etc.) to the 5G 218 application servers, each with its own distinct SLO. 220 Each of these independent networks is called a 5G E2E network slice. 221 Each E2E network slice comprised of three componets RAN slice, IETF 222 network slice, and Core slice, respectively representing RAN, 223 transport and core domain portions of the slice. 225 <---------------- 5G End to End Network Slice -----------------> 227 <-- RAN --> <-- IETF Network --> <- Core -> <-- IETF Network --> 228 Slice Slice 1 Slice Slice 2 230 ......... ................... ............ ................. 231 : : : : : : : : 232 : : : : : : : : 233 NS1 ---------------------------------------------------------------- 234 NS2 ================================================================ 235 NS3 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 236 : : : : : : : : 237 NS4 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 238 : : : : : : : : 239 : : : : : : : : 240 :.......: :.................: :..........: :...............: 242 RAN Transport Core Transport App 243 Network Network 1 Network Network 2 Servers 245 Legend: 246 ----- NS1: 5G E2E NS 1 for customer C1, service type Infotainment 247 ===== NS2: 5G E2E NS 2 for customer C1, service type Autonomous Driving 248 +++++ NS3: 5G E2E NS 3 for customer C1, service type HD Map 249 - - - NS4: 5G E2E NS 4 for customer C2, service type CCTV 251 Figure 1: High level architecture of a 5G end-to-end network slice 253 In Figure 1 mobile network operator Y has created four 5G E2E network 254 slices, NS1, NS2, NS3 and NS4, each with its own RAN, Core and IETF 255 network slices. To create a RAN slice, the RAN network function s 256 such as eNB and gNB should be programmed to have a context for each 257 5G E2E network slice. This context means that the RAN network 258 functions should allocate certain resources for each 5G E2E network 259 slice they belong to such as air interface, various schedulers, 260 policies and profiles to guarantee the SLO requirement for that 261 specific network slice. By the same token, the Core slices will be 262 created which means that the mobile network operator will create the 263 context for each 5G E2E network slice on Core network functions. 265 For each 5G E2E network slice NS1, NS2, NS3 and NS4, after creation 266 of RAN and Core slices, they should be connected to each other and be 267 connected to mobile application servers to form the 5G E2E network 268 slice. As defined in [I-D.nsdt-teas-ietf-network-slice-definition], 269 the set of connections are referred to "IETF Network Slices" and 270 specifically for 5G they are referred to "5G IETF Network Slices". 272 Referring to Figure 1, for each 5G E2E network slice, the following 273 5G IETF network Slices are needed: 275 o 5G IETF Network Slice 1: To connect RAN slice to Core slice in 276 Transport Network 1 278 o 5G IETF Network Slice 2: To connect Core slice to Mobile 279 Application Servers in Transport Network 2. This might be needed 280 if the mobile application servers are connected to core network 281 functions through a transport network. For example, if the Core 282 slice, which is realized on VNFs, and mobile application servers 283 are in the same data center, the 5G IETF Network Slice 2 is not 284 needed. In this case the transport network 2 does not exist. 286 Note that as we will see later in Section 4.1, Section 4.2 and 287 Section 4.3, the number of "5G IETF network slices" might be more 288 than two which depends on some factors such as RAN deployment: 290 After creation of RAN, Core and 5G IETF network slices, they will be 291 associated together to form a working 5G E2E network slice identified 292 by an ID referred as to S-NSSAI. Please refer to [TS.23.501-3GPP] 293 for more info on S-NSSAI. 295 To support fully automated enablement and assurance of 5G E2E network 296 slices, multiple controllers are needed to perform the life cycle of 297 5G E2E network slices in RAN, Core and Transport domains. As shown 298 in Figure 2 each RAN, Core and Transport domain needs its own 299 controller called RAN Slice Controller, Core Slice Controller and 300 IETF Network Slice Controller. In addition, an E2E network slice 301 orchestrator is needed to provide coordination and control of network 302 slices from an E2E perspective. 304 In summary, a 5G E2E network slice will involve several domains, each 305 with its own controller; 5G RAN, 5G Core and transport domains need 306 to be coordinated in order to deliver an E2E mobile service. Note 307 that in this context a service is not an IP/MPLS service but rather 308 customer facing services such as CCTV service, eMBB service, 309 Infotainment service and so on. 311 |---------------------------------------------------------| 312 | E2E Network Slice Orchestrator | 313 |---------------------------------------------------------| 315 |----------------| |-------------------| |----------------| 316 | RAN Slice | | IETF Network | | Core Slice | 317 | Controller | | Slice Controller | | Controller | 318 |----------------| |-------------------| |----------------| 320 .......... ................... ........... ................ 321 : : : : : : : : 322 : : : : : : : : 323 : RAN : : Transport : : Core : : Transport : Mobile 324 : Network: : Network 1 : : Network : : Network 2 : App 325 : : : : : : : : Servers 326 : : : : : : : : 327 :........: :.................: :.........: :..............: 329 Figure 2: Various controllers for 5G end-to-end network slice 331 3. Typical flow for fulfillment of a 5G E2E network slice 333 Figure 3 provides a typical flow across various controllers, 334 orchestrator, NFVO and RAN/Transport/Core networks to achieve the 335 automatic creation of a 5G E2E network slices such as NS1, NS2, NS3 336 or NS4 shown in Figure 1. Below are typical steps from the time a 337 customer sends its request for a 5G E2E network slice creation to the 338 operators network until the network slice is created and ready to be 339 used by the customer. It is important to note that in practice some 340 of these steps can be combined or re-ordered. 342 1. The customer C1 requests, from operator Y, the creation of a 5G 343 E2E network slice NS1 for Infotainment service type and SLO of 344 10 [Mbps] 346 2. The 5G E2E network slice orchestrator receives this request and 347 using its pre-defined network slice blueprints (a.k.a. network 348 slice templates), creates a network slice profile (a.k.a. 349 network slice instance) containing all the network functions in 350 RAN and core which should be part of this E2E network slice. It 351 then goes through decomposition of this profile and triggers 352 various actions towards RAN, Core and transport domains. 354 3. A request for creation of 5G RAN slice will be sent to RAN Slice 355 Controller. 357 4. If new instances of virtual RAN network functions are needed, 358 the RAN Slice Controller triggers the creation of new VNFs in 359 RAN (using for example ETSI interface Os-Ma-nfvo) 361 5. NFVO manages the life cycle of virtual RAN network functions 363 6. Since both physical and virtual RAN network functions which are 364 part of 5G E2E network functions are known to the RAN slice 365 controller, it triggers the creation of a RAN slice by 366 programming 5G RAN network functions 368 7. Similary to previous step (3), a request for creation of a Core 369 slice will be sent to the Core Slice Controller. 371 8. If new instances of virtual Core network functions are needed, 372 the Core Slice controller triggers the creation of new 5G core 373 VNFs (using for example ETSI interface Os-Ma-nfvo) and NFVO 374 manages the life cycle of virtual Core network functions 376 9. Since both physical and virtual 5G Core network functions as 377 components of 5G E2E network functions are known to the Core 378 slice controller, it triggers the creation of Core slice by 379 programming 5G Core network functions 381 10. In this step, the creation of various 5G IETF network slices 382 will be triggered. Each 5G IETF network slice contains one or 383 more connections between RAN network functions, Core network 384 functions and 5G mobile applications. For example, connectivity 385 between 5G RAN and 5G Core slices, connectivity between 5G RAN 386 network functions (such as DU to CU) or connectivity between 5G 387 core slice and mobile applications. Note that this step can be 388 triggered by E2E network slice orchestrator, RAN slice 389 controller, Core slice controller, or a combination of them. 391 11. [Optional] If the realization of a 5G IETF network slice 392 involves creation of new VNFs (e.g. Firewall, security gateway 393 etc.), 5G IETF network slice controller triggers the creation of 394 those VNFs (using for example ETSI interface Os-Ma-nfvo) 396 12. Various 5G IETF network slices will be realized in transport 397 network. Note that interface (10) is technology-agnostic 398 whereas interface (12) is technology-specific 400 13. The E2E network slice orchestrator associates RAN slice, Core 401 slice and 5G IETF network slices together to form a single 5G 402 E2E network slice NS1 404 14. At the end, when the E2E network slice is created, the E2E 405 network slice orchestrator will allocate a unique network slice 406 id (called S-NSSAI) and eventually, during the UE network 407 attach, UEs will be informed about the existence of this newly 408 created E2E network slice. UEs can request it using the 3GPP 5G 409 signaling procedures. 411 Note that the interfaces 3 and 7 between 5G E2E network slice 412 orchestrator and RAN and Core slice controllers along with their 413 information models are defined in various 3GPP technical 414 specifications. However, 3GPP has not defined the same interface for 415 transport network (i.e. interface 10). 417 The aim of this document is to define specific attributes related to 418 5G network slices which will be used later to augment 419 [I-D.wd-teas-transport-slice-yang]. 421 |----------------------------------------------------| 422 | Customer portal | 423 |----------------------------------------------------| 424 |(1) 425 V 426 |----------------------------------------------------| 427 | Generate NS Profile (aka NSI) using NS Blueprints | 5G E2E 428 | |(2) | Network Slice 429 | V | Orchestrator 430 | Decompose NS Profile and trigger various actions | 431 |----------------------------------------------------| 432 |(3) |(10) |(7) 433 | |--------| | |------| | 434 V | V V V | V 435 --------------- | ----------------- | ---------------- 436 | RAN | | | IETF | | | Core | Domain 437 | Slice |-| | Network Slice | |-| Slice | Controllers 438 | Controller | | Controller | | Controller | 439 --------------- ----------------- ---------------- 440 (6)| |(4) (12)| |(11) (8)| |(9) 441 | | | |--------| | | 442 | |-------------- | --------| | |------| | 443 | | V V V | 444 | | |----------| | 445 | | | NFVO | | 446 | | |----------| | 447 | | | | 448 .............. ................. | ................. 449 : RAN : : IETF Network : | : Core : 450 : Slice : : Slice : | : Slice : 452 :............: :...............: | :...............: 453 .... | ................ | ........ | .......... | ..... 5G E2E 454 : | | | | : Network Slice 455 :... | ................ | ........ | .......... | ....: (13) 456 | | | | 457 (6)| (12)| (5)| |(9) 458 V V V V 459 |-----------------------------------------------------| 460 | ,--------. ,-------------. ,--------. | Network of 461 | / RAN \ / Transport \ / Core \ | Mobile 462 | \ Network / \ Network / \ Network / | Operator "Y" 463 | `--------' `-------------' `--------' | 464 |-----------------------------------------------------| 466 Legend: 467 NS: 5G E2E Network Slice 468 NSI: Network Slice Instance 469 NFVO: NFV Orchestrator 471 Figure 3: Typical flow for fulfillment of a 5G E2E network slice 473 4. Definition of 5G IETF Network Slice 475 Referring to [I-D.nsdt-teas-ietf-network-slice-definition], the IETF 476 network slice is define as follows: 478 An IETF network slice is a logical network topology connecting a 479 number of endpoints with a set of shared or dedicated network 480 resources. These resources are used to satisfy specific Service 481 Level Objectives (SLOs). 483 The 5G IETF Network slice specification is technology-agnostic. 484 Using the above-mentioned definition, the 5G IETF network slice is 485 define as follows: 487 5G IETF network slices are sets of connections among the following 488 network functions and mobile applications: 490 o 5G RAN slice and 5G Core slice 492 o 5G Core slice and mobile application server 494 o Among 5G RAN network functions DU to CU 496 o Among 5G RAN network functions RU to DU 497 In Section 4.1, Section 4.2 and Section 4.3, the details of various 498 5G IETF network slices for following RAN deployment will be provided: 500 o Distributed RAN 502 o Centralized RAN 504 o Cloud RAN (C-RAN) 506 4.1. 5G IETF Network Slices in Distributed RAN deployment 508 Distributed RAN is the most common deployment of 4G and 5G RAN 509 networks whereas shown in Figure 4, the RAN network is connected to 510 Core network using the transport network 1. Optionally the mobile 511 applications can be also connected to the Core network using another 512 transport network 2. 514 In this case, a single 5G E2E network slice contains not only 5G RAN 515 and 5G Core slices but two 5G IETF network slices INS_1 and INS_2. 516 INS_1 connects the RAN slice to Core slice and INS_2 connects Core 517 slice to mobile application servers (if needed). 519 <------------- 5G E2E Network Slice -------------> 520 <--- RS --> <-- CS --> 521 <--- INS_1 --> <--- INS_2 ---> 522 .................. 523 : RAN : 524 : : ............. ............. 525 : |----| |-----| : : : |------| : : |-----| 526 : | RU | | BBU | : : Transport : | Core | : Transport : | App | 527 : |----| |-----| : : Network 1 : |------| : Network 2 : |-----| 528 : : :...........: :...........: 529 :................: 531 Legend 532 INS: 5G IETF Network Slice 533 RS: RAN Slice 534 CS: Core Slice 535 RU: Radio Unit 536 BBU: BaseBand Unit 537 App: Mobile Application Servers 539 Figure 4: 5G IETF network slices in distributed RAN deployment 541 4.2. 5G IETF Network Slices in Centralized RAN deployment 543 The RAN consists of two functional units: the baseband unit (BBU) and 544 the radio unit (RU). The BBU processes the signal and is connected 545 to the transport network. The RU transmits and receives the carrier 546 signal that is transmitted over the air to the end user equipment 547 (UE). In Centralized RAN as depicted in Figure 5, the RU and BBU are 548 separated by a network called fronthaul network. 550 In this deployment a single 5G E2E network slice contains not only 5G 551 RAN and 5G Core slices but three 5G IETF network slices INS_1, INS_2 552 and INS_3 where INS_1 and INS_2 are identical to their counterparts 553 in distributed RAN deployment case (see Figure 4) and a new INS_3 554 connects the Radio Units (RU) to the BBUs. 556 <-------------------- 5G E2E Network Slice --------------------> 557 <-------- RS --------> <-- CS --> 558 <--- INS_3 ---> <--- INS_1 ---> <---- INS_2 ----> 560 ........................... 561 : RAN : 562 : ........ : ............. ............. 563 : |----| : : |-----| : : : |------| : : |-----| 564 : | RU | : FN : | BBU | : : Transport : | Core | : Transport : | App | 565 : |----| : : |-----| : : Network 1 : |------| : Network 2 : |-----| 566 : :......: : :...........: :...........: 567 : : 568 :.........................: 570 Legend 571 INS: 5G IETF Network Slice 572 RS: RAN Slice 573 CS: Core Slice 574 FN: Fronthaul network 575 RU: Radio Unit 576 BBU: BaseBand Unit 577 App: Mobile Application Servers 579 Figure 5: 5G IETF network slices in Centralized RAN deployment 581 4.3. 5G IETF Network Slices in Cloud RAN (C-RAN) 583 In Cloud-RAN deployment, the baseband unit (BBU) is further 584 disaggregated into real-time and non-real-time components. The 585 former is deployed close to antenna to manages the real-time air 586 interface resources while the non-real-time control functions are 587 hosted centrally in the cloud. In 5G, BBU is split into two parts 588 called CU (Central Unit) and DU (Distributed Unit) as shown in 589 Figure 6 where these entities are connected by a new network called 590 Midhaul network. 592 In this deployment a single 5G E2E network slice contains not only 5G 593 RAN and 5G Core slices but four 5G IETF network slices INS_1, INS_2, 594 INS_3 and INS_4 where INS_1, INS_2 and INS_3 are identical to their 595 counterparts in centralized RAN deployment case (see Figure 5) and a 596 new 5G IETF network slice INS_4 connects the DUs to CUs. 598 <--------------------- 5G E2E Network Slice ---------------------> 599 <-------------- RS ---------------> <- CS -> 600 <--- INS_3 ---> <-- INS_4 --> <-- INS_1 --> <--- INS_2 ---> 601 ...................................... 602 : RAN : 603 : ...... ...... : ........ ...... 604 :|----| : : |----| : : |----| : : : |------| : : |-----| 605 :| RU | : FN : | DU | : MN : | CU | : : TN1 : | Core | :TN2 : | App | 606 :|----| : : |----| : : |----| : : : |------| : : |-----| 607 : :....: :....: : :......: :....: 608 : : 609 :....................................: 611 Legend 612 INS: 5G IETF Network Slice 613 RS: RAN Slice 614 CS: Core Slice 615 FN: Fronthaul network 616 MN: Midhaul network 617 TN: Transport network 618 DU: Distributed Unit 619 CU: Central Unit 620 RU: Radio Unit 621 App: Mobile Application Servers 623 Figure 6: 5G IETF network slices in Cloud RAN deployment 625 4.4. 5G IETF Network Slice as a set of Connection Groups 627 As discussed in [I-D.nsdt-teas-ietf-network-slice-definition], an 628 IETF network slice contains one or more connections between various 629 network functions, application and devices. These connections can be 630 grouped into various Connection Groups where each group has its own 631 SLA/SLO. 633 To further explore this concept in 5G E2E network slicing, consider 634 Figure 7, where the details of 5G IETF network slice INS_1 introduced 635 in Figure 4 is illustrated. The 5G IETF network slice INS_1 is 636 between 5G RAN and Core slices and has multiple connections between 637 5G RAN network functions BBU1 and BBU2 and 5G Core network functions 638 AMF1 and UPF1. In particular, it contains the following connection 639 groups, each with its own SLO where SLO-C and SLO-U might be 640 different (e.g. they might be control and user plans SLOs): 642 o "Connection group C" connects BBU1 and BBU2 to AMF1 with SLO-C 644 o "Connection group U" connects BBU1 and BBU2 to UPF1 with SLO-U 646 The combination of two connection groups will form the 5G IETF 647 network slice INS_1. Note that the definition of 5G IETF network 648 slice INS_1 does not specify how these connections should be realized 649 in transport network 1. Although it is optionally possible, it is 650 not necessarily mandatory for the definition of a 5G IETF network 651 slice to state which technology (e.g. IP, MPLS, Optics, PON etc.) or 652 tunnel type (e.g. RSVP-TE, SR-TE etc.) should be employed for 653 realization. As discussed in 654 [[I-D.nsdt-teas-ietf-network-slice-definition], any of these 655 technologies may be used by the IETF Network Slice Controller (NSC) 656 to realize an IETF network slice. 658 In summary, a 5G IETF network slice is a distinct set of technology- 659 agnostic connection groups between various 5G network functions, 5G 660 devices or 5G applications each with its own deterministic SLO which 661 can be realized by any suitable technology, tunnel type and service 662 type. 664 <------- IETF Network Slice INS_1 -------> 666 ...................... ..................... ................... 667 : : : : : : 668 : --------- NSE1 : : : : NSE1 --------- : 669 : | | <---------------------------------------> | | : 670 : | BBU1 | <+++++ : : /------------> | AMF1 | : 671 : | | NSE2 + : : / : : | | : 672 : --------- +: : / : : --------- : 673 : :+ : / : : : 674 : : + : / : : : 675 : --------- NSE1 : + / : : : 676 : | | <-----------+--------/ : : NSE1 --------- : 677 : | BBU2 | : +++++++++++++++++++++++++++> | | : 678 : | | <+++++++++++++++++++++++++++++++++++++++> | UPF1 | : 679 : --------- NSE2 : : : : | | : 680 : : : : : --------- : 681 :....................: ....................: :.................: 682 RAN Transport Core 683 Network Network 1 Network 685 5G IETF Network Slice INS_1: 686 {"Connection group C" + "Connection group U"} 687 Connection Group C {from BBU1.NSE1, BBU2.NSE1 to AMF1.NSE1 with SLO-C} 688 Connection Group U {from BBU1.NSE2, BBU2.NSE2 to UPF1.NSE1 with SLO-U} 690 Legend 691 BBU: BaseBand Unit 692 AMF: Access and Mobility Management Function 693 UPF: User Plane Function 694 NSE: 5G IETF Network Slice Endpoint 695 ---- Connection group C 696 ++++ Connection group U 698 Figure 7: Details of 5G IETF Network Slice as a set of Connection 699 Groups 701 5. IETF Network Slice Controller NBI for 5G 703 As discussed in [I-D.nsdt-teas-ietf-network-slice-definition] and 704 [I-D.nsdt-teas-ns-framework], to fulfill (i.e. create, modify, 705 delete) any IETF network slice and perform monitoring on it, an 706 entity called IETF Network Slice Controller (NSC) is required to take 707 abstract requests for 5G IETF network slices and realize them using 708 suitable underlying technologies. An IETF Network Slice Controller 709 is the key building block for control and management of the transport 710 slice. It provides the creation/modification/deletion, monitoring 711 and optimization of transport Slices in a multi-domain, a multi- 712 technology and multi-vendor environment. 714 Figure 8 shows the NSC and its NBI interface for 5G. Draft 715 [I-D.wd-teas-transport-slice-yang] addresses the base data model of 716 the NSC NBI interface for all network slicing use-cases. However, 717 for 5G network slicing, the current model shall be augmented to 718 include the specific characteristics of the 5G network slices for 719 this interface. The details of NSC NBI interface for 5G provided in 720 Section 6. 722 +------------------------------------------+ 723 | 5G Customer (Tenant) | 724 +------------------------------------------+ 725 A 726 | 727 V 728 +------------------------------------------+ 729 | 5G E2E Network Slice Orchestrator | 730 +------------------------------------------+ 731 A 732 | NSC NBI 733 V 734 +------------------------------------------+ 735 | IETF Network Slice Controller (I-NSC) | 736 +------------------------------------------+ 737 A 738 | NSC SBI 739 V 740 +------------------------------------------+ 741 | Network Controller(s) | 742 +------------------------------------------+ 744 Figure 8: IETF Network Slice Controller NBI for 5G 746 5.1. Relationship between 5G IETF Network Slice NBI and various IETF 747 data models 749 As discussed in [I-D.nsdt-teas-ns-framework], the main task of the 750 IETF Network Slice Controller is to map abstract IETF network slice 751 requirements from NBI to concrete technologies on SBI and establish 752 the required connectivity, and ensure that required resources are 753 allocated to IETF network slice. There are a number of different 754 technologies that can be used on SBI including physical connections, 755 MPLS, TSN, Flex-E, PON etc. If the undelay technology is IP/MPLS/ 756 Optics, any IETF models can be used during the realization of IETF 757 network slice. 759 There are no specific mapping requirements for 5G. The only 760 difference is that in case of 5G, the NBI interface contains 761 additional 5G specific attributes such as customer name, mobile 762 service type, 5G E2E network slice ID (i.e. S-NSSAI) and so on (See 763 Section 6). These 5G specific attributes can be employed by IETF 764 Network Slice Controller during the realization of 5G IETF network 765 slices on how to map NBI to SBI. They can also be used for assurance 766 of 5G IETF network slices. Figure 9 shows the mapping between NBI to 767 SBI for 5G IETF network slices. 769 | (1) NBI: Request to create/modify/delete 770 | 5G IETF Network Slice 771 V 772 +----------------------+ 773 | IETF Network Slice | (2) Mapping between technology 774 | Controller (NSC) | agnostics NBI to technology 775 +----------------------+ specific SBI 776 ^ ^ ^ 777 | | | 778 |---| | |---| (3) SBI: Realize 5G IETF Network Slice 779 | | | by using various IETF models for 780 V V V services, tunnels and paths 781 +----------------------+ 782 | Network |-+ 783 | Controller(s) | |-+ 784 +----------------------+ | | 785 +----------------------+ | 786 +----------------------+ 788 Figure 9: Relationship between transport slice interface and IETF 789 Service/Tunnels/Path data models 791 6. 5G IETF Network Slice NBI Information Model 793 Based on the definition of 5G IETF Network slices (see Section 4), 794 the high-level information model of northbound interface of IETF 795 Network Slice Controller (NSC) for 5G IETF network slices should 796 conform with Figure 10: 798 module: 5g-ietf-network-slices 799 +--rw 5g-ietf-network-slice 800 +--rw 5g-ietf-network-slice-info 801 +--rw ins-id 802 +--rw ins-name 803 +--rw ins-plmn 804 +--rw ins-hierarchical-tenant-id 805 +--rw 5g-network-slice-info [s-nssai] 806 +--rw s-nssai (i.e. 5G E2E network slice id) 807 +--rw 5g-customer (i.e. 5G tenant) 808 +--rw 5g-mobile-service-type (e.g. CCTV, infotainment etc) 809 +--rw 5g-connection-group* [connection-group-id ] 810 +--rw connection-group-id 811 +--rw connection-group-name 812 +--rw connection-group-type (e.g., P2P, MP2MP, etc.) 813 +--rw connection-group-status 814 +-- admin-status 815 +-- operational-status 816 +--rw connection-group-member* [member-id] 817 +--rw member-id 818 +--rw member-name 819 +--rw member //Ref. to 5G-ietf-connection-group-member 820 +--ro member-slo-monitoring 821 +--ro latency? 822 +--ro jitter? 823 +--ro loss? 824 +--rw connection-group-slo-policy 825 +--rw policy-id 826 +--rw slo attributes 827 +--rw connection-group-realization-policy //Optional 828 +--rw policy-id 829 +--rw realization-attributes //Optional 830 //Technology-specific attributes 831 +--rw connection-group-monitoring-policy //Optional 832 +--rw policy-id 833 +--rw monitoring-attributes //Optional. Such as if monitoring 834 //is needed, frequency of 835 //monitoring and how often send 836 //them to NBI etc. 837 +--rw 5g-ietf-network-slice-endpoint* [ep-id] 838 +--rw ep-id 839 +--rw ep-name 840 +--rw domain-id 841 +--rw node-id 842 +--rw transport-port-id 843 +--rw transport-vlan-id 844 +--rw transport-id (e.g. IP address of the transport) 845 +--rw transport-label (For future use) 846 +--rw transport-bsid (For future use) 847 +--rw 5G-ietf-connection-group-member* [member-id] 848 +--rw member-id 849 +--rw member-endpoint-a //Ref. to 5g-ietf-network-slice-endpoint 850 +--rw member-endpoint-b //Ref. to 5g-ietf-network-slice-endpoint 852 Figure 10: Information model of NSC NBI interface for 5G IETF Network 853 Slices 855 The proposed information model should include the following building 856 blocks: 858 o 5g-ietf-network-slice-info: All attributes related to 5G IETF 859 Network Slice. It contains information such as 5G IETF network 860 slice name, 5G IETF network slice ID, PLMN and hierarchical tenant 861 ID etc. 863 o 5g-network-slice-info: A list of all E2E network slices mapped to 864 this 5G IETF network slice. As discussed in Section 3, a request 865 for creation of a 5G IETF network slice is sent from 5G E2E 866 network slice orchestrator to IETF Network Slice Controller (NSC) 867 for a customer and certain service type (e.g. CCTV, Infotainment, 868 URLLC, etc.). It is NSC's decision to either create a new 869 transport slice or use one of the existing ones. As a result, the 870 mapping between 5G E2E network slice and IETF network slice is 871 many to one, i.e. one 5G IETF network slice can be used with 872 multiple 5G E2E network slices. The attributes of each 5G E2E 873 network slices are included here. The 5g-network-slice-info 874 contains the list of E2E network slices which are mapped to a 5G 875 IETF network slice with all relevant attributes such as S-NSSAI, 876 customer name and service type. 878 o 5g-connection-group: A 5G IETF network slice contains one or more 879 connection groups each with its own SLA/SLO. Each connection 880 group contains: 882 * connection-group-attributes: A list of attributes for each 5g- 883 connection-group such as connection-group-id, connection-group- 884 name and connection-group-status 886 * connection-group-member: A list of members. Each member is a 887 connection between two endpoints. A connection group can 888 contain one or more members. For example, the connections 889 BBU1-UPF1 and BBU2-UPF1 are 2 members of "connection group U" 890 in Figure 7. 892 * connection-group-slo-policy: This is a mandatory policy. The 893 connection-group-slo-policy represents in a generic and 894 technology-agnostics fashion the SLO requirement needed to 895 realize members of a connection group. It contains SLOs such 896 as bounded latency, bandwidth, reliability, security etc. Note 897 that all members of a connection group must have the same SLO. 899 * connection-group-realization-policy: This is an optional 900 policy. In some scenarios, the 5G E2E network slice 901 orchestrator might be able to influence the IETF Network Slice 902 Controller on how to realize a 5G IETF network slice by 903 providing some technology-specific information. 905 * connection-group-monitoring-policy: This is an optional policy. 906 The 5G E2E network slice orchestrator can influence the IETF 907 Network Slice Controller on how to perform monitoring, 908 analytics and optimization on 5G IETF Network Slices. It 909 contains, the type of assurance needed, time interval, 910 frequency of how often to inform the 5G E2E Network Slice 911 Orchestrator etc. 913 o 5g-ietf-network-slice-endpoint: It contains the list of all 914 endpoints along with their attributes which belong to a 5G IETF 915 network slice. See Figure 11 917 o 5G-ietf-connection-group-member: It contains the list of all 918 members of connectin groups along with their attributes which 919 belong to a 5G IETF network slice. 921 transport-port-id 922 transport-vlan-id 923 transport-id (e.g. IP address of the transport) 924 transport-label (For future use) 925 transport-bsid (For future use) 926 | 927 DAN | 928 |----------------| | 929 | | | |--------------| 930 | o | V | Transport | 931 | NSE |------------| Network | 932 | | | | 933 | | |--------------| 934 |----------------| 935 ^ 936 | 937 | 938 ep-id (e.g. the IP address) 939 ep-name 940 domain-id 941 node-id 943 Legend: 944 DAN: Device, application and/or network function 945 NSE: IETF Network Slice Endpoint 947 Figure 11: Details of the 5G IETF network slice endpoints 949 7. IANA Considerations 951 This memo includes no request to IANA. 953 8. Security Considerations 955 TBD 957 9. Acknowledgments 959 The authors would like to thank the following people for their 960 contribution to this draft: 962 o Ryan Hoffman, Telus 964 10. Informative References 966 [I-D.boucadair-connectivity-provisioning-protocol] 967 Boucadair, M., Jacquenet, C., Zhang, D., and P. 968 Georgatsos, "Connectivity Provisioning Negotiation 969 Protocol (CPNP)", draft-boucadair-connectivity- 970 provisioning-protocol-15 (work in progress), December 971 2017. 973 [I-D.contreras-teas-slice-nbi] 974 Contreras, L., Homma, S., and J. Ordonez-Lucena, "IETF 975 Network Slice use cases and attributes for Northbound 976 Interface of controller", draft-contreras-teas-slice- 977 nbi-03 (work in progress), October 2020. 979 [I-D.homma-slice-provision-models] 980 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 981 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 982 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 983 Foy, "Network Slice Provision Models", draft-homma-slice- 984 provision-models-00 (work in progress), February 2019. 986 [I-D.ietf-i2rs-yang-network-topo] 987 Clemm, A., Medved, J., Varga, R., Bahadur, N., 988 Ananthakrishnan, H., and X. Liu, "A Data Model for Network 989 Topologies", draft-ietf-i2rs-yang-network-topo-20 (work in 990 progress), December 2017. 992 [I-D.ietf-teas-actn-vn-yang] 993 Lee, Y., Dhody, D., Ceccarelli, D., Bryskin, I., Yoon, B., 994 Wu, Q., and P. Park, "A Yang Data Model for VN Operation", 995 draft-ietf-teas-actn-vn-yang-04 (work in progress), 996 February 2019. 998 [I-D.king-teas-applicability-actn-slicing] 999 King, D. and Y. Lee, "Applicability of Abstraction and 1000 Control of Traffic Engineered Networks (ACTN) to Network 1001 Slicing", draft-king-teas-applicability-actn-slicing-04 1002 (work in progress), October 2018. 1004 [I-D.nsdt-teas-ietf-network-slice-definition] 1005 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 1006 Tantsura, "Definition of IETF Network Slices", draft-nsdt- 1007 teas-ietf-network-slice-definition-00 (work in progress), 1008 October 2020. 1010 [I-D.nsdt-teas-ns-framework] 1011 Gray, E. and J. Drake, "Framework for Transport Network 1012 Slices", draft-nsdt-teas-ns-framework-04 (work in 1013 progress), July 2020. 1015 [I-D.qiang-coms-netslicing-information-model] 1016 Qiang, L., Galis, A., Geng, L., 1017 kiran.makhijani@huawei.com, k., Martinez-Julia, P., 1018 Flinck, H., and X. Foy, "Technology Independent 1019 Information Model for Network Slicing", draft-qiang-coms- 1020 netslicing-information-model-02 (work in progress), 1021 January 2018. 1023 [I-D.wd-teas-transport-slice-yang] 1024 Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data 1025 Model for Transport Slice NBI", draft-wd-teas-transport- 1026 slice-yang-02 (work in progress), July 2020. 1028 [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP 1029 Connectivity Provisioning Profile (CPP)", RFC 7297, 1030 DOI 10.17487/RFC7297, July 2014, 1031 . 1033 [RFC8049] Litkowski, S., Tomotaki, L., and K. Ogaki, "YANG Data 1034 Model for L3VPN Service Delivery", RFC 8049, 1035 DOI 10.17487/RFC8049, February 2017, 1036 . 1038 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 1039 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 1040 DOI 10.17487/RFC8453, August 2018, 1041 . 1043 [RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG 1044 Data Model for Layer 2 Virtual Private Network (L2VPN) 1045 Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 1046 2018, . 1048 [TS.23.501-3GPP] 1049 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 1050 (V16.2.0): System Architecture for the 5G System (5GS); 1051 Stage 2 (Release 16)", September 2019, 1052 . 1055 [TS.28.530-3GPP] 1056 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 1057 V15.1.0 Technical Specification Group Services and System 1058 Aspects; Management and orchestration; Concepts, use cases 1059 and requirements (Release 15)", December 2018, 1060 . 1063 [TS.28.531-3GPP] 1064 3rd Generation Partnership Project (3GPP), "3GPP TS 28.531 1065 V16.2.0 Technical Specification Group Services and System 1066 Aspects; Management and orchestration; Provisioning; 1067 (Release 16)", June 2019, . 1070 [TS.28.540-3GPP] 1071 3rd Generation Partnership Project (3GPP), "3GPP TS 28.540 1072 V16.0.0 Technical Specification Group Services and System 1073 Aspects; Management and orchestration; 5G Network Resource 1074 Model (NRM); Stage 1 (Release 16)", June 2019, 1075 . 1078 [TS.28.541-3GPP] 1079 3rd Generation Partnership Project (3GPP), "3GPP TS 28.541 1080 V16.1.0 Technical Specification Group Services and System 1081 Aspects; Management and orchestration; 5G Network Resource 1082 Model (NRM); Stage 2 and stage 3 (Release 16)", June 2019, 1083 . 1086 Authors' Addresses 1088 Reza Rokui 1089 Nokia 1090 Canada 1092 Email: reza.rokui@nokia.com 1094 Shunsuke Homma 1095 NTT 1096 3-9-11, Midori-cho 1097 Musashino-shi, Tokyo 180-8585 1098 Japan 1100 Email: shunsuke.homma.ietf@gmail.com 1101 Xavier de Foy 1102 InterDigital Inc. 1103 Canada 1105 Email: Xavier.Defoy@InterDigital.com 1107 Luis M. Contreras 1108 Telefonica 1109 Spain 1111 Email: luismiguel.contrerasmurillo@telefonica.com 1113 Philip Eardley 1114 BT 1115 UK 1117 Email: philip.eardley@bt.com 1119 Kiran Makhijani 1120 Futurewei Networks 1121 US 1123 Email: kiranm@futurewei.com 1125 Hannu Flinck 1126 Nokia 1127 Finland 1129 Email: hannu.flinck@nokia-bell-labs.com 1131 Rainer Schatzmayr 1132 Deutsche Telekom 1133 Germany 1135 Email: rainer.schatzmayr@telekom.de 1137 Ali Tizghadam 1138 TELUS Communications Inc 1139 Canada 1141 Email: ali.tizghadam@telus.com 1142 Christopher Janz 1143 Huawei Canada 1144 Canada 1146 Email: christopher.janz@huawei.com 1148 Henry Yu 1149 Huawei Canada 1150 Canada 1152 Email: henry.yu1@huawei.com