[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-matsushima-spring-dmm-srv6-mobile-uplane) 00 01 02 03

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


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

Abstract

   This document discusses the applicability of SRv6 (Segment Routing
   IPv6) to user-plane of mobile networks that SRv6 source routing
   capability with its programmability can fulfill the user-plane
   functions, such as access and anchor functions.  It takes advantage
   of underlying layer awareness and flexibility to deploy user-plane
   functions that enables optimizing data-path for applications.
   Network slicing and an interworking way between SRv6 and existing
   mobile user-plane are also discussed in 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, 2018.

Copyright Notice

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




Matsushima, et al.        Expires June 3, 2018                  [Page 1]


Internet-Draft             SRv6-mobile-uplane              November 2017


   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 . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Mobile User-Plane . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Supporting Mobile User-Plane Functions  . . . . . . . . . . .   5
     5.1.  Access Point  . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Layer-2 Anchor  . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  Layer-3 Anchor  . . . . . . . . . . . . . . . . . . . . .   6
     5.4.  Stateless Interworking  . . . . . . . . . . . . . . . . .   7
       5.4.1.  End.TM: End point function with encapsulation for
               mapped tunnel . . . . . . . . . . . . . . . . . . . .   7
       5.4.2.  T.Tmap: Transit behavior with tunnel decapsulation
               and mapping an SRv6 Policy  . . . . . . . . . . . . .   8
     5.5.  Rate Limit  . . . . . . . . . . . . . . . . . . . . . . .   9
   6.  Segment Routing IPv6 Functions and Behaviors by Use Cases . .   9
     6.1.  Basic Mode  . . . . . . . . . . . . . . . . . . . . . . .   9
       6.1.1.  Uplink  . . . . . . . . . . . . . . . . . . . . . . .  10
       6.1.2.  Downlink  . . . . . . . . . . . . . . . . . . . . . .  10
     6.2.  Aggregate Mode  . . . . . . . . . . . . . . . . . . . . .  11
       6.2.1.  Uplink  . . . . . . . . . . . . . . . . . . . . . . .  11
       6.2.2.  Downlink  . . . . . . . . . . . . . . . . . . . . . .  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
   7.  Network Slicing Considerations  . . . . . . . . . . . . . . .  16
   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
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  18
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  18



Matsushima, et al.        Expires June 3, 2018                  [Page 2]


Internet-Draft             SRv6-mobile-uplane              November 2017


     12.2.  Informative References . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  19

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 route for the
   packets from and to the mobile node.  SRv6 endpoint nodes act as
   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 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 are requiring highly optimized data-
   path between mobile nodes and the entities of those applications in
   perspectives of latency, bandwidth, etc,. However current
   architecture of mobile management is agnostic about underlying
   topologies 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
   the operator to optimize the data-path.

   While the mobile network industry has been trying to solve that,
   applications shift to use IPv6 data-path and network operators adopt
   it as their IP transport as well.  SRv6 integrates both application
   data-path and underlying transport layer in data-path optimization
   aspects that does not require any other techniques.

   SRv6 source routing capability with programmable functions
   [I-D.filsfils-spring-srv6-network-programming] could fulfills the
   user-plane functions of mobility management.  It takes advantage of



Matsushima, et al.        Expires June 3, 2018                  [Page 3]


Internet-Draft             SRv6-mobile-uplane              November 2017


   underlying layer awareness and flexibility to deploy user-plane
   functions.  Those are 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 to which SRv6 endpoint
   applied.

   Figure 1 shows mobile user-plane functions which are connected
   through IPv6-only networks.  In the Figure 1, an mobile node (MN)
   connects to an SRv6 endpoint serving access point role for the MN.
   When the endpoint receives packets from the MN, it pushes SRH to the
   packets.  The segment list in the SRH indicates the rest of user-
   plane segments which are L2 and L3 anchors respectively.  Then the
   endpoint send the packets to the IPv6 network.  In opposite
   direction, when an SRv6 endpoint serving L3 anchor role for the MN
   receives packets to it, the endpoint push SRH consist of the L2
   anchor and access point segments to 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 and Layer-3 (L3) Anchor.  This makes mobile
   networks highly flexible to deploy any user-plane functions to which
   nodes in user flow basis.  An SRv6 segment can represent a set of



