INTERNET-DRAFT K. Bogineni
Intended Status: Informational Verizon
Expires: September 2018 A. Akhavain
Huawei Technologies Canada
T. Herbert
Quantonium
D. Farinacci
lispers.net
A. Rodriguez-Natal
Cisco
March 5, 2018
Optimized Mobile User Plane Solutions for 5G
draft-bogineni-dmm-optimized-mobile-user-plane-00.txt
Abstract
3GPP CT4 has approved a study item to study different mobility
management protocols for potential replacement of GTP tunnels between
UPFs (N9 Interface) in the 3GPP 5G system architecture.
This document provides an overview of 5G system architecture in the
context of N9 Interface which is the scope of the 3GPP CT4 study item
[23501, 23502, 23503, 23203, 29244, 29281, 38300, 38401]. The
requirements for the network functions and the relevant interfaces
are provided.
Reference scenarios and criteria for evaluation of various IETF
protocols are provided.
Several IETF protocols are considered for comparison: SRv6, LISP, ILA
and several combinations of control plane and user plane protocols.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
K. Bogineni Expires September 6, 2018 [Page 1]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 6, 2018.
Copyright 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
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 and Problem Statement . . . . . . . . . . . . . . 4
2 Conventions used in this document . . . . . . . . . . . . . . . 4
3 Overview of Existing Architecture and Protocol Stack . . . . . 4
4 Reference Scenario(s) for Evaluation . . . . . . . . . . . . . 14
5 SRv6 Based Solution . . . . . . . . . . . . . . . . . . . . . . 15
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 SRV6 as Drop-In Alternative for GTP-U . . . . . . . . . . . 15
5.3 SRV6 as Drop-In GTP Replacement with TE . . . . . . . . . . 17
5.4 UPF Chaining with SRV6 . . . . . . . . . . . . . . . . . . . 18
5.5 SRV6 and Entropy . . . . . . . . . . . . . . . . . . . . . . 19
5.6 SRV6 and 5G Slicing . . . . . . . . . . . . . . . . . . . . 19
5.7 SRV6 and Lawful Interception in 5G . . . . . . . . . . . . . 20
5.8 SRV6 and Alternative Approaches to Advanced Mobility
Support . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.8.1 SRV6 and Locator/ID Separation Paradigm for N9
Interface . . . . . . . . . . . . . . . . . . . . . . . 20
5.8.2 Brief Overview of Locator-ID Separation . . . . . . . . 20
5.8.3 Locator-ID Separation via SRV6 for UPF connectivity . . 21
5.8.3.1 Overlay model with SRV6 Locators . . . . . . . . . . 21
5.8.3.2 SRV6 Capable UPFs and RLOCs . . . . . . . . . . . . 22
5.8.4 Advanced Features in ID-Locator Architecture . . . . . . 23
5.9 Areas of Concern . . . . . . . . . . . . . . . . . . . . . . 23
6 LISP based Solution . . . . . . . . . . . . . . . . . . . . . . 24
K. Bogineni Expires September 6, 2018 [Page 2]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.2 LISP Data-Plane . . . . . . . . . . . . . . . . . . . . . . 25
6.3 LISP Control-Plane . . . . . . . . . . . . . . . . . . . . . 25
6.4 LISP Mobility Features . . . . . . . . . . . . . . . . . . . 25
6.5 ILSR . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.6 LISP Control-Plane with ILA Data-Plane . . . . . . . . . . . 26
7 ILNP Based Solution . . . . . . . . . . . . . . . . . . . . . . 27
8 ILA based Solution . . . . . . . . . . . . . . . . . . . . . . 27
8.1 Overview of ILA . . . . . . . . . . . . . . . . . . . . . . 28
8.2 ILA in the 5G architecture . . . . . . . . . . . . . . . . . 29
8.3 Protocol layering . . . . . . . . . . . . . . . . . . . . . 31
8.4 Control plane . . . . . . . . . . . . . . . . . . . . . . . 32
8.4.1 ILA-M services interface . . . . . . . . . . . . . . . . 32
8.4.2 ILA control plane . . . . . . . . . . . . . . . . . . . 32
8.5 IP addressing . . . . . . . . . . . . . . . . . . . . . . . 33
8.5.1 Singleton address assignment . . . . . . . . . . . . . . 33
8.5.2 Network prefix assignment . . . . . . . . . . . . . . . 33
8.5.3 Strong privacy addresses . . . . . . . . . . . . . . . . 34
8.6 Traffic engineering . . . . . . . . . . . . . . . . . . . . 34
8.7 Locator Chaining with ILA . . . . . . . . . . . . . . . . . 35
8.8 ILA and network slices . . . . . . . . . . . . . . . . . . . 35
8.9 Security considerations . . . . . . . . . . . . . . . . . . 36
9 No Protocol Option . . . . . . . . . . . . . . . . . . . . . . 36
10 Comparison of Protocols . . . . . . . . . . . . . . . . . . . . 36
11 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
12 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 37
13 Security Considerations . . . . . . . . . . . . . . . . . . . . 37
14 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 37
15 References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
15.1 Normative References . . . . . . . . . . . . . . . . . . . 37
15.2 Informative References . . . . . . . . . . . . . . . . . . 37
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 38
K. Bogineni Expires September 6, 2018 [Page 3]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
1 Introduction and Problem Statement
3GPP CT4 WG has approved a study item [CT4SID] to study user-plane
protocol for N9 in 5GC architecture as specified in TS 23.501 [23501]
and TS 23.502 [23502] for Rel-15. This provides an opportunity to
investigate potential limits of the existing user plane solution and
potential benefits of alternative user plane solutions.
IETF has some protocols for potential consideration as candidates.
These protocols have the potential to simplify the architecture
through reduction/elimination of encapsulation; use of native routing
mechanisms; support of anchor-less mobility management; reduction of
session state and reduction of signaling associated with mobility
management.
This document comprehensively describes the various protocols and how
they can be used in the 3GPP 5G architecture. Specifically Segment
Routing v6 (SRv6), Locator Identifier Separation Protocol (LISP) and
Identifier Locator Addressing (ILA) are described in the context of
the 3GPP 5G architecture for several scenarios: as a replacement of
GTP on N9; as a replacement of GTP in the whole system; integrated
with transport; used in specific network slices, etc.
A comparison of the various protocols is also provided.
2 Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying significance described in RFC 2119.
In this document, the characters ">>" preceding an indented line(s)
indicates a statement using the key words listed above. This
convention aids reviewers in quickly identifying or finding the
portions of this RFC covered by these keywords.
3 Overview of Existing Architecture and Protocol Stack
This section briefly describes the 5G system architecture as
specified in 3GPP TS 23.501. The key relevant features for session
management and mobility management are:
K. Bogineni Expires September 6, 2018 [Page 4]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
- Separate the User Plane (UP) functions from the Control Plane
(CP) functions, allowing independent scalability, evolution and
flexible deployments e.g. centralized location or distributed
(remote) location.
- Support concurrent access to local and centralized services. To
support low latency services and access to local data networks,
UP functions can be deployed close to the Access Network.
- Support roaming with both Home routed traffic as well as Local
breakout traffic in the visited PLMN.
+------+ +------+ +------+
| NSSF | | AUSF +-N13-+ UDM |
+------+ +------+ +------+
| /
N22 N12 N8 N10
| /
+-+---+---+ +-------+ +------+ +-----+
+--------+ AMF +- N11 -+ SMF +- N7 -+ PCF +- N5 -+ AF |
| +-++-----++ +---+---+ +---+--+ +-----+
| || || | |
| || |+-----------|----- N15 ---+
N1 N2|+-N14-+ N4
| | |
+---+-+ ++-------+ +--+----+ +------+
| UE +- NR --+ (R)AN +-- N3 --+ UPF +-- N6 --+ DN |
+-----+ +--------+ ++-----++ +------+
| |
+--N9-+
Figure 1: 5G System Architecture in Reference Point Representation
K. Bogineni Expires September 6, 2018 [Page 5]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
Service Based Interfaces
----+-----+-----+----+----+----+----+--------+-----+--------
| | | | | | | | |
+---+---+ | +--+--+ | +--+--+ | +--+--+ +--+--+ |
| NSSF | | | NRF | | | DSF | | | UDM | | NEF | |
+-------+ | +-----+ | +-----+ | +-----+ +-----+ |
+---+----+ +--+--+ +---+--+ +-------------+--+
| AMF | | PCF | | AUSF | | SMF |
+---+--+-+ +-----+ +------+ +-+-----------+--+
N1 | | |
+-------+ | | N4 N4
| 5G UE |--+ | | |
+---+---+ N2 +-----+-+ +---+---+ +----+
| | +----N3------+ UPF +-N9--+ UPF +--N6--+ DN |
| | | ++----+-+ +-------+ +----+
| | | | |
| +---+------+-+ +-N9-+
+-----| gNB |
+------------+
Figure 2: 5G Services Based Architecture
The roaming architectures are depicted in the two figures below.
VPLMN | HPLMN
----------+-------+------+------+---- N32 -------+------+----
| | | | | | |
+--+--+ +-+-+ +--+--+ +-+-+ | +--+--+ +-+-+
| AMF | |PCF| | SMF | |AF | | | UDM | |PCF|
+-+-+-+ +---+ +--+--+ +---+ | +-----+ +---+
N1| | |
+-------+ | | N4 |
| 5G UE +-+ | | |
+---+---+ N2 +-----+--+ |
| | | | |
| +---+-+ +-+-+ +-+-+ +----+ |
+---| gNB |---|UPF|-N9-|UPF|--| DN | |
+-----+ +-+-+ +---+ +----+ |
Figure 3: Roaming 5G System architecture- local breakout scenario
K. Bogineni Expires September 6, 2018 [Page 6]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
VPLMN | HPLMN
----------+------+------+----- N32 --------+-------+------+-----+--
| | | | | | | |
+--+--+ +-+-+ +--+--+ | +--+--+ +--+--+ +-+-+ +-+-+
| AMF | |PCF| | SMF | | | SMF | | UDM | |PCF| |AF |
+-+-+-+ +---+ +--+--+ | +--+--+ +-----+ +---+ +---+
N1 | | | |
+-------+ | | | | |
| 5G UE |-+ | | | |
+---+---+ N2 N4 | N4
| | | |
| +-+---+ +--+--+ +--+--+ +----+
+-----| gNB |-----| UPF |-----N9------| UPF |------| DN |
+-----+ +--+--+ +-----+ +----+
Figure 4: Roaming 5G System architecture - home routed scenario
Figure 5 depicts the non-roaming architecture for UEs concurrently
accessing two (e.g. local and central) data networks using multiple
PDU Sessions, using the reference point representation. This figure
shows the architecture for multiple PDU Sessions where two SMFs are
selected for the two different PDU Sessions. However, each SMF may
also have the capability to control both a local and a central UPF
within a PDU Session.
Service Based Interfaces
---------+------------+------------------+----------------------
| | |
+--+--+ +--+--+ +--+--+
| AMF | | SMF | | SMF |
+--+-++ +--+--+ +--+--+
N1| | |
+-------+ | | N4 N4
| 5G UE |-+ | | |
+---+---+ N2 +--+--+ +----+ +-----------+
| | +---| UPF |----| DN | | |
| | | +-----+ +----+ | |
| +-+---+-+ +--+--+ +--+--+ +----+
+-----| gNB |--------------------| UPF |--N9-| UPF |--| DN |
+-------+ +-----+ +-----+ +----+
Figure 5: Non-roaming architecture for multiple PDU Sessions
K. Bogineni Expires September 6, 2018 [Page 7]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
Service Based Interfaces
---------+-----------------------+-----------------------
| |
+--+---+ +--+--+
| AMF | | SMF |
+--+-+-+ +--+--+
N1 | |
+-------+ | | +------+-------+
| 5G UE |-+ | | |
+---+---+ N2 N4 N4
| +-+---+ +--+--+ +--+--+ +----+
+-----| gNB |-------| UPF |----N9--| UPF |----| DN |
+-----+ +--+--+ +-----+ +----+
|
+--+--+
| DN |
+-----+
Figure 6: Non-roaming 5G System architecture for concurrent access
to two (e.g. local and central) data networks
(single PDU Session option)
Figure 6 depicts the non-roaming architecture in case concurrent
access to two (e.g. local and central) data networks is provided
within a single PDU Session.
The User plane function (UPF) is the function relevant to this
evaluation and the N9 interface between two UPFs [23501].
The User Plane Function (UPF) handles the user plane path of PDU
sessions. The UPF transmits the PDUs of the PDU session in a single
tunnel between 5GC and (R)AN. The UPF includes the following
functionality. Some or all of the UPF functionalities may be
supported in a single instance of a UPF. Not all of the UPF
functionalities are required to be supported in an instance of user
plane function of a Network Slice.
o Anchor point for Intra-/Inter-RAT mobility (when applicable)
o Sending and forwarding of one or more "end marker" to the source
NG-RAN node
o External PDU Session point of interconnect to Data Network.
o PDU session type: IPv4, IPv6, Ethernet, Unstructured (type of
PDU totally transparent to the 5GS)
o Activation and release of the UP connection of an PDU session,
K. Bogineni Expires September 6, 2018 [Page 8]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
upon UE transition between the CM-IDLE and CM-CONNECTED states
(i.e. activation and release of N3 tunnelling towards the access
network)
o Data forwarding between the SMF and the UE or DN, e.g. IP
address allocation or DN authorization during the establishment
of a PDU session
o Packet routing & forwarding (e.g. support of Uplink classifier
to route traffic flows to an instance of a data network, support
of Branching point to support IPv6 multi-homed PDU session)
o Branching Point to support routing of traffic flows of an IPv6
multi-homed PDU session to a data network, based on the source
Prefix of the PDU
o User Plane part of policy rule enforcement, e.g. Gating,
Redirection, Traffic steering)
o Uplink Classifier enforcement to support routing traffic flows
to a data network, e.g. based on the destination IP
address/Prefix of the UL PDU
o Lawful intercept (UP collection)
o Traffic usage reporting e.g. allowing SMF support for charging,
and/or allowing the SMF to initiate a CN initiated deactivation
of UP connection of an existing PDU session when the UPF detects
that the PDU Session has no user plane data activity for a
specified Inactivity period provided by the SMF
o QoS handling for user plane including:
- packet filtering, gating, UL/DL rate enforcement, UL/DL
Session-AMBR enforcement (with the Session-AMBR computed by
the UPF over the Averaging window provisioned over N4, see
subclause 5.7.3 of 3GPP TS 23.501), UL/DL Guaranteed Flow Bit
Rate (GFBR) enforcement, UL/DL Maximum Flow Bit Rate (MFBR)
enforcement, etc
- marking packets with the QoS Flow ID (QFI) in an encapsulation
header on N3 (the QoS flow is the finest granularity of QoS
differentiation in the PDU session)
- enabling/disabling reflective QoS activation via the User
Plane, i.e. marking DL packets with the Reflective QoS
Indication (RQI) in the encapsulation header on N3, for DL
packets matching a QoS Rule that contains an indication to
K. Bogineni Expires September 6, 2018 [Page 9]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
activate reflective QoS
o Uplink Traffic verification (SDF to QoS flow mapping, i.e.
checking that QFIs in the UL PDUs are aligned with the QoS Rules
provided to the UE or implicitly derived by the UE e.g. when
using reflective QoS)
o Transport level packet marking in the uplink and downlink, e.g.
based on 5QI and ARP of the associated QoS flow
o Packet Filter Set is used in the QoS rules or SDF template to
identify a QoS flow. The Packet Filter Set may contain packet
filters for the DL direction, the UL direction or packet filters
that are applicable to both directions.
o Downlink packet buffering and downlink data notification
triggering:
This includes the support and handling of the ARP priority of
QoS Flows over the N4 interface, to support priority mechanism:
- "For a UE that is not configured for priority treatment, upon
receiving the "N7 PDU-CAN Session Modification" message from
the PCF with an ARP priority level that is entitled for
priority use, the SMF sends an "N4 Session Modification
Request" to update the ARP for the Signalling QoS Flows, and
sends an "N11 SM Request with PDU Session Modification
Command" message to the AMF, as specified in clause 4.3.3.2 of
TS 23.502.
- "If an IP packet arrives at the UPF for a UE that is CM-IDLE
over a QoS Flow which has an ARP priority level value that is
entitled for priority use, delivery of priority indication
during the Paging procedure is provided by inclusion of the
ARP in the N4 interface "Downlink Data Notification" message,
as specified in clause 4.2.3.4 of TS 23.502."
o ARP proxying as specified in IETF RFC 1027 [53] and / or IPv6
Neighbour Solicitation Proxying as specified in IETF RFC 4861
[54] functionality for the Ethernet PDUs. The UPF responds to
the ARP and / or the IPv6 Neighbour Solicitation Request by
providing the MAC address corresponding to the IP address sent
in the request.
o Packet inspection (e.g. Application detection based on service
data flow template and the optional PFDs received from the SMF
in addition)
K. Bogineni Expires September 6, 2018 [Page 10]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
o Traffic detection capabilities
For IP PDU session type, the UPF traffic detection
capabilities may detect traffic using traffic pattern based
on at least any combination of:
PDU session
QFI
IP Packet Filter Set, comprising:
- Source/destination IP address or IPv6 network prefix
- Source / destination port number
- Protocol ID of the protocol above IP/Next header type
- Type of Service (TOS) (IPv4) / Traffic class (IPv6) and
Mask
- Flow Label (IPv6)
- Security parameter index
Application Identifier: The Application ID is an index to a
set of application detection rules configured in UPF
In the IP Packet Filter Set:
- a value left unspecified in a filter matches any value
of the corresponding information in a packet
- an IP address or Prefix may be combined with a prefix
mask
- port numbers may be specified as port ranges
For Ethernet PDU session type, the SMF may control UPF traffic
detection capabilities based on at least any combination of:
PDU session
QFI
Ethernet Packet Filter Set, comprising:
- Source/destination MAC address
- EtherType as defined in IEEE 802.3
- Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-
TAG) VID fields as defined in IEEE 802.1Q
- Customer-VLAN tag (C-TAG) and/or Service-VLAN tag (S-
TAG) PCP/DEI fields as defined in IEEE 802.1Q
- IP Packet Filter Set, in case Ethertype indicates
IPv4/IPv6 payload
o Network slicing Requirements for different MM mechanisms on
different slice.
The selection mechanism for SMF to select UPF based on the
selected network slice instance, DNN and other information e.g.
UE subscription and local operator policies.
The following information is sent in an encapsulation header over the
N3 interface. N9 needs to support that.
QFI (QoS Flow Identifier), see subclause 5.7.1 of 3GPP TS 23.501:
K. Bogineni Expires September 6, 2018 [Page 11]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
"A QoS Flow ID (QFI) is used to identify a QoS flow in the 5G
system. User Plane traffic with the same QFI within a PDU
session receives the same traffic forwarding treatment (e.g.
scheduling, admission threshold). The QFI is carried in an
encapsulation header on N3 (and N9) i.e. without any changes to
the e2e packet header. It can be applied to PDUs with different
types of payload, i.e. IP packets, non-IP PDUs and Ethernet
frames. The QFI shall be unique within a PDU session." The QFI
is sent for both downlink and uplink user plane traffic.
RQI (Reflective QoS Identifier), see subclause 5.7.5.4.2 of 3GPP TS
23.501:
"When the 5GC determines to activate reflective QoS via U-plane,
the SMF shall include a QoS rule including an indication to the
UPF via N4 interface to activate User Plane with user plane
reflective. When the UPF receives a DL packet matching the QoS
rule that contains an indication to activate reflective QoS, the
UPF shall include the RQI in the encapsulation header on N3
reference point. The UE creates a UE derived QoS rule when the UE
receives a DL packet with a RQI."
The RQI is sent for downlink user plane traffic only.
Support of RAN initiated QoS Flow mobility, when using Dual
connectivity, also requires the QFI to be sent within End Marker
packets. See subclause 5.11.1 of 3GPP TS 23.501 and subclause 4.14.1
of 3GPP TS 23.502 respectively:
" For some other PDU sessions of an UE: Direct the DL User Plane
traffic of some QoS flows of the PDU session to the Secondary
(respectively Master) RAN Node while the remaining QoS flows of
the PDU session are directed to the Master (respectively
Secondary) RAN Node. In this case there are, irrespective of the
number of QoS Flows, two N3 tunnel terminations at the RAN for
such PDU session."
" In order to assist the reordering function in the Master RAN
node and/or Secondary RAN node, for the QFIs that are switched
between Master RAN node and Secondary RAN node, the UPF sends one
or more "end marker" packets along with QFI on the old tunnel
immediately after switching the tunnel for the QFI. The UPF starts
sending downlink packets to the Target RAN."
GTPv1-U as defined in 3GPP TS 29.281 is used over the N3 and N9
interfaces in Release 15. Release 15 is still work-in-progress and
RAN3 will specify the contents of the 5GS Container. It is to be
decided whether CT4 needs to specify new GTP-U extension header(s) in
K. Bogineni Expires September 6, 2018 [Page 12]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
3GPP TS 29.281 for the 5GS Container.
A GTP-U tunnel is used per PDU session to encapsulate T-PDUs and GTP-
U signaling messages (e.g. End Marker, Echo Request, Error
Indication) between GTP-U peers.
A 5GS Container is defined as a new single GTP-U Extension Header
over the N3 and N9 interfaces and the elements are added to this
container as they appear with the forthcoming features and releases.
This approach would allow to design the 5GS information elements
independently from the tunneling protocol used within the 5GS, i.e.
it would achieve the separation of the Transport Network Layer (TNL)
and Radio Network Layer (RNL) as required in 3GPP TR 38.801 subclause
7.3.2. This would allow to not impact the RNL if in a future release
a new transport network layer (TNL) other than GTP-U/UDP/IP (e.g.
GRE/IP) was decided to be supported. The protocol stack for the User
Plane transport for a PDU session is depicted below in Figure 7.
+-----+ | | |
| App +---------------------|-----------------------|----------|
+-----+ | | +------+ |
| PDU +---------------------|-----------------------|-+ PDU | |
+-----+ +---------------+ | +-----------------+ | +------+ |
| | | /| | | /| | | | |
| | | Relay / | | | Relay / | | | | |
| | | / | | | / | | |5G UP | |
| AN | | --+-- | | | ---+--- | | | Enc | |
| Pro | |AN Pro | GTP-U +--|--+ GTP-U |5GUP Enc+--|-+ | |
| Lyrs| | Lyrs +-------+ | +--------+--------+ | +------+ |
| +--+ |UDP/IP +--|--+ UDP/IP | UDP/IP +--|-+UDP/IP| |
| | | +-------+ | +--------+--------+ | +------+ |
| | | | L2 +--|--+ L2 | L2 +--|-+ L2 | |
| | | +-------+ | +--------+--------+ | +------+ |
| | | | L1 +--|--+ L1 | L1 +--|-+ L1 | |
+-----+ +-------+-------+ | +--------+--------+ | +------+ |
UE AN N3 UPF N9 N6
UPF
(PDU Session Anchor)
Legend:
- PDU layer: This layer corresponds to the PDU carried between the
UE and the DN over the PDU session. When the PDU session Type is
IPV6, it corresponds to IPv6 packets; When the PDU session Type
is Ethernet, it corresponds to Ethernet frames; etc.
- GPRS Tunnelling Protocol for the user plane (GTP-U): This
protocol supports multiplexing traffic of different PDU sessions
(possibly corresponding to different PDU session Types) by
K. Bogineni Expires September 6, 2018 [Page 13]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
tunnelling user data over N3 (i.e. between the AN node and the
UPF) in the backbone network. GTP shall encapsulate all end user
PDUs. It provides encapsulation on a per PDU session level. This
layer carries also the marking associated with a QoS Flow.
- 5G Encapsulation: This layer supports multiplexing traffic of
different PDU sessions (possibly corresponding to different PDU
session Types) over N9 (i.e. between different UPF of the 5GC).
It provides encapsulation on a per PDU session level. This layer
carries also the marking associated with a QoS Flow.
Figure 7: User Plane Protocol Stack
4 Reference Scenario(s) for Evaluation
Different proposals will be described for the following scenarios:
1. Non-Roaming Scenarios
a. UE- Internet Connectivity (mobility cases)
b. UE-UE IP Packet Flow (mobility cases)
c. UE - 2 DNs with multiple PDU sessions
d. UE - 2 DNs single PDU session
2. Roaming Scenarios
a. Local Break out
b. Home routed
Flows will be provided for mobility cases (UE mobility, UPF mobility)
and session continuity cases (SSC Mode 1/2/3).
1. UE mobility SSC Mode 1
a. Single UPF
b. Multiple UPF
2. UE Mobility SSC Mode 2
a. Single UPF
b. Multiple UPF
3. UE Mobility SSC Mode 3
a. Single UPF
b. Multiple UPF
Each proposal will also describe how network slicing will be
supported for the following configurations:
o Support for independent slices using GTP and/or other protocol
will be covered. Mobility Management will be within each slice.
o Support for one UE connected to multiple slices using different
mobility protocols will be described.
K. Bogineni Expires September 6, 2018 [Page 14]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
The criteria for evaluation will be the ability to support the above
scenarios and identifying the impacts to N2, N3, N4, gNB, AMF and
SMF.
5 SRv6 Based Solution
5.1 Overview
Segment Routing (SR), defined in [I-D.ietf-spring-segment-routing]
generalises the source routing paradigm with an ordered list of
global and/or nodal instructions (segments) prepended in an SR header
in order to either steer traffic flows through the network while
confining flow states to the ingress nodes in the SR domains and/or
to indicate functions that are performed at specific network
locations.
The IPV6 realisation of SR (SRV6) defines a SR Header (SRH), see [I-
D.ietf-6man-segment-routing-header]. SRV6 encodes segments as IPV6
addresses in the Segment List (SL) of its header. The packet
destination address in SRV6 specifies the active segment while an
index field in the SRH points to the next active segment in the list.
The index field in SRH is decremented as SRV6 progressively forces
packet flows through different segments over the IPV6 data plane.
The versatility and adaptability of SR combined with IPV6's ample and
flexible address space positions SRV6 as a viable data path
technology for the next generation of mobile user plane, in
particular the 3GPP N9 (UPF to UPF).
This section starts by summarising the use of SRV6 as a drop-in
alternative for GTP-U over the N9 interface connecting different User
Plane Functions (UPF). It then shows how SRV6 as a GTP-U replacement
can then provide additional features such as TE, sparing, rate
limiting, and service chaining that are not natively available by
GTP.
The discussion then focuses on advanced routing with the
Identifier/Locator paradigm and shows how SRV6 can be used to realise
this model in the mobile back-haul in either an anchored or
anchorless mode of operation.
SRV6 appears well placed as a mechanism to replace GTP-U with
initially no control plane changes, but to then offer a progressive
path towards many innovations in routing.
5.2 SRV6 as Drop-In Alternative for GTP-U
Existing mobile back-haul employs GTP tunnels to carry user traffic
K. Bogineni Expires September 6, 2018 [Page 15]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
flows in the network. These tunnels are unidirectional, are
established via the control plane for a particular QoS level, and run
on links between access and the different anchor nodes all the way to
DN gateways. 3GPP uses the term UPF to refer to the variety of
functions performing different tasks on user traffic along the data
path in 5G networks and suggests the use of GTP tunnels to carry user
traffic between these UPFs (N9 interface).
The Tunnel Id (TEID) field in the GTP tunnel plays a crucial role in
stitching the data path between the above mentioned network nodes for
a particular user flow. In other words, TEIDs are used to coordinate
traffic hand off between different UPFs.
In its most basic form, SRV6 can be used as a simple drop-in
alternative for GTP tunnels. The control plane in this approach
remains the same, and still attempts to establish GTP-U tunnels and
communicate TEIDs between the tunnel end points. However, at the user
plane, SRV6 capable nodes use SIDs to direct user traffic between the
UPFs.
The simplest option is to encapsulate the entire GTP frame as a
payload within SRV6. However, this scheme still carries the GTP
header as the payload and as such doesn't offer significant
advantage.
A much more promising option however is to use SIDs to carry tunnel
related information. Here, TEIDs and other relevant data can be
encoded into SRV6 SIDs which can be mapped back to TEID's at the
intermediate UPFs thus requiring no changes except at the
encapsulation and de-encapsulation points in the UPF chains.
[I-D.ietf-dmm-srv6-mobile-uplane] discusses the details of leveraging
the existing control plane for distributing GTP tunnel information
between the end nodes and employing SRV6 in data plane for UPF
connectivity. The document defines a SID structure for conveying
TEID, DA, and SA of GTP tunnels, shows how hybrid IPV4/IPV6 networks
are supported by this model and in doing so, it paves a migration
path toward a full SRV6 data plane.
Another alternative that can provide for a smooth migration toward
SRV6 data plane between UPFs is via the use of "Tag", and optional
TLV fields in SRH. Similar to the previously described method, this
approach takes advantage of the existing control plane to deliver GTP
tunnel information to the UPF endpoints. "Tag" and optional TLV
fields in SRH are then used to encode tunnel information in the SRV6
data plane where the UPFs can determine the TEID etc. by inverting
the mapping.
K. Bogineni Expires September 6, 2018 [Page 16]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
In yet another option, GTP tunnel information can be encoded as a
separate SID either within the same SRH after the SID that identifies
the UPF itself (SRH-UPF)or inside a separate SRH (SRH-G). In this
option, SID representing the GTP tunnel information acts as both
start and end point of a segment within the UPF. This option
resembles the MPLS label stacking mechanism which is widely used in
different VPN scenarios.
It must be noted that in any of the above mentioned approaches, the
ingress UPF in SRV6 domain can insert a SRH containing the list of
SIDs that corresponds to all UPFs along the path. Alternatively, UPFs
can stack a new SRH on top of the one inserted by the previous one as
packets traverse network paths between different pairs of UPFs in the
network.
+-------+
+------+ SMF +------+
| +-------+ |
N4 N4
| |
+-------+ +---+---+ +---+---+ +-------+
| RAN |--N3--| UPF | | UPF |--N6--| DN |
+-------+ +---+---+ +---+---+ +-------+
| SRV6 N9 |
| carries GTP info. |
+---------------------+
Figure 8: SRV6 as Drop-In replacement for GTP-U in 5G
5.3 SRV6 as Drop-In GTP Replacement with TE
The previous section discussed using SRV6 as a drop-in replacement
for GTP tunnels in existing mobile networks. No new capabilities were
introduced by this simple 1 to 1 replacement. We now explore
additional possible features once SRV6 has been introduced.
Traffic engineering is an integral feature of SR. The SRV6 variant of
SR of course supports both strict and loose models of source routing.
Here, the SID list in SRH can represent a loose or strict path to
UPFs. Therefore, traffic engineering can easily be supported
regardless of any of the aforementioned approaches.
For loose paths to UPFs, a set of one or more SIDs in SRH's SID list
identifies on or more, but not all the intermediate nodes to a
particular UPF. Packets then follow the IGP shortest path through the
network to each specified intermediate node till they reach the
target UPF.
K. Bogineni Expires September 6, 2018 [Page 17]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
In the case of strict path to UPFs, SRH contains a set of SIDs
representing all the intermediate nodes and links that the packet
must visit on its route to a particular UPF. The last SID in the set
represents the target UPF itself or the last link to this UPF. Here,
SRV6 packet processing at each node invokes the function(s) that is
associated with SID[SL], the packet then receives the required
treatment and gets forwarded over the SRH's specified path toward the
target UPF.
It must be noted that the SRH could contain multiple sets of SIDs
each representing a TE path between a pair of UPFs. Alternatively,
the SRH can contain a fully resolved end to end TE path that covers
every intermediate node and UPF along the data plane.
SR considers segments to be instructions. Therefore each SID can
represent a function that enforces a specific nodal or global packet
treatment. Attributes such as jitter and delay requirement, rate
limiting factors, etc. can be easily encoded in to SIDs in order to
apply the desired treatment as packets traverse the network from UPF
to UPF. [I-D.ietf-dmm-srv6-mobile-uplane] suggests a SID encoding
mechanism for rate limiting purposes.
Please refer to the followings for further details about SR and SRV6
traffic engineering capabilities, network programming concept, and a
list of some of the main SR functions.
[I-D.ietf-spring-segment-routing]
[I-D.ietf-6man-segment-routing-header]
[I-D.filsfils-spring-srv6-network-programming].
[draft-gundavelli-dmm-mfa-00.txt]
5.4 UPF Chaining with SRV6
Service or function chaining is another intrinsic feature of SR and
its SRV6 derivative. Using this capability, operators can direct user
traffic through a set of UPFs where each UPF performs a specific task
or executes certain functions on the traffic.
UPF chaining is achieved through the use of SIDs in SRV6 in the
manner identical to what was described in the previous section
regarding SRV6 support for traffic engineering.
Generally speaking, the SRH is populated with a set of SIDs with each
SID identifying a specific UPF in the network. Starting from the
ingress SRV6 node, packets are then forwarded through the network in
K. Bogineni Expires September 6, 2018 [Page 18]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
either loose or explicit mode toward each UPF.
Please refer to [I-D.xuclad-spring-sr-service-chaining] for further
detail.
5.5 SRV6 and Entropy
Ability to provide a good level of entropy is an important aspect of
data plane protocols. The TEID field in GTP tunnels if included in
network node's hashing algorithms can result in good load balancing.
Therefore, any new data plane proposal should be able to deal with
entropy in an efficient manner.
SRV6 SIDs can easily accommodate entropy at either hop by hop or
global level via reserving a set of bits in the SID construct itself;
and hence, eliminate the need for a special entropy Segment ID in
SRH. Here, the hashing algorithm at different nodes distribute
traffic flows based on the SID which has been copied to IPV6 DA
field.
Alternatively, entropy related information can be encoded as optional
TLV field in SRV6's SRH.
5.6 SRV6 and 5G Slicing
Slicing is one of the main features in 5G [3GPP 23501]. Several
Slices with different requirements can coexist on top of the common
network infrastructure. Diverse flows belonging to different 5G
slices can be completely disjoint or can share different parts of the
network infrastructure. SRV6's native features such as TE, Chaining,
one-plus-one protection, etc. either in stand-alone or in conjunction
with other alternatives for mobility support such as ID-LOC model
lend themselves well to 5G slicing paradigm.
K. Bogineni Expires September 6, 2018 [Page 19]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
+--+ +--+
+----------------+N1| . . . |Nn+----------------+
| ++-+ +-++ |
| | | |
+---+---+ | | +---+---+
| UPF-1 | +------+ +------+ | UPF-2 |
+---+---+ | | +---+---+
| |
Slice-A | |
--------------------|-------------------------|----------------------
Slice-B | |
+----------+ +----------+
| |
+---+---+ +---+---+
| UPF-1'| | UPF-2'|
+---+---+ +---+---+
| +--+ +--+ |
+----------------+M1| . . . |Mn+----------------+
+--+ +--+
Figure 9: SRV6 TE, Service Chaining, Sparing, and
Protection for 5G Slices
5.7 SRV6 and Lawful Interception in 5G
To be filled.
5.8 SRV6 and Alternative Approaches to Advanced Mobility Support
SRV6 flexibility enables it to support different methods of providing
mobility in the network. ID-LOC for mobility support is one such
option.
5.8.1 SRV6 and Locator/ID Separation Paradigm for N9 Interface
The previous sections discussed how SRV6 could be employed as a
replacement for GTP tunnels while leaving the existing control plane
intact. This section describes the use of SRV6 as a vehicle to
implement Locator/ID Separation model for UPF data plane
connectivity.
5.8.2 Brief Overview of Locator-ID Separation
Traditional routing architecture uses IP addresses as both device
identity and its location in the network. Locator-ID Separation model
establishes a paradigm in which a device identity and its network
location are split into two separate namespaces: End-point
Identifiers (EID), and Route Locators (RLOC) that are correlated via
K. Bogineni Expires September 6, 2018 [Page 20]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
a control plane, or a dynamic (centralised or distributed) mapping
system.
RLOCs are tied to network topology. They represent network devices
that are reachable via traditional routing. EIDs, on the other hand,
represent mobile or stationary devices, functions, etc. that are
reachable via different RLOCs based on the network location where
they get instantiated, activated or moved.
Using this model, as long as EID-RLOC relationship remains up to
date, EIDs can easily move between the RLOCs. That is the EID
namespace can freely move without any impact to the routing paths and
connectivity between the Route Locators.
This type of multi encapsulation and routing has been employed in
fixed networks (IP, VPN, MPLS, etc.). The use of this paradigm in
mobile data plane, therefore, offers an approach that takes advantage
of a mature and proven technology to implement the N9 interface for
UPF connectivity.
5.8.3 Locator-ID Separation via SRV6 for UPF connectivity
SRV6 can easily implement ID-LOC Separation model for UPF
connectivity. The SIDs are once again the main vehicle here. In this
model, UPFs are considered to be the IDs while the nodes where the
UPFs attach to take on the role of the Locators. Multiple UPFs are
allowed to attach to the same Locator. It is also possible for a UPF
to connect to multiple Locators. There are several implementation
options. The followings highlights a few possibilities.
5.8.3.1 Overlay model with SRV6 Locators
In this approach, UPFs connect to SRV6 capable Locators. UPFs use
IPV4/IPV6 transport either in conjunction with GTP or without any GTP
tunnel and send the packets to their associated Locator at the near
end (Ingress SRV6 Locator).
In either case, the ingress SRV6 Locator uses the DA field in
arriving packets to identify the far end Locator (Egress SRV6
Locator) where the target UPF is attached and obtains its associated
SID.
For GTP encapsulated traffic from UPFs, the ingress SRV6 Locator must
also deliver GTP information to the far end Locator. Please see
section 5.2. for more information on different methods of conveying
GTP information in SRV6 domains.
The ingress SRV6 Locator then constructs the SRH and sends the
K. Bogineni Expires September 6, 2018 [Page 21]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
traffic through the SRV6 network toward the egress SRV6 Locator.
Egress Locator marks the end of the segment and ships the traffic to
the target UPF.
It must be noted that use of GTP at UPFs allows us to leave the 3GPP
control plane intact and hence provides a smooth migration path
toward SRV6 with ID-Locator model. For inter UPF traffic that doesn't
use GTP, the control plane requires some modifications in order to be
able to convey endpoint information to interested parties.
+----+----+
+----------N4--------+ SMF +--------N4--------+
| +----+----+ |
| |
| |
| +----+----+ |
| | ID-Loc | |
| +----->| Mapping |<----+ |
| | +----+----+ | |
| V V |
+---+---+ +----+----+ +----+----+ +---+---+
--N3-+ UPF-A +----+ RLOC-A +<---SRV6--->+ RLOC-B +---+ UPF-B +-N6--
+---+---+ +----+----+ +----+----+ +---+---+
<----------------------N9-GTP----------------------->
Figure 10: Overlay Model with SRV6 Locator in 5G
5.8.3.2 SRV6 Capable UPFs and RLOCs
In this model, the head end UPF (Ingress UPF) is the ingress node and
the entity that constructs the SRH in the SRV6 domain. Here, both
UPFs (IDs) and Locators are represented by SIDs in the SRH. The SID
list establishes either a partial or the full path to a target or a
set of UPFs that traffic is required to traverse.
The 3GPP control plane is responsible for distributing UPF's endpoint
information. But it requires some modifications to be able to convey
endpoint information to interested parties.
In its simplest form, the SMF using policy information prepares a set
of one or more UPFs along the traffic path and distributes this set
in the form a SID list to the ingress UPF. This SID list of UPFs is
then gets augmented with a set of SIDs identifying the Locators
representing the current point of attachment for each UPF along the
data path.
Alternatively, the SMF can provide a fully resolved SID list by
communicating with a centralised or distributed ID-LOC mapping system
containing all the relevant data regarding the UPF-Locator
K. Bogineni Expires September 6, 2018 [Page 22]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
relationship.
In yet another approach, the SMF can provide a partial SID list
representing the segment between each pair of UPFs to individual UPFs
along the path.
Regardless of the approach, any changes to UPF's point of attachment
must be reflected in the mapping system and communicated to the SMF
for distribution to the appropriate set of UPFs. Keeping the mapping
system current is essential to proper operation. As long as the
mapping database is up-to-date, UPFs can be easily moved in the
network. Design of ID-Locator mapping system is beyond the scope of
this document. However, experiment with distributed mapping systems
offered by today's public clouds has shown very promising results
which can be further improved and tailored to mobile network
requirements.
The following figure shows the use of SRV6 UPFs and RLOCs in 5G.
+----+----+
| ID-Loc |
+----->+ Mapping |
+----+----+ | | |
+ +<------+ +----+----+
| SMF |
+----------N4--------+ +--------N4--------+
| +----+----+ |
SID-UA | SID-RA SID-RB | SID-UB
+---+---+ +----+----+ +----+----+ +---+---+
--N3-+ UPF-A +-----+ RLOC-A +---------+ RLOC-B +-----+ UPF-B +-N6--
+---+---+ +----+----+ +----+----+ +---+---+
<---------------------N9-SRV6--------------------->
Figure 11: SRV6 Capable UPFs and Locators in 5G
5.8.4 Advanced Features in ID-Locator Architecture
SRV6's native features such as Traffic Engineering, QoS support, UPF
Chaining, etc. can be easily added to ID-Locator support. As it was
noted earlier, these features are not readily available by GTP.
5.9 Areas of Concern
Support for IPV6 is a precondition for SRV6. Although SRV6 can
support hybrid IPV4/IPV6 mobile data plane through an interworking
node, support of UPFs with IPV4 address is rather complex.
Due to IPV6 128-bit address space, large SRH size can have a negative
K. Bogineni Expires September 6, 2018 [Page 23]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
impact on MTU. Large SRH size can also exert undesirable header tax
especially in the case of small payload size. Furthermore, compound
SID processing at each node might affect line rate.
ID-LOC architecture relies on high performance mapping systems.
Distributed mapping systems using some form Distributed Hash
Table(DHT) exhibit very promising results. But further investigation
is required to ensure mobility requirements in mobile data plane.
6 LISP based Solution
+------------------------------------------------------+
| SMF |
+-+-----------+- - - - - - - - - - - - - +---+-------+-+
| | Mapping System | | |
| +--+----+---------------+--+ | |
N4 | | | N4 N4
| | LISP-CP | | |
| | | | | |
+--+---+ | | +------+ | | +---+--+
| UPF | | | | UPF +-------------+ | UPF |
--N3-+------+ | | +------+ | +------+-N6--
| XTR +--LISP-CP-+ +-+ XTR | +--LISP-CP-+ XTR |
+--+-+-+ +-+--+-+ +-+-+--+
| | | | | |
| +-------LISP-DP-------+ +--------LISP-DP------+ |
| |
+----------------------LISP-DP---------------------+
Figure 12: LISP in the 5G architecture
6.1 Overview
The Locator/Identifier Separation Protocol (LISP), which provides a
set of functions for routers to exchange information used to map from
Endpoint Identifiers (EIDs) that are not globally routable to
routable Routing Locators (RLOCs). It also defines a mechanism for
these LISP routers to encapsulate IP packets addressed with EIDs for
transmission across a network infrastructure that uses RLOCs for
routing and forwarding.
An introduction to LISP can be found in [I-D.ietf-lisp-introduction].
A complete RFC-set of specifications can be found in [RFC6830],
[RFC6831], [RFC6832], [RFC6833], [RFC6836], [RFC7215], [RFC8061],
[RFC.8111]. They describe support and mechanisms for all combinations
of inner and outer IPv4 and IPv6 packet headers for unicast and
multicast packet flows that also interwork with non-LISP sites as
K. Bogineni Expires September 6, 2018 [Page 24]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
well as two designs to realize a scalable mapping system.
A standards-track based set of drafts [I-D.ietf-lisp-rfc6830bis] [I-
D.ietf-lisp-rfc6833bis] are products and work in progress of the LISP
Working Group.
6.2 LISP Data-Plane
LISP uses dynamic tunnel encapsulation as its fundadmental mechanism
for the data-plane. Fixed headers are used between the outer and
inner IP headers which are 16 bytes in length. Details can be found
in[RFC6830].
6.3 LISP Control-Plane
Many years of research dating back to 2007 have gone into LISP
scalable mapping systems. They can be found at [LISP-WG] and [IRTF-
RRG]. The two that show promise and have deployment experience are
LISP-DDT [RFC8111] and LISP-ALT [RFC6836].
The control-plane API which LISP xTRs are the clients of is
documented in [RFC6833]. Various mapping system and control-plane
tools are available [RFC6835] [RFC8112] and are in operational use.
6.4 LISP Mobility Features
LISP supports multi-homed shortest-path session survivable mobility.
An EID can remain fixed for a node that roams while its dynamic
binding changes to the RLOCs it uses when it reconnect to the new
network location.
When the roaming node supports LISP, its EIDs and RLOCs are local to
the node. This form of mobility is call LISP Mobile-Node. Details can
be found in [I-D.ietf-lisp-mn].
When the roaming node does not support LISP, but LISP runs in the
network the node roams to, the EIDs and RLOCs are not co-located in
the same device. In this case, EIDs are assigned to the roaming node
and RLOCs are assigned to LISP xTRs. So when the roaming node
attaches to the network, its EIDs are mapped to the RLOCs of the LISP
xTRs in the network. This form of mobility is called LISP EID-
Mobility. Details can be found in [I-D.ietf-lisp-eid-mobility].
For a 3GGP mobile network, the LISP EID-Mobility form of mobility is
recommended and is specified in the use-case document [I-D.ietf-
farinacci-lisp-mobile-network].
K. Bogineni Expires September 6, 2018 [Page 25]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
6.5 ILSR
ILSR is a specific recommendation for using LISP in the 3GPP 5G
mobile network architecture. A detailed whitepaper can be found at
[ILSR-WP]. The recommendation is to use the mechanisms in [I-D.ietf-
farinacci-lisp-mobile-network].
6.6 LISP Control-Plane with ILA Data-Plane
In the LISP WG re-charter of 2016, consensus was reached to separate
the data-plane and control-plane aspects of the protocol. The current
LISP control-plane (LISP-CP) specification [I-D.ietf-lisp-rfc6833bis]
is data-plane agnostic and can serve as control-plane for different
data-plane protocols. In this section we describe how LISP-CP can
serve to enable the operation of an ILA data-plane. A similar
approach can be followed to use LISP-CP as control-plane for other
data-plane protocols (e.g. VXLAN, SRv6, etc).
+------------------------------------------------------+
| SMF |
+-+-----------+- - - - - - - - - - - - - +---+-------+-+
| | Mapping System | | |
| +--+----+---------------+--+ | |
N4 | | | N4 N4
| | LISP-CP | | |
| | | | | |
+--+---+ | | +------+ | | +---+--+
| UPF | | | | UPF +-------------+ | UPF |
--N3-+------+ | | +------+ | +------+-N6--
| XTR +--LISP-CP-+ +-+ XTR | +--LISP-CP-+ XTR |
+--+-+-+ +-+--+-+ +-+-+--+
| | | | | |
| +---------ILA---------+ +----------ILA--------+ |
| |
+------------------------ILA-----------------------+
Figure 13: LISP-CP + ILA in the 5G architecture
Please refer to Section 8 for description of the ILA data-plane. The
complete specification of how to use the LISP-CP in conjunction with
an ILA data-plane can be found in [I-D.rodrigueznatal-ila-lisp].
Below are summarized the major points to take into account when
running LISP-CP as control-plane for ILA.
o Leveraging on the flexible LISP-CP address encoding defined in
[RFC8060], different ILA address types are defined in [I-
D.rodrigueznatal-ila-lisp] to carry ILA metadata over the LISP-
CP.
K. Bogineni Expires September 6, 2018 [Page 26]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
o XTRs can serve as both ILA-Ns (when their map-cache is
incomplete) or ILA-Rs (when their map-cache is complete). XTRs
serving as ILA-Rs subscribe to the Mapping System to populate
their map-cache with all the mappings in the domain (or its
shard) using [I-D.rodrigueznatal-lisp-pubsub].
o LISP-CP can run over TCP or UDP. The same signaling and logic
applies independently of the transport. Additionally, when
running over TCP, the optimizations specified in [I-D. kouvelas-
lisp-map-server-reliable-transport] can be applied.
o The ILA control-plane operations "request/response" and "push"
are implemented via the LISP mechanisms defined in [I-D.ietf-
lisp-rfc6833bis] and [I-D.rodrigueznatal-lisp-pubsub]
respectively. When the Mapping System is co-located with the
XTRs serving as ILA-Rs, the ILA "redirect" operation is
implemented via the mapping notifications described in [I-
D.rodrigueznatal-lisp-pubsub].
o XTRs serving as ILA-Ns can use LISP-CP as described in [I-
D.ietf-lisp-rfc6833bis] to register and keep updated in the
Mapping System the information regarding their local mappings.
o When using ILA as data-plane, the mobility features and benefits
discussed in Section 8 and in [I-D.ietf-lisp-eid-mobility] still
apply.
o As discussed in [I-D.rodrigueznatal-ila-lisp], the LISP-CP can
be used not only to resolve ID-Loc mappings but also to obtain
the ILA Identifier when it is not possible to locally derivate
it from the endpoint address. These two mapping operations can
be combined into one to obtain the ILA Identifier and associated
locators in a single round of signaling.
7 ILNP Based Solution
<Text to be Included>.
8 ILA based Solution
Identifier-Locator Addressing [ILA] is a protocol to implement
transparent network overlays without encapsulation. It addresses the
need for network overlays in virtualization and mobility that are
efficient, lightweight, performant, scalable, secure, provide
seamless mobility, leverage and encourage use of IPv6, provide strong
privacy, are interoperable with existing infrastructure, applicable
to a variety of use cases, and have simplified control and
management.
K. Bogineni Expires September 6, 2018 [Page 27]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
8.1 Overview of ILA
ILA is a form of identifier/locator split where IPv6 addresses are
transformed from application-visible, non-topological "identifier"
addresses to topological "locator" addresses. Locator addresses allow
packets to be forwarded to the network location where a logical or
mobile node currently resides or is attached. Before delivery to the
ultimate destination, locator addresses are reverse transformed back
to the original application visible addresses. ILA does address
"transformation" as opposed to "translation" since address
modifications are always undone. ILA is conceptually similar to ILNP
and 8+8, however ILA is contained in the network layer. It is not
limited to end node deployment, does not require any changes to
transport layer protocols, and does not use extension headers.
ILA includes both a data plane and control plane. The data plane
defines the address structure and mechanisms for transforming
application visible identifier addresses to locator addresses. The
control plane's primary focus is a mapping system that includes a
database of identifier to locator mappings. This mapping database
drives ILA transformations. Control plane protocols disseminate
identifier to locator mappings amongst ILA nodes.
The use cases of ILA include mobile networks, datacenter
virtualization, and network virtualization. A recent trend in the
industry is to build converged networks containing all three of these
to provide low latency and high availability. A single network
overlay solution that works across multiple use cases is appealing.
Benefits of ILA include:
o Facilitates node mobility and virtualization
o Multiple use cases (mobile, datacenter, cloud)
o Super efficient and performant data plane
o Allows strong privacy in addressing [ADDRPRIV]
o Promotes anchorless mobility
o No typical tunneling issues (e.g. MTU) or management related to
encapsulation
o Flexible control plane that splits data & control
o Modern "SDN" control protocols (e.g. RPC/TCP)
K. Bogineni Expires September 6, 2018 [Page 28]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
o Scale number of nodes to billions for 5G, DC virtualization
o Upstream Linux kernel data path [ILAKERNEL] and open source ctrl
plane [ILACONTROL].
The ILA data plane protocol is described in [ILA], motivation and
problems areas are described in [ILAMOTIVE], ILA in the mobile user-
plane is described in detail in [ILAMOBILE].
8.2 ILA in the 5G architecture
ILA is a proposed alternative to GTP-U and encapsulation. It does not
require anchors and simplifies both the data plane and control plane.
ILA is a general network overlay protocol can be used to meet the
requirements of use cases in a converged network. User Plane
Functions (UPF) with ILA are lightweight and stateless such that they
can be brought up quickly as needed.
Figures 13 and 14 depict two architectural options for the use of ILA
in a 5G architecture. ILA is logically a network function and ILA
interfaces to the 5G control plane via service based interfaces. In
this architecture, ILA replaces GTP use over the N9 interface.
Identifier address to locator address transformations in the downlink
from the data network are done by an ILA-R. Transformations for intra
domain traffic can be done by an ILA-N close to the gNB or by an ILA-
R in the case of a cache miss. Locator address to identifier address
transformation happen at ILA-Ns. ILA could be supported on a gNB. In
this case, an ILA-N would be co- resident at a gNB and ILA is used
over N3 interface in lieu GTP-U. Figures 14 and 15 depict two options
of how ILA can be used in the 5G architecture. The control plane
functions can be implemented as standalone network functions or can
be implemented with other network functions. The control plane
protocol can be implemented as enhancement to N4, as APIs or as
independent protocol. Use of ILA in roaming scenarios is still TBD.
K. Bogineni Expires September 6, 2018 [Page 29]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
Service Based Interfaces
----+-----+-----+----+----+----+----+--------+-----+--------
| | | | | | | | |
+---+---+ | +--+--+ | +--+--+ | +--+--+ +--+--+ |
| NSSF | | | NRF | | | DSF | | | UDM | | NEF | |
+-------+ | +-----+ | +-----+ | +-----+ +-----+ |
| | | |
+---+----+ +--+--+ +---+--+ +-------------+--+
| AMF | | PCF | | AUSF | | ILA-M |
+---+--+-+ +-----+ +------+ +-+-----------+--+
+-------+ | | | |
| 5G UE |--+ | | |
+---+---+ | N2 +-----+----+ +---+---+ +----+
| | +------------| ILA-N |--| ILA-R |----| DN |
| | | N3 +-+---+--+-+ +-+-----+ +----+
| | | | | | |
| +---+------+-+ +---+ +------+
+-----| gNB | N9 N9
+------------+
Figure 14: ILA in 5G architecture - Option 1
Service Based Interfaces
----+-----+-----+----+----+----+------+----+----+----+--------+--
| | | | | | | | | | |
+---+---+ | +--+--+ | +--+--+ | | | | +--+--+ +--+--+
| NSSF | | | NRF | | | DSF | | | | | | UDM | | NEF |
+-------+ | +-----+ | +-----+ | | | | +-----+ +-----+
| | | | | |
+---+----+ +--+--+ +---+--+ | +--+--+ |
| AMF | | PCF | | AUSF | | |ILA-M| |
+---+--+-+ +-----+ +------+ | +--+--+ |
+-------+ | | | |
| 5G UE |--+ | | |
+---+---+ | N2 +----+--+ +---+---+ +----+
| | +------------| ILA-N |--| ILA-R |------| DN |
| | | N3 ++--+-+-+ +-+-----+ +----+
| | | | | | |
| +---+------+-+ +--+ +------+
+-----| gNB | N9 N9
+------------+
Figure 15: ILA in 5G architecture - Option 2
K. Bogineni Expires September 6, 2018 [Page 30]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
Service Based Interfaces
---------+-------+------------------+----------------------
| | |
+--+--+ +--+--+ +---+---+
| AMF | | SMF | | ILA-M |
+--+-++ +--+--+ +---+---+
N1| |
+-------+ | | +-------------+----+
| 5G UE |-+ | | |
+---+---+ N2 +---+---+ +----+ +-----------+
| | +--| ILAN/R|----| DN | | |
| | | +-------+ +----+ | |
| +-+---+-+ +--+--+ +--+--+ +----+
+-----| gNB |--------------------|ILAN |--N9-|ILAR |--| DN |
+-------+ +-----+ +-----+ +----+
Figure 16: Non-roaming ILA-based architecture for multiple PDU Sessions
Service Based Interfaces
---------+----------+------------+-----------
| | |
+--+---+ +--+--+ +---+---+
| AMF | | SMF | | ILA-M |
+--+-+-+ +--+--+ +---+---+
N1 | |
+-------+ | | +------+-------+
| 5G UE |-+ | | |
+---+---+ N2 | |
| +-+---+ +---+---+ +--+--+ +----+
+-----| gNB |------| ILAN/R|---N9--| ILAR|----| DN |
+-----+ +---+---+ +-----+ +----+
|
+--+--+
| DN |
+-----+
Figure 17: Non-roaming 5G ILA-based System architecture for concurrent
access to two (e.g. local and central) data networks
(single PDU Session option)
8.3 Protocol layering
Figure 3 illustrates the protocol layers of packets packets sent over
various data plane interfaces in the downlink direction of data
network to a mobile node. Note that this assumes the topology shown
in Figure 2 where GTP-U is used over N3 and ILA is used on N9.
K. Bogineni Expires September 6, 2018 [Page 31]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
---> ---> --->
DN to ILA-R ILA-R to ILA-N ILA-N to gNB gNB to UE
+------------+ +------------+ +------------+ +------------+
| Application| | Application| | Application| | Application|
+------------+ +------------+ +------------+ +------------+
| L4 | | L4 | | L4 | | L4 |
+------------+ +------------+ +------------+ +------------+
| IPv6 | | IPv6 (ILA) | | IPv6 | | PDU Layer |
+------------+ | +------------+ | +------------+ +------------+
| L2 | | | L2 | | | GTP-U | | AN Protocol|
+------------+ | +------------+ | +------------+ | Layers |
| | | UDP/IP | | |
N6 <--N9 --> N3 +------------+ +------------+
| L2 |
+------------+
Figure 18: ILA and protocol layer in 5G
8.4 Control plane
ILA-M provides the interface between the 5G services architecture and
the common ILA control plane.
8.4.1 ILA-M services interface
The control interface into ILA is via an ILA-M that interacts with 5G
network services. ILA-M uses RESTful APIs to make requests to network
services. An ILA-M receives notifications when devices enter the
network, leave it, or move within the network. The ILA-M writes the
ILA mapping entries accordingly.
ILA is a consumer of several 5G network services. The service
operations of interest to ILA are:
o Nudm (Unified Data Management): Provides subscriber information.
o Nsmf (Service Managment Function): Provides information about
PDU sessions.
o Namf (Core Access and Mobility Function): Provides notifications
of mobility events.
8.4.2 ILA control plane
The ILA control plane is composed of mapping protocols that manage
and disseminate information about the mapping database. There are two
levels of mapping protocols: one used by ILA routers that require the
full set of ILA mappings for a domain, and one used by ILA nodes that
maintain a caches of mappings.
K. Bogineni Expires September 6, 2018 [Page 32]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
The ILA mapping system is effectively a key/value datastore that maps
identifiers to locators. The protocol for sharing mapping information
amongst ILA routers can thus be implemented by a distributed database
[ILAMP]. ILA separates the control plane from the data plane, so
alternative control plane protocols may be used with a common data
plane [ILABGP],[ILALISP].
The ILA Mapping Protocol [ILAMP] is used between ILA forwarding nodes
and ILA mapping routers. The purpose of the protocol is to populate
and maintain the ILA mapping cache in forwarding nodes. ILAMP defines
redirects, a request/response protocol, and a push mechanism to
populate the mapping table. Unlike traditional routing protocols that
run over UDP, this protocol is intended to be run over TCP and may be
RPC oriented. TCP provides reliability, statefulness implied by
established connections, ordering, and security in the form of TLS.
Secure redirects are facilitated by the use of TCP. RPC facilities
such REST, Thrift, or GRPC leverage widely deployed models that are
popular in SDN.
8.5 IP addressing
ILA supports single address assignments as well as prefix
assignments. ILA will also support strong privacy in addressing
[ADDRPRIV].
8.5.1 Singleton address assignment
Singleton addresses can use a canonical 64/64 locator/identifier
split. Singleton addresses can be assigned by DHCPv6.
8.5.2 Network prefix assignment
Prefix assignment can be done via SLAAC or DHCPv6-PD.
To support /64 prefix assignment with ILA, the ILA identifier can be
encoded in the upper sixty-four bits of an address. A level of
indirection is used so that ILA transforms the upper sixty four bits
to contain both a locator and an index into a locator (ILA-N)
specific table. The entry in the table provides the original sixty-
four bit prefix so that locator to identifier address transformation
can be done.
As an example of this scheme, suppose network has a /24 prefix. The
identifier address format for /64 assignment might be:
K. Bogineni Expires September 6, 2018 [Page 33]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
| 24 bits | 40 bits | 64 bits |
+-------------+---------------------|------------------------------+
| Network | Identifier | IID |
+-------------+---------------------+------------------------------+
The IID part is arbitrarily assigned by the device, so that is
ignored by ILA. All routing, lookups, and transformations (excepting
checksum neutral mapping) are based on the upper sixty-four bits.
For identifier to locator address transformation, a lookup is done on
the upper sixty-four bits. That returns a value that contains a
locator and a locator table index. The resulting packet format may be
something like:
| 24 bits | 20 bits | 20 bits | 64 bits |
+-------------+---------------------|------------------------------+
| Network | Locator | Loc index | IID |
+-------------+---------+-----------+------------------------------+
The packet is forwarded and routed to the ILA-N addressed by locator
(/44 route in this case). At the ILA forwarding node, the locator
index is used as a key to an ILA-N specific table that returns a 40
bit Identifier. This value is then written in the packet do ILA to
identifier address transformation thereby restoring the original
destination address.
The locator index is not globally unique, it is specific to each ILA-
N. When a node attaches to an ILA-N, an index is chosen so that the
table is populated at the ILA-N and the ILA mapping includes the
locator and index. When a node detaches from on ILA, it's entry in
the table is removed and the index can be reused after a hold-down
period to allow stale mappings to be purged.
8.5.3 Strong privacy addresses
Note that when a /64 is assigned to UEs, the assigned prefix may
become a persistent identifier for a device. This is a potential
privacy issue. [ADDPRIV] describes this problem and suggests some
solutions that may be used with ILA.
8.6 Traffic engineering
ILA is primarily a mechanism for mobility and network virtualization.
Transport mechanisms for traffic engineering such as MPLS, network
slices, encapsulation, routing based on flow hash(flow label) can be
applied independently of ILA. This separation allows any discussion
related to transport to be left to operator deployment.
K. Bogineni Expires September 6, 2018 [Page 34]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
8.7 Locator Chaining with ILA
ILA transformations can be performed on a hop-by-hop bases. In this
manner a packet can be source routed through a sequence of nodes. At
each hop a determination is made as to the next hop the packet should
visit. The locator for the target is then written into the
destination. Eventually, the packet will be forwarded to an ILA
forwarding node that will restore the original address before
delivery to the final destination.
8.8 ILA and network slices
Figure 19 illustrates the use of network slices with ILA.
----+--------------------------------+--------------------
| |
+----------------------+ +------------------------+
| +-------+ Slice #1 | | +-----------+ Slice #2 |
| | SMF |----+ GTP | | | ILA-M |---+ ILA |
| +--+----+ | | | +---------+-+ | |
| N4 | | N4 | | | | | |
| +--+--+ +--+----+ | | +-------+ | +--+----+ | +----+
| | UPF | | UPF | | | | ILA-N | | | ILA-R | |---| DN |
| +-----+ +-------+ | | +-------+ | +-------+ | +----+
+------------ ---------+ +-----------|------------+
| |
+--+-+ +------------|-------------+
| DN | | | Slice #3 |
+----+ | +------+----+ ILA |
| | | |
| +-------+ +-------+ | +----+
+-----+ | | ILA-N | | ILA-R | |---| DN |
| MEC |--| +-------+ +-------+ | +----+
+-----+ +--------------------------+
Figure 19: ILA and network slices in 5G
In this figure, slice #1 illustrates legacy use of UPFs without ILA
in a slice. ILA can be deployed incrementally or in parts of the
network. As demonstrated, the use of network slices can provide
domain isolation for this.
Slice #2 supports ILA. Some number of ILA-Ns and ILA-Rs are deployed.
ILA transformations are performed over the N9 interface. ILA-Rs would
be deployed at the N6 interface to perform transformations on packets
received from a data network. ILA-Ns will be deployed deeper in the
network at one side of the N3 interface. ILA-Ns may be supplemented
by ILA-Rs that are deployed in the network. ILA-M manages the ILA
K. Bogineni Expires September 6, 2018 [Page 35]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
nodes and mapping database within the slice.
Slice #3 shows another slice that supports ILA. In this scenario, the
slice is for Mobile Edge Computing. The slice contains ILA-Rs and
ILA-Ns, and as illustrated, it may also contain ILA_Hs that run
directly on edge computing servers. Note in this example, one ILA-M,
and hence one ILA domain, is shared between slice #2 and slice #3.
Alternatively, the two slices could each have their own ILA-M and
define separate ILA domains.
8.9 Security considerations
A mobile public infrastructure has many considerations in security as
well as privacy. Fundamentally, a system must protect against
misdirection for the purposes of hijacking traffic, spoofing,
revealing user identities, exposing accurate geo-location, and Denial
of Service attacks on the infrastructure.
The ILA mapping system contains personally identifiable information
(PII) including user identities and geo-location. The information
must be safeguarded. An ILA domain is confined to one administrative
domain, only trusted parties entities in the domain participate in
ILA. There is no concept of a global, public mapping system and UEs
in public networks generally do not participate in ILA protocols
since they are untrusted. ILA control protocols, include ILA
redirects, use TCP. TLS or other protocols can be applied for strong
security.
Privacy in addressing is a consideration. ILA endeavors to provide a
mechanism of address assignment that prevents inference of user
identity or location. This problem is described in [ADDRPRIV].
9 No Protocol Option
In this option, mobility is handled nomadically by the app.
10 Comparison of Protocols
This section will compare the different protocols with reference to
how they will support the requirements for UPF and N9 interface; how
the various scenarios identified in Sections 3 and 4 will be
supported and impacts to other interfaces and functions of the
architecture (e.g. N3, N4, SMF, AMF, etc).
11 Summary
This document summarized the various IETF protocol options for GTP
replacement on N9 interface of 3GPP 5G architecture.
K. Bogineni Expires September 6, 2018 [Page 36]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
12 Formal Syntax The following syntax specification uses the augmented
Backus-Naur Form (BNF) as described in RFC-2234 [RFC2234].
<Define your formal syntax here.>
13 Security Considerations
<Add any security considerations>
14 IANA Considerations
<Add any IANA considerations>
15 References
15.1 Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
15.2 Informative References
[ILA] Herbert, T., and Lapukhov, P., "Identifier Locator
Addressing for IPv6" draft-herbert-intarea-ila-00
[ILAMP] Herbert, T., "Identifier Locator Addressing Mapping
Protocol" draft-herbert-ila-ilamp-00
[29891] 5G System - Phase 1, CT WG4 Aspects, 3GPP TR 29891 v15.0.0,
December 2017
[29244] Interface between the Control Plane and the User Plane
Nodes; Stage 3, 3GPP TS 29.244 v15.0.0, December 2017
[29281] GPRS Tunneling Protocol User Plane (GTPv1-U), 3GPP TS
29.281 v15.1.0, December 2017
[23501] System Architecture for 5G System; Stage 2, 3GPP TS 23.501
v2.0.1, December 2017
[23502] Procedures for 5G System; Stage 2, 3GPP TS 23.502, v2.0.0,
December 2017
[23503] Policy and Charging Control System for 5G Framework; Stage
2, 3GPP TS 23.503 v1.0.0, December 2017
[38300] NR and NG-RAN Overall Description: Stage 2, 3GPP TS 38.300
v2.0.0, December 2017
K. Bogineni Expires September 6, 2018 [Page 37]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
[38401] NG-RAN: Architecture Description, 3GPP TS 38.401 v1.0.0,
December 2017
[CT4SID] Study on User Plane Protocol in 5GC, 3GPP CP-173037,
December 2017
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, DOI
10.17487/RFC3513, April 2003, <https://www.rfc-
editor.org/info/rfc3513>.
[RFC4941] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices",
RFC 4641, DOI 10.17487/RFC4641, September 2006,
https://www.rfc-editor.org/info/rfc4641
[ILAGRPS] Herbert, T., "Identifier Groups in ILA", To be published
[BGPILA] Lapukhov, P., "Use of BGP for dissemination of ILA mapping
information" draft-lapukhov-bgp-ila-afi-02
[3GPPTS] 3rd Generation Partnership Project (3GPP), "3GPP TS
23.502", http://www.3gpp.org/DynaReport/23-series.htm
Acknowledgments
The author would like to thank Farooq Bari, Devaki Chandramouli, Ravi
Guntupalli, Sri Gundavelli, Peter Ashwood Smith, Satoru Matsushima,
Michael Mayer, Vina Ermagan, Fabio Maino, Albert Cabellos, and
Cameron Byrne for reviewing various iterations of the document and
for providing content into various sections.
Authors' Addresses
K. Bogineni Verizon
Email: kalyani.bogineni@verizon.com
A, Akhavain Huawei Technologies Canada
Email: arashmid.akhavain@huawei.com
T. Herbert Quantonium Email: tom@quantonium.net
D. Farinacci lispers.net Email: farinacci@gmail.com
A. Rodriguez-Natal Cisco
K. Bogineni Expires September 6, 2018 [Page 38]
INTERNET DRAFTdraft-bogineni-dmm-optimized-mobile-user-planeMarch 5, 2018
Email: natal@cisco.com
K. Bogineni Expires September 6, 2018 [Page 39]