Review on issues in discussion of next generation converged networks (5G) from an IP point of view
draft-vonhugo-5gangip-ip-issues-02
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Expired".
|
|
|---|---|---|---|
| Authors | Dirk Von Hugo , Behcet Sarikaya | ||
| Last updated | 2017-02-23 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-vonhugo-5gangip-ip-issues-02
Network Working Group D. von Hugo
Internet-Draft Telekom Innovation Laboratories
Intended status: Informational B. Sarikaya
Expires: August 27, 2017 Huawei
February 23, 2017
Review on issues in discussion of next generation converged networks
(5G) from an IP point of view
draft-vonhugo-5gangip-ip-issues-02
Abstract
This document presents considerations related to open and upcoming
issues with upcoming new communication systems denoted as 5G aiming
to set a basis for documenting problem space, use-cases, and
potential solutions related to next-generation network
infrastructure. The draft reviews currently investigated topics,
including both inputs from IETF and from other SDOs as well as
research activities. Further the outcome of recent discussions at
side sessions during IETF meetings are recaptured to help identifying
a starting point for future thoughts.
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 August 27, 2017.
Copyright Notice
Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of
von Hugo & Sarikaya Expires August 27, 2017 [Page 1]
Internet-Draft 5G IP Issues February 2017
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. Problem Space and Typical Use Cases . . . . . . . . . . . . . 4
2.1. Ubiquitous Broadband Access Use Case . . . . . . . . . . 4
2.2. Massive Deployment of Machines Use Case . . . . . . . . . 4
2.3. Critical Communications Use Case . . . . . . . . . . . . 4
3. Requirements to Future Communication Systems . . . . . . . . 4
4. Current Activities and Areas of Work within IETF/IRTF . . . . 5
5. Future Internet Architecture . . . . . . . . . . . . . . . . 6
6. Edge Network with no Tunneling . . . . . . . . . . . . . . . 8
7. Logical Network Isolation (Slicing) Concepts . . . . . . . . 9
8. Towards Converged Access-Agnostic Core Network . . . . . . . 10
9. Session Management Architecture . . . . . . . . . . . . . . . 12
10. Towards Next Generation Mobility Protocol . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
15.1. Normative References . . . . . . . . . . . . . . . . . . 16
15.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
This document focuses on IP architecture and protocol aspects related
to upcoming new communication system infrastructure. This envisaged
5G system is foreseen to be available from 2020 onwards to provide a
converged Information and Communication Technology (ICT) ecosystem.
The offered broad spectrum of fixed and mobile services will be
characterised mainly by improved flexibility and efficient usage of
available resources to support services' demands with partially
contradicting requirements. A new highly re-configurable
architecture in both heterogeneous access and a converged core
network shall allow for key features as
o Stable selectable low latency
o Granted reliability and availability according to user and service
demands
von Hugo & Sarikaya Expires August 27, 2017 [Page 2]
Internet-Draft 5G IP Issues February 2017
o Potential (adaptive) mobility support (i.e. on demand): in case of
change in device or service location or as countermeasure to
partial failures /outage
o Low cost (i.e. affordable and related to service characteristics)
with respect to both investment and operational expenses:
efficiency in terms of resource consumption and effort
o Adaptive support of service quality in terms of (raw network)
performance (Quality of Service, QoS) and individual user
experience (Quality of Experience, QoE) requiring end-to-end
monitoring and feedback
o Selectable inbuilt security: different measures to be chosen from
a tool box
o Improved resource efficiency (e.g. in terms of energy consumption,
processing power, data storage, and radio spectrum usage)
o High flexibility for new services (and service features)
introduction and deployment
o Much better scalability in terms of amount of supported end
devices and transferred data rates and volume
o Higher bandwidth, data rate and throughput shall be achieved with
new radio technologies (multiple antennas) and usage of multiple
potentially heterogeneous technologies in concurrence
(multiaccess), bandwidth/ broadband access values exceeding 1Gbps.
A network to serve diverse demands ranging between very strict and
quite relaxed requirements asks for dynamic feature selection per
network functionality and thus will be much more software centric.
Only an architecture with modular control plane functions will enable
service tailored selection or adaptation of network characteristics
in terms of functionalities.
Also the expected high flexibility and resource efficiency demands
for exploitation of SDN and NFV together with computation and storage
space provision in central or distributed cloud environments.
In addition a new architecture with modular control plane functions
is required to enable service tailored selection or adaptation of
network characteristics in terms of functionalities.
Decoupling and abstraction of access and core domains to allow for
heterogeneity enabling higher flexibility and resource usage
efficiency is a request to 5G systems.
von Hugo & Sarikaya Expires August 27, 2017 [Page 3]
Internet-Draft 5G IP Issues February 2017
2. Problem Space and Typical Use Cases
The design of the new 5G system faces challenging requirements which
are derived from potential prospective services to be provisioned via
the 5G ecosystem. To illustrate the broad range of diverse demands
out of the plentitude of use cases as identified e.g. in [NGMN] a set
of three exemplary use case families is presented below following
[METIS].
Generally all such services cannot and have not to be provided within
one specifically configured logical network. Flexibility to allow
different adaptations of the same physical infrastructure to fulfill
one tenants or verticals (service providers) requests is essential
for an appropriate 5G system concept.
2.1. Ubiquitous Broadband Access Use Case
These group of use cases covers fixed, portable, and mobile
applications between user equipment and servers in the network which
may be characterized by large bandwidth requirements, support of
moving devices, typical multimedia services between humans and
between humans and content in the network to only name a few.
2.2. Massive Deployment of Machines Use Case
The Machine Type Communication (MTC) or Internet of Things (IoT) use
cases cover generally a large amount and dense deployment of devices
(sensors, metering) as smart grid or of Industry 4.0 type, but also
vehicular communication.
2.3. Critical Communications Use Case
Here a strict latency and reliability limit has to be considered
since services are time-critical or need high delivery probability.
3. Requirements to Future Communication Systems
Derived from the use case scenarios a list of requirements for 5G has
been established by several organisations as e.g. NGMN or 3GPP
denoting as key issues or key design principles or key drivers, for
details see e.g. 3GPP [TR23.799]. Also ITU has identified key
capabilities of IMT-2020, i.e. the International Mobile
Telecommunications (IMT) system for 2020 and beyond, which can be
found in [M.2083].
Beside quantitatively measurable expected enhancement of performance
parameters as
von Hugo & Sarikaya Expires August 27, 2017 [Page 4]
Internet-Draft 5G IP Issues February 2017
o User experienced data rate: 100 vs. 10 Mbit/s
o Spectrum efficiency 3 times that of IMT Advanced
o Mobility support for up to 500 km/h instead of 350 km/h (only)
o Latency (of 1 vs. 10 ms), Latency down to 1ms could be foreseen
for 5G
o Connection density of 1 Million vs. 100000 devices/km
o Network energy efficiency of 100 times improved
o Area traffic capacity of 10 vs. 0.1 Mbit/s/m2
o Peak data rate of 20 instead of below 1 Gbit/s
Other key improvements which are not always direct quantitatively
measurable cover so-called soft features are also essential for 5G:
o Network scalability and flexibility
o Logical network separation (slicing)
o Consistent customer experience
o Service and network trust, reliability and security
o Operational efficiency
o Openness for innovation
4. Current Activities and Areas of Work within IETF/IRTF
Although a vertical topic as 5G is seen not as IETF topic ( providing
standardized building blocks for specific engineering challenges
"horizontals." IETF does not define or adapt "vertical" frameworks
like "Smart Cities," "Internet of Things," or "5G networks." It is
implicitly assumed that the participants will apply the building
blocks within the verticals
[I-D.arkko-ietf-trends-and-observations].), the topic creates issues
on multiple horizontal levels as is reflected within drafts and
discussions in WGs such as LISP (Locator/Identifier Separation
Protocol), NVO3 (Network Virtualization Overlays). Furthermore IRTF
RGs with focus on 5G topics are NFV(Network Function Virtualization),
SDN (Software Defined Networking), and ICN (Information Centric
Networking).
von Hugo & Sarikaya Expires August 27, 2017 [Page 5]
Internet-Draft 5G IP Issues February 2017
There is also a rich set of Mobile IP based mobility approaches which
also can be viewed as identifier locator separation protocol with
home address as the identifier and care-of address as the locator.
Original Mobile IP used tunneling and a fixed anchor called Home
Agent (HA) or Local Mobility Anchor (LMA). However more recently
extensions for distributed anchoring were designed.
The current activities there contribute to one or more of the
following issues addressed in more detail during the preceding side
meetings of the 5GangIP mailing list archive.
5. Future Internet Architecture
Currently the efforts towards the Next Generation System have defined
architectural requirements as outlined in [TR23.799] and design of
specific network entities as network functions (NFs or VNFs) and
interfaces between them, protocols and procedures both for 5G Access
Network for various different accesses and a common core network is
ongoing. Aim is specifying and optimizing protocols for a more
efficient internet to provide mobility, scale, security and ease of
deployment required for a connected society beyond the year 2020.
But the industry seems to be divided by what should qualify as a true
5G. One approach to 5G is:
5G radio / enhanced LTE + 5G core
This new core shall both meet the 5G requirements and allow for
connection via enhanced 4G radio for reasons of operational
continuity.
The current IP is connectivity-centric. Additional features such as
mobility and security are added as optional patches and fix-ups.
Moreover, protocols have been designed in a segmented way instead of
an architectural way.
Future Internet Architecture attempts to look at the current user/
data plane protocol stack that is in use in both fixed and mobile
networks and redesign it. One issue the future internet architecture
addresses is the number of layers below the IP layer.
If we consider the current LTE radio protocol stack, we can easily
find that there are 6-plus layers, with PDCP, RLC, MAC and PHY being
the ones below IP layer. Each layer adds some bytes to the header,
some layers have their own checksums, i.e. more overhead. However,
in cellular Internet of Things, (IoT) a packet may have only 1 byte
payload. In this case, we would not call it efficient, the
efficiency rate is less than 1%, with the efficiency rate defined as
(payload length)/(packet size).
von Hugo & Sarikaya Expires August 27, 2017 [Page 6]
Internet-Draft 5G IP Issues February 2017
Future internet architecture deals with data plane protocol stack
reduction issues like:
o Which layers could be reduced?
o How can we deal with multiple checksums, since it is very
expensive to compute checksums, remembering we aim at 1ms latency
budget?
o Should we design a new type of protocol that does not reuse the
existing ones to make the network more efficient? Such a clean
slate approach would expose a high degree of disruption.
o What would happen if we take away GTP, LTE's tunneling protocol?
For more discussion on this see Section 6.
Future internet architecture proposes a unified layering for both
fixed and mobile networks. In the IP layer, we have Identifier
Oriented Networking or IP protocol. Below this, we have the next
generation medium access control protocol providing a unified medium
access to 5G radio, 802.11 or Wi-Fi and Ethernet type of fixed access
technologies. The lowest layer is the next generation physical layer
protocol unifying all physical accesses to 5G-era.
In the control plane, there are even much more we need to consider.
For example, the current internet is operated by routing protocols
and their extensions. These protocols are usually driven by Command
Line Interfaces (CLIs) on the first hand, e.g. for protocols like
OSPF [RFC5340] will work as instructed by the commands in CLI.
However, in 5G, there will be many moving things, perhaps with low-
power so that at one instant they are up and at the next instant they
are down. The traditional operation model won't work any more, since
we can't easily configure them and we don't want their mobility and
status change affecting the routing tables, Routing Information Base
(RIB) frequently.
In this case, mobility issue will arise. A cell phone moves, but its
identifier (ID) does not change. Can 5G network mobility protocols
(see Section 10) be used for this use case, i.e. also handle e.g.
session continuity in case of multi-connectivity? Which further
extensions and modifications might be needed to re-scope the approach
to apply for the required mobility? ID plays a central role in
mobility. Can we design a new protocol, say ID-Oriented Networking
Protocol? In future, more and more mobile things are connected to
the internet which may not yet have proper identifiers available
compared to cell phones (see e.g. [I-D.ietf-dmm-4283mnids]): things
like connected cars, connected drones, etc.
von Hugo & Sarikaya Expires August 27, 2017 [Page 7]
Internet-Draft 5G IP Issues February 2017
For more discussion on this see Section 10.
6. Edge Network with no Tunneling
In fixed network, PPPoE protocol [RFC2516] is used between the
residential gateway and broadband network gateway to transport the
residential users IP packets to the fixed network gateway to the
Internet. PPPoE protocol requires 8 octets of header in every IP
packet, thereby reducing the MTU size by 8 octets to usually 1492
octets. PPPoE protocol is carried in Ethernet frames with 18 octet
headers where the destination address is the broadband network
gateway address.
Aiming at an IP protocol unaware/agnostic/overarching control plane
logic multiple protocol approches can be deployed depending on actual
service and slice demands, such as e.g. those based on low-overhead
translation mechanisms and encapsulation-based ones on the other
hand. If a client-based mapping between Identifier and Locator is
required (i.e. executed on a user terminal) translation would be the
recommended approach. For network-centric deployment a LISP-like
mapping function on gateways or the session terminating servers and
data centers can be deployed. How such a control plane could look
like on L2/L3 to support LISP has recently been described in
[I-D.portoles-lisp-eid-mobility].
In mobile network, IP packets are tunneled using GTP data plane
protocol called GTP-U. First eNodeB or the base station tunnels UE's
IP packets to the Serving Gateway, in S1 GTP tunnel and then the
serving gateway tunnels to the Packet Gateway, called S5 tunnel.
Both of them are UDP tunnels which adds 8 octet header and GTP
protocol header is 12 octets, so a total of 20 octets are used. In
addition also an IPSec header should be accounted for between eNodeB
and SGW.
On the other hand in an end-to-end path between UEs or towards the
Application Function the network has either to keep a lot of status
information (meta data) for finding and maintaining the optimum path
- or apply encapsulation with specific headers between eNB and SGW/
PGW - as tunneling. As exemplarily shown above, however, tunneling
adds a lot of overhead to the user IP packets and therefore
inefficiencies arise including reducing the MTU size.
If tunneling can be avoided, i.e. if edge networks can be designed
with no tunneling, a corollary of this would be no gateways would be
needed, leading to edge networks with no tunneling or no gateway.
The means to avoid gateways and tunneling a direct end-to-end routing
has to be established in the edge network.
von Hugo & Sarikaya Expires August 27, 2017 [Page 8]
Internet-Draft 5G IP Issues February 2017
With routing support edge networks can direct the user traffic to the
correct destinations, rather than tunneling to the gateways. In
order to deal with user mobility, ID-oriented networking protocol
would be needed. So it needs to be evaluated if using ID-oriented
networking protocol with routing will lead to more efficient delivery
of user IP packets in the edge network compared with 4G edge network
techniques of tunneling with gateways.
As we deal with carrier-grade networks here also the aspects of AAA
and charging have to be considered. The main reason why tunneling is
used in 4G edge networks and broadband network is to direct the user
traffic so that the operator can identify and handle the traffic
according to underlying service class specific demands. Another
issue is charging and accounting the user properly and both requires
the traffic to be routed via specific gateway nodes using the tunnel
endpoint identifiers (TEID) carried in GTP header. Edge networks
with no gateways should enable enough control to the operators so
that charging and other functions on the user traffic is properly
conducted.
Optimum use of available resources may also require a common control
framework including e.g. user plane communication between devices
directly or via relays / access nodes only. How such an efficient,
scalable, and performant solution in case of mobility has to be
designed - preferably without much effort due to complex state
handling - is one of the challenging questions.
7. Logical Network Isolation (Slicing) Concepts
Within the framework of 5G a network slice is seen as an independent
logical end-to-end network, defined by a set of specific network
functions providing service-specific network characteristic
(performance). The basic Network Functions can be both physical and
virtual in nature, and comprise C-plane and D-plane tasks (maybe
supplemented by Management), and should be independently instantiated
and operated. Network functions are adapted and configured according
to service demands which includes as well parameter settings as their
logical and spatial location within the network topology (e.g. at
central or remote processing clouds, i.e. data centers, to achieve
e.g. a low transmission delay towards the end user).
A major issue in isolation between different network slices beside
the security and reliability is a minimum interference in between
them in terms of trade-off with respect to joint usage of shared
resources (e.g. radio spectrum for wireless access or processing
capacity for network function execution). Here again, the more
limited the resources are, the more important it is to achieve a
highly effient usage creating the need for proper mechanisms (e.g.,
von Hugo & Sarikaya Expires August 27, 2017 [Page 9]
Internet-Draft 5G IP Issues February 2017
algorithms and protocols) to orchestrate and coordinate resource
assignment (and to monitor the actual network slice performance).
8. Towards Converged Access-Agnostic Core Network
Currently network infrastructure is being transformed into two-layer
data center or cloud as Core Network (CN) and the Access Network
which mainly accommodates 5G radio access network on the wireless
side and central office on the wireline network closer to the user.
This new architecture enables us to flexibly deploy 5G Virtual
Network Functions (VNFs) based on the service scenarios. The
division of work in this case is to deploy 5G control plane VNFs in
the core cloud and 5G user/data plane VNFs and related applications
in the edge cloud.
The new architecture also leads us to a converged access independent
core network with a common access network - core network interface
which integrates 5G network with the fixed network leading us to 5G
Fixed Mobile Convergence (FMC). 5G architecture minimizes
dependencies between Access Network (AN) and Core Network (CN), the
architecture is defined with a converged access-agnostic core network
with a common AN - CN interface which integrates different 3GPP and
non-3GPP access types.
Proposed 5G architecture is shown in Figure 1. The rectangles are
the network functions and the lines are their interconnections or
reference points from N1 to N15. Network Function names are given on
the right hand side.
The reference points usually carry a specific protocol such as GTP
(GTP-C for control plane, e.g. over N2 or GTP-U for data plane, e.g.
over N3) or Non-Access Stratum (NAS) of 3GPP. Access and Mobility
Management Function (AMF) is the Network Function (NF) that
terminates N1 and N2. User Plane Function (UPF) is the NF that
terminates N3. We explain a few important network functions here.
Access and Mobility Management Function (AMF) is in charge of
registration management, connection management, reachability
management, mobility Management, it is transparent proxy for routing
session management messages. It does access authentication and
access authorization.
Session Management Function (SMF) is in charge of session
establishment, modify and release, including tunnel maintainance
between UPF and the access network (AN) node. UE IP address
allocation and management (incl. optional Authorization), selection
and control of the user plane (UP), i.e. data plane function. SMF
configures traffic steering at UPF to route traffic to proper
von Hugo & Sarikaya Expires August 27, 2017 [Page 10]
Internet-Draft 5G IP Issues February 2017
destination (i.e the corresponding Data Network, DN); termination of
interfaces towards policy control functions (PCF); control part of
policy enforcement and QoS termination of session management (SM)
parts of non-access stratum (NAS) messages, downlink Data
Notification; initiator of AN specific SM information, sent via AMF
over N2 to AN; support for interaction with external DN for transport
of signalling for PDU session authorization/authentication by
external DN.
User Plane Function (UPF) is anchor point for mobility (when
applicable); external PDU session point of interconnect to Data
Network; packet routing and forwarding Packet inspection and User
plane part of Policy rule enforcement; uplink classifier to support
routing traffic flows to a data network; branching point to support
multi-homed PDU session; transport level packet marking in the uplink
and downlink; downlink packet buffering and downlink data
notification triggering.
According to 5G architecture, 5G UE is expected to use Non-Access
Stratum (as opposed to Access-Stratum (AS) which is used between
radio network and UE) signaling for establishment of communication
sessions and for maintaining continuous communications with the user
equipment as it moves with 5G core network even when UE is connected
to 5G core network via a non-3GPP access network, e.g. over Wi-Fi,
oftentimes simultaneously to the wireless radio access network (RAN).
Key principles and concepts in 5G architecture include separation of
User Plane (UP) functions from the Control Plane (CP) functions,
allowing independent scalability, evolution and a flexible deployment
e.g. centralised location or distributed (remote) location;
definition of the the network functions, e.g. to enable flexible and
efficient network slicing. Network slicing (see Section 7) with
slices that may include components served by fixed networks is
another innovation in 3GPP 5G architecture work as well as the
definition of a common core network which is access agnostic.
Wherever applicable, procedures (i.e. the set of interactions between
network functions) are defined as services, so that their re-use is
possible. Each Network Function can interact with the other NF
directly if required. The architecture does not preclude the use of
an intermediate function to help route control plane messages.
von Hugo & Sarikaya Expires August 27, 2017 [Page 11]
Internet-Draft 5G IP Issues February 2017
+----+ +---+ Authentication
|AUSF|---N13---|UDM| Server Function
+----+ +---+ (AUSF)
\ /\ Core Access and
\ / \ Mobility Management
N12 N8 N10 Function (AMF)
\ / \ Data network (DN)
+---+ +---+ +---+ +--+
________|AMF|-N11-|SMF|-N7-|PCF|--N5-|AF|
/ +---+ +---+ +---+ +--+
/ / N14|_______/__N15_____|
/ / / Policy Control
N1 N2 / Function (PCF)
/ / N4 Session Management
/ / / Function (SMF)
/ / / Unified Data
/ / / Management (UDM)
+--+ +---+ +---+ /---\ User Equipment(UE)
|UE|-------|RAN|---N3---|UPF|---N6- -|DN | (Radio)Access Network ((R)AN)
+--+ +---+ +---+ \---/ User Plane Function (UPF)
|-N9-|
Figure 1: 5G Architecture
One of the challenges in 5G FMC is how to provide seamless mobility
when 5G UE while in a 5G radio access network later moves to an area
of Wi-Fi access point connected to a central office while both access
networks are served by a converged common core. Another challenge is
to enable flexible and seamless management of the user sessions while
accessing sometimes simultaneously over UE's multiple interfaces,
e.g. 5G and Wi-Fi.
9. Session Management Architecture
Session management responsible for the setup of the connectivity for
the UE as well as managing the user plane for that connectivity is
identified as one of the key issues in 5G system architecture in
[TR23.799]. It is one of the network functions, the Session
Management Function (SMF) in 5G Architecture described in Section 8.
Session management design issues include managing multiple access,
multiple connectivity, multiple transport paths, e.g. to RAN and to
non-3GPP access network (AN), sometimes simultaneously and how to
efficiently transmit and receive infrequent small amounts of data and
short data bursts, e.g. for Narrow Band Internet of Things (NB-IoT).
In this section, we take a look at how SMF can be structured.
Using control plane data plane separation principle, SMF can be
subdivided into a control plane component called Network Connection
von Hugo & Sarikaya Expires August 27, 2017 [Page 12]
Internet-Draft 5G IP Issues February 2017
Manager (NCM) and a data plane component for user data traffic
forwarding called Network Multi-Access Data Proxy (MADP). NCM and
MADP are hosted in 5G core network. We also need corresponding
client side NCM, called CCM and MADP hosted on the UE
[I-D.kanugovi-intarea-mams-protocol].
Network Multi-Access Data Proxy (MADP) in the core network handles
the user data traffic forwarding across multiple network paths, as
well as other user-plane functionalities, e.g. encapsulation,
fragmentation, concatenation, reordering, retransmission, etc.
N-MADP is the distribution node for uplink and downlink data with
visibility of packets at the IP layer.
Network Connection Manager (NCM) in the core network configures
identification and distribution rules for different user data traffic
type at the N-MADP. The NCM configures the routing in the MADP based
on signaling exchanged with the CCM in UE. In the uplink, NCM
specifies the core network path to be used by MADP to route uplink
user data at the MADP. In the downlink, NCM specifies the access
links to be used for delivery of data to the client at the MADP.
At the UE, MADP handles encapsulation, fragmentation, concatenation,
reordering, retransmissions, etc. C-MADP is configured by CCM based
on signaling exchange with NCM and local policies at the UE.
At the UE, CCM manages the multiple network connections. CCM is
responsible for exchange of MAMS signaling messages with the NCM for
supporting functions like configuring uplink and downlink user
network paths for transporting user data packets, link sounding and
reporting to support adaptive network path selection by NCM. In the
downlink, for the user data received by UE, it configures IP layer
forwarding for application data packets received over any of the
accesses to reach the appropriate application module on the client.
In the uplink, for the data transmitted by UE, it configures the
routing table to determine the best access to be used for uplink data
based on a combination of local policy and network policy delivered
by the NCM.
The challenges of this kind of SMF design include if such a design
can be simplified so that NB-IoT type of very simple sessions can
also be handled. Regarding SMF and AMF, identifying the correlation
between session management and mobility management, identifying the
interactions between session management and the mobility framework
required to enable the various mobility scenarios while minimizing
any negative impact on the user experience investigating solutions to
coordinate the relocation of user-plane flows with the relocation of
applications (hosted close to the point of attachment of the UE) due
von Hugo & Sarikaya Expires August 27, 2017 [Page 13]
Internet-Draft 5G IP Issues February 2017
to the mobility of users can be considered as the challenges of 5G
architecture.
10. Towards Next Generation Mobility Protocol
With both physical and logical mobility of (an extremely high number
of) entities and virtualization of network functions the traditional
usage of IP addresses for denoting both IDentifier and Address or
logical entity and location as source or destination of data packets
becomes cumbersome. New approaches to solve the issues are proposed
in LISP WG in terms of [RFC6830] and ICN RG (see [RFC7476]) but also
ILNP [RFC6740] and ILA [I-D.herbert-nvo3-ila] address this challenge.
By separating a Routing LOCator (RLOC) from a unique Identity (EID)
LISP keeps a single address to each session endpoint even in multi-
homing but requires a dedicated mapping mechanism for compatibility
with the (LISP-unaware) Internet. ILNP (and ILNP-based ILA) avoid
encapsulation and require no changes in higher layers (except the
transport layer) re-using part of an (IPv6) Address as Identifier and
Locator. ILA does not require any changes in transport layer but it
is IPv6 only.
In LISP the EID/RLOC split can be collocated in the same entity: EID
mobile, RLOC static or dynamic. Predictive RLOCs
[I-D.farinacci-lisp-predictive-rlocs] can be used if LISP entity
knows where the user going so that the system can mitigate mobility
impacts. LISP can be used between the Serving and Packet data
Gateways. Best solution is to keep LISP close to the moving entity
with the functions as close to the edge as possible.
ILNP defines minimal changes on IPv4 and IPv6, it requires changes on
the domain name system and the transport layer [RFC6740]. Both ILNP
and ILNP-based ILA rely on the routing system or LTE core network to
route to the translated address.
LISP requires routing system changes, it is implemented on the
routers, possibly on the edge routers. That means LISP requires
changes on LTE core network. ILNP does not use encapsulation so it
is light weight. LISP is UDP encapsulated so in IPv6, LISP messages
incur 52 bytes of overhead.
ILNP nodes send Locator Update messages which are ICMPv4/v6 messages
to its correspondent nodes when its Locator value changes during an
active session. Correspondent node could be a fixed node such as
Google server which means ILNP has to be implemented by the fixed
nodes as well.
von Hugo & Sarikaya Expires August 27, 2017 [Page 14]
Internet-Draft 5G IP Issues February 2017
ILA is a major update to ILNP [I-D.herbert-nvo3-ila]. It is
originally designed for network virtualization to be used in cloud
networks. ILA can encode a virtual network identifier (VNID) and
virtual address as an ILNP identifier. ILA adaptation for 3G network
mobility is investigated in [I-D.mueller-ila-mobility].
Further investigations are needed if ILA can be adopted for mobility
in a 5G fixed mobile convergence network with a converged core
network. The prospective approach is to overcome tunneling and
encapsulation overhead by simplified routing according to identifiers
not bound to locations and thus allowing for relocation within
underlying infrastructure. Such an approach should also incorporate
session management in support of session and service continuity in
the 5G architecture with a common core enabling mobility in multiple
access networks.
As none of the mentioned existing proposals fully covers the 5G
requirements consistently, in this document, the authors propose the
following steps for investigations on further enhancements that have
to be performed.
Problem statement on the need for a next generation or 5G mobility
protocol with session management, exploiting previous standardization
efforts.
Requirements on a new 5G FMC network mobility protocol in view of 5G
execution environments such as in Section 8, and issues such as in
Section 6.
An architecture document that uses all the relevant Network Functions
identified in 5G architecture and possibly their subdivisions or
components when deploying 5G FMC network mobility and session
management protocol and their interconnections.
A document on possible solution space investigations including
adaptations into specific architectures such as 5G architecture.
11. IANA Considerations
None.
12. Security Considerations
Security considerations related to the 5G systems are discussed in
[NGMN]. Due to the request for intrinsic realization of security
such aspects have to be considered by design for architecture and
protocols.
von Hugo & Sarikaya Expires August 27, 2017 [Page 15]
Internet-Draft 5G IP Issues February 2017
Especially as a joint usage of resources and network functions by
different separate logical network slices (e.g. in terms of virtual
network functions) seems to be inevitable in the framework of 5G the
need for strong security measures in such an environment is a major
challenge.
13. Privacy Considerations
Support of full privacy of the users (customers and tenants / end
service providers) is a basic feature of the next generation trusted
and reliable communications offering system. Such a high degree of
ensured privacy shall be reflected in the proposed architecture and
protocol solutions (details have to be added).
Especially as Identifiers and mapping of locators to them are
addressed the discussion on identifier and privacy should consider
existing solutions such as 3GPP Globally Unique Temporary UE Identity
(GUTI) which is a temporary identity obfuscating the permanent
identity in the mobile network and specified in [TS23.003].
14. Acknowledgements
This work has been partially performed in the framework of the
cooperation Config. Contributions of the project partners are
gratefully acknowledged. The project consortium is not liable for
any use that may be made of any of the information contained therein.
Comments and careful review by Dino Farinacci as well as
contributions by Tom Herbert, Julius Mueller, Robert Moskowitz and
others of the 5GangIP mailing list are gratefully acknowledged.
15. References
15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
15.2. Informative References
[I-D.arkko-ietf-trends-and-observations]
Arkko, J., Atlas, A., Doria, A., Gondrom, T., Kolkman, O.,
olshansky@isoc.org, o., Schliesser, B., Sparks, R., and R.
White, "IETF Trends and Observations", draft-arkko-ietf-
trends-and-observations-00 (work in progress), February
2016.
von Hugo & Sarikaya Expires August 27, 2017 [Page 16]
Internet-Draft 5G IP Issues February 2017
[I-D.farinacci-lisp-predictive-rlocs]
Farinacci, D. and P. Pillay-Esnault, "LISP Predictive
RLOCs", draft-farinacci-lisp-predictive-rlocs-01 (work in
progress), November 2016.
[I-D.herbert-nvo3-ila]
Herbert, T., "Identifier-locator addressing for IPv6",
draft-herbert-nvo3-ila-03 (work in progress), October
2016.
[I-D.ietf-dmm-4283mnids]
Perkins, C. and V. Devarapalli, "MN Identifier Types for
RFC 4283 Mobile Node Identifier Option", draft-ietf-dmm-
4283mnids-04 (work in progress), January 2017.
[I-D.kanugovi-intarea-mams-protocol]
Kanugovi, S., Vasudevan, S., Baboescu, F., Zhu, J., and S.
Peng, "Multiple Access Management Services", draft-
kanugovi-intarea-mams-protocol-02 (work in progress),
January 2017.
[I-D.mueller-ila-mobility]
Mueller, J. and T. Herbert, "Mobility Management Using
Identifier Locator Addressing", draft-mueller-ila-
mobility-03 (work in progress), February 2017.
[I-D.portoles-lisp-eid-mobility]
Portoles-Comeras, M., Ashtaputre, V., Moreno, V., Maino,
F., and D. Farinacci, "LISP L2/L3 EID Mobility Using a
Unified Control Plane", draft-portoles-lisp-eid-
mobility-01 (work in progress), October 2016.
[M.2083] ITU-R, "Rec. ITU-R M.2083-0, IMT Vision-Framework and
overall objectives of the future development of IMT for
2020 and beyond", September 2015.
[METIS] Elayoubi, S. and et al., "5G Service Requirements and
Operational Use Cases: Analysis and METIS II Vision",
Proc. euCNC, 2016.
[NGMN] NGMN Alliance, "NGMN White Paper", February 2015.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
and R. Wheeler, "A Method for Transmitting PPP Over
Ethernet (PPPoE)", RFC 2516, DOI 10.17487/RFC2516,
February 1999, <http://www.rfc-editor.org/info/rfc2516>.
von Hugo & Sarikaya Expires August 27, 2017 [Page 17]
Internet-Draft 5G IP Issues February 2017
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740,
DOI 10.17487/RFC6740, November 2012,
<http://www.rfc-editor.org/info/rfc6740>.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[RFC7476] Pentikousis, K., Ed., Ohlman, B., Corujo, D., Boggia, G.,
Tyson, G., Davies, E., Molinaro, A., and S. Eum,
"Information-Centric Networking: Baseline Scenarios",
RFC 7476, DOI 10.17487/RFC7476, March 2015,
<http://www.rfc-editor.org/info/rfc7476>.
[TR23.799]
"3GPP TR23.799, Study on Architecture for Next Generation
System (Release 14)", December 2016.
[TS23.003]
"3GPP TS23.003, Numbering, addressing and identification
(Release 14)", September 2016.
Authors' Addresses
Dirk von Hugo
Telekom Innovation Laboratories
Deutsche-Telekom-Allee 7
D-64295 Darmstadt
Germany
Email: Dirk.von-Hugo@telekom.de
Behcet Sarikaya
Huawei
5340 Legacy Dr.
Plano, TX 75024
Email: sarikaya@ieee.org
von Hugo & Sarikaya Expires August 27, 2017 [Page 18]