Matsushima, et al.        Expires June 3, 2018                  [Page 4]


Internet-Draft             SRv6-mobile-uplane              November 2017


   flows in any granularity of aggregation even though it is just for a
   single flow.

   Figure 2 shows that an SRv6 endpoint connects existing IPv4 mobile
   user-plane, which is defined in [RFC5213] and [TS.29281].  An SRv6
   segment in the endpoint represents interworking function which
   enables interworking between existing access point and SRv6 anchor
   segment, or SRv6 access point segment and existing anchor node.

   Existing mobile user-plane with IPv6 underlay 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



Matsushima, et al.        Expires June 3, 2018                  [Page 5]


Internet-Draft             SRv6-mobile-uplane              November 2017


   (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 for a Layer-3 Anchor function, the
   SRv6 node allocates one UL L3-anchor segment SID per L3-anchor



Matsushima, et al.        Expires June 3, 2018                  [Page 6]


Internet-Draft             SRv6-mobile-uplane              November 2017


   function.  Each L3-anchor SID represents one policy which is shared
   by multiple sessions, such as a routing table, or a service policy
   with in the table.  The routing table should maintain forwarding
   entries of the belonging MNs.

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

5.4.  Stateless Interworking

   Stateless interworking function provides SRv6 node a role to
   interworking between existing mobile user-plane and SRv6 mobile user-
   plane.  Figure 3 shows the SRv6 SID format for stateless interworking
   function that is encoding identifiers of corresponding tunnel in
   existing network as argument of 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 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 of legacy
                           mobile user-plane for SRv6 user-plane
   TUN-PROTO:              Tunnel protocol type, 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 for
   short) is used to the direction from SRv6 user-plane to legacy user-
   plane network.



Matsushima, et al.        Expires June 3, 2018                  [Page 7]


Internet-Draft             SRv6-mobile-uplane              November 2017


   When interworking node N receives a packet destined to S and S is a
   local End.TM SID, N does:

 1. IF NH=SRH & SL > 0 THEN
 2.    decrement SL
 3.    update the IPv6 DA with SRH[SL]
 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 target tunnel type.

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

   The "Transit with tunnel decapsulation 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 to a IW-
   IPv4-Prefix, N does:

 1.   IF P.PLOAD == TUN-PROTO & T.PLOAD == IPv6 THEN    ;; Ref1, Ref1bis
 2.      pop the outer IPv4 header and tunnel headers
 3.      copy IPv4 DA, SA, TUN-ID to form SID B with IW-IPv6-Prefix
 4.      insert the SRH (D, B; SL=1)                    ;; Ref2, Ref2bis
 5.      set the IPv6 DA = B
 6.      forward along the shortest path to B
 7.   ELSE
 8.      Drop the packet

   Ref1: P.PLOAD and T.PLOAD represent payload protocol of the receiving
   packet, and payload protocol of the tunnel respectively.

   Ref1bis: First nibble of payload is used to determine payload
   protocol in GTP-U case due to it has no payload protocol indicator in
   the header.

   Ref2: The received IPv6 DA is placed as last SID of the inserted SRH.

   Ref2bis: The SRH is inserted before any other IPv6 Routing Extension
   Header.








Matsushima, et al.        Expires June 3, 2018                  [Page 8]


Internet-Draft             SRv6-mobile-uplane              November 2017


5.5.  Rate Limit

   Mobile user-plane requires rate-limit feature.  SID is able 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.  This helps to keep user-plane stateless.  That
   enables SRv6 endpoint nodes which are unaware from the mobile
   control-plane information.  Encoding format of rate limit segment SID
   is following:


              +----------------------+----------+-----------+
              | Locater of rate-limit| group-id | limit-rate|
              +----------------------+----------+-----------+
                        128-i-j            i          j


               Figure 4: Stateless Interworking SID Encoding

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

