idnits 2.17.00 (12 Aug 2021) /tmp/idnits14586/draft-contreras-teas-slice-nbi-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 9, 2020) is 803 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-nsdt-teas-transport-slice-definition-00 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: September 10, 2020 NTT 6 J. Ordonez-Lucena 7 Telefonica 8 March 9, 2020 10 Considerations for defining a Transport Slice NBI 11 draft-contreras-teas-slice-nbi-01 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 controller for satisfying such transport slice 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 September 10, 2020. 41 Copyright Notice 43 Copyright (c) 2020 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 network 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.1.3. Provisioning procedures . . . . . . . . . . . . . . . 9 72 4.2. NFV-based services . . . . . . . . . . . . . . . . . . . 9 73 4.3. Network sharing . . . . . . . . . . . . . . . . . . . . . 10 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 78 7.2. Informative References . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 A number of new technologies, such as 5G, NFV and SDN are not only 84 evolving the network from a pure technological perspective but also 85 are changing the concept in which new services are offered to the 86 customers [I-D.homma-slice-provision-models] by introducing the 87 concept of network slicing. 89 The transport network is an essential component in the end-to-end 90 delivery of services and, consequently, it is necessary to understand 91 what could be the way in which the transport network is consumed as a 92 slice. For a definition of transport slice refer to 93 [I-D.nsdt-teas-transport-slice-definition]. 95 In this document it is assumed that there exists a (logically) 96 centralized component in the transport network, namely Transport 97 Slice Controller (TSC) with the responsibilities on the control and 98 management of the transport slices invoked for a given service, as 99 requested by Transport Slice Consumers. 101 This document analyses the needs of potential transport slice 102 consumers in order to identify the functionality required on the 103 North Bound Interface (NBI) of the TSC to be exposed towards such 104 transport slice consumers. Solutions to construct the requested 105 transport slices are out of scope of this document. 107 This document addresses some of the discussions of the TEAS Slice 108 Design Team. However, it is not at this stage an official outcome of 109 the Design Team. 111 2. Conventions used in this document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC2119 [RFC2119]. 117 3. Northbound interface for transport slices 119 In a general manner, the transport network supports different kinds 120 of services. These services consume capabilities provided by the 121 transport network for deploying end-to-end services, interconnecting 122 network functions or applications spread across the network and 123 providing connectivity toward the final users of these services. 125 Under the slicing approach, a transport slice consumer requests to a 126 transport slice controller a slice with certain characteristics and 127 parametrization. Such request it is assumed here to be done through 128 a NBI exposed by the TSC to the consumer, as reflected in Fig. 1. 130 +--------------------+ 131 | | 132 | Transport | 133 | Slice Consumer | 134 | | 135 +--------------------+ 136 A 137 | 138 | Transport 139 | Slice 140 | NBI 141 | 142 V 143 +--------------------+ 144 | | 145 | Transport | 146 | Slice Controller | 147 | | 148 +--------------------+ 150 Figure 1: Transport slice NBI concept 152 The functionality supported by the NBI depends on the requirements 153 that the slice consumer has to satisfy. It is then important to 154 understand the needs of the slice consumers as well as the way of 155 expressing them. 157 4. Transport slice use cases 159 Different use cases for slice consumers can be identified, as 160 described in the following sections. 162 4.1. 5G Services 164 5G services natively rely on the concept of network slicing. 5G is 165 expected to allow vertical customers to request slices in such a 166 manner that the allocated resources and capabilities in the network 167 appear as dedicated for them. 169 In network slicing scenarios, a vertical customer requests a network 170 operator to allocate a network slice instance (NSI) satisfying a 171 particular set of service requirements. The content/format of these 172 requirements are highly dependent on the networking expertise and use 173 cases of the customer under consideration. To deal with this 174 heterogeneity, it is fundamental for the network operator to define a 175 a unified ability to interpret service requirements from different 176 vertical customers, and to represent them in a common language, with 177 the purposes of facilitating their translation/mapping into specific 178 slicing-aware network configuration actions. In this regard, model- 179 based network slice descriptors built on the principles of 180 reproducibility, reusability and customizability can be defined for 181 this end. 183 As a starting point for such a definition, GSMA developed the idea of 184 having a universal blueprint that, being offered by network 185 operators, can be used by any vertical customer to order the 186 deployment of an NSI based on a specific set of service requirements. 187 The result of this work has been the definition of a baseline network 188 slice descriptor called Generic network Slice Template (GST). The 189 GST contains multiple attributes that can be used to characterize a 190 network slice. A Network Slice Type (NEST) describes the 191 characteristics of a network slice by means of filling GST attributes 192 with values based on specific service requirements. Basically, a 193 NEST is a filled-in version of a GST. Different NESTs allow 194 describing different types of network slices. For slices based on 195 standardized service types, e.g. eMBB, uRLLC and mIoT, the network 196 operator may have a set of readymade, standardized NESTs (S-NESTs). 197 For slices based on specific industry use cases, the network operator 198 can define additional NESTs. 200 Service requirements from a given vertical customer are mapped to a 201 NEST, which provides a self-contained description of the network 202 slice to be provisioned for that vertical customer. According to 203 this reasoning, the NEST can be used by the network operator as input 204 to the NSI preparation phase, which is defined in [TS28.530]. 3GPP is 205 working on the translation of the GST/NEST attributes into NSI 206 related requirements, which are defined in the "ServiceProfile" data 207 type from the Network Slice Information Object Class (IOC) in 208 [TS28.541]. These requirements are used by the 3GPP Management 209 System to allocate the NSI across all network domains, including 210 transport network. The transport slice defines the part of that NSI 211 that is deployed across the transport network. 213 Despite the translation is an on-going work in 3GPP it seems 214 convenient to start looking at the GST attributes to understand what 215 kind of parameters could be required for the transport slice NBI. 217 4.1.1. Generic network Slice Template 219 The structure of the GST is defined in [GSMA]. The template defines 220 a total of 35 attributes. For each of them, the following 221 information is provided: 223 o Attribute definition, which provides a formal definition of what 224 the attribute represents. 226 o Attribute parameters, including: 228 * Value, e.g. integer, float. 230 * Measurement unit, e.g. milliseconds, Gbps 232 * Example, which provides examples of values the parameter can 233 take in different use cases. 235 * Tag, which allow describing the type of parameter, according to 236 its semantics. An attribute can be tagged as a 237 characterization attribute or a scalability attribute. If it 238 is characterization attribute, it can be further tagged as a 239 performance-related attribute, a functionality-related 240 attribute or an operation-related attribute. 242 * Exposure, which allow describing how this attribute interact 243 with the slice consumer, either as an API or a KPI. 245 o Attribute presence, either mandatory, conditional or optional. 247 Attributes from GST can be used by the network operator (slice 248 controller) and a vertical customer (slice consumer) to agree SLA. 250 GST attributes are generic in the sense that they can be used to 251 characterize different types of network slices. Once those 252 attributes become filled with specific values, it becomes a NEST 253 which can be ordered by slice consumers. 255 4.1.2. Categorization of GST attributes 257 Not all the GST attributes as defined in [GSMA] have impact in the 258 transport network since some of them are specific to either the radio 259 or the mobile core part. 261 In the analysis performed in this document, the attributes have been 262 categorized as: 264 o Directly impactive attributes, which are those that have direct 265 impact on the definition of the transport slice, i.e., attributes 266 that can be directly translated into requirements required to be 267 satisfied by a transport slice. 269 o Indirectly impactive attributes, which are thise that impact in an 270 indirect manner on the definition of the transport slice, i.e., 271 attributes that indirectly impose some requirements to a transport 272 slice. 274 o Non-impactive attributes, that are those which do not have impact 275 on the transport slice at all. 277 The following sections describe the attributes falling into the three 278 categories. 280 4.1.2.1. Attributes with direct impact on the transport slice 281 definition 283 The following attributes impose requirements in the transport slice 285 o Availability 287 o Deterministic communication 289 o Downlink throughput per network slice 291 o Energy efficiency 293 o Group communication support 295 o Isolation level 297 o Maximum supported packet size 299 o Mission critical support 301 o Performance monitoring 303 o Reliability 305 o Slice quality of service parameters 307 o Support for non-IP traffic 309 o Uplink throughput per network slice 311 o User data access (i.e., tunneling mechanisms) 313 4.1.2.2. Attributes with indirect impact on the transport slice 314 definition 316 The following attributes indirectly impose requirements in the 317 transport slice to support the end-to-end service. 319 o Coverage 320 o Delay tolerance (i.e., if the service can be delivered when the 321 system has sufficient resources) 323 o Downlink throughput per UE 325 o Network Slice Customer network functions 327 o Number of connections 329 o Performance prediction (i.e., capability to predict the network 330 and service status) 332 o Root cause investigation 334 o Session and Service Continuity support 336 o Simultaneous use of the network slice 338 o Supported device velocity 340 o Terminal density 342 o Uplink throughput per UE 344 o User management openness (i.e., capability to manage users' 345 network services and corresponding requirements) 347 4.1.2.3. Attributes with no impact on the transport slice definition 349 The following attributes do not impact the transport slice. 351 o Location based message delivery (not related to the geographical 352 spread of the network slice itself but with the localized 353 distribution of information) 355 o MMTel support, i.e. support of and Multimedia Telephony Service 356 (MMTel)as well as IP Multimedia Subsystem (IMS) support. 358 o Number of terminals 360 o Positioning support 362 o Radio spectrum 364 o Synchronicity (among devices) 366 o V2X communication mode 368 4.1.3. Provisioning procedures 370 3GPP identifies in [TS28.531] a number of procedures for the 371 provisioning of a network slice in general. It can be assumed that 372 similar procedures may also apply to a transport slice, facilitating 373 a consistent management and control of end-to-end slices. 375 The envisioned procedures are the following: 377 o Slice instance allocation: this procedure permits to create a new 378 slice instance (or reuse an existing one). 380 o Slice instance de-allocation: this procedure decommissions a 381 previously instantiated slice. 383 o Slice instance modification: this procedure permits the change in 384 the characteristics of an existing slice instance. 386 o Get slice instance status: this procedure helps to retrieve run- 387 time information on the status of a deployed slice instance. 389 o Retrieval of slice capabilities: this procedure assists on getting 390 information about the capabilities (e.g. maximum latency 391 supported). 393 All these procedures fit in the operation of transport network 394 slices. 396 4.2. NFV-based services 398 NFV technology allows the flexible and dynamic instantiation of 399 virtualized network functions (and their composition into network 400 services) on top of a distributed, cloud-enabled compute 401 infrastructure. This infrastructure can span across different points 402 of presence in a carrier network. By leveraging on transport network 403 slicing, connectivity services established across geographically 404 remote points of presence can be enriched by providing additional QoS 405 guarantees with respect present state-of-the-art mechanisms, as 406 conventional L2/L3 VPNs. 408 ETSI NFV defines the role of WAN Infrastructure Manager (WIM) as the 409 component in charge of managing and controlling the connectivity 410 external to the PoPs. In [IFA032] a number of interfaces are 411 identified to be exposed by the WIM for supporting the multi-site 412 connectivity, thus representing the capabilities expected for a 413 transport network slice, as well, in case of satisfying such 414 connectivity needs by means of the slice concept. 416 The interfaces considered are the following: 418 o Multi-Site Connectivity Service (MSCS) Management: this interface 419 permits the creation, termination, update and query of MSCSs, 420 including reservation. It also enables subscription for 421 notifications and information retrieval associated to the 422 connectivity service. 424 o Capacity Management: this interface allows querying about the 425 capacity (e.g. bandwidth), topology, and network edge points of 426 the connectivity service, as well as about information of consumed 427 and available capacity on the underlying network resources. 429 o Fault Management: this interface serves for the provision of 430 alarms related to the MSCSs. 432 o Performance Management: this interface assists on the retrieval of 433 performance information (measurement results collection and 434 notifications) related to MSCSs. 436 The connectivity services themselves are expressed through a number 437 of attributes, including bandwidth (for egress and ingress 438 directions), QoS metrics, directionality (i.e., unidirectional or 439 bidirectional service), MTU, connectivity type (e.g., multi-point) 440 and protection scheme (e.g., 1;1, 1+1, etc.), among others. All 441 those attributes will assist on the characterization of the 442 connectivity slice to be deployed, and thus, are relevant for the 443 definition of a transport slice supporting such connectivity. 445 Author's note: Detail on attributes will be provided in a forthcoming 446 version. 448 4.3. Network sharing 450 To be done. 452 5. Security Considerations 454 This draft does not include any security considerations. 456 6. IANA Considerations 458 This draft does not include any IANA considerations 460 7. References 462 7.1. Normative References 464 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 465 Requirement Levels", BCP 14, RFC 2119, 466 DOI 10.17487/RFC2119, March 1997, 467 . 469 7.2. Informative References 471 [GSMA] "Generic Network Slice Template, version 2.0", NG.116 , 472 October 2019. 474 [I-D.homma-slice-provision-models] 475 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 476 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 477 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 478 Foy, "Network Slice Provision Models", draft-homma-slice- 479 provision-models-02 (work in progress), November 2019. 481 [I-D.nsdt-teas-transport-slice-definition] 482 Rokui, R., Homma, S., and K. Makhijani, "IETF Definition 483 of Transport Slice", draft-nsdt-teas-transport-slice- 484 definition-00 (work in progress), November 2019. 486 [IFA032] "IFA032 Interface and Information Model Specification for 487 Multi-Site Connectivity Services V3.2.1.", ETSI GS NFV-IFA 488 032 V3.2.1 , April 2019. 490 [TS28.530] 491 "TS 28.530 Management and orchestration; Concepts, use 492 cases and requirements (Release 16) V16.0.0.", 3GPP TS 493 28.530 V16.0.0 , September 2019. 495 [TS28.541] 496 "TS 28.541 Management and orchestration; 5G Network 497 Resource Model (NRM); Stage 2 and stage 3 (Release 16) 498 V16.2.0.", 3GPP TS 28.541 V16.2.0 , September 2019. 500 Authors' Addresses 501 Luis M. Contreras 502 Telefonica 503 Ronda de la Comunicacion, s/n 504 Sur-3 building, 3rd floor 505 Madrid 28050 506 Spain 508 Email: luismiguel.contrerasmurillo@telefonica.com 509 URI: http://lmcontreras.com/ 511 Shunsuke Homma 512 NTT 513 Japan 515 Email: shunsuke.homma.fp@hco.ntt.co.jp 517 Jose A. Ordonez-Lucena 518 Telefonica 519 Ronda de la Comunicacion, s/n 520 Sur-3 building, 3rd floor 521 Madrid 28050 522 Spain 524 Email: joseantonio.ordonezlucena@telefonica.com