idnits 2.17.1 draft-contreras-teas-slice-nbi-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (November 4, 2019) is 1635 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-homma-slice-provision-models-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational S. Homma 5 Expires: May 7, 2020 NTT 6 J. Ordonez-Lucena 7 Telefonica 8 November 4, 2019 10 Considerations for defining a Transport Slice NBI 11 draft-contreras-teas-slice-nbi-00 13 Abstract 15 The transport network is an essential component in the end-to-end 16 delivery of services and, consequently, with the advent of network 17 slicing it is necessary to understand what could be the way in which 18 the transport network is consumed as a slice. This document analyses 19 the needs of potential transport slice consumers in order to identify 20 the functionality required on the North Bound Interface (NBI) of a 21 transport slice producer for satisfying such transport slcie 22 requests. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on May 7, 2020. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. Northbound interface for transport slices . . . . . . . . . . 3 61 4. Transport slice use cases . . . . . . . . . . . . . . . . . . 4 62 4.1. 5G Services . . . . . . . . . . . . . . . . . . . . . . . 4 63 4.1.1. Generic Slice Template . . . . . . . . . . . . . . . 5 64 4.1.2. Categorization of GST attributes . . . . . . . . . . 6 65 4.1.2.1. Attributes with direct impact on the transport 66 slice definition . . . . . . . . . . . . . . . . 7 67 4.1.2.2. Attributes with indirect impact on the transport 68 slice definition . . . . . . . . . . . . . . . . 7 69 4.1.2.3. Attributes with no impact on the transport slice 70 definition . . . . . . . . . . . . . . . . . . . 8 71 4.2. NFV-based services . . . . . . . . . . . . . . . . . . . 8 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 7.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 A number of new technologies, such as 5G, NFV and SDN are not only 82 evolving the network from a pure technological perspective but also 83 are changing the concept in which new services are offered to the 84 customers [I-D.homma-slice-provision-models] by introducing the 85 concept of network slicing. 87 The transport network is an essential component in the end-to-end 88 delivery of services and, consequently, it is necessary to understand 89 what could be the way in which the transport network is consumed as a 90 slice. 92 In this document it is assumed that there exists a (logically) 93 centralized component in the transport network, namely Transport 94 Slice Producer (TSP) with the responsibilities on the control and 95 management of the transport slices invoked for a given service, as 96 requested by Transport Slice Consumers (TSC). 98 This document analyses the needs of potential transport slice 99 consumers in order to identify the functionality required on the 100 North Bound Interface (NBI) of the TSP to be exposed towards such 101 transport slice consumers. Solutions to construct the requested 102 transport slices are out of scope of this document. 104 This document addresses some of the discussions of the TEAS Slice 105 Design Team. However it is not at this stage an official outcome of 106 the Design Team. 108 2. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC2119 [RFC2119]. 114 3. Northbound interface for transport slices 116 In a general manner, the transport network supports different kinds 117 of services. These services consume the transport network provided 118 capabilities for deploying end-to-end services, interconnecting 119 network functions or applications spread across the network and 120 providing connectivity toward the final users of these services. 122 Under the slicing approach, a transport slice consumer requests to a 123 transport slice producer a slice with certain characteristics and 124 parametrization. Such request it is assumed here to be done through 125 an NBI exposed by the TSP to the consumer, as reflected in Fig. 1. 127 +--------------------+ 128 | | 129 | Transport | 130 | Slice Consumer | 131 | | 132 +--------------------+ 133 A 134 | 135 | Transport 136 | Slice 137 | NBI 138 | 139 V 140 +--------------------+ 141 | | 142 | Transport | 143 | Slice Producer | 144 | (Transport Slicer) | 145 | | 146 +--------------------+ 148 Figure 1: Transport slice NBI concept 150 The functionality supported by the NBI depends on the requirements 151 that the slice consumer has to satisfy. It is then important to 152 understand the needs of the slice consumers as well as the way of 153 expressing them. 155 4. Transport slice use cases 157 Different use cases for slice consumers can be identified, as 158 described in the following sections. 160 4.1. 5G Services 162 5G services natively rely on the concept of network slicing. 5G is 163 expected to allow vertical customers to request slices in such a 164 manner that the allocated resources and capabilities in the network 165 appear as dedicated for them. 167 In network slicing scenarios, a vertical customer requests a network 168 operator to allocate a network slice instance (NSI) satisfying a 169 particular set of service requirements. The content/format of these 170 requirements are highly dependent on the networking expertise and use 171 cases of the customer under consideration. To deal with this 172 heterogeneity, it is fundamental for the network operator to define a 173 a unified ability to interpret service requirements from different 174 vertical customers, and to represent them in a common language, with 175 the purposes of facilitating their translation/mapping into specific 176 slicing-aware network configuration actions. In this regard, model- 177 based network slice descriptors built on the principles of 178 reproducibility, reusability and customizability can be defined for 179 this end. 181 As a starting point for such a definition, GSMA developed the idea of 182 having a universal blueprint that can be used by any vertical 183 customer to order the deployment of an NSI based on a specific set of 184 service requirements. The result of this work has been the 185 definition of a baseline network slice descriptor called Generic 186 Slice Template (GST). The GST contains multiple attributes that can 187 be used to characterize a network slice. A Network Slice Type (NEST) 188 describes the characteristics of a network slice by means of filling 189 GST attributes with values based on specific service requirements. 190 Basically, a NEST is a filled-in version of a GST. Different NESTs 191 allow describing different types of network slices. For slices based 192 on standardized service types, e.g. eMBB, uRLLC and mIoT, the network 193 operator may have a set of readymade, standardized NESTs (S-NESTs). 194 For slices based on specific industry use cases, the network operator 195 can define additional NESTs. 197 Service requirements from a given vertical customer are mapped to a 198 NEST, which provides a self-contained description of the network 199 slice to be provisioned for that vertical customer. According to 200 this reasoning, the NEST can be used by the network operator as input 201 to the NSI preparation phase, which is defined in [TS28.530]. 3GPP is 202 working on the translation of the GST/NEST attributes into NSI 203 related requirements, which are defined in the "ServiceProfile" data 204 type from the Network Slice Information Object Class (IOC) in 205 [TS28.541]. These requirements are used by the 3GPP Management 206 System to allocate the NSI across all network domains, including 207 transport network. The transport slice defines the part of that NSI 208 that is deployed across the transport network. 210 Despite the translation is an on-going work in 3GPP it seems 211 convenient to start looking at the GST attributes to understand what 212 kind of parameters could be required for the transport slice NBI. 214 4.1.1. Generic Slice Template 216 The structure of the GST is defined in [GSMA]. The template defines 217 a total of 35 attributes. For each of them, the following 218 information is provided: 220 o Attribute definition, which provides a formal definition of what 221 the attribute represents. 223 o Attribute parameters, including: 225 * Value, e.g. integer, float. 227 * Measurement unit, e.g. milliseconds, Gbps 229 * Example, which provides examples of values the parameter can 230 take in different use cases. 232 * Tag, which allow describing the type of parameter, according to 233 its semantics. An attribute can be tagged as a 234 characterization attribute or a scalability attribute. If it 235 is characterization attribute, it can be further tagged as a 236 performance-related attribute, a functionality-related 237 attribute or an operation-related attribute. 239 * Exposure, which allow describing how this attribute interact 240 with the slice consumer, either as an API or a KPI. 242 o Attribute presence, either mandatory, conditional or optional. 244 Attributes from GST can be used by the network operator (slice 245 producer) and a vertical customer (slice consumer) to agree SLA. 247 GST attributes are generic in the sense that they can be used to 248 characterize different types of network slices. Once those 249 attributes become filled with specific values, it becomes a NEST 250 which can be ordered by slice consumers. 252 4.1.2. Categorization of GST attributes 254 Not all the GST attributes as defined in [GSMA] have impact in the 255 transport network since some of them are specific to either the radio 256 or the mobile core part. 258 In the analysis performed in this document, the attributes have been 259 categorized as: 261 o Attributes that directly impact the definition of the transport 262 slice, i.e., attributes that can be directly translated into 263 requirements required to be satisfied by a transport slice. 265 o Attributes that indirectly impact the definition of the transport 266 slice, i.e., attributes that indirectly impose some requirements 267 to a transport slice. 269 o Attributes that do not have impact on the transport slice. 271 The following sections describe the attributes falling into the three 272 categories. 274 4.1.2.1. Attributes with direct impact on the transport slice 275 definition 277 The following attributes impose requirements in the transport slice 279 o Availability 281 o Deterministic communication 283 o Downlink throughput per network slice 285 o Energy efficiency 287 o Group communication support 289 o Isolation level 291 o Maximum supported packet size 293 o Mission critical support 295 o Performance monitoring 297 o Reliability 299 o Slice quality of service parameters 301 o Support for non-IP traffic 303 o Uplink throughput per network slice 305 o User data access (i.e., tunneling mechanisms) 307 4.1.2.2. Attributes with indirect impact on the transport slice 308 definition 310 The following attributes indirectly impose requirements in the 311 transport slice to support the end-to-end service. 313 o Coverage 315 o Delay tolerance (i.e., if the service can be delivered when the 316 system has sufficient resources) 318 o Downlink throughput per UE 319 o Network Slice Customer network functions 321 o Number of connections 323 o Performance prediction (i.e., capability to predict the network 324 and service status) 326 o Root cause investigation 328 o Session and Service Continuity support 330 o Simultaneous use of the network slice 332 o Supported device velocity 334 o Terminal density 336 o Uplink throughput per UE 338 o User management openness (i.e., capability to manage users' 339 network services and corresponding requirements) 341 4.1.2.3. Attributes with no impact on the transport slice definition 343 The following attributes do not impact the transport slice. 345 o Location based message delivery (not related to the geographical 346 spread of the network slice itself but with the localized 347 distribution of information) 349 o MMTel support, i.e. support of and Multimedia Telephony Service 350 (MMTel)as well as IP Multimedia Subsystem (IMS) support. 352 o Number of terminals 354 o Positioning support 356 o Radio spectrum 358 o Synchronicity (among devices) 360 o V2X communication mode 362 4.2. NFV-based services 364 To do. 366 5. Security Considerations 368 This draft does not include any security considerations. 370 6. IANA Considerations 372 This draft does not include any IANA considerations 374 7. References 376 7.1. Normative References 378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 379 Requirement Levels", BCP 14, RFC 2119, 380 DOI 10.17487/RFC2119, March 1997, 381 . 383 7.2. Informative References 385 [GSMA] "Generic Network Slice Template, version 1.0", NG.116 , 386 May 2019. 388 [I-D.homma-slice-provision-models] 389 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 390 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 391 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 392 Foy, "Network Slice Provision Models", draft-homma-slice- 393 provision-models-01 (work in progress), July 2019. 395 [TS28.530] 396 "TS 28.530 Management and orchestration; Concepts, use 397 cases and requirements (Release 16) V16.0.0.", 3GPP TS 398 28.530 V16.0.0 , September 2019. 400 [TS28.541] 401 "TS 28.541 Management and orchestration; 5G Network 402 Resource Model (NRM); Stage 2 and stage 3 (Release 16) 403 V16.2.0.", 3GPP TS 28.541 V16.2.0 , September 2019. 405 Authors' Addresses 406 Luis M. Contreras 407 Telefonica 408 Ronda de la Comunicacion, s/n 409 Sur-3 building, 3rd floor 410 Madrid 28050 411 Spain 413 Email: luismiguel.contrerasmurillo@telefonica.com 414 URI: http://lmcontreras.com/ 416 Shunsuke Homma 417 NTT 418 Japan 420 Email: shunsuke.homma.fp@hco.ntt.co.jp 422 Jose A. Ordonez-Lucena 423 Telefonica 424 Ronda de la Comunicacion, s/n 425 Sur-3 building, 3rd floor 426 Madrid 28050 427 Spain 429 Email: joseantonio.ordonezlucena@telefonica.com