idnits 2.17.1 draft-geng-teas-network-slice-mapping-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 15 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 (25 October 2021) is 906 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-teas-ietf-network-slice-definition' is defined on line 695, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-contreras-teas-slice-nbi-05 == Outdated reference: A later version (-25) exists of draft-ietf-teas-ietf-network-slices-04 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Geng 3 Internet-Draft J. Dong 4 Intended status: Informational Huawei Technologies 5 Expires: 28 April 2022 R. Pang 6 China Unicom 7 L. Han 8 China Mobile 9 R. Rokui 10 Nokia 11 T. Niwa 12 Individual 13 J. Jin 14 LG U+ 15 C. Liu 16 China Unicom 17 N. Nageshar 18 Individual 19 25 October 2021 21 5G End-to-end Network Slice Mapping from the view of Transport Network 22 draft-geng-teas-network-slice-mapping-04 24 Abstract 26 Network Slicing is one of the core features in 5G. End-to-end 27 network slice consists of 3 major types of network segments: Access 28 Network (AN), Mobile Core Network (CN) and Transport Network (TN). 29 This draft describes the procedure of mapping 5G end-to-end network 30 slice to transport network slice defined in IETF. This draft also 31 intends to expose some gaps in the existing network management plane 32 and data plane technologies to support inter-domain network slice 33 mapping. Further work may require collaboration between IETF and 34 3GPP (or other standard organizations). Data model specification, 35 signaling protocol extension and new encapsulation definition are out 36 of the scope of this draft. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 42 document are to be interpreted as described in RFC 2119 [RFC2119]. 44 Status of This Memo 46 This Internet-Draft is submitted in full conformance with the 47 provisions of BCP 78 and BCP 79. 49 Internet-Drafts are working documents of the Internet Engineering 50 Task Force (IETF). Note that other groups may also distribute 51 working documents as Internet-Drafts. The list of current Internet- 52 Drafts is at https://datatracker.ietf.org/drafts/current/. 54 Internet-Drafts are draft documents valid for a maximum of six months 55 and may be updated, replaced, or obsoleted by other documents at any 56 time. It is inappropriate to use Internet-Drafts as reference 57 material or to cite them other than as "work in progress." 59 This Internet-Draft will expire on 28 April 2022. 61 Copyright Notice 63 Copyright (c) 2021 IETF Trust and the persons identified as the 64 document authors. All rights reserved. 66 This document is subject to BCP 78 and the IETF Trust's Legal 67 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 68 license-info) in effect on the date of publication of this document. 69 Please review these documents carefully, as they describe your rights 70 and restrictions with respect to this document. Code Components 71 extracted from this document must include Simplified BSD License text 72 as described in Section 4.e of the Trust Legal Provisions and are 73 provided without warranty as described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 79 3. 5G End-to-End Network Slice Identification . . . . . . . . . 4 80 4. Network Slice Mapping Structure . . . . . . . . . . . . . . . 5 81 5. Network Slice Mapping Procedure . . . . . . . . . . . . . . . 8 82 5.1. Network Slice Mapping in Management Plane . . . . . . . . 9 83 5.2. Network Slice Mapping in Control Plane . . . . . . . . . 10 84 5.3. Network Slice Mapping in Data Plane . . . . . . . . . . . 10 85 5.3.1. Data Plane Mapping Considerations . . . . . . . . . . 10 86 5.3.2. Data Plane Mapping Options . . . . . . . . . . . . . 11 87 6. Network Slice Mapping Summary . . . . . . . . . . . . . . . . 15 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 91 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 94 1. Introduction 96 Driven by the new applications of 5G, the concept of network slicing 97 is defined to provide a logical network with specific capabilities 98 and characteristics. Network slice contains a set of network 99 functions and allocated resources(e.g. computation, storage and 100 network resources). According to [TS28530], a 5G end-to-end network 101 slice is composed of three major types network segments: Radio Access 102 Network (RAN), Transport Network (TN) and Mobile Core Network (CN). 103 Transport network is supposed to provide the required connectivity 104 between AN and CN, with specific performance commitment. For each 105 end-to-end network slice, the topology and performance requirement 106 for transport network can be very different, which requests transport 107 network to have the capability of supporting multiple different 108 transport network slices. 110 The concept of IETF network slice is discussed in 111 [I-D.ietf-teas-ietf-network-slices]. In summary, an IETF Network 112 Slice is a logical network topology connecting a number of endpoints 113 using a set of shared or dedicated network resources that are used to 114 satisfy specific Service Level Objectives SLOs) and Service Level 115 Expectations (SLEs). 117 The realization of an IETF network slices in Transport network (TN) 118 could span multiple technology (e.g., IP/MPLS, Optical) and multiple 119 administrative domains. Depending on the consumer's requirement, an 120 IETF network slice could be isolated from other concurrent IETF 121 network slices, in terms of data plane, control plane and management 122 plane. The procedure for lifecycle of an end-to-end network slice 123 instance (i.e., creation, deletion, modificatinon, termination etc.) 124 is defined in [TS28531]. End-to-end network slicing provisioning is 125 specified in ETSI [ZSM003]. But there is no specifications about how 126 to map end-to-end network slice to IETF network slices in Transport 127 Network (TN). This draft describes the procedure of mapping the 5G 128 end-to-end network slice to IETF network slices in management plane, 129 control plane and data plane. 131 2. Terminologies 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]. 137 The following terms are used in this document: 139 NSC: IETF Network Slice Controller 141 NSI: Network Slice Instance 142 NSSI: Network Slice Subnet Instance 144 S-NSSAI: Single Network Slice Selection Assistance Information 146 AN: Access Network 148 RAN: Radio Access Network 150 TN: Transport Network 152 CN: Mobile Core Network 154 DSCP: Differentiated Services Code Point 156 CSMF: Communication Service Management Function 158 NSMF: Network Slice Management Function 160 NSSMF: Network Slice Subnet Management Function 162 3. 5G End-to-End Network Slice Identification 164 The following figure illustrates a typical mobile network with three 165 5G e2e network slices. Each e2e network slice contains AN slice, CN 166 slice and one or more IETF network Slices. 3GPP identifies each e2e 167 network slice using an integer called S-NSSAI. In Figure-1 there are 168 three instances of e2e network slices which are identified by S-NSSAI 169 01111111, 02222222 and 02333333, respectively. Each instance of e2e 170 network slice contains AN slice, CN Slice and one or more IETF 171 network slices. For example, e2e network slice 01111111 has AN Slice 172 instance 4, CN Slice instance 1 and IETF network slice 6. Note that 173 3GPP does not cover the IETF network slice. See [I-D.ietf-teas-ietf- 174 network-slices] for details of IETF network slice. 176 Note that 3GPP uses the terms NSI and NSSI which are a set of network 177 function and required resources (e.g. compute, storage and networking 178 resources) which corresponds to network slice Instance, whereas 179 S-NSSAI is an integer that identifies the e2e network slice. 181 +-----------+ +-----------+ +-----------+ 182 | S-NSSAI | | S-NSSAI | | S-NSSAI | 183 | 01111111 | | 02222222 | | 03333333 | 184 +---|-------+ +---|---|---+ +----|------+ 185 | +----------+ | | 186 V V V V 187 ******* ******** ******** 188 Core * NSSI 1 * * NSSI 2 * * NSSI 3 * 189 Network ******** ******** ******** 190 \ \ / 191 \ \ / 192 +-----+ +-----+ +-----+ 193 Transport | IETF| | IETF| | IETF| 194 Network | NS 6| | NS 7| | NS 8| 195 +-----+ +-----+ +-----+ 196 \ \ / 197 \ \ / 198 ******** ******** 199 Access * NSSI 4 * * NSSI 5 * 200 Network ******** ******** 202 Figure 1 5G End-to-End Network Slice and its components 204 4. Network Slice Mapping Structure 206 Referring to 3GPP TR 28.801, the management of 5G e2e network slices 207 from 3GPP view is shown in Figure-2(A). Figure-2(B) illustrates the 208 view of IETF and how it maps to 3GPP network slice management. In 209 particular, the IETF network slice controller (NSC) is equivalent to 210 3GPP TN NSSMF and functional block "Consumer" at IETF is equivalent 211 to 3GPP NSMF. 213 +-----------------+ 214 | NSMF | 215 +-----------------+ 216 +----------| S-NSSAI |----------+ 217 | |(e.g. 011111111) | | 218 | +-----------------+ | 219 | | | 220 V V V 221 +-------------+ +---------------------+ +-------------+ 222 | AN NSSMF | | IETF NSC | | CN NSSMF | 223 +-------------+ +---------------------+ +-------------+ 224 | AN Slice | | IETF Network Slice | | CN Slice | 225 | Identifier | | Identifier | | Identifier | 226 | (e.g., 4) | | (e.g., 6) | | (e.g., 1) | Management 227 +-------------+ +---------------------+ +-------------+ Plane 228 | | | | ----------------- 229 | | | | 230 V V V V ----------------- 231 /\ +-----+ +-----+ +-------+ Data 232 /AN\ -----| PE |-----...-----| PE |----| CN | Plane 233 /____\ +-----+ +-----+ +-------+ 235 Note: Refer to Figure-1 for S-NSSAI 01111111, AN, CN and IETF networks slices 4,6 and 1 237 Figure-2 Relation between IETF and 3GPP Network Slice management 239 The following figure shows the necessary elements for mapping end-to- 240 end network slice into IETF network slices. 242 +---------------------+ 243 | CSMF | 244 +----------|----------+ 245 | +------------------------+ 246 +---------------------+ | 5G E2E Network Slice | 247 | NSMF | | Orchestrator | 248 +---------------------+ +------------------------+ 249 / | \ | 250 / | \ NSC NBI | 251 / | \ | 252 +---------++---------++---------+ +------------------------+ 253 | AN || TN || CN | | IETF Network Slice | 254 | NSSMF || NSSMF || NSSMF | | Controller (NSC) | 255 | || || | +------------------------+ 256 +---------++---------++---------+ NSC SBI | 257 | | | | 258 | | | +------------------------+ 259 | | | | Network Controllers | 260 | | | +------------------------+ 261 | | | | 262 | | | | 263 ****** ****** ****** ****** 264 * 5G * * IETF * * 5G * * IETF * 265 * RAN * * Network* * Core * * Network* 266 * * * * * * * * 267 ****** ****** ****** ****** 269 Figure-3 5G E2E Network Slice Mapping Structure 271 The following network slice related identifiers in management plane, 272 control plane and data(user) plane play an important role in end-to- 273 end network slice mapping. 275 * Single Network Slice Selection Assistance Information(S-NSSAI): 276 The end-to-end network slice identifier, which is defined in 277 [TS23501]; S-NSSAI is used during 3GPP network slice signalling 278 process. 280 * IETF Network Slice Identifier: An identifier allocated by IETF 281 Neetwork Slice Controller (NSC) in management plane. In data 282 plane, IETF Network Slice Identifier may be instantiated with 283 existing data plane identifiers and doesn't necessarily require 284 new encapsulation. 286 * IETF Network Slice Interworking Identifier: Data-plane network 287 slice identifier which is used for mapping the end-to-end network 288 slice traffic to specific IETF network slice. The IETF Network 289 Slice Interworking Identifier is a new concept introduced by this 290 draft, which may be instantiated with existing data plane 291 identifiers and doesn't necessarily require new encapsulation. 293 The relationship between these identifiers are specifies in the 294 following sections. 296 5. Network Slice Mapping Procedure 298 This section provides a general procedure of network slice mapping: 300 1. NSMF receives the request from CSMF for allocation of a network 301 slice instance with certain characteristics. 303 2. Based on the service requirement , NSMF acquires requirements for 304 the end-to-end network slice instance , which is defined in Service 305 Profile([TS28541] section 6.3.3). 307 3. Based on Service Profile, NSMF identified the network function 308 and the required resources in AN, CN and TN networks. It also 309 assigns the unique ID S-NSSAI. 311 4. NSMF sends a request to AN NSSMF for creation of AN Slice. 313 5. NSMF sends a request to CN NSSMF for creation of CN Slice. 315 6. NSMF sends a request to IETF Network Slice Controller (NSC) for 316 creation of IETF Network Slice. The request contains such attribute 317 such as endpoints, required SLA/SLO along with other IETF network 318 slice attributes. It also cotains mapping informatin for IETF 319 Network Slice Interworking Identifier. 321 7. NSC realizes the IETF network slice which satisfies the 322 requirement of IETF network slice between the specified endpoints 323 (AN/ CN edge nodes). It assigns sliceID and send it to NSMF. 325 8. NSMF has the mapping relationship between S-NSSAI and IETF 326 Network Slice ID; 328 9. When the User Equipment (UE) appears, and during the 5G 329 signalling, it requests to be connected to specific e2e network slice 330 identified by S-NASSI. Then a GTP tunnel (which is UDP/IP) will be 331 created. 333 10. UE starts sending traffic in context of e2e network slice for 334 specific S-NASSI. 336 11. In context of GTP tunnel, the AN edge nodes encapsulates the 337 packet with sliceIID according to the selected S-NSSAI ans send it to 338 the transport network. 340 12. The transport network edge node receives the IP packet and 341 parses the sliceIID from the packet and maps the packet to the 342 corresponding IETF network slice. It may encapsulate packet with 343 sliceID if needed (for example for enforcing QoS in transport 344 network). 346 5.1. Network Slice Mapping in Management Plane 348 The transport network management Plane maintains the interface 349 between NSMF and TN NSSMF, which 1) guarantees that IETF network 350 slice could connect the AN and CN with specified characteristics that 351 satisfy the requirements of communication; 2) builds up the mapping 352 relationship between NSI identifier and TN NSSI identifier; 3) 353 maintains the end-to-end slice relevant functions; 355 Service Profile defined in[TS28541] represents the requirement of 356 end-to-end network slice instance in 5G network. Parameters defined 357 in Service Profile include Latency, resource sharing level, 358 availability and so on. How to decompose the end-to-end requirement 359 to the transport network requirement is one of the key issues in 360 Network slice requirement mapping. GSMA(Global System for Mobile 361 Communications Association) defines the [GST] to indicate the network 362 slice requirement from the view of service provider. 363 [I-D.contreras-teas-slice-nbi] analysis the parameters of GST and 364 categorize the parameters into three classes, including the 365 attributes with direct impact on the IETF network slice definition. 366 It is a good start for selecting the transport network relevant 367 parameters in order to define Network Slice Profile for Transport 368 Network. Network slice requirement parameters are also necessary for 369 the definition of transport network northbound interface. 371 Inside the TN NSSMF, it is supposed to maintain the attributes of the 372 IETF network slice. If the attributes of an existing TN NSSI could 373 satisfy the requirement from TN Network Slice Profile, the existing 374 TN NSSI could be selected and the mapping is finished If there is no 375 existing TN NSSI which could satisfy the requirement, a new TN NSSI 376 is supposed to be created by the NSSMF with new attributes. 378 TN NSSI resource reservation should be considered to avoid over 379 allocation from multiple requests from NSMF (but the detailed 380 mechanism should be out of scope in the draft) 381 TN NSSMF sends the selected or newly allocated TN NSSI identifier to 382 NSMF. The mapping relationship between NSI identifier and TN NSSI 383 identifier is maintained in both NSMF and TN NSSMF. 385 YANG data model for the Transport Slice NBI, which could be used by a 386 higher level system which is the Transport slice consumer of a 387 Transport Slice Controller (TSC) to request, configure, and manage 388 the components of a transport slices, is defined in 389 [I-D.wd-teas-transport-slice-yang]. The northbound Interface of IETF 390 network slice refers to [I-D.wd-teas-ietf-network-slice-nbi-yang]. 392 5.2. Network Slice Mapping in Control Plane 394 There is no explicit interaction between transport network and AN/CN 395 in the control plane, but the S-NSSAI defined in [TS23501] is treated 396 as the end-to-end network slice identifier in the control plane of AN 397 and CN, which is used in UE registration and PDU session setup. In 398 this draft, we assume that there is mapping relationship between 399 S-NSSAI and NSI in the management plane, thus it could be mapped to a 400 IETF network slice . 402 Editor's note: The mapping relationship between NSI defined in 403 [TS23501] and S-NSSAI defined in [TS23501] is still in discussion. 405 5.3. Network Slice Mapping in Data Plane 407 If multiple network slices are carried through one physical interface 408 between AN/CN and TN, IETF Network Slice Interworking ID in the data 409 plane needs to be introduced. If different network slices are 410 transported through different physical interfaces, Network Slices 411 could be distinguished by the interface directly. Thus IETF Network 412 Slice Interworking ID is not the only option for network slice 413 mapping, while it may help in introducing new network slices. 415 5.3.1. Data Plane Mapping Considerations 417 The mapping relationship between AN or CN network slice identifier 418 (either S-NSSAI in control plane or NSI/NSSI in management plane) and 419 IETF Network Slice Interworking ID needs to be maintained in AN/CN 420 network nodes, and the mapping relationship between IETF Network 421 Slice Interworking ID and IETF Network Slice is maintained in the 422 edge node of transport network. When the packet of a uplink flow 423 goes from AN to TN, the packet is encapsulated based on the IETF 424 Network Slice Interworking ID; then the encapsulation of IETF Network 425 Slice Interworking ID is read by the edge node of transport network, 426 which maps the packet to the corresponding IETF network slice. 428 Editor's Note: We have considered to add "Network Instance" defined 429 in [TS23501]in the draft. However, after the discussion with 3GPP 430 people, we think the concept of "network instance" is a 'neither 431 Necessary nor Sufficient Condition' for network slice. Network 432 Instance could be determined by S-NSSAI, it could also depends on 433 other information; Network slice could also be allocated without 434 network instance (in my understanding) And, IETF Network Slice 435 Interworking ID is not a competitive concept with network 436 instance.IETF Network Slice Interworking ID is a concept for the data 437 plane interconnection with transport network, network instance may be 438 used by AN and CN nodes to associate a network slice with IETF 439 Network Slice Interworking ID 441 5.3.2. Data Plane Mapping Options 443 The following picture shows the end-to-end network slice in data 444 plane: 446 +--+ +-----+ +----------------+ 447 |UE|- - - -|(R)AN|---------------------------| UPF | 448 +--+ +-----+ +----------------+ 449 |<----AN NS---->|<----------TN NS---------->|<----CN NS----->| 451 The mapping between 3GPP slice and transport slice in user plane 452 could happens in: 454 (R)AN: User data goes from (radio) access network to transport 455 network 457 UPF: User data goes from core network functions to transport network 459 Editor's Note: As figure 4.7.1. in [TS28530] describes, TN NS will 460 not only exist between AN and CN but may also within AN NS and CN NS. 461 However, here we just show the TN between AN and CN as an example to 462 avoid unncessary complexity. 464 The following picture shows the user plane protocol stack in end-to- 465 end 5G system. 467 +-----------+ | | | 468 |Application+--------------------|------------------|---------------| 469 +-----------+ | | +-----------+ | 470 | PDU Layer +--------------------|------------------|-| PDU Layer | | 471 +-----------+ +-------------+ | +-------------+ | +-----------+ | 472 | | | ___Relay___ |--|--| ___Relay___ |-|-| | | 473 | | | \/ GTP-U|--|--|GTP-U\/ GTP-U|-|-| GTP-U | | 474 | 5G-AN | |5G-AN +------+ | +------+------+ | +-----------+ | 475 | Protocol | |Protoc|UDP/IP|--|--|UDP/IP|UDP/IP|-|-| UDP/IP | | 476 | Layers | |Layers+------+ | +------+------+ | +-----------+ | 477 | | | | L2 |--|--| L2 | L2 |-|-| L2 | | 478 | | | +------+ | +------+------+ | +-----------+ | 479 | | | | L1 |--|--| L1 | L1 |-|-| L1 | | 480 +-----------+ +-------------+ | +-------------+ | +-----------+ | 481 UE 5G-AN | UPF | UPF | 482 N3 N9 N6 484 The following figure shows the typical encapsulation in N3 interface 485 which could be used to carry the IETF Network Slice Interworking ID 486 between AN/CN and TN. 488 +------------------------+ 489 | Application Protocols | 490 +------------------------+ 491 | IP (User) | 492 +------------------------+ 493 | GTP | 494 +------------------------+ 495 | UDP | 496 +------------------------+ 497 | IP | 498 +------------------------+ 499 | Ethernet | 500 +------------------------+ 502 5.3.2.1. Layer 3 and Layer 2 Encapsulations 504 If the encapsulation above IP layer is not visible to Transport 505 Network, it is not able to be used for network slice interworking 506 with transport network. In this case, IP header and Ethernet header 507 could be considered to provide information of network slice 508 interworking from AN or CN to TN. 510 +------------------------+----------- 511 | Application Protocols | ^ 512 +------------------------+ | 513 | IP (User) | Invisible 514 +------------------------+ for 515 | GTP | TN 516 +------------------------+ | 517 | UDP | V 518 +------------------------+------------ 519 | IP | 520 +------------------------+ 521 | Ethernet | 522 +------------------------+ 524 The following field in IP header and Ethernet header could be 525 considered : 527 IP Header: 529 * DSCP: It is traditionally used for the mapping of QoS identifier 530 between AN/CN and TN network. Although some values (e.g. The 531 unassigned code points) may be borrowed for the network slice 532 interworking, it may cause confusion between QoS mapping and 533 network slicing mapping.; 535 * Destination Address: It is possible to allocate different IP 536 addresses for entities in different network slice, then the 537 destination IP address could be used as the network slice 538 interworking identifier. However, it brings additional 539 requirement to IP address planning. In addition, in some cases 540 some AN or CN network slices may use duplicated IP addresses. 542 * Option fields/headers: It requires that both AN and CN nodes can 543 support the encapsulation and decapsulation of the options. 545 Ethernet header 547 * VLAN ID: It is widely used for the interconnection between AN/CN 548 nodes and the edge nodes of transport network for the access to 549 different VPNs. One possible problem is that the number of VLAN 550 ID can be supported by AN nodes is typically limited, which 551 effects the number of IETF network slices a AN node can attach to. 552 Another problem is the total amount of VLAN ID (4K) may not 553 provide a comparable space as the network slice identifiers of 554 mobile networks. 556 Two or more options described above may also be used together as the 557 IETF Network Slice Interworking ID, while it would make the mapping 558 relationship more complex to maintain. 560 In some other case, when AN or CN could support more layer 3 561 encapsulations, more options are available as follows: 563 If the AN or CN could support MPLS, the protocol stack could be as 564 follows: 566 +------------------------+----------- 567 | Application Protocols | ^ 568 +------------------------+ | 569 | IP (User) | Invisible 570 +------------------------+ for 571 | GTP | TN 572 +------------------------+ | 573 | UDP | V 574 +------------------------+------------ 575 | MPLS | 576 +------------------------+ 577 | IP | 578 +------------------------+ 579 | Ethernet | 580 +------------------------+ 582 A specified MPLS label could be used to as a IETF Network Slice 583 Interworking ID. 585 If the AN or CN could support SRv6, the protocol stack is as follows: 587 +------------------------+----------- 588 | Application Protocols | ^ 589 +------------------------+ | 590 | IP (User) | Invisible 591 +------------------------+ for 592 | GTP | TN 593 +------------------------+ | 594 | UDP | V 595 +------------------------+------------ 596 | SRH | 597 +------------------------+ 598 | IPv6 | 599 +------------------------+ 600 | Ethernet | 601 +------------------------+ 603 The following field could be considered to identify a network slice: 605 SRH: 607 * SRv6 functions: AN/CN is supposed to support the new function 608 extension of SRv6. 610 * Optional TLV: AN/CN is supposed to support the extension of 611 optional TLV of SRH. 613 5.3.2.2. Above Layer 3 Encapsulations 615 If the encapsulation above IP layer is visible to Transport Network, 616 it is able to be used to identify a network slice. In this case, UPD 617 and GTP-U could be considered to provide information of network slice 618 interworking between AN or CN and TN. 620 +------------------------+---------- 621 | Application Protocols | | 622 +------------------------+ Invisible 623 | IP (User) | for 624 +------------------------+ TN 625 | GTP | | 626 +------------------------+------------ 627 | UDP | 628 +------------------------+ 629 | IP | 630 +------------------------+ 631 | Ethernet | 632 +------------------------+ 634 The following field in UDP header could be considered: 636 UDP Header: 638 * UDP Source port: The UDP source port is sometimes used for load 639 balancing. Using it for network slice mapping would require to 640 disable the load-balancing behavior. 642 6. Network Slice Mapping Summary 644 The following picture shows the mapping relationship between the 645 network slice identifier in management plane, control plane and user 646 plane. 648 AN/CN | TN 649 Management +---------+ | +-----------------------+ 650 Plane | NSI |<--------|-->| IETF Network Slice ID | 651 +---------+ | +-----------------------+ 652 | | | 653 | | | 654 Control +-----V-----+ | +----------+----------+ 655 Plane | S-NSSAI | | | | 656 +-----------+ | | | 657 | +----V----+ +----V-------+ 658 +----------->| IETF |<--------->| IETF | 659 Data | Network |<--------->| Network | 660 Plane | Slice | | Slice | 661 | InterID | |realization | 662 +---------+ +------------+ 664 7. IANA Considerations 666 TBD 668 Note to RFC Editor: this section may be removed on publication as an 669 RFC. 671 8. Security Considerations 673 TBD 675 9. Acknowledgements 677 The authors would like to thank Shunsuke Homma for reviewing the 678 draft and giving valuable comments. 680 10. Normative References 682 [GST] "Generic Network Slice Template", 683 . 686 [I-D.contreras-teas-slice-nbi] 687 Contreras, L. M., Homma, S., Ordonez-Lucena, J. A., 688 Tantsura, J., and K. Szarkowicz, "IETF Network Slice Use 689 Cases and Attributes for Northbound Interface of IETF 690 Network Slice Controllers", Work in Progress, Internet- 691 Draft, draft-contreras-teas-slice-nbi-05, 12 July 2021, 692 . 695 [I-D.ietf-teas-ietf-network-slice-definition] 696 Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and 697 J. Tantsura, "Definition of IETF Network Slices", Work in 698 Progress, Internet-Draft, draft-ietf-teas-ietf-network- 699 slice-definition-01, 22 February 2021, 700 . 703 [I-D.ietf-teas-ietf-network-slices] 704 Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S., 705 Makhijani, K., Contreras, L. M., and J. Tantsura, 706 "Framework for IETF Network Slices", Work in Progress, 707 Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23 708 August 2021, . 711 [I-D.wd-teas-ietf-network-slice-nbi-yang] 712 Wu, B., Dhody, D., Rokui, R., Saad, T., Han, L., and L. M. 713 Contreras, "IETF Network Slice Service YANG Model", Work 714 in Progress, Internet-Draft, draft-wd-teas-ietf-network- 715 slice-nbi-yang-05, 26 September 2021, 716 . 719 [I-D.wd-teas-transport-slice-yang] 720 Wu, B., Dhody, D., Han, L., and R. Rokui, "A Yang Data 721 Model for Transport Slice NBI", Work in Progress, 722 Internet-Draft, draft-wd-teas-transport-slice-yang-02, 12 723 July 2020, . 726 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 727 Requirement Levels", BCP 14, RFC 2119, 728 DOI 10.17487/RFC2119, March 1997, 729 . 731 [TS23501] "3GPP TS23.501", 732 . 735 [TS28530] "3GPP TS28.530", 736 . 739 [TS28531] "3GPP TS28.531", 740 . 743 [TS28541] "3GPP TS 28.541", 744 . 747 [ZSM003] "ETSI ZSM003", 748 . 751 Authors' Addresses 753 Xuesong Geng 754 Huawei Technologies 756 Email: gengxuesong@huawei.com 758 Jie Dong 759 Huawei Technologies 761 Email: jie.dong@huawei.com 763 Ran Pang 764 China Unicom 766 Email: pangran@chinaunicom.cn 768 Liuyan Han 769 China Mobile 771 Email: hanliuyan@chinamobile.com 773 Reza Rokui 774 Nokia 776 Email: reza.rokui@nokia.com 778 Tomonobu Niwa 779 Individual 781 Email: tomonobu.niwa@gmail.com 782 Jaehwan Jin 783 LG U+ 785 Email: daenamu1@lguplus.co.kr 787 Chang Liu 788 China Unicom 790 Email: liuc131@chinaunicom.cn 792 Nikesh Nageshar 793 Individual 795 Email: nikesh.nageshar@gmail.com