[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        T. Miyasaka
Internet-Draft                                             KDDI Research
Intended status: Informational                                 K. Kumaki
Expires: December 28, 2018                                       T. Niwa
                                                                    KDDI
                                                           June 26, 2018


  Analysis and Problem Statements for Interworking between 5G Network
                     Slicing and Transport Network
                    draft-mink-5g-ns-transport-ps-00

Abstract

   This document describes problem statements for realizing an end-to-
   end network slicing that is expected to provide service-oriented
   communications between users and applications.  3GPP introduced the
   network slicing concept in the 5G architecture (3GPP Release 15),
   however, it mainly focuses on mobile access and core domains.  In
   order to reap the benefit of the concept, a network slicing needs to
   be designed across multiple domains of the network including non-3GPP
   parts.  This document analyzes the current 3GPP 5G network slicing
   architecture and summarizes problem statements for the interworking
   between the 5G network slicing and the transport network.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on December 28, 2018.

Copyright Notice

   Copyright (c) 2018 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Miyasaka, et al.        Expires December 28, 2018               [Page 1]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Scope of this document  . . . . . . . . . . . . . . . . .   3
   2.  5G Network Slicing and Transport Network  . . . . . . . . . .   5
     2.1.  5G Network Slicing  . . . . . . . . . . . . . . . . . . .   5
     2.2.  Transport Network for End-to-End 5G Communication . . . .   6
       2.2.1.  Transport Network inside 5G System  . . . . . . . . .   6
       2.2.2.  Transport Network outside 5G System . . . . . . . . .   6
       2.2.3.  Management and Orchestration of 5G Network Slicing  .   7
   3.  General Procedure for Interworking between 5G Network Slicing
       and Transport Network . . . . . . . . . . . . . . . . . . . .   7
   4.  Analysis on Interworking  . . . . . . . . . . . . . . . . . .  10
     4.1.  Analysis Assumption . . . . . . . . . . . . . . . . . . .  10
     4.2.  Analysis inside 5G Core Network . . . . . . . . . . . . .  11
     4.3.  Analysis outside 5G Core Network  . . . . . . . . . . . .  13
   5.  Problem Statement Summary . . . . . . . . . . . . . . . . . .  14
   6.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  14
   7.  Security Consideration  . . . . . . . . . . . . . . . . . . .  15
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .  15
   10. Informative References  . . . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   An End-to-End(E2E) network slicing is expected to cater to much
   greater diversity of requirements for wide variety of services such
   as V2X services and factory automation.  Here, the E2E means that a
   network slicing penetrates all network domains: mobile networks,
   transport networks and so forth.  Network operators anticipate that
   it is possible to tailor the network to fit for service-oriented
   demands in a timely and cost-effective way, which in turn reduces
   OPEX and CAPEX.

   3GPP is leading a network slicing concept in the 5G system (3GPP
   Release 15).  The 3GPP network slicing is defined as a logical
   network that provides specific network capabilities and network



Miyasaka, et al.        Expires December 28, 2018               [Page 2]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


   characteristics.  However, it covers a limited domains and mainly
   focuses on an isolation for the 5G network functions.  In order to
   achieve the goal, the network slicing needs to be designed from the
   E2E perspectives, not only 3GPP but also non-3GPP including transport
   networks.

   The way to map transport networks to the 5G system for a network
   slicing can be classified into two parts: inside and outside 5G
   system.  Inside 5G system, network connections between UE, RAN, UPF
   and DN can be identified as network slice with one or more QoS Flow
   rules, and thus its underlying transport network should also be aware
   of the network slice.  Outside 5G system, the E2E network slicing
   shall concatenate the network slicing whthin 5G systems with that of
   the following transport networks.  To this end, a method to stitch
   user plane traffic to/from UPF and logical tunnels in transport
   networks (e.g.  MPLS-TE) is required.

   Therefore, in terms of the E2E network slicing, the transport network
   shall accommodate to the 5G system.  This document analyzes the
   current 5G network slicing architecture and summarizes problem
   statements for the interworking between the 5G network slicing and
   the transport network.

1.1.  Scope of this document

   The scope of this document is to analyze an interworking between the
   5G network slicing and the transport network and summarize problem
   statements for the interworking.  Figure 1 shows an E2E communication
   between UE and CP(Content Provider Server) on 5G network slicing
   environment.  We define each term used in the scope with Figure 1 as
   follows.




















Miyasaka, et al.        Expires December 28, 2018               [Page 3]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


          + - - - - - - - - - - - - - - - - - - +
          | Network Slice Instance(NS1)         |
    +--+    +---+          +---+          +---+
    |UE+--|-+RAN|          |UPF|----------|DN | |
    +--+    +-|-+          +-|-+          +-|-+
          + - + - - - - - - -+- - - - - - - + - +
              |              |              |
        + - - + - - - - - - -|- - +   + - - + - - - - - - - - - +
        |     |              |    |   |     |                   |
              |    +----+    |              |    +----+
        |     |    | R2 |    |    |   |     |    | R6 |         |
              |    +----+    |              |    +----+
        |     |   /     \    |    |   |     |   /     \         |
           +--|-+/       \+--|-+         +--|-+/       \+----+     +--+
        |  | R1 |         | R4 |  |   |  | R5 |         | R8 |--+--|CP|
           +--|-+\       /+--|-+         +--|-+\       /+----+     +--+
        |     |   \     /    |    |   |     |   \     /         |
              |    +----+    |              |    +----+
        |     |    | R3 |    |    |   |     |    | R7 |         |
              |    +----+    |              |    +----+
        |     | Transport    |    |   |     | Transport         |
              | Network      |              | Network
        |     | Inside 5GC   |    |   |     | Outside 5GC       |
        + - - + - - - - - - -|- - +   + - - + - - - - - - - - - +
              |              |              |
          + - + - - - - - - -+- - - - - - - + - +
    +--+    +-|-+          +-|-+          +-|-+
    |UE+--|-+RAN|          |UPF|----------|DN | |
    +--+    +---+          +---+          +---+
          | Network Slice Instance(NS2)         |
          + - - - - - - - - - - - - - - - - - - +

               Figure 1: E2E communication between UE and CP

   o  Network slice instance

   The network slice instance is defined as "A set of Network Function
   instances and the required resources (e.g. compute, storage and
   networking resources) which form a deployed Network Slice" in
   [TS.23.501-3GPP].

   o  Transport network

   The definition of the transport network in this document is a network
   which provides a network connectivity to the 5G network functions
   such as UPF.  The scope of the the transport network in this document
   is limited to layer-3 network, thus IPv4 and IPv6.  This is because
   3GPP adopted IPv4/IPv6 as a transport network of the 5G user plane.



Miyasaka, et al.        Expires December 28, 2018               [Page 4]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


   There are two different transport networks in Figure 1: the transport
   network inside 5G core network consists of R1, R2, R3, and R4 and the
   transport network outside 5G core network consists of R5, R6, R7, and
   R8.  Both inside and outside networks are within the scope of this
   document.

   o  Traffic engineering

   The definition of traffic engineering in this document is to control
   the traffic path of IPv4/IPv6 packet in order to fulfill each network
   slice instance's requirements. (e.g. bandwidth and latency)

   For example, there are two network slice instance in Figure 1: NS1
   and NS2.  Suppose NS1 provides latency sensitive service such as V2X
   (in this case, UE is an automotive vehicle and CP is a control/
   monitoring server operated by a car vendor), an operator needs to
   perform traffic engineering in transport network to select a path
   that total latency between UE and CP is minimum.  If one-way latency
   is measured as follows,

   o  R1->R2->R4 : 1msec

   o  R1->R3->R4 : 2msec

   o  R5->R6->R8 : 9msec

   o  R5->R7->R8 : 6msec

   the traffic path of NS1 in the transport network inside 5G core
   network is R1->R2->R4 and the traffic path of NS1 in the transport
   network outside 5G core network is R5->R7->R8.  Therefore, the E2E
   communication from UE to CP is
   "UE->RAN->R1->R2->R4->UPF->DN->R5->R7->R8->CP".

   o  Interworking

   The definition of an interworking in this document is that the
   network slice instance and the transport network collaborate in order
   to perform the traffic engineering which fulfills requirements of the
   network slice instance.

2.  5G Network Slicing and Transport Network

2.1.  5G Network Slicing

   The 5G system architecture introduced the following key features:





Miyasaka, et al.        Expires December 28, 2018               [Page 5]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


   o  Separate the user plane (UP) functions from the control plane (CP)
      functions, allowing independent scalability and flexible
      deployments.

   o  Modularize the network function to enable the flexible and
      efficient network slicing.

   Thanks to the features, the deployed network slicing is comprised of
   a network slice instance that indicates a set of network
   functions(e.g.  UPF) and the required resources.  S-NSSAI(Single
   Network Slice Selection Assistance Information) is used to identify a
   network slice and assists the selection of a particular network slice
   instance corresponding to the slice.  A network slice instance can be
   associated with one or more S-NSSAIs, and an S-NSSAI can be
   associated with one or more network slice instances.  NSI ID(Network
   Slice Instance Identifier) may identify a network slice instance
   corresponding to a certain S-NSSAI.

2.2.  Transport Network for End-to-End 5G Communication

   An E2E network slicing needs a cross-domain technology that covers
   3GPP, transport networks and others (e.g. optical networks, data
   center networks).  For the 5G system, the transport networks are
   classifled two parts; inside and outside 5G systems.

2.2.1.  Transport Network inside 5G System

   A PDU session belongs to one and only one specific network slice
   instance in the 5G system.  The 5G QoS model is based on the QoS
   Flows that is the finest granularity of QoS differentiation in the
   PDU session.  The QoS Flow is characterised by QoS profiles for RAN,
   QoS rules for UE and PDR(Packet Detection Rule) for UPF.  DSCP can be
   optinally utilized to support the QoS Flow, however, the QoS Flow
   does not correspond to the network slice one by one.  Therefore, a
   network slice can not be identified from the transport network
   perspective.  Regarding the transport connectivity between different
   3GPP nodes in the network slice instance, transport networks shall
   take 3GPP link requirements (e.g.  NSI ID, topology, QoS parameters,
   etc.) from the network slice into account.

2.2.2.  Transport Network outside 5G System

   The S-NSSAI instructs which a PDU session is associated with a DN and
   a network slice instance.  In the current 3GPP specification,
   transport networks cannot recognize the S-NSSAI or the NSI ID from UP
   directly and thus cannot map the network slicing in the 3GPP system
   to that of transport networks.




Miyasaka, et al.        Expires December 28, 2018               [Page 6]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


2.2.3.  Management and Orchestration of 5G Network Slicing

   The management and orchestration of the 5G network slicing is studied
   in 3GPP SA5.  This study includes creation, modification, and
   elimination of the network slice instance from the 3GPP management
   system.

   In this 3GPP management system, the coordination with the management
   system of non-3GPP parts also has been taken into account and the
   transport network management is included in the scope of the
   management system.  Figure 2 shows a concept of the 3GPP management
   system and a coordination with the transport network management
   system, which is described in section 4.7 of [TS.28.530-3GPP]
   However, the detailed analysis for the coordination with the
   transport network management system is not studied.


                     +------------------------+
                     | 3GPP Management System |
                     +------------------------+
                                /|\
                                 |
                                 |
                                \|/
                       +-------------------+
                       | Transport Network |
                       | Management System |
                       +-------------------+
                         /|\    /|\    /|\
                          |      |      |
               +----------+      |      +------------+
               |                 |                   |
              \|/               \|/                 \|/
   +---+     ----     +---+     ----     +---+     ----     +----------+
   |RAN|----( TN )----|UPF|----( TN )----|DN |----( TN )----|App Server|
   +---+     ----     +---+     ----     +---+     ----     +----------+

                                                * TN = Transport Network

               Figure 2: E2E communication between UE and CP

3.  General Procedure for Interworking between 5G Network Slicing and
    Transport Network

   Figure 3 illustrates a general procedure for an interworking between
   5G Network Slicing and Transport Network and we use following
   terminology in this figure




Miyasaka, et al.        Expires December 28, 2018               [Page 7]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


   o  5G User Plane Function : A function which is related to 5G user
      plane.  RAN, UPF, and DN are current 5G User Plane Fucntion
      defined by 3GPP.

   o  NS Forwarding Policy DB : A database which maintains a forwarding
      policy which needs to be applied to each NS instance.

   o  TE Indicator : An indicator which instructs an adequate forwarding
      policy to router for the NS instance and encoded in an incoming
      packet.  MPLS label and SRv6 SRH are an example for TE indicator.

   o  5G IP Packet : An IPv4/IPv6 packet sents from 5G network function.

   The 5G network function performs the following procedures for an
   interworking.

   1.  Recognize the NSI ID of an outgoing packet at 5G User Plane
       Function

   2.  Decide an adequate forwarding policy which is performed on this
       network slice instance by inquiring to the NS Forwarding Policy
       DB.

   3.  Encapsulate an outgoing 5G IP Packet with an adequate TE
       indicator for the forwarding policy of a network slice instance

   4.  Send the encapsulated packet to the transport network
























Miyasaka, et al.        Expires December 28, 2018               [Page 8]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


     5G Network Function
    +-----------------+
    |+---------------+|
    || NS Forwarding ||
    || Policy DB     ||
    |+---------------+|
    |   /|\    |      |
    |    |     |      |
    |    |     |      |
    |    |    \|/     |
    | +-------------+ |
    | |5G User Plane| |
    | |  Function   | | +------------+                  +------------+
    | +-------------+ | |TE Indicator|                  |TE Indicator|
    |       |         | +------------+      Router      +------------+
    |      \|/        | |5G IP Packet| +--------------+ |5G IP Packet|
    |  +----------+   | +------------+ | +----------+ | +------------+
    |  |Data Plane|---+----------------+>|Data Plane|-|-------------->
    |  +----------+   |                | +----------+ |    Next Router
    +-----------------+                +--------------+

                     Figure 3: Interworking Procedure

   Figure 4 shows an example of interworking procedure.  In this
   example, the 5G network function uses MPLS-TE for traffic engineering
   in transport network and encapsulated with MPLS label which
   represents an adequate MPLS-TE tunnel which fulfills requirements of
   a network slice instance.  The following list describes the detailed
   procedure in this example.

   1.  5G Network Function recognizes that the NSI ID of the outgoing
       packet is 123

   2.  5G Network Function resolves the required traffic engineering
       policy is the MPLS-TE tunnel 123 for the network slice instance

   3.  5G Network Function encapsulated the outgoing 5G IP packet with
       MPLS label of 123 which is the outgoing label of the MPLS-TE
       tunnel 123

   4.  5G Network Function sends the encapsulated packet to the
       transport network









Miyasaka, et al.        Expires December 28, 2018               [Page 9]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


    5G Network Function
   +-------------------+
   |+-----------------+|
   || NS Forwarding   ||
   || Policy DB       ||
   ||                 ||
   ||NSI ID:Policy    ||
   ||   111:MPLS-TE   ||
   ||       tunnel 111||
   ||       (HighBW)  ||
   ||   123:MPLS-TE   ||
   ||       tunnel 123||
   ||     (LowLatency)||
   |+-----------------+|
   |   /|\    |        |
   |    |     |        |
   |    |     |        |
   | +-------------+   | +------------+                  +------------+
   | |5G User Plane|   | | MPLS label |                  | MPLS label |
   | |  Function   |   | |    123     |                  |    234     |
   | +-------------+   | |(tunnel 123)|                  |(tunnel 123)|
   |       |           | +------------+      Router      +------------+
   |      \|/          | |5G IP Packet| +--------------+ |5G IP Packet|
   |  +----------+     | +------------+ | +----------+ | +------------+
   |  |Data Plane|-----+----------------+>|Data Plane|-|-------------->
   |  +----------+     |                | +----------+ |    Next Router
   +-------------------+                +--------------+

                Figure 4: Example of Interworking Procedure

4.  Analysis on Interworking

   This section describes an analysis on an interworking between the 5G
   network slicing and the transport network both outside and inside 5G
   core networks.

4.1.  Analysis Assumption

   Figure 5 and the following list illustrates an assumption on the 5G
   network slicing for our analysis.  Sharing of network function (UPF
   and DN) among different network slice instances is suggested in
   section 4.5 of [TS.28.530-3GPP].

   o  UE can connect to the multiple network slice instances.

   o  RAN is a common network function to select adequate network slice
      instance's UPF.




Miyasaka, et al.        Expires December 28, 2018              [Page 10]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


   o  UPF may be shared between different network slice instances.  The
      shared UPF has a common IP address/prefix for an endpoint.

   o  DN may be shared between different network slice instances.  The
      shared DN has a common IP address/prefix for an endpoint.

                            + - - - - - - - - - - - - - - - - +
                            | NS1                             |
                                +-----+     +-----+     +---+
                      +-----|---| UPF |-----| UPF |-----|   |-|
                      |         +-----+     +-----+     |   |
                      |     + - - - - - - - - - - - - - |DN | +
                      |     + - - - - - - - - - - - - - |   | +
                      |     | NS2                       |   | |
            +--+    +-+-+                   +-----+     |   |
            |UE+----+RAN+---|---------------|     |-----|   |-|
            +--+    +-+-+                   |     |     +---+
                      |     + - - - - - - - |     | - - - - - +
                      |     + - - - - - - - | UPF | - - - - - +
                      |     | NS3           |     |           |
                      |         +-----+     |     |     +---+
                      +-----|---| UPF |-----|     |-----|DN |-|
                                +-----+     +-----+     +---+
                            + - - - - - - - - - - - - - - - - +

                       Figure 5: Analysis Assumption

4.2.  Analysis inside 5G Core Network

   This section describes an analysis on an interworking between the 5G
   network slicing and the transport network inside 5G core network
   based on the procedure described in Section 3.  The problem statement
   in this analysis is emphasized as [PS-Interwork-X].

   [PS-Interwork-1]:  5G Network Function cannot recognize the NSI ID of
                      an established PDU session.  Therefore, statically
                      configured Policy Based Routing(PBR) based traffic
                      engineering is required.

   5G Network Function cannot recognize the NSI ID of an established PDU
   session due to the following two reasons.

   1.  From the user plane perspective, the NSI ID is not encoded in any
       header including GTP-U extension header.  New PDU Session
       Container GTP-U extension header is introduced for the 5G user
       plane in [TS.29.281-3GPP], but the extension header only includes
       QFI information.




Miyasaka, et al.        Expires December 28, 2018              [Page 11]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


   2.  From the control plane perspective, the NSI ID is not signaled to
       the user plane function such as UPF.  PFCP is extended for the 5G
       control plane protocol in [TS.29.244-3GPP], however, the NSI ID
       is not signaled to the user plane function.

   For this problem statement, we have to statically configure a policy
   based routing(PBR) based traffic engineering in the 5G network
   function.  In Figure 6, an example for statically configured PBR in
   UPFb and UPFd is described in Figure 7.

                         + - - - - - - - - - - - - - - - - - - - +
                         | NS1 (NSI ID=1)                        |
                               +------+     +------+     +-----+
                   +-----|-----| UPFa |-----| UPFb |-----| DNa | |
                   |           +------+     +------+     +-----+
                   |     + - - - - - - - - - - - - - - - - - - - +
                   |     + - - - - - - - - - - - - - - - - - - - +
                   |     | NS2 (NSI ID=2)                        |
         +--+    +-+-+         +------+     +------+     +-----+
         |UE+----+RAN+---|-----|      |-----|      |-----| DNb | |
         +--+    +---+         |      |     |      |     +-----+
                   |     + - - |      |- - -|      | - - - - - - +
                   |     + - - | UPFc |- - -| UPFd | - - - - - - +
                   |     |     |      |     |      |             |
                   |           |      |     |      |     +-----+
                   +-----|-----|      |-----|      |-----| DNc | |
                               +------+     +------+     +-----+
                         | NS3 (NSI ID=3)                        |
                         + - - - - - - - - - - - - - - - - - - - +

            Figure 6: Example for PBR based traffic engineering

   In case of UPFd in Figure 6, statically configured PBR needs to
   include a source IP address classification because a destination IP
   address of next UPF (UPFc) is common as UPFc is shared between NS2
   and NS3 as described in Section 4.1.















Miyasaka, et al.        Expires December 28, 2018              [Page 12]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


        +------------------------------------------------------------+
        | Routing Table for UPFb                                     |
        | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
        | IF: Subsequent Node IP address is <IP address of UPFa>     |
        | THEN: Nexthop is <MPLS-TE tunnel 1> (for NS1)              |
        |                                                            |
        | IF: Subsequent Node IP address is <IP address of DNa>      |
        | THEN: Nexthop is <MPLS-TE tunnel 2> (for NS2)              |
        +------------------------------------------------------------+

        +------------------------------------------------------------+
        |Routing Table for UPFd                                      |
        | - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -|
        | IF: Subsequent Node IP address is <IP address of UPFc>     |
        |     AND Previous Node IP address is <IP address of DNb>    |
        | THEN: Nexthop is <MPLS-TE tunnel 1> (for NS2)              |
        |                                                            |
        | IF: Subsequent Node IP address is <IP address of DNb>      |
        | THEN: Nexthop is <MPLS-TE tunnel 2> (for NS2)              |
        |                                                            |
        | IF: Subsequent Node IP address is <IP address of UPFc>     |
        |     AND Previous Node IP address is <IP address of DNc>    |
        | THEN: Nexthop is <MPLS-TE tunnel 3> (for NS3)              |
        |                                                            |
        | IF: Subsequent Node IP address is <IP address of DNc>      |
        | THEN: Nexthop is <MPLS-TE tunnel 4> (for NS3)              |
        +------------------------------------------------------------+

                  Figure 7: PBR based traffic engineering

   [PS-Interwork-2]:  5G network function cannot classify a network
                      slice instance by using PBR If both previous node
                      and subsequent node are shared between different
                      network slice instances.

   For example, a routing table for UPFc in Figure 6 toward RAN node
   cannot classify NS2 and NS3, because previous node is UPFb which is
   shared NS2 and NS3 and the subsequent node is RAN which is a common
   network function among network slice instances as described in
   Section 4.1.  Therefore, the source IP address and the destination IP
   address are common among NS2 and NS3, so we cannot create an adequate
   PBR rule for each network slice instance.

4.3.  Analysis outside 5G Core Network

   TBD





Miyasaka, et al.        Expires December 28, 2018              [Page 13]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


5.  Problem Statement Summary

   The following list summarizes problem statements for the interworking
   inside 5G core network.

   [PS-Interwork-1]:  5G Network Function cannot recognize the NSI ID of
                      the established PDU session.  Therefore,
                      statically configured Policy Based Routing(PBR)
                      based traffic engineering is required

   [PS-Interwork-2]:  5G network function cannot classify the network
                      slice instance by using PBR If both previous node
                      and subsequent node are shared between different
                      network slice instances.

   The following list summarizes problem statements for the interworking
   outside 5G core network.

   [PS-Interwork-3]:  TBD

6.  Conclusion

   This document summarizes problem statements for an interworking
   between 5G network slicing and transport network.  Our analysis shows
   the traffic engineering for a 5G network slicing is achieved by using
   a policy based routing.  However, if the 5G network function (e.g.,
   UPF) is shared among different network slice instances, there is a
   case that the traffic engineering is not achieved because the 5G
   network function cannot distinguish a network slice instance [PS-
   Interwork-2].  This issue is inevitable under the current 5G
   specification and we need to give the feedback to 3GPP to solve the
   issue.

   From the IETF perspective, "transport network management system" is
   required from 3GPP SA5 WG as described in Section 2.2.3.  This
   transport network management system needs to serve a transport
   network related request sent from a 3GPP management system, which
   means the transport network management system needs to provide API to
   the 3GPP management system to control the transport network from the
   3GPP side.  Therefore, IETF needs to collaborate with 3GPP,
   specifically for 3GPP SA5 WG, and examine if the current standardized
   technology and framework in the IETF activity fulfills requirements
   from 3GPP.








Miyasaka, et al.        Expires December 28, 2018              [Page 14]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


7.  Security Consideration

   TBD

8.  IANA Considerations

   This document does not require any action from IANA.

9.  Acknowledgement

   The author would like to thank Takeshi Usui, Satoru Matsushima,
   Shunsuke Homma for their useful comments.

10.  Informative References

   [TS.23.501-3GPP]
              3rd Generation Partnership Project (3GPP), "3GPP TS 23.501
              (V15.1.0): System Architecture for 5G System; Stage 2",
              March 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
              Rel-15/23_series/23501-f10.zip>.

   [TS.28.530-3GPP]
              3rd Generation Partnership Project (3GPP), "3GPP TS 28.530
              (V1.0.0): Telecommunication management; Management and
              orchestration of networks and network slicing; Concepts,
              use cases and requirements", June 2018,
              <http://ftp.3gpp.org//Specs/
              archive/28_series/28.530/28530-100.zip>.

   [TS.29.244-3GPP]
              3rd Generation Partnership Project (3GPP), "3GPP TS 29.244
              (V15.1.0): Interface between the Control Plane and the
              User Plane Nodes; Stage 3", March 2018,
              <http://www.3gpp.org/FTP/Specs/2018-03/
              Rel-15/29_series/29244-f10.zip>.

   [TS.29.281-3GPP]
              3rd Generation Partnership Project (3GPP), "3GPP TS 29.281
              (V15.2.0): GPRS Tunneling Protocol User Plane (GTPv1-U)",
              March 2018, <http://www.3gpp.org/FTP/Specs/2018-03/
              Rel-15/29_series/29281-f20.zip>.

Authors' Addresses








Miyasaka, et al.        Expires December 28, 2018              [Page 15]


Internet-Draft      draft-mink-5g-ns-transport-ps-00           June 2018


   Takuya Miyasaka
   KDDI Research
   2-1-15, Ohara, Fujimino-shi
   Saitama  356-8502
   JP

   Email: ta-miyasaka@kddi-research.jp


   Kenji Kumaki
   KDDI
   3-22-7, Yoyogi, Shibuya-ku
   Tokyo  151-0053
   JP

   Email: ke-kumaki@kddi.com


   Tomonobu Niwa
   KDDI
   3-22-7, Yoyogi, Shibuya-ku
   Tokyo  151-0053
   JP

   Email: to-niwa@kddi.com


























Miyasaka, et al.        Expires December 28, 2018              [Page 16]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/