6.  Segment Routing IPv6 Functions and Behaviors by Use Cases

   This section describes SRv6 functions and behavior applied to mobile
   user-plane functions by use cases.  Terminology of SRv6 endpoint
   functions refers to [I-D.filsfils-spring-srv6-network-programming].

6.1.  Basic Mode

   In the basic mode, we assume that mobile user-plane functions are as
   same as existing ones except using SRv6.  This means that there is no
   impact to rest part of mobile system should be expected while no
   advanced segment routing features are introduced 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 for Basic Mode






Matsushima, et al.        Expires June 3, 2018                  [Page 9]


Internet-Draft             SRv6-mobile-uplane              November 2017


6.1.1.  Uplink

   In uplink, SRv6 node applies following SRv6 end point functions and
   transit behavior.  SIDs are allocated per L3-anchor function in the
   SRv6 nodes of both L2 and L3-anchor functions in basic mode.

   Access Point:

         When the access point node receives a packet destine to "D::1"
         from a mobile node "S::1", it does T.Insert process for the
         receiving packets to push a SRH with SID list <A2::1, D::1>
         with SL=1.  The access point node update DA to next UL
         L2-anchor SID "A2::1" which the SL indicates and forward the
         packet.

   Layer-2 Anchor:

         The L2-anchor node of "A2::1" segment does End.B6 process for
         the receiving packet according to the SRH.  The node updates DA
         to next UL L3-anchor SID "A3::1" bound to "A2::1" and forward
         the packet.  In this basic use case, just one UL L3-anchor SID
         with SL=0 is enough to do it so that there is no need to push
         another SRH to the packet in that PSP (Penultimate Segment Pop)
         operation.

   Layer-3 Anchor:

         The L3-anchor node of "A3::1" segment does End.T process for
         the receiving packet according to the SRH.  The node decrement
         SL to 0, updates DA to D::1 which the SL indicates and lookup
         IPv6 table associated with "A3::1".  In this basic use case,
         the decremented SL is 0 so that the node does PSP operation of
         popped out the SRH from 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 the SRv6 nodes
   of both L2-anchor and access point functions in basic mode.

   Layer-3 Anchor:

         When the L3-anchor node receives a packet destine to "S::1"
         from a correspondent node "D::1", it does T.Insert process for
         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" which the SL indicates and forward the packet.




Matsushima, et al.        Expires June 3, 2018                 [Page 10]


Internet-Draft             SRv6-mobile-uplane              November 2017


   Layer-2 Anchor:

         The L2-anchor node of "A2::2" segment does End.B6 process for
         the receiving packet according to the SRH.  The node updates DA
         to next DL access point segment "A1::1" bound to "A2::2" and
         forward the packet.  In this basic use case, just one DL access
         point SID with SL=0 is enough to do it so that there is no need
         to push another SRH to the packet in that PSP (Penultimate
         Segment Pop) operation.

   Access Point:

         The access point node of "A1::1" segment does End.X process for
         the receiving packet according to the segment.  The node
         decrement SL to 0, updates DA to S::1 which the SL indicates
         and forward the packet to the mobile node of "S::1" through
         radio channel associated with "A1::1".  In this use case, the
         decremented SL is 0 so that the node does PSP operation of
         popped out the SRH from the packet and forward it.

6.2.  Aggregate Mode

   In the aggregate mode, user-plane function is able to steer multiple
   mobile sessions per service policy.  This means that mobile sessions
   paths are aggregated into a service path which includes not only
   mobile user-plane functions but also other nodes, links or service
   functions.  SIDs are allocated per service policy in the SRv6 nodes
   of user-plane functions in the aggregate mode.

   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 to fulfil 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

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




Matsushima, et al.        Expires June 3, 2018                 [Page 11]


