idnits 2.17.1 draft-contreras-teas-3gpp-ietf-slice-mapping-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-teas-actn-yang' is defined on line 451, but no explicit reference was found in the text == Unused Reference: 'I-D.liu-teas-transport-network-slice-yang' is defined on line 468, but no explicit reference was found in the text == Unused Reference: 'RFC8453' is defined on line 479, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-teas-actn-yang-08 == Outdated reference: A later version (-12) exists of draft-ietf-teas-ietf-network-slice-nbi-yang-01 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-08 == Outdated reference: A later version (-09) exists of draft-liu-teas-transport-network-slice-yang-05 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Informational I. Bykov 5 Expires: September 8, 2022 Ribbon Communications 6 J. Ordonez-Lucena 7 Telefonica 8 March 7, 2022 10 Connecting 3GPP slices through IETF Network Slice services 11 draft-contreras-teas-3gpp-ietf-slice-mapping-00 13 Abstract 15 3GPP is introducing the concept of slicing as a primary way of 16 service delivery. Slicing at 3GPP implies the differentiation of 17 services in terms of performance expectations as well as the 18 connection of different network entities also potentially 19 differentiated per slice. With that aim, 3GPP is defining a number 20 of logical constructs with the intent of being served with specific 21 characteristics, determined by different QoS profiles. This document 22 describes the connectivity of 3GPP slices through IETF Network Slice 23 services taking into account that specific service level objectives, 24 and identifies gaps existing nowadays on both 3GPP and IETF 25 specifications for an straightforward mapping of parameters between 26 both environments. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 8, 2022. 45 Copyright Notice 47 Copyright (c) 2022 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Conventions used in this document . . . . . . . . . . . . . . 3 64 3. Network slicing artifacts at 3GPP . . . . . . . . . . . . . . 3 65 4. IETF network slice service . . . . . . . . . . . . . . . . . 6 66 5. Mapping of 3GPP slice and IETF network slice endpoints . . . 6 67 5.1. Mapping EP_transport to IETF NS CE endpoints . . . . . . 7 68 5.2. Mapping IETF NS CE to PE endpoints . . . . . . . . . . . 8 69 6. Discussion on the realization of 3GPP slices through IETF 70 Network Slice services . . . . . . . . . . . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 77 1. Introduction 79 Editor's Note: the terminology in this draft will be aligned with the 80 final terminology defined in [I-D.ietf-teas-ietf-network-slices]. 82 Network slicing intends to provide network capabilities tailored to 83 specific service expectations. 3GPP has been a precursor of the 84 slicing concept conceiving the 5G architecture that natively supports 85 slicing. 87 3GPP network slices require then tailored connectivity services to 88 interconnect 3GPP network entities with the expected behavior and 89 footprint. For doing so, it is expected that 3GPP higher management 90 system will require IETF Network Slice services to an IETF Network 91 Slice Controller, as defined in [I-D.ietf-teas-ietf-network-slices]. 93 The NBI model in [I-D.ietf-teas-ietf-network-slice-nbi-yang] is 94 working on the definition of a technology agnostic model with the aim 95 of permitting the flexible provision of IETF Network Slices. Being 96 this a work in progress it is useful and convenient to exercise the 97 mapping of the 3GPP constructs defined for interconnecting 3GPP slice 98 parts with the IETF model for that purpose, then identifying gaps 99 that could be reported back into the corresponding specification 100 fora. 102 2. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC2119 [RFC2119]. 108 3. Network slicing artifacts at 3GPP 110 The network slice concept was present in 3GPP specifications from the 111 first 5G release (Rel-15). As captured in [TS23.501], a network 112 slice represents a logical network providing specific network 113 capabilities and network characteristics. 115 To make slicing a reality, every technical domain is split into one 116 or more logical network partitions, each referred to as a network 117 slice subnet. The definition of multiple slice subnets on a single 118 domain allows this segment to provide differentiated behaviors, in 119 terms of functionality and/or performance. The stitching of slice 120 subnets across the RAN, CN and TN results in the definition of 121 network slices. 123 From a management viewpoint, the concept of network slice subnet 124 represents an independently manageable yet composable portion of a 125 network slice. The rules for the definition of network slice subnets 126 and their composition into network slices are detailed in the 5G 127 Network Resource Model (NRM) [TS28.541], specifically in the Network 128 Slice NRM fragment. This fragment captures the information model of 129 5G network slicing, which specifies the relationships between 130 different slicing related managed entities, each represented as a 131 separate Information Object Class (IOC). An IOC captures the 132 semantics and attributes of a manageable entity; in other words, it 133 defines the class based on which instances (objects) from this entity 134 can be created. In the model, we have four different IOCs: 136 o NetworkSlice IOC, representing a network slice. This IOC is 137 associated with one or more ServiceProfiles, each representing the 138 requirements of a particular service. The 1:N relationship of 139 NetworkSlice IOC with the ServiceProfile is because one network 140 slice can host multiple services, as long as they do not impose 141 conflicting requirements. 143 o NetworkSliceSubnet IOC, associated with a network slice subnet. 144 This IOC is associated with one or more SliceProfiles. 146 o ManagedFunction IOC, which represents a 5G network function. 148 o EP_Transport IOC, which represents an interface associated with 149 transport network level information, e.g., transport address, 150 reachability information, and QoS profiles. 152 For the transport related part of a network slice, the key focus is 153 on EP_Transport IOC. Instances of this IOC servesto instantiate 3GPP 154 interfaces which are needed to support Network Slicing and to define 155 Network Slice transport resources within the 5G NRM. In a nutshell, 156 the EP_Transport IOC permits to define additional logical interfaces 157 for each slice instance of the 3GPP user plane. 159 According to [TS28.541], the EP_Transport construct on 3GPP side has 160 the following attributes: 162 o ipAddress (mandatory): specifies the IP address asigned to the 163 logical transport interface. It is used for transport routing. 164 Assigned uniquely per slice. As per [TS28.541] IP address is 165 defined as an IPv4 address or an IPv6 address. The concern is 166 that for the coherent networking, IP address should be assigned to 167 the interface with a network mask, to form an IPv4 or IPv6 prefix. 169 o logicInterfaceInfo (mandatory): a set of parameters, which 170 includes logicInterfaceType and logicInterfaceId. It specifies 171 the type and identifier of a logical interface. It could be a 172 VLAN ID, MPLS Tag or Segment ID. This is assigned uniquely per 173 slice. 175 o nextHopInfo (optional): identifies the ingress transport node. 176 Each node can be identified by any combination of IP address of 177 next-hop router of transport network, system name, port name and 178 IP management addresses of transport nodes. 180 o qosProfile (optional): specifies the set of QoS parameters which 181 are logically provisioned on both sides on a logical transport 182 interface. This is assigned uniquely per slice. 184 o epApplicationRef (mandatory): specifies the list of application 185 endpoints associated with the logical transport interface. May be 186 assigned multiple per slice. Used to maintain association with 187 corresponding 3GPP logical interface (NgU (N3), F1_U), to which 188 EP_Transport is related to. Notice that one EP_Transport 189 (representing a logical transport interface) can be associated 190 with more than one multiple EP_Application (representing an 191 application endpoint of a 3GPP managed function), but also the 192 other way around. While the first case captures the typical 193 situation, the second case can be used for the sake of resilience 194 or load balance in the transport network. 196 From the Transport Network domain side, these parameters define CE 197 transport interface configuration and shall be taken as an input to 198 the transport service model to create coherent Network Slice 199 transport service. 201 According to the [TS28.541] attributes in the EP_Transport, the IETF 202 Network Slice may be defined by the following combination of the 203 parameters: 205 +------------------------------------------------------------------+ 206 | EP_Transport attribute name | 207 | | 208 +---------------+----------------+----------------+----------------+ 209 | ipAddress |logicInterfaceId| nextHopInfo | qosProfile | 210 +---------------+----------------+----------------+----------------+ 211 | Different | Same for all | 212 | per slice | slices | 213 +---------------+---------------------------------+----------------+ 214 | Same for all | Different | Same for all | 215 | slices | per slice | slices | 216 +---------------+----------------+----------------+----------------+ 217 | Different | Same for all | Different | Same for all | 218 | per slice | slices | per slice | slices | 219 +---------------+----------------+----------------+----------------+ 220 | Same for all | Different | Same for all | 221 | slices | per slice | slices | 222 +--------------------------------+----------------+----------------+ 223 | Different | 224 | per slice | 225 +---------------+--------------------------------------------------+ 226 | Same for all | Different | 227 | slices | per slice | 228 +---------------+--------------------------------------------------+ 230 Figure 1: Table_name 232 From the perspective of IETF Network Slcie realization, some of these 233 options could be realized in a straightforward manner while other 234 could require of advanced features (e.g., PBR, SRv6, FlexE, etc). 236 4. IETF network slice service 238 The IETF Network Slice (NS) service is defined in 239 [I-D.ietf-teas-ietf-network-slices] as a set of connections between a 240 number of CEs, with that connections having specific Service Level 241 Objectives (SLOs) and Service Level Expectations (SLEs) over a common 242 underlay network, with the traffic of one customer being separated 243 from another. The concept of IETF network slice is conceived as 244 technology agnostic. 246 The IETF NS service is specified in terms of the set of endpoints 247 (from CE perspective) connected to the slice, the type of 248 connectivity among them, and a set of SLOs and SLEs for each 249 connectivity construct. 251 In [I-D.ietf-teas-ietf-network-slice-nbi-yang] the endpoints are 252 described by an identifier, with some metrics associated to the 253 connections among them as well as certain policies (e.g., rate limits 254 for incoming and outgoing traffic). 256 5. Mapping of 3GPP slice and IETF network slice endpoints 258 At the time of provisioning a 3GPP slice, it is required to provide 259 slice connectivity constructs by means of IETF network slices. Then 260 it is necessary to bind two different endpoints, as depicted in 261 Figure 2: 263 o Mapping of EP_Transport (as defined by [TS28.541]) to the endpoint 264 at the CE side of the IETF network slice. This is necessary 265 because the IETF Network Slice Controller (NSC) will receive as 266 input for the IETF network slice service the set of endpoints at 267 CE side to be interconnected. 269 o Mapping of the endpoints at both CE and PE side. The endpoint at 270 PE side should be elicited by some means by the NSC, in order to 271 establish and set up the connectivity construct intended for the 272 customer slice request, according to the SLOs and SLEs received 273 from the higher level system. 275 3GPP concern 277 ----------- --------- 278 / / 279 / / 280 O EP_Transport_left EP_Transport_right O 281 /A /A 282 / | / | 283 ----- | ---|------- 284 | | 285 | | 286 .......|............................................|.......... 287 | | 288 | | 289 | | 290 -------|-- ---------- ---------- | ------- 291 | / / / ____ / / | / 292 V/ / / ( ) / / V/ 293 O<---->O 0==( )==0 O<---->O 294 / / / (____) / / / 295 / / / / / / 296 ----- ---------- ---------- ---------- 297 CE_left PE_left PE_right CE_right 299 IETF concern 301 Figure 2: Title to be added 303 5.1. Mapping EP_transport to IETF NS CE endpoints 305 The 3GPP Management system provides the EP_Transport IOC to extend 306 the slice awareness to the transport network. The EP_Transport IOC 307 contains parameters as IP address, additional identifiers (i.e., vlan 308 tag, MPLS label, etc), and associated QoS profile. This IOC is 309 related to the endpoints of the 3GPP managed functions 310 (EP_Application IOC). 312 The information captured in the EP_Transport IOC (3GPP concern) 313 should be translated into the CE related parameters (IETF concern). 314 There will be cases where such translation is straightforward, as for 315 instance, when the 3GPP managed functions run on monolithic, purpose- 316 specific network elements, in the way that the IP address attribute 317 from the EP_Transport IOC is the IP address of an interface of the 318 network element. In this case, the information on EP_Transport IOC 319 can be directly passed to the IETF NSC through the NBI, even though 320 some additional information could be yet required, not being defined 321 yet on 3GPP specifications (e.g., the mask applicable to the IP 322 address field on EP_Transport). 324 However, there could be other cases where such a relationship is not 325 straightforward. This could be the case of virtualized 3GPP managed 326 functions that could be instantiated on a general-purpose network 327 element. In these other cases it is necessary to define additional 328 means for eliciting the endpoint at the CE side corresponding to the 329 endpoint of the 3GPP-related function. 331 With solely EP_Transport characterization in 3GPP, we could expect 332 the NS CE endpoint being identified by a combination of IP address 333 and some additional information such as vlan tag or SRv6 label that 334 could discriminate against a certain logical interface. The next hop 335 router information is related to the next hop view from the 336 perspective of the 3GPP entity part of the slice, then providing 337 hints for determining the slice endpoint at the other side of the 338 slice service. Finally, the QoS profile helps to determine 339 configurations needed at the PE side to respect the SLOs in the 340 connection between CEs slice endpoints. 342 5.2. Mapping IETF NS CE to PE endpoints 344 As described in [I-D.ietf-teas-ietf-network-slices], there are 345 different potential endpoint positions for an IETF NS. 347 |<---------------------- (1) ---------------------->| 348 | | 349 | |<-------------------- (2) -------------------->| | 350 | | | | 351 | | |<----------- (3) ----------->| | | 352 | | | | | | 353 | | | |<-------- (4) -------->| | | | 354 | | | | | | | | 355 V V AC V V V V AC V V 356 +-----+ | +-----+ +-----+ | +-----+ 357 | |--------| | | |--------| | 358 | CE1 | | | PE1 |. . . . . . . . .| PE2 | | | CE2 | 359 | |--------| | | |--------| | 360 +-----+ | +-----+ +-----+ | +-----+ 361 ^ ^ ^ ^ 362 | | | | 363 | | | | 364 Customer Provider Provider Customer 365 Edge 1 Edge 1 Edge 2 Edge 2 367 Figure 3: IETF Network Slice endpoints 369 The information that is passed to the IETF NSC in terms of endpoints 370 is the information relative to the CE position, which is the one 371 known by the slice customer. From that information, the NSC needs to 372 infer the corresponding endpoint position at PE side, in order to 373 setup the desired connectivity constructs with the SLOs indicated in 374 the request. 376 Being slice request technology-agnostic, the identification of the 377 slice endpoints at the PE side should leverage on generic information 378 passed through the NBI to the IETF NSC. 380 6. Discussion on the realization of 3GPP slices through IETF Network 381 Slice services 383 The way in which 3GPP is characterizing the slice endpoint (i.e., 384 EP_Transport) is based on Layer 3 information (e.g., the IP Address). 385 However the information provided seems not to be sufficient for 386 instructing the IETF Network Slice Controller for the realization of 387 the IETF NEtwork Slice. For instance, some basic information such as 388 the mask associated to the IP address of the EP_Transport is not 389 specified, as well as other kind of parameters like the connection 390 MTU or the connectivity type (unicast, multicast, etc). More 391 sophisticated information could be required as well, like the level 392 of isolation or protection necessary for the intended slice. 394 In the case in which the 3GPP managed function runs on a purpose- 395 specific network element, the IP address specified in the 396 EP_Transport IOC serves as reference to identify the CE endpoint, 397 assuming the endpoint of the CE has been configured with that IP 398 address. With that information (together with the logical interface 399 ID) should be sufficient for the IETF NSC to identify the counterpart 400 endpoint at the PE side, and configuring it accordingly (e.g., with a 401 compatible IP address) for setting up the slice end-to-end. 402 Similarly, the next hop information in EP_Transport can help validate 403 the end-to-end slice between PE endpoints. 405 In the case in which the 3GPP managed function is instantiated as a 406 virtualized network function, the direct association between the IP 407 address of EP_Transport and the actual endpoint mapped at the CE is 408 not so clear. It could be the case, for instance when the 409 virtualized network function is instantiated at the internal of a 410 data center, that the CE facing the PE is far from the point where 411 the function is deployed, being that connectivity extended through 412 the internals of the data center (or by some internal configuration 413 of a virtual switch in a server). In these situations additional 414 information is needed for accomplishing the end-to-end connection. 416 At the same time, [TS28.541] IOC contains useful parameters to be 417 used in IETF Network Slice creation mechanism and enreaching IETF 418 Network Slice model. The following parameters may be suggested as a 419 candidates to the correlation of the IETF Network Slice parameters 420 and IETF Network Slice model enreachments: 422 o For the latency, dLThptPerSliceSubnet, uLThptPerSliceSubnet, 423 reliability and delayTolerance attributes, the following NRM apply 424 (with reference to the section in that specification): 426 * CNSliceSubnetProfile (section 6.3.22 in [TS28.541]) 428 * RANSliceSubnetProfile (section 6.3.23 in [TS28.541]) 430 * TopSliceSubnetProfile (section 6.3.24 in [TS28.541]) 432 o For the qosProfile attribute, the NRM which applies is 433 EP_Transport (detailed in section 6.3.17 in [TS28.541]) 435 7. Security Considerations 437 To be done. 439 8. IANA Considerations 441 This draft does not include any IANA considerations 443 9. Acknowledgements 445 The work of Luis M. Contreras has been partially funded by the 446 European Commission under Horizon 2020 project Int5Gent (grant 447 agreement 957403). 449 10. References 451 [I-D.ietf-teas-actn-yang] 452 Lee, Y., Zheng, H., Ceccarelli, D., Yoon, B. Y., and S. 453 Belotti, "Applicability of YANG models for Abstraction and 454 Control of Traffic Engineered Networks", draft-ietf-teas- 455 actn-yang-08 (work in progress), September 2021. 457 [I-D.ietf-teas-ietf-network-slice-nbi-yang] 458 Wu, B., Dhody, D., Rokui, R., Saad, T., and L. Han, "IETF 459 Network Slice Service YANG Model", draft-ietf-teas-ietf- 460 network-slice-nbi-yang-01 (work in progress), March 2022. 462 [I-D.ietf-teas-ietf-network-slices] 463 Farrel, A., Drake, J., Rokui, R., Homma, S., Makhijani, 464 K., Contreras, L. M., and J. Tantsura, "Framework for IETF 465 Network Slices", draft-ietf-teas-ietf-network-slices-08 466 (work in progress), March 2022. 468 [I-D.liu-teas-transport-network-slice-yang] 469 Liu, X., Tantsura, J., Bryskin, I., Contreras, L. M., Wu, 470 Q., Belotti, S., and R. Rokui, "IETF Network Slice YANG 471 Data Model", draft-liu-teas-transport-network-slice- 472 yang-05 (work in progress), March 2022. 474 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 475 Requirement Levels", BCP 14, RFC 2119, 476 DOI 10.17487/RFC2119, March 1997, 477 . 479 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 480 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 481 DOI 10.17487/RFC8453, August 2018, 482 . 484 [TS23.501] 485 "System architecture for the 5G System (5GS)", 3GPP TS 486 23.501 V16.11.0 , December 2021. 488 [TS28.541] 489 "5G Network Resource Model (NRM)", 3GPP TS 28.541 490 V16.11.0 , December 2021. 492 Authors' Addresses 494 Luis M. Contreras 495 Telefonica 496 Ronda de la Comunicacion, s/n 497 Sur-3 building, 3rd floor 498 Madrid 28050 499 Spain 501 Email: luismiguel.contrerasmurillo@telefonica.com 502 URI: http://lmcontreras.com/ 503 Ivan Bykov 504 Ribbon Communications 505 30 Hasivim Street 506 Petah Tikva 4959388 507 Israel 509 Email: Ivan.Bykov@rbbn.com 511 Jose Ordonez-Lucena 512 Telefonica 513 Ronda de la Comunicacion, s/n 514 Sur-3 building, 3rd floor 515 Madrid 28050 516 Spain 518 Email: joseantonio.ordonezlucena@telefonica.com