[Docs] [txt|pdf] [Tracker] [Email] [Nits]
Versions: 00 01 02 03
DMM Working Group M. Kohno
Internet-Draft F. Clad
Intended status: Informational P. Camarillo
Expires: May 4, 2020 Z. Ali
Cisco Systems, Inc.
November 1, 2019
Architecture Discussion on SRv6 Mobile User plane
draft-kohno-dmm-srv6mob-arch-00
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, rather than from the viewpoint of individual layer.
One important value propositions of SRv6 mobile user plane is the
possible optimization across the existing multiple layers.
This document discusses the architectural implications of applying
SRv6 mobile user plane, especially regarding the possible
optimization of existing layers. Then it takes 5G requirements and
use cases as an example, and describes how these use cases are simply
and effectively realized with the inter-layer optimization capability
of SRv6 mobile user plane. Thus it show that SRv6 mobile use plane
is a right architectural choice for the 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 May 4, 2020 [Page 1]
Internet-Draft SRv6mob-arch November 2019
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 4, 2020.
Copyright Notice
Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.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 May 4, 2020 [Page 2]
Internet-Draft SRv6mob-arch November 2019
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 layer separation 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 layer.
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].
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.
This document discusses the architectural implications of applying
SRv6 mobile user plane, especially regarding the possible
Kohno, et al. Expires May 4, 2020 [Page 3]
Internet-Draft SRv6mob-arch November 2019
optimization of existing layers. Then it takes 5G requirements and
use cases as an example, and describes how these use cases are simply
and effectively realized with the inter-layer optimization capability
of SRv6 mobile user plane. Thus it show that SRv6 mobile use plane
is a right architectural choice for the 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 tight-SLA characteristics and flexible traffic
steering towards various service functions. While 3GPP has been
focused on the mobility overlay, how to map the overlay requirements
into the transport network is out of the scope.
IETF has discussed mobile end-to-end slicing in different WGs
[I-D.rokui-5g-transport-slice], [I-D.clt-dmm-tn-aware-mobility].
However, all these proposals are based on the current assumption that
the underlying network is separated from the overlay and agnostic.
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 has a potential to
perform inter-layer optimizations and/or eliminate overlay tunnels,
though it does not mandate to do so.
Note that SRv6 can also be applied to the mobility overlay, in which
case it also has benefits as the tunnels are removed.
Kohno, et al. Expires May 4, 2020 [Page 4]
Internet-Draft SRv6mob-arch November 2019
3. Terminology
The terminology used in this document leverages and conforms to
[I-D.ietf-dmm-srv6-mobile-uplane].
+-----+
| 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
4. SRv6 mobile user plane and the 5G use cases
4.1. Network Slicing
The SRv6 mobile user plane proposal specifies the Traditional mode
and the Enhanced mode. The Traditional mode inherits the existing
mobile user plane and minimize the impact to the existing the 3GPP
architecture. The Enhanced mode can encode any required SID(s) for
constraint path steering and service steering purpose, which enable
efficient end-to-end network slicing.
How to build network slicing using the Segment Routing based
technology is described in
[I-D.ali-spring-network-slicing-building-blocks]
Kohno, et al. Expires May 4, 2020 [Page 5]
Internet-Draft SRv6mob-arch November 2019
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:
- 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.
In the past, this was unavoidable. But nowadays 3GPP dataa plane
entities are implemented on servers or dedicated platforms which have
virtualized infrastructure, and it is getting common that routing
instances are implemented in such servers/platforms.
Furthermore, as stated in the introduction section, SRv6 have been
implemented in various forms, it is natural for such servers/
platforms to be SRv6 aware.
If the routing administrative domain must be separated between the
3GPP data plane entities and IP network, then BSID (BSID) may be
used. With BSID, Topology information is abstracted and not exposed
to the 3GPP data plane entities.
The BSID is bound to an SR policy, instantiation of which may involve
a list of SIDs. Any packets received with active segment = BSID are
steered onto the bound SR Policy, as defined in [RFC8402].
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.
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.
Kohno, et al. Expires May 4, 2020 [Page 6]
Internet-Draft SRv6mob-arch November 2019
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 such document are focused at improving the
overlay protocol (GTP-U) and limit 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.
- 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. This is
Kohno, et al. Expires May 4, 2020 [Page 7]
Internet-Draft SRv6mob-arch November 2019
a sub-50ms FRR mechanism that provides protection regardless of the
topology through the optimal backup path.
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. Security Considerations
TBD
6. IANA Considerations
NA
7. Acknowledgements
TBD
8. References
8.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.
[]
Filsfils, C., Dukes, D., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", draft-ietf-6man-segment-routing-header-26 (work in
progress), October 2019.
[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-06
(work in progress), September 2019.
[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-05 (work in
progress), October 2019.
Kohno, et al. Expires May 4, 2020 [Page 8]
Internet-Draft SRv6mob-arch November 2019
[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>.
8.2. Informative References
[I-D.ali-spring-network-slicing-building-blocks]
Ali, Z., Filsfils, C., Camarillo, P., and d.
daniel.voyer@bell.ca, "Building blocks for Slicing in
Segment Routing Network", draft-ali-spring-network-
slicing-building-blocks-01 (work in progress), March 2019.
[I-D.clt-dmm-tn-aware-mobility]
Chunduri, U., Li, R., Bhaskaran, S., Tantsura, J.,
Contreras, L., Muley, P., and J. Kaippallimalil,
"Transport Network aware Mobility for 5G", draft-clt-dmm-
tn-aware-mobility-04 (work in progress), July 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.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.
[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.
Kohno, et al. Expires May 4, 2020 [Page 9]
Internet-Draft SRv6mob-arch November 2019
[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
Francois Clad
Cisco Systems, Inc.
France
Email: fclad@cisco.com
Kohno, et al. Expires May 4, 2020 [Page 10]
Internet-Draft SRv6mob-arch November 2019
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 4, 2020 [Page 11]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/