DMM Working Group                                          S. Matsushima
Internet-Draft                                                  SoftBank
Intended status: Standards Track                             C. Filsfils
Expires: January 3, April 25, 2019                                         M. Kohno
                                                            P. Camarillo
                                                     Cisco Systems, Inc.
                                                                D. Voyer
                                                             Bell Canada
                                                              C. Perkins
                                                               Futurewei
                                                            July 2,
                                                        October 22, 2018

               Segment Routing IPv6 for Mobile User Plane
                  draft-ietf-dmm-srv6-mobile-uplane-02
                  draft-ietf-dmm-srv6-mobile-uplane-03

Abstract

   This document discusses shows the applicability of SRv6 (Segment Routing IPv6)
   to the user-plane of mobile networks (N3 and N9 interfaces). networks.  The
   source routing capability and the network programming nature
   of SRv6, SRv6 accomplish mobile user-plane functions in a simple manner.
   The statelessness of SRv6 and the its ability to control underlying both service
   layer will path and underlying transport can be
   even more beneficial to the mobile
   user-plane, in terms of providing flexibility and SLA control for various
   applications.  It also
   simplifies the network architecture by eliminating  This document describes the necessity of
   tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS, SRv6 mobile user plane
   behavior and so on.  In addition, Segment Routing defines the SID functions for that.  It also provides an enhanced method a
   mechanism for end-to-end network slicing, which is briefly introduced by this document. slicing.

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 January 3, April 25, 2019.

Copyright Notice

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

   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Motivation
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Reference Architecture
     2.3.  Predefined SRv6 Functions . . . . . . . . . . . . . . . .   4
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  A 3GPP Reference Architecture . . . . . . . . . . . . . . . .   6
   5.  User-plane behaviors  . . . . . . . . . . . . . . . . . . . .   6   7
     5.1.  Traditional mode (formerly Basic mode)  . . . . . . . . . . . . . . . . . . . .   7
       5.1.1.  Packet flow - Uplink  . . . . . . . . . . . . . . . .   7   8
       5.1.2.  Packet flow - Downlink  . . . . . . . . . . . . . . .   8
       5.1.3.  IPv6 user-traffic . . . . . . . . . . . . . . . . . .   8   9
     5.2.  Enhanced Mode (formerly Aggregate mode) . . . . . . . . .   8 . . . . . . . . . . . . .   9
       5.2.1.  Packet flow - Uplink  . . . . . . . . . . . . . . . .   9  10
       5.2.2.  Packet flow - Downlink  . . . . . . . . . . . . . . .  10
       5.2.3.  IPv6 user-traffic . . . . . . . . . . . . . . . . . .  10  11
     5.3.  Enhanced mode with unchanged gNB GTP behavior . . . . . .  11
       5.3.1.  Interworking with IPv6 GTP  . . . . . . . . . . . . .  11  12
       5.3.2.  Interworking with IPv4 GTP  . . . . . . . . . . . . .  14  15
       5.3.3.  Extensions to the interworking mechanisms . . . . . .  17
   6.  SRv6 SID Mobility Functions . . . . . . . . . . . . . . . . .  17  18
     6.1.  End.MAP: Endpoint function with SID mapping  Args.Mob.Session  . . . . . . .  17
     6.2.  End.M.GTP6.D: Endpoint function with decapsulation from
           IPv6/GTP tunnel . . . . . . . . . . . . .  18
     6.2.  End.MAP . . . . . . . .  17
     6.3.  End.M.GTP6.E: Endpoint function with encapsulation for
           IPv6/GTP tunnel . . . . . . . . . . . . . . . . .  18
     6.3.  End.M.GTP6.D  . . . .  18
     6.4.  End.M.GTP4.E: Endpoint function with encapsulation for
           IPv4/GTP tunnel . . . . . . . . . . . . . . . . . .  19
     6.4.  End.M.GTP6.E  . . .  18
     6.5.  T.M.Tmap: Transit behavior with IPv4/GTP decapsulation
           and mapping into an SRv6 Policy . . . . . . . . . . . . .  19
     6.6.  End.Limit: Rate Limiting function . . . . . .  19
     6.5.  End.M.GTP4.E  . . . . . .  20
   7.  SRv6 supported PDU session types . . . . . . . . . . . . . .  20 . .  20
     6.6.  T.M.Tmap  . . . . . . . . . . . . . . . . . . . . . . . .  20
     6.7.  End.Limit: Rate Limiting function . . . . . . . . . . . .  21
   7.  SRv6 supported 3GPP PDU session types . . . . . . . . . . . .  22
   8.  Network Slicing Considerations  . . . . . . . . . . . . . . .  21  22
   9.  Control Plane Considerations  . . . . . . . . . . . . . . . .  21  22
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  22  23
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  22  23
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  22  23
   13. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  22  23
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  22  24
     14.1.  Normative References . . . . . . . . . . . . . . . . . .  22  24
     14.2.  Informative References . . . . . . . . . . . . . . . . .  23  24
   Appendix A.  Implementations  . . . . . . . . . . . . . . . . . .  25  26
   Appendix B.  Changes from revision 02 to revision 03  . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25  27

1.  Introduction

   In mobile networks, mobility management systems provide connectivity
   while mobile nodes move around. move.  While the control-plane of the system
   signals movements of a mobile node, the user-plane establishes a
   tunnel between the mobile node and its anchor node over IP based IP-based
   backhaul and core networks.

   This document discusses shows the applicability of SRv6 (Segment Routing IPv6)
   to those mobile networks.  SRv6 provides source routing to networks where
   so that operators can explicitly indicate a route for the packets from and to
   and from the mobile node.  SRv6 endpoint nodes perform serve as the
   roles of anchor anchors
   of mobile user-plane.

2.  Conventions and Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

   SRH is the abbreviation for the Segment Routing Header.  We assume
   that the SRH may be present multiple times inside each packet.

   NH is the abbreviation

2.1.  Terminology

   o  AMBR: Aggregate Maximum Bit Rate
   o  APN: Access Point Name (commonly used to identify a network or
      class of the service)
   o  BSID: SR Binding SID [RFC8402]
   o  CNF: Cloud-native Network Function
   o  gNB: gNodeB
   o  NH: The IPv6 next-header field.
   o  NFV: Network Function Virtualization
   o  PDU: Packet Data Unit
   o  Session: TBD...
   o  SID: A Segment Identifier which represents a specific segment in a
      segment routing domain.
   o  SRH: The Segment Routing Header.
      [I-D.ietf-6man-segment-routing-header]
   o  TEID: Tunnel Endpoint Identifier
   o  UE: User Equipment
   o  UPF: User Plane Function
   o  VNF: Virtual Network Function

