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