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