idnits 2.17.1 draft-contreras-teas-slice-nbi-04.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 (February 22, 2021) is 1159 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-ietf-teas-ietf-network-slice-definition-00 == Outdated reference: A later version (-05) exists of draft-nsdt-teas-ns-framework-04 Summary: 0 errors (**), 0 flaws (~~), 4 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: August 26, 2021 NTT 6 J. Ordonez-Lucena 7 Telefonica 8 February 22, 2021 10 IETF Network Slice Use Cases and Attributes for Northbound Interface of 11 IETF Network Slice Controllers 12 draft-contreras-teas-slice-nbi-04 14 Abstract 16 This document analyses the needs of potential customers of network 17 slices realized with IETF techniques in several use cases, identifies 18 the functionalities for the North Bound Interface (NBI) of an IETF 19 Network Slice Controller to satisfy such requests. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 26, 2021. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Conventions used in this document and terminology . . . . . . 3 57 3. Northbound Interface for IETF Network Slices . . . . . . . . 3 58 4. IETF Network Slice Use Cases . . . . . . . . . . . . . . . . 4 59 4.1. 5G Services . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1.1. Generic network Slice Template . . . . . . . . . . . 5 61 4.1.2. Categorization of GST attributes . . . . . . . . . . 6 62 4.1.2.1. Attributes with direct impact on the IETF network 63 slice definition . . . . . . . . . . . . . . . . 7 64 4.1.2.2. Attributes with indirect impact on the IETF 65 network slice definition . . . . . . . . . . . . 7 66 4.1.2.3. Attributes with no impact on the IETF network 67 slice definition . . . . . . . . . . . . . . . . 8 68 4.1.3. Provisioning procedures . . . . . . . . . . . . . . . 9 69 4.2. NFV-based services . . . . . . . . . . . . . . . . . . . 9 70 4.2.1. Connectivity attributes . . . . . . . . . . . . . . . 10 71 4.2.2. Provisioning procedures . . . . . . . . . . . . . . . 10 72 4.3. Network sharing . . . . . . . . . . . . . . . . . . . . . 11 73 4.3.1. Connectivity attributes . . . . . . . . . . . . . . . 12 74 4.3.2. Provisioning procedures . . . . . . . . . . . . . . . 12 75 4.4. Additional use cases . . . . . . . . . . . . . . . . . . 12 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 80 7.2. Informative References . . . . . . . . . . . . . . . . . 13 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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 IETF network slice refer to 95 [I-D.ietf-teas-ietf-network-slice-definition]. 97 In this document it is assumed that there exists a (logically) 98 centralized component in the transport network, namely IETF Network 99 Slice Controller (NSC) with the responsibilities on the control and 100 management of the IETF network slices invoked for a given service, as 101 requested by IETF network slice customers. 103 This document analyses different use cases deriving the needs of 104 potential IETF network slice customers in order to identify the 105 functionality required on the North Bound Interface (NBI) of the NSC 106 to be exposed towards such IETF network slice customers. Solutions 107 to construct the requested IETF network slices are out of scope of 108 this 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 and terminology 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 The terminology in this draft will be aligned in forthcoming versions 121 with the final terminology selected for describing the notion of IETF 122 network slice when applied to IETF technologies, which is currently 123 under discussion. By now same terminology as used in 124 [I-D.ietf-teas-ietf-network-slice-definition] and 125 [I-D.nsdt-teas-ns-framework] is primarily used here. 127 The term "transport network" in the context of this draft refers in 128 broad sense to WAN, MBH, IP backbone and other network segments 129 implemented by IETF technologies. 131 3. Northbound Interface for IETF Network Slices 133 In a general manner, the transport network supports different kinds 134 of services. These services consume capabilities provided by the 135 transport network for deploying end-to-end services, interconnecting 136 network functions or applications spread across the network and 137 providing connectivity toward the final users of these services. 139 Under the slicing approach, a IETF network slice customer requests to 140 a IETF network slice controller a slice with certain characteristics 141 and parametrization. Such request it is assumed here to be done 142 through a NBI exposed by the NSC to the customer, as reflected in 143 Fig. 1. 145 +--------------------+ 146 | | 147 | IETF Network | 148 | Slice Customer | 149 | | 150 +--------------------+ 151 A 152 | 153 | IETF Network 154 | Slice Controller 155 | NBI 156 | 157 V 158 +--------------------+ 159 | | 160 | IETF Network | 161 | Slice Controller | 162 | | 163 +--------------------+ 165 Figure 1: IETF network slice NBI concept 167 The functionality supported by the NBI depends on the requirements 168 that the slice customer has to satisfy. It is then important to 169 understand the needs of the slice customers as well as the way of 170 expressing them. 172 4. IETF Network Slice Use Cases 174 Different use cases for slice customers can be identified, as 175 described in the following sections. 177 4.1. 5G Services 179 5G services natively rely on the concept of network slicing. 5G is 180 expected to allow vertical customers to request slices in such a 181 manner that the allocated resources and capabilities in the network 182 appear as dedicated for them. 184 In network slicing scenarios, a vertical customer requests a network 185 operator to allocate a network slice instance (NSI) satisfying a 186 particular set of service requirements. The content/format of these 187 requirements are highly dependent on the networking expertise and use 188 cases of the customer under consideration. To deal with this 189 heterogeneity, it is fundamental for the network operator to define a 190 a unified ability to interpret service requirements from different 191 vertical customers, and to represent them in a common language, with 192 the purposes of facilitating their translation/mapping into specific 193 slicing-aware network configuration actions. In this regard, model- 194 based network slice descriptors built on the principles of 195 reproducibility, reusability and customizability can be defined for 196 this end. 198 As a starting point for such a definition, GSMA developed the idea of 199 having a universal blueprint that, being offered by network 200 operators, can be used by any vertical customer to order the 201 deployment of an NSI based on a specific set of service requirements. 202 The result of this work has been the definition of a baseline network 203 slice descriptor called Generic network Slice Template (GST). The 204 GST contains multiple attributes that can be used to characterize a 205 network slice. A Network Slice Type (NEST) describes the 206 characteristics of a network slice by means of filling GST attributes 207 with values based on specific service requirements. Basically, a 208 NEST is a filled-in version of a GST. Different NESTs allow 209 describing different types of network slices. For slices based on 210 standardized service types, e.g. eMBB, uRLLC and mIoT, the network 211 operator may have a set of readymade, standardized NESTs (S-NESTs). 212 For slices based on specific industry use cases, the network operator 213 can define additional NESTs. 215 Service requirements from a given vertical customer are mapped to a 216 NEST, which provides a self-contained description of the network 217 slice to be provisioned for that vertical customer. According to 218 this reasoning, the NEST can be used by the network operator as input 219 to the NSI preparation phase, which is defined in [TS28.530]. 3GPP is 220 working on the translation of the GST/NEST attributes into NSI 221 related requirements, which are defined in the "ServiceProfile" data 222 type from the Network Slice Information Object Class (IOC) in 223 [TS28.541]. These requirements are used by the 3GPP Management 224 System to allocate the NSI across all network domains, including 225 transport network. The IETF network slice defines the part of that 226 NSI that is deployed across the transport network. 228 Despite the translation is an on-going work in 3GPP it seems 229 convenient to start looking at the GST attributes to understand what 230 kind of parameters could be required for the IETF network slice NBI. 232 4.1.1. Generic network Slice Template 234 The structure of the GST is defined in [GSMA]. The template defines 235 a total of 35 attributes. For each of them, the following 236 information is provided: 238 o Attribute definition, which provides a formal definition of what 239 the attribute represents. 241 o Attribute parameters, including: 243 * Value, e.g. integer, float. 245 * Measurement unit, e.g. milliseconds, Gbps 247 * Example, which provides examples of values the parameter can 248 take in different use cases. 250 * Tag, which allow describing the type of parameter, according to 251 its semantics. An attribute can be tagged as a 252 characterization attribute or a scalability attribute. If it 253 is characterization attribute, it can be further tagged as a 254 performance-related attribute, a functionality-related 255 attribute or an operation-related attribute. 257 * Exposure, which allow describing how this attribute interact 258 with the slice customer, either as an API or a KPI. 260 o Attribute presence, either mandatory, conditional or optional. 262 Attributes from GST can be used by the network operator (slice 263 controller) and a vertical customer (slice customer) to agree SLA. 265 GST attributes are generic in the sense that they can be used to 266 characterize different types of network slices. Once those 267 attributes become filled with specific values, it becomes a NEST 268 which can be ordered by slice customers. 270 4.1.2. Categorization of GST attributes 272 Not all the GST attributes as defined in [GSMA] have impact in the 273 transport network since some of them are specific to either the radio 274 or the mobile core part. 276 In the analysis performed in this document, the attributes have been 277 categorized as: 279 o Directly impactive attributes, which are those that have direct 280 impact on the definition of the IETF network slice, i.e., 281 attributes that can be directly translated into requirements 282 required to be satisfied by a IETF network slice. 284 o Indirectly impactive attributes, which are those that impact in an 285 indirect manner on the definition of the IETF network slice, i.e., 286 attributes that indirectly impose some requirements to a IETF 287 network slice. 289 o Non-impactive attributes, that are those which do not have impact 290 on the IETF network slice at all. 292 The following sections describe the attributes falling into the three 293 categories. 295 4.1.2.1. Attributes with direct impact on the IETF network slice 296 definition 298 The following attributes impose requirements in the IETF network 299 slice 301 o Availability 303 o Deterministic communication 305 o Downlink throughput per network slice 307 o Energy efficiency 309 o Group communication support 311 o Isolation level 313 o Maximum supported packet size 315 o Mission critical support 317 o Performance monitoring 319 o Slice quality of service parameters 321 o Support for non-IP traffic 323 o Uplink throughput per network slice 325 o User data access (i.e., tunneling mechanisms) 327 4.1.2.2. Attributes with indirect impact on the IETF network slice 328 definition 330 The following attributes indirectly impose requirements in the IETF 331 network slice to support the end-to-end service. 333 o Area of service (i.e., the area where terminals can access a 334 particular network slice) 336 o Delay tolerance (i.e., if the service can be delivered when the 337 system has sufficient resources) 339 o Downlink (maximum) throughput per UE 341 o Network functions owned by Network Slice Customer 343 o Maximum number of (concurrent) PDU sessions 345 o Performance prediction (i.e., capability to predict the network 346 and service status) 348 o Root cause investigation 350 o Session and Service Continuity support 352 o Simultaneous use of the network slice 354 o Supported device velocity 356 o UE density 358 o Uplink (maximum) throughput per UE 360 o User management openness (i.e., capability to manage users' 361 network services and corresponding requirements) 363 o Latency from (last) UPF to Application Server 365 4.1.2.3. Attributes with no impact on the IETF network slice definition 367 The following attributes do not impact the IETF network slice. 369 o Location based message delivery (not related to the geographical 370 spread of the network slice itself but with the localized 371 distribution of information) 373 o MMTel support, i.e. support of and Multimedia Telephony Service 374 (MMTel)as well as IP Multimedia Subsystem (IMS) support. 376 o NB-IoT Support, i.e., support of NB-IoT in the RAN in the network 377 slice. 379 o Maximum number of (simultaneous) UEs 381 o Positioning support 383 o Radio spectrum 384 o Synchronicity (among devices) 386 o V2X communication mode 388 o Network Slice Specific Authentication and Authorization (NSSAA) 390 4.1.3. Provisioning procedures 392 3GPP identifies in [TS28.541] a number of procedures for the 393 provisioning of a network slice in general. It can be assumed that 394 similar procedures may also apply to a transport slice, facilitating 395 a consistent management and control of end-to-end slices. 397 The envisioned procedures are the following: 399 o Slice instance allocation: this procedure permits to create a new 400 slice instance (or reuse an existing one). 402 o Slice instance de-allocation: this procedure decommissions a 403 previously instantiated slice. 405 o Slice instance modification: this procedure permits the change in 406 the characteristics of an existing slice instance. 408 o Get slice instance status: this procedure helps to retrieve run- 409 time information on the status of a deployed slice instance. 411 o Retrieval of slice capabilities: this procedure assists on getting 412 information about the capabilities (e.g. maximum latency 413 supported). 415 All these procedures fit in the operation of transport network 416 slices. 418 4.2. NFV-based services 420 NFV technology allows the flexible and dynamic instantiation of 421 virtualized network functions (and their composition into network 422 services) on top of a distributed, cloud-enabled compute 423 infrastructure. This infrastructure can span across different points 424 of presence in a carrier network. By leveraging on transport network 425 slicing, connectivity services established across geographically 426 remote points of presence can be enriched by providing additional QoS 427 guarantees with respect present state-of-the-art mechanisms, as 428 conventional L2/L3 VPNs. 430 4.2.1. Connectivity attributes 432 The connectivity services are expressed through a number of 433 attributes as listed: 435 o Incoming and outgoing bandwidth: bandwidth required for the 436 connectivity services (in Mbps). 438 o Qos metrics: set of metrics (e.g., cost, latency and delay 439 variation) applicable to a specific connectivity service 441 o Directionality: indication if the traffic is unidirectional or 442 bidirectional. 444 o MTU: value of the largest PDU to be transmitted in the 445 connectivity service. 447 o Protection scheme: indication of the kind of protection to be 448 performed (e.g., 1;1, 1+1, etc.) 450 o Connectivity mode: indication of the service is point-to-point of 451 point-to-multipoint 453 All those attributes will assist on the characterization of the 454 connectivity slice to be deployed, and thus, are relevant for the 455 definition of a IETF network slice supporting such connectivity. 457 4.2.2. Provisioning procedures 459 ETSI NFV defines the role of WAN Infrastructure Manager (WIM) as the 460 component in charge of managing and controlling the connectivity 461 external to the PoPs. In [IFA032] a number of interfaces are 462 identified to be exposed by the WIM for supporting the multi-site 463 connectivity, thus representing the capabilities expected for a 464 transport network slice, as well, in case of satisfying such 465 connectivity needs by means of the slice concept. 467 The interfaces considered are the following: 469 o Multi-Site Connectivity Service (MSCS) Management: this interface 470 permits the creation, termination, update and query of MSCSs, 471 including reservation. It also enables subscription for 472 notifications and information retrieval associated to the 473 connectivity service. 475 o Capacity Management: this interface allows querying about the 476 capacity (e.g. bandwidth), topology, and network edge points of 477 the connectivity service, as well as about information of consumed 478 and available capacity on the underlying network resources. 480 o Fault Management: this interface serves for the provision of 481 alarms related to the MSCSs. 483 o Performance Management: this interface assists on the retrieval of 484 performance information (measurement results collection and 485 notifications) related to MSCSs. 487 4.3. Network sharing 489 Network sharing is one of the means network operators exploit for 490 increasing efficiencies. There are different scenarios of network 491 sharing, being especially popular in the deployment of mobile 492 networks, typically referred to as Radio Access Network (RAN) 493 sharing. From an operational perspective, in RAN sharing we have two 494 roles: master operator, being the actor (e.g. infrastructure 495 provider, network operator) to which the deployment and daily 496 operation of shared RAN elements are entrusted to; and the 497 participant operators, who are the mobile operators who share the RAN 498 facilities provided by the master operator. Note that in this 499 context the master and participant operator can be seen as provider 500 and customer, respectively. 502 While there exist different modes of RAN sharing [TS23.251], 503 including passive RAN sharing (infrastructure site sharing) and 504 active RAN sharing (e.g. Multi-Operator Core Networks or MOCN), most 505 of the cases require the establishment of separated connections in 506 order to separate the traffic per participant operator. Such 507 connections typically extend from the cell site to some pre-defined 508 and agreed interconnection points, from which the traffic is routed 509 and delivered to individual participant operators. 511 The above-referred connections can have specific attributes. Aspects 512 like guaranteed bandwidth (in line with the expected load from the 513 aggregated cells), redundancy, bounded latency (per kind of traffic), 514 or secure delivery of the information should be considered. 516 The master operator is the one in charge of provisioning the 517 connections and collecting management data (e.g. performance 518 measurements, telemetry, fault alarms, trace data) for individual 519 participant operators. The use of network slicing could make the 520 network sharing approach more flexible by allowing the other 521 operators control and manage the established connections [MEF]. 523 The implications of the RAN sharing scenario here described can be 524 extended to either fixed networks or even to mobile networks 525 leveraging on radio functional split (i.e., including fronthaul and 526 midhaul network segments). 528 4.3.1. Connectivity attributes 530 The connections for RAN sharing typically consider attributes like: 532 o Maximum and Guaranteed Bit Rate (MBR and GBR respectively). 534 o Bounded latency (e.g., for user plane, control plane, etc) 536 o Packet loss rate. 538 o IP addressing (consistent among the operators sharing the 539 infrastructure). 541 o L2/L3 reachability. 543 o Recovery time (on the event of failures). 545 o Secure connection (e.g., encryption support). 547 4.3.2. Provisioning procedures 549 The expected provisioning procedures are: 551 o Connection provisioning between site and interconnection point. 552 Those connections could evolve in time in terms of capacity 553 depending on the capacity growth of each particular site. 555 o Collection of management data, including performance measurements, 556 fault alarms and trace data. 558 4.4. Additional use cases 560 This is a placeholder for describing additional use cases (e.g., data 561 center interconnection, etc). To be completed. 563 5. Security Considerations 565 This draft does not include any security considerations. 567 6. IANA Considerations 569 This draft does not include any IANA considerations 571 7. References 573 7.1. Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, 577 DOI 10.17487/RFC2119, March 1997, 578 . 580 7.2. Informative References 582 [GSMA] "Generic Network Slice Template, version 3.0", NG.116 , 583 May 2020. 585 [I-D.homma-slice-provision-models] 586 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V., 587 Lopez, D., Contreras, L., Ordonez-Lucena, J., Martinez- 588 Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., and X. 589 Foy, "Network Slice Provision Models", draft-homma-slice- 590 provision-models-02 (work in progress), November 2019. 592 [I-D.ietf-teas-ietf-network-slice-definition] 593 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. 594 Tantsura, "Definition of IETF Network Slices", draft-ietf- 595 teas-ietf-network-slice-definition-00 (work in progress), 596 January 2021. 598 [I-D.nsdt-teas-ns-framework] 599 Gray, E. and J. Drake, "Framework for Transport Network 600 Slices", draft-nsdt-teas-ns-framework-04 (work in 601 progress), July 2020. 603 [IFA032] "IFA032 Interface and Information Model Specification for 604 Multi-Site Connectivity Services V3.2.1.", ETSI GS NFV-IFA 605 032 V3.2.1 , April 2019. 607 [MEF] "Slicing for Shared 5G Fronthaul and Backhaul", MEF White 608 paper , April 2020. 610 [TS23.251] 611 "TS 23.251 Network Sharing; Architecture and functional 612 description (Release 16) V16.0.0.", 3GPP TS 23.251 613 V16.0.0 , July 2020. 615 [TS28.530] 616 "TS 28.530 Management and orchestration; Concepts, use 617 cases and requirements (Release 16) V16.0.0.", 3GPP TS 618 28.530 V16.0.0 , September 2019. 620 [TS28.541] 621 "TS 28.541 Management and orchestration; 5G Network 622 Resource Model (NRM); Stage 2 and stage 3 (Release 16) 623 V16.2.0.", 3GPP TS 28.541 V16.2.0 , September 2019. 625 Authors' Addresses 627 Luis M. Contreras 628 Telefonica 629 Ronda de la Comunicacion, s/n 630 Sur-3 building, 3rd floor 631 Madrid 28050 632 Spain 634 Email: luismiguel.contrerasmurillo@telefonica.com 635 URI: http://lmcontreras.com/ 637 Shunsuke Homma 638 NTT 639 Japan 641 Email: shunsuke.homma.ietf@gmail.com 643 Jose A. Ordonez-Lucena 644 Telefonica 645 Ronda de la Comunicacion, s/n 646 Sur-3 building, 3rd floor 647 Madrid 28050 648 Spain 650 Email: joseantonio.ordonezlucena@telefonica.com