DMM Working Group M. Kohno
Internet-Draft F. Clad
Intended status: Informational P. Camarillo
Expires: September 9, 2020 Z. Ali
Cisco Systems, Inc.
March 8, 2020
Architecture Discussion on SRv6 Mobile User plane
draft-kohno-dmm-srv6mob-arch-01
Abstract
Layer separation is a powerful concept in system architecture. In
the area of mobility, by separating GTP-U that is the overlay tunnel,
and the IP transport network that is the underlay, the operation of
the mobile network and the transport network can be separated,
allowing them to evolve independently.
However, evolving individually at each layer promotes local
optimization and may result in non-optimal solutions overall in the
long run.
When a drastic architectural transition is required, for example, in
the 5G era where various SLAs and completely new data intensive
services are assumed, it is necessary to reconsider the architecture
holistically, not from the viewpoint of individual part.
One of important value propositions of SRv6 mobile user plane is to
create overlay with underlay optimization.
This document discusses the architecture implication of applying SRv6
mobile user plane. Then it takes 5G use cases as an example, and
describes how these use cases are simply and effectively realized.
Thus it shows that SRv6 mobile use plane is a right architectural
choice for 5G era.
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/.
Kohno, et al. Expires September 9, 2020 [Page 1]
Internet-Draft SRv6mob-arch March 2020
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 September 9, 2020.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Architecture Consideration and Necessity of Inter-layer
Optimization . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. SRv6 mobile user plane and the 5G use cases . . . . . . . . . 5
4.1. Network Slicing . . . . . . . . . . . . . . . . . . . . . 5
4.2. Edge Computing . . . . . . . . . . . . . . . . . . . . . 6
4.3. URLLC (Ultra-Reliable Low-Latency Communication) support 6
5. Incremental Deployment . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Layer separation is a powerful concept in system architecture. In
the area of mobility, by separating GTP-U that is the overlay tunnel,
and the IP transport network that is the underlay, the operation of
the mobile network and the transport network can be separated,
allowing them to evolve independently.
Kohno, et al. Expires September 9, 2020 [Page 2]
Internet-Draft SRv6mob-arch March 2020
However, evolving individually at each layer promotes local
optimization and may result in non-optimal solutions overall in the
long run.
The well-known aphorism of David J.Wheeler says:
"All problems in computer science can be solved by adding another
level of indirection."
But, as a corollary, it also says: "...that usually will create
another problem." In other words, excessive use of tunnels is not
good for an overall architecture.
Existing practices have reasonable grounds, so it is usually
recommended to follow them. But when a drastic architectural
transition is required, for example, in the 5G era where various SLAs
and completely new data intensive services are assumed, it is
necessary to reconsider the architecture holistically, rather than
from the viewpoint of individual part.
SRv6 mobile user plane has been proposed as an alternative way to
complement or replace GTP-U both in IETF
[I-D.ietf-dmm-srv6-mobile-uplane] and 3GPP [TR.29892]. In the 3GPP
CT4, the scope of the study was narrow (N9 only) and it was concluded
not to accept as a candidate protocol for the user plane in 5GC based
on Rel-16 stage 2 requirements. However, the future is still open
given the heterogeneous access evolution and stringent data
intensiveness.
SRv6 has also an advantage if it is used as a mobile user plane,
because of its flexibility through Service Programming functions and
the use of metadata, in addition to the simple and stateless traffic
steering capability.
The 3GPP data plane entities such as UPFs and service functions can
be implemented either as virtual or physical appliances. The fact
that SRv6 has been supported on various platforms including custom
ASICs, commercially available NPUs, programmable switches, Smart
NICs, Linux Kernel, virtual forwarders on server and container
networking, will make the deployment flexible.
Also, the declarative programming nature of SRv6 will provide the
necessary distinction to clarify basic reachability vs constraint
path vs service path, whereas existing practices depended on the
layer separation - service overlay and underlay. In other words, one
of the most important value propositions of SRv6 mobile user plane is
the possibility to perform cross-layer optimizations.
Kohno, et al. Expires September 9, 2020 [Page 3]
Internet-Draft SRv6mob-arch March 2020
This document discusses the architecture implication of applying SRv6
mobile user plane. Then it takes 5G use cases as an example, and
describes how these use cases are simply and effectively realized.
Thus it shows that SRv6 mobile use plane is a right architectural
choice for 5G era.
2. Architecture Consideration and Necessity of Inter-layer Optimization
Historically, Mobile and Transport Network have been designed,
standardized and operated separately. GTP-U has been defined as the
mobile user plane. This is an overlay tunnel that runs over the
Transport Network. Therefore, the underlying network cannot be
directly controlled.
5G requires variety of SLA characteristics and flexible traffic
steering towards various service functions. How to map the transport
slice to mobile end-to-end slice has been being discussed in multiple
WGs in IETF [I-D.rokui-5g-transport-slice],
[I-D.clt-dmm-tn-aware-mobility].
They are based on the current assumption that underlying network is
separated and agnostic. But it could be effective if the underlying
network can be more interactive.
The evolution of architecture requires a review of conventional
domain boundaries and practices. This way, inefficiencies caused by
traditional practices can be reduced. For example, now that "CUPS"
separated the Control Plane and User Plane, UPF, which is dedicated
to forwarding, can be considered as an entity on the IP Transport
Network.
And, as a matter of fact, layer reduction for efficiency has been
done in other domains. Some data centers adopted native IP CLOS,
avoiding using VXLAN for simplicity. Also broadband subscriber
managements were simplified by using IPoE instead of PPPoE / L2TP.
In the context of mobile operators, SRv6 provides end-to-end simpler
network operations thus decreasing the OPEX. SRv6 can also be
applied to the mobility overlay, in which case it also has benefits
as the tunnels are removed.
3. Terminology
The terminology used in this document leverages and conforms to
[I-D.ietf-dmm-srv6-mobile-uplane].
Kohno, et al. Expires September 9, 2020 [Page 4]
Internet-Draft SRv6mob-arch March 2020
+-----+
| AMF |
+-----+
/ | [N11]
[N2] / +-----+
+------/ | SMF |
/ +-----+
/ / \
/ / \ [N4]
/ / \ ________
/ / \ / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ TN +------+ TN +------+ \________/
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
4. SRv6 mobile user plane and the 5G use cases
4.1. Network Slicing
SRv6 network programming realizes network slicing. How to build
network slicing using the Segment Routing based technology is
described in [I-D.ali-spring-network-slicing-building-blocks]
Also, the stateless slice identifier
[I-D.filsfils-spring-srv6-stateless-slice-id] has been proposed to
enable per-slice forwarding policy and bandwidth manipulation.
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. This
results in the following facts:
Kohno, et al. Expires September 9, 2020 [Page 5]
Internet-Draft SRv6mob-arch March 2020
- A certain Extra ID such as VLAN-ID is needed for segregating
traffic and mapping it onto a designated slice.
- 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, which makes systems inefficient and complex.
Another possibility would be that 3GPP user plane entities are
deployed as VNF/CNF in a DC. In this case, slice in the DC network
and other networks are to be inter-connected via DCI.
In either case, it would improve the scalability, QoS and efficiency,
if the user plane entities directly support SRv6.
4.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.
SRv6's flexible traffic steering capabilities and the Network
Programming concept of freely describing Instructions and meta data
are per se suitable for providing Edge Computing.
In addition, since SRv6 can be a common data plane regardless of the
domains such as access, WAN, mobility and data center, Service
Placement and Service Chain that used to be concentrated in Data
Center can be expanded over a wide area.
Furthermore, with SRv6, session and QoS information can be exposed in
IP header. It does not affect performance, thanks to the longest
match mechanism in the IP routing. Only the services/applications
who need the information for granular processing are to lookup. This
also allows services/applications to be placed in between N9 paths if
needed.
The draft implementation of Firewall using SRv6 meta data is
discussed in [I-D.guichard-spring-srv6-simplified-firewall]
4.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
Kohno, et al. Expires September 9, 2020 [Page 6]
Internet-Draft SRv6mob-arch March 2020
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.
- Dual Connectivity based end-to-end Redundant User Plane Paths
- Support of redundant transmission on N3/N9 interfaces
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.
5. Incremental Deployment
Incremental deployment should be considered. In the case of hcin
mobility [I-D.auge-dmm-hicn-mobility-deployment-options], the
insertion with no modification to the existing 3GPP architecture is
considered first, and then the tighter integration of data plane is
Kohno, et al. Expires September 9, 2020 [Page 7]
Internet-Draft SRv6mob-arch March 2020
to be achieved. The same shall apply in the case of SRv6 mobile user
plane.
6. Security Considerations
TBD
7. IANA Considerations
NA
8. Acknowledgements
Authors would like to thank Satoru Matsushima and Shunsuke Homma for
their insights and comments.
9. References
9.1. Normative References
[I-D.filsfils-spring-srv6-network-programming]
Filsfils, C., Camarillo, P., Leddy, J.,
daniel.voyer@bell.ca, d., Matsushima, S., and Z. Li, "SRv6
Network Programming", draft-filsfils-spring-srv6-network-
programming-07 (work in progress), February 2019.
[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-07
(work in progress), November 2019.
[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.
[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>.
Kohno, et al. Expires September 9, 2020 [Page 8]
Internet-Draft SRv6mob-arch March 2020
[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>.
9.2. Informative References
[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-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-03 (work in progress), January
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-05 (work in progress), November 2019.
[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.
[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-00
(work in progress), January 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-01 (work in progress), September 2019.
Kohno, et al. Expires September 9, 2020 [Page 9]
Internet-Draft SRv6mob-arch March 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-12
(work in progress), June 2018.
[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.
[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
Kohno, et al. Expires September 9, 2020 [Page 10]
Internet-Draft SRv6mob-arch March 2020
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 September 9, 2020 [Page 11]