SPRING and
DMM Working Group                                          S. Matsushima
Internet-Draft                                                  SoftBank
Intended status: Standards Track                             C. Filsfils
Expires: June 3, September 6, 2018                                      M. Kohno
                                                            P. Camarillo
                                                     Cisco Systems, Inc.
                                                                D. Voyer
                                                             Bell Canada
                                                              C. Perkins
                                                               Futurewei
                                                       November 30, 2017
                                                           March 5, 2018

               Segment Routing IPv6 for Mobile User-Plane
                  draft-ietf-dmm-srv6-mobile-uplane-00 User Plane
                  draft-ietf-dmm-srv6-mobile-uplane-01

Abstract

   This document discusses the applicability of SRv6 (Segment Routing
   IPv6) to user-plane of mobile networks that SRv6 networks.  The source routing
   capability with its programmability can fulfill and the network programming nature of SRv6, accomplish
   mobile user-plane
   functions, such as access functions in a simple manner.  The statelessness
   and anchor functions.  It takes advantage
   of the ability to control underlying layer awareness and flexibility will be even more
   beneficial to deploy user-plane
   functions that enables optimizing data-path the mobile user-plane, in terms of providing
   flexibility and SLA control for various applications.
   Network slicing  It also
   simplifies the network architecture by eliminating the necessity of
   tunnels, such as GTP-U [TS.29281], PMIP [RFC5213], Mac-in-Mac, MPLS,
   and so on.  In addition, Segment Routing provides an interworking way between SRv6 and existing
   mobile user-plane are also discussed in enhanced method
   for network slicing, which is briefly introduced by this document.

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 http://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 June 3, September 6, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (http://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.  Motivations  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   4.  Mobile User-Plane .  Reference Architecture  . . . . . . . . . . . . . . . . . . .   5
   5.  User-plane behaviors  . .   4
   5.  Supporting Mobile User-Plane Functions . . . . . . . . . . .   5
     5.1.  Access Point . . . . . . .   6
     5.1.  Traditional mode (formerly Basic mode)  . . . . . . . . .   6
       5.1.1.  Packet flow - Uplink  . . . . . .   6
     5.2.  Layer-2 Anchor . . . . . . . . . .   7
       5.1.2.  Packet flow - Downlink  . . . . . . . . . . .   6
     5.3.  Layer-3 Anchor . . . .   8
       5.1.3.  IPv6 user-traffic . . . . . . . . . . . . . . . . .   6
     5.4.  Stateless Interworking .   8
     5.2.  Enhanced Mode (formerly Aggregate mode) . . . . . . . . .   8
       5.2.1.  Packet flow - Uplink  . . . . . . .   7
       5.4.1.  End.TM: End point function with encapsulation for
               mapped tunnel . . . . . . . . .   9
       5.2.2.  Packet flow - Downlink  . . . . . . . . . . .   7
       5.4.2.  T.Tmap: Transit behavior with tunnel decapsulation
               and mapping an SRv6 Policy . . . .  10
       5.2.3.  IPv6 user-traffic . . . . . . . . .   8
     5.5.  Rate Limit . . . . . . . . .  10
     5.3.  Enhanced mode with unchanged gNB GTP behavior . . . . . .  10
       5.3.1.  Interworking with IPv6 GTP  . . . . . . . .   9
   6.  Segment Routing IPv6 Functions and Behaviors by Use Cases . .   9
     6.1.  Basic Mode . . .  11
       5.3.2.  Interworking with IPv4 GTP  . . . . . . . . . . . . .  14
       5.3.3.  Extensions to the interworking mechanisms . . . . . .  16
   6.  SRv6 SID Mobility Functions .   9
       6.1.1.  Uplink . . . . . . . . . . . . . . . .  17
     6.1.  End.MAP: Endpoint function with SID mapping . . . . . . .  10
       6.1.2.  Downlink  17
     6.2.  End.M.GTP6.D: Endpoint function with decapsulation from
           IPv6/GTP tunnel . . . . . . . . . . . . . . . . . . . . .  17
     6.3.  End.M.GTP6.E: Endpoint function with encapsulation for
           IPv6/GTP tunnel .  10
     6.2.  Aggregate Mode . . . . . . . . . . . . . . . . . . . .  18
     6.4.  End.M.GTP4.E: Endpoint function with encapsulation for
           IPv4/GTP tunnel .  11
       6.2.1.  Uplink . . . . . . . . . . . . . . . . . . . .  18
     6.5.  T.M.Tmap: Transit behavior with IPv4/GTP decapsulation
           and mapping into an SRv6 Policy . . .  11
       6.2.2.  Downlink . . . . . . . . . .  19
     6.6.  End.Limit: Rate Limiting function . . . . . . . . . . . .  13
     6.3.  Stateless Interworking with Legacy Access Network . . . .  14
       6.3.1.  Uplink: Lagacy Access to SRv6 . . . . . . . . . . . .  14
       6.3.2.  Downlink: SRv6 to Legacy Access . . . . . . . . . . .  15  20
   7.  Network Slicing Considerations  . . . . . . . . . . . . . . .  16  20
   8.  Control Plane Considerations  . . . . . . . . . . . . . . . .  16
     8.1.  Existing Control Plane  . . . . . . . . . . . . . . . . .  16
     8.2.  Aggregate Mode  . . . . . . . . . . . . . . . . . . . . .  17
     8.3.  User-Plane Sepalated Control Plane  . . . . . . . . . . .  17
     8.4.  Centralized Controller  . . . . . . . . . . . . . . . . .  17
     8.5.  Stateless Interworking  . . . . . . . . . . . . . . . . .  18  20
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18  21
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18  21
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18  21
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18  21
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  18  21
     12.2.  Informative References . . . . . . . . . . . . . . . . .  19  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19  23

1.  Introduction

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

   This document discusses the applicability of SRv6 (Segment Routing
   IPv6) to those mobile networks.  SRv6 provides source routing to
   networks where operators can explicitly indicate a route for the
   packets from and to the mobile node.  SRv6 endpoint nodes act as perform the
   roles of anchor 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].

   All segment

   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 of the IPv6 next-header field.

   NH=SRH means that the next-header field is 43 with routing and SRv6 network programming terms are defined in
   [I-D.ietf-spring-segment-routing] and
   "[I-D.filsfils-spring-srv6-network-programming].

3.  Motivations

   Today's and future applications type 4.

   When there are requiring highly optimized data-
   path between mobile nodes and multiple SRHs, they must follow each other: the entities of those applications in
   perspectives next-
   header field of latency, bandwidth, etc,. However current
   architecture all SRH, except the last one, must be SRH.

   The effective next-header (ENH) is the next-header field of mobile management the IP
   header when no SRH is agnostic about underlying
   topologies present, or is the next-header field of transport layer.  It rigidly fragments the user-plane
   in radio access, core and service networks and connects them by
   tunneling techniques through the user-plane functions such as access
   and anchor nodes.  Those agnostic and rigidness make it difficult for
   last SRH.

   In this version of the operator to optimize document, we assume that there is no other
   extension header than the data-path.

   While SRH.  This will be lifted in future
   versions of the mobile network industry has been trying to solve that,
   applications shift to use document.

   SID: A Segment Identifier which represents a specific segment in
   segment routing domain.  The SID type used in this document is IPv6 data-path and network operators adopt
   it as their IP transport
   address (also referenced as well. SRv6 integrates both application
   data-path and underlying transport layer in data-path optimization
   aspects that does not require any other techniques. Segment or SRv6 source routing capability with programmable functions
   [I-D.filsfils-spring-srv6-network-programming] could fulfills SID).

   A SID list is represented as <S1, S2, S3> where S1 is the
   user-plane functions of mobility management.  It takes advantage of
   underlying layer awareness and flexibility first SID
   to deploy user-plane
   functions.  Those are visit, S2 is the motivations to adopt SRv6 for mobile user-
   plane.

