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