Internet-Draft             SRv6-mobile-uplane              November 2017


   Access Point:

         When the access point node receives a packet destine to "D::1"
         from a mobile node "S::1", it does T.Insert process for the
         receiving packets.

         First scenario is that the service policy for "D::1" is via
         service function S1 and node C1 before reach to L2-anchor
         "A2::1" so that the node pushes a SRH with SID list <S1, C1,
         A2::1, D::1> with SL=3.  The node updates DA to service
         function S1 which the SL indicates and forward the packet.

         Second case is that the access point function directly
         indicates the path beyond the L2-anchor, service function S2
         and L3-anchor "A3::1" for example, the SID list shoud be <S1,
         C1, A2::, S2, A3::1, D::1> with SL=5.

   Layer-2 Anchor:

         It is assumed that the packet successfully traversed S1 and C1
         segments so that the SL was decremented 3 to 1 in the first
         scenario, and 5 to 3 in the second scenario before arriving the
         node of "A2::1" or "A2::" segment.

         In the first scenario that the L2-anchor node of "A2::1"
         segment is bound to a service policy which indicates path via
         service function S2 and L3-anchor function A3::1, the node does
         End.B6 process for the receiving packet to push a new SRH with
         SID list <S2, A3::1> with SL=1.  The node updates DA to next
         service function SID S2 which the SL indicates and forward the
         packet.

         In the second scenario that one SRH with SIDs <S1, C1, A2::,
         S2, A3::1, D::1>, the L2-anchor node of "A2::" segment is bound
         to just End function.  The node does End process for the
         receiving packet according to the SRH that decrements SL to 2,
         updates DA to next service function SID S2 which the SL
         indicates and forward the packet.

   Layer-3 Anchor:

         The L3-anchor node of "A3::1" segment does End.T process for
         the receiving packet according to the SRH(s).

         In the first scenario that outer SRH with SIDs <S2, A3::1>, it
         is assumed that the SL is decremented to 0 at service function
         S2 so that the node pops outer SRH.  Then the node processes
         second SRH with SIDs <S1, C1, A2::1, D::1> that decrements SL



Matsushima, et al.        Expires June 3, 2018                 [Page 12]


Internet-Draft             SRv6-mobile-uplane              November 2017


         to 0, updates DA to D::1 which the SL indicates and lookup IPv6
         table associated with "A3::1".  In this case, the decremented
         SL is 0 so that the node does PSP operation of popped out the
         SRH from the packet and forward it.

         In 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 the receiving packet according 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 the L3-anchor node receives a packet destine to "S::1"
         from a mobile node "D::1", it does T.Insert process for the
         receiving packets.

         First scenario is that the service policy for "S::1" is via
         service function S2 before reach to L2-anchor "A2::2" so that
         the node pushes a SRH with SID list <S2, A2::2, S::1> with
         SL=2.  The node updates DA to service function S2 which the SL
         indicates and forward the packet.

         Second scenario is that the L3-anchor function directly
         indicates the path beyond the L2-anchor, service function S1,
         node C3 and access point "A1::" for example, the SID list shoud
         be <S2, A2::, S1, C1, A1::1, D::1> with SL=5.

   Layer-2 Anchor:

         It is assumed that the packet successfully traversed S2 segment
         so that the SL was decremented 2 to 1 in the former case, and 5
         to 4 in the latter case before arriving the node of "A2::2" or
         "A2::" segment.

         In the first scenario that the L2-anchor node of "A2::2"
         segment is bound to a service policy which indicates path via
         node C1, service function S1 and access point function A1::,
         the node does End.B6 process for the receiving packet to push a
         new SRH with SID list <C1, S1, A1::1> with SL=1.  The node
         updates DA to next service function SID C1 which the SL
         indicates and forward the packet.





Matsushima, et al.        Expires June 3, 2018                 [Page 13]


