idnits 2.17.1 draft-mink-5g-ns-transport-ps-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 26, 2018) is 2129 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? 'PS-Interwork-X' on line 468 looks like a reference -- Missing reference section? 'PS-Interwork-1' on line 573 looks like a reference -- Missing reference section? 'PS-Interwork-2' on line 578 looks like a reference -- Missing reference section? 'PS-Interwork-3' on line 586 looks like a reference Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Miyasaka 3 Internet-Draft KDDI Research 4 Intended status: Informational K. Kumaki 5 Expires: December 28, 2018 T. Niwa 6 KDDI 7 June 26, 2018 9 Analysis and Problem Statements for Interworking between 5G Network 10 Slicing and Transport Network 11 draft-mink-5g-ns-transport-ps-00 13 Abstract 15 This document describes problem statements for realizing an end-to- 16 end network slicing that is expected to provide service-oriented 17 communications between users and applications. 3GPP introduced the 18 network slicing concept in the 5G architecture (3GPP Release 15), 19 however, it mainly focuses on mobile access and core domains. In 20 order to reap the benefit of the concept, a network slicing needs to 21 be designed across multiple domains of the network including non-3GPP 22 parts. This document analyzes the current 3GPP 5G network slicing 23 architecture and summarizes problem statements for the interworking 24 between the 5G network slicing and the transport network. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on December 28, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Scope of this document . . . . . . . . . . . . . . . . . 3 62 2. 5G Network Slicing and Transport Network . . . . . . . . . . 5 63 2.1. 5G Network Slicing . . . . . . . . . . . . . . . . . . . 5 64 2.2. Transport Network for End-to-End 5G Communication . . . . 6 65 2.2.1. Transport Network inside 5G System . . . . . . . . . 6 66 2.2.2. Transport Network outside 5G System . . . . . . . . . 6 67 2.2.3. Management and Orchestration of 5G Network Slicing . 7 68 3. General Procedure for Interworking between 5G Network Slicing 69 and Transport Network . . . . . . . . . . . . . . . . . . . . 7 70 4. Analysis on Interworking . . . . . . . . . . . . . . . . . . 10 71 4.1. Analysis Assumption . . . . . . . . . . . . . . . . . . . 10 72 4.2. Analysis inside 5G Core Network . . . . . . . . . . . . . 11 73 4.3. Analysis outside 5G Core Network . . . . . . . . . . . . 13 74 5. Problem Statement Summary . . . . . . . . . . . . . . . . . . 14 75 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 7. Security Consideration . . . . . . . . . . . . . . . . . . . 15 77 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 78 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 79 10. Informative References . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 An End-to-End(E2E) network slicing is expected to cater to much 85 greater diversity of requirements for wide variety of services such 86 as V2X services and factory automation. Here, the E2E means that a 87 network slicing penetrates all network domains: mobile networks, 88 transport networks and so forth. Network operators anticipate that 89 it is possible to tailor the network to fit for service-oriented 90 demands in a timely and cost-effective way, which in turn reduces 91 OPEX and CAPEX. 93 3GPP is leading a network slicing concept in the 5G system (3GPP 94 Release 15). The 3GPP network slicing is defined as a logical 95 network that provides specific network capabilities and network 96 characteristics. However, it covers a limited domains and mainly 97 focuses on an isolation for the 5G network functions. In order to 98 achieve the goal, the network slicing needs to be designed from the 99 E2E perspectives, not only 3GPP but also non-3GPP including transport 100 networks. 102 The way to map transport networks to the 5G system for a network 103 slicing can be classified into two parts: inside and outside 5G 104 system. Inside 5G system, network connections between UE, RAN, UPF 105 and DN can be identified as network slice with one or more QoS Flow 106 rules, and thus its underlying transport network should also be aware 107 of the network slice. Outside 5G system, the E2E network slicing 108 shall concatenate the network slicing whthin 5G systems with that of 109 the following transport networks. To this end, a method to stitch 110 user plane traffic to/from UPF and logical tunnels in transport 111 networks (e.g. MPLS-TE) is required. 113 Therefore, in terms of the E2E network slicing, the transport network 114 shall accommodate to the 5G system. This document analyzes the 115 current 5G network slicing architecture and summarizes problem 116 statements for the interworking between the 5G network slicing and 117 the transport network. 119 1.1. Scope of this document 121 The scope of this document is to analyze an interworking between the 122 5G network slicing and the transport network and summarize problem 123 statements for the interworking. Figure 1 shows an E2E communication 124 between UE and CP(Content Provider Server) on 5G network slicing 125 environment. We define each term used in the scope with Figure 1 as 126 follows. 128 + - - - - - - - - - - - - - - - - - - + 129 | Network Slice Instance(NS1) | 130 +--+ +---+ +---+ +---+ 131 |UE+--|-+RAN| |UPF|----------|DN | | 132 +--+ +-|-+ +-|-+ +-|-+ 133 + - + - - - - - - -+- - - - - - - + - + 134 | | | 135 + - - + - - - - - - -|- - + + - - + - - - - - - - - - + 136 | | | | | | | 137 | +----+ | | +----+ 138 | | | R2 | | | | | | R6 | | 139 | +----+ | | +----+ 140 | | / \ | | | | / \ | 141 +--|-+/ \+--|-+ +--|-+/ \+----+ +--+ 142 | | R1 | | R4 | | | | R5 | | R8 |--+--|CP| 143 +--|-+\ /+--|-+ +--|-+\ /+----+ +--+ 144 | | \ / | | | | \ / | 145 | +----+ | | +----+ 146 | | | R3 | | | | | | R7 | | 147 | +----+ | | +----+ 148 | | Transport | | | | Transport | 149 | Network | | Network 150 | | Inside 5GC | | | | Outside 5GC | 151 + - - + - - - - - - -|- - + + - - + - - - - - - - - - + 152 | | | 153 + - + - - - - - - -+- - - - - - - + - + 154 +--+ +-|-+ +-|-+ +-|-+ 155 |UE+--|-+RAN| |UPF|----------|DN | | 156 +--+ +---+ +---+ +---+ 157 | Network Slice Instance(NS2) | 158 + - - - - - - - - - - - - - - - - - - + 160 Figure 1: E2E communication between UE and CP 162 o Network slice instance 164 The network slice instance is defined as "A set of Network Function 165 instances and the required resources (e.g. compute, storage and 166 networking resources) which form a deployed Network Slice" in 167 [TS.23.501-3GPP]. 169 o Transport network 171 The definition of the transport network in this document is a network 172 which provides a network connectivity to the 5G network functions 173 such as UPF. The scope of the the transport network in this document 174 is limited to layer-3 network, thus IPv4 and IPv6. This is because 175 3GPP adopted IPv4/IPv6 as a transport network of the 5G user plane. 177 There are two different transport networks in Figure 1: the transport 178 network inside 5G core network consists of R1, R2, R3, and R4 and the 179 transport network outside 5G core network consists of R5, R6, R7, and 180 R8. Both inside and outside networks are within the scope of this 181 document. 183 o Traffic engineering 185 The definition of traffic engineering in this document is to control 186 the traffic path of IPv4/IPv6 packet in order to fulfill each network 187 slice instance's requirements. (e.g. bandwidth and latency) 189 For example, there are two network slice instance in Figure 1: NS1 190 and NS2. Suppose NS1 provides latency sensitive service such as V2X 191 (in this case, UE is an automotive vehicle and CP is a control/ 192 monitoring server operated by a car vendor), an operator needs to 193 perform traffic engineering in transport network to select a path 194 that total latency between UE and CP is minimum. If one-way latency 195 is measured as follows, 197 o R1->R2->R4 : 1msec 199 o R1->R3->R4 : 2msec 201 o R5->R6->R8 : 9msec 203 o R5->R7->R8 : 6msec 205 the traffic path of NS1 in the transport network inside 5G core 206 network is R1->R2->R4 and the traffic path of NS1 in the transport 207 network outside 5G core network is R5->R7->R8. Therefore, the E2E 208 communication from UE to CP is 209 "UE->RAN->R1->R2->R4->UPF->DN->R5->R7->R8->CP". 211 o Interworking 213 The definition of an interworking in this document is that the 214 network slice instance and the transport network collaborate in order 215 to perform the traffic engineering which fulfills requirements of the 216 network slice instance. 218 2. 5G Network Slicing and Transport Network 220 2.1. 5G Network Slicing 222 The 5G system architecture introduced the following key features: 224 o Separate the user plane (UP) functions from the control plane (CP) 225 functions, allowing independent scalability and flexible 226 deployments. 228 o Modularize the network function to enable the flexible and 229 efficient network slicing. 231 Thanks to the features, the deployed network slicing is comprised of 232 a network slice instance that indicates a set of network 233 functions(e.g. UPF) and the required resources. S-NSSAI(Single 234 Network Slice Selection Assistance Information) is used to identify a 235 network slice and assists the selection of a particular network slice 236 instance corresponding to the slice. A network slice instance can be 237 associated with one or more S-NSSAIs, and an S-NSSAI can be 238 associated with one or more network slice instances. NSI ID(Network 239 Slice Instance Identifier) may identify a network slice instance 240 corresponding to a certain S-NSSAI. 242 2.2. Transport Network for End-to-End 5G Communication 244 An E2E network slicing needs a cross-domain technology that covers 245 3GPP, transport networks and others (e.g. optical networks, data 246 center networks). For the 5G system, the transport networks are 247 classifled two parts; inside and outside 5G systems. 249 2.2.1. Transport Network inside 5G System 251 A PDU session belongs to one and only one specific network slice 252 instance in the 5G system. The 5G QoS model is based on the QoS 253 Flows that is the finest granularity of QoS differentiation in the 254 PDU session. The QoS Flow is characterised by QoS profiles for RAN, 255 QoS rules for UE and PDR(Packet Detection Rule) for UPF. DSCP can be 256 optinally utilized to support the QoS Flow, however, the QoS Flow 257 does not correspond to the network slice one by one. Therefore, a 258 network slice can not be identified from the transport network 259 perspective. Regarding the transport connectivity between different 260 3GPP nodes in the network slice instance, transport networks shall 261 take 3GPP link requirements (e.g. NSI ID, topology, QoS parameters, 262 etc.) from the network slice into account. 264 2.2.2. Transport Network outside 5G System 266 The S-NSSAI instructs which a PDU session is associated with a DN and 267 a network slice instance. In the current 3GPP specification, 268 transport networks cannot recognize the S-NSSAI or the NSI ID from UP 269 directly and thus cannot map the network slicing in the 3GPP system 270 to that of transport networks. 272 2.2.3. Management and Orchestration of 5G Network Slicing 274 The management and orchestration of the 5G network slicing is studied 275 in 3GPP SA5. This study includes creation, modification, and 276 elimination of the network slice instance from the 3GPP management 277 system. 279 In this 3GPP management system, the coordination with the management 280 system of non-3GPP parts also has been taken into account and the 281 transport network management is included in the scope of the 282 management system. Figure 2 shows a concept of the 3GPP management 283 system and a coordination with the transport network management 284 system, which is described in section 4.7 of [TS.28.530-3GPP] 285 However, the detailed analysis for the coordination with the 286 transport network management system is not studied. 288 +------------------------+ 289 | 3GPP Management System | 290 +------------------------+ 291 /|\ 292 | 293 | 294 \|/ 295 +-------------------+ 296 | Transport Network | 297 | Management System | 298 +-------------------+ 299 /|\ /|\ /|\ 300 | | | 301 +----------+ | +------------+ 302 | | | 303 \|/ \|/ \|/ 304 +---+ ---- +---+ ---- +---+ ---- +----------+ 305 |RAN|----( TN )----|UPF|----( TN )----|DN |----( TN )----|App Server| 306 +---+ ---- +---+ ---- +---+ ---- +----------+ 308 * TN = Transport Network 310 Figure 2: E2E communication between UE and CP 312 3. General Procedure for Interworking between 5G Network Slicing and 313 Transport Network 315 Figure 3 illustrates a general procedure for an interworking between 316 5G Network Slicing and Transport Network and we use following 317 terminology in this figure 318 o 5G User Plane Function : A function which is related to 5G user 319 plane. RAN, UPF, and DN are current 5G User Plane Fucntion 320 defined by 3GPP. 322 o NS Forwarding Policy DB : A database which maintains a forwarding 323 policy which needs to be applied to each NS instance. 325 o TE Indicator : An indicator which instructs an adequate forwarding 326 policy to router for the NS instance and encoded in an incoming 327 packet. MPLS label and SRv6 SRH are an example for TE indicator. 329 o 5G IP Packet : An IPv4/IPv6 packet sents from 5G network function. 331 The 5G network function performs the following procedures for an 332 interworking. 334 1. Recognize the NSI ID of an outgoing packet at 5G User Plane 335 Function 337 2. Decide an adequate forwarding policy which is performed on this 338 network slice instance by inquiring to the NS Forwarding Policy 339 DB. 341 3. Encapsulate an outgoing 5G IP Packet with an adequate TE 342 indicator for the forwarding policy of a network slice instance 344 4. Send the encapsulated packet to the transport network 345 5G Network Function 346 +-----------------+ 347 |+---------------+| 348 || NS Forwarding || 349 || Policy DB || 350 |+---------------+| 351 | /|\ | | 352 | | | | 353 | | | | 354 | | \|/ | 355 | +-------------+ | 356 | |5G User Plane| | 357 | | Function | | +------------+ +------------+ 358 | +-------------+ | |TE Indicator| |TE Indicator| 359 | | | +------------+ Router +------------+ 360 | \|/ | |5G IP Packet| +--------------+ |5G IP Packet| 361 | +----------+ | +------------+ | +----------+ | +------------+ 362 | |Data Plane|---+----------------+>|Data Plane|-|--------------> 363 | +----------+ | | +----------+ | Next Router 364 +-----------------+ +--------------+ 366 Figure 3: Interworking Procedure 368 Figure 4 shows an example of interworking procedure. In this 369 example, the 5G network function uses MPLS-TE for traffic engineering 370 in transport network and encapsulated with MPLS label which 371 represents an adequate MPLS-TE tunnel which fulfills requirements of 372 a network slice instance. The following list describes the detailed 373 procedure in this example. 375 1. 5G Network Function recognizes that the NSI ID of the outgoing 376 packet is 123 378 2. 5G Network Function resolves the required traffic engineering 379 policy is the MPLS-TE tunnel 123 for the network slice instance 381 3. 5G Network Function encapsulated the outgoing 5G IP packet with 382 MPLS label of 123 which is the outgoing label of the MPLS-TE 383 tunnel 123 385 4. 5G Network Function sends the encapsulated packet to the 386 transport network 388 5G Network Function 389 +-------------------+ 390 |+-----------------+| 391 || NS Forwarding || 392 || Policy DB || 393 || || 394 ||NSI ID:Policy || 395 || 111:MPLS-TE || 396 || tunnel 111|| 397 || (HighBW) || 398 || 123:MPLS-TE || 399 || tunnel 123|| 400 || (LowLatency)|| 401 |+-----------------+| 402 | /|\ | | 403 | | | | 404 | | | | 405 | +-------------+ | +------------+ +------------+ 406 | |5G User Plane| | | MPLS label | | MPLS label | 407 | | Function | | | 123 | | 234 | 408 | +-------------+ | |(tunnel 123)| |(tunnel 123)| 409 | | | +------------+ Router +------------+ 410 | \|/ | |5G IP Packet| +--------------+ |5G IP Packet| 411 | +----------+ | +------------+ | +----------+ | +------------+ 412 | |Data Plane|-----+----------------+>|Data Plane|-|--------------> 413 | +----------+ | | +----------+ | Next Router 414 +-------------------+ +--------------+ 416 Figure 4: Example of Interworking Procedure 418 4. Analysis on Interworking 420 This section describes an analysis on an interworking between the 5G 421 network slicing and the transport network both outside and inside 5G 422 core networks. 424 4.1. Analysis Assumption 426 Figure 5 and the following list illustrates an assumption on the 5G 427 network slicing for our analysis. Sharing of network function (UPF 428 and DN) among different network slice instances is suggested in 429 section 4.5 of [TS.28.530-3GPP]. 431 o UE can connect to the multiple network slice instances. 433 o RAN is a common network function to select adequate network slice 434 instance's UPF. 436 o UPF may be shared between different network slice instances. The 437 shared UPF has a common IP address/prefix for an endpoint. 439 o DN may be shared between different network slice instances. The 440 shared DN has a common IP address/prefix for an endpoint. 442 + - - - - - - - - - - - - - - - - + 443 | NS1 | 444 +-----+ +-----+ +---+ 445 +-----|---| UPF |-----| UPF |-----| |-| 446 | +-----+ +-----+ | | 447 | + - - - - - - - - - - - - - |DN | + 448 | + - - - - - - - - - - - - - | | + 449 | | NS2 | | | 450 +--+ +-+-+ +-----+ | | 451 |UE+----+RAN+---|---------------| |-----| |-| 452 +--+ +-+-+ | | +---+ 453 | + - - - - - - - | | - - - - - + 454 | + - - - - - - - | UPF | - - - - - + 455 | | NS3 | | | 456 | +-----+ | | +---+ 457 +-----|---| UPF |-----| |-----|DN |-| 458 +-----+ +-----+ +---+ 459 + - - - - - - - - - - - - - - - - + 461 Figure 5: Analysis Assumption 463 4.2. Analysis inside 5G Core Network 465 This section describes an analysis on an interworking between the 5G 466 network slicing and the transport network inside 5G core network 467 based on the procedure described in Section 3. The problem statement 468 in this analysis is emphasized as [PS-Interwork-X]. 470 [PS-Interwork-1]: 5G Network Function cannot recognize the NSI ID of 471 an established PDU session. Therefore, statically 472 configured Policy Based Routing(PBR) based traffic 473 engineering is required. 475 5G Network Function cannot recognize the NSI ID of an established PDU 476 session due to the following two reasons. 478 1. From the user plane perspective, the NSI ID is not encoded in any 479 header including GTP-U extension header. New PDU Session 480 Container GTP-U extension header is introduced for the 5G user 481 plane in [TS.29.281-3GPP], but the extension header only includes 482 QFI information. 484 2. From the control plane perspective, the NSI ID is not signaled to 485 the user plane function such as UPF. PFCP is extended for the 5G 486 control plane protocol in [TS.29.244-3GPP], however, the NSI ID 487 is not signaled to the user plane function. 489 For this problem statement, we have to statically configure a policy 490 based routing(PBR) based traffic engineering in the 5G network 491 function. In Figure 6, an example for statically configured PBR in 492 UPFb and UPFd is described in Figure 7. 494 + - - - - - - - - - - - - - - - - - - - + 495 | NS1 (NSI ID=1) | 496 +------+ +------+ +-----+ 497 +-----|-----| UPFa |-----| UPFb |-----| DNa | | 498 | +------+ +------+ +-----+ 499 | + - - - - - - - - - - - - - - - - - - - + 500 | + - - - - - - - - - - - - - - - - - - - + 501 | | NS2 (NSI ID=2) | 502 +--+ +-+-+ +------+ +------+ +-----+ 503 |UE+----+RAN+---|-----| |-----| |-----| DNb | | 504 +--+ +---+ | | | | +-----+ 505 | + - - | |- - -| | - - - - - - + 506 | + - - | UPFc |- - -| UPFd | - - - - - - + 507 | | | | | | | 508 | | | | | +-----+ 509 +-----|-----| |-----| |-----| DNc | | 510 +------+ +------+ +-----+ 511 | NS3 (NSI ID=3) | 512 + - - - - - - - - - - - - - - - - - - - + 514 Figure 6: Example for PBR based traffic engineering 516 In case of UPFd in Figure 6, statically configured PBR needs to 517 include a source IP address classification because a destination IP 518 address of next UPF (UPFc) is common as UPFc is shared between NS2 519 and NS3 as described in Section 4.1. 521 +------------------------------------------------------------+ 522 | Routing Table for UPFb | 523 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| 524 | IF: Subsequent Node IP address is | 525 | THEN: Nexthop is (for NS1) | 526 | | 527 | IF: Subsequent Node IP address is | 528 | THEN: Nexthop is (for NS2) | 529 +------------------------------------------------------------+ 531 +------------------------------------------------------------+ 532 |Routing Table for UPFd | 533 | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -| 534 | IF: Subsequent Node IP address is | 535 | AND Previous Node IP address is | 536 | THEN: Nexthop is (for NS2) | 537 | | 538 | IF: Subsequent Node IP address is | 539 | THEN: Nexthop is (for NS2) | 540 | | 541 | IF: Subsequent Node IP address is | 542 | AND Previous Node IP address is | 543 | THEN: Nexthop is (for NS3) | 544 | | 545 | IF: Subsequent Node IP address is | 546 | THEN: Nexthop is (for NS3) | 547 +------------------------------------------------------------+ 549 Figure 7: PBR based traffic engineering 551 [PS-Interwork-2]: 5G network function cannot classify a network 552 slice instance by using PBR If both previous node 553 and subsequent node are shared between different 554 network slice instances. 556 For example, a routing table for UPFc in Figure 6 toward RAN node 557 cannot classify NS2 and NS3, because previous node is UPFb which is 558 shared NS2 and NS3 and the subsequent node is RAN which is a common 559 network function among network slice instances as described in 560 Section 4.1. Therefore, the source IP address and the destination IP 561 address are common among NS2 and NS3, so we cannot create an adequate 562 PBR rule for each network slice instance. 564 4.3. Analysis outside 5G Core Network 566 TBD 568 5. Problem Statement Summary 570 The following list summarizes problem statements for the interworking 571 inside 5G core network. 573 [PS-Interwork-1]: 5G Network Function cannot recognize the NSI ID of 574 the established PDU session. Therefore, 575 statically configured Policy Based Routing(PBR) 576 based traffic engineering is required 578 [PS-Interwork-2]: 5G network function cannot classify the network 579 slice instance by using PBR If both previous node 580 and subsequent node are shared between different 581 network slice instances. 583 The following list summarizes problem statements for the interworking 584 outside 5G core network. 586 [PS-Interwork-3]: TBD 588 6. Conclusion 590 This document summarizes problem statements for an interworking 591 between 5G network slicing and transport network. Our analysis shows 592 the traffic engineering for a 5G network slicing is achieved by using 593 a policy based routing. However, if the 5G network function (e.g., 594 UPF) is shared among different network slice instances, there is a 595 case that the traffic engineering is not achieved because the 5G 596 network function cannot distinguish a network slice instance [PS- 597 Interwork-2]. This issue is inevitable under the current 5G 598 specification and we need to give the feedback to 3GPP to solve the 599 issue. 601 From the IETF perspective, "transport network management system" is 602 required from 3GPP SA5 WG as described in Section 2.2.3. This 603 transport network management system needs to serve a transport 604 network related request sent from a 3GPP management system, which 605 means the transport network management system needs to provide API to 606 the 3GPP management system to control the transport network from the 607 3GPP side. Therefore, IETF needs to collaborate with 3GPP, 608 specifically for 3GPP SA5 WG, and examine if the current standardized 609 technology and framework in the IETF activity fulfills requirements 610 from 3GPP. 612 7. Security Consideration 614 TBD 616 8. IANA Considerations 618 This document does not require any action from IANA. 620 9. Acknowledgement 622 The author would like to thank Takeshi Usui, Satoru Matsushima, 623 Shunsuke Homma for their useful comments. 625 10. Informative References 627 [TS.23.501-3GPP] 628 3rd Generation Partnership Project (3GPP), "3GPP TS 23.501 629 (V15.1.0): System Architecture for 5G System; Stage 2", 630 March 2018, . 633 [TS.28.530-3GPP] 634 3rd Generation Partnership Project (3GPP), "3GPP TS 28.530 635 (V1.0.0): Telecommunication management; Management and 636 orchestration of networks and network slicing; Concepts, 637 use cases and requirements", June 2018, 638 . 641 [TS.29.244-3GPP] 642 3rd Generation Partnership Project (3GPP), "3GPP TS 29.244 643 (V15.1.0): Interface between the Control Plane and the 644 User Plane Nodes; Stage 3", March 2018, 645 . 648 [TS.29.281-3GPP] 649 3rd Generation Partnership Project (3GPP), "3GPP TS 29.281 650 (V15.2.0): GPRS Tunneling Protocol User Plane (GTPv1-U)", 651 March 2018, . 654 Authors' Addresses 655 Takuya Miyasaka 656 KDDI Research 657 2-1-15, Ohara, Fujimino-shi 658 Saitama 356-8502 659 JP 661 Email: ta-miyasaka@kddi-research.jp 663 Kenji Kumaki 664 KDDI 665 3-22-7, Yoyogi, Shibuya-ku 666 Tokyo 151-0053 667 JP 669 Email: ke-kumaki@kddi.com 671 Tomonobu Niwa 672 KDDI 673 3-22-7, Yoyogi, Shibuya-ku 674 Tokyo 151-0053 675 JP 677 Email: to-niwa@kddi.com