idnits 2.17.1 draft-contreras-teas-slice-nbi-02.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 (July 13, 2020) is 1376 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-03 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: January 14, 2021 NTT 6 J. Ordonez-Lucena 7 Telefonica 8 July 13, 2020 10 Considerations for defining a Transport Slice NBI 11 draft-contreras-teas-slice-nbi-02 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 customers (i.e., use cases) in 20 order to identify the functionality required on the North Bound 21 Interface (NBI) of a transport slice controller for satisfying such 22 transport slice 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 January 14, 2021. 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.2.1. Connectivity attributes . . . . . . . . . . . . . . . 10 74 4.2.2. Provisioning procedures . . . . . . . . . . . . . . . 10 75 4.3. Network sharing . . . . . . . . . . . . . . . . . . . . . 11 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 7.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 A number of new technologies, such as 5G, NFV and SDN are not only 86 evolving the network from a pure technological perspective but also 87 are changing the concept in which new services are offered to the 88 customers [I-D.homma-slice-provision-models] by introducing the 89 concept of network slicing. 91 The transport network is an essential component in the end-to-end 92 delivery of services and, consequently, it is necessary to understand 93 what could be the way in which the transport network is consumed as a 94 slice. For a definition of transport slice refer to 95 [I-D.nsdt-teas-transport-slice-definition]. 97 In this document it is assumed that there exists a (logically) 98 centralized component in the transport network, namely Transport 99 Slice Controller (TSC) with the responsibilities on the control and 100 management of the transport slices invoked for a given service, as 101 requested by Transport Slice customers. 103 This document analyses different use cases deriving the needs of 104 potential transport slice customers in order to identify the 105 functionality required on the North Bound Interface (NBI) of the TSC 106 to be exposed towards such transport slice customers. Solutions to 107 construct the requested transport slices are out of scope of this 108 document. 110 This document addresses some of the discussions of the TEAS Slice 111 Design Team. However, it is not at this stage an official outcome of 112 the Design Team. 114 2. Conventions used in this document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC2119 [RFC2119]. 120 3. Northbound interface for transport slices 122 In a general manner, the transport network supports different kinds 123 of services. These services consume capabilities provided by the 124 transport network for deploying end-to-end services, interconnecting 125 network functions or applications spread across the network and 126 providing connectivity toward the final users of these services. 128 Under the slicing approach, a transport slice customer requests to a 129 transport slice controller a slice with certain characteristics and 130 parametrization. Such request it is assumed here to be done through 131 a NBI exposed by the TSC to the customer, as reflected in Fig. 1. 133 +--------------------+ 134 | | 135 | Transport | 136 | Slice Customer | 137 | | 138 +--------------------+ 139 A 140 | 141 | Transport 142 | Slice 143 | NBI 144 | 145 V 146 +--------------------+ 147 | | 148 | Transport | 149 | Slice Controller | 150 | | 151 +--------------------+ 153 Figure 1: Transport slice NBI concept 155 The functionality supported by the NBI depends on the requirements 156 that the slice customer has to satisfy. It is then important to 157 understand the needs of the slice customers as well as the way of 158 expressing them. 160 4. Transport slice use cases 162 Different use cases for slice customers can be identified, as 163 described in the following sections. 165 4.1. 5G Services 167 5G services natively rely on the concept of network slicing. 5G is 168 expected to allow vertical customers to request slices in such a 169 manner that the allocated resources and capabilities in the network 170 appear as dedicated for them. 172 In network slicing scenarios, a vertical customer requests a network 173 operator to allocate a network slice instance (NSI) satisfying a 174 particular set of service requirements. The content/format of these 175 requirements are highly dependent on the networking expertise and use 176 cases of the customer under consideration. To deal with this 177 heterogeneity, it is fundamental for the network operator to define a 178 a unified ability to interpret service requirements from different 179 vertical customers, and to represent them in a common language, with 180 the purposes of facilitating their translation/mapping into specific 181 slicing-aware network configuration actions. In this regard, model- 182 based network slice descriptors built on the principles of 183 reproducibility, reusability and customizability can be defined for 184 this end. 186 As a starting point for such a definition, GSMA developed the idea of 187 having a universal blueprint that, being offered by network 188 operators, can be used by any vertical customer to order the 189 deployment of an NSI based on a specific set of service requirements. 190 The result of this work has been the definition of a baseline network 191 slice descriptor called Generic network Slice Template (GST). The 192 GST contains multiple attributes that can be used to characterize a 193 network slice. A Network Slice Type (NEST) describes the 194 characteristics of a network slice by means of filling GST attributes 195 with values based on specific service requirements. Basically, a 196 NEST is a filled-in version of a GST. Different NESTs allow 197 describing different types of network slices. For slices based on 198 standardized service types, e.g. eMBB, uRLLC and mIoT, the network 199 operator may have a set of readymade, standardized NESTs (S-NESTs). 200 For slices based on specific industry use cases, the network operator 201 can define additional NESTs. 203 Service requirements from a given vertical customer are mapped to a 204 NEST, which provides a self-contained description of the network 205 slice to be provisioned for that vertical customer. According to 206 this reasoning, the NEST can be used by the network operator as input 207 to the NSI preparation phase, which is defined in [TS28.530]. 3GPP is 208 working on the translation of the GST/NEST attributes into NSI 209 related requirements, which are defined in the "ServiceProfile" data 210 type from the Network Slice Information Object Class (IOC) in 211 [TS28.541]. These requirements are used by the 3GPP Management 212 System to allocate the NSI across all network domains, including 213 transport network. The transport slice defines the part of that NSI 214 that is deployed across the transport network. 216 Despite the translation is an on-going work in 3GPP it seems 217 convenient to start looking at the GST attributes to understand what 218 kind of parameters could be required for the transport slice NBI. 220 4.1.1. Generic network Slice Template 222 The structure of the GST is defined in [GSMA]. The template defines 223 a total of 35 attributes. For each of them, the following 224 information is provided: 226 o Attribute definition, which provides a formal definition of what 227 the attribute represents. 229 o Attribute parameters, including: 231 * Value, e.g. integer, float. 233 * Measurement unit, e.g. milliseconds, Gbps 235 * Example, which provides examples of values the parameter can 236 take in different use cases. 238 * Tag, which allow describing the type of parameter, according to 239 its semantics. An attribute can be tagged as a 240 characterization attribute or a scalability attribute. If it 241 is characterization attribute, it can be further tagged as a 242 performance-related attribute, a functionality-related 243 attribute or an operation-related attribute. 245 * Exposure, which allow describing how this attribute interact 246 with the slice customer, either as an API or a KPI. 248 o Attribute presence, either mandatory, conditional or optional. 250 Attributes from GST can be used by the network operator (slice 251 controller) and a vertical customer (slice customer) to agree SLA. 253 GST attributes are generic in the sense that they can be used to 254 characterize different types of network slices. Once those 255 attributes become filled with specific values, it becomes a NEST 256 which can be ordered by slice customers. 258 4.1.2. Categorization of GST attributes 260 Not all the GST attributes as defined in [GSMA] have impact in the 261 transport network since some of them are specific to either the radio 262 or the mobile core part. 264 In the analysis performed in this document, the attributes have been 265 categorized as: 267 o Directly impactive attributes, which are those that have direct 268 impact on the definition of the transport slice, i.e., attributes 269 that can be directly translated into requirements required to be 270 satisfied by a transport slice. 272 o Indirectly impactive attributes, which are thise that impact in an 273 indirect manner on the definition of the transport slice, i.e., 274 attributes that indirectly impose some requirements to a transport 275 slice. 277 o Non-impactive attributes, that are those which do not have impact 278 on the transport slice at all. 280 The following sections describe the attributes falling into the three 281 categories. 283 4.1.2.1. Attributes with direct impact on the transport slice 284 definition 286 The following attributes impose requirements in the transport slice 288 o Availability 290 o Deterministic communication 292 o Downlink throughput per network slice 294 o Energy efficiency 296 o Group communication support 298 o Isolation level 300 o Maximum supported packet size 302 o Mission critical support 304 o Performance monitoring 306 o Slice quality of service parameters 308 o Support for non-IP traffic 310 o Uplink throughput per network slice 312 o User data access (i.e., tunneling mechanisms) 314 4.1.2.2. Attributes with indirect impact on the transport slice 315 definition 317 The following attributes indirectly impose requirements in the 318 transport slice to support the end-to-end service. 320 o Area of service (i.e., the area where terminals can access a 321 particular network slice) 323 o Delay tolerance (i.e., if the service can be delivered when the 324 system has sufficient resources) 326 o Downlink (maximum) throughput per UE 328 o Network functions owned by Network Slice Customer 330 o Maximum number of (concurrent) PDU sessions 332 o Performance prediction (i.e., capability to predict the network 333 and service status) 335 o Root cause investigation 337 o Session and Service Continuity support 339 o Simultaneous use of the network slice 341 o Supported device velocity 343 o UE density 345 o Uplink (maximum) throughput per UE 347 o User management openness (i.e., capability to manage users' 348 network services and corresponding requirements) 350 o Latency from (last) UPF to Application Server 352 4.1.2.3. Attributes with no impact on the transport slice definition 354 The following attributes do not impact the transport slice. 356 o Location based message delivery (not related to the geographical 357 spread of the network slice itself but with the localized 358 distribution of information) 360 o MMTel support, i.e. support of and Multimedia Telephony Service 361 (MMTel)as well as IP Multimedia Subsystem (IMS) support. 363 o NB-IoT Support, i.e., support of NB-IoT in the RAN in the network 364 slice. 366 o Maximum number of (simultaneous) UEs 368 o Positioning support 370 o Radio spectrum 372 o Synchronicity (among devices) 373 o V2X communication mode 375 o Network Slice Specific Authentication and Authorization (NSSAA) 377 4.1.3. Provisioning procedures 379 3GPP identifies in [TS28.531] a number of procedures for the 380 provisioning of a network slice in general. It can be assumed that 381 similar procedures may also apply to a transport slice, facilitating 382 a consistent management and control of end-to-end slices. 384 The envisioned procedures are the following: 386 o Slice instance allocation: this procedure permits to create a new 387 slice instance (or reuse an existing one). 389 o Slice instance de-allocation: this procedure decommissions a 390 previously instantiated slice. 392 o Slice instance modification: this procedure permits the change in 393 the characteristics of an existing slice instance. 395 o Get slice instance status: this procedure helps to retrieve run- 396 time information on the status of a deployed slice instance. 398 o Retrieval of slice capabilities: this procedure assists on getting 399 information about the capabilities (e.g. maximum latency 400 supported). 402 All these procedures fit in the operation of transport network 403 slices. 405 4.2. NFV-based services 407 NFV technology allows the flexible and dynamic instantiation of 408 virtualized network functions (and their composition into network 409 services) on top of a distributed, cloud-enabled compute 410 infrastructure. This infrastructure can span across different points 411 of presence in a carrier network. By leveraging on transport network 412 slicing, connectivity services established across geographically 413 remote points of presence can be enriched by providing additional QoS 414 guarantees with respect present state-of-the-art mechanisms, as 415 conventional L2/L3 VPNs. 417 4.2.1. Connectivity attributes 419 The connectivity services are expressed through a number of 420 attributes as listed: 422 o Incoming and outgoing bandwidth: bandwidth required for the 423 connectivity services (in Mbps). 425 o Qos metrics: set of metrics (e.g., cost, latency and delay 426 variation) applicable to a specific connectivity service 428 o Directionality: indication if the traffic is unidirectional or 429 bidirectional. 431 o MTU: value of the largest PDU to be transmitted in the 432 connectivity service. 434 o Protection scheme: indication of the kind of protection to be 435 performed (e.g., 1;1, 1+1, etc.) 437 o Connectivity mode: indication of the service is point-to-point of 438 point-to-multipoint 440 All those attributes will assist on the characterization of the 441 connectivity slice to be deployed, and thus, are relevant for the 442 definition of a transport slice supporting such connectivity. 444 4.2.2. Provisioning procedures 446 ETSI NFV defines the role of WAN Infrastructure Manager (WIM) as the 447 component in charge of managing and controlling the connectivity 448 external to the PoPs. In [IFA032] a number of interfaces are 449 identified to be exposed by the WIM for supporting the multi-site 450 connectivity, thus representing the capabilities expected for a 451 transport network slice, as well, in case of satisfying such 452 connectivity needs by means of the slice concept. 454 The interfaces considered are the following: 456 o Multi-Site Connectivity Service (MSCS) Management: this interface 457 permits the creation, termination, update and query of MSCSs, 458 including reservation. It also enables subscription for 459 notifications and information retrieval associated to the 460 connectivity service. 462 o Capacity Management: this interface allows querying about the 463 capacity (e.g. bandwidth), topology, and network edge points of 464 the connectivity service, as well as about information of consumed 465 and available capacity on the underlying network resources. 467 o Fault Management: this interface serves for the provision of 468 alarms related to the MSCSs. 470 o Performance Management: this interface assists on the retrieval of 471 performance information (measurement results collection and 472 notifications) related to MSCSs. 474 4.3. Network sharing 476 To be done. 478 5. Security Considerations 480 This draft does not include any security considerations. 482 6. IANA Considerations 484 This draft does not include any IANA considerations 486 7. References 488 7.1. Normative References 490 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 491 Requirement Levels", BCP 14, RFC 2119, 492 DOI 10.17487/RFC2119, March 1997, 493 . 495 7.2. Informative References 497 [GSMA] "Generic Network Slice Template, version 3.0", NG.116 , 498 May 2020. 500 [I-D.homma-slice-provision-models] 501 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 502 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 503 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 504 Foy, "Network Slice Provision Models", draft-homma-slice- 505 provision-models-02 (work in progress), November 2019. 507 [I-D.nsdt-teas-transport-slice-definition] 508 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 509 Tantsura, "IETF Definition of Transport Slice", draft- 510 nsdt-teas-transport-slice-definition-03 (work in 511 progress), July 2020. 513 [IFA032] "IFA032 Interface and Information Model Specification for 514 Multi-Site Connectivity Services V3.2.1.", ETSI GS NFV-IFA 515 032 V3.2.1 , April 2019. 517 [TS28.530] 518 "TS 28.530 Management and orchestration; Concepts, use 519 cases and requirements (Release 16) V16.0.0.", 3GPP TS 520 28.530 V16.0.0 , September 2019. 522 [TS28.541] 523 "TS 28.541 Management and orchestration; 5G Network 524 Resource Model (NRM); Stage 2 and stage 3 (Release 16) 525 V16.2.0.", 3GPP TS 28.541 V16.2.0 , September 2019. 527 Authors' Addresses 529 Luis M. Contreras 530 Telefonica 531 Ronda de la Comunicacion, s/n 532 Sur-3 building, 3rd floor 533 Madrid 28050 534 Spain 536 Email: luismiguel.contrerasmurillo@telefonica.com 537 URI: http://lmcontreras.com/ 539 Shunsuke Homma 540 NTT 541 Japan 543 Email: shunsuke.homma.fp@hco.ntt.co.jp 545 Jose A. Ordonez-Lucena 546 Telefonica 547 Ronda de la Comunicacion, s/n 548 Sur-3 building, 3rd floor 549 Madrid 28050 550 Spain 552 Email: joseantonio.ordonezlucena@telefonica.com