Internet-Draft             SRv6-mobile-uplane              November 2017


         In the second scenario that one SRH with SIDs <S1, C1, A2::,
         S2, A3::1, D::1>, the L2-anchor node of "A2::" segment is bound
         to just End function.  The node does End process for the
         receiving packet according to the SRH that decrements SL to 2,
         updates DA to next node C1 which the SL indicates and forward
         the packet.

   Access Point:

         The access point node of "A1::1" segment does End process for
         the receiving packet according to the SRH(s).

         In the first scenario that outer SRH with SIDs <C1, S1, A1::1>,
         it is assumed that the SL is decremented 2 to 0 at node C1 and
         service function S1 so that the outer SRH is popped out by PSP
         at S1.  Thus the node processes second SRH with SIDs <S2,
         A2::2, S::1> that decrements SL to 0, updates DA to S::1 which
         the SL indicates and forward the packet to the mobile node
         through radio channel associated with "S::1".  In this case,
         the decremented SL is 0 so that the node does PSP operation of
         popped out the SRH from the packet and forward it.

         In the second scenario that one SRH with SIDs <S2, A2::, C1,
         S1, A1::1, S::1>, access node of "A1::1" segment does End
         process for the receiving packet according to the SRH.  Rest
         part of processes are as same as previous case.

6.3.  Stateless Interworking with Legacy Access Network

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

   As some types of interworking scenarios could be considered, we will
   describe other cases in the future versions of this document.

6.3.1.  Uplink: Lagacy Access to SRv6

   Legacy Access Point:

         When a legacy access point node receives a packet destined to
         "D::1" from a mobile node "S::1" through associated radio
         channel, it does tunnel encapsulation with the tunneling
         parameters, IPv4 DA, SA and tunnel header with ID, and sends
         out the packet to the network.

   Stateless Interworking:



Matsushima, et al.        Expires June 3, 2018                 [Page 14]


Internet-Draft             SRv6-mobile-uplane              November 2017


         The stateless interworking node of corresponding to the IPv4 DA
         does T.Tmap process for the receiving packet to pop the tunnel
         headers and push a SRH to the packet.  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 the
         packet.  SA of the packet must be kept as "S::1".

   Layer-2 or Layer-3 Anchor:

         The receiving node of 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 of B1 to an L2-anchor node, the L2-anchor node does
         End.B6 process for the receiving packet as same as previous
         section.

         In case of B1 to an L3-anchor node, the L3-anchor node does
         End.T process for the receiving packet as same as previous
         section.

6.3.2.  Downlink: SRv6 to Legacy Access

   Layer-2 or Layer-3 Anchor:

         In case of an L3-anchor node receives a packet destine to S::1
         from the correspondent node "D::1", and stateless interworking
         SID is bound to the next segment of S::1 , the L3-anchor node
         does T.Insert process for the receiving packet to push a SRH
         with SID list <B2::, S::1> with SL=1, where "B2" which encodes
         IW-IPv6-Prefix, tunnel IPv4 DA, SA and TUN-ID in it as Figure 3
         defined.  The L3-anchor node updates DA to "B2" and forward the
         packet.

         In case of an L2-anchor node receives a packet destine to SID
         "A2::B2" and the SID is bound to "B2", the L2-anchor node does
         End.B6 process for the receiving packet as same as previous
         section.  The node updates DA to B2 and forward the packet.

   Stateless Interworking:

         The stateless interworking node of "B2" End.TM process for the
         receiving packet according to the SRH.  The node decrement SL
         to 0, updates DA to "D::1" which the SL indicates, push IPv4
         and tunnel headers with IPv4 DA, SA and TUN-ID extracted from
         "B2", and forward the packet to the legacy network.




Matsushima, et al.        Expires June 3, 2018                 [Page 15]


Internet-Draft             SRv6-mobile-uplane              November 2017


         In this use case, decremented SL is 0 so that the node does PSP
         operation of popped out the SRH from the packet and forward it.

   Legacy Access Point:

         The legacy access point node of the IPv4 DA does tunnel
         termination process for the receiving packet according to the
         tunnel header.  The node pop the IPv4 and tunnel header and
         forward the packet to the mobile node through radio channel
         associated with the tunnel.