4.  Mobile User-Plane

   This section describes user-plane using SRv6 for mobile networks.
   This clarifies mobile user-plane functions second SID to which SRv6 endpoint
   applied.

   Figure 1 shows mobile user-plane functions which are connected
   through IPv6-only networks.  In visit and S3 is the Figure 1, an mobile node (MN)
   connects last SID to an SRv6 endpoint serving access point role for the MN.
   When the endpoint receives packets from
   visit along the MN, it pushes SR path.

   (SA,DA) (S3, S2, S1; SL) represents an IPv6 packet with:

   o  IPv6 header with source and destination addresses respectively SA
      and DA and next-header is SRH to the
   packets.  The segment
   o  SRH with SID list in <S1, S2, S3> with SegmentsLeft = SL
   o  Note the SRH indicates difference between the rest of user-
   plane segments which are L2 <> and L3 anchors respectively.  Then the
   endpoint send () symbols: <S1, S2, S3>
      represents a SID list where S1 is the packets to first SID and S3 is the IPv6 network.  In opposite
   direction, when an SRv6 endpoint serving L3 anchor role for last
      SID.  (S3, S2, S1; SL) represents the MN
   receives packets to it, same SID list but encoded in
      the endpoint push SRH consist of format where the L2
   anchor and access point segments to rightmost SID in the packets.

                                User-plane
                                Function
                               <L2 Anchor>
                                O------O
                                | SRv6 |
                                | End  |
                                | Point|
                                O------O
              User-plane           ||           User-plane
    [MN]      Function        _____||_____      Function
      |     <Access Point>   /            \    <L3 Anchor>
   ___v___     O------O     /              \     O------O     ________
  /  Radio \   | SRv6 |    /                \    | SRv6 |    /        \
 /  Access  \==| End  |===/     IPv6-Only    \===| End  |===/ Service  \
 \    NW    /  | Point|   \      Network     /   | Point|   \    NW    /
  \________/   O------O    \                /    O------O    \________/
                            \              /
                             \____________/

                   Figure 1: Mobile User-plane with SRv6

   An SRv6 segment represents those each function, such as Access Point,
   Layer-2 (L2) Anchor SRH is the first SID
      and Layer-3 (L3) Anchor.  This makes mobile
   networks highly flexible to deploy any user-plane functions the leftmost SID in the SRH is the last SID.  When referring
      to which
   nodes an SR policy in user flow basis.  An SRv6 segment can represent a set of
   flows in any granularity of aggregation even though high-level use-case, it is just for a
   single flow.

   Figure 2 shows that simpler to use the
      <S1, S2, S3> notation.  When referring to an SRv6 endpoint connects existing IPv4 mobile
   user-plane, which illustration of the
      detailed behavior, the (S3, S2, S1; SL) notation is more
      convenient.
   o  The payload of the packet is defined in [RFC5213] and [TS.29281].  An SRv6
   segment omitted.

   SRH[SL] represents the SID pointed by the SL field in the endpoint first SRH.
   In our example, SRH[2] represents interworking function which
   enables interworking between existing access point and SRv6 anchor
   segment, or SRv6 access point segment S1, SRH[1] represents S2 and existing anchor node.

   Existing mobile user-plane with IPv6 underlay SRH[0]
   represents S3.

   FIB is expected to be
   widely deployed.  As IPv6 network should be interoperable with SRv6
   endpoints can be accommodated on it, interworking with existing IPv6
   network is out of scope of this document.

     ________                                                 _______
    /        \    O------O                                   /       \
   / Service  \===|L2/L3 |                                  / Service \
   \    NW    /   |Anchor|         User-plane               \    NW   /
    \________/    |Node  |         Function                  \_______/
                  O------O       <Interworking>                  ||
                      \\_______     O------O     ________     O------O
                      /        \    | SRv6 |    /        \    | SRv6 |
                     / Existing \===| End  |===/ IPv6-Only\===| End  |
                     \  IPv4 NW /   | Point|   \  Network /   | Point|
       [MN]           \________/    O------O    \________/    O------O
        |             //                                         ||
     ___v____    O------O                                     ___||__
    / Radio  \   |Access|                                    / Radio  \
   /  Access  \==|Point |                            [MN]~~~/  Access  \
   \    NW    /  |Node  |                                   \    NW    /
    \________/   O------O                                    \________/

           Figure 2: Interworking with Existing Mobile Networks

   The detail of SRv6 segments representing user-plane functions are
   described in Section 5.

5.  Supporting Mobile User-Plane Functions

   This section describes mobile user-plane functions to which an SRv6
   node can apply SRv6 functions and behaviors.  The SRv6 node
   configured with those segments thereby fulfills the user-plane
   functions.  Each function consist of two segments which are uplink
   (UL) from mobile node to the correspondent node, and downlink (DL)
   from the correspondent node to mobile node.

   An SRv6 node may be configured with multiple type of user-plane
   functions.  Each function may also be configured with multiple sets
   of the segments for one type of function that to purpose of
   separating tenants, resources and service policies, etc.

5.1.  Access Point

   Access Point function provides SRv6 node the role to which mobile
   node is connected directly.  eNodeB could be referenced as an entity
   implementing the access point in 3GPP term.

   When an SRv6 node is configured for an Access Point function, the
   SRv6 node allocates one DL access-point segment SID per session, or
   per Access Point function which represents one policy that is shared
   by multiple sessions.

   Applicable SRv6 functions and behaviors are determined by use cases
   described in Section 6.

5.2.  Layer-2 Anchor

   Layer-2 anchor function provides SRv6 node the role to be anchor
   point while mobile node move around within a serving area which could
   be assumed as a layer-2 network.  Serving Gateway (SGW) could be
   referenced as an entity implementing the layer-2 anchor in 3GPP term.

   When an SRv6 node is configured for a Layer-2 anchor function, the
   SRv6 node allocates UL L2-anchor segment SID per SRv6 policy, which
   is bound to next L3-anchor function and specific service if needed.
   The SRv6 node also allocates one DL L2-anchor segment SID per SRv6
   policy, which is bound to serving access point SID and specific
   service if needed.

   Applicable SRv6 functions and behaviors are determined by use cases
   described in Section 6.

5.3.  Layer-3 Anchor

   Layer-3 anchor function provides SRv6 node the role to be anchor
   point across a mobile network consists of multiple serving areas.
   Packet data network gateway (PGW) could be referenced as an entity
   implementing the layer-3 anchor.

   When an SRv6 node is configured abbreviation for a Layer-3 Anchor function, the
   SRv6 node allocates one UL L3-anchor segment SID per L3-anchor
   function.  Each L3-anchor SID represents one policy which forwarding table.  A FIB lookup is shared
   by multiple sessions, such as a routing table, or a service policy
   with
   lookup in the table.  The routing table should maintain forwarding
   entries of table.  When a packet is intercepted on a
   wire, it is possible that SRH[SL] is different from the belonging MNs.

   Applicable SRv6 functions and behaviors DA.

