Internet DRAFT - draft-wei-dmm-source-routing-mobility-management
draft-wei-dmm-source-routing-mobility-management
INTERNET-DRAFT X. Wei
Intended Status: <Proposed Standard> F.Yang
Expires: May 23, 2019 Huawei
November 19, 2018
Mobility Management based on Source Routing
draft-wei-dmm-source-routing-mobility-management-00
Abstract
This document explores how mobility management could be provided
based on source routing like solutions and take SRv6 as an example
for 5G LAN service.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2018 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
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
<Author> Expires May 23, 2019 [Page 1]
INTERNET DRAFT <Document Title> November 19, 2018
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. 5G LAN Network Model . . . . . . . . . . . . . . . . . . . . . 4
4. SRv6-based mobility management for 5G LAN . . . . . . . . . . . 5
4.1 UE Handover . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2 SRv6-based Handover . . . . . . . . . . . . . . . . . . . . 5
5. Extensions of SRv6 . . . . . . . . . . . . . . . . . . . . . . 7
3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9
4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 Normative References . . . . . . . . . . . . . . . . . . . 9
5.2 Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
<Author> Expires May 23, 2019 [Page 2]
INTERNET DRAFT <Document Title> November 19, 2018
1 Introduction
The 5G network is designed aims at three scenarios which are eMBB
(enhanced Mobile Broad Band), uRLLC (ultra-Reliable Low latency
Communication ), and mMTC (massive Machine Type Communication). The
goal of 5G is to provide network services for various application
scenarios not limited to traditional MBB service.
One of the promises of 5G is the convergence of fixed and mobile
networks, and providing LAN (Local Area Network) services in 5G
networks is a new communication requirement. 5G LAN has many
potential application scenarios, for example, provide communication
for home service in residential environment which will solve many
coverage and QoS problems that home owners are suffering with the
current solutions; provide enterprise communication service in
enterprise environment to interwork with and enhance existing WLAN
and fixed LANs in the enterprise and as a replacement LAN technology
that eliminates the need for other WLAN and fixed LAN deployments and
provide with a wider area coverage using the cellular radio and
greater mobility for UEs.
Communication between UEs in a 5G LAN is a full mesh communication
mode, and UEs that belong to the same LAN can communicate with each
other, and the UE has mobility characteristics and may move between
different network locations. The traditional GTP tunnel-based
solution needs to establish a tunnel between network nodes in a full
mesh manner in order to connect all the UEs in the same LAN, which
will result in many tunnels. The maintenance process of the tunnels
involves the process of establishing and deleting a tunnel through
signaling, which is very complicated, especially when the UE moves,
it may involve a large number of tunnel establishment and removal
processes.
Source routing is an alternative method for packets routing, which
allows a sender of a packet to partially or completely specify the
route the packet takes through the network, source routing could be a
candidate for routing packets in 5G LAN. Currently there are
different types of approach for source routing, and SRv6 is one of
them. SRv6 (Segment Routing IPv6) [I-D. draft-filsfils-spring-srv6-
network-programming-05] uses a source routing idea to forward packets
in the network and provides flexible routing features for packet
forwarding. SRv6 also defines a number of commands that provide more
powerful additional functions based on data forwarding.
This document explores how mobility management could be provided
based on source routing like solutions and take SRv6 as an example
for 5G LAN service.
<Author> Expires May 23, 2019 [Page 3]
INTERNET DRAFT <Document Title> November 19, 2018
2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
3. 5G LAN Network Model
This section provides a more detailed description of 5G LAN network.
(for simplicity, the control plane entities of 5G core network is
eliminated, for more information about 5G core architecture, please
refer to [TS 23.501])
+----+ +----+
|UPF1|-------------------|UPF2|
+-+--+ ++--++
| | |
| -----+ +-------+
| | |
+-+--+ +-+--+ +-+--+
|gNB1| |gNB2| |gNB3|
+|--+| +--+-+ +|--|+
+----+ || | +--+ +--+
| |+------+ | | |
| | | | | |
| | | | | |
| | | | | |
++--+ ++--+ +-+-+ +-+-+ +-+-+ +-+-+
|UE1| |UE2| |UE3| |UE4| |UE5| |UE6|
+---+ +---+ +---+ +---+ +---+ +---+
Figure 1: 5G LAN Network Model
UE: User Equipment.
gNB: RAN node of 5G system.
UPF: User Plane Function.
Multiple UEs can be included in the same LAN and different UEs can
access the same LAN through different network access point. The
data frame can be unicasted, multicasted or broadcasted among UEs
as in the traditional layer 2 LAN except that data frames are
carried over a 5G network. The UEs may move between different
network locations while maintaining continuity of UE services.
<Author> Expires May 23, 2019 [Page 4]
INTERNET DRAFT <Document Title> November 19, 2018
4. SRv6-based mobility management for 5G LAN
4.1 UE Handover
The solution of 5G LAN based on SRv6 instead of tunnel can make
full use of SRv6 flexibility, and avoid the complexity of tunnel
maintenance while meeting the mobility requirements.
The UE in the LAN handover from one gNB to another gNB due to
reasons such as UE's movement or radio signal quality change. The
network side needs to ensure that no packets are lost during the
handover process, and no packets re-ordering happens to ensure
service continuity. Several requirements that the handover scheme
needs to meet: the switching of the forwarding context from S-gNB
to T-gNB and distinguish between normal traffic and in-transit
traffic.
+----+ +----+
+--+ +-----+ | | | |
|UE| |S-gNB|-----------------| |
+--+ +-----++++++| | | |
| +| | | |
move| +|UPF1| |UPF2|
V +| | | |
+--+ +-----++++++| | | |
|UE| |T-gNB|-----------------| |
+--+ +-----+ | | | |
+----+ +----+
Figure 2: UE Handover
4.2 SRv6-based Handover
When using SRv6 to carry data packets, SRv6 not only needs to
identify the transmission path for packets, but also needs to
distinguish the in-transit data packets during the handover
process, so as to avoid the packets re-ordering received by the
UE. The in-transit packets are packets that should be sent to T-
gNB but sent to S-gNB for transit after handover.
Before the handover occurs, the service flow of the UE is
transmitted between the anchor UPF, the S-gNB and the UE based on
the SRv6, the data packet is carried between the network entities
through SRv6 encapsulation, and the S-gNB and the anchor UPF are
respectively responsible for adding SRv6 header for the uplink
data packets and the downlink data packets. The SRv6 header
encapsulated on the data packet sent by the anchor UPF to the UE
<Author> Expires May 23, 2019 [Page 5]
INTERNET DRAFT <Document Title> November 19, 2018
carries the "Forward" flag to indicate that the data packet is a
data packet from the anchor UPF.
The UE periodically sends a channel measurement report to the S-
gNB for S-gNB to make decision whether a handover to new gNB is
needed. Once the S-gNB decides to initiate the handover procedure,
the S-gNB will interact with the target T-gNB so that the T-gNB is
ready for UE access.
After receiving the handover notification, the Anchor UPF will
stop to transmit data on the path used before the handover. At
this time, the Anchor UPF will set the "End" flag in the SRv6
header of the packet sent on the path before the handover. The
"End" flag is used to indicate that the anchor UPF will stop
transmitting data packets to the path used before the handover,
and then the anchor UPF will transmit the data packet to the T-gNB
through the new path established after handover, and in order to
avoid packets re-ordering, the packets from the anchor UPF are
first cached by T-gNB.
The outer layer of the packets that anchor UPF packet sent to the
S-gNB uses a SRv6 header as the routing field to carry routing
information. The routing information contains one or more path
nodes' information through which the packet traverses from anchor
UPF to S-gNB.. Each SRv6 header includes one or more IPv6
addresses, and each IPv6 address is in one-to-one correspondence
with a path node. The 128-bit IPv6 address is divided into a route
identifier field and a packet source flag field, where the route
identifier field is used to carry path node's information, the
packet source flag field is used to carry the packet source flag.
After the handover notification is sent, S-gNB creates a temporary
forwarding entry for the data transmission path from the S-gNB to
the T-gNB. The forwarding entry records the routing information of
the forwarding nodes for packets to be forwarded from the S-gNB to
the T-gNB. At the same time, the S-gNB receives packet from the
anchor UPF on the path before handover, and the "Forward" flag
carried in the packet indicates that the packet is directly from
the anchor UPF, and the S-gNB obtains routing information from the
temporary forwarding entry and the SRv6 header of the received
data packet is modified according the routing information, the
obtained routing information is carried in the SRv6 header, and
the "Forward" flag carried in the previous SRv6 header is changed
to "Transit" flag, which is used to indicate that the transmitted
data packet is an in-transit packet, and then forward the modified
packet to the T-gNB.
The packet sent by the S-gNB to the T-gNB is encapsulated using a
<Author> Expires May 23, 2019 [Page 6]
INTERNET DRAFT <Document Title> November 19, 2018
SRv6 header as the routing field to carry the routing information,
similar to the SRv6 header encapsulated on packets sent from the
anchor UPF to the S-gNB, where the SRv6 header contains one or
more IPv6 addresses, each IPv6 address is in one-to-one
correspondence with a path node, and the 128-bit IPv6 address is
divided into a route identifier field and a packet source flag
field, where the route identifier field is used to carry path
node's information, the packet source flag field is used to carry
the packet source flag.
An alternative method to carry the packet source flag is to carry
it in the extension field of the SRv6 header, and not in the IPv6
address in the SRv6 header.
When the S-gNB receives a packet with the "End" flag from the
anchor UPF, it forwards the modified packet to the T-gNB by using
a method similar to deal with the "Forward" flag packets. The
difference is that the packet is forwarded to the T-gNB with "End"
flag set instead of "Transit" flag. The "End" flag indicates
anchor UPF will stop transmitting data packets on the path used
before the handover.
Before receiving packets from S-gNB with "End" flag set, the T-gNB
will buffer the packets from anchor UPF transmitted on new path
after handover, and will transmit the in-transit packets from the
S-gNB to UE. When the T-gNB receives the packet with "End" flag
set from the S-gNB, it starts transmitting the packets receiving
from the new path established after handover.
5. Extensions of SRv6
This section describes extensions of SRv6 that are needed when
SRv6 is used for 5G LAN, and there are two kinds of options for
the extensions.
Option 1: IPv6 Address Redefinition
Redefine the 128-bit IPv6 address into two parts: a route
identifier field and a packet source flag field, where the route
identifier field is used to carry path node's information, the
packet source flag field is used to carry the packet source flag.
+--------------------------------+------+
| RID | Flag |
+--------------------------------+------+
Figure 3: IPv6 Address Redefinition
<Author> Expires May 23, 2019 [Page 7]
INTERNET DRAFT <Document Title> November 19, 2018
RID:
Contains path node's information, the information will be used for
routing packet to the specific node.
Flag:
00, "Forward", the default flag that indicates the packet is from
UPF.
01, "Transit", indicates the packet is an in-transit packet.
10, "End", indicating anchor UPF will stop transmitting data
packets on the path used before the handover.
11, reserved.
Option 2: SRv6 Header Extension
Because SRv6 header itself contains an "Optional Type Length Value
objects" field, so this field can be used to carry packet source
flag field, and segment list of IPv6 address in SRv6 header acts
as route identifier field.
+-----------+--------------+--------------+
| Type | Length | Flag |
+-----------+--------------+--------------+
Figure 4: New Optional Type Length Value Object for SRv6 Header
Type: TBD1.
Length: 1
Flag:
00, "Forward", the default flag that the packet is from UPF.
01, "Transit", indicates the packet is an in-transit packet.
10, "End", anchor UPF will stop transmitting data packets to the
path used before the handover.
11, reserved.
<Author> Expires May 23, 2019 [Page 8]
INTERNET DRAFT <Document Title> November 19, 2018
3 Security Considerations
TBD.
4 IANA Considerations
TBD.
5 References
5.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
5.2 Informative References
[I-D.filsfils-spring-srv6-network-programming-05] 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-05 (work in progress), July 2018.
[TS 23.501] 3GPP, "System Architecture for the 5G System", 3GPP
TS23.501 15.0.0, November 2017.
Authors' Addresses
Xinpeng Wei
Beiqing Rd. Z-park No.156, Haidian District,
Beijing, 100095, P. R. China
E-mail: weixinpeng@huawei.com
Fei Yang
Beiqing Rd. Z-park No.156, Haidian District,
Beijing, 100095, P. R. China
E-mail: yangfei15@huawei.com
<Author> Expires May 23, 2019 [Page 9]
