idnits 2.17.1
draft-geng-teas-network-slice-mapping-03.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 2 instances of too long lines in the document, the longest one
being 2 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 (February 22, 2021) is 1156 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-06) exists of
draft-contreras-teas-slice-nbi-03
== Outdated reference: A later version (-01) exists of
draft-ietf-teas-ietf-network-slice-definition-00
== Outdated reference: A later version (-05) exists of
draft-wd-teas-ietf-network-slice-nbi-yang-01
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: August 26, 2021 R. Pang
6 China Unicom
7 L. Han
8 China Mobile
9 T. Niwa
10 Individual
11 J. Jin
12 LG U+
13 C. Liu
14 China Unicom
15 N. Nageshar
16 Individual
17 February 22, 2021
19 5G End-to-end Network Slice Mapping from the view of Transport Network
20 draft-geng-teas-network-slice-mapping-03
22 Abstract
24 Network Slicing is one of the core featrures in 5G. End-to-end
25 network slice consists of 3 major types of network segments: Access
26 Network (AN), Mobile Core Network (CN) and Transport Network (TN).
27 This draft describes the procedure of mapping 5G end-to-end network
28 slice to transport network slice defined in IETF. This draft also
29 intends to expose some gaps in the existing network management plane
30 and data plane technologies to support inter-domain network slice
31 mapping. Further work may require cooperation between IETF and 3GPP
32 (or other standard organizations). Data model specification,
33 signaling protocol extension and new encapsulation definition are out
34 of the scope of this draft.
36 Requirements Language
38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
40 document are to be interpreted as described in RFC 2119 [RFC2119].
42 Status of This Memo
44 This Internet-Draft is submitted in full conformance with the
45 provisions of BCP 78 and BCP 79.
47 Internet-Drafts are working documents of the Internet Engineering
48 Task Force (IETF). Note that other groups may also distribute
49 working documents as Internet-Drafts. The list of current Internet-
50 Drafts is at https://datatracker.ietf.org/drafts/current/.
52 Internet-Drafts are draft documents valid for a maximum of six months
53 and may be updated, replaced, or obsoleted by other documents at any
54 time. It is inappropriate to use Internet-Drafts as reference
55 material or to cite them other than as "work in progress."
57 This Internet-Draft will expire on August 26, 2021.
59 Copyright Notice
61 Copyright (c) 2021 IETF Trust and the persons identified as the
62 document authors. All rights reserved.
64 This document is subject to BCP 78 and the IETF Trust's Legal
65 Provisions Relating to IETF Documents
66 (https://trustee.ietf.org/license-info) in effect on the date of
67 publication of this document. Please review these documents
68 carefully, as they describe your rights and restrictions with respect
69 to this document. Code Components extracted from this document must
70 include Simplified BSD License text as described in Section 4.e of
71 the Trust Legal Provisions and are provided without warranty as
72 described in the Simplified BSD License.
74 Table of Contents
76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
77 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
78 3. Network Slice Mapping Structure . . . . . . . . . . . . . . . 4
79 3.1. Requirements Profile . . . . . . . . . . . . . . . . . . 5
80 3.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6
81 3.3. Relevant functions . . . . . . . . . . . . . . . . . . . 6
82 4. Network Slice Mapping Procedure . . . . . . . . . . . . . . . 7
83 4.1. Network Slice Mapping in Management Plane . . . . . . . . 8
84 4.2. Network Slice Mapping in Control Plane . . . . . . . . . 9
85 4.3. Network Slice Mapping in Data Plane . . . . . . . . . . . 10
86 4.3.1. Data Plane Mapping Considerations . . . . . . . . . . 10
87 4.3.2. Data Plane Mapping Options . . . . . . . . . . . . . 10
88 5. Network Slice Mapping Summary . . . . . . . . . . . . . . . . 15
89 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
91 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
92 9. Normative References . . . . . . . . . . . . . . . . . . . . 16
93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
95 1. Introduction
97 Driven by the new applications of 5G, the concept of network slicing
98 is defined to provide a logical network with specific capabilities
99 and characteristics. Network slice contains a set of network
100 functions and allocated resources(e.g. computation, storage and
101 network resources). According to [TS28530], a 5G end-to-end network
102 slice is composed of three major types network segments: Radio Access
103 Network (RAN), Transport Network (TN) and Mobile Core Network (CN).
104 Transport network is supposed to provide the required connectivity
105 between AN and CN, with specific performance commitment. For each
106 end-to-end network slice, the topology and performance requirement
107 for transport network can be very different, which requests transport
108 network to have the capability of supporting multiple different
109 transport network slices.
111 A transport network slice is a virtual (logical) network with a
112 particular network topology and a set of shared or dedicated network
113 resources, which are used to provide the network slice consumer with
114 the required connectivity, appropriate isolation and specific Service
115 Level Agreement (SLA). A transport network slice could span multiple
116 technology (IP, Optical) and multiple administrative domains.
117 Depending on the consumer's requirement, a transport network slice
118 could be isolated from other concurrent transport network slices, in
119 terms of data plane, control plane and management plane. Transport
120 network slice is being defined and discussed in IETF.
122 Editor's Note: The definition of transport network slice will align
123 with [I-D.ietf-teas-ietf-network-slice-definition].
125 The procedure of end-to-end network slice instance creation, network
126 slice subnet instance creation and network slice instance termination
127 in management plane is defined in [TS28531]. The end-to-end network
128 slice allocation is defined in ETSI [ZSM003]. But there is no
129 specifications about how to map end-to-end network slice in 5G system
130 to transport network slice. This draft describes the procedure of
131 mapping 5G end-to-end network slice into transport network slice in
132 management plane, control plane and user plane.
134 5G end-to-end network slice mapping is treated as an independent
135 mechanism from 5G end-to-end QoS mapping. The latter is not covered
136 by this version.
138 2. Terminologies
140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
142 document are to be interpreted as described in [RFC2119].
144 The following terms are used in this document:
146 NS: Network Slice
148 NSI: Network Slice Instance
150 NSSI: Network Slice Subnet Instance
152 NSSAI: Network Slice Selection Assistance Information
154 S-NSSAI: Single Network Slice Selection Assistance Information
156 AN: Access Network
158 RAN: Radio Access Network
160 TN: Transport Network
162 CN: Mobile Core Network
164 DSCP: Differentiated Services Code Point
166 CSMF: Communication Service Management Function
168 NSMF: Network Slice Management Function
170 NSSMF: Network Slice Subnet Management Function
172 GST: General Slice Template
174 TNSII: Transport Network Slice Interworking Identifier
176 TNSI: Transport Network Slice Identifier
178 PDU: Protocol Data Unit
180 Editor's Note: Terminologies defined in 3GPP, e.g.,Network Slice
181 Subnet Management Function(NSSMF), Network Slice Subnet
182 Instance(NSSI) and Network Slice Selection Assistance
183 Information(NSSAI), are used in the end-to-end network slice mapping,
184 which may not be used necessarily within the transport network.
186 3. Network Slice Mapping Structure
188 The following figure shows the necessary elements for mapping end-to-
189 end network slice into transport network slice. All these network
190 slice elements are classified into three groups: requirements/
191 capabilities, identifiers and relevant functions.
193 +-----------------+
194 | CSMF |
195 +--------+--------+
196 |
197 +--------V--------+
198 | NSMF |
199 +-----------------+
200 +----------| NSI Identifier |----------+
201 | | Service Profile | |
202 | | TN Network- | |
203 | | -Slice Profile | |
204 | +-----------------+ |
205 | | |
206 +------V------+ +----------V----------+ +------V------+
207 | AN NSSMF | | TN NSSMF | | CN NSSMF |
208 +-------------+ +---------------------+ +-------------+
209 | AN-NSSI- | | TN-NSSI Identifier | | CN-NSSI- |
210 | -Identifier | | Function Management| | -Identifier |
211 | ... | | ... | | ... | Management
212 +-------------+ +---------------------+ +-------------+ Plane
213 | | | | -----------------
214 |<----------PDU session (S-NSSAI)---------->| Control
215 | | | | Plane
216 V V V V -----------------
217 /\ +-----+ +-----+ +-------+ Data
218 /AN\ -----| PE |-----...-----| PE |----| UPF | Plane
219 /____\ +-----+ +-----+ +-------+
220 |-->TNSII<--|------>TNSI<-------|-->TNSII<--|
222 3.1. Requirements Profile
224 In order to satisfy a tenant's request for a network slice with
225 certain characteristics, creating a new network slice or using
226 existing network slice instance is constrained by the requirement
227 profile and the capability of the network slices.
229 o Service Profile: represents the properties of network slice
230 related requirement that should be supported by the network slice
231 instance in 5G network. Service profile is defined in [TS28541]
232 6.3.3.
234 o TN Network Slice Profile: represents the properties of transport
235 network slice related requirement that should be supported by the
236 transport network slice in a 5G network. Slice Profile is defined
237 in [TS28541] 6.3.4. TN Network slice profile is newly defined in
238 this draft.
240 3.2. Identifiers
242 Network slice related identifiers in management plane, control plane
243 and data(user) plane play an important role in end-to-end network
244 slice mapping.
246 o Single Network Slice Selection Assistance Information(S-NSSAI):
247 end-to-end network slice identifier in control plane, which is
248 defined in [TS23501];
250 o Network Slice Instance(NSI) Identifier:end-to-end network slice
251 identifier in management plane, which is created in NSMF; NSI is
252 is set of Network Function instances and the required resources
253 (e.g. computing, storage and networking resources) which form a
254 deployed Network Slice, which is defined in [TS23501]; ;
256 o Transport Network Slice Instance(TN-NSSI) Identifier: transport
257 network slice identifier in management plane, which is created in
258 TN NSSMF; TN-NSSI is newly defined in this draft.
260 o Transport Network Slice Interworking Identifier (TNSII): network
261 slice identifier which is used for mapping end-to-end network
262 slice into transport network slice in data plane. TNSII is a new
263 concept introduced by this draft, which can be instantiated with
264 existing data plane identifiers and doesn't necessarilly request
265 new encapsulation. TNSII could be pre-allocated as a global
266 identifier.
268 o Transport Network Slice Identifier(TNSI): transport network slice
269 identifier in data plane(user plane). TNSI is newly defined in
270 this draft.
272 The relationship between these identifiers are specifies in the
273 following sections.
275 3.3. Relevant functions
277 There are a set of slice relevant functions that are necessary for
278 transport network slice management:
280 o Topology management
282 o QoS management
284 o Resource management
286 o Measurement management
287 o ...
289 Some of these functions are implemented inside the transport network
290 and independent from the end-to-end network slice, e.g., topology
291 management, QoS management, resource management; Some of the
292 functions are related to the end-to-end network slice and should
293 cooperate with other network elements from other domain, e.g.,
294 Measurement management.
296 4. Network Slice Mapping Procedure
298 This section provides a general procedure of network slice mapping:
300 +--------------------------------+
301 | Requirement Matching |
302 +---------------+----------------+
303 |
304 V
305 +--------------------------------+
306 | NSI<->TN NSSI Mapping |
307 +---------------+----------------+
308 |
309 V
310 +--------------------------------+
311 | S-NSSAI Selection |
312 +---------------+----------------+
313 |
314 V
315 +--------------------------------+
316 |S-NSSAI<---------->TNSII Mapping|
317 | (NSI<->TN NSSI) |
318 +---------------+----------------+
319 |
320 V
321 +--------------------------------+
322 | TNSII<->TNSI Mapping |
323 +--------------------------------+
325 1. NSMF receives the request from CSMF for allocation of a network
326 slice instance with certain characteristics.
328 2. Based on the service requirement , NSMF acquires requirements for
329 the end-to-end network slice instance , which is defined in Service
330 Profile([TS28541] section 6.3.3).
332 3. NSMF derives transport network slice related requirements from
333 the Service profile, and maintains them in Transport Network Slice
334 Profile, So as to CN Slice Profile and AN Slice Profile, in order to
335 decide on the constituent NSSIs(including AN NSSI, CN NSSI and TN
336 NSSI) of the NSI, based on the service profile and the endpoint
337 information(AN/CN edge nodes).
339 4. NSMF sends the Transport Network Slice Profile, endpoint
340 information, along with other TS NBI attributes to TN NSSMF for TN
341 NSSI allocation.
343 5. TN NSSMF allocates TN NSSI which could satisfy the requirement of
344 Transport Network Slice Profile between the specified endpoints (AN/
345 CN edge nodes) and sends the TN NSSI Identifier to NSMF.
347 6. NSMF acquires the mapping relationship between NSI and TN NSSI.
349 7. NSMF matains the mapping relationship between NSI and S-NSSAI and
350 the mapping relationship between TN NSSI and TNSII, which could be
351 used to set up mapping relationship between S-NSSAI and TNSII.
353 8. When a PDU session is set up between AN and CN, an S-NSSAI is
354 selected for the PDU session.
356 9. AN/CN edge nodes encapsulates the packet using TNSII, according
357 to the selected S-NSSAI. Network Slice could also be differentiated
358 by physical interface, if different network slices are transported
359 through different interface;
361 10. The edge node of transport network parses the TNSII from the
362 packet and maps the packet to the corresponding transport network
363 slice. It may encapsulate packet with TNSI. The nodes in transport
364 network transit the packet inside the corresponding transport network
365 slice according to TNSI.
367 The procedure of end-to-end network slice mapping involves the
368 mapping in three network planes: management plane, control plane and
369 data plane.
371 4.1. Network Slice Mapping in Management Plane
373 The transport network management Plane maintains the interface
374 between NSMF and TN NSSMF, which 1) guarantees that transport network
375 slice could connect the AN and CN with specified characteristics that
376 satisfy the requirements of communication; 2) builds up the mapping
377 relationship between NSI identifier and TN NSSI identifier; 3)
378 maintains the end-to-end slice relevant functions;
380 Service Profile defined in[TS28541] represents the requirement of
381 end-to-end network slice instance in 5G network. Parameters defined
382 in Service Profile include Latency, resource sharing level,
383 availability and so on. How to decompose the end-to-end requirement
384 to the transport network requirement is one of the key issues in
385 Network slice requirement mapping. GSMA(Global System for Mobile
386 Communications Association) defines the [GST] to indicate the network
387 slice requirement from the view of service provider.
388 [I-D.contreras-teas-slice-nbi] analysis the parameters of GST and
389 categorize the parameters into three classes, including the
390 attributes with direct impact on the transport network slice
391 definition. It is a good start for selecting the transport network
392 relevant parameters in order to define Network Slice Profile for
393 Transport Network. Network slice requirement parameters are also
394 necessary for the definition of transport network northbound
395 interface.
397 Inside the TN NSSMF, it is supposed to maintain the attributes of the
398 transport network slice. If the attributes of an existing TN NSSI
399 could satisfy the requirement from TN Network Slice Profile, the
400 existing TN NSSI could be selected and the mapping is finished If
401 there is no existing TN NSSI which could satisfy the requirement, a
402 new TN NSSI is supposed to be created by the NSSMF with new
403 attributes.
405 TN NSSI resource reservation should be considered to avoid over
406 allocation from multiple requests from NSMF (but the detailed
407 mechanism should be out of scope in the draft)
409 TN NSSMF sends the selected or newly allocated TN NSSI identifier to
410 NSMF. The mapping relationship between NSI identifier and TN NSSI
411 identifier is maintained in both NSMF and TN NSSMF.
413 YANG data model for the Transport Slice NBI, which could be used by a
414 higher level system which is the Transport slice consumer of a
415 Transport Slice Controller (TSC) to request, configure, and manage
416 the components of a transport slices, is defined in
417 [I-D.wd-teas-transport-slice-yang]. The northbound Interface of IETF
418 network slice refers to [I-D.wd-teas-ietf-network-slice-nbi-yang].
420 4.2. Network Slice Mapping in Control Plane
422 There is no explicit interaction between transport network and AN/CN
423 in the control plane, but the S-NSSAI defined in [TS23501] is treated
424 as the end-to-end network slice identifier in the control plane of AN
425 and CN, which is used in UE registration and PDU session setup. In
426 this draft, we assume that there is mapping relationship between
427 S-NSSAI and NSI in the management plane, thus it could be mapped to a
428 transport network slice .
430 Editor's note: The mapping relationship between NSI defined in
431 [TS23501] and S-NSSAI defined in [TS23501] is still in discussion.
433 4.3. Network Slice Mapping in Data Plane
435 If multiple network slices are carried through one physical interface
436 between AN/CN and TN, transport network slice interworking
437 identifier(TNSII) in the data plane needs to be introduced. If
438 different network slices are transported through different physical
439 interfaces, Network Slices could be distinguished by the interface
440 directly. Thus TNSII is not the only option for network slice
441 mapping, while it may help in introducing new network slices.
443 4.3.1. Data Plane Mapping Considerations
445 The mapping relationship between AN or CN network slice identifier
446 (either S-NSSAI in control plane or NSI/NSSI in management plane) and
447 TNSII needs to be maintained in AN/CN network nodes, and the mapping
448 relationship between TNSII and TNSI is maintained in the edge node of
449 transport network. When the packet of a uplink flow goes from AN to
450 TN, the packet is encapsulated based on the TNSII; then the
451 encapsulation of TNSII is read by the edge node of transport network,
452 which maps the packet to the corresponding transport network slice.
454 Editor's Note: We have considered to add "Network Instance" defined
455 in [TS23501]in the draft. However, after the discussion with 3GPP
456 people, we think the concept of "network instance" is a 'neither
457 Necessary nor Sufficient Condition' for network slice. Network
458 Instance could be determined by S-NSSAI, it could also depends on
459 other information; Network slice could also be allocated without
460 network instance (in my understanding) And, TNSII is not a
461 competitive concept with network instance.TNSII is a concept for the
462 data plane interconnection with transport network, network instance
463 may be used by AN and CN nodes to associate a network slice with
464 TNSII
466 4.3.2. Data Plane Mapping Options
468 The following picture shows the end-to-end network slice in data
469 plane:
471 +--+ +-----+ +----------------+
472 |UE|- - - -|(R)AN|---------------------------| UPF |
473 +--+ +-----+ +----------------+
474 |<----AN NS---->|<----------TN NS---------->|<----CN NS----->|
476 The mapping between 3GPP slice and transport slice in user plane
477 could happens in:
479 (R)AN: User data goes from (radio) access network to transport
480 network
482 UPF: User data goes from core network functions to transport network
484 Editor's Note: As figure 4.7.1. in [TS28530] describes, TN NS will
485 not only exist between AN and CN but may also within AN NS and CN NS.
486 However, here we just show the TN between AN and CN as an example to
487 avoid unncessary complexity.
489 The following picture shows the user plane protocol stack in end-to-
490 end 5G system.
492 +-----------+ | | |
493 |Application+--------------------|------------------|---------------|
494 +-----------+ | | +-----------+ |
495 | PDU Layer +--------------------|------------------|-| PDU Layer | |
496 +-----------+ +-------------+ | +-------------+ | +-----------+ |
497 | | | ___Relay___ |--|--| ___Relay___ |-|-| | |
498 | | | \/ GTP-U|--|--|GTP-U\/ GTP-U|-|-| GTP-U | |
499 | 5G-AN | |5G-AN +------+ | +------+------+ | +-----------+ |
500 | Protocol | |Protoc|UDP/IP|--|--|UDP/IP|UDP/IP|-|-| UDP/IP | |
501 | Layers | |Layers+------+ | +------+------+ | +-----------+ |
502 | | | | L2 |--|--| L2 | L2 |-|-| L2 | |
503 | | | +------+ | +------+------+ | +-----------+ |
504 | | | | L1 |--|--| L1 | L1 |-|-| L1 | |
505 +-----------+ +-------------+ | +-------------+ | +-----------+ |
506 UE 5G-AN | UPF | UPF |
507 N3 N9 N6
509 The following figure shows the typical encapsulation in N3 interface
510 which could be used to carry the transport network slice interworking
511 identifier (TNSII) between AN/CN and TN.
513 +------------------------+
514 | Application Protocols |
515 +------------------------+
516 | IP (User) |
517 +------------------------+
518 | GTP |
519 +------------------------+
520 | UDP |
521 +------------------------+
522 | IP |
523 +------------------------+
524 | Ethernet |
525 +------------------------+
527 4.3.2.1. Layer 3 and Layer 2 Encapsulations
529 If the encapsulation above IP layer is not visible to Transport
530 Network, it is not able to be used for network slice interworking
531 with transport network. In this case, IP header and Ethernet header
532 could be considered to provide information of network slice
533 interworking from AN or CN to TN.
535 +------------------------+-----------
536 | Application Protocols | ^
537 +------------------------+ |
538 | IP (User) | Invisible
539 +------------------------+ for
540 | GTP | TN
541 +------------------------+ |
542 | UDP | V
543 +------------------------+------------
544 | IP |
545 +------------------------+
546 | Ethernet |
547 +------------------------+
549 The following field in IP header and Ethernet header could be
550 considered :
552 IP Header:
554 o DSCP: It is traditionally used for the mapping of QoS identifier
555 between AN/CN and TN network. Although some values (e.g. The
556 unassigned code points) may be borrowed for the network slice
557 interworking, it may cause confusion between QoS mapping and
558 network slicing mapping.;
560 o Destination Address: It is possible to allocate different IP
561 addresses for entities in different network slice, then the
562 destination IP address could be used as the network slice
563 interworking identifier. However, it brings additional
564 requirement to IP address planning. In addition, in some cases
565 some AN or CN network slices may use duplicated IP addresses.
567 o Option fields/headers: It requires that both AN and CN nodes can
568 support the encapsulation and decapsulation of the options.
570 Ethernet header
572 o VLAN ID: It is widely used for the interconnection between AN/CN
573 nodes and the edge nodes of transport network for the access to
574 different VPNs. One possible problem is that the number of VLAN
575 ID can be supported by AN nodes is typically limited, which
576 effects the number of transport network slices a AN node can
577 attach to. Another problem is the total amount of VLAN ID (4K)
578 may not provide a comparable space as the network slice
579 identifiers of mobile networks.
581 Two or more options described above may also be used together as the
582 TNSII, while it would make the mapping relationship more complex to
583 maintain.
585 In some other case, when AN or CN could support more layer 3
586 encapsulations, more options are available as follows:
588 If the AN or CN could support MPLS, the protocol stack could be as
589 follows:
591 +------------------------+-----------
592 | Application Protocols | ^
593 +------------------------+ |
594 | IP (User) | Invisible
595 +------------------------+ for
596 | GTP | TN
597 +------------------------+ |
598 | UDP | V
599 +------------------------+------------
600 | MPLS |
601 +------------------------+
602 | IP |
603 +------------------------+
604 | Ethernet |
605 +------------------------+
607 A specified MPLS label could be used to as a TNSII.
609 If the AN or CN could support SRv6, the protocol stack is as follows:
611 +------------------------+-----------
612 | Application Protocols | ^
613 +------------------------+ |
614 | IP (User) | Invisible
615 +------------------------+ for
616 | GTP | TN
617 +------------------------+ |
618 | UDP | V
619 +------------------------+------------
620 | SRH |
621 +------------------------+
622 | IPv6 |
623 +------------------------+
624 | Ethernet |
625 +------------------------+
627 The following field could be considered to identify a network slice:
629 SRH:
631 o SRv6 functions: AN/CN is supposed to support the new function
632 extension of SRv6.
634 o Optional TLV: AN/CN is supposed to support the extension of
635 optional TLV of SRH.
637 4.3.2.2. Above Layer 3 Encapsulations
639 If the encapsulation above IP layer is visible to Transport Network,
640 it is able to be used to identify a network slice. In this case, UPD
641 and GTP-U could be considered to provide information of network slice
642 interworking between AN or CN and TN.
644 +------------------------+----------
645 | Application Protocols | |
646 +------------------------+ Invisible
647 | IP (User) | for
648 +------------------------+ TN
649 | GTP | |
650 +------------------------+------------
651 | UDP |
652 +------------------------+
653 | IP |
654 +------------------------+
655 | Ethernet |
656 +------------------------+
657 The following field in UDP header could be considered:
659 UDP Header:
661 o UDP Source port: The UDP source port is sometimes used for load
662 balancing. Using it for network slice mapping would require to
663 disable the load-balancing behavior.
665 5. Network Slice Mapping Summary
667 The following picture shows the mapping relationship between the
668 network slice identifier in management plane, control plane and user
669 plane.
671 AN/CN | TN
672 Management +---------+ | +---------+
673 Plane | NSI |<--------|------->| TN NSSI |
674 +---------+ | +---------+
675 | | |
676 | | |
677 Control +-----V-----+ | +----------+----------+
678 Plane | S-NSSAI | | | |
679 +-----------+ | | |
680 | +----V----+ +----V----+
681 +----------->| TNSII |<--------->| TNSI |
682 User | /Port |<--------->| |
683 Plane +---------+ +---------+
685 6. IANA Considerations
687 TBD
689 Note to RFC Editor: this section may be removed on publication as an
690 RFC.
692 7. Security Considerations
694 TBD
696 8. Acknowledgements
698 The authors would like to thank Shunsuke Homma for reviewing the
699 draft and giving valuable comments.
701 9. Normative References
703 [GST] "Generic Network Slice Template",
704 .
707 [I-D.contreras-teas-slice-nbi]
708 Contreras, L., Homma, S., and J. Ordonez-Lucena, "IETF
709 Network Slice use cases and attributes for Northbound
710 Interface of controller", draft-contreras-teas-slice-
711 nbi-03 (work in progress), October 2020.
713 [I-D.ietf-teas-ietf-network-slice-definition]
714 Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J.
715 Tantsura, "Definition of IETF Network Slices", draft-ietf-
716 teas-ietf-network-slice-definition-00 (work in progress),
717 January 2021.
719 [I-D.wd-teas-ietf-network-slice-nbi-yang]
720 Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data
721 Model for IETF Network Slice NBI", draft-wd-teas-ietf-
722 network-slice-nbi-yang-01 (work in progress), November
723 2020.
725 [I-D.wd-teas-transport-slice-yang]
726 Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data
727 Model for Transport Slice NBI", draft-wd-teas-transport-
728 slice-yang-02 (work in progress), July 2020.
730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
731 Requirement Levels", BCP 14, RFC 2119,
732 DOI 10.17487/RFC2119, March 1997,
733 .
735 [TS23501] "3GPP TS23.501",
736 .
739 [TS28530] "3GPP TS28.530",
740 .
743 [TS28531] "3GPP TS28.531",
744 .
747 [TS28541] "3GPP TS 28.541",
748 .
751 [ZSM003] "ETSI ZSM003",
752 .
755 Authors' Addresses
757 Xuesong Geng
758 Huawei Technologies
760 Email: gengxuesong@huawei.com
762 Jie Dong
763 Huawei Technologies
765 Email: jie.dong@huawei.com
767 Ran Pang
768 China Unicom
770 Email: pangran@chinaunicom.cn
772 Liuyan Han
773 China Mobile
775 Email: hanliuyan@chinamobile.com
777 Tomonobu Niwa
778 Individual
780 Email: tomonobu.niwa@gmail.com
782 Jaehwan Jin
783 LG U+
785 Email: daenamu1@lguplus.co.kr
786 Chang Liu
787 China Unicom
789 Email: liuc131@chinaunicom.cn
791 Nikesh Nageshar
792 Individual
794 Email: nikesh.nageshar@gmail.com