3.  Motivation

   Every day mobility networks are determined by use cases
   described in Section 6.

5.4.  Stateless Interworking

   Stateless interworking function provides SRv6 node a role getting more challenging to
   interworking between existing mobile user-plane operate:
   on one hand, traffic is constantly growing, and SRv6 mobile user-
   plane.  Figure 3 shows latency requirements
   are more strict; on the SRv6 SID format for stateless interworking
   function other-hand, there are new use-cases like NFV
   that is encoding identifiers of corresponding tunnel in
   existing are also challenging network as argument of management.

   Problem comes from the SID.

             +----------------------+-------+-------+-------+
             |    IW-IPv6-Prefix    |IPv4DA |IPv4SA |TUN-ID |
             +----------------------+-------+-------+-------+
                     128-a-b-c          a      b       c

               Figure 3: Stateless Interworking SID Encoding

   Stateless interworking function introduce following SRv6 end function
   and transit behavior.

   End.TM:                 End point function with encapsulation for
                           mapped tunnel
   T.Tmap:                 Transit behavior with tunnel decapsulation
                           and mapping an SRv6 Policy

   Stateless interworking function is associated with fact that the following
   mandatory parameters:

   IW-IPv4-Prefix:         IPv4 prefix representing network of SRv6
                           user-plane for legacy mobile user-plane
   IW-IPv6-Prefix:         IPv6 prefix representing network current architecture of legacy mobile
   networks is agnostic to the underlying transport.  Indeed, it rigidly
   fragments the user-plane for SRv6 into radio access, core and service networks
   and connects them by tunneling techniques through the user-plane
   TUN-PROTO:              Tunnel protocol type,
   roles such as GTP-U or GRE
                           for PMIP

5.4.1.  End.TM: End point function with encapsulation for mapped tunnel

   The "End point to encapsulate for mapped tunnel" function (End.TM access and anchor nodes.  Such agnosticism and
   rigidness make it difficult for
   short) is used the operator to optimize and operate
   the direction from SRv6 user-plane data-path.

   While the mobile network industry has been trying to legacy user-
   plane network.

   When interworking node N receives a packet destined solve those
   problems, applications have shifted to S use IPv6, and S is a
   local End.TM SID, N does:

 1. IF NH=SRH & SL > 0 THEN
 2.    decrement SL
 3.    update network
   operators have started adopting IPv6 as their IP transport as well.
   SRv6, the IPv6 DA with SRH[SL]
 4.    push header instantiation of TUN-PROTO with tunnel ID from S            ;; Ref1
 5.    push outer IPv4 header with SA, DA from S
 6. ELSE
 7.    Drop Segment Routing
   [I-D.ietf-spring-segment-routing], integrates both the packet

   Ref1: TUN-PROTO indicates target tunnel type.

5.4.2.  T.Tmap: Transit behavior with tunnel decapsulation and mapping
        an SRv6 Policy

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

   When interworking node N receives a packet destined underlying transport layer into one single
   protocol, allowing operators to a IW-
   IPv4-Prefix, N does:

 1.   IF P.PLOAD == TUN-PROTO & T.PLOAD == IPv6 THEN    ;; Ref1, Ref1bis
 2.      pop optimize the outer IPv4 header network in a simplified
   manner and tunnel headers
 3.      copy IPv4 DA, SA, TUN-ID to form SID B with IW-IPv6-Prefix
 4.      insert removing state from the SRH (D, B; SL=1)                    ;; Ref2, Ref2bis
 5.      set network.

   Further on, SRv6 introduces the IPv6 DA = B
 6.      forward along notion of network-programming
   [I-D.filsfils-spring-srv6-network-programming], that applied to
   mobility fulfils the shortest path user-plane functions of mobility management.
   SRv6 takes advantage of underlying transport awareness and
   flexibility to B
 7.   ELSE
 8.      Drop deploy mobility user-plane functions in an optimized
   manner.  Those are the packet

   Ref1: P.PLOAD motivations to adopt SRv6 for mobile user-
   plane.

4.  Reference Architecture

   This section describes a reference architecture and T.PLOAD represent payload protocol of possible
   deployment scenarios.

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

   Please note that all the receiving
   packet, and payload protocol of user-plane described in this document does
   not depend on any specific architecture.  This architecture is just
   used as a reference based on the tunnel respectively.

   Ref1bis: First nibble latest 3GPP standards at the time of payload
   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: Reference Architecture

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

      *  UPF1: Interfaces N3 and N9
      *  UPF2: Interfaces N9 and N6
      *  Note: For simplicity we don't depict a UPF that is used only
         connected to determine payload
   protocol N9 interfaces, although the techniques described
         in GTP-U case due to it has no payload protocol indicator this document are also valid in
   the header.

   Ref2: The received IPv6 DA is placed as last SID such case.
   o  SMF : Session Management Function
   o  AMF : Access and Mobility Management Function
   o  DN : Data Network e.g. operator services, Internet access

   A session from an UE gets assigned to an UPF.  Sometimes more than
   one UPF may be used for providing a certain kind of richer service
   functions.  UE gets its IP address from the inserted SRH.

   Ref2bis: DHCP block of its UPF.
   The SRH is inserted before any other IPv6 Routing Extension
   Header.

5.5.  Rate Limit

   Mobile user-plane requires rate-limit feature.  SID UPF advertises the IP address block towards the Internet ensuring
   that return traffic is able routed to encode
   limiting rate as an argument in SID.  Multiple flows of packets
   should have same group identifier in SID when those flows are in an
   same AMBR group. the right UPF.

5.  User-plane behaviors

   This helps to keep section describes the mobile user-plane stateless.  That
   enables behaviors using SRv6.

   In order to simplify the SRv6 endpoint nodes adoption, we present two different
   "modes" that vary with respect the SRv6 SID allocation.  The first
   one is the "Traditional mode", which are unaware from inherits the traditional mobile
   control-plane information.  Encoding format of rate limit segment SID
   user-plane.  In this mode there is following:

              +----------------------+----------+-----------+
              | Locater no change to mobility networks
   architecture, except for the pure replacement of rate-limit| group-id | limit-rate|
              +----------------------+----------+-----------+
                        128-i-j            i          j

               Figure 4: Stateless Interworking GTP-U [TS.29281] for
   SRv6.

   The second mode is the "Enhanced mode", which aggregates the mobile
   sessions and allocates SID Encoding

   In case on a per policy basis.  The benefit of j bit length is zero in SID, the node should not do rate
   limiting unless static configuration or control-plane sets
   latter is that the limit
   rate associated to SR policy contains SIDs for Traffic Engineering
   and VNFs.  Both of these modes assume both the SID.

6.  Segment Routing IPv6 Functions gNB and Behaviors by Use Cases UPFs are SR-
   aware (N3 and N9 interfaces are SRv6).

   Additionally, 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-. One of these
   mechanism 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 describes makes reference to already existing SRv6 functions and behavior applied to
   defined in [I-D.filsfils-spring-srv6-network-programming] as well as
   new SRv6 functions designed for the mobile userplane.  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 by
   are the same as existing ones except the use cases.  Terminology of SRv6 endpoint
   functions refers as the data
   plane instead of GTP-U.  No impact to [I-D.filsfils-spring-srv6-network-programming].