2.2.  Conventions

   o  NH=SRH means that the next-header field NH is 43 with routing type 4.

   When there are multiple SRHs,
   o  Multiple SRHs may be present inside each packet, but they must
      follow each other: the next-
   header other.  The next-header field of all each SRH, except the
      last one, must be SRH.

   The effective next-header (ENH) is the next-header field of the IP
   header when NH-SRH (43 type 4).
   o  For simplicity, no SRH is present, or is the next-header field of other extension headers are shown except the
   last
      SRH.

   In this version of the document, we assume that there is no other
   extension header than the SRH.  This will be lifted in future
   versions of the document.

   SID: A Segment Identifier which represents a specific segment in
   segment routing domain.
   o  The SID type used in this document is IPv6 address (also referenced as called
      SRv6 Segment or SRv6 SID).
   o  gNB::1 is an IPv6 address (SID) assigned to the gNB.
   o  U1::1 is an IPv6 address (SID) assigned to UPF1.
   o  U2::1 is an IPv6 address (SID) assigned to UPF2.
   o  U2:: is some other IPv6 address (SID) assigned to UPF2.
   o  A SID list is represented as <S1, S2, S3> where S1 is the first
      SID to visit, S2 is the second SID to visit and S3 is the last SID
      to visit along the SR path.
   o  (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:

   o

      *  IPv6 header with source and destination addresses respectively SA and DA
         respectively, and next-header is SRH
   o  SRH SRH, with SID list <S1, S2, S3>
         with SegmentsLeft = SL
      *  The payload of the packet is not represented.
   o  Note the difference between the <> and () symbols: <S1, S2, S3>
      represents a SID list where S1 is the first SID and S3 is the last
      SID.  (S3, S2, S1; SL) represents the same SID list but encoded in
      the SRH format where the rightmost SID in the SRH is the first SID
      and the leftmost SID in the SRH is the last SID.  When referring
      to an SR policy in a high-level use-case, it is simpler to use the
      <S1, S2, S3> notation.  When referring to an illustration of the
      detailed behavior, the (S3, S2, S1; SL) notation is more
      convenient.
   o  The payload of the packet is omitted.  SRH[SL] represents the SID pointed by the SL field in the first
      SRH.  In our example, SRH[2] represents S1, SRH[1] represents S2
      and SRH[0] represents S3.

   FIB is
   o  SRH[SL] can be different from the abbreviation for DA of the forwarding table.  A FIB lookup is a
   lookup IPv6 header.

2.3.  Predefined SRv6 Functions

   The following functions are defined in
   [I-D.filsfils-spring-srv6-network-programming].

   o  End.DT4 means to decapsulate and forward using a specific IPv4
      table lookup.

   o  End.DT6 means to decapsulate and forward using a specific IPv6
      table lookup.
   o  End.DX4 means to decapsulate and forward through a particular link
      configured with the forwarding table.  When SID.
   o  End.DX6 means to decapsulate and forward through a packet is intercepted on particular link
      configured with the SID.
   o  End.T means to forward using a
   wire, it is possible that SRH[SL] specific IPv6 table lookup.
   o  End.X means to forward through a link configured with the SID.
   o  T.Encaps.Red means encapsulation without pushing SRH (resulting in
      "Reduced" packet size).
   o  PSP means Penultimate Segment Pop.  The packet is different from subsequently
      forwarded without the DA. popped SRH.

   New SRv6 functions are defined in Section 6 to support the needs of
   the mobile user plane.

3.  Motivation

   Every day mobility

   Mobility networks are getting becoming more challenging to operate:
   on operate.  On one
   hand, traffic is constantly growing, and latency requirements are
   more strict; on the other-hand, there are new use-cases like NFV that
   are also challenging network management.

   Problem comes from the fact that the

   The current architecture of mobile networks is agnostic to does not take into
   account the underlying transport.  Indeed, it rigidly
   fragments the  The user-plane is rigidly
   fragmented into radio access, core and service networks
   and connects them networks, connected by
   tunneling techniques through the according to user-plane roles such as access and anchor
   nodes.  Such agnosticism and
   rigidness make  These factors have made it difficult for the operator to
   optimize and operate the data-path.

   While

   In the mobile network industry has been trying to solve those
   problems, meantime, applications have shifted to use IPv6, and network
   operators have started adopting IPv6 as their IP transport as well. transport.  SRv6,
   the IPv6 dataplane instantiation of Segment Routing
   [I-D.ietf-spring-segment-routing], [RFC8402],
   integrates both the application data-path and the underlying
   transport layer into one a single protocol, allowing operators to
   optimize the network in a simplified manner and removing forwarding
   state from the network.

   Further on,  It is also suitable for virtualized
   environments, VNF/CNF to VNF/CNF networking.

   SRv6 introduces the notion of specifies network-programming
   [I-D.filsfils-spring-srv6-network-programming], that applied (see
   [I-D.filsfils-spring-srv6-network-programming]).  Applied to
   mobility fulfils
   mobility, SRv6 can provide the user-plane functions of needed for
   mobility management.  SRv6 takes advantage of underlying transport
   awareness and flexibility to deploy improve mobility user-plane functions in an optimized
   manner.  Those are the motivations to adopt SRv6 functions.

   The use-cases for mobile user-
   plane. SRv6 mobility are discussed in
   [I-D.camarilloelmalky-springdmm-srv6-mob-usecases].

4.  A 3GPP Reference Architecture

   This section describes presents a reference architecture and possible
   deployment scenarios.

   Figure 1 shows a reference architecture, based on diagram from the 5G packet core
   architecture [TS.23501].

   Please note that all the user-plane

   The user plane described in this document does not depend on any
   specific architecture.  This  The 5G packet core architecture is just
   used as a reference shown is
   based on the latest 3GPP standards at the time of writing this draft.
   Other type of architectures can be seen in [I-D.gundavelli-dmm-mfa] and
   [WHITEPAPER-5G-UP].

                                  +-----+
                                  | AMF |
                                  +-----+
                                 /    | [N11]
                          [N2]  /  +-----+
                        +------/   | SMF |
                       /           +-----+
                      /              / \
                     /              /   \  [N4]
                    /              /     \                    ________
                   /              /       \                  /        \
   +--+      +-----+ [N3] +------+  [N9]  +------+  [N6]    /          \
   |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \    DN    /
   +--+      +-----+      +------+        +------+           \________/

                 Figure 1: 3GPP 5G Reference Architecture

   o  UE : User Equipment
   o  gNB :  gNB: gNodeB
   o  UPF : User Plane Function

      *  UPF1: UPF with Interfaces N3 and N9
      *
   o  UPF2: UPF with Interfaces N9 and N6
      *  Note: For simplicity we don't depict a UPF that is only
         connected to N9 interfaces, although the techniques described
         in this document are also valid in such case.
   o  SMF :  SMF: Session Management Function
   o  AMF :  AMF: Access and Mobility Management Function
   o  DN :  DN: Data Network e.g. operator services, Internet access

   A

   This reference diagram does not depict a UPF that is only connected
   to N9 interfaces, although the description in this document also work
   for such UPFs.

   Each session from an UE gets assigned to an a UPF.  Sometimes more than
   one UPF multiple
   UPFs may be used for used, providing a certain kind of richer service functions.  A UE gets its
   IP address from the DHCP block of its UPF.  The UPF advertises the that
   IP address block towards toward the Internet Internet, ensuring that return traffic is
   routed to the right UPF.

5.  User-plane behaviors

   This section describes the some mobile user-plane behaviors using SRv6.

   In order to simplify the SRv6 adoption, adoption of SRv6, we present two different
   "modes" that vary with respect to the SRv6 SID allocation. use of SRv6.  The first one is
   the "Traditional mode", which inherits the traditional current 3GPP mobile
   user-plane. user-
   plane.  In this mode there is no change to mobility networks
   architecture, except for the pure replacement of that GTP-U [TS.29281] for is replaced by SRv6.

   The second mode is the "Enhanced mode", which aggregates the mobile
   sessions and allocates SID on a per policy basis.  The benefit of the
   latter is that mode".  In this mode the SR policy
   contains SIDs for Traffic Engineering and VNFs.  Both of these modes VNFs, which results in
   effective end-to-end network slices.

   In both, the Traditional and the Enhanced modes, we assume both that the
   gNB and as well as the UPFs are SR-
   aware (N3 and SR-aware (N3, N9 and -potentially- N6
   interfaces are SRv6).

   Additionally, we

   We introduce a new "Enhanced mode with unchanged gNB
   GTP behavior".  This mode consists of two mechanisms for interworking with legacy access
   networks -interface N3 unmodified-. (N3 interface is unmodified).  In these document we
   introduce them applied to the Enhanced mode, although they could be
   used in combination with the Traditional mode as well.

   One of these
   mechanism mechanisms is designed to interwork with legacy gNBs
   using GTP/IPv4.  The second method is designed to interwork with
   legacy gNBs using GTP/IPv6.

   This section makes reference to already existing document uses SRv6 functions defined in
   [I-D.filsfils-spring-srv6-network-programming] as well as new SRv6
   functions designed for the mobile userplane. user plane.  The new SRv6 functions
   are detailed in the Section 6.

5.1.  Traditional mode (formerly Basic mode)

   In the traditional mode, we assume that mobile user-plane functions
   are the same as existing ones mobile UPFs remain unchanged
   except for the use of SRv6 as the data plane instead of GTP-U.  No  There
   is no impact to the rest of mobile system
   should be expected. system.

   In the traditional existing 3GPP mobile network, networks, an UE session is mapped 1-for-1
   with a specific GTP tunnel (TEID).  This 1-for-1 mapping is
   replicated here to replace the GTP encaps encapsulation with the SRv6 encaps,
   encapsulation, while not changing anything else.

   This

   The traditional mode minimizes the changes required to the entire system and mobile
   system; it is a good starting point for forming the a common basis.  Note that in
   this mode the TEID is embedded in each SID.

   Our reference example topology is shown in Figure 2.  In this traditional mode we assume
   that the
   gNB and the UPFs are SR-aware.  In the descriptions of the uplink and
   downlink packet flow, A is an IPv6 address of the UE, and Z is an
   IPv6 address reachable within the Data Network DN.  A new SRv6
   function End.MAP, defined in Section 6.2, is used.

                                                              ________
                     SRv6           SRv6                     /        \
   +--+      +-----+ [N3] +------+  [N9]  +------+  [N6]    /          \
   |UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \    DN    /
   +--+      +-----+      +------+        +------+           \________/
            SRv6 node     SRv6 node       SRv6 node

               Figure 2: Traditional mode - Reference example topology

5.1.1.  Packet flow - Uplink

   The uplink packet flow is the following: as follows:

         UE_out  : (A,Z)
         gNB_out : (gNB, U1::1) (A,Z)     -> T.Encaps.Reduced T.Encaps.Red <U1::1>
         UPF1_out: (gNB, U2::1) (A,Z)     -> End.MAP
         UPF2_out: (A,Z)                  -> End.DT4 or End.DT6

   The

   When the UE packet arrives to at the gNB, the gNB.  The gNB performs a
   T.Encaps.Reduced operations.
   T.Encaps.Red operation.  Since there is only one SID, there is no
   need to push an SRH. gNB only adds an outer IPv6 header with IPv6 DA
   U1::1.  U1::1 represents an anchoring SID specific for that session
   at UPF1.  The gNB obtains the SID U1::1 is retrieved through U1::1 from the existing control plane
   (N2 interface).

   Upon

   When the packet arrival on arrives at UPF1, the SID U1::1 is identifies a local
   End.MAP function.  This function maps the SID with the next anchoring point
   and  End.MAP replaces U1::1 by U2::1, that belongs to
   the next anchoring
   point.

   Upon UPF (U2).

   When the packet arrival on arrives at UPF2, the SID U2::1 corresponds to an
   End.DT function.  UPF2 decapsulates the packet, performs a lookup in
   a specific table and forwards the packet towards toward the data network. network
   (DN).

5.1.2.  Packet flow - Downlink

   The downlink packet flow is the following: as follows:

         UPF2_in : (Z,A)
         UPF2_out: (U2::, U1::1) (Z,A)    -> T.Encaps.Reduced T.Encaps.Red <U1::1>
         UPF1_out: (U2::, gNB::1) (Z,A)   -> End.MAP
         gNB_out : (Z,A)                  -> End.DX4 or End.DX6

   When the packet arrives to at the UPF2, the UPF2 will map maps that
   particular flow into a
   UE session.  This UE session is associated with the policy segment endpoint
   <U1::1>.  The  UPF2 performs a T.Encaps.Reduced T.Encaps.Red operation, encapsulating the
   packet into a new IPv6 header with no SRH since there is only one
   SID.

   Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP
   function.  This function maps the SID with to the next anchoring point and
   replaces U1::1 by gNB::1, that belongs to the next anchoring
   point. hop.

   Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4/ End.DX4
   or End.DX6 function.  The gNB will decapsulates the packet, removing the
   IPv6 header and all it's its extensions headers headers, and will forward forwards the traffic towards
   toward the UE.

5.1.3.  IPv6 user-traffic

   For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
   However based on local policy, a service provider MAY choose to do
   SRH insertion.  The main benefit is a lower overhead.  In such case,
   the functions used are T.Insert.Red at gNB, End.MAP at UPF1 and End.T
   at UPF2 on Uplink, T.Insert.Red at UPF2, End.MAP at UPF1 and End.X at
   gNB on Downlink.

5.2.  Enhanced Mode (formerly Aggregate mode)

   This

   Enhanced mode improves the scalability.  In addition, it provides key
   improvements in terms of scalability, traffic steering and service
   programming
   [I-D.xuclad-spring-sr-service-programming] , [I-D.xuclad-spring-sr-service-programming], thanks to the
   use of an
   SR policy of multiple SIDs, instead of a single one SID as done in the
   Traditional mode.

   Key points:

   o  Several UE share the same SR Policy (and it's composing SID)
   o

   The main difference is that the SR policy MAY include SIDs for
   traffic engineering and service programming on top of in addition to the UPF anchor. UPFs
   SIDs.

   The gNB control-plane (N2 interface) is unchanged, specifically a
   single IPv6 address is given to the gNB.

   o  The gNB MAY resolve the IP address into a SID list through using a
      mechanism like PCEP, DNS-lookup, small augment for LISP control-
      plane, etc.

   Our reference topology is shown in

   Note that the SIDs MAY use the arguments Args.Mob.Session if required
   by the UPFs.

   Figure 3.  In this 3 shows an Enhanced mode we assume
   that topology.  In the Enhanced mode, the
   gNB and the UPF are SR-aware.  We also assume that we have  The Figure shows two services service segments,
   S1 and C1.  S1 represents a VNF in the network, and C1 represents a
   constraint path on a router over which
   we are going to perform requiring Traffic Engineering.  Note that  S1 and C1
   belong to the underlay and don't have an N4 interface.  For this
   reason we don't consider them interface, so they are
   not considered UPFs.

                                    +----+  SRv6               _______
                    SRv6          --| C1 |--[N3]              /       \
   +--+    +-----+  [N3]         /  +----+  \  +------+ [N6] /         \
   |UE|----| gNB |--       SRv6 /    SRv6    --| UPF2 |------\   DN    /
   +--+    +-----+  \      [N3]/      TE       +------+       \_______/
          SRv6 node  \ +----+ /               SRv6 node
                      -| S1 |-
                       +----+
                      SRv6 node
                        VNF
                        CNF

                Figure 3: Enhanced mode - Reference Example topology

5.2.1.  Packet flow - Uplink

   The uplink packet flow is the following: as follows:

   UE_out  : (A,Z)
   gNB_out : (gNB, S1)(U2::1, C1; SL=2)(A,Z)-> T.Encaps.Red<S1,C1,U2::1>
   S1_out  : (gNB, C1)(U2::1, C1; SL=1 (A,Z)
   C1_out  : (gNB, U2::1)(A,Z)              -> PSP
   UPF2_out: (A,Z)                          -> End.DT4 or End.DT6

   UE sends its packet (A,Z) on a specific bearer session to its gNB.  gNB's CP
   control plane associates that session from the UE(A) with the IPv6
   address B and GTP TEID T.  gNB's CP control plane does a lookup on B (by reverseDNS, LISP,
   etc.) to
   find the related SID list <S1, C1, U2::1>.

   Once the packet leaves

   When gNB transmits the gNB, packet, it already contains all the segments of the SR
   policy.  This  The SR policy contains can include segments for traffic engineering
   (C1) and for service programming (S1).

   The nodes

   Nodes S1 and C1 perform their related Endpoint functionality and
   forward.
   forward the packet.

   When the packet arrives to at UPF2, the active segment (U2::1) is an
   End.DT4/6 which performs the decapsulation (removing the IPv6 header
   with all it's its extension headers) and forward towards forwards toward the data network.

   Note that in case several APNs are using duplicated IPv4 private
   address spaces, then the aggregated SR policies are unique per APNs.

5.2.2.  Packet flow - Downlink

   The downlink packet flow is the following: as follows:

   UPF2_in : (Z,A)                              -> UPF2 maps the flow w/
                                                   SID list <C1,S1, gNB>
   UPF2_out: (U2::1, C1)(gNB, S1; SL=2)(Z,A)    -> T.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=1)(Z,A)
   S1_out  : (U2::1, gNB)(Z,A)                  -> PSP
   gNB_out : (Z,A)                              -> End.DX4 or End.DX6

   When the packet arrives to at the UPF2, the UPF2 will map maps that particular
   flow into a UE session.  This UE session is associated with the
   policy <C1, S1, gNB>.  The UPF2 performs a T.Encaps.Reduced T.Encaps.Red operation,
   encapsulating the packet into a new IPv6 header with its
   corresponding SRH.

   The nodes C1 and S1 perform their related Endpoint processing.

   Once the packet arrives to at the gNB, the IPv6 DA corresponds to an
   End.DX4 or End.DX6 (depending on the underlying traffic).  The gNB
   will decapsulate
   decapsulates the packet, removing the IPv6 header and all it's its
   extensions headers and will forward forwards the traffic towards toward the UE.

5.2.3.  IPv6 user-traffic

   For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
   However based on local policy, a service provider MAY choose to do
   SRH insertion.  The main benefit is a lower overhead.  In such case,
   the functions used are T.Insert.Red at gNB and End.T at UPF2 on
   Uplink, T.Insert.Red at UPF2 and End.X at gNB on Downlink.

5.3.  Enhanced mode with unchanged gNB GTP behavior

   In this

   This section we introduce describes two mechanisms for interworking with legacy
   gNBs that still use GTP.  One of the mechanisms is valid GTP: one for
   IPv4 while IPv4, the other for IPv6.

   In this scenario, it is assumed that

   In the interworking scenarios as illustrated in Figure 4, gNB does
   not support SRv6.  It
   just  gNB supports GTP encapsulation over IPv4 or IPv6.  Hence in order to
   To achieve interworking we are going to add interworking, a new SR Gateway (SRGW-UPF1)
   entity.  This SRGW entity is going to map added.
   The SRGW maps the GTP traffic into SRv6.  Note
   that the SR GW

   The SRGW is not an anchor point.

   The SRGW point, and maintains very little state on it. state.
   For this reason, both of
   these methods (IPv4 IPv4 and IPv6) IPv6 methods scale to millions of UEs.

                                                              _______
                     IP GTP          SRv6                    /       \
    +--+      +-----+ [N3] +------+  [N9]  +------+  [N6]   /         \
    |UE|------| gNB |------| UPF1 |--------| UPF2 |---------\   DN    /
    +--+      +-----+      +------+        +------+          \_______/
                          SR Gateway       SRv6 node

                Figure 4: Reference Example topology for interworking

5.3.1.  Interworking with IPv6 GTP

   In this interworking mode we assume that the gNB is using uses GTP over IPv6 in via the N3
   interface

   Key points:

   o  The gNB is unchanged (control-plane or user-plane) and encaps
      encapsulates into GTP (N3 interface is not modified).
   o  The 5G Control-Plane (N2 interface) is unmodified: 1 unmodified; one IPv6
      address is needed (i.e. a BSID at the SRGW) SRGW).
   o  The SRGW removes GTP, finds the SID list related to DA, add and adds
      SRH with the SID list.
   o  There is NO no state for the downlink at the SRGW.
   o  There is simple state in the uplink at the SRGW (leveraging the
      enhanced SRGW; using Enhanced
      mode results in few fewer SR policies on this node.  A SR policy can
      be shared across UEs). UEs.
   o  As soon as the  When a packet leaves from the gNB (uplink), UE leaves the traffic gNB, it is SR-
      routed. SR-routed.  This
      simplifies considerably network slicing [I-D.hegdeppsenak-isis-sr-flex-algo].
   o  In the uplink, we use the IPv6 DA BSID to steer the steers traffic into an SR policy
      when it arrives at the SRGW-UPF1-.

   Our reference SRGW-UPF1.

   An example topology is shown in Figure 5.  In this mode we assume
   that the gNB is an
   unmodified gNB using IPv6/GTP.  The UPFs are SR-
   aware.  Also, as explained SR-aware.  As before, we introduce a new SRGW entity
   that is going to map
   the SRGW maps IPv6/GTP traffic to SRv6.

   We also assume that we have two service segment,

   S1 and C1. C1 are two service segments.  S1 represents a VNF in the
   network, and C1 represents a router over
   which we are going to perform configured for Traffic
   Engineering.

                                  +----+
                IPv6/GTP         -| S1 |-                            ___
   +--+  +-----+ [N3]           / +----+ \                          /
   |UE|--| gNB |-         SRv6 /   SRv6   \ +----+   +------+ [N6] /
   +--+  +-----+ \        [N9]/     VNF    -| C1 |---| UPF2 |------\  DN
           GTP    \ +------+ /              +----+   +------+       \___
                   -| UPF1 |-                SRv6      SRv6
                    +------+                  TE
                   SR Gateway

       Figure 5: Enhanced mode with unchanged gNB IPv6/GTP behavior

5.3.1.1.  Packet flow - Uplink

   The uplink packet flow is the following: as follows:

   UE_out  : (A,Z)
   gNB_out : (gNB, B)(GTP: TEID T)(A,Z)       -> Interface N3 unmodified
                                                 (IPv6/GTP)
   SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
                                                 SID at the SRGW
   S1_out  : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
   C1_out  : (SRGW, U2::1)(A,Z)               -> PSP
   UPF2_out: (A,Z)                            -> End.DT4 or End.DT6

   The UE sends a packet destined to Z towards toward the gNB on a specific
   bearer for that session.  The gNB, which is unmodified, encapsulates
   the packet into a new IPv6, UDP and GTP headers.  The IPv6 DA B, and the
   GTP TEID T are the ones received in the N2 interface.

   The IPv6 address that was signalled over the N2 interface for that UE
   session, B, is now the IPv6 DA.  B is an SRv6 Binding SID
   instantiated at the
   SRGW.  Hence the packet, will be packet is routed up to the SRGW.

   When the packet arrives at the SRGW, the SRGW realises that identifies B is as an
   End.M.GTP6.D BindingSID. Binding SID (see Section 6.3).  Hence, the SRGW will remove removes
   the IPv6, UDP and GTP headers, and will push a new pushes an IPv6 header with its own
   SRH containing the SIDs bound to the SR policy associated with this
   BindingSID.  Note that there will be  There is one instance of the End.M.GTP6.D SID per PDU
   type.

   The nodes

   S1 and C1 perform their related Endpoint functionality and
   forward. forward
   the packet.

   When the packet arrives to at UPF2, the active segment is (U2::1) which
   bound to End.DT4/6 which
   is going bound to perform the decapsulation End.DT4/6.  UPF2 then decapsulates (removing the outer
   IPv6 header with all it's its extension headers) and
   forward towards forwards the packet
   toward the data network.

5.3.1.2.  Packet flow - Downlink

   The downlink packet flow is the following: as follows:

   UPF2_in : (Z,A)                           -> UPF2 maps the flow with
                                                <C1, S1, SRGW::TEID,gNB>
   UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> T.Encaps.Red
   C1_out  : (U2::1, S1)(gNB, S1; SL=2)(Z,A)
   S1_out  : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A)
   SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A)   -> SRGW/96 is End.M.GTP6.E
   gNB_out : (Z,A)

   When a packet destined to A arrives at the UPF2, the UPF2 performs a
   lookup in the associated table associated to A and finds the SID list <C1, S1,
   SRGW::TEID, gNB>.  The UPF2 performs a T.Encaps.Reduced T.Encaps.Red operation,
   encapsulating the packet into a new IPv6 header with its
   corresponding SRH.

   The nodes

   C1 and S1 perform their related Endpoint processing.

   Once the packet arrives to at the SRGW, the SRGW realizes identifies the active
   SID
   is as an End.M.GTP6.E function.  The SRGW removes the IPv6 header
   and all it's its extensions headers.  The SRGW generates an new IPv6, UDP and
   GTP headers.  The new IPv6 DA is the gNB which is the last SID in the
   received SRH.  The TEID in the generated GTP header is the arguments an argument of
   the received End.M.GTP6.E SID.  The SRGW pushes the headers to the
   packet and forwards the packet towards toward the gNB.  Note that there will
   be  There is one instance
   of the End.M.GTP6.E SID per PDU type.

   Once the packet arrives to at the gNB, the packet is a regular IPv6/GTP
   packet.  The gNB looks for the specific radio bearer for that TEID
   and forward it on the bearer.  This gNB behavior is not modified from
   current and previous generations.

5.3.1.3.  Scalability

   For the downlink traffic, the SRGW is stateless.  All the state is in
   the SRH imposed inserted by the UPF2.  The UPF2 must have the UE states as since
   it is the UE's session anchor point.

   For the uplink traffic, the state at the SRGW does not necessarily
   need to be unique per UE session basis.  A session; the state of SR policy of which state can be shared among UE's.  Hence it is possible to deploy SRGW in
   very
   UEs.  This enables much more scalable way SRGW deployments compared to hold a
   solution holding millions of states states, one or more per UE session
   basis. UE.

5.3.1.4.  IPv6 user-traffic

   For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
   However based on local policy, a service provider MAY choose to do
   SRH insertion.  The main benefit is a lower overhead.

5.3.2.  Interworking with IPv4 GTP

   In this interworking mode we assume that the gNB is using uses GTP over IPv4 in the N3
   interface

   Key points:

   o  The gNB is unchanged and encaps encapsulates packets into GTP (N3 (the N3
      interface is not modified).
   o  In the uplink, traffic is classified at SRGW by UL CL(Uplink
      Classifier) SRGW's Uplink Classifier
      and steered into an SR policy.  The SRGW is a UPF1
      functionality, hence it functionality
      and can coexist with UPF UL CL UPF1's Uplink Classifier functionality.
   o  SRGW removes GTP, finds the SID list related to DA, add and adds a SRH
      with the SID list.

   Our reference

   An example topology is shown in Figure 6.  In this mode we assume
   that the gNB is an
   unmodified gNB using IPv4/GTP.  The UPFs are SR-
   aware.  Also, as explained SR-aware.  As before, we introduce a new
   the SRGW entity
   that is going to map maps the IPv4/GTP traffic to SRv6.

   We also assume that we have two service segment,

   S1 and C1. C1 are two service segment endpoints.  S1 represents a VNF in
   the network, and C1 represents a router over
   which we are going to perform configured for Traffic
   Engineering.

                                  +----+
                IPv4/GTP         -| S1 |-                            ___
   +--+  +-----+ [N3]           / +----+ \                          /
   |UE|--| gNB |-         SRv6 /   SRv6   \ +----+   +------+ [N6] /
   +--+  +-----+ \        [N9]/     VNF    -| C1 |---| UPF2 |------\  DN
           GTP    \ +------+ /              +----+   +------+       \___
                   -| UPF1 |-                SRv6      SRv6
                    +------+                  TE
                   SR Gateway

       Figure 6: Enhanced mode with unchanged gNB IPv4/GTP behavior

5.3.2.1.  Packet flow - Uplink

   The uplink packet flow is the following: as follows:

    gNB_out : (gNB, B)(GTP: TEID T)(A,Z)          -> Interface N3
                                                     unchanged IPv4/GTP
    SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z)    -> T.M.Tmap function
    S1_out  : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
    C1_out  : (SRGW, U2::1) (A,Z)                 -> PSP
    UPF2_out: (A,Z)                               -> End.DT4 or End.DT6

   The UE sends a packet destined to Z towards toward the gNB on a specific
   bearer for that session.  The gNB, which is unmodified, encapsulates
   the packet into a new IPv4, UDP and GTP headers.  The IPv4 DA, B, and
   the GTP TEID are the ones received at the N2 interface.

   When the packet arrives to at the SRGW -UPF1-, for UPF1, the SRGW has an UL CL
   (uplink classifier) Uplink
   Classifier rule for incoming traffic from the gNB gNB, that steers the
   traffic into an SR policy by using the function T.M.TMap.  The SRGW
   removes the IPv4, UDP and GTP headers and pushes an IPv6 header with
   its own SRH containing the SIDs related to the SR policy associated
   with this traffic.  The SRGW forwards according to the new IPv6 DA.

   The nodes

   S1 and C1 perform their related Endpoint functionality and
   forward. forward
   the packet.

   When the packet arrives at UPF2, the active segment is (U2::1) which
   is bound to End.DT4/6 which performs the decapsulation (removing the
   outer IPv6 header with all it's its extension headers) and forwards
   towards toward
   the data network.

5.3.2.2.  Packet flow - Downlink

   The downlink packet flow is the following: as follows:

   UPF2_in : (Z,A)                            -> UPF2 maps flow with SID
                                               <C1, S1,SRGW::SA:DA:TEID>
   UPF2_out: (U2::1, C1)(SRGW::SA:DA:TEID, S1; SL=2)(Z,A) ->T.Encaps.Red
   C1_out  : (U2::1, S1)(SRGW::SA:DA:TEID, S1; SL=1)(Z,A)
   S1_out  : (U2::1, SRGW::SA:DA:TEID)(Z,A)
   SRGW_out: (SA, DA)(GTP: TEID=T)(Z,A)       -> End.M.GTP4.E
   gNB_out : (Z,A)

   When a packet destined to A arrives to at the UPF2, the UPF2 performs a
   lookup in the associated table associated to A and finds the SID list <C1, S1,
   SRGW::SA:DA:TEID>.  The UPF2 performs a T.Encaps.Reduced T.Encaps.Red operation,
   encapsulating the packet into a new IPv6 header with its
   corresponding SRH.

   The nodes C1 and S1 perform their related Endpoint processing.

   Once the packet arrives to at the SRGW, the SRGW realizes identifies the active
   SID
   is as an End.M.GTP4.E function.  The SRGW removes the IPv6 header
   and all it's its extensions headers.  The SRGW generates an IPv4, UDP and
   GTP headers.  The IPv4 SA and DA will the ones are received as part of the SID arguments.  The
   TEID in the generated GTP header is also the arguments of the
   received End.M.GTP4.E SID SID.  The SRGW pushes the headers to the packet
   and forwards the packet towards toward the gNB.

   Once

   When the packet arrives to at the gNB, the packet is a regular IPv4/GTP
   packet.  The gNB looks for the specific radio bearer for that TEID
   and forward it on the bearer.  This gNB behavior is not modified from
   current and previous generations.

5.3.2.3.  Scalability

   For the downlink traffic, the SRGW is stateless.  All the state is in
   the SRH imposed inserted by the UPF.  The UPF must have this UE-base state
   anyway (it (since it is its anchor point).

   For the uplink traffic, the state at the SRGW is dedicated on a per
   UE/session basis.  This is basis according to an UL CL (uplink classifier). Uplink Classifier.  There is state
   for steering the different sessions on a SR policies.  Notice
   however that the  However, SR
   policies are shared among several UE/sessions.

5.3.2.4.  IPv6 user-traffic

   For IPv6 user-traffic it is RECOMMENDED to perform encapsulation.
   However based
   Based on local policy, a service provider MAY choose to do SRH
   insertion.  The main benefit is a lower overhead.

5.3.3.  Extensions to the interworking mechanisms

   In this section we presented two mechanisms for interworking with
   gNBs that do not support SRv6.  These mechanism are done to support
   GTP over IPv4 and GTP over IPv6.

   Even though we have presented these methods as an extension to the
   "Enhanced mode", it is straightforward in its applicability to the
   "Traditional mode".

   Furthermore, although these mechanisms are designed for interworking
   with legacy RAN at the N3 interface, these methods could also be
   applied for interworking with a non-SRv6 capable UPF at the N9
   interface (e.g.  L3-anchor is SRv6 capable but L2-anchor is not).

6.  SRv6 SID Mobility Functions

6.1.  End.MAP: Endpoint function  Args.Mob.Session

   Args.Mob.Session provide per-session information for charging,
   buffering and lawful intercept (among others) required by some mobile
   nodes.  The Args.Mob.Session argument format is used in combination
   with SID mapping End.Map, End.DT and End.DX functions.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   QFI     |R|U|                PDU Session ID                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |PDU Sess(cont')|
     +-+-+-+-+-+-+-+-+

                          Args.Mob.Session format

   o  QFI: QoS Flow Identifier [TS.38415]
   o  R: Reflective QoS Indication [TS.23501].  This parameter indicates
      the activaton of reflective QoS towards the UE for the transfered
      packet.  Reflective QoS enables the UE to map UL User Plane
      traffic to QoS Flows without SMF provided QoS rules.
   o  U: Unused and for future use.  MUST be 0 on transmission and
      ignored on receipt.
   o  PDU Session ID: Identifier of PDU Session.  The GTP-U equivalent
      is TEID.

   Since the SRv6 function is likely NOT to be instantiated per PDU
   session, Args.Mob.Session helps the UPF to perform the functions
   which require per QFI and/or per PDU Session granularity.

6.2.  End.MAP

   The "Endpoint function with SID mapping" function (End.MAP for short)
   is used in several scenarios.  Particularly in mobility, it End.MAP is
   used in the UPFs for the PDU Session anchor functionality in some of the use-cases. functionality.

   When a SR node N receives a packet destined to S and S is a local
   End.MAP SID, N does: does the following:

   1.    look up the IPv6 DA in the mapping table
   2.    update the IPv6 DA with the new mapped SID            ;; Ref1 Note 1
   3.    IF segment_list > 1
   4.       insert a new SRH
   5.    forward according to the new mapped SID
   4.
   6. ELSE
   5.
   7.    Drop the packet

   Ref1:

   Note that the 1: The SID in the SRH is NOT modified.

6.2.  End.M.GTP6.D: Endpoint function with decapsulation from IPv6/GTP
      tunnel

6.3.  End.M.GTP6.D

   The "Endpoint function with IPv6/GTP decapsulation into SR policy"
   function (End.M.GTP6.D for short) is used in interworking scenario
   for the uplink towards toward from the legacy gNB using IPv6/GTP.  This  Suppose,
   for example, this SID is associated with an SR policy <S1, S2, S3>
   and an IPv6 Source Address A.

   When the SR Gateway node N receives a packet destined to S and S is a
   local End.M.GTP6.D SID, N does:

   1. IF NH=UDP & UDP_PORT = GTP THEN
   2.    pop the IP, UDP and GTP headers
   3.    push a new IPv6 header with its own SRH <S2, S3>
   4.    set the outer IPv6 SA to A
   5.    set the outer IPv6 DA to S1
   6.    forward according to the first S1 segment of the SRv6 Policy
   7. ELSE
   8.    Drop the packet

6.3.  End.M.GTP6.E: Endpoint function with encapsulation for IPv6/GTP
      tunnel

6.4.  End.M.GTP6.E

   The "Endpoint function with encapsulation for IPv6/GTP tunnel"
   function (End.M.GTP6.E for short) is used in interworking scenario
   for the downlink towards toward the legacy gNB using IPv6/GTP.

   The End.M.GTP6.E function has a 32-bit argument space.  This argument
   corresponds space which is used
   to provide the GTP TEID.

   When the SR Gateway node N receives a packet destined to S S, and S is
   a local End.M.GTP6.E SID, N does: does the following:

    1. IF NH=SRH & SL = 1  THEN                                ;; Ref1 Note 1
    2.    decrement SL
    3.    store SRH[SL] in variable new_DA
    4.    store TEID in variable new_TEID                      ;; Ref2 Note 2
    5.    pop IP header and all it's its extension headers
    6.    push new IPv6 header and GTP-U header
    7.    set IPv6 DA to new_DA
    8.    set GTP_TEID to new_TEID
    9.    lookup the new_DA and forward the packet accordingly
   10. ELSE
   11.    Drop the packet

   Ref1:

   Note 1: An End.M.GTP6.E SID MUST always be the penultimate SID.

   Ref2:

   Note 2: TEID is extracted from the argument space of the current SID.

6.4.  End.M.GTP4.E: Endpoint function with encapsulation for IPv4/GTP
      tunnel

6.5.  End.M.GTP4.E

   The "Endpoint function with encapsulation for IPv4/GTP tunnel"
   function (End.M.GTP4.UP (End.M.GTP4.E for short) is used in the downlink when doing
   interworking with legacy gNB using IPv4/GTP.

   When the SR Gateway node N receives a packet destined to S and S is a
   local End.M.GTP4.E SID, N does:

   1. IF NH=SRH & SL > 0 THEN
   2.    decrement SL
   3.    update the IPv6 DA with SRH[SL]
   4.    pop the SRH
   5.    push header of TUN-PROTO UDP/GTP headers with tunnel ID from S          ;; Ref1
   6.    push outer IPv4 header with SA, DA from S
   7. ELSE
   8.    Drop the packet

   Ref1: TUN-PROTO indicates target tunnel type.

   Note that

   S has the following format:

             +----------------------+-------+-------+-------+
             |  SRGW-IPv6-LOC-FUNC  |IPv4DA |IPv4SA |TUN-ID |
             +----------------------+-------+-------+-------+
                     128-a-b-c          a      b       c

                         End.M.GTP4.E SID Encoding

6.5.  T.M.Tmap: Transit behavior with IPv4/GTP decapsulation and mapping
      into an SRv6 Policy

6.6.  T.M.Tmap

   The "Transit with tunnel decapsulation and map to an SRv6 policy"
   function (T.Tmap (T.M.Tmap for short) is used in the direction from legacy
   user-plane to SRv6 user-plane network.

   When the SR Gateway node N receives a packet destined to a IW-
   IPv4-Prefix, N does:

   1. IF P.PLOAD Payload == TUN-PROTO UDP/GTP THEN    ;; Ref1
   2.    pop the outer IPv4 header and tunnel UDP/GTP headers
   3.    copy IPv4 DA, SA, TUN-ID to form SID B with SRGW-IPv6-Prefix
   4.    encapsulate the packet into a new IPv6 header  ;; Ref2, Ref2bis
   5.    set the IPv6 DA = B
   6.    forward along the shortest path to B
   7. ELSE
   8.    Drop the packet

   Ref1: TUN-PROTO indicates target tunnel type.

   Note that

   B has the following format:

             +----------------------+-------+-------+-------+
             |  SRGW-IPv6-LOC-FUNC  |IPv4DA |IPv4SA |TUN-ID |
             +----------------------+-------+-------+-------+
                     128-a-b-c          a      b       c

                         End.M.GTP4.E SID Encoding

   Note that the

   The SID B SID, is going to be an SRv6 BindingSID instantiated at the first UPF (anchor point). (U1).
   A static format is leveraged to
   instantiate used for this Binding SIDs in order to remove
   state from the SRGW.

6.6.

6.7.  End.Limit: Rate Limiting function

   Mobile

   The mobile user-plane requires a rate-limit feature.  SID is able to
   encode limiting rate as an argument  For this
   purpose, we define a new function "End.Limit".  The "End.Limit"
   function encodes in SID. its arguments the rate limiting parameter that
   should be applied to this packet.  Multiple flows of packets should
   have the same group identifier in the SID when those flows are in an
   same AMBR group.  This helps to keep user-plane stateless.
   That enables SRv6 endpoint nodes which are unaware from the mobile
   control-plane information.  Encoding  The encoding format of the rate limit segment SID
   is following: as follows:

              +----------------------+----------+-----------+
              | LOC+FUNC rate-limit  | group-id | limit-rate|
              +----------------------+----------+-----------+
                    128-i-j                i          j

             End.Limit: Rate limiting function argument format

   In case of

   If the j bit length is zero in SID, zero, the node should not do rate limiting
   unless static configuration or control-plane sets the limit rate
   associated to the SID.

7.  SRv6 supported 3GPP PDU session types

   The 3GPP [TS.23501] defines the following PDU session types:

   o  IPv4
   o  IPv6
   o  IPv4v6
   o  Ethernet
   o  Unstructured

   SRv6 supports all the 3GPP PDU session types without any protocol
   overhead by using the corresponding SRv6 functions (End.DX4, End.DT4
   for IPv4 PDU sessions; End.DX6, End.DT6, End.T for IPv6 PDU sessions;
   End.DT46 for IPv4v6 PDU sessions; End.DX2, End.DT2M for L2 PDU
   sessions; End.DX2 for Unstructured PDU sessions).

8.  Network Slicing Considerations

   A mobile network may be required to implement "network slices", which
   logically separate network resources.  User-plane functions
   represented as SRv6 segments would be part of a slice.

   [I-D.filsfils-spring-segment-routing-policy] describes a solution to
   build basic network slices with SR.  Depending on the requirements,
   these slices can be further refined by leveraging adopting the mechanisms from:

   o  IGP Flex-Algo [I-D.hegdeppsenak-isis-sr-flex-algo]
   o  Inter-Domain policies
      [I-D.ietf-spring-segment-routing-central-epe]

   Furthermore, these can be combined with ODN/AS
   [I-D.filsfils-spring-segment-routing-policy] for automated slice
   provisioning and traffic steering.

   A separate document will explain in detail

   Further details on how each one of these tools is leveraged can be used to build a create end to end
   network slice. slices are documented in
   [I-D.ali-spring-network-slicing-building-blocks].

9.  Control Plane Considerations

   This documents document focuses on the user-plane behavior and it's
   independent its independence
   from the control plane.

   The control plane could be the current 3GPP-defined control plane
   with slight modifications to the N4 interface [TS.29244].

   Alternatively, SRv6 could be used in conjunction with a new mobility
   control plane as described in LISP [I-D.rodrigueznatal-lisp-srv6],
   hICN [I-D.auge-dmm-hicn-mobility-deployment-options], MFA
   [I-D.gundavelli-dmm-mfa] or in cunjunction conjunction with FPC
   [I-D.ietf-dmm-fpc-cpdp].  The analysis of new mobility control-planes
   and it's its applicability to SRv6 is is out of the scope of this document.

   Note that the IANA section of this document

   Section 11 allocates the SRv6 endpoint function types for the new
   functions defined in this document.  All control-plane  Control-plane protocols are
   expected to leverage use these function type-codes type codes to signal each function.

   It's notable that

   SRv6's network programming nature allows a flexible and dynamic anchor UPF
   placement.

10.  Security Considerations

   TBD

11.  IANA Considerations

   This I-D requests to

   IANA is requested to allocate, within the "SRv6 Endpoint Types" sub-registry sub-
   registry belonging to the top-level "Segment-routing with IPv6
   dataplane (SRv6) Parameters" registry
   [I-D.filsfils-spring-srv6-network-programming], the following
   allocations: values:

           +-------------+-----+-------------------+-----------+
           | Value/Range | Hex | Endpoint function | Reference |
           +-------------+-----+-------------------+-----------+
           | TBA         | TBA |      End.MAP      | [This.ID] |
           | TBA         | TBA |    End.M.GTP6.D   | [This.ID] |
           | TBA         | TBA |    End.M.GTP6.E   | [This.ID] |
           | TBA         | TBA |    End.M.GTP4.E   | [This.ID] |
           | TBA         | TBA |     End.Limit     | [This.ID] |
           +-------------+-----+-------------------+-----------+

              Table 1: SRv6 Mobile User-plane Endpoint Types

12.  Acknowledgements

   The authors would like to thank Daisuke Yokota, Bart Peirens,
   Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois
   Clad, Sri Gundavelli, Sridhar Bhaskaran and Bhaskaran, Arashmid Akhavain Akhavain, Ravi
   Shekhar and Aeneas Dodd-Noble for their useful comments of this work.

13.  Contributors

   Kentaro Ebisawa
   Ponto Networks
   Japan
   Email: ebiken@pontonetworks.com

14.  References

14.1.  Normative References

   [I-D.filsfils-spring-segment-routing-policy]
              Filsfils, C., Sivabalan, S., Hegde, S.,
              daniel.voyer@bell.ca, d., Lin, S., bogdanov@google.com,
              b., Krol, P., Horneffer, M., Steinberg, D., Decraene, B.,
              Litkowski, S., Mattes, P., Ali, Z., Talaulikar, K., Liste,
              J., Clad, F., and K. Raza, "Segment Routing Policy
              Architecture", draft-filsfils-spring-segment-routing-
              policy-06 (work in progress), May 2018.

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Li, Z., Camarillo, P., Leddy, J., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca,
              daniel.voyer@bell.ca, d., Steinberg, D., Raszuk, R., Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
              Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P., and
              M. Sharif, Z. Li, "SRv6
              Network Programming", draft-filsfils-
              spring-srv6-network-programming-04 draft-filsfils-spring-srv6-network-
              programming-05 (work in progress),
              March July 2018.

   [I-D.ietf-6man-segment-routing-header]
              Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and
              d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header
              (SRH)", draft-ietf-6man-segment-routing-header-14 (work in
              progress), June 2018.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-15 (work
              in progress), January 2018.

   [I-D.xuclad-spring-sr-service-programming]
              Clad, F., Xu, X., Filsfils, C., Bernier, D., Li, C.,
              Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W., and
              S. Salsano, "Service Programming with Segment Routing",
              draft-xuclad-spring-sr-service-programming-00 (work in
              progress), July 2018.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

14.2.  Informative References

   [I-D.ali-spring-network-slicing-building-blocks]
              Ali, Z., Filsfils, C., and P. Camarillo, "Building blocks
              for Slicing in Segment Routing Network", draft-ali-spring-
              network-slicing-building-blocks-00 (work in progress),
              July 2018.

   [I-D.auge-dmm-hicn-mobility-deployment-options]
              Auge, J., Carofiglio, G., Muscariello, L., and M.
              Papalini, "Anchorless mobility management through hICN
              (hICN-AMM): Deployment options", draft-auge-dmm-hicn-
              mobility-deployment-options-00 (work in progress), June
              2018.

   [I-D.camarillo-dmm-srv6-mobile-pocs]
              Camarillo Garvia,
              Camarillo, P., Filsfils, C., Bertz, L., Akhavain, A.,
              Matsushima, S., and D. Voyer, d. daniel.voyer@bell.ca, "Segment
              Routing IPv6 for mobile user-plane PoCs", draft-xuclad-spring-sr-
              service-programming-00 draft-camarillo-
              dmm-srv6-mobile-pocs-00 (work in progress), July 2018.

   [I-D.camarilloelmalky-springdmm-srv6-mob-usecases]
              Camarillo, P., Filsfils, C., Elmalky, H., Allan, D.,
              Matsushima, S., daniel.voyer@bell.ca, d., Cui, A., and B.
              Peirens, "SRv6 Mobility Use-Cases", draft-
              camarilloelmalky-springdmm-srv6-mob-usecases-00 (work in
              progress), July 2018.

   [I-D.gundavelli-dmm-mfa]
              Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
              aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-00 draft-gundavelli-dmm-mfa-01
              (work in progress), February September 2018.

   [I-D.hegdeppsenak-isis-sr-flex-algo]
              Psenak, P., Hegde, S., Filsfils, C., and A. Gulko, "ISIS
              Segment Routing Flexible Algorithm", draft-hegdeppsenak-
              isis-sr-flex-algo-02 (work in progress), February 2018.

   [I-D.ietf-dmm-fpc-cpdp]
              Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
              Moses, D., and C. Perkins, "Protocol for Forwarding Policy
              Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-12
              (work in progress), June 2018.

   [I-D.ietf-spring-segment-routing-central-epe]
              Filsfils, C., Previdi, S., Dawra, G., Aries, E., and D.
              Afanasiev, "Segment Routing Centralized BGP Egress Peer
              Engineering", draft-ietf-spring-segment-routing-central-
              epe-10 (work in progress), December 2017.

   [I-D.rodrigueznatal-lisp-srv6]
              Rodriguez-Natal, A., Ermagan, V., Maino, F., Dukes, D.,
              Camarillo, P., and C. Filsfils, "LISP Control Plane for
              SRv6 Endpoint Mobility", draft-rodrigueznatal-lisp-srv6-00
              (work in progress), July 2018.

   [RFC5213]  Gundavelli,

   [I-D.xuclad-spring-sr-service-programming]
              Clad, F., Xu, X., Filsfils, C., daniel.bernier@bell.ca,
              d., Li, C., Decraene, B., Ma, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., Yadlapalli, C.,
              Henderickx, W., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <https://www.rfc-editor.org/info/rfc5213>.

   [TR.29891]
              3GPP, "5G System - Phase 1 CT WG4 Aspects", 3GPP TR
              29.891 15.0.0, December 2017. S. Salsano, "Service Programming with
              Segment Routing", draft-xuclad-spring-sr-service-
              programming-00 (work in progress), July 2018.

   [TS.23501]
              3GPP, "System Architecture for the 5G System", 3GPP TS
              23.501 15.0.0, November 2017.

   [TS.29244]
              3GPP, "Interface between the Control Plane and the User
              Plane Nodes", 3GPP TS 29.244 15.0.0, December 2017.

   [TS.29281]
              3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
              December 2017.

   [TS.38415]
              3GPP, "Draft Specification for 5GS container (TS 38.415)",
              3GPP R3-174510 0.0.0, August 2017.

Appendix A.  Implementations

   This I-D document introduces new SRv6 functions.  These functions have an
   open-source P4 implementation available in
   <https://github.com/ebiken/p4srv6>.

   Additionally, there

   There are ongoing PoC efforts also implementations in M-CORD NGIC and Open Air Interface
   (OAI).  Progress and results  Further details can be found in
   [I-D.camarillo-dmm-srv6-mobile-pocs].

Appendix B.  Changes from revision 02 to revision 03

   This section lists the changes between draft-ietf-dmm-srv6-mobile-
   uplane revisions ...-02 and ...-03.

   o  Added new terminology section for abbreviations.
   o  Added new terminology section for predefined SRv6 functions.
   o  Made terminology section for conventions used in the document.
   o  Renamed "Basic" mode to be called "Traditional" mode.
   o  Renamed "Aggregate" mode to be called "Enhanced" mode.
   o  Added new Args.Mob.Session format to supply QFI, RQI indication
      and PDU Session ID.
   o  Modified End.MAP function to define the SID argument format and
      support more than one SID

   o  Added missing references.
   o  Editorial updates to improve readability.

Authors' Addresses

   Satoru Matsushima
   SoftBank
   Tokyo
   Japan

   Email: satoru.matsushima@g.softbank.co.jp

   Clarence Filsfils
   Cisco Systems, Inc.
   Belgium

   Email: cf@cisco.com

   Miya Kohno
   Cisco Systems, Inc.
   Japan

   Email: mkohno@cisco.com

   Pablo Camarillo Garvia
   Cisco Systems, Inc.
   Spain

   Email: pcamaril@cisco.com

   Daniel Voyer
   Bell Canada
   Canada

   Email: daniel.voyer@bell.ca
   Charles E. Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA  95050
   USA

   Phone: +1-408-330-4586
   Email: charliep@computer.org