idnits 2.17.00 (12 Aug 2021) /tmp/idnits11864/draft-contreras-teas-slice-nbi-05.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 : ---------------------------------------------------------------------------- ** There are 51 instances of too long lines in the document, the longest one being 47 characters in excess of 72. 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 12, 2021) is 313 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'TM' is mentioned on line 819, but not defined Summary: 1 error (**), 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 13, 2022 NTT 6 J. Ordonez-Lucena 7 Telefonica 8 J. Tantsura 9 Microsoft 10 K. Szarkowicz 11 Juniper Networks 12 July 12, 2021 14 IETF Network Slice Use Cases and Attributes for Northbound Interface of 15 IETF Network Slice Controllers 16 draft-contreras-teas-slice-nbi-05 18 Abstract 20 This document analyses the needs of potential customers of network 21 slices realized with IETF techniques in several use cases, identifies 22 the functionalities for the North Bound Interface (NBI) of an IETF 23 Network Slice Controller to satisfy such 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 January 13, 2022. 42 Copyright Notice 44 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Conventions used in this document and terminology . . . . . . 3 61 3. Northbound Interface for IETF Network Slices . . . . . . . . 4 62 4. IETF Network Slice Use Cases . . . . . . . . . . . . . . . . 5 63 4.1. 5G Services . . . . . . . . . . . . . . . . . . . . . . . 5 64 4.1.1. 3GPP network slice . . . . . . . . . . . . . . . . . 6 65 4.1.1.1. Topology of the TN-NSS . . . . . . . . . . . . . 6 66 4.1.1.2. Traffic segregation and mapping to S-NSSAI list . 7 67 4.1.1.3. Reachability information . . . . . . . . . . . . 10 68 4.1.1.4. QoS profiling . . . . . . . . . . . . . . . . . . 10 69 4.1.2. Generic network Slice Template . . . . . . . . . . . 10 70 4.1.3. Categorization of GST attributes . . . . . . . . . . 11 71 4.1.3.1. Attributes with direct impact on the IETF network 72 slice definition . . . . . . . . . . . . . . . . 12 73 4.1.3.2. Attributes with indirect impact on the IETF 74 network slice definition . . . . . . . . . . . . 12 75 4.1.3.3. Attributes with no impact on the IETF network 76 slice definition . . . . . . . . . . . . . . . . 13 77 4.1.4. Provisioning procedures . . . . . . . . . . . . . . . 14 78 4.2. NFV-based services . . . . . . . . . . . . . . . . . . . 14 79 4.2.1. Connectivity attributes . . . . . . . . . . . . . . . 15 80 4.2.2. Provisioning procedures . . . . . . . . . . . . . . . 15 81 4.3. Network sharing . . . . . . . . . . . . . . . . . . . . . 16 82 4.3.1. Connectivity attributes . . . . . . . . . . . . . . . 17 83 4.3.2. Provisioning procedures . . . . . . . . . . . . . . . 17 84 4.4. SD-WAN . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 4.4.1. SD-WAN Structure . . . . . . . . . . . . . . . . . . 18 86 4.4.2. Connectivity Attributes . . . . . . . . . . . . . . . 19 87 4.4.3. SD-WAN Endpoint Attributes . . . . . . . . . . . . . 21 88 4.4.4. SD-WAN UNI Attributes . . . . . . . . . . . . . . . . 21 89 4.5. Radio functional splits . . . . . . . . . . . . . . . . . 22 90 4.5.1. Attributes and procedures . . . . . . . . . . . . . . 23 91 4.6. Additional use cases . . . . . . . . . . . . . . . . . . 23 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 93 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 95 7.1. Normative References . . . . . . . . . . . . . . . . . . 23 96 7.2. Informative References . . . . . . . . . . . . . . . . . 23 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 100 1. Introduction 102 A number of new technologies, such as 5G, NFV and SDN are not only 103 evolving the network from a pure technological perspective but also 104 are changing the concept in which new services are offered to the 105 customers [I-D.homma-slice-provision-models] by introducing the 106 concept of network slicing. 108 The transport network is an essential component in the end-to-end 109 delivery of services and, consequently, it is necessary to understand 110 what could be the way in which the transport network is consumed as a 111 slice. For a definition of IETF network slice refer to 112 [I-D.ietf-teas-ietf-network-slice-definition]. 114 In this document it is assumed that there exists a (logically) 115 centralized component in the transport network, namely IETF Network 116 Slice Controller (NSC) with the responsibilities on the control and 117 management of the IETF network slices invoked for a given service, as 118 requested by IETF network slice customers. 120 This document analyses different use cases deriving the needs of 121 potential IETF network slice customers in order to identify the 122 functionality required on the North Bound Interface (NBI) of the NSC 123 to be exposed towards such IETF network slice customers. Solutions 124 to construct the requested IETF network slices are out of scope of 125 this document. 127 This document addresses some of the discussions of the TEAS Slice 128 Design Team. However, it is not at this stage an official outcome of 129 the Design Team. 131 2. Conventions used in this document and terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in RFC2119 [RFC2119]. 137 The terminology in this draft will be aligned in forthcoming versions 138 with the final terminology selected for describing the notion of IETF 139 network slice when applied to IETF technologies, which is currently 140 under discussion. By now same terminology as used in 141 [I-D.ietf-teas-ietf-network-slice-definition] and 142 [I-D.nsdt-teas-ns-framework] is primarily used here. 144 The term "transport network" in the context of this draft refers in 145 broad sense to WAN, MBH, IP backbone and other network segments 146 implemented by IETF technologies. 148 3. Northbound Interface for IETF Network Slices 150 In a general manner, the transport network supports different kinds 151 of services. These services consume capabilities provided by the 152 transport network for deploying end-to-end services, interconnecting 153 network functions or applications spread across the network and 154 providing connectivity toward the final users of these services. 156 Under the slicing approach, a IETF network slice customer requests to 157 a IETF network slice controller a slice with certain characteristics 158 and parametrization. Such request it is assumed here to be done 159 through a NBI exposed by the NSC to the customer, as reflected in 160 Figure 1. 162 +--------------------+ 163 | | 164 | IETF Network | 165 | Slice Customer | 166 | | 167 +--------------------+ 168 A 169 | 170 | IETF Network 171 | Slice Controller 172 | NBI 173 | 174 V 175 +--------------------+ 176 | | 177 | IETF Network | 178 | Slice Controller | 179 | | 180 +--------------------+ 182 Figure 1: IETF network slice NBI concept 184 The functionality supported by the NBI depends on the requirements 185 that the slice customer has to satisfy. It is then important to 186 understand the needs of the slice customers as well as the way of 187 expressing them. 189 4. IETF Network Slice Use Cases 191 Different use cases for slice customers can be identified, as 192 described in the following sections. 194 4.1. 5G Services 196 5G services natively rely on the concept of network slicing. 5G is 197 expected to allow vertical customers to request slices in such a 198 manner that the allocated resources and capabilities in the network 199 appear as dedicated for them. 201 In network slicing scenarios, a vertical customer requests a network 202 operator to allocate a network slice instance (NSI) satisfying a 203 particular set of service requirements. The content/format of these 204 requirements are highly dependent on the networking expertise and use 205 cases of the customer under consideration. To deal with this 206 heterogeneity, it is fundamental for the network operator to define a 207 a unified ability to interpret service requirements from different 208 vertical customers, and to represent them in a common language, with 209 the purposes of facilitating their translation/mapping into specific 210 slicing-aware network configuration actions. In this regard, model- 211 based network slice descriptors built on the principles of 212 reproducibility, reusability and customizability can be defined for 213 this end. 215 As a starting point for such a definition, GSMA developed the idea of 216 having a universal blueprint that, being offered by network 217 operators, can be used by any vertical customer to order the 218 deployment of an NSI based on a specific set of service requirements. 219 The result of this work has been the definition of a baseline network 220 slice descriptor called Generic network Slice Template (GST). The 221 GST contains multiple attributes that can be used to characterize a 222 network slice. A Network Slice Type (NEST) describes the 223 characteristics of a network slice by means of filling GST attributes 224 with values based on specific service requirements. Basically, a 225 NEST is a filled-in version of a GST. Different NESTs allow 226 describing different types of network slices. For slices based on 227 standardized service types, e.g. eMBB, uRLLC and mIoT, the network 228 operator may have a set of readymade, standardized NESTs (S-NESTs). 229 For slices based on specific industry use cases, the network operator 230 can define additional NESTs. 232 Service requirements from a given vertical customer are mapped to a 233 NEST, which provides a self-contained description of the network 234 slice to be provisioned for that vertical customer. According to 235 this reasoning, the NEST can be used by the network operator as input 236 to the NSI preparation phase, which is defined in [TS28.530]. 3GPP is 237 working on the translation of the GST/NEST attributes into NSI 238 related requirements, which are defined in the "ServiceProfile" data 239 type from the Network Slice Information Object Class (IOC) in 240 [TS28.541]. These requirements are used by the 3GPP Management 241 System to allocate the NSI across all network domains, including 242 transport network. The IETF network slice defines the part of that 243 NSI that is deployed across the transport network. 245 Despite the translation is an on-going work in 3GPP it seems 246 convenient to start looking at the GST attributes to understand what 247 kind of parameters could be required for the IETF network slice NBI. 249 4.1.1. 3GPP network slice 251 A 3GPP network slice represents a logical network that provides 252 specific capabilities and network characteristics, supporting the 253 service requirements of one or more network slice customers. The 254 service requirements of each network slice customer are captured into 255 a separate "ServiceProfile" artifact within the network slice class 256 (see Network Slicing NRM fragment in TS 28.541). 258 A 3GPP network slice spans from 5GNR access nodes to the UPF that 259 terminates the PDU session, i.e. PSA UPF. In this in-slice data 260 path, there are TN segments (e.g. backhaul) that are out of scope of 261 3GPP management domain. For the provisioning and operation of these 262 TN segments, usually referred to as transport Network Slice Subnets 263 (TN-NSS), the 3GPP management system relies on an external TN 264 management system, which hosts (among other components) the IETF NSC. 265 To proceed with this delegation, the 3GPP management system needs to 266 make available to the TN management system the information described 267 in the following sub-sections. 269 4.1.1.1. Topology of the TN-NSS 271 The TN management system needs to know the transport termination/end 272 points to determine the transport resources, either physical or 273 virtual nodes. 3GPP management system systems need to provide the 274 transport endpoints of 3GPP managed functions that are part of the 275 RAN-NSS (e.g., gNB-CU-UP, gNB-CU-CP) and CN-NSS (e.g., UPF, AMF), and 276 if applicable further information such as the next-hop router IP 277 address configured in a RAN-NSS or CN-NSS. The TN management system 278 should be able to correlate this with the transport network topology 279 and derive the site or border routers connecting to 3GPP managed 280 functions. 282 4.1.1.2. Traffic segregation and mapping to S-NSSAI list 284 As network functions can be shared by many network slices, it will be 285 necessary to segregate the traffic belonging to specific slices on 286 transport interfaces. 288 One option for traffic segregation is to assign application endpoints 289 to specific sets of S-NSSAI values. The transport network can map 290 packets to connectivity services based on local remote or remote 291 endpoints, provided that the allocation of S-NSSAI to endpoints is 292 known and exposed, and provided that the application endpoints are 293 visible on the transport layer. The application endpoints visible in 294 a RAN-NSS and CN-NSS are already mapped to a specific set of S-NSSAI. 295 Figure 2 illustrates an example of this solution, whereby a 3GPP 296 network slice with S-NSSAI=1 is mapped to specific application 297 endpoints (e.g., N3 tunnel endpoint 1) by the access network node. 298 In this example, the TN management system decides to map application 299 endpoints 1 and 2 to the same transport connectivity service A. This 300 mapping is implemented by the site router connecting to the access 301 network node. On the core network slice, a similar mapping is done 302 by the border router. Demultiplexing the packet streams belonging to 303 different transport interfaces is based on regular routing and 304 reachability of endpoint IP addresses. 306 Transport Interface Transport Interface 307 (App_EP "x" <-> CSR) (BR <-> App_EP "x") 309 +---------------+ +-------+ +-------+ +---------------+ 310 +---|----+ +----|----+ | | | | +---|-----+ +---|----+ 311 |NSS-AN 1|-----| App_EP 1|<--->|-- | | --|<--->|App_EP 1 |-----|NSS-CN 1| 312 +---|----+ +----|----+ | \ +-|---Transport------+ / | +---|-----+ +---|----+ 313 | | | --| Connectivity |-- | | | 314 +---|----+ +----|----+ | / +-|------"A"---------+ \ | +---|-----+ +---|----+ 315 |NSS-AN 2|-----| App_EP 2|<--->|-- | | --|<--->|App_EP 2 |-----|NSS-CN 2| 316 +---|----+ +----|----+ | | | | +---|-----+ +---|----+ 317 | | | | | | | | 318 +---|----+ | | | | | | +---|----+ 319 |NSS-AN 3|- | | | | | | -|NSS-CN 3| 320 +---|----+ \ +----|----+ | +-----Transport------+ / | +---|-----+ +---|----+ 321 | ---| App_EP 3|<--->|-----| Connectivity |-----|<--->|App_EP 3 |--- | 322 +---|----+ / +----|----+ | +--------"B"---------+ | +---|-----+ \ +---|----+ 323 |NSS-AN 4|- | | | | | | -|NSS-CN 4| 324 +---|----+ | | | | | | +---|----+ 325 +---------------+ +-------+ +-------+ +---------------+ 327 Access network node(s) Cell Site Router (CSR) Border Router (BR) Core network node(s) 329 S-NSSAI=1: {NSS-AN 1, App_EP 1, Transport Connectivity A, App_EP 1, NSS-CN 1} 330 S-NSSAI=2: {NSS-AN 2, App_EP 2, Transport Connectivity A, App_EP 2, NSS-CN 2} 331 S-NSSAI=4: {NSS-AN 4, App_EP 3, Transport Connectivity B, App_EP 3, NSS-CN 3} 333 Figure 2: Mapping of S-NSSAI to specific application endpoints 335 Despite the simplicity of the above-referred approach, notice that it 336 is not a universal solution as the application endpoint addresses are 337 not always visible to the TN, for example when they are encrypted by 338 IPSec tunnels. In such a case, the application endpoints are not 339 visible to the site router, and thus cannot be used for transport 340 connectivity mappings. To deal with these situations, an alternative 341 solution is to use the concept of logical transport interfaces. A 342 logical transport interface is a virtual interface separate from 343 application endpoints; it can be for example a specific IP address / 344 VLAN combination that corresponds to an IPSec termination point, an 345 identifier (e.g., MPLS label, segment ID) that the TN recognizes, or 346 it can be just a logical interface defined on top of top a physical 347 transport interface. As long as the interface identity can derived 348 from packet headers, the TN nodes can perform the mapping to 349 transport connectivity services. In this regard, it is useful to 350 indicate to the TN which traffic types are carried over an interface 351 (e.g., N3 user plane packets, N2 control plane packets, etc.). 353 Figure 3 illustrates an example on the use of this solution. As 354 seen, logical transport need to be exposed from 3GPP management 355 system to TN management system, so that the latter can create 356 transport network topology and determine the TN resources to support 357 the 3GPP slice. 359 Logical transport interface, Logical transport interface, 360 exposed by RAN NSSMF exposed by CN NSSMF 362 +--------+ +-------+ +-------+ +-------+ 363 | | | | | | | | 364 +---|----+ +-----Logical------+ | | +-----Logical------+ +---|----+ 365 |NSS-AN 1|--| Transport |- | | -| Transport |--|NSS-CN 1| 366 +---|----+ +---Interface 1----+ \ +----Transport-----+ / +---Interface 1----+ +---|----+ 367 | | | --| Connectivity |-- | | | 368 +---|----+ +-----Logical------+ / +--------"A"-------+ \ +-----Logical------+ +---|----+ 369 |NSS-AN 2|--| Transport |- | | -| Transport |--|NSS-CN 2| 370 +---|----+ +---Interface 2----+ | | +---Interface 1----+ +---|----+ 371 | | | | | | | | 372 +---|----+ | | | | | | +---|----+ 373 |NSS-AN 3|- | | | | | | -|NSS-CN 3| 374 +---|----+ \+-----Logical------+ +----Transport----+ +-----Logical-------+/ +---|----+ 375 | | Transport |----| Connectivity |----| Transport | | 376 +---|----+ /+---Interface 2----+ +--------"B"------+ +---Interface 1-----+\ +---|----+ 377 |NSS-AN 4|- | | | | | | -|NSS-CN 4| 378 +---|----+ | | | | | | +---|----+ 379 | | | | | | | | 380 +--------+ +-------+ +-------+ +-------+ 382 Access network node(s) Cell Site Router (CSR) Border Router (BR) Core network node(s) 384 S-NSSAI=1: {NSS-AN 1, Logical Transport Interface 1, Transport Connectivity A, Logical Transport Interface 1, NSS-CN 1} 385 S-NSSAI=2: {NSS-AN 2, Logical Transport Interface 2, Transport Connectivity A, Logical Transport Interface 2, NSS-CN 2} 386 S-NSSAI=4: {NSS-AN 4, Logical Transport Interface 3, Transport Connectivity B, Logical Transport Interface 3, NSS-CN 4} 388 Figure 3: Logical Transport Interfaces 390 For traffic segregation, though solutions might be valid, 3GPP 391 prefers the second solution: on the use of concept of transport 392 logical interface. The reason is that it does not impose 1:1 mapping 393 between application endpoint and transport interface (allowing for 394 better redundancy) and that it always works, no matter if encryption. 395 To support this solution, the 3GPP has recently extended the Network 396 Slice NRM fragment, including a new Information Object Class called 397 EP_Transport. This class provides a complete characterization of the 398 logical transport interface, including transport level information 399 (i.e., IP address, reachability information, QoS profile) and the set 400 of application endpoints aggregated to this interface. For further 401 information on reachability information and QoS profile, see next 402 subsections. For further details on fields of EP_Transport, see 403 Network Slice NRM fragment in TS 28.541. 405 4.1.1.3. Reachability information 407 Each physical or logical transport interface will carry the traffic 408 associated with some 3GPP application endpoints that may be using IP 409 addresses separate from the transport interface. These IP addresses 410 must be reachable within the TN-NSS, and hence they need to be 411 advertised to populate forwarding tables. A 3GPP network function 412 can advertise such reachability information by running a dynamic 413 routing protocol towards the next hop router. If that is not 414 possible, it can create association between the reachability data 415 with the logical transport interface and expose it towards the 3GPP 416 and TN management system. This information can be derived from the 417 IP addresses available for application and transport endpoints. 419 4.1.1.4. QoS profiling 421 Each TN-NSS may be associated a "TNSliceSubnetProfile", which hosts 422 the SLO requirements (e.g., guaranteed throughput, bounded latency, 423 maximum jitter) that the TN-NSS must support. "TNSliceSubnetProfile" 424 is a 3GPP artifact that result from the decomposition of e2e service 425 requirements ("ServiceProfile" artifact ) into domain-specific 426 service requirements ("RANSliceSubnetProfile", "CNSliceSubnetProfile" 427 and "TNSliceSubnetProfile") applicable to RAN-NSS, CN-NSS and TN-NSS 428 respectively. Unlike "RANSliceSubnetProfile" and 429 "CNSliceSubnetProfile", there is not agreement yet on the specific 430 parameters to be captured by the "TNSliceSubnetProfile". Further 431 work in this regard in the upcoming 3GPP SA5 meetings. 433 Upon receiving the "TNSliceSubnetProfile" from the 3GPP management 434 system, the TN management system translates the SLO requirements 435 therein into a QoS profile, which includes applicability and use of 436 DSCPs and other QoS related properties onto the TN-NSS realization. 437 To enable this, each logical interface may have an associated QoS 438 profile. The QoS profile is just a reference to the detailed profile 439 parameters which are logically provisioned on both sides of a logical 440 transport interface. 442 4.1.2. Generic network Slice Template 444 The structure of the GST is defined in [GSMA]. The template defines 445 a total of 35 attributes. For each of them, the following 446 information is provided: 448 o Attribute definition, which provides a formal definition of what 449 the attribute represents. 451 o Attribute parameters, including: 453 * Value, e.g. integer, float. 455 * Measurement unit, e.g. milliseconds, Gbps 457 * Example, which provides examples of values the parameter can 458 take in different use cases. 460 * Tag, which allow describing the type of parameter, according to 461 its semantics. An attribute can be tagged as a 462 characterization attribute or a scalability attribute. If it 463 is characterization attribute, it can be further tagged as a 464 performance-related attribute, a functionality-related 465 attribute or an operation-related attribute. 467 * Exposure, which allow describing how this attribute interact 468 with the slice customer, either as an API or a KPI. 470 o Attribute presence, either mandatory, conditional or optional. 472 Attributes from GST can be used by the network operator (slice 473 controller) and a vertical customer (slice customer) to agree SLA. 475 GST attributes are generic in the sense that they can be used to 476 characterize different types of network slices. Once those 477 attributes become filled with specific values, it becomes a NEST 478 which can be ordered by slice customers. 480 4.1.3. Categorization of GST attributes 482 Not all the GST attributes as defined in [GSMA] have impact in the 483 transport network since some of them are specific to either the radio 484 or the mobile core part. 486 In the analysis performed in this document, the attributes have been 487 categorized as: 489 o Directly impactive attributes, which are those that have direct 490 impact on the definition of the IETF network slice, i.e., 491 attributes that can be directly translated into requirements 492 required to be satisfied by a IETF network slice. 494 o Indirectly impactive attributes, which are those that impact in an 495 indirect manner on the definition of the IETF network slice, i.e., 496 attributes that indirectly impose some requirements to a IETF 497 network slice. 499 o Non-impactive attributes, that are those which do not have impact 500 on the IETF network slice at all. 502 The following sections describe the attributes falling into the three 503 categories. 505 4.1.3.1. Attributes with direct impact on the IETF network slice 506 definition 508 The following attributes impose requirements in the IETF network 509 slice 511 o Availability 513 o Deterministic communication 515 o Downlink throughput per network slice 517 o Energy efficiency 519 o Group communication support 521 o Isolation level 523 o Maximum supported packet size 525 o Mission critical support 527 o Performance monitoring 529 o Slice quality of service parameters 531 o Support for non-IP traffic 533 o Uplink throughput per network slice 535 o User data access (i.e., tunneling mechanisms) 537 4.1.3.2. Attributes with indirect impact on the IETF network slice 538 definition 540 The following attributes indirectly impose requirements in the IETF 541 network slice to support the end-to-end service. 543 o Area of service (i.e., the area where terminals can access a 544 particular network slice) 546 o Delay tolerance (i.e., if the service can be delivered when the 547 system has sufficient resources) 549 o Downlink (maximum) throughput per UE 551 o Network functions owned by Network Slice Customer 553 o Maximum number of (concurrent) PDU sessions 555 o Performance prediction (i.e., capability to predict the network 556 and service status) 558 o Root cause investigation 560 o Session and Service Continuity support 562 o Simultaneous use of the network slice 564 o Supported device velocity 566 o UE density 568 o Uplink (maximum) throughput per UE 570 o User management openness (i.e., capability to manage users' 571 network services and corresponding requirements) 573 o Latency from (last) UPF to Application Server 575 4.1.3.3. Attributes with no impact on the IETF network slice definition 577 The following attributes do not impact the IETF network slice. 579 o Location based message delivery (not related to the geographical 580 spread of the network slice itself but with the localized 581 distribution of information) 583 o MMTel support, i.e. support of and Multimedia Telephony Service 584 (MMTel)as well as IP Multimedia Subsystem (IMS) support. 586 o NB-IoT Support, i.e., support of NB-IoT in the RAN in the network 587 slice. 589 o Maximum number of (simultaneous) UEs 590 o Positioning support 592 o Radio spectrum 594 o Synchronicity (among devices) 596 o V2X communication mode 598 o Network Slice Specific Authentication and Authorization (NSSAA) 600 4.1.4. Provisioning procedures 602 3GPP identifies in [TS28.541] a number of procedures for the 603 provisioning of a network slice in general. It can be assumed that 604 similar procedures may also apply to a transport slice, facilitating 605 a consistent management and control of end-to-end slices. 607 The envisioned procedures are the following: 609 o Slice instance allocation: this procedure permits to create a new 610 slice instance (or reuse an existing one). 612 o Slice instance de-allocation: this procedure decommissions a 613 previously instantiated slice. 615 o Slice instance modification: this procedure permits the change in 616 the characteristics of an existing slice instance. 618 o Get slice instance status: this procedure helps to retrieve run- 619 time information on the status of a deployed slice instance. 621 o Retrieval of slice capabilities: this procedure assists on getting 622 information about the capabilities (e.g. maximum latency 623 supported). 625 All these procedures fit in the operation of transport network 626 slices. 628 4.2. NFV-based services 630 NFV technology allows the flexible and dynamic instantiation of 631 virtualized network functions (and their composition into network 632 services) on top of a distributed, cloud-enabled compute 633 infrastructure. This infrastructure can span across different points 634 of presence in a carrier network. By leveraging on transport network 635 slicing, connectivity services established across geographically 636 remote points of presence can be enriched by providing additional QoS 637 guarantees with respect present state-of-the-art mechanisms, as 638 conventional L2/L3 VPNs. 640 4.2.1. Connectivity attributes 642 The connectivity services are expressed through a number of 643 attributes as listed: 645 o Incoming and outgoing bandwidth: bandwidth required for the 646 connectivity services (in Mbps). 648 o Qos metrics: set of metrics (e.g., cost, latency and delay 649 variation) applicable to a specific connectivity service 651 o Directionality: indication if the traffic is unidirectional or 652 bidirectional. 654 o MTU: value of the largest PDU to be transmitted in the 655 connectivity service. 657 o Protection scheme: indication of the kind of protection to be 658 performed (e.g., 1;1, 1+1, etc.) 660 o Connectivity mode: indication of the service is point-to-point of 661 point-to-multipoint 663 All those attributes will assist on the characterization of the 664 connectivity slice to be deployed, and thus, are relevant for the 665 definition of a IETF network slice supporting such connectivity. 667 4.2.2. Provisioning procedures 669 ETSI NFV defines the role of WAN Infrastructure Manager (WIM) as the 670 component in charge of managing and controlling the connectivity 671 external to the PoPs. In [IFA032] a number of interfaces are 672 identified to be exposed by the WIM for supporting the multi-site 673 connectivity, thus representing the capabilities expected for a 674 transport network slice, as well, in case of satisfying such 675 connectivity needs by means of the slice concept. 677 The interfaces considered are the following: 679 o Multi-Site Connectivity Service (MSCS) Management: this interface 680 permits the creation, termination, update and query of MSCSs, 681 including reservation. It also enables subscription for 682 notifications and information retrieval associated to the 683 connectivity service. 685 o Capacity Management: this interface allows querying about the 686 capacity (e.g. bandwidth), topology, and network edge points of 687 the connectivity service, as well as about information of consumed 688 and available capacity on the underlying network resources. 690 o Fault Management: this interface serves for the provision of 691 alarms related to the MSCSs. 693 o Performance Management: this interface assists on the retrieval of 694 performance information (measurement results collection and 695 notifications) related to MSCSs. 697 4.3. Network sharing 699 Network sharing is one of the means network operators exploit for 700 increasing efficiencies. There are different scenarios of network 701 sharing, being especially popular in the deployment of mobile 702 networks, typically referred to as Radio Access Network (RAN) 703 sharing. From an operational perspective, in RAN sharing we have two 704 roles: master operator, being the actor (e.g. infrastructure 705 provider, network operator) to which the deployment and daily 706 operation of shared RAN elements are entrusted to; and the 707 participant operators, who are the mobile operators who share the RAN 708 facilities provided by the master operator. Note that in this 709 context the master and participant operator can be seen as provider 710 and customer, respectively. 712 While there exist different modes of RAN sharing [TS23.251], 713 including passive RAN sharing (infrastructure site sharing) and 714 active RAN sharing (e.g. Multi-Operator Core Networks or MOCN), most 715 of the cases require the establishment of separated connections in 716 order to separate the traffic per participant operator. Such 717 connections typically extend from the cell site to some pre-defined 718 and agreed interconnection points, from which the traffic is routed 719 and delivered to individual participant operators. 721 The above-referred connections can have specific attributes. Aspects 722 like guaranteed bandwidth (in line with the expected load from the 723 aggregated cells), redundancy, bounded latency (per kind of traffic), 724 or secure delivery of the information should be considered. 726 The master operator is the one in charge of provisioning the 727 connections and collecting management data (e.g. performance 728 measurements, telemetry, fault alarms, trace data) for individual 729 participant operators. The use of network slicing could make the 730 network sharing approach more flexible by allowing the other 731 operators control and manage the established connections [MEF]. 733 The implications of the RAN sharing scenario here described can be 734 extended to either fixed networks or even to mobile networks 735 leveraging on radio functional split (i.e., including fronthaul and 736 midhaul network segments). 738 4.3.1. Connectivity attributes 740 The connections for RAN sharing typically consider attributes like: 742 o Maximum and Guaranteed Bit Rate (MBR and GBR respectively). 744 o Bounded latency (e.g., for user plane, control plane, etc) 746 o Packet loss rate. 748 o IP addressing (consistent among the operators sharing the 749 infrastructure). 751 o L2/L3 reachability. 753 o Recovery time (on the event of failures). 755 o Secure connection (e.g., encryption support). 757 4.3.2. Provisioning procedures 759 The expected provisioning procedures are: 761 o Connection provisioning between site and interconnection point. 762 Those connections could evolve in time in terms of capacity 763 depending on the capacity growth of each particular site. 765 o Collection of management data, including performance measurements, 766 fault alarms and trace data. 768 4.4. SD-WAN 770 SD-WAN is a solution to provide a virtual overlay network for 771 connecting between customer's sites, (virtual) private cloud, or 772 public cloud/Internet. SD-WAN operates over one or more underlay 773 networks, and enables to offer more differentiated service delivery 774 capabilities. SD-WAN can be esteemed as a type of network slices or 775 can be established over underlay networks provided as network slices. 776 The definitions, specification, service attributes, and framework of 777 SD-WAN is defined in Metro Ethernet Forum ([MEF-70]). 779 SD-WAN forwards traffic based on application flows, and the policies 780 include rules and constraints on the forwarding of the application 781 flows. In SD-WAN, it may be required from the customer to adjust the 782 behaviors based on its needs in near real time. The service provider 783 is required to monitor the performance of the service and modify the 784 forwarding policies based on the real-time telemetry from the 785 underlying network components. 787 4.4.1. SD-WAN Structure 789 SD-WAN has three logical constructs: 791 o SD-WAN virtual connection 793 o SD-WAN virtual connection endpoint 795 o SD-WAN UNI 797 Several additional components may be visible to the customer. These 798 include: 800 o Customer network 802 o Service provider network 804 o Underlay connectivity 806 o Tunnel virtual connection 808 The following figure shows the overview of SD-WAN structure. In this 809 case, the customer sites are connected with underlay connectivity#1 810 and they are also connected to remote private cloud with underlay 811 connectivity#2. An SD-WAN endpoint is usually located in each 812 customer network site as a CPE or a customer edge, and it allocates 813 application flow to appropriate underlay connectivity. 815 ,----. 816 | \ 817 ,-aEUR[TM] Private`--. 818 | cloud | 819 `---+---+-----aEUR[TM] 820 - - - - |EP | - - - - - 821 | +---+ | 822 | # | 823 /---------\| # |/----------\ 824 | Customer +--+=========#===========+--+ Customer | 825 | Network |EP|. . . . . . . . . . .|EP| Network | 826 | site A +--+ Service Provider +--+ site B | 827 \---------A| Network |A---------/ 828 | - - - - - - - - - - - - - | 829 | | 830 SD-WAN UNI SD-WAN UNI 832 * Legend 833 . . . : Underlay connectivity#1 834 ===== : Underlay Connectivity#2 835 EP : SD-WAN Endpoint 837 Figure 4: Overview of SD-WAN Structure 839 SD-WAN may be provided as a network slice, or it is realized on 840 several network slices provided as underlay connectivities. In the 841 former case, a network slice PE will be mapped to CE in SD-WAN. In 842 the later case, PEs of the provider of underlay connectivities will 843 behave as network slice PEs. 845 4.4.2. Connectivity Attributes 847 SD-WAN defined in MEF-70 has several attributes on its connectivity 848 as below: 850 o SD-WAN Identifier: the value is a string that is used by the 851 customer and service provider to uniquely identify an SD-WAN 852 connectivity. 854 o Endpoint list: the value is a list contains endpoint identifiers 855 and their connected endpoints. 857 o Service Uptime Objective: the value is the proportion of time 858 that the connectivity service is working during a given time 859 period. 861 o Reserved Prefixes: the values are IP prefixes reserved by the 862 service provider for use for SD-WAN within its own network or for 863 distribution to the customer via DHCP or SLAAC. 865 o List for Policies: the value is a list of policies applied to 866 application flows and application flow groups at endpoints. An 867 SD-WAN policy list contains policy name and list of policy 868 criteria. Support of the criteria listed below would be required: 870 * Encryption: indicates whether or not the application flow 871 requires encryption 873 * Public-Private: indicates whether the application flow can 874 traverse public or private underlay connectivity services (or 875 both). 877 * Internet-Breakout: indicates whether the application flow 878 should be forwarded to an Internet destination. 880 * Billing-Method: indicate the application flow can be sent over 881 an underlay connectivity service that has usage-based or flat- 882 rate billing. 884 * Backup: indicates whether this application flow can use a TVC 885 designated as aEURbackupaEUR. 887 * Bandwidth: specifies a rate limit on the application flow. 889 o List of Application Flow Groups: the value is a list of 890 application flow groups that application flows can be members of. 891 An application flow group list contains application flow group 892 name and application flow group policy. 894 o List of Application Flows: the value is a list of the application 895 flows that are recognized by the SD-WAN. An application flow list 896 contains application flow name, list of application flow criteria, 897 and application flow group name. The criteria is listed below: 899 * Ethertype 901 * C-VLAN ID list 903 * IPv4 source address 905 * IPv4 destination address 907 * IPv4 source or destination address 908 * IPv4 protocol list 910 * IPv6 source address 912 * IPv6 destination address 914 * IPv6 source or destination address 916 * IPv6 next header list 918 * TCP/UDP source port list 920 * TCP/UDP destination port list 922 * Application identifier 924 * any 926 4.4.3. SD-WAN Endpoint Attributes 928 SD-WAN contains some endpoints as boundary nodes between underlay 929 connections and customers sites. [MEF-70] defines some attributes 930 for SD-WAN endpoints as below: 932 o Endpoint Identifier: the value is for identification of SD-WAN 933 endpoint for management purposes. 935 o Endpoint UNI: the value is for identification of the UNI that the 936 endpoint is associated with. 938 o Endpoint policy map: the value is for mapping policies to 939 application flows and application flow groups. 941 4.4.4. SD-WAN UNI Attributes 943 SD-WAN UNI is a reference point that represents the demarcation 944 between the responsibility of the customer and the responsibility of 945 the provider. Some attributes for UNI is defined in [MEF-70] as 946 below: 948 o SD-WAN UNI Identifier: the value is for identification of the UNI 949 for management purposes. 951 o SD-WAN UNI L2 Interface: the value describes the underlay L2 952 interface for the UNI. 954 o SD-WAN UNI Maximum L2 Frame Size: the value specifies the maximum 955 length L2 frame that is accepted by the provider. 957 o SD-WAN UNI IPv4 connection addressing: the value describes IPv4 958 connection address mechanisms (e.g., Static or DHCP). 960 o SD-WAN UNI IPv6 connection addressing: the value describes IPv6 961 connection address mechanisms (e.g., DHCP, SLAAC, Static or Link- 962 Local-only). 964 4.5. Radio functional splits 966 The disaggregation of the software stack in radio base stations 967 allows the centralization of some of the radio processing functions. 968 O-RAN is promoting the interoperability of implementations of radio 969 functional splits, defining an architecture where three main entities 970 can be considered: the Radio Unit (RU), with some basic processing, 971 the Distributed Unit (DU) with the rest of real-time processing 972 capabilities, and the Centralized Unit (CU) with the non-real-time 973 processing of the software stack. The network segment between RU and 974 DU is known as fronthaul (FH), while the segment between DU and CU is 975 referred as midhaul (MH). Figure 5 shows this situation. 977 ................................................. 978 : Radio functional split : 979 +-------+ : : 980 | radio | :+----+ Fronthaul +----+ Midhaul +----+ : Backhaul +-----+ 981 | base | => :| RU |<=============>| DU |<===========>| CU | :<==========>| UPF | 982 |station| :+----+ +----+ +----+ : +-----+ 983 +-------+ : : 984 : : 985 :...............................................: 987 Figure 5: Logical Transport Interfaces 989 The fronthaul leverages on eCPRI protocol which can be transported 990 directly on Ethernet frames or encapsulated in IP/UDP (for the user 991 plane). The midhaul can be transported in a similar way as the 992 backhaul. 994 With current specifications, individual service flows being carried 995 by FH cannot be distinguished, so no possibility of differentiating 996 connectivity slices at that point. Similar thing happens for MH. 997 The only possible differentiation per flow can happen in downstream 998 direction from CU to DU, but this basically can only help for 999 policing traffic at that point (i.e., slice is yet the same). 1001 Advanced scenarios such as RU sharing could allow traffic 1002 differentiation per mobile operator based on e.g. vlans, being each 1003 of those vlans mapped to a different slice. 1005 4.5.1. Attributes and procedures 1007 The attributes of IETF network slices for the conveniently supported 1008 the radio functional split are based on main characteristics of FH/ 1009 MH: Latency, BW, and packet loss, as specified in [O-RAN]. 1010 Geographical location could have an impact due to latency 1011 restrictions for FH. 1013 Regarding slice management procedures, it can be assumed a similar 1014 lifecycle as in 3GPP slices. 1016 4.6. Additional use cases 1018 This is a placeholder for describing additional use cases (e.g., data 1019 center interconnection, etc). To be completed. 1021 5. Security Considerations 1023 This draft does not include any security considerations. 1025 6. IANA Considerations 1027 This draft does not include any IANA considerations 1029 7. References 1031 7.1. Normative References 1033 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1034 Requirement Levels", BCP 14, RFC 2119, 1035 DOI 10.17487/RFC2119, March 1997, 1036 . 1038 7.2. Informative References 1040 [GSMA] "Generic Network Slice Template, version 3.0", NG.116 , 1041 May 2020. 1043 [I-D.homma-slice-provision-models] 1044 Homma, S., Nishihara, H., Miyasaka, T., Galis, A., OV, V. 1045 R., Lopez, D. R., Contreras, L. M., Ordonez-Lucena, J. A., 1046 Martinez-Julia, P., Qiang, L., Rokui, R., Ciavaglia, L., 1047 and X. D. Foy, "Network Slice Provision Models", draft- 1048 homma-slice-provision-models-02 (work in progress), 1049 November 2019. 1051 [I-D.ietf-teas-ietf-network-slice-definition] 1052 Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and 1053 J. Tantsura, "Definition of IETF Network Slices", draft- 1054 ietf-teas-ietf-network-slice-definition-01 (work in 1055 progress), February 2021. 1057 [I-D.nsdt-teas-ns-framework] 1058 Gray, E. and J. Drake, "Framework for IETF Network 1059 Slices", draft-nsdt-teas-ns-framework-05 (work in 1060 progress), February 2021. 1062 [IFA032] "IFA032 Interface and Information Model Specification for 1063 Multi-Site Connectivity Services V3.2.1.", ETSI GS NFV-IFA 1064 032 V3.2.1 , April 2019. 1066 [MEF] "Slicing for Shared 5G Fronthaul and Backhaul", MEF White 1067 paper , April 2020. 1069 [MEF-70] "SD-WAN Service Attributes and Services", MEF-70 , July 1070 2019. 1072 [O-RAN] "O-RAN Xhaul Transport Requirements 1.0", O-RAN.WG9.XTRP- 1073 REQ-v01.00 , November 2020. 1075 [TS23.251] 1076 "TS 23.251 Network Sharing; Architecture and functional 1077 description (Release 16) V16.0.0.", 3GPP TS 23.251 1078 V16.0.0 , July 2020. 1080 [TS28.530] 1081 "TS 28.530 Management and orchestration; Concepts, use 1082 cases and requirements (Release 16) V16.0.0.", 3GPP TS 1083 28.530 V16.0.0 , September 2019. 1085 [TS28.541] 1086 "TS 28.541 Management and orchestration; 5G Network 1087 Resource Model (NRM); Stage 2 and stage 3 (Release 16) 1088 V16.2.0.", 3GPP TS 28.541 V16.2.0 , September 2019. 1090 Authors' Addresses 1091 Luis M. Contreras 1092 Telefonica 1093 Ronda de la Comunicacion, s/n 1094 Sur-3 building, 3rd floor 1095 Madrid 28050 1096 Spain 1098 Email: luismiguel.contrerasmurillo@telefonica.com 1099 URI: http://lmcontreras.com/ 1101 Shunsuke Homma 1102 NTT 1103 Japan 1105 Email: shunsuke.homma.ietf@gmail.com 1107 Jose A. Ordonez-Lucena 1108 Telefonica 1109 Ronda de la Comunicacion, s/n 1110 Sur-3 building, 3rd floor 1111 Madrid 28050 1112 Spain 1114 Email: joseantonio.ordonezlucena@telefonica.com 1116 Jeff Tantsura 1117 Microsoft 1119 Email: jefftant.ietf@gmail.com 1121 Krzysztof Szarkowicz 1122 Juniper Networks 1124 Email: kszarkowicz@juniper.net