6.1.  Basic Mode the rest of mobile system
   should be expected.

   In the basic mode, traditional mobile network, 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 with the SRv6 encaps, while
   not changing anything else.

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

   Our reference topology is shown in Figure 2.  In this mode we assume
   that mobile user-plane functions the gNB and the UPFs are as
   same as existing ones except using SRv6.  This means that there SR-aware.

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

              Figure 2: Traditional mode - Reference topology

5.1.1.  Packet flow - Uplink

   The uplink packet flow is no
   impact the following:

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

   The UE packet arrives to rest part of mobile system should be expected while the gNB.  The gNB performs a
   T.Encaps.Reduced operations.  Since there is only one SID, there is
   no
   advanced segment routing features are introduced need to it.

               +---------------------+----------+----------+
               | User-plane Function |  Uplink  | Downlink |
               +---------------------+----------+----------+
               | Access Point        | T.Insert |  End.X   |
               | L2-anchor           |  End.B6  |  End.B6  |
               | L3-anchor           |  End.T   | T.Insert |
               +---------------------+----------+----------+

                  Table 1: SRv6 Functions push an SRH. gNB only adds an outer IPv6 header with IPv6
   DA U1::1.  U1::1 represents an anchoring SID specific for Basic Mode

6.1.1.  Uplink

   In uplink, SRv6 node applies following SRv6 end point functions and
   transit behavior.  SIDs are allocated per L3-anchor that
   session at UPF1.  The SID U1::1 is retrieved through the existing
   control plane (N2 interface).

   Upon packet arrival on UPF1, the SID U1::1 is a local End.MAP
   function.  This function in maps the
   SRv6 nodes of both L2 SID with the next anchoring point
   and L3-anchor functions replaces U1::1 by U2::1, that belongs to the next anchoring
   point.

   Upon packet arrival on UPF2, the SID U2::1 corresponds to an End.DT
   function.  UPF2 decapsulates the packet, performs a lookup in basic mode.

   Access Point: a
   specific table and forwards the packet towards the data network.

5.1.2.  Packet flow - Downlink

   The downlink packet flow is the following:

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

   When the access point node receives a packet destine arrives to "D::1"
         from the UPF2, the UPF2 will map that
   particular flow into a mobile node "S::1", it does T.Insert process for UE session.  This UE session is associated
   with the
         receiving packets to push policy <U1::1>.  The UPF2 performs a T.Encaps.Reduced
   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 SRH with local End.MAP
   function.  This function maps the SID list <A2::1, D::1> with SL=1.  The access the next anchoring point node update DA
   and replaces U1::1 by gNB::1, that belongs to the next UL
         L2-anchor anchoring
   point.

   Upon packet arrival on gNB, the SID "A2::1" which gNB::1 corresponds to an End.DX4/
   End.DX6 function.  The gNB will decapsulates the SL indicates packet, removing the
   IPv6 header and all it's extensions headers and will forward the
         packet.

   Layer-2 Anchor:

         The L2-anchor node of "A2::1" segment does End.B6 process for
         the receiving packet according to
   traffic towards the SRH.  The node updates DA UE.

