< draft-geng-teas-network-slice-mapping-03.txt		draft-geng-teas-network-slice-mapping-04.txt >
	Network Working Group X. Geng		Network Working Group X. Geng
	Internet-Draft J. Dong		Internet-Draft J. Dong
	Intended status: Informational Huawei Technologies		Intended status: Informational Huawei Technologies
	Expires: August 26, 2021 R. Pang		Expires: 28 April 2022 R. Pang
	China Unicom		China Unicom
	L. Han		L. Han
	China Mobile		China Mobile
	T. Niwa		R. Rokui
			Nokia
			T. Niwa
	Individual		Individual
	J. Jin		J. Jin
	LG U+		LG U+
	C. Liu		C. Liu
	China Unicom		China Unicom
	N. Nageshar		N. Nageshar
	Individual		Individual
	February 22, 2021		25 October 2021
	5G End-to-end Network Slice Mapping from the view of Transport Network		5G End-to-end Network Slice Mapping from the view of Transport Network
	draft-geng-teas-network-slice-mapping-03		draft-geng-teas-network-slice-mapping-04
	Abstract		Abstract
	Network Slicing is one of the core featrures in 5G. End-to-end		Network Slicing is one of the core features in 5G. End-to-end
	network slice consists of 3 major types of network segments: Access		network slice consists of 3 major types of network segments: Access
	Network (AN), Mobile Core Network (CN) and Transport Network (TN).		Network (AN), Mobile Core Network (CN) and Transport Network (TN).
	This draft describes the procedure of mapping 5G end-to-end network		This draft describes the procedure of mapping 5G end-to-end network
	slice to transport network slice defined in IETF. This draft also		slice to transport network slice defined in IETF. This draft also
	intends to expose some gaps in the existing network management plane		intends to expose some gaps in the existing network management plane
	and data plane technologies to support inter-domain network slice		and data plane technologies to support inter-domain network slice
	mapping. Further work may require cooperation between IETF and 3GPP		mapping. Further work may require collaboration between IETF and
	(or other standard organizations). Data model specification,		3GPP (or other standard organizations). Data model specification,
	signaling protocol extension and new encapsulation definition are out		signaling protocol extension and new encapsulation definition are out
	of the scope of this draft.		of the scope of this draft.
	Requirements Language		Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [RFC2119].		document are to be interpreted as described in RFC 2119 [RFC2119].
	Status of This Memo		Status of This Memo
	skipping to change at page 2, line 12 ¶		skipping to change at page 2, line 15 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 26, 2021.		This Internet-Draft will expire on 28 April 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Simplified BSD License text
	include Simplified BSD License text as described in Section 4.e of		as described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Simplified BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Network Slice Mapping Structure . . . . . . . . . . . . . . . 4		3. 5G End-to-End Network Slice Identification . . . . . . . . . 4
	3.1. Requirements Profile . . . . . . . . . . . . . . . . . . 5		4. Network Slice Mapping Structure . . . . . . . . . . . . . . . 5
	3.2. Identifiers . . . . . . . . . . . . . . . . . . . . . . . 6		5. Network Slice Mapping Procedure . . . . . . . . . . . . . . . 8
	3.3. Relevant functions . . . . . . . . . . . . . . . . . . . 6		5.1. Network Slice Mapping in Management Plane . . . . . . . . 9
	4. Network Slice Mapping Procedure . . . . . . . . . . . . . . . 7		5.2. Network Slice Mapping in Control Plane . . . . . . . . . 10
	4.1. Network Slice Mapping in Management Plane . . . . . . . . 8		5.3. Network Slice Mapping in Data Plane . . . . . . . . . . . 10
	4.2. Network Slice Mapping in Control Plane . . . . . . . . . 9		5.3.1. Data Plane Mapping Considerations . . . . . . . . . . 10
	4.3. Network Slice Mapping in Data Plane . . . . . . . . . . . 10		5.3.2. Data Plane Mapping Options . . . . . . . . . . . . . 11
	4.3.1. Data Plane Mapping Considerations . . . . . . . . . . 10		6. Network Slice Mapping Summary . . . . . . . . . . . . . . . . 15
	4.3.2. Data Plane Mapping Options . . . . . . . . . . . . . 10		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	5. Network Slice Mapping Summary . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		10. Normative References . . . . . . . . . . . . . . . . . . . . 16
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Normative References . . . . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	1. Introduction		1. Introduction
	Driven by the new applications of 5G, the concept of network slicing		Driven by the new applications of 5G, the concept of network slicing
	is defined to provide a logical network with specific capabilities		is defined to provide a logical network with specific capabilities
	and characteristics. Network slice contains a set of network		and characteristics. Network slice contains a set of network
	functions and allocated resources(e.g. computation, storage and		functions and allocated resources(e.g. computation, storage and
	network resources). According to [TS28530], a 5G end-to-end network		network resources). According to [TS28530], a 5G end-to-end network
	slice is composed of three major types network segments: Radio Access		slice is composed of three major types network segments: Radio Access
	Network (RAN), Transport Network (TN) and Mobile Core Network (CN).		Network (RAN), Transport Network (TN) and Mobile Core Network (CN).
	Transport network is supposed to provide the required connectivity		Transport network is supposed to provide the required connectivity
	between AN and CN, with specific performance commitment. For each		between AN and CN, with specific performance commitment. For each
	end-to-end network slice, the topology and performance requirement		end-to-end network slice, the topology and performance requirement
	for transport network can be very different, which requests transport		for transport network can be very different, which requests transport
	network to have the capability of supporting multiple different		network to have the capability of supporting multiple different
	transport network slices.		transport network slices.
	A transport network slice is a virtual (logical) network with a		The concept of IETF network slice is discussed in
	particular network topology and a set of shared or dedicated network		[I-D.ietf-teas-ietf-network-slices]. In summary, an IETF Network
	resources, which are used to provide the network slice consumer with		Slice is a logical network topology connecting a number of endpoints
	the required connectivity, appropriate isolation and specific Service		using a set of shared or dedicated network resources that are used to
	Level Agreement (SLA). A transport network slice could span multiple		satisfy specific Service Level Objectives SLOs) and Service Level
	technology (IP, Optical) and multiple administrative domains.		Expectations (SLEs).
	Depending on the consumer's requirement, a transport network slice
	could be isolated from other concurrent transport network slices, in
	terms of data plane, control plane and management plane. Transport
	network slice is being defined and discussed in IETF.
	Editor's Note: The definition of transport network slice will align
	with [I-D.ietf-teas-ietf-network-slice-definition].
	The procedure of end-to-end network slice instance creation, network
	slice subnet instance creation and network slice instance termination
	in management plane is defined in [TS28531]. The end-to-end network
	slice allocation is defined in ETSI [ZSM003]. But there is no
	specifications about how to map end-to-end network slice in 5G system
	to transport network slice. This draft describes the procedure of
	mapping 5G end-to-end network slice into transport network slice in
	management plane, control plane and user plane.
	5G end-to-end network slice mapping is treated as an independent		The realization of an IETF network slices in Transport network (TN)
	mechanism from 5G end-to-end QoS mapping. The latter is not covered		could span multiple technology (e.g., IP/MPLS, Optical) and multiple
	by this version.		administrative domains. Depending on the consumer's requirement, an
			IETF network slice could be isolated from other concurrent IETF
			network slices, in terms of data plane, control plane and management
			plane. The procedure for lifecycle of an end-to-end network slice
			instance (i.e., creation, deletion, modificatinon, termination etc.)
			is defined in [TS28531]. End-to-end network slicing provisioning is
			specified in ETSI [ZSM003]. But there is no specifications about how
			to map end-to-end network slice to IETF network slices in Transport
			Network (TN). This draft describes the procedure of mapping the 5G
			end-to-end network slice to IETF network slices in management plane,
			control plane and data plane.
	2. Terminologies		2. Terminologies
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	The following terms are used in this document:		The following terms are used in this document:
	NS: Network Slice		NSC: IETF Network Slice Controller
	NSI: Network Slice Instance		NSI: Network Slice Instance
	NSSI: Network Slice Subnet Instance		NSSI: Network Slice Subnet Instance
	NSSAI: Network Slice Selection Assistance Information
	S-NSSAI: Single Network Slice Selection Assistance Information		S-NSSAI: Single Network Slice Selection Assistance Information
	AN: Access Network		AN: Access Network
	RAN: Radio Access Network		RAN: Radio Access Network
	TN: Transport Network		TN: Transport Network
	CN: Mobile Core Network		CN: Mobile Core Network
	DSCP: Differentiated Services Code Point		DSCP: Differentiated Services Code Point
	CSMF: Communication Service Management Function		CSMF: Communication Service Management Function
	NSMF: Network Slice Management Function		NSMF: Network Slice Management Function
	NSSMF: Network Slice Subnet Management Function		NSSMF: Network Slice Subnet Management Function
	GST: General Slice Template		3. 5G End-to-End Network Slice Identification
	TNSII: Transport Network Slice Interworking Identifier		The following figure illustrates a typical mobile network with three
			5G e2e network slices. Each e2e network slice contains AN slice, CN
			slice and one or more IETF network Slices. 3GPP identifies each e2e
			network slice using an integer called S-NSSAI. In Figure-1 there are
			three instances of e2e network slices which are identified by S-NSSAI
			01111111, 02222222 and 02333333, respectively. Each instance of e2e
			network slice contains AN slice, CN Slice and one or more IETF
			network slices. For example, e2e network slice 01111111 has AN Slice
			instance 4, CN Slice instance 1 and IETF network slice 6. Note that
			3GPP does not cover the IETF network slice. See [I-D.ietf-teas-ietf-
			network-slices] for details of IETF network slice.
	TNSI: Transport Network Slice Identifier		Note that 3GPP uses the terms NSI and NSSI which are a set of network
			function and required resources (e.g. compute, storage and networking
			resources) which corresponds to network slice Instance, whereas
			S-NSSAI is an integer that identifies the e2e network slice.
	PDU: Protocol Data Unit		+-----------+ +-----------+ +-----------+
			| S-NSSAI | | S-NSSAI | | S-NSSAI |
			| 01111111 | | 02222222 | | 03333333 |
			+---|-------+ +---|---|---+ +----|------+
			| +----------+ | |
			V V V V
			******* ******** ********
			Core * NSSI 1 * * NSSI 2 * * NSSI 3 *
			Network ******** ******** ********
			\ \ /
			\ \ /
			+-----+ +-----+ +-----+
			Transport | IETF| | IETF| | IETF|
			Network | NS 6| | NS 7| | NS 8|
			+-----+ +-----+ +-----+
			\ \ /
			\ \ /
			******** ********
			Access * NSSI 4 * * NSSI 5 *
			Network ******** ********
	Editor's Note: Terminologies defined in 3GPP, e.g.,Network Slice		Figure 1 5G End-to-End Network Slice and its components
	Subnet Management Function(NSSMF), Network Slice Subnet
	Instance(NSSI) and Network Slice Selection Assistance
	Information(NSSAI), are used in the end-to-end network slice mapping,
	which may not be used necessarily within the transport network.
	3. Network Slice Mapping Structure		4. Network Slice Mapping Structure
	The following figure shows the necessary elements for mapping end-to-		Referring to 3GPP TR 28.801, the management of 5G e2e network slices
	end network slice into transport network slice. All these network		from 3GPP view is shown in Figure-2(A). Figure-2(B) illustrates the
	slice elements are classified into three groups: requirements/		view of IETF and how it maps to 3GPP network slice management. In
	capabilities, identifiers and relevant functions.		particular, the IETF network slice controller (NSC) is equivalent to
			3GPP TN NSSMF and functional block "Consumer" at IETF is equivalent
			to 3GPP NSMF.
	+-----------------+		+-----------------+
	| CSMF |
	+--------+--------+
	|
	+--------V--------+
	| NSMF |		| NSMF |
	+-----------------+		+-----------------+
	+----------| NSI Identifier |----------+		+----------| S-NSSAI |----------+
	| | Service Profile | |		| |(e.g. 011111111) | |
	| | TN Network- | |
	| | -Slice Profile | |
	| +-----------------+ |		| +-----------------+ |
	| | |		| | |
	+------V------+ +----------V----------+ +------V------+		V V V
	| AN NSSMF | | TN NSSMF | | CN NSSMF |
	+-------------+ +---------------------+ +-------------+		+-------------+ +---------------------+ +-------------+
	| AN-NSSI- | | TN-NSSI Identifier | | CN-NSSI- |		| AN NSSMF | | IETF NSC | | CN NSSMF |
	| -Identifier | | Function Management| | -Identifier |		+-------------+ +---------------------+ +-------------+
	| ... | | ... | | ... | Management		| AN Slice | | IETF Network Slice | | CN Slice |
			| Identifier | | Identifier | | Identifier |
			| (e.g., 4) | | (e.g., 6) | | (e.g., 1) | Management
	+-------------+ +---------------------+ +-------------+ Plane		+-------------+ +---------------------+ +-------------+ Plane
	| | | | -----------------		| | | | -----------------
	|<----------PDU session (S-NSSAI)---------->| Control		| | | |
	| | | | Plane
	V V V V -----------------		V V V V -----------------
	/\ +-----+ +-----+ +-------+ Data		/\ +-----+ +-----+ +-------+ Data
	/AN\ -----| PE |-----...-----| PE |----| UPF | Plane		/AN\ -----| PE |-----...-----| PE |----| CN | Plane
	/____\ +-----+ +-----+ +-------+		/____\ +-----+ +-----+ +-------+
	|-->TNSII<--|------>TNSI<-------|-->TNSII<--|
	3.1. Requirements Profile
	In order to satisfy a tenant's request for a network slice with
	certain characteristics, creating a new network slice or using
	existing network slice instance is constrained by the requirement
	profile and the capability of the network slices.
	o Service Profile: represents the properties of network slice		Note: Refer to Figure-1 for S-NSSAI 01111111, AN, CN and IETF networks slices 4,6 and 1
	related requirement that should be supported by the network slice
	instance in 5G network. Service profile is defined in [TS28541]
	6.3.3.
	o TN Network Slice Profile: represents the properties of transport		Figure-2 Relation between IETF and 3GPP Network Slice management
	network slice related requirement that should be supported by the
	transport network slice in a 5G network. Slice Profile is defined
	in [TS28541] 6.3.4. TN Network slice profile is newly defined in
	this draft.
	3.2. Identifiers		The following figure shows the necessary elements for mapping end-to-
			end network slice into IETF network slices.
	Network slice related identifiers in management plane, control plane		+---------------------+
	and data(user) plane play an important role in end-to-end network		| CSMF |
	slice mapping.		+----------|----------+
			| +------------------------+
			+---------------------+ | 5G E2E Network Slice |
			| NSMF | | Orchestrator |
			+---------------------+ +------------------------+
			/ | \ |
			/ | \ NSC NBI |
			/ | \ |
			+---------++---------++---------+ +------------------------+
			| AN || TN || CN | | IETF Network Slice |
			| NSSMF || NSSMF || NSSMF | | Controller (NSC) |
			| || || | +------------------------+
			+---------++---------++---------+ NSC SBI |
			| | | |
			| | | +------------------------+
			| | | | Network Controllers |
			| | | +------------------------+
			| | | |
			| | | |
			****** ****** ****** ******
			* 5G * * IETF * * 5G * * IETF *
			* RAN * * Network* * Core * * Network*
			* * * * * * * *
			****** ****** ****** ******
	o Single Network Slice Selection Assistance Information(S-NSSAI):		Figure-3 5G E2E Network Slice Mapping Structure
	end-to-end network slice identifier in control plane, which is
	defined in [TS23501];
	o Network Slice Instance(NSI) Identifier:end-to-end network slice		The following network slice related identifiers in management plane,
	identifier in management plane, which is created in NSMF; NSI is		control plane and data(user) plane play an important role in end-to-
	is set of Network Function instances and the required resources		end network slice mapping.
	(e.g. computing, storage and networking resources) which form a
	deployed Network Slice, which is defined in [TS23501]; ;
	o Transport Network Slice Instance(TN-NSSI) Identifier: transport		* Single Network Slice Selection Assistance Information(S-NSSAI):
	network slice identifier in management plane, which is created in		The end-to-end network slice identifier, which is defined in
	TN NSSMF; TN-NSSI is newly defined in this draft.		[TS23501]; S-NSSAI is used during 3GPP network slice signalling
			process.
	o Transport Network Slice Interworking Identifier (TNSII): network		* IETF Network Slice Identifier: An identifier allocated by IETF
	slice identifier which is used for mapping end-to-end network		Neetwork Slice Controller (NSC) in management plane. In data
	slice into transport network slice in data plane. TNSII is a new		plane, IETF Network Slice Identifier may be instantiated with
	concept introduced by this draft, which can be instantiated with		existing data plane identifiers and doesn't necessarily require
	existing data plane identifiers and doesn't necessarilly request		new encapsulation.
	new encapsulation. TNSII could be pre-allocated as a global
	identifier.
	o Transport Network Slice Identifier(TNSI): transport network slice		* IETF Network Slice Interworking Identifier: Data-plane network
	identifier in data plane(user plane). TNSI is newly defined in		slice identifier which is used for mapping the end-to-end network
	this draft.		slice traffic to specific IETF network slice. The IETF Network
			Slice Interworking Identifier is a new concept introduced by this
			draft, which may be instantiated with existing data plane
			identifiers and doesn't necessarily require new encapsulation.
	The relationship between these identifiers are specifies in the		The relationship between these identifiers are specifies in the
	following sections.		following sections.
	3.3. Relevant functions		5. Network Slice Mapping Procedure
	There are a set of slice relevant functions that are necessary for
	transport network slice management:
	o Topology management
	o QoS management
	o Resource management
	o Measurement management
	o ...
	Some of these functions are implemented inside the transport network
	and independent from the end-to-end network slice, e.g., topology
	management, QoS management, resource management; Some of the
	functions are related to the end-to-end network slice and should
	cooperate with other network elements from other domain, e.g.,
	Measurement management.
	4. Network Slice Mapping Procedure
	This section provides a general procedure of network slice mapping:		This section provides a general procedure of network slice mapping:
	+--------------------------------+
	| Requirement Matching |
	+---------------+----------------+
	|
	V
	+--------------------------------+
	| NSI<->TN NSSI Mapping |
	+---------------+----------------+
	|
	V
	+--------------------------------+
	| S-NSSAI Selection |
	+---------------+----------------+
	|
	V
	+--------------------------------+
	|S-NSSAI<---------->TNSII Mapping|
	| (NSI<->TN NSSI) |
	+---------------+----------------+
	|
	V
	+--------------------------------+
	| TNSII<->TNSI Mapping |
	+--------------------------------+
	1. NSMF receives the request from CSMF for allocation of a network		1. NSMF receives the request from CSMF for allocation of a network
	slice instance with certain characteristics.		slice instance with certain characteristics.
	2. Based on the service requirement , NSMF acquires requirements for		2. Based on the service requirement , NSMF acquires requirements for
	the end-to-end network slice instance , which is defined in Service		the end-to-end network slice instance , which is defined in Service
	Profile([TS28541] section 6.3.3).		Profile([TS28541] section 6.3.3).
	3. NSMF derives transport network slice related requirements from		3. Based on Service Profile, NSMF identified the network function
	the Service profile, and maintains them in Transport Network Slice		and the required resources in AN, CN and TN networks. It also
	Profile, So as to CN Slice Profile and AN Slice Profile, in order to		assigns the unique ID S-NSSAI.
	decide on the constituent NSSIs(including AN NSSI, CN NSSI and TN
	NSSI) of the NSI, based on the service profile and the endpoint
	information(AN/CN edge nodes).
	4. NSMF sends the Transport Network Slice Profile, endpoint		4. NSMF sends a request to AN NSSMF for creation of AN Slice.
	information, along with other TS NBI attributes to TN NSSMF for TN
	NSSI allocation.
	5. TN NSSMF allocates TN NSSI which could satisfy the requirement of		5. NSMF sends a request to CN NSSMF for creation of CN Slice.
	Transport Network Slice Profile between the specified endpoints (AN/
	CN edge nodes) and sends the TN NSSI Identifier to NSMF.
	6. NSMF acquires the mapping relationship between NSI and TN NSSI.		6. NSMF sends a request to IETF Network Slice Controller (NSC) for
			creation of IETF Network Slice. The request contains such attribute
			such as endpoints, required SLA/SLO along with other IETF network
			slice attributes. It also cotains mapping informatin for IETF
			Network Slice Interworking Identifier.
	7. NSMF matains the mapping relationship between NSI and S-NSSAI and		7. NSC realizes the IETF network slice which satisfies the
	the mapping relationship between TN NSSI and TNSII, which could be		requirement of IETF network slice between the specified endpoints
	used to set up mapping relationship between S-NSSAI and TNSII.		(AN/ CN edge nodes). It assigns sliceID and send it to NSMF.
	8. When a PDU session is set up between AN and CN, an S-NSSAI is		8. NSMF has the mapping relationship between S-NSSAI and IETF
	selected for the PDU session.		Network Slice ID;
	9. AN/CN edge nodes encapsulates the packet using TNSII, according		9. When the User Equipment (UE) appears, and during the 5G
	to the selected S-NSSAI. Network Slice could also be differentiated		signalling, it requests to be connected to specific e2e network slice
	by physical interface, if different network slices are transported		identified by S-NASSI. Then a GTP tunnel (which is UDP/IP) will be
	through different interface;		created.
	10. The edge node of transport network parses the TNSII from the		10. UE starts sending traffic in context of e2e network slice for
	packet and maps the packet to the corresponding transport network		specific S-NASSI.
	slice. It may encapsulate packet with TNSI. The nodes in transport
	network transit the packet inside the corresponding transport network
	slice according to TNSI.
	The procedure of end-to-end network slice mapping involves the		11. In context of GTP tunnel, the AN edge nodes encapsulates the
	mapping in three network planes: management plane, control plane and		packet with sliceIID according to the selected S-NSSAI ans send it to
	data plane.		the transport network.
	4.1. Network Slice Mapping in Management Plane		12. The transport network edge node receives the IP packet and
			parses the sliceIID from the packet and maps the packet to the
			corresponding IETF network slice. It may encapsulate packet with
			sliceID if needed (for example for enforcing QoS in transport
			network).
			5.1. Network Slice Mapping in Management Plane
	The transport network management Plane maintains the interface		The transport network management Plane maintains the interface
	between NSMF and TN NSSMF, which 1) guarantees that transport network		between NSMF and TN NSSMF, which 1) guarantees that IETF network
	slice could connect the AN and CN with specified characteristics that		slice could connect the AN and CN with specified characteristics that
	satisfy the requirements of communication; 2) builds up the mapping		satisfy the requirements of communication; 2) builds up the mapping
	relationship between NSI identifier and TN NSSI identifier; 3)		relationship between NSI identifier and TN NSSI identifier; 3)
	maintains the end-to-end slice relevant functions;		maintains the end-to-end slice relevant functions;
	Service Profile defined in[TS28541] represents the requirement of		Service Profile defined in[TS28541] represents the requirement of
	end-to-end network slice instance in 5G network. Parameters defined		end-to-end network slice instance in 5G network. Parameters defined
	in Service Profile include Latency, resource sharing level,		in Service Profile include Latency, resource sharing level,
	availability and so on. How to decompose the end-to-end requirement		availability and so on. How to decompose the end-to-end requirement
	to the transport network requirement is one of the key issues in		to the transport network requirement is one of the key issues in
	Network slice requirement mapping. GSMA(Global System for Mobile		Network slice requirement mapping. GSMA(Global System for Mobile
	Communications Association) defines the [GST] to indicate the network		Communications Association) defines the [GST] to indicate the network
	slice requirement from the view of service provider.		slice requirement from the view of service provider.
	[I-D.contreras-teas-slice-nbi] analysis the parameters of GST and		[I-D.contreras-teas-slice-nbi] analysis the parameters of GST and
	categorize the parameters into three classes, including the		categorize the parameters into three classes, including the
	attributes with direct impact on the transport network slice		attributes with direct impact on the IETF network slice definition.
	definition. It is a good start for selecting the transport network		It is a good start for selecting the transport network relevant
	relevant parameters in order to define Network Slice Profile for		parameters in order to define Network Slice Profile for Transport
	Transport Network. Network slice requirement parameters are also		Network. Network slice requirement parameters are also necessary for
	necessary for the definition of transport network northbound		the definition of transport network northbound interface.
	interface.
	Inside the TN NSSMF, it is supposed to maintain the attributes of the		Inside the TN NSSMF, it is supposed to maintain the attributes of the
	transport network slice. If the attributes of an existing TN NSSI		IETF network slice. If the attributes of an existing TN NSSI could
	could satisfy the requirement from TN Network Slice Profile, the		satisfy the requirement from TN Network Slice Profile, the existing
	existing TN NSSI could be selected and the mapping is finished If		TN NSSI could be selected and the mapping is finished If there is no
	there is no existing TN NSSI which could satisfy the requirement, a		existing TN NSSI which could satisfy the requirement, a new TN NSSI
	new TN NSSI is supposed to be created by the NSSMF with new		is supposed to be created by the NSSMF with new attributes.
	attributes.
	TN NSSI resource reservation should be considered to avoid over		TN NSSI resource reservation should be considered to avoid over
	allocation from multiple requests from NSMF (but the detailed		allocation from multiple requests from NSMF (but the detailed
	mechanism should be out of scope in the draft)		mechanism should be out of scope in the draft)
	TN NSSMF sends the selected or newly allocated TN NSSI identifier to		TN NSSMF sends the selected or newly allocated TN NSSI identifier to
	NSMF. The mapping relationship between NSI identifier and TN NSSI		NSMF. The mapping relationship between NSI identifier and TN NSSI
	identifier is maintained in both NSMF and TN NSSMF.		identifier is maintained in both NSMF and TN NSSMF.
	YANG data model for the Transport Slice NBI, which could be used by a		YANG data model for the Transport Slice NBI, which could be used by a
	higher level system which is the Transport slice consumer of a		higher level system which is the Transport slice consumer of a
	Transport Slice Controller (TSC) to request, configure, and manage		Transport Slice Controller (TSC) to request, configure, and manage
	the components of a transport slices, is defined in		the components of a transport slices, is defined in
	[I-D.wd-teas-transport-slice-yang]. The northbound Interface of IETF		[I-D.wd-teas-transport-slice-yang]. The northbound Interface of IETF
	network slice refers to [I-D.wd-teas-ietf-network-slice-nbi-yang].		network slice refers to [I-D.wd-teas-ietf-network-slice-nbi-yang].
	4.2. Network Slice Mapping in Control Plane		5.2. Network Slice Mapping in Control Plane
	There is no explicit interaction between transport network and AN/CN		There is no explicit interaction between transport network and AN/CN
	in the control plane, but the S-NSSAI defined in [TS23501] is treated		in the control plane, but the S-NSSAI defined in [TS23501] is treated
	as the end-to-end network slice identifier in the control plane of AN		as the end-to-end network slice identifier in the control plane of AN
	and CN, which is used in UE registration and PDU session setup. In		and CN, which is used in UE registration and PDU session setup. In
	this draft, we assume that there is mapping relationship between		this draft, we assume that there is mapping relationship between
	S-NSSAI and NSI in the management plane, thus it could be mapped to a		S-NSSAI and NSI in the management plane, thus it could be mapped to a
	transport network slice .		IETF network slice .
	Editor's note: The mapping relationship between NSI defined in		Editor's note: The mapping relationship between NSI defined in
	[TS23501] and S-NSSAI defined in [TS23501] is still in discussion.		[TS23501] and S-NSSAI defined in [TS23501] is still in discussion.
	4.3. Network Slice Mapping in Data Plane		5.3. Network Slice Mapping in Data Plane
	If multiple network slices are carried through one physical interface		If multiple network slices are carried through one physical interface
	between AN/CN and TN, transport network slice interworking		between AN/CN and TN, IETF Network Slice Interworking ID in the data
	identifier(TNSII) in the data plane needs to be introduced. If		plane needs to be introduced. If different network slices are
	different network slices are transported through different physical		transported through different physical interfaces, Network Slices
	interfaces, Network Slices could be distinguished by the interface		could be distinguished by the interface directly. Thus IETF Network
	directly. Thus TNSII is not the only option for network slice		Slice Interworking ID is not the only option for network slice
	mapping, while it may help in introducing new network slices.		mapping, while it may help in introducing new network slices.
	4.3.1. Data Plane Mapping Considerations		5.3.1. Data Plane Mapping Considerations
	The mapping relationship between AN or CN network slice identifier		The mapping relationship between AN or CN network slice identifier
	(either S-NSSAI in control plane or NSI/NSSI in management plane) and		(either S-NSSAI in control plane or NSI/NSSI in management plane) and
	TNSII needs to be maintained in AN/CN network nodes, and the mapping		IETF Network Slice Interworking ID needs to be maintained in AN/CN
	relationship between TNSII and TNSI is maintained in the edge node of		network nodes, and the mapping relationship between IETF Network
	transport network. When the packet of a uplink flow goes from AN to		Slice Interworking ID and IETF Network Slice is maintained in the
	TN, the packet is encapsulated based on the TNSII; then the		edge node of transport network. When the packet of a uplink flow
	encapsulation of TNSII is read by the edge node of transport network,		goes from AN to TN, the packet is encapsulated based on the IETF
	which maps the packet to the corresponding transport network slice.		Network Slice Interworking ID; then the encapsulation of IETF Network
			Slice Interworking ID is read by the edge node of transport network,
			which maps the packet to the corresponding IETF network slice.
	Editor's Note: We have considered to add "Network Instance" defined		Editor's Note: We have considered to add "Network Instance" defined
	in [TS23501]in the draft. However, after the discussion with 3GPP		in [TS23501]in the draft. However, after the discussion with 3GPP
	people, we think the concept of "network instance" is a 'neither		people, we think the concept of "network instance" is a 'neither
	Necessary nor Sufficient Condition' for network slice. Network		Necessary nor Sufficient Condition' for network slice. Network
	Instance could be determined by S-NSSAI, it could also depends on		Instance could be determined by S-NSSAI, it could also depends on
	other information; Network slice could also be allocated without		other information; Network slice could also be allocated without
	network instance (in my understanding) And, TNSII is not a		network instance (in my understanding) And, IETF Network Slice
	competitive concept with network instance.TNSII is a concept for the		Interworking ID is not a competitive concept with network
	data plane interconnection with transport network, network instance		instance.IETF Network Slice Interworking ID is a concept for the data
	may be used by AN and CN nodes to associate a network slice with		plane interconnection with transport network, network instance may be
	TNSII		used by AN and CN nodes to associate a network slice with IETF
			Network Slice Interworking ID
	4.3.2. Data Plane Mapping Options		5.3.2. Data Plane Mapping Options
	The following picture shows the end-to-end network slice in data		The following picture shows the end-to-end network slice in data
	plane:		plane:
	+--+ +-----+ +----------------+		+--+ +-----+ +----------------+
	|UE|- - - -|(R)AN|---------------------------| UPF |		|UE|- - - -|(R)AN|---------------------------| UPF |
	+--+ +-----+ +----------------+		+--+ +-----+ +----------------+
	|<----AN NS---->|<----------TN NS---------->|<----CN NS----->|		|<----AN NS---->|<----------TN NS---------->|<----CN NS----->|
	The mapping between 3GPP slice and transport slice in user plane		The mapping between 3GPP slice and transport slice in user plane
	skipping to change at page 11, line 39 ¶		skipping to change at page 12, line 23 ¶
	| Protocol | |Protoc|UDP/IP|--|--|UDP/IP|UDP/IP|-|-| UDP/IP | |		| Protocol | |Protoc|UDP/IP|--|--|UDP/IP|UDP/IP|-|-| UDP/IP | |
	| Layers | |Layers+------+ | +------+------+ | +-----------+ |		| Layers | |Layers+------+ | +------+------+ | +-----------+ |
	| | | | L2 |--|--| L2 | L2 |-|-| L2 | |		| | | | L2 |--|--| L2 | L2 |-|-| L2 | |
	| | | +------+ | +------+------+ | +-----------+ |		| | | +------+ | +------+------+ | +-----------+ |
	| | | | L1 |--|--| L1 | L1 |-|-| L1 | |		| | | | L1 |--|--| L1 | L1 |-|-| L1 | |
	+-----------+ +-------------+ | +-------------+ | +-----------+ |		+-----------+ +-------------+ | +-------------+ | +-----------+ |
	UE 5G-AN | UPF | UPF |		UE 5G-AN | UPF | UPF |
	N3 N9 N6		N3 N9 N6
	The following figure shows the typical encapsulation in N3 interface		The following figure shows the typical encapsulation in N3 interface
	which could be used to carry the transport network slice interworking		which could be used to carry the IETF Network Slice Interworking ID
	identifier (TNSII) between AN/CN and TN.		between AN/CN and TN.
	+------------------------+		+------------------------+
	| Application Protocols |		| Application Protocols |
	+------------------------+		+------------------------+
	| IP (User) |		| IP (User) |
	+------------------------+		+------------------------+
	| GTP |		| GTP |
	+------------------------+		+------------------------+
	| UDP |		| UDP |
	+------------------------+		+------------------------+
	| IP |		| IP |
	+------------------------+		+------------------------+
	| Ethernet |		| Ethernet |
	+------------------------+		+------------------------+
	4.3.2.1. Layer 3 and Layer 2 Encapsulations		5.3.2.1. Layer 3 and Layer 2 Encapsulations
	If the encapsulation above IP layer is not visible to Transport		If the encapsulation above IP layer is not visible to Transport
	Network, it is not able to be used for network slice interworking		Network, it is not able to be used for network slice interworking
	with transport network. In this case, IP header and Ethernet header		with transport network. In this case, IP header and Ethernet header
	could be considered to provide information of network slice		could be considered to provide information of network slice
	interworking from AN or CN to TN.		interworking from AN or CN to TN.
	+------------------------+-----------		+------------------------+-----------
	| Application Protocols | ^		| Application Protocols | ^
	+------------------------+ |		+------------------------+ |
	skipping to change at page 12, line 46 ¶		skipping to change at page 13, line 24 ¶
	| IP |		| IP |
	+------------------------+		+------------------------+
	| Ethernet |		| Ethernet |
	+------------------------+		+------------------------+
	The following field in IP header and Ethernet header could be		The following field in IP header and Ethernet header could be
	considered :		considered :
	IP Header:		IP Header:
	o DSCP: It is traditionally used for the mapping of QoS identifier		* DSCP: It is traditionally used for the mapping of QoS identifier
	between AN/CN and TN network. Although some values (e.g. The		between AN/CN and TN network. Although some values (e.g. The
	unassigned code points) may be borrowed for the network slice		unassigned code points) may be borrowed for the network slice
	interworking, it may cause confusion between QoS mapping and		interworking, it may cause confusion between QoS mapping and
	network slicing mapping.;		network slicing mapping.;
	o Destination Address: It is possible to allocate different IP		* Destination Address: It is possible to allocate different IP
	addresses for entities in different network slice, then the		addresses for entities in different network slice, then the
	destination IP address could be used as the network slice		destination IP address could be used as the network slice
	interworking identifier. However, it brings additional		interworking identifier. However, it brings additional
	requirement to IP address planning. In addition, in some cases		requirement to IP address planning. In addition, in some cases
	some AN or CN network slices may use duplicated IP addresses.		some AN or CN network slices may use duplicated IP addresses.
	o Option fields/headers: It requires that both AN and CN nodes can		* Option fields/headers: It requires that both AN and CN nodes can
	support the encapsulation and decapsulation of the options.		support the encapsulation and decapsulation of the options.
	Ethernet header		Ethernet header
	o VLAN ID: It is widely used for the interconnection between AN/CN		* VLAN ID: It is widely used for the interconnection between AN/CN
	nodes and the edge nodes of transport network for the access to		nodes and the edge nodes of transport network for the access to
	different VPNs. One possible problem is that the number of VLAN		different VPNs. One possible problem is that the number of VLAN
	ID can be supported by AN nodes is typically limited, which		ID can be supported by AN nodes is typically limited, which
	effects the number of transport network slices a AN node can		effects the number of IETF network slices a AN node can attach to.
	attach to. Another problem is the total amount of VLAN ID (4K)		Another problem is the total amount of VLAN ID (4K) may not
	may not provide a comparable space as the network slice		provide a comparable space as the network slice identifiers of
	identifiers of mobile networks.		mobile networks.
	Two or more options described above may also be used together as the		Two or more options described above may also be used together as the
	TNSII, while it would make the mapping relationship more complex to		IETF Network Slice Interworking ID, while it would make the mapping
	maintain.		relationship more complex to maintain.
	In some other case, when AN or CN could support more layer 3		In some other case, when AN or CN could support more layer 3
	encapsulations, more options are available as follows:		encapsulations, more options are available as follows:
	If the AN or CN could support MPLS, the protocol stack could be as		If the AN or CN could support MPLS, the protocol stack could be as
	follows:		follows:
	+------------------------+-----------		+------------------------+-----------
	| Application Protocols | ^		| Application Protocols | ^
	+------------------------+ |		+------------------------+ |
	skipping to change at page 13, line 52 ¶		skipping to change at page 14, line 31 ¶
	+------------------------+ |		+------------------------+ |
	| UDP | V		| UDP | V
	+------------------------+------------		+------------------------+------------
	| MPLS |		| MPLS |
	+------------------------+		+------------------------+
	| IP |		| IP |
	+------------------------+		+------------------------+
	| Ethernet |		| Ethernet |
	+------------------------+		+------------------------+
	A specified MPLS label could be used to as a TNSII.		A specified MPLS label could be used to as a IETF Network Slice
			Interworking ID.
	If the AN or CN could support SRv6, the protocol stack is as follows:		If the AN or CN could support SRv6, the protocol stack is as follows:
	+------------------------+-----------		+------------------------+-----------
	| Application Protocols | ^		| Application Protocols | ^
	+------------------------+ |		+------------------------+ |
	| IP (User) | Invisible		| IP (User) | Invisible
	+------------------------+ for		+------------------------+ for
	| GTP | TN		| GTP | TN
	+------------------------+ |		+------------------------+ |
	skipping to change at page 14, line 27 ¶		skipping to change at page 15, line 7 ¶
	+------------------------+		+------------------------+
	| IPv6 |		| IPv6 |
	+------------------------+		+------------------------+
	| Ethernet |		| Ethernet |
	+------------------------+		+------------------------+
	The following field could be considered to identify a network slice:		The following field could be considered to identify a network slice:
	SRH:		SRH:
	o SRv6 functions: AN/CN is supposed to support the new function		* SRv6 functions: AN/CN is supposed to support the new function
	extension of SRv6.		extension of SRv6.
	o Optional TLV: AN/CN is supposed to support the extension of		* Optional TLV: AN/CN is supposed to support the extension of
	optional TLV of SRH.		optional TLV of SRH.
	4.3.2.2. Above Layer 3 Encapsulations		5.3.2.2. Above Layer 3 Encapsulations
	If the encapsulation above IP layer is visible to Transport Network,		If the encapsulation above IP layer is visible to Transport Network,
	it is able to be used to identify a network slice. In this case, UPD		it is able to be used to identify a network slice. In this case, UPD
	and GTP-U could be considered to provide information of network slice		and GTP-U could be considered to provide information of network slice
	interworking between AN or CN and TN.		interworking between AN or CN and TN.
	+------------------------+----------		+------------------------+----------
	| Application Protocols | |		| Application Protocols | |
	+------------------------+ Invisible		+------------------------+ Invisible
	| IP (User) | for		| IP (User) | for
	skipping to change at page 15, line 4 ¶		skipping to change at page 15, line 33 ¶
	| IP (User) | for		| IP (User) | for
	+------------------------+ TN		+------------------------+ TN
	| GTP | |		| GTP | |
	+------------------------+------------		+------------------------+------------
	| UDP |		| UDP |
	+------------------------+		+------------------------+
	| IP |		| IP |
	+------------------------+		+------------------------+
	| Ethernet |		| Ethernet |
	+------------------------+		+------------------------+
	The following field in UDP header could be considered:		The following field in UDP header could be considered:
	UDP Header:		UDP Header:
	o UDP Source port: The UDP source port is sometimes used for load		* UDP Source port: The UDP source port is sometimes used for load
	balancing. Using it for network slice mapping would require to		balancing. Using it for network slice mapping would require to
	disable the load-balancing behavior.		disable the load-balancing behavior.
	5. Network Slice Mapping Summary		6. Network Slice Mapping Summary
	The following picture shows the mapping relationship between the		The following picture shows the mapping relationship between the
	network slice identifier in management plane, control plane and user		network slice identifier in management plane, control plane and user
	plane.		plane.
	AN/CN | TN		AN/CN | TN
	Management +---------+ | +---------+		Management +---------+ | +-----------------------+
	Plane | NSI |<--------|------->| TN NSSI |		Plane | NSI |<--------|-->| IETF Network Slice ID |
	+---------+ | +---------+		+---------+ | +-----------------------+
	| | |		| | |
	| | |		| | |
	Control +-----V-----+ | +----------+----------+		Control +-----V-----+ | +----------+----------+
	Plane | S-NSSAI | | | |		Plane | S-NSSAI | | | |
	+-----------+ | | |		+-----------+ | | |
	| +----V----+ +----V----+		| +----V----+ +----V-------+
	+----------->| TNSII |<--------->| TNSI |		+----------->| IETF |<--------->| IETF |
	User | /Port |<--------->| |		Data | Network |<--------->| Network |
	Plane +---------+ +---------+		Plane | Slice | | Slice |
			| InterID | |realization |
			+---------+ +------------+
	6. IANA Considerations		7. IANA Considerations
	TBD		TBD
	Note to RFC Editor: this section may be removed on publication as an		Note to RFC Editor: this section may be removed on publication as an
	RFC.		RFC.
	7. Security Considerations		8. Security Considerations
	TBD		TBD
	8. Acknowledgements		9. Acknowledgements
	The authors would like to thank Shunsuke Homma for reviewing the		The authors would like to thank Shunsuke Homma for reviewing the
	draft and giving valuable comments.		draft and giving valuable comments.
	9. Normative References		10. Normative References
	[GST] "Generic Network Slice Template",		[GST] "Generic Network Slice Template",
	<https://www.gsma.com/newsroom/all-documents/generic-		<https://www.gsma.com/newsroom/all-documents/generic-
	network-slice-template-v2-0/>.		network-slice-template-v2-0/>.
	[I-D.contreras-teas-slice-nbi]		[I-D.contreras-teas-slice-nbi]
	Contreras, L., Homma, S., and J. Ordonez-Lucena, "IETF		Contreras, L. M., Homma, S., Ordonez-Lucena, J. A.,
	Network Slice use cases and attributes for Northbound		Tantsura, J., and K. Szarkowicz, "IETF Network Slice Use
	Interface of controller", draft-contreras-teas-slice-		Cases and Attributes for Northbound Interface of IETF
	nbi-03 (work in progress), October 2020.		Network Slice Controllers", Work in Progress, Internet-
			Draft, draft-contreras-teas-slice-nbi-05, 12 July 2021,
			<https://www.ietf.org/archive/id/draft-contreras-teas-
			slice-nbi-05.txt>.
	[I-D.ietf-teas-ietf-network-slice-definition]		[I-D.ietf-teas-ietf-network-slice-definition]
	Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J.		Rokui, R., Homma, S., Makhijani, K., Contreras, L. M., and
	Tantsura, "Definition of IETF Network Slices", draft-ietf-		J. Tantsura, "Definition of IETF Network Slices", Work in
	teas-ietf-network-slice-definition-00 (work in progress),		Progress, Internet-Draft, draft-ietf-teas-ietf-network-
	January 2021.		slice-definition-01, 22 February 2021,
			<https://www.ietf.org/archive/id/draft-ietf-teas-ietf-
			network-slice-definition-01.txt>.
			[I-D.ietf-teas-ietf-network-slices]
			Farrel, A., Gray, E., Drake, J., Rokui, R., Homma, S.,
			Makhijani, K., Contreras, L. M., and J. Tantsura,
			"Framework for IETF Network Slices", Work in Progress,
			Internet-Draft, draft-ietf-teas-ietf-network-slices-04, 23
			August 2021, <https://www.ietf.org/archive/id/draft-ietf-
			teas-ietf-network-slices-04.txt>.
	[I-D.wd-teas-ietf-network-slice-nbi-yang]		[I-D.wd-teas-ietf-network-slice-nbi-yang]
	Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data		Wu, B., Dhody, D., Rokui, R., Saad, T., Han, L., and L. M.
	Model for IETF Network Slice NBI", draft-wd-teas-ietf-		Contreras, "IETF Network Slice Service YANG Model", Work
	network-slice-nbi-yang-01 (work in progress), November		in Progress, Internet-Draft, draft-wd-teas-ietf-network-
	2020.		slice-nbi-yang-05, 26 September 2021,
			<https://www.ietf.org/archive/id/draft-wd-teas-ietf-
			network-slice-nbi-yang-05.txt>.
	[I-D.wd-teas-transport-slice-yang]		[I-D.wd-teas-transport-slice-yang]
	Bo, W., Dhody, D., Han, L., and R. Rokui, "A Yang Data		Wu, B., Dhody, D., Han, L., and R. Rokui, "A Yang Data
	Model for Transport Slice NBI", draft-wd-teas-transport-		Model for Transport Slice NBI", Work in Progress,
	slice-yang-02 (work in progress), July 2020.		Internet-Draft, draft-wd-teas-transport-slice-yang-02, 12
			July 2020, <https://www.ietf.org/archive/id/draft-wd-teas-
			transport-slice-yang-02.txt>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[TS23501] "3GPP TS23.501",		[TS23501] "3GPP TS23.501",
	<https://portal.3gpp.org/desktopmodules/Specifications/		<https://portal.3gpp.org/desktopmodules/Specifications/
	SpecificationDetails.aspx?specificationId=3144>.		SpecificationDetails.aspx?specificationId=3144>.
	skipping to change at page 17, line 35 ¶		skipping to change at page 18, line 35 ¶
	Ran Pang		Ran Pang
	China Unicom		China Unicom
	Email: pangran@chinaunicom.cn		Email: pangran@chinaunicom.cn
	Liuyan Han		Liuyan Han
	China Mobile		China Mobile
	Email: hanliuyan@chinamobile.com		Email: hanliuyan@chinamobile.com
			Reza Rokui
			Nokia
			Email: reza.rokui@nokia.com
	Tomonobu Niwa		Tomonobu Niwa
	Individual		Individual
	Email: tomonobu.niwa@gmail.com		Email: tomonobu.niwa@gmail.com
	Jaehwan Jin		Jaehwan Jin
	LG U+		LG U+
	Email: daenamu1@lguplus.co.kr		Email: daenamu1@lguplus.co.kr
	Chang Liu		Chang Liu
	China Unicom		China Unicom
	Email: liuc131@chinaunicom.cn		Email: liuc131@chinaunicom.cn
	Nikesh Nageshar		Nikesh Nageshar
	Individual		Individual
	Email: nikesh.nageshar@gmail.com		Email: nikesh.nageshar@gmail.com
End of changes. 89 change blocks.
	292 lines changed or deleted		293 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/