[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03
DMM Working Group M. Kohno
Internet-Draft F. Clad
Intended status: Informational P. Camarillo
Expires: May 6, 2021 Z. Ali
Cisco Systems, Inc.
November 2, 2020
Architecture Discussion on SRv6 Mobile User plane
draft-kohno-dmm-srv6mob-arch-03
Abstract
This document discusses a solution approach and its architectural
benefits of common data plane across domains and across overlay/
underlay.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Kohno, et al. Expires May 6, 2021 [Page 1]
Internet-Draft SRv6mob-arch November 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Problem Definition . . . . . . . . . . . . . . . . . . . . . 2
3. Common data plane across domains and across overlay/underlay 3
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
5. SRv6 mobile user plane and the 5G use cases . . . . . . . . . 4
5.1. Network Slicing . . . . . . . . . . . . . . . . . . . . . 4
5.2. Edge Computing . . . . . . . . . . . . . . . . . . . . . 5
5.3. URLLC (Ultra-Reliable Low-Latency Communication) support 6
6. Control Plane Considerations . . . . . . . . . . . . . . . . 7
7. Incremental Deployment . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
Mobile architectures have evolved individually, and the user plane,
GTP-U, has been defined as an overlay tunnel that is agnostic to the
IP infrastructure.
However, it will not be able to efficiently meet the diverse SLA
requirements of the 5G era. Also, it will not be able to meet the
demands of new mobile first and/or data intensive applications.
This document discusses a solution approach and its architectural
benefits of common data plane across domains (e.g., mobile including
UE, IP transport, data center, applications) and across overlay/
underlay.
This approach is in a sense contrary to proposals that the underlying
transport can be anything (L2, IPv4, IPv6, MPLS, SR, SRv6). But it
is an approach to make the network as flat as possible, making it
suitable for the distributed mobile deployment model.
2. Problem Definition
The current mobile user plane, GTP-U, defined as an overlay tunnel
that is agnostic to the IP infrastructure, has the following
limitations that prevent it from supporting new application demands.
o Non-optimal for any-to-any communication
o lack a way to map to the underlay
Kohno, et al. Expires May 6, 2021 [Page 2]
Internet-Draft SRv6mob-arch November 2020
o Non-optimal for edge/distributed computing
o Lack a way for application developers to manipulate
In addition, the centralized tunnel terminating gateway becomes a
scaling bottleneck and a single point of failure
For IP and data center networking, tunnel sessions can be eliminated
when necessary and if possible (e.g. PPPoE -> IPoE, VXLAN/GENEVE/NSH
-> SRv6), but such an architectural change used to be difficult for
mobile domain.
3. Common data plane across domains and across overlay/underlay
[I-D.ietf-dmm-srv6-mobile-uplane] defines SRv6 mobile user plane as
an alternative or co-existing solution to GTP-U.
Since SRv6 is a native IPv6 data plane, it can be a common data plane
regardless of the domain.
SRv6 Network Programming [I-D.ietf-spring-srv6-network-programming]
enables the creation of overlays with underlay optimization. In
addition, SRv6 can be operated by application developers because of
its implementation in the computing stack, e.g. VPP, Linux Kernel,
smart NIC.
Data plane commonality offers significant advantage regarding
function, scaling, and cost. In particular, the benefits of the 5G
era are shown in Section 5.
Note that the interaction with underlay infrastructure is not a
mandatory in the data plane commonality. It just gives a design
option to interact with the underlay and optimize it, and it is
totally fine to keep ovelray underlay-agnostic.
4. Terminology
The terminology used in this document leverages and conforms to
[I-D.ietf-dmm-srv6-mobile-uplane].
Kohno, et al. Expires May 6, 2021 [Page 3]
Internet-Draft SRv6mob-arch November 2020
+-----+
| AMF |
+-----+
/ | [N11]
[N2] / +-----+
+------/ | SMF |
/ +-----+
/ / \
/ / \ [N4]
/ / \ ________
/ / \ / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ TN +------+ TN +------+ \________/
|
_______
/ \
/ Local \
\ DN /
\_______/
Figure 1: Reference Architecture
- UE : User Equipment
- gNB : gNodeB
- UPF : User Plane Function
- SMF : Session Management Function
- AMF : Access and Mobility Management Function
- 3GPP data plane entities : 3GPP entities responsible for data plane
forwarding, i.e. gNB and UPF
- TN : Transport Network - IP network where 3GPP data plane entities
connected
- DN : Data Network e.g. operator services, Internet access
- CUPS : Control Plane and User Plane Separation
- VNF : Virtual Network Function
- CNF : Cloud native Network Function
5. SRv6 mobile user plane and the 5G use cases
This section describes the advantages of the common data plane and of
applying SRv6 mobile user plane for 5G use cases.
5.1. Network Slicing
Network slicing enables network segmentation, isolation, and SLA
differentiation in terms of latency and availability. End-to-end
Kohno, et al. Expires May 6, 2021 [Page 4]
Internet-Draft SRv6mob-arch November 2020
slicing will be achieved by mapping and coordinating IP network
slicing, RAN and mobile packet core slicing.
However, as pointed out in [I-D.clt-dmm-tn-aware-mobility], the 5G
System as defined, does not have underlying IP network awareness,
which could lead to the inability in meeting SLAs.
Segment Routing has a comprehensive set of slice engineering
technologies. How to build network slicing using the Segment Routing
based technology is described in
[I-D.ali-spring-network-slicing-building-blocks].
In the typical GTP-U over IP/MPLS/SR configuration, 3GPP data plane
entity such as UPF is a CE to the transport networks PE. But if 3GPP
they support SRv6 mobile user plane, they can directly participate in
network slicing, and efficiently solves the following issues.
o A certain Extra ID such as VLAN-ID is needed for segregating
traffic and mapping it onto a designated slice.
o PE and the PE-CE connection is a single point of failure, so some
form of PE redundancy (using routing protocols, MC-LAG, etc.) is
required.
And In some deployment scenarios, it may be better to have a
transport network PE present. For such a case, the stateless slice
identifier encoding [I-D.filsfils-spring-srv6-stateless-slice-id] can
be applicable to enable per-slice forwarding policy using the IPv6
header.
5.2. Edge Computing
Edge computing, where the computing workload is placed closer to
users, is recognized as one of the key pillars to meet 5G's demanding
key performance indicators (KPIs), especially with regard to low
latency and bandwidth efficiency. The computing workload includes
network services, security, analytics, content cache and various
applications. (UPF can also be viewed as a distributed network
service function.)
Edge computing is more important than ever. This is because no
matter how much 5G improves access speeds, it won't improve end-to-
end throughput because it's largely bound to round trip delay.
However, the current MEC discussion [ETSI-MEC] focuses on how to
properly select the UPF of adequate proximity, and not on how to
interact with applications.
Kohno, et al. Expires May 6, 2021 [Page 5]
Internet-Draft SRv6mob-arch November 2020
SRv6 has an advantage in enabling edge computing for the following
reasons.
o Programmable and Flexible Traffic Steering : SRv6's flexible
traffic steering capabilities and the network programming concept
is suitable for flexible placement of computing workload.
o Common data plane across domains : SRv6/IPv6 can be a common data
plane regardless of the domains such as mobile including UE, IP
transport, data center, applications.
o Stateless Service Chaining : It does not require any per-flow
state in network fabric.
o Interaction with Applications : SRv6 can be implemented in the
compute stack and can be manipulated by applications using socket
API. Also, SRv6 can carry meta data, which can be used for
interacting with applications.
o Functionality without performance degradation : Various
information can be exposed in IP header, but it does not degrade
performance thanks to the longest match mechanism in the IP
routing. Only who needs the information for granular processing
are to lookup.
It is even more beneficial if service functions/applications directly
support SRv6.
5.3. URLLC (Ultra-Reliable Low-Latency Communication) support
3GPP [TR.23725] investigates the key issues for meeting the URLLC
requirements on latency, jitter and reliability in the 5G System.
The solutions provided in the document are focused at improving the
overlay protocol (GTP-U) and limits to provide a few hints into how
to map such tight-SLA into the transport network. These hints are
based on static configuration or static mapping for steering the
overlay packet into the right transport SLA. Such solutions do not
scale and hinder network economics.
Some of the issues can be solved more simply without GTP-U tunnel.
SRv6 mobile user plane can exposes session and QoS flow information
in IP header as discussed in the previous section. This would make
routing and forwarding path optimized for URLLC, much simpler than
the case with GTP-U tunnel.
Another issue that deserves special mention is the ultra-reliability
issue. In 3GPP, in order to support ultra-reliability, redundant
user planes paths based on dual connectivity has been proposed. The
proposal has two main options.
o Dual Connectivity based end-to-end Redundant User Plane Paths
o Support of redundant transmission on N3/N9 interfaces
Kohno, et al. Expires May 6, 2021 [Page 6]
Internet-Draft SRv6mob-arch November 2020
In the case of the former, UE and hosts have RHF(Redundancy Handling
Function). In sending, RFH is to replicate the traffic onto two
GTP-U tunnels, and in receiving, RHF is to merge the traffic.
In the case of the latter, the 3GPP data plane entities are to
replicate and merge the packets with the same sequence for specific
QoS flow, which requires further enhancements.
SRv6 mobile user plane has some advantages for URLLC traffic. First,
it can be used to enforce a low-latency path in the network by means
of scalable Traffic Engineering. Additionally, SRv6 provides an
automated reliability protection mechanism known as TI-LFA, which is
a sub-50ms FRR mechanism that provides protection regardless of the
topology through the optimal backup path. It can be provisioned
slice-aware.
With the case that dual live-live path is required, the problem is
not only the complexity but that the replication point and the
merging point would be the single point of failure. The SRv6 mobile
user plane also has an advantage in this respect, because any
endpoints or 3GPP data plane nodes themselves can be the replication/
merging point when they are SRv6 aware.
Furthermore, SRv6 supports inband telemetry/time stamping for latency
monitoring and control.
6. Control Plane Considerations
This draft focuses on commonalization of data plane, and control
plane is out of scope for now. Having said that, IGP and BGP
extension for SRv6 can be used as the control plane as they are.
As for the mobility management, BGP based Loc/ID mapping would be
straightforward to implement. Or even pure ID based anchorless
protocol such as hICN [I-D.auge-dmm-hicn-mobility] can be used.
The co-existence with the 3GPP control plane is for further study.
7. Incremental Deployment
Although it may seem difficult to migrate from the current mobile
architecture, the conversion between GTP-U and SRv6 has been defined
and can co-exist with the current mobile architecture as needed.
Since the conversion is done completely statelessly (i.e., all
necessary information is retained in the packet), there will not be a
scaling bottleneck or a single point of failure.
Kohno, et al. Expires May 6, 2021 [Page 7]
Internet-Draft SRv6mob-arch November 2020
With regard to the architectural migration, the insertion with no
modification to the existing 3GPP architecture is considered first,
and then the tighter integration of data plane is to be achieved. as
described in [I-D.auge-dmm-hicn-mobility-deployment-options].
8. Security Considerations
TBD
9. IANA Considerations
NA
10. Acknowledgements
Authors would like to thank Satoru Matsushima and Shunsuke Homma for
their insights and comments.
11. References
11.1. Normative References
[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-srv6-mobile-uplane]
Matsushima, S., Filsfils, C., Kohno, M., Camarillo, P.,
Voyer, D., and C. Perkins, "Segment Routing IPv6 for
Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-09
(work in progress), July 2020.
[I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018.
[I-D.ietf-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J., Voyer, D.,
Matsushima, S., and Z. Li, "SRv6 Network Programming",
draft-ietf-spring-srv6-network-programming-24 (work in
progress), October 2020.
Kohno, et al. Expires May 6, 2021 [Page 8]
Internet-Draft SRv6mob-arch November 2020
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
11.2. Informative References
[ETSI-MEC]
ETSI, "MEC in 5G Networks", ETSI White Paper No.28, June
2018.
[I-D.ali-spring-network-slicing-building-blocks]
Ali, Z., Filsfils, C., Camarillo, P., and D. Voyer,
"Building blocks for Slicing in Segment Routing Network",
draft-ali-spring-network-slicing-building-blocks-02 (work
in progress), November 2019.
[I-D.auge-dmm-hicn-mobility]
Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "Anchorless mobility through hICN", draft-auge-
dmm-hicn-mobility-04 (work in progress), July 2020.
[I-D.auge-dmm-hicn-mobility-deployment-options]
Auge, J., Carofiglio, G., Muscariello, L., and M.
Papalini, "Anchorless mobility management through hICN
(hICN-AMM): Deployment options", draft-auge-dmm-hicn-
mobility-deployment-options-04 (work in progress), July
2020.
[I-D.clt-dmm-tn-aware-mobility]
Chunduri, U., Li, R., Bhaskaran, S., Kaippallimalil, J.,
Tantsura, J., Contreras, L., and P. Muley, "Transport
Network aware Mobility for 5G", draft-clt-dmm-tn-aware-
mobility-07 (work in progress), September 2020.
[I-D.filsfils-spring-srv6-interop]
Filsfils, C., Clad, F., Camarillo, P., Abdelsalam, A.,
Salsano, S., Bonaventure, O., Horn, J., and J. Liste,
"SRv6 interoperability report", draft-filsfils-spring-
srv6-interop-02 (work in progress), March 2019.
Kohno, et al. Expires May 6, 2021 [Page 9]
Internet-Draft SRv6mob-arch November 2020
[I-D.filsfils-spring-srv6-stateless-slice-id]
Filsfils, C., Clad, F., Camarillo, P., and K. Raza,
"Stateless and Scalable Network Slice Identification for
SRv6", draft-filsfils-spring-srv6-stateless-slice-id-01
(work in progress), July 2020.
[I-D.guichard-spring-srv6-simplified-firewall]
Guichard, J., Filsfils, C., daniel.bernier@bell.ca, d.,
Li, Z., Clad, F., Camarillo, P., and A. Abdelsalam,
"Simplifying Firewall Rules with Network Programming and
SRH Metadata", draft-guichard-spring-srv6-simplified-
firewall-02 (work in progress), April 2020.
[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-14
(work in progress), September 2020.
[I-D.rokui-5g-transport-slice]
Rokui, R., Homma, S., Lopez, D., Foy, X., Contreras, L.,
Ordonez-Lucena, J., Martinez-Julia, P., Boucadair, M.,
Eardley, P., Makhijani, K., and H. Flinck, "5G Transport
Slice Connectivity Interface", draft-rokui-5g-transport-
slice-00 (work in progress), July 2019.
[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>.
[TR.23725]
3GPP, "Study on enhancement of Ultra-Reliable Low-Latency
Communication (URLLC) support in the 5G Core network
(5GC)", 3GPP TR 23.725 16.2.0, June 2019.
[TR.29892]
3GPP, "Study on User Plane Protocol in 5GC", 3GPP TR
29.892 16.1.0, April 2019.
[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.
Kohno, et al. Expires May 6, 2021 [Page 10]
Internet-Draft SRv6mob-arch November 2020
[TS.29281]
3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 15.1.0,
December 2017.
Authors' Addresses
Miya Kohno
Cisco Systems, Inc.
Japan
Email: mkohno@cisco.com
Francois Clad
Cisco Systems, Inc.
France
Email: fclad@cisco.com
Pablo Camarillo Garvia
Cisco Systems, Inc.
Spain
Email: pcamaril@cisco.com
Zafar Ali
Cisco Systems, Inc.
Canada
Email: zali@cisco.com
Kohno, et al. Expires May 6, 2021 [Page 11]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/