5.1.3.  IPv6 user-traffic

   For IPv6 user-traffic it is RECOMMENDED to next UL L3-anchor SID "A3::1" bound perform encapsulation.
   However based on local policy, a service provider MAY choose to "A2::1" 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 forward 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 mode improves the packet. scalability.  In this basic addition, it provides key
   improvements in terms of traffic steering and service chaining,
   thanks to the use case, just of an SR policy of multiple SIDs, instead of single
   one UL L3-anchor in the Traditional mode.

   Key points:

   o  Several UE share the same SR Policy (and it's composing SID)
   o  The SR policy MAY include SIDs for traffic engineering and service
      chaining on top of the UPF anchor.

   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
         with SL=0 list through a
      mechanism like PCEP, DNS-lookup, small augment for LISP control-
      plane, etc.

   Our reference topology is enough shown in Figure 3.  In this mode we assume
   that the gNB and the UPF are SR-aware.  We also assume that we have
   two services 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 do it so perform Traffic Engineering.  Note that there S1 and C1
   belong to the underlay and don't have an N4 interface.  For this
   reason we don't consider them UPFs.

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

               Figure 3: Enhanced mode - Reference topology

5.2.1.  Packet flow - Uplink

   The uplink packet flow is no need to push
         another SRH to the packet in that following:

   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 (Penultimate Segment Pop)
         operation.

   Layer-3 Anchor:

         The L3-anchor node of "A3::1" segment does End.T process for
         the receiving
   UPF2_out: (A,Z)                          -> End.DT4 or End.DT6

   UE sends its packet according (A,Z) on a specific bearer session to its gNB.
   gNB's CP associates that session from the SRH.  The node decrement
         SL to 0, updates DA to D::1 which UE(A) with the SL indicates IPv6 address
   B and GTP TEID T. gNB's CP does a lookup
         IPv6 table associated with "A3::1".  In this basic use case, on B (by reverseDNS, LISP,
   etc.) to find the decremented SL is 0 so that related SID list <S1, C1, U2::1>.

   Once the node does PSP operation of
         popped out packet leaves the SRH from gNB, it already contains all the packet and forward it.

6.1.2.  Downlink

   In downlink, SRv6 node applies following SRv6 end point functions and
   transit behavior.  SIDs are allocated per session in segments
   of the SRv6 SR policy.  This SR policy contains segments for traffic
   engineering (C1) and for service chaining (S1).

   The nodes
   of both L2-anchor S1 and access point functions in basic mode.

   Layer-3 Anchor: C1 perform their related Endpoint functionality and
   forward.

   When the L3-anchor node receives a packet destine arrives to "S::1"
         from a correspondent node "D::1", it does T.Insert process for UPF2, the receiving packets to push a SRH with SID list <A2::2, S::1>
         with SL=1.  The L3-anchor node update DA to next DL L2-anchor
         SID "A2::2" active segment (U2::1) is an
   End.DT4/6 which performs the SL indicates decapsulation (removing the IPv6 header
   with all it's extension headers) and forward towards the packet.

   Layer-2 Anchor:

         The L2-anchor node of "A2::2" segment does End.B6 process for data
   network.

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

5.2.2.  Packet flow - Downlink

   The downlink packet according to flow is the SRH.  The node updates DA
         to next DL access point segment "A1::1" bound to "A2::2" and
         forward following:

   UPF2_in : (Z,A)                              -> UPF2 maps the packet.  In this basic use case, just one DL access
         point flow w/
                                                   SID with SL=0 is enough 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 do it so the UPF2, the UPF2 will map that there
   particular flow into a UE session.  This UE session is no need
         to push another SRH to associated
   with the packet in that PSP (Penultimate
         Segment Pop) operation.

   Access Point: policy <C1, S1, gNB>.  The UPF2 performs a T.Encaps.Reduced
   operation, encapsulating the packet into a new IPv6 header with its
   corresponding SRH.

   The access point node of "A1::1" segment does End.X process for nodes C1 and S1 perform their related Endpoint processing.

   Once the receiving packet according arrives to the segment.  The node
         decrement SL to 0, updates gNB, the IPv6 DA corresponds to S::1 which an
   End.DX4 or End.DX6 (depending on the SL indicates underlying traffic).  The gNB
   will decapsulate the packet, removing the IPv6 header and all it's
   extensions headers and will forward the packet traffic towards 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 mobile node of "S::1" through
         radio channel associated 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 "A1::1". unchanged gNB GTP behavior

   In this section we introduce two mechanisms for interworking with
   legacy gNBs that still use case, GTP.  One of the
         decremented SL mechanisms is 0 so that valid for
   IPv4 while the node other for IPv6.

   In this scenario, it is assumed that gNB does PSP operation of
         popped out not support SRv6.  It
   just supports GTP encapsulation over IPv4 or IPv6.  Hence in order to
   achieve interworking we are going to add a new SR Gateway (SRGW-UPF1)
   entity.  This SRGW is going to map the SRH from GTP traffic into SRv6.  Note
   that the packet and forward SR GW is not an anchor point.

   The SRGW maintains very little state on it.

6.2.  Aggregate Mode  For this reason, both of
   these methods (IPv4 and IPv6) scale to millions of UEs.

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

               Figure 4: Reference topology for interworking

5.3.1.  Interworking with IPv6 GTP

   In this interworking mode we assume that the aggregate mode, user-plane function gNB is able to steer multiple
   mobile sessions per service policy.  This means that mobile sessions
   paths are aggregated using GTP over
   IPv6 in the N3 interface

   Key points:

   o  gNB is unchanged (control-plane or user-plane) and encaps into a service path which includes GTP
      (N3 interface is not only
   mobile user-plane functions but also other nodes, links or service
   functions.  SIDs are allocated per service policy in modified).
   o  5G Control-Plane (N2 interface) is unmodified: 1 IPv6 address
      (i.e. a BSID at the SRGW)
   o  SRGW removes GTP, finds SID list related to DA, add SRH with the SRv6 nodes
   of user-plane functions
      SID list.
   o  There is NO state for the downlink at the SRGW.
   o  There is simple state in the aggregate mode.

   Aggregate uplink at the SRGW (leveraging the
      enhanced mode user-plane results in few SR policies on this node.  A SR
      policy can take advantage of SRv6 that enables
   seamless mobile user-plane deployment with service chaining, VPNs,
   traffic-engineering by computed path to fulfil be shared across UEs).
   o  As soon as the policy.

          +---------------------+---------------+---------------+
          | User-plane Function |     Uplink    |    Downlink   |
          +---------------------+---------------+---------------+
          | Access Point        |    T.Insert   |      End      |
          | L2-anchor           | End or End.B6 | End or End.B6 |
          | L3-anchor           |     End.T     |    T.Insert   |
          +---------------------+---------------+---------------+

                Table 2: SRv6 Functions for Aggregate Mode

6.2.1.  Uplink packet leaves the gNB (uplink), the traffic is SR-
      routed.  This simplifies considerably network slicing
      [I-D.hegdeppsenak-isis-sr-flex-algo].
   o  In the uplink, SRv6 node applies following SRv6 end point functions and
   transit behavior.

   Access Point:

         When we use the access point node receives a packet destine IPv6 DA BSID to "D::1"
         from a mobile node "S::1", steer the traffic into
      an SR policy when it does T.Insert process for arrives at the
         receiving packets.

         First scenario SRGW-UPF1-.

   Our reference topology is shown in Figure 5.  In this mode we assume
   that the service policy for "D::1" gNB is an unmodified gNB using IPv6/GTP.  The UPFs are SR-
   aware.  Also, as explained before, we introduce a new SRGW entity
   that is via going to map the IPv6/GTP traffic to SRv6.

   We also assume that we have two service function segment, S1 and node C1 before reach to L2-anchor
         "A2::1" so that C1.  S1
   represents a VNF in the node pushes network, and C1 represents a SRH router over
   which we are going to perform Traffic Engineering.

                                  +----+
                IPv6/GTP         -| S1 |-                            ___
   +--+  +-----+ [N3]           / +----+ \                          /
   |UE|--| gNB |-         SRv6 /   SRv6   \ +----+   +------+ [N6] /
   +--+  +-----+ \        [N9]/    NFV     -| 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:

   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 list <S1, C1,
         A2::1, D::1> with SL=3. 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 node updates DA UE sends a packet destined to service
         function S1 Z towards the gNB on a specific
   bearer for that session.  The gNB, which is unmodified, encapsulates
   the SL indicates packet into a new IPv6, UDP and GTP headers.  The IPv6 DA B, and forward
   the packet.

         Second case is that GTP TEID T are the access point function directly
         indicates ones received in the path beyond N2 interface.

   The IPv6 address that was signalled over the L2-anchor, service function S2
         and L3-anchor "A3::1" N2 interface for example, that UE
   session, B, is now the SID list shoud be <S1,
         C1, A2::, S2, A3::1, D::1> with SL=5.

   Layer-2 Anchor:

         It IPv6 DA.  B is assumed that an SRv6 Binding SID
   instantiated at the packet successfully traversed S1 and C1
         segments so that SRGW.  Hence the SL was decremented 3 packet, will be routed up to 1 in the first
         scenario, and 5 to 3 in
   SRGW.

   When the second scenario before arriving packet arrives at the
         node of "A2::1" or "A2::" segment.

         In SRGW, the first scenario SRGW realises that the L2-anchor node of "A2::1"
         segment B is bound to a service policy which indicates path via
         service function S2 and L3-anchor function A3::1, an
   End.M.GTP6.D BindingSID.  Hence, the node does
         End.B6 process for SRGW will remove the receiving packet to IPv6, UDP
   and GTP headers, and will push a new SRH with
         SID list <S2, A3::1> IPv6 header with SL=1.  The node updates DA its own SRH
   containing the SIDs bound to next
         service function SID S2 which the SL indicates SR policy associated with this
   BindingSID.

   The nodes S1 and forward the
         packet.

         In C1 perform their related Endpoint functionality and
   forward.

   When the second scenario that one SRH with SIDs <S1, C1, A2::,
         S2, A3::1, D::1>, packet arrives to UPF2, the L2-anchor node of "A2::" active segment is (U2::1) which
   bound to just End function. End.DT4/6 which is going to perform the decapsulation
   (removing the outer IPv6 header with all it's extension headers) and
   forward towards the data network.

5.3.1.2.  Packet flow - Downlink

   The node does End process for downlink packet flow is the following:

   UPF2_in : (Z,A)                           -> UPF2 maps the
         receiving 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 according destined to A arrives at the SRH that decrements SL to 2,
         updates DA to next service function SID S2 which UPF2, the SL
         indicates UPF2 performs a
   lookup in the associated table to A and forward finds the packet.

   Layer-3 Anchor: SID list <C1, S1,
   SRGW::TEID, gNB>.  The L3-anchor node of "A3::1" segment does End.T process for UPF2 performs a T.Encaps.Reduced 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 receiving packet according arrives to the SRH(s).

         In SRGW, the first scenario that outer SRH with SIDs <S2, A3::1>, it
         is assumed that SRGW realizes the SL active SID
   is decremented to 0 at service function
         S2 so that the node pops outer SRH.  Then an End.M.GTP6.E function.  The SRGW removes the node processes
         second SRH with SIDs <S1, C1, A2::1, D::1> that decrements SL
         to 0, updates IPv6 header and
   all it's extensions headers.  The SRGW generates an IPv6, UDP and GTP
   headers.  The new IPv6 DA to D::1 is the gNB which is the SL indicates and lookup IPv6
         table associated with "A3::1".  In this case, last SID in the decremented
         SL
   received SRH.  The TEID in the generated GTP header is 0 so that the node does PSP operation arguments
   of popped out the
         SRH from received End.M.GTP6.E SID.  The SRGW pushes the headers to the
   packet and forward it.

         In forwards the second scenario that one SRH with SIDs <S1, C1, A2::,
         S2, A3::1, D::1>, L3-anchor node of "A3::" segment does End.T
         process for packet towards the gNB.

   Once the receiving packet according arrives to the SRH.  Rest
         part of processes are as same as previous case.

6.2.2.  Downlink

   In downlink, SRv6 node applies following SRv6 end point functions and
   transit behavior.

   Layer-3 Anchor:

         When gNB, the L3-anchor node receives a packet destine to "S::1"
         from is a mobile node "D::1", it does T.Insert process regular IPv6/GTP
   packet.  The gNB looks for the
         receiving packets.

         First scenario is specific radio bearer for that TEID
   and forward it on the service policy for "S::1" bearer.  This gNB behavior is via
         service function S2 before reach to L2-anchor "A2::2" so that 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 node pushes a SRH with SID list <S2, A2::2, S::1> with
         SL=2. imposed by the UPF2.  The node updates DA to service function S2 which UPF2 must have the SL
         indicates and forward UE states as the packet.

         Second scenario
   session anchor point.

   For the uplink traffic, the state at the SRGW does not necessarily
   need to be per UE session basis.  A state of SR policy of which state
   can be shared among UE's.  Hence it is possible to deploy SRGW in
   very scalable way compared to hold millions of states per UE session
   basis.

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 L3-anchor function directly
         indicates the path beyond gNB is using GTP over
   IPv4 in the L2-anchor, service function S1,
         node C3 N3 interface

   Key points:

   o  gNB is unchanged and access point "A1::" for example, encaps into GTP (N3 interface is not
      modified).
   o  In the uplink, traffic is classified at SRGW by UL CL(Uplink
      Classifier) and steered into an SR policy.  The SRGW is a UPF1
      functionality, hence it can coexist with UPF UL CL functionality.
   o  SRGW removes GTP, finds SID list shoud
         be <S2, A2::, S1, C1, A1::1, D::1> related to DA, add SRH with SL=5.

   Layer-2 Anchor:

         It SID
      list.

   Our reference topology is assumed shown in Figure 6.  In this mode we assume
   that the packet successfully traversed S2 segment
         so gNB is an unmodified gNB using IPv4/GTP.  The UPFs are SR-
   aware.  Also, as explained before, we introduce a new SRGW entity
   that the SL was decremented 2 is going to 1 in map the former case, and 5 IPv4/GTP traffic to 4 in the latter case before arriving the node of "A2::2" or
         "A2::" segment.

         In the first scenario SRv6.

   We also assume that the L2-anchor node of "A2::2"
         segment is bound to a service policy which indicates path via
         node C1, we have two service function segment, S1 and access point function A1::,
         the node does End.B6 process for C1.  S1
   represents a VNF in the receiving packet to push network, and C1 represents a
         new SRH with SID list <C1, S1, A1::1> with SL=1.  The node
         updates DA router over
   which we are going to next service function SID perform Traffic Engineering.

                                  +----+
                IPv4/GTP         -| S1 |-                            ___
   +--+  +-----+ [N3]           / +----+ \                          /
   |UE|--| gNB |-         SRv6 /   SRv6   \ +----+   +------+ [N6] /
   +--+  +-----+ \        [N9]/    NFV     -| C1 which the SL
         indicates and forward the packet.

         In the second scenario that one SRH |---| UPF2 |------\  DN
           GTP    \ +------+ /              +----+   +------+       \___
                   -| UPF1 |-                SRv6      SRv6
                    +------+                  TE
                   SR Gateway

       Figure 6: Enhanced mode with SIDs <S1, C1, A2::,
         S2, A3::1, D::1>, the L2-anchor node of "A2::" segment is bound
         to just End function. unchanged gNB IPv4/GTP behavior

5.3.2.1.  Packet flow - Uplink

   The node does End process for uplink packet flow is the
         receiving following:

    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 according destined to Z towards the SRH gNB on a specific
   bearer for that decrements SL to 2,
         updates DA to next node C1 which the SL indicates and forward session.  The gNB, which is unmodified, encapsulates
   the packet.

   Access Point: packet into a new IPv4, UDP and GTP headers.  The access point node of "A1::1" segment does End process for IPv4 DA, B, and
   the GTP TEID are the ones received at the N2 interface.

   When the receiving packet according arrives to the SRH(s).

         In SRGW -UPF1-, the first scenario that outer SRH with SIDs <C1, S1, A1::1>,
         it is assumed that SRGW has an UL CL
   (uplink classifier) rule for incoming traffic from the SL is decremented 2 to 0 at node C1 and
         service function S1 so gNB that
   steers the outer SRH is popped out traffic into an SR policy by PSP
         at S1.  Thus using the node processes second SRH with SIDs <S2,
         A2::2, S::1> that decrements SL to 0, updates DA to S::1 which function T.M.TMap.
   The SRGW removes the SL indicates IPv4, UDP and forward GTP headers and pushes an IPv6
   header with its own SRH containing the packet SIDs related to the mobile node
         through radio channel SR policy
   associated with "S::1".  In this case,
         the decremented SL is 0 so that the node does PSP operation of
         popped out traffic.  The SRGW forwards according to the SRH from new
   IPv6 DA.

   The nodes S1 and C1 perform their related Endpoint functionality and
   forward.

   When the packet and forward it.

         In arrives at UPF2, the second scenario that one SRH with SIDs <S2, A2::, C1,
         S1, A1::1, S::1>, access node of "A1::1" active segment does End
         process for the receiving packet according is (U2::1) which
   is bound to End.DT4/6 which performs the SRH.  Rest
         part of processes are as same as previous case.

6.3.  Stateless Interworking decapsulation (removing the
   outer IPv6 header with Legacy Access Network

   This section describes an use case where user-plane functions are
   interworking in stateless between SRv6 all it's extension headers) and legacy access networks.
   Here stateless means that there's no need to be aware any states of
   mobility sessions in forwards
   towards the node.

   As some types of interworking scenarios could be considered, we will
   describe other cases in data network.

5.3.2.2.  Packet flow - Downlink

   The downlink packet flow is the future versions of this document.

6.3.1.  Uplink: Lagacy Access to SRv6

   Legacy Access Point: following:

   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 legacy access point node receives a packet destined to
         "D::1" from A arrives to the UPF2, the UPF2 performs a
   lookup in the associated table to A and finds the SID list <C1, S1,
   SRGW::SA:DA:TEID>.  The UPF2 performs a mobile node "S::1" through associated radio
         channel, it does tunnel encapsulation with T.Encaps.Reduced operation,
   encapsulating the tunneling
         parameters, IPv4 DA, SA and tunnel packet into a new IPv6 header with ID, its
   corresponding SRH.

   The nodes C1 and sends
         out S1 perform their related Endpoint processing.

   Once the packet arrives to the network.

   Stateless Interworking:

         The stateless interworking node of corresponding to SRGW, the IPv4 DA
         does T.Tmap process for SRGW realizes the receiving packet to pop active SID
   is an End.M.GTP4.E function.  The SRGW removes the tunnel
         headers IPv6 header and push a SRH to the packet.
   all it's extensions headers.  The SRGW generates an IPv4, UDP and GTP
   headers.  The SRH consists of SIDs
         <B1, D::1> with SL=1, where "B1" encodes IW-IPv6-Prefix, tunnel IPv4 DA, SA and TUN-ID in it as Figure 3 defined.  The
         stateless interworking node updates DA to "B1" and forward will the
         packet.  SA ones received as part of the packet must be kept as "S::1".

   Layer-2 or Layer-3 Anchor:
   SID arguments.  The receiving node of TEID in the packet destine to B1 either be
         Layer-2 anchor, or Layer-3 anchor node.  Which type of anchor
         function bound to B1 depends on operational policy.

         In case generated GTP header is also the
   arguments of B1 the received End.M.GTP4.E SID The SRGW pushes the
   headers to an L2-anchor node, the L2-anchor node does
         End.B6 process for packet and forwards the receiving packet as same as previous
         section.

         In case of B1 towards the gNB.

   Once the packet arrives to an L3-anchor node, the L3-anchor node does
         End.T process for gNB, the receiving packet as same as 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
         section.

6.3.2.  Downlink: SRv6 to Legacy Access

   Layer-2 or Layer-3 Anchor:

         In case of generations.

5.3.2.3.  Scalability

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

   For the uplink traffic, the state at the SRGW is dedicated on a per
   UE/session basis.  This is an L3-anchor node receives UL CL (uplink classifier).  There is
   state for steering the different sessions on a SR policies.  Notice
   however that the 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 on local policy, a service provider MAY choose to do
   SRH insertion.  The main benefit is a packet destine lower overhead.

5.3.3.  Extensions to S::1
         from the correspondent node "D::1", and stateless interworking
         SID is bound 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 next segment of S::1 ,
   "Enhanced mode", it is straightforward in its applicability to the L3-anchor node
         does T.Insert process
   "Traditional mode".

   Furthermore, although these mechanisms are designed for interworking
   with legacy RAN at the receiving packet to push N3 interface, these methods could also be
   applied for interworking with a SRH 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 with SID list <B2::, S::1> mapping

   The "Endpoint function with SL=1, where "B2" which encodes
         IW-IPv6-Prefix, tunnel IPv4 DA, SA and TUN-ID SID mapping" function (End.MAP for short)
   is used in several scenarios.  Particularly in mobility, it as Figure 3
         defined.  The L3-anchor node updates DA to "B2" and forward is used
   in the
         packet.

         In case UPFs for the anchor functionality in some of an L2-anchor the use-cases.

   When a SR node N receives a packet destine destined to SID
         "A2::B2" S and the SID S is bound to "B2", a local
   End.MAP SID, N does:

   1.    look up the L2-anchor node does
         End.B6 process for IPv6 DA in the receiving packet as same as previous
         section.  The node updates mapping table
   2.    update the IPv6 DA to B2 and with the new mapped SID              ;; Ref1
   5.    forward according to the packet.

   Stateless Interworking:

         The stateless interworking node of "B2" End.TM process for new mapped SID
   8. ELSE
   9.    Drop the
         receiving packet according to

   Ref1: Note that the SRH.  The node decrement SL
         to 0, updates DA to "D::1" which SID in the SL indicates, push IPv4
         and tunnel headers SRH is NOT modified.

6.2.  End.M.GTP6.D: Endpoint function with IPv4 DA, SA and TUN-ID extracted decapsulation from
         "B2", and forward the packet to the legacy network.

         In this use case, decremented SL IPv6/GTP
      tunnel

   The "Endpoint function with IPv6/GTP decapsulation into SR policy"
   function (End.M.GTP6.D for short) is 0 so that the node does PSP
         operation of popped out used in interworking scenario
   for the SRH uplink towards from the packet and forward it.

   Legacy Access Point:

         The legacy access point node of the IPv4 DA does tunnel
         termination process for gNB using IPv6/GTP.  This SID
   is associated with an SR policy <S1, S2, S3> and an IPv6 Source
   Address A.

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

   1. IF NH=UDP & UDP_PORT = GTP THEN
   2.    pop the IPv4 IP, UDP and tunnel GTP headers
   3.    push a new IPv6 header and
         forward the packet to the mobile node through radio channel
         associated with its own SRH <S2, S3>
   4.    set the tunnel.

7.  Network Slicing Considerations

   Mobile network may be required outer IPv6 SA to create a network slicing that
   represent a A
   5.    set the outer IPv6 DA to S1
   6.    forward according to the first segment of network resources and isolate those resource from
   other slices.  User-plane functions represented as the SRv6 segments
   would be part of a slice.

   To represent a set of user-plane Policy
   7. ELSE
   8.    Drop the packet

6.3.  End.M.GTP6.E: Endpoint function segments with encapsulation for a slice,
   sharing same prefix through those SIDs within the slice could be a
   straightforward way.  SIDs IPv6/GTP
      tunnel

   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 the legacy gNB using IPv6/GTP.

   The End.M.GTP6.E function has a network slice may include other type
   of functions in addition 32-bit argument space.  This argument
   corresponds to the mobile user-plane functions described
   in this document, and underlay integration to meet SLA and quality
   requirements.

   While network slicing has been discussed in GTP TEID.

   When the IETF SR Gateway node N receives a packet destined to S and other
   standardization bodies, what functionalities are required for network
   slicing S is a
   local End.M.GTP6.E SID, N does:

    1. IF NH=SRH & SL = 1  THEN                                  ;; Ref1
    2.    decrement SL
    3.    store SRH[SL] in mobile user-plane is further study item variable new_DA
    4.    store TEID in variable new_TEID                        ;; Ref2
    5.    pop IP header and all it's extension headers
    6.    push new IPv6 header and GTP-U header
    7.    set IPv6 DA to be
   discussed. new_DA
    8.  Control Plane Considerations

8.1.  Existing Control Plane

   A mobile control-plane entity may allocate SIDs    set GTP_TEID to new_TEID
    9.    lookup the node of
   corresponding user-plane function.  In this case, new_DA and forward the control-plane
   entity must signal allocated SIDs to other side packet accordingly
   10. ELSE
   11.    Drop the packet

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

   Ref2: TEID is extracted from the argument space of entity.

   If the control-plane entity needs to employ existing mobile control-
   plane protocol to signal, GTP-C or PMIP current SID.

6.4.  End.M.GTP4.E: Endpoint function with encapsulation for example, it must require
   not to impact the control-plane protocols.  In this case, IPv4/GTP
      tunnel
   endpoint IPv6 address field

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

   When the SR Gateway node N receives a packet destined to signal S and S is a SID.

   The basic mode described in Section 6.1 should be adopted.  In
   local End.M.GTP4.E SID, N does:

   1. IF NH=SRH & SL > 0 THEN
   2.    decrement SL
   3.    update the
   basic mode, SID IPv6 DA with SRH[SL]
   4.    pop the SRH
   4.    push header of TUN-PROTO with tunnel ID from S          ;; Ref1
   5.    push outer IPv4 header with SA, DA from S
   6. ELSE
   7.    Drop the packet
   Ref1: TUN-PROTO indicates unique session so 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

   The "Transit with tunnel identifier decapsulation and map to an SRv6 policy"
   function (T.Tmap for short) is
   not required used in the direction from legacy
   user-plane to SRv6 user-plane.  But the mobile control-plane may be
   assumed that one user-plane entity has one IPv6 address network.

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

   1. IF P.PLOAD == TUN-PROTO THEN    ;; Ref1
   2.    pop the outer IPv4 header and it
   allocates tunnel identifier per session.  In this case, SRv6 node of
   user-plane can headers
   3.    copy IPv4 DA, SA, TUN-ID to form SID B with SRGW-IPv6-Prefix
   4.    encapsulate the packet into a new IPv6 address and header  ;; Ref2, Ref2bis
   5.    set the tunnel
   identifier.

   When an IPv6 prefix "A::/64" is allocated DA = B
   6.    forward along the shortest path to an user-plane, and B
   7. ELSE
   8.    Drop the
   control-plane allocate one 32bits packet

   Ref1: TUN-PROTO indicates target tunnel identifier of "0x12345678"
   for a mobile session, type.

   Note that B has the user-plane node forms following format:

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

                         End.M.GTP4.E SID
   "A::1234:5678".

   In this way, there Encoding

   Note that the B SID, is no impact going to the control-plane.

8.2.  Aggregate Mode

   To support aggregate mode described in Section 6.2 in control-plane
   protocol, allocated SIDs for service policies can be signaled as
   tunnel endpoint IPv6 address too.  In this case, an SRv6 policy
   associated to BindingSID instantiated
   at the SID should be configured first UPF (anchor point).  A static format is leveraged to
   instantiate this Binding SIDs in the user-plane node
   through other means.

   Aggregate mode user-plane can take advantage of SRv6 that enables
   seamless mobile user-plane deployment with service chaining, VPNs,
   traffic-engineering by computed path order to fulfil remove state from the policy.

   In case of SRGW.

6.6.  End.Limit: Rate Limiting function

   Mobile user-plane requires a mobile control-plane rate-limit feature.  SID is aware able to
   encode limiting rate as an argument in SID.  Multiple flows of
   packets should have same group identifier in SID when those policies and is
   capable flows are
   in an same AMBR group.  This helps to advertise them, keep user-plane stateless.
   That enables SRv6 endpoint nodes which are unaware from the mobile
   control-plane can integrate
   SRv6 advanced features.

8.3.  User-Plane Sepalated Control Plane

   In an user-plane separated control-plane system, a mobile user-plane
   entity may allocate SIDs to an user-plane function instead information.  Encoding format of the
   control-plane. rate limit segment SID
   is following:

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

             End.Limit: Rate limiting function argument format

   In this case, case of j bit length is zero in SID, the user-plane entity node should inform
   allocated SIDs back to the not do rate
   limiting unless static configuration or control-plane entity.

   If sets the control- and user-plane entities need limit
   rate associated to employ existing user-
   plane control protocol in between, such as PFCP for example, it the SID.

7.  Network Slicing Considerations

   A mobile network may be required not to impact that protocol.  In this case, the control-
   plane entity is only allowed to signal SID in a tunnel endpoint IPv6
   address field.

8.4.  Centralized Controller

   When implement "network slices", which
   logically separate network resources.  User-plane functions
   represented as SRv6 segments would be part of a centralized controller interfaces slice.

   A simple way to mobile control-planes is
   capable represent slice would be to allocate SIDs apply L2/L3 VPN described
   in [I-D.filsfils-spring-srv6-network-programming].  Segment Routing
   with [I-D.hegdeppsenak-isis-sr-flex-algo] provides even more advanced
   separation based on metrics like link-delay.  Thus, a service
   provider would be able to the controlling have network slices per required SLA.

   The SRv6 nodes, the mobile
   control-planes just need to indicate nodes SID and their user-plane
   functions to the controller.  In this case, the controller must
   allocate appropriate SIDs quite a few SR extended capability would be a
   powerful tool for providing logical separation/integration within a
   network.  Details are for further study.

8.  Control Plane Considerations

   This documents focuses on the user-plane functions to the SRv6
   nodes.  The controller must configure allocated SIDs to the nodes.

   To indicate nodes and their user-plane functions from mobile control-
   plane to user-plane, the centralized controller dataplane behavior.  The control planes
   could take advantage
   of [I-D.ietf-dmm-fpc-cpdp].  It provides interface to be based on the control-
   plane existing 3GPP based signalling for N4 interface
   [TS.29244], [I-D.ietf-dmm-fpc-cpdp], control-plane protocols
   described in [WHITEPAPER-5G-UP], etc. and to manage be discussed further.

   Note that the user-plane IANA section of mobile networks.  To build
   centralized controller this document allocates the SRv6
   endpoint function types for mobile user-plane is out of scope of the new functions defined in this
   document.

8.5.  Stateless Interworking

   A mobile  All control-plane is not required protocols are expected to configure statless
   interworking leverage these
   function in interworking node.  This benefits operators
   to gradually migrate from legacy to advanced mobile user-plane with
   no impact to the legacy system.

   SID allocating entity of SRv6 user-plane nodes needs to be aware of
   IW-IPv6-Prefix to form interworking SID.  Legacy user-plane network
   allocate IPv4 address space routed to SRv6 user-plane network.  The
   mobile control-plane of legacy user-plane also need type-codes to allocate
   tunnel endpoint IPv4 addresses from signal each function.

   It's notable that address space for mobile
   sessions which is usual operation for it SRv6's network programming nature allows a flexible
   and no difference from
   legacy system. dynamic anchor placement.

9.  Security Considerations

   TBD

10.  IANA Considerations

   This document has no actions for IANA. I-D requests to IANA to allocate, within the "SRv6 Endpoint
   Types" 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:

           +-------------+-----+-------------------+-----------+
           | 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

11.  Acknowledgements

   TBD

   The authors would like to thank Daisuke Yokota, Bart Peirens,
   Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch and Darren Dukes for
   their useful comments of this work.

12.  References

12.1.  Normative References

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Leddy, J., daniel.voyer@bell.ca, d.,
              daniel.bernier@bell.ca, d., Steinberg, D., Raszuk, R.,
              Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
              Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
              Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
              Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
              Camarillo, "SRv6 Network Programming", draft-filsfils-
              spring-srv6-network-programming-02
              spring-srv6-network-programming-03 (work in progress),
              October
              December 2017.

   [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-13 draft-ietf-spring-segment-routing-15 (work
              in progress), October 2017. January 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>.

12.2.  Informative References

   [I-D.gundavelli-dmm-mfa]
              Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
              aware Floating Anchor (MFA)", draft-gundavelli-dmm-mfa-00
              (work in progress), February 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-09
              (work in progress), October 2017.

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <https://www.rfc-editor.org/info/rfc5213>.

   [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 10.3.0,
              September 2011. 15.1.0,
              December 2017.

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