7.  Network Slicing Considerations

   Mobile network may be required to create a network slicing that
   represent a set of network resources and isolate those resource from
   other slices.  User-plane functions represented as SRv6 segments
   would be part of a slice.

   To represent a set of user-plane function segments for a slice,
   sharing same prefix through those SIDs within the slice could be a
   straightforward way.  SIDs in a network slice may include other type
   of functions in addition 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 the IETF and other
   standardization bodies, what functionalities are required for network
   slicing in mobile user-plane is further study item and to be
   discussed.

8.  Control Plane Considerations

8.1.  Existing Control Plane

   A mobile control-plane entity may allocate SIDs to the node of
   corresponding user-plane function.  In this case, the control-plane
   entity must signal allocated SIDs to other side of entity.

   If the control-plane entity needs to employ existing mobile control-
   plane protocol to signal, GTP-C or PMIP for example, it must require
   not to impact the control-plane protocols.  In this case, tunnel
   endpoint IPv6 address field in the control-plane message can be used
   to signal a SID.

   The basic mode described in Section 6.1 should be adopted.  In the
   basic mode, SID indicates unique session so that tunnel identifier is
   not required to SRv6 user-plane.  But the mobile control-plane may be
   assumed that one user-plane entity has one IPv6 address and it



Matsushima, et al.        Expires June 3, 2018                 [Page 16]


Internet-Draft             SRv6-mobile-uplane              November 2017


   allocates tunnel identifier per session.  In this case, SRv6 node of
   user-plane can form SID with the IPv6 address and the tunnel
   identifier.

   When an IPv6 prefix "A::/64" is allocated to an user-plane, and the
   control-plane allocate one 32bits tunnel identifier of "0x12345678"
   for a mobile session, the user-plane node forms a 128bits SID
   "A::1234:5678".

   In this way, there is no impact 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, SRv6 policy
   associated to the SID should be configured 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 to fulfil the policy.

   In case of a mobile control-plane is aware those policies and is
   capable to advertise them, 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 of the
   control-plane.  In this case, the user-plane entity should inform
   allocated SIDs back to the control-plane entity.

   If the control- and user-plane entities need to employ existing user-
   plane control protocol in between, such as PFCP for example, it 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 a centralized controller interfaces to mobile control-planes is
   capable to allocate SIDs to the controlling SRv6 nodes, the mobile
   control-planes just need to indicate nodes and their user-plane
   functions to the controller.  In this case, the controller must
   allocate appropriate SIDs for the user-plane functions to the SRv6
   nodes.  The controller must configure allocated SIDs to the nodes.



Matsushima, et al.        Expires June 3, 2018                 [Page 17]


Internet-Draft             SRv6-mobile-uplane              November 2017


   To indicate nodes and their user-plane functions from mobile control-
   plane to user-plane, the centralized controller could take advantage
   of [I-D.ietf-dmm-fpc-cpdp].  It provides interface to the control-
   plane to manage the user-plane of mobile networks.  To build
   centralized controller for mobile user-plane is out of scope of this
   document.

8.5.  Stateless Interworking

   A mobile control-plane is not required to configure statless
   interworking 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 to allocate
   tunnel endpoint IPv4 addresses from that address space for mobile
   sessions which is usual operation for it and no difference from
   legacy system.

9.  Security Considerations

   TBD

10.  IANA Considerations

   This document has no actions for IANA.

11.  Acknowledgements

   TBD

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 (work in progress),
              October 2017.



Matsushima, et al.        Expires June 3, 2018                 [Page 18]


Internet-Draft             SRv6-mobile-uplane              November 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 (work
              in progress), October 2017.

   [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.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.29281]
              3GPP, , "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 10.3.0,
              September 2011.

Authors' Addresses

   Satoru Matsushima
   SoftBank
   Tokyo
   Japan

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


   Clarence Filsfils
   Cisco Systems, Inc.
   Belgium

   Email: cf@cisco.com







Matsushima, et al.        Expires June 3, 2018                 [Page 19]


Internet-Draft             SRv6-mobile-uplane              November 2017


   Miya Kohno
   Cisco Systems, Inc.
   Japan

   Email: mkohno@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





























Matsushima, et al.        Expires June 3, 2018                 [Page 20]


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