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