draft-ietf-dmm-srv6-mobile-uplane-15.txt   draft-ietf-dmm-srv6-mobile-uplane-16.txt 
DMM Working Group S. Matsushima, Ed. DMM Working Group S. Matsushima, Ed.
Internet-Draft SoftBank Internet-Draft SoftBank
Intended status: Standards Track C. Filsfils Intended status: Standards Track C. Filsfils
Expires: 28 January 2022 M. Kohno Expires: 12 February 2022 M. Kohno
P. Camarillo, Ed. P. Camarillo, Ed.
Cisco Systems, Inc. Cisco Systems, Inc.
D. Voyer D. Voyer
Bell Canada Bell Canada
C.E. Perkins C.E. Perkins
Lupin Lodge Lupin Lodge
27 July 2021 11 August 2021
Segment Routing IPv6 for Mobile User Plane Segment Routing IPv6 for Mobile User Plane
draft-ietf-dmm-srv6-mobile-uplane-15 draft-ietf-dmm-srv6-mobile-uplane-16
Abstract Abstract
This document shows the applicability of SRv6 (Segment Routing IPv6) This document shows the applicability of SRv6 (Segment Routing IPv6)
to the user-plane of mobile networks. The network programming nature to the user-plane of mobile networks. The network programming nature
of SRv6 accomplishes mobile user-plane functions in a simple manner. of SRv6 accomplishes mobile user-plane functions in a simple manner.
The statelessness of SRv6 and its ability to control both service The statelessness of SRv6 and its ability to control both service
layer path and underlying transport can be beneficial to the mobile layer path and underlying transport can be beneficial to the mobile
user-plane, providing flexibility, end-to-end network slicing, and user-plane, providing flexibility, end-to-end network slicing, and
SLA control for various applications. This document describes the SLA control for various applications. This document describes the
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 January 2022. This Internet-Draft will expire on 12 February 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 40 skipping to change at page 2, line 40
5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 11 5.2.3. Scalability . . . . . . . . . . . . . . . . . . . . . 11
5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 12 5.3. Enhanced mode with unchanged gNB GTP behavior . . . . . . 12
5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12 5.3.1. Interworking with IPv6 GTP . . . . . . . . . . . . . 12
5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15 5.3.2. Interworking with IPv4 GTP . . . . . . . . . . . . . 15
5.3.3. Extensions to the interworking mechanisms . . . . . . 17 5.3.3. Extensions to the interworking mechanisms . . . . . . 17
5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17 5.4. SRv6 Drop-in Interworking . . . . . . . . . . . . . . . . 17
6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19 6. SRv6 Segment Endpoint Mobility Behaviors . . . . . . . . . . 19
6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19 6.1. Args.Mob.Session . . . . . . . . . . . . . . . . . . . . 19
6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. End.MAP . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20 6.3. End.M.GTP6.D . . . . . . . . . . . . . . . . . . . . . . 20
6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 21 6.4. End.M.GTP6.D.Di . . . . . . . . . . . . . . . . . . . . . 22
6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 22 6.5. End.M.GTP6.E . . . . . . . . . . . . . . . . . . . . . . 23
6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 23 6.6. End.M.GTP4.E . . . . . . . . . . . . . . . . . . . . . . 24
6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 25 6.7. H.M.GTP4.D . . . . . . . . . . . . . . . . . . . . . . . 25
6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26 6.8. End.Limit: Rate Limiting behavior . . . . . . . . . . . . 26
7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 26 7. SRv6 supported 3GPP PDU session types . . . . . . . . . . . . 26
8. Network Slicing Considerations . . . . . . . . . . . . . . . 26 8. Network Slicing Considerations . . . . . . . . . . . . . . . 26
9. Control Plane Considerations . . . . . . . . . . . . . . . . 27 9. Control Plane Considerations . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 28
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
skipping to change at page 11, line 19 skipping to change at page 11, line 19
End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing End.DT4/End.DT6/End.DT2U which performs the decapsulation (removing
the IPv6 header with all its extension headers) and forwards toward the IPv6 header with all its extension headers) and forwards toward
the data network. the data network.
5.2.2. Packet flow - Downlink 5.2.2. Packet flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF1_in : (Z,A) ->UPF1 maps the flow w/ UPF1_in : (Z,A) ->UPF1 maps the flow w/
SID list <C1,S1, gNB> SID list <C1,S1, gNB>
UPF1_out: (U1::1, C1)(gNB, S1; SL=2)(Z,A) ->H.Encaps.Red UPF1_out: (U1::1, C1)(gNB::1, S1; SL=2)(Z,A)->H.Encaps.Red
C1_out : (U1::1, S1)(gNB, S1; SL=1)(Z,A) C1_out : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A)
S1_out : (U1::1, gNB)(Z,A) ->End with PSP S1_out : (U1::1, gNB::1)(Z,A) ->End with PSP
gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2 gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2
When the packet arrives at the UPF1, the UPF1 maps that particular When the packet arrives at the UPF1, the UPF1 maps that particular
flow into a UE PDU Session. This UE PDU Session is associated with flow into a UE PDU Session. This UE PDU Session is associated with
the policy <C1, S1, gNB>. The UPF1 performs a H.Encaps.Red the policy <C1, S1, gNB>. The UPF1 performs a H.Encaps.Red
operation, encapsulating the packet into a new IPv6 header with its operation, encapsulating the packet into a new IPv6 header with its
corresponding SRH. corresponding SRH.
The nodes C1 and S1 perform their related Endpoint processing. The nodes C1 and S1 perform their related Endpoint processing.
Once the packet arrives at the gNB, the IPv6 DA corresponds to an Once the packet arrives at the gNB, the IPv6 DA corresponds to an
End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the End.DX4, End.DX6 or End.DX2 behavior at the gNB (depending on the
underlying traffic). The gNB decapsulates the packet, removing the underlying traffic). The gNB decapsulates the packet, removing the
IPv6 header and forwards the traffic toward the UE. IPv6 header, and forwards the traffic towards the UE. The SID gNB::1
is one example of a SID associated to this service.
Note that there are several means to provide the UE session Note that there are several means to provide the UE session
aggregation. The decision on which one to use is a local decision aggregation. The decision on which one to use is a local decision
made by the operator. One option is to use the Args.Mob.Session made by the operator. One option is to use the Args.Mob.Session
(Section 6.1). Another option comprises the gNB performing an IP (Section 6.1). Another option comprises the gNB performing an IP
lookup on the inner packet by using the End.DT4, End.DT6, and End.DT2 lookup on the inner packet by using the End.DT4, End.DT6, and End.DT2
behaviors. behaviors.
5.2.3. Scalability 5.2.3. Scalability
skipping to change at page 12, line 40 skipping to change at page 12, line 40
5.3.1. Interworking with IPv6 GTP 5.3.1. Interworking with IPv6 GTP
In this interworking mode the gNB at the N3 interface uses GTP over In this interworking mode the gNB at the N3 interface uses GTP over
IPv6. IPv6.
Key points: Key points:
* The gNB is unchanged (control-plane or user-plane) and * The gNB is unchanged (control-plane or user-plane) and
encapsulates into GTP (N3 interface is not modified). encapsulates into GTP (N3 interface is not modified).
* The 5G Control-Plane towards the gNB (N2 interface) is unmodified; * The 5G Control-Plane towards the gNB (N2 interface) is unmodified;
one IPv6 address is needed (i.e. a BSID at the SRGW). The SRv6 one IPv6 address is needed per SLA(i.e. a BSID at the SRGW). The
SID is different depending on the required SLA. SRv6 SID is different depending on the required SLA.
* In the uplink, the SRGW removes GTP, finds the SID list related to * In the uplink, the SRGW removes GTP, finds the SID list related to
the IPv6 DA, and adds SRH with the SID list. the IPv6 DA, and adds SRH with the SID list.
* There is no state for the downlink at the SRGW. * There is no state for the downlink at the SRGW.
* There is simple state in the uplink at the SRGW; using Enhanced * There is simple state in the uplink at the SRGW; using Enhanced
mode results in fewer SR policies on this node. An SR policy is mode results in fewer SR policies on this node. An SR policy is
shared across UEs as long as they belong to the same context shared across UEs as long as they belong to the same context
(i.e., tenant). A set of many different policies (i.e., different (i.e., tenant). A set of many different policies (i.e., different
SLAs) increases the amount of state required. SLAs) increases the amount of state required.
* When a packet from the UE leaves the gNB, it is SR-routed. This * When a packet from the UE leaves the gNB, it is SR-routed. This
simplifies network slicing [I-D.ietf-lsr-flex-algo]. simplifies network slicing [I-D.ietf-lsr-flex-algo].
skipping to change at page 15, line 25 skipping to change at page 15, line 25
5.3.2. Interworking with IPv4 GTP 5.3.2. Interworking with IPv4 GTP
In this interworking mode the gNB uses GTP over IPv4 in the N3 In this interworking mode the gNB uses GTP over IPv4 in the N3
interface interface
Key points: Key points:
* The gNB is unchanged and encapsulates packets into GTP (the N3 * The gNB is unchanged and encapsulates packets into GTP (the N3
interface is not modified). interface is not modified).
* In the uplink, traffic is classified by SRGW's Uplink Classifier * In the uplink, traffic is classified by SRGW's classification
and steered into an SR policy. The SRGW is a UPF1 functionality engine and steered into an SR policy. The SRGW may be implemented
and can coexist with UPF1's Uplink Classifier functionality. in a UPF or as a separate entity.
* SRGW removes GTP, finds the SID list related to DA, and adds an * SRGW removes GTP, finds the SID list related to DA, and adds an
SRH with the SID list. SRH with the SID list.
An example topology is shown in Figure 6. In this mode the gNB is an An example topology is shown in Figure 6. In this mode the gNB is an
unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before,
the SRGW maps the IPv4/GTP traffic to SRv6. the SRGW maps the IPv4/GTP traffic to SRv6.
S1 and C1 are two service segment endpoints. S1 represents a VNF in S1 and C1 are two service segment endpoints. S1 represents a VNF in
the network, and C1 represents a router configured for Traffic the network, and C1 represents a router configured for Traffic
Engineering. Engineering.
skipping to change at page 16, line 21 skipping to change at page 16, line 21
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z) S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1) (A,Z) -> PSP C1_out : (SRGW, U2::1) (A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6 UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z toward the gNB on a specific The UE sends a packet destined to Z toward the gNB on a specific
bearer for that session. The gNB, which is unmodified, encapsulates bearer for that session. The gNB, which is unmodified, encapsulates
the packet into a new IPv4, UDP, and GTP headers. The IPv4 DA, B, the packet into a new IPv4, UDP, and GTP headers. The IPv4 DA, B,
and the GTP TEID are the ones received at the N2 interface. and the GTP TEID are the ones received at the N2 interface.
When the packet arrives at the SRGW for UPF1, the SRGW has an Uplink When the packet arrives at the SRGW for UPF1, the SRGW has an
Classifier rule for incoming traffic from the gNB, that steers the classification engine rule for incoming traffic from the gNB, that
traffic into an SR policy by using the function H.M.GTP4.D. The SRGW steers the traffic into an SR policy by using the function
removes the IPv4, UDP, and GTP headers and pushes an IPv6 header with H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP headers and
its own SRH containing the SIDs related to the SR policy associated pushes an IPv6 header with its own SRH containing the SIDs related to
with this traffic. The SRGW forwards according to the new IPv6 DA. the SR policy associated with this traffic. The SRGW forwards
according to the new IPv6 DA.
S1 and C1 perform their related Endpoint functionality and forward S1 and C1 perform their related Endpoint functionality and forward
the packet. the packet.
When the packet arrives at UPF2, the active segment is (U2::1) which When the packet arrives at UPF2, the active segment is (U2::1) which
is bound to End.DT4/6 which performs the decapsulation (removing the is bound to End.DT4/6 which performs the decapsulation (removing the
outer IPv6 header with all its extension headers) and forwards toward outer IPv6 header with all its extension headers) and forwards toward
the data network. the data network.
Note that the interworking mechanisms for IPv4/GTP and IPv6/GTP
differs. This is due to the fact that in IPv6/GTP we can leverage
the remote steering capabilities provided by SRv6. In IPv4 this is
not the case, and it would require a significant address consumption.
5.3.2.2. Packet flow - Downlink 5.3.2.2. Packet flow - Downlink
The downlink packet flow is as follows: The downlink packet flow is as follows:
UPF2_in : (Z,A) -> UPF2 maps flow with SID UPF2_in : (Z,A) -> UPF2 maps flow with SID
<C1, S1,GW::SA:DA:TEID> <C1, S1,GW::SA:DA:TEID>
UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red
C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A) C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A)
S1_out : (U2::1, GW::SA:DA:TEID)(Z,A) S1_out : (U2::1, GW::SA:DA:TEID)(Z,A)
SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E
skipping to change at page 17, line 27 skipping to change at page 17, line 32
and forwards it on the bearer. This gNB behavior is not modified and forwards it on the bearer. This gNB behavior is not modified
from current and previous generations. from current and previous generations.
5.3.2.3. Scalability 5.3.2.3. Scalability
For the downlink traffic, the SRGW is stateless. All the state is in For the downlink traffic, the SRGW is stateless. All the state is in
the SRH pushed by the UPF2. The UPF must have this UE-base state the SRH pushed by the UPF2. The UPF must have this UE-base state
anyway (since it is its anchor point). anyway (since it is its anchor point).
For the uplink traffic, the state at the SRGW is dedicated on a per For the uplink traffic, the state at the SRGW is dedicated on a per
UE/session basis according to an Uplink Classifier. There is state UE/session basis according to a classification engine. There is
for steering the different sessions in the form of an SR Policy. state for steering the different sessions in the form of an SR
However, SR policies are shared among several UE/sessions. Policy. However, SR policies are shared among several UE/sessions.
5.3.3. Extensions to the interworking mechanisms 5.3.3. Extensions to the interworking mechanisms
In this section we presented two mechanisms for interworking with In this section we presented two mechanisms for interworking with
gNBs and UPFs that do not support SRv6. These mechanisms are used to gNBs and UPFs that do not support SRv6. These mechanisms are used to
support GTP over IPv4 and IPv6. support GTP over IPv4 and IPv6.
Even though we have presented these methods as an extension to the Even though we have presented these methods as an extension to the
"Enhanced mode", it is straightforward in its applicability to the "Enhanced mode", it is straightforward in its applicability to the
"Traditional mode". "Traditional mode".
 End of changes. 12 change blocks. 
25 lines changed or deleted 32 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/