< draft-xyx-5gip-ps-00.txt   draft-xyx-5gip-ps-01.txt >
Network Working Group D. von Hugo Network Working Group D. von Hugo
Internet-Draft Deutsche Telekom - Technology Innovation Internet-Draft Deutsche Telekom
Intended status: Informational B. Sarikaya Intended status: Informational B. Sarikaya
Expires: November 3, 2017 Huawei Expires: November 23, 2017 Huawei
T. Herbert T. Herbert
Quantonium Quantonium
K. Satish K. Satish
Nokia Nokia
R. Schott R. Schott
Deutsche Telekom Deutsche Telekom
May 2, 2017 S. Seo
Korea Telekom
May 22, 2017
5G IP Access Mobility and Session Management Protocols 5G IP Access and Session Management Protocols
draft-xyx-5gip-ps-00 draft-xyx-5gip-ps-01
Abstract Abstract
This document builds upon 5G IP issues work and - based on a This document builds upon 5G IP issues work and - based on a
simplified 5G system architecture - attempts to make the case for a simplified 5G system architecture - attempts to make the case for a
possible set of new protocols that need to be developed to be used possible set of new protocols that need to be developed to be used
among various virtualized functions in a 5G network. among various virtualized functions in a 5G network.
Status of This Memo Status of This Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 3, 2017. This Internet-Draft will expire on November 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Converged Access-Agnostic Core Network . . . . . . . . . . . 3 3. Converged Access-Agnostic Core Network . . . . . . . . . . . 3
4. Access Management Protocols . . . . . . . . . . . . . . . . 6 4. Access Management Protocols . . . . . . . . . . . . . . . . 7
5. Mobility Management Protocols . . . . . . . . . . . . . . . . 8 5. Mobility Management Protocols . . . . . . . . . . . . . . . . 8
6. Session Management Protocols . . . . . . . . . . . . . . . . 9 6. Session Management Protocols . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Current networking infrastructure is moving towards a converged Current networking infrastructure is moving towards a converged
common core network serving wireline and wireless access networks to common core network serving wireline and wireless access networks to
which the end users are connected. Such a network if realized in which the end users are connected. Such a network if realized in
skipping to change at page 2, line 45 skipping to change at page 2, line 49
[I-D.vonhugo-5gangip-ip-issues]. [I-D.vonhugo-5gangip-ip-issues].
In this document we elaborate upon 5G system architecture which is In this document we elaborate upon 5G system architecture which is
composed of modularised adaptable network functions of control plane composed of modularised adaptable network functions of control plane
and data plane and their interconnections. Much of this and data plane and their interconnections. Much of this
functionality is expected to be implemented as virtualized functions functionality is expected to be implemented as virtualized functions
running in central and/or distributed computation environment (cloud) running in central and/or distributed computation environment (cloud)
as well as traditional physical entities in parallel. as well as traditional physical entities in parallel.
We discuss IP level protocols that need to be developed. The We discuss IP level protocols that need to be developed. The
discussion is based on and builds upon our existing documents on discussion is based on and builds upon existing documents on mobility
mobility management and access management. Identifier Locator management and access management. Identifier Locator Addressing
Addressing (ILA) protocol is designed as a data plane protocol for (ILA) protocol is designed as a data plane protocol for task
task communication and migration in L3 based data center networks communication and migration in L3 based data center networks
[I-D.herbert-nvo3-ila]. ILA can also be used in user mobility. This [I-D.herbert-nvo3-ila]. ILA can also be used in user mobility. This
aspect of ILA is investigated in [I-D.mueller-ila-mobility] by aspect of ILA is investigated in [I-D.mueller-ila-mobility] by
attempting to apply it directly to 4G 3GPP Evolved Packet System attempting to apply it directly to 4G 3GPP Evolved Packet System
(EPS). (EPS).
Regarding access management, a framework allowing clients and Regarding access management, a framework allowing clients and
networks in a multi-network scenario to negotiate combination of networks in a multi-network scenario to negotiate combination of
uplink and downlink paths taking into account client's application uplink and downlink paths taking into account client's application
needs and network conditions has been developed in needs and network conditions has been developed in
[I-D.kanugovi-intarea-mams-protocol]. A control plane protocol for [I-D.kanugovi-intarea-mams-protocol]. A control plane protocol for
configuring the user plane in a multi access management framework configuring the user plane in a multi access management framework
that can be used to flexibly select the combination of uplink and that can be used to flexibly select the combination of uplink and
downlink access and core network paths is described in downlink access and core network paths is described in
[I-D.zhu-intarea-mams-control-protocol]. A data plane protocol for [I-D.zhu-intarea-mams-control-protocol]. A data plane protocol for
multiplexing end to end connections is described in multiplexing end to end connections is described in
[I-D.zhu-intarea-mams-user-protocol] using trailer approach. [I-D.zhu-intarea-mams-user-protocol] using trailer approach, i.e. the
IP header of a Multi-Access (MX) PDU is extended by a newly defined
MX trailer containing data to indicate control procedures and
identities to support that multiple connections can be integrated
building up a single end-to-end connectivity.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Converged Access-Agnostic Core Network 3. Converged Access-Agnostic Core Network
Key principles and concepts in 5G system architecture include Key principles and concepts in 5G system architecture include
skipping to change at page 3, line 39 skipping to change at page 3, line 46
functions, allowing independent scalability, evolution, and a functions, allowing independent scalability, evolution, and a
flexible deployment at e.g. centralised location or distributed flexible deployment at e.g. centralised location or distributed
(remote) locations; the concept relies on a new definition of the (remote) locations; the concept relies on a new definition of the
network functions, e.g. to enable flexible and efficient provision of network functions, e.g. to enable flexible and efficient provision of
logically separated network slices. Network slicing with slice logically separated network slices. Network slicing with slice
instantiations that may include components served by fixed networks instantiations that may include components served by fixed networks
is another innovation in 3GPP 5G system architecture as well as the is another innovation in 3GPP 5G system architecture as well as the
definition of a common core network which is access agnostic. definition of a common core network which is access agnostic.
Wherever applicable, procedures (i.e. the set of interactions between Wherever applicable, procedures (i.e. the set of interactions between
network functions) are defined as services, so that their re-use is network functions) are defined as services, so that their re-use is
possible. Each Network Function can interact with the other NF possible. Each Network function (NF) can interact with the other NF
directly if required. The architecture does not preclude the use of directly if required. The architecture does not preclude the use of
an intermediate function to help route control plane messages. On an intermediate function to help route control plane messages. On
the other hand, the architecture shall be flexible enough to allow the other hand, the architecture shall be flexible enough to allow
for hassle-free introduction of newly specified network services if for hassle-free introduction of newly specified network services if
required by a specific network slice for a prospective new use case. required by a specific network slice for a prospective new use case.
Currently network infrastructure is being transformed into two-layer Currently network infrastructure is being transformed into two-layer
data center or cloud as Core Network (CN) and the Access Network (AN) data center or cloud as Core Network (CN) and the Access Network (AN)
which mainly accommodates 5G radio access network on the wireless which mainly accommodates 5G radio access network on the wireless
side and central office on the wireline network closer to the user. side and central office on the wireline network closer to the user.
skipping to change at page 4, line 16 skipping to change at page 4, line 23
cloud and distributed local edge clouds. cloud and distributed local edge clouds.
Especially for new ultra low latency services offering vehicular Especially for new ultra low latency services offering vehicular
communications a placement of both user data plane functions (e.g. communications a placement of both user data plane functions (e.g.
caches or anchors) and corresponding control plane tasks (e.g. caches or anchors) and corresponding control plane tasks (e.g.
activating and monitoring them) near the points of attachment (e.g. activating and monitoring them) near the points of attachment (e.g.
road side radio antennas) may be required. road side radio antennas) may be required.
These Network Function names as defined in current version of draft These Network Function names as defined in current version of draft
3GPP specifications are given here exemplarily and shall serve for 3GPP specifications are given here exemplarily and shall serve for
illustrative purposes. The final version of the architecture is illustrative purposes only. The final version of the architecture is
still under discussion. still under discussion.
5G system architecture is based on a complete system operation 5G system architecture is based on a complete system operation
including policy control, authentication, quality of service (QoS), including policy control, authentication, quality of service (QoS),
subscriber profiles and charging which are not of interest to us in subscriber profiles and charging which are not of interest to us in
this document. Based on this abstraction we can simplify the this document. Based on this abstraction we can simplify the
architecture with the elimination of the corresponding network architecture with the elimination of the corresponding network
functions and their interconnections. The resulting simplified functions and their interconnections. The resulting simplified
system architecture is shown in Figure 1. The rectangles are the system architecture is shown in Figure 1. The rectangles are the
network functions and the lines are their interconnections. Network network functions and the lines are their interconnections. Network
skipping to change at page 6, line 21 skipping to change at page 6, line 28
o Adopt the identifier locator addressing protocol which does not o Adopt the identifier locator addressing protocol which does not
involve tunneling for mobility management involve tunneling for mobility management
o Define address allocation function of the session management as o Define address allocation function of the session management as
part of the mobility management protocol part of the mobility management protocol
o Define session and service continuity as part of the session o Define session and service continuity as part of the session
management management
o 5G IoT. Addressing of large number of small IOT devices by way of
globally unique prefixes would be a challenge unless they are
considered local, possibly requiring some proxies and
encapsulation
One of the challenges in 5G FMC is how to provide seamless mobility 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 when 5G UE while in a 5G radio access network later moves to an area
of served by a Wi-Fi access point connected to a central office of served by a Wi-Fi access point connected to a central office
within the fixed network while both access networks are served by a within the fixed network while both access networks are served by a
converged common core. Another challenge is to enable flexible and converged common core. Another challenge is to enable flexible and
seamless management of the user sessions while accessing the network seamless management of the user sessions while accessing the network
sometimes simultaneously over UE's multiple interfaces, e.g. 5G and sometimes simultaneously over UE's multiple interfaces, e.g. 5G and
Wi-Fi. Wi-Fi.
In the next sections, we discuss access (Section 4) and mobility In the next sections, we discuss access (Section 4) and mobility
skipping to change at page 6, line 50 skipping to change at page 7, line 17
An investigation of multiple access management for a UE that An investigation of multiple access management for a UE that
simultaneously connects to multiple data networks is presented in simultaneously connects to multiple data networks is presented in
[I-D.kanugovi-intarea-mams-protocol]. [I-D.kanugovi-intarea-mams-protocol].
[I-D.kanugovi-intarea-mams-protocol] sets forward the requirements [I-D.kanugovi-intarea-mams-protocol] sets forward the requirements
such as enabling connectivity using different access networks. The such as enabling connectivity using different access networks. The
network path selection and user data distribution should work network path selection and user data distribution should work
transparently. Access path selection should be independent for transparently. Access path selection should be independent for
Uplink and Downlink. A common core network independent of the access Uplink and Downlink. A common core network independent of the access
networks should be accessed by the UE. Network path selection should networks should be accessed by the UE. Network path selection should
be adaptive to the link quality. Distribution and aggregation of be adaptive to the link quality implications on service specific
user data across multiple network paths at the IP layer should be performance requirements. Distribution and aggregation of user data
supported. Heterogeneous access networks, which may have different across multiple network paths at the IP layer should be supported.
MTU sizes should be supported using concatenation and fragmentation. Heterogeneous access networks, which may have different MTU sizes
should be supported using concatenation and fragmentation.
Based on these requirements, control and data plane functions for Based on these requirements, control and data plane functions for
connection management can be determined. Network Connection Manager connection management can be determined. Network Connection Manager
(NCM) is the control plane function. There is a data plane component (NCM) is the control plane function. There is a data plane component
for user data traffic forwarding called Network Multi-Access Data for user data traffic forwarding called Network Multi-Access Data
Proxy (MADP) which is part of the User Plane Function (UPF) in Proxy (MADP) which is part of the User Plane Function (UPF) in
Figure 1. It can be argued that we also need corresponding client Figure 1. It can be argued that we also need corresponding client
side counter part of NCM, called CCM and MADP hosted on the UE. side counter part of NCM, called CCM and MADP hosted on the UE.
Network Multi-Access Data Proxy (MADP), i.e. hosted in AMF in the Network Multi-Access Data Proxy (MADP), i.e. hosted in AMF in the
core network handles the user data traffic forwarding across multiple core network handles the user data traffic forwarding across multiple
skipping to change at page 7, line 46 skipping to change at page 8, line 13
network paths for transporting user data packets, link sounding and network paths for transporting user data packets, link sounding and
reporting to support adaptive network path selection by NCM. In the reporting to support adaptive network path selection by NCM. In the
downlink, for the user data received by UE, it configures IP layer downlink, for the user data received by UE, it configures IP layer
forwarding for application data packets received over any of the forwarding for application data packets received over any of the
accesses to reach the appropriate application module on the client. accesses to reach the appropriate application module on the client.
In the uplink, for the data transmitted by UE, it configures the 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 routing table to determine the best access to be used for uplink data
based on a combination of local policy and network policy delivered based on a combination of local policy and network policy delivered
by the NCM. by the NCM.
It should be noted that the access management approach still requires
future work involving consideration of 5G System Architecture
specifics and carrying out any changes needed correspondingly.
IP level protocols need to be developed supporting connection IP level protocols need to be developed supporting connection
management in a 5G IP network. An example is the trailer based management in a 5G IP network. An example is the trailer based
approach integrating multiple connections into a single end to end IP approach integrating multiple connections into a single end to end IP
connection. A multiplexing trailer is added to the end of IP payload connection. A multiplexing trailer is added to the end of IP payload
to flexibly support concatenation and fragmentation. to flexibly support concatenation and fragmentation.
[I-D.zhu-intarea-mams-user-protocol] details an approach, however
[I-D.zhu-intarea-mams-user-protocol] gives an earlier 4G approach,
there could possibly be other similar approaches. there could possibly be other similar approaches.
5. Mobility Management Protocols 5. Mobility Management Protocols
Next, we discuss mobility management. Anchor-less mobility in a 5G Next, we discuss mobility management. Anchor-less mobility in a 5G
fixed mobile convergence network with a converged core network fixed mobile convergence network with a converged core network
possibly based on identifier and locator separation should be the possibly based on identifier and locator separation should be the
preferred approach as opposed to tunneling approaches with fixed preferred approach as opposed to tunneling approaches with fixed
anchors, e.g. or with distributed anchors. anchors, e.g. or with distributed anchors.
skipping to change at page 9, line 11 skipping to change at page 9, line 29
Based on the requirements, Identifier Locator Addressing (ILA) Based on the requirements, Identifier Locator Addressing (ILA)
protocol [I-D.herbert-nvo3-ila] qualifies to be used as the base protocol [I-D.herbert-nvo3-ila] qualifies to be used as the base
protocol. IPv6 operation in the current ILA need to be improved in protocol. IPv6 operation in the current ILA need to be improved in
order to be used by the end nodes such as the UEs. Mobility order to be used by the end nodes such as the UEs. Mobility
procedures in the control plane need to be defined. ILA design is procedures in the control plane need to be defined. ILA design is
influenced by UE prefix/address allocation and management which is influenced by UE prefix/address allocation and management which is
part of Session Management function. Therefore the two functions part of Session Management function. Therefore the two functions
need to be designed in an integrated fashion. need to be designed in an integrated fashion.
Given the prefix assignment techniques to the UEs in effect, the base
protocol need to be modified and carrying the identifier as an
extension header similar to the segment routing header may need to be
considered. for communication with the legacy hosts such as the
servers encapsulation mode need to be developed involving the base
ILA encapsulated using the Generic UDP Encapsulation (GUE).
Multihoming, UEs with more than one network interfaces should be Multihoming, UEs with more than one network interfaces should be
supported including simultaneous usage of the interfaces to connect supported including simultaneous usage of the interfaces to connect
to multiple access networks. ILNP [RFC6740] supports multihoming. to multiple access networks. ILNP [RFC6740] supports multihoming.
ILA support could be similarly designed. ILA support could be similarly designed.
6. Session Management Protocols 6. Session Management Protocols
Session management responsible for the setup of the connectivity for Session management responsible for the setup of the connectivity for
the UE as well as managing the user plane for that connectivity is 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 identified as one of the key issues in 5G system architecture in
skipping to change at page 9, line 42 skipping to change at page 10, line 19
identifying the interactions between session management and the identifying the interactions between session management and the
mobility framework required to enable the various mobility scenarios mobility framework required to enable the various mobility scenarios
while minimizing any negative impact on the user experience while minimizing any negative impact on the user experience
investigating solutions to coordinate the relocation of user-plane investigating solutions to coordinate the relocation of user-plane
flows with the relocation of applications (hosted close to the point flows with the relocation of applications (hosted close to the point
of attachment of the UE) due to the mobility of users can be of attachment of the UE) due to the mobility of users can be
considered as the challenges of 5G architecture. considered as the challenges of 5G architecture.
Network layer or IP session normally has two components: source IP Network layer or IP session normally has two components: source IP
address and destination IP address. In case identifier locator address and destination IP address. In case identifier locator
separation protocol is used IP session has four components source separation protocol is used IP session has four components, i.e.
locator, source identifier, destination locator and destination source locator, source identifier, destination locator and
identifier. With transport layer independence IP session should be destination identifier. With transport layer independence IP session
composed of source identifier and destination identifier only. should be composed of source identifier and destination identifier
only.
Session management deals with IP address management. SMF performs IP Session management deals with IP address management. SMF performs IP
address allocation. Both IPv4 and IPv6 should be supported. In an address allocation. Both IPv4 and IPv6 should be supported. In an
identifier locator separation system, IPv4 can be supported identifier locator separation system, IPv4 can be supported
transparently by keeping the communication in IPv6 and converting the transparently by keeping the communication in IPv6 and converting the
addresses at the end points. addresses at the end points.
Session continuity in the case of UE mobility should be provided. In Session continuity in the case of UE mobility should be provided. In
an anchorless system, UE mobility incurs changes to the locators. an anchorless system, UE mobility incurs changes to the locators.
Session management should maintain the established sessions when the Session management should maintain the established sessions when the
skipping to change at page 10, line 35 skipping to change at page 11, line 13
network functions) seems to be inevitable in the framework of 5G the network functions) seems to be inevitable in the framework of 5G the
need for strong security measures in such an environment is a major need for strong security measures in such an environment is a major
challenge. challenge.
9. Privacy Considerations 9. Privacy Considerations
Support of full privacy of the users (customers and tenants / end Support of full privacy of the users (customers and tenants / end
service providers) is a basic feature of the next generation trusted service providers) is a basic feature of the next generation trusted
and reliable communications offering system. Such a high degree of and reliable communications offering system. Such a high degree of
ensured privacy shall be reflected in the proposed architecture and ensured privacy shall be reflected in the proposed architecture and
protocol solutions (details have to be added). protocol solutions.
Especially as Identifiers and mapping of locators to them are Especially as Identifiers and mapping of locators to them are
addressed the discussion on identifier and privacy should consider addressed some privacy concerns arise. Mobility solutions tend to
existing solutions such as 3GPP Globally Unique Temporary UE Identity expose unique identifiers. A solution inside the mobile network
(GUTI) which is a temporary identity obfuscating the permanent exposes these identifiers to the network operator, which is not a big
identity in the mobile network and specified in [TS23.003]. deal since the network operator already has information about the
device's location. In contrast, an IP level solution exposes both
the identifiers and the locations at the IP layer. That means that
web sites, for example, can now track the device's successive
locations by watching the IP address. Solutions such as transporting
the identifiers not as part of the IP header should be considered.
10. Acknowledgements 10. Acknowledgements
This work has been partially performed in the framework of the This work has been partially performed in the framework of the
cooperation Config. Contributions of the project partners are cooperation Config. Contributions of the project partners are
gratefully acknowledged. The project consortium is not liable for gratefully acknowledged. The project consortium is not liable for
any use that may be made of any of the information contained therein. any use that may be made of any of the information contained therein.
Comments, constructive critisms from Christian Huitema, Cameron
Bynes, Lorenzo Colitti, Saleem Bhatti, Mikael Abrahamsson, David
Lake, Samita Chakrabarti, Jouni Korhonen, Zhu Jing are respectfully
acknowledged.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
11.2. Informative References 11.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.
[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] [I-D.herbert-nvo3-ila]
Herbert, T. and P. Lapukhov, "Identifier-locator Herbert, T. and P. Lapukhov, "Identifier-locator
addressing for IPv6", draft-herbert-nvo3-ila-04 (work in addressing for IPv6", draft-herbert-nvo3-ila-04 (work in
progress), March 2017. progress), March 2017.
[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] [I-D.kanugovi-intarea-mams-protocol]
Kanugovi, S., Vasudevan, S., Baboescu, F., Zhu, J., Peng, Kanugovi, S., Vasudevan, S., Baboescu, F., Zhu, J., Peng,
S., Mueller, J., and S. Seo, "Multiple Access Management S., Mueller, J., and S. Seo, "Multiple Access Management
Services", draft-kanugovi-intarea-mams-protocol-04 (work Services", draft-kanugovi-intarea-mams-protocol-04 (work
in progress), March 2017. in progress), March 2017.
[I-D.mueller-ila-mobility] [I-D.mueller-ila-mobility]
Mueller, J. and T. Herbert, "Mobility Management Using Mueller, J. and T. Herbert, "Mobility Management Using
Identifier Locator Addressing", draft-mueller-ila- Identifier Locator Addressing", draft-mueller-ila-
mobility-03 (work in progress), February 2017. 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-02 (work in progress), April 2017.
[I-D.vonhugo-5gangip-ip-issues] [I-D.vonhugo-5gangip-ip-issues]
Hugo, D. and B. Sarikaya, "Review on issues in discussion Hugo, D. and B. Sarikaya, "Review on issues in discussion
of next generation converged networks (5G) from an IP of next generation converged networks (5G) from an IP
point of view", draft-vonhugo-5gangip-ip-issues-03 (work point of view", draft-vonhugo-5gangip-ip-issues-03 (work
in progress), March 2017. in progress), March 2017.
[I-D.zhu-intarea-mams-control-protocol] [I-D.zhu-intarea-mams-control-protocol]
Kanugovi, S., Vasudevan, S., Zhu, J., Baboescu, F., Peng, Kanugovi, S., Vasudevan, S., Zhu, J., Baboescu, F., Peng,
S., and S. Seo, "Control Plane Protocols and Procedures S., and S. Seo, "Control Plane Protocols and Procedures
for Multiple Access Management Services", draft-zhu- for Multiple Access Management Services", draft-zhu-
skipping to change at page 12, line 39 skipping to change at page 12, line 49
[M.2083] ITU-R, "Rec. ITU-R M.2083-0, IMT Vision-Framework and [M.2083] ITU-R, "Rec. ITU-R M.2083-0, IMT Vision-Framework and
overall objectives of the future development of IMT for overall objectives of the future development of IMT for
2020 and beyond", September 2015. 2020 and beyond", September 2015.
[METIS] Elayoubi, S. and et al., "5G Service Requirements and [METIS] Elayoubi, S. and et al., "5G Service Requirements and
Operational Use Cases: Analysis and METIS II Vision", Operational Use Cases: Analysis and METIS II Vision",
Proc. euCNC, 2016. Proc. euCNC, 2016.
[NGMN] NGMN Alliance, "NGMN White Paper", February 2015. [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>.
[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 [RFC6740] Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
Protocol (ILNP) Architectural Description", RFC 6740, Protocol (ILNP) Architectural Description", RFC 6740,
DOI 10.17487/RFC6740, November 2012, DOI 10.17487/RFC6740, November 2012,
<http://www.rfc-editor.org/info/rfc6740>. <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.501] [TR23.501]
"3GPP TR23.501, System Architecture for the 5G System "3GPP TR23.501, System Architecture for the 5G System
(Release 15)", December 2017. (Release 15)", December 2017.
[TR23.502] [TR23.502]
"3GPP TR23.502, Procedures for the 5G System (Release "3GPP TR23.502, Procedures for the 5G System (Release
15)", December 2017. 15)", December 2017.
[TR23.799] [TR23.799]
"3GPP TR23.799, Study on Architecture for Next Generation "3GPP TR23.799, Study on Architecture for Next Generation
System (Release 14)", December 2016. System (Release 14)", December 2016.
[TS23.003]
"3GPP TS23.003, Numbering, addressing and identification
(Release 14)", September 2016.
Authors' Addresses Authors' Addresses
Dirk von Hugo Dirk von Hugo
Deutsche Telekom - Technology Innovation Deutsche Telekom
Deutsche-Telekom-Allee 7 Deutsche-Telekom-Allee 7
D-64295 Darmstadt D-64295 Darmstadt
Germany Germany
Email: Dirk.von-Hugo@telekom.de Email: Dirk.von-Hugo@telekom.de
Behcet Sarikaya Behcet Sarikaya
Huawei Huawei
5340 Legacy Dr. 5340 Legacy Dr.
Plano, TX 75024 Plano, TX 75024
skipping to change at page 14, line 4 skipping to change at page 13, line 33
Germany Germany
Email: Dirk.von-Hugo@telekom.de Email: Dirk.von-Hugo@telekom.de
Behcet Sarikaya Behcet Sarikaya
Huawei Huawei
5340 Legacy Dr. 5340 Legacy Dr.
Plano, TX 75024 Plano, TX 75024
Email: sarikaya@ieee.org Email: sarikaya@ieee.org
Tom Herbert Tom Herbert
Quantonium Quantonium
Email: tom@herbertland.com Email: tom@herbertland.com
K Satish K Satish
Nokia Nokia
Email: satish.k@nokia.com Email: satish.k@nokia.com
Roland Schott Roland Schott
Deutsche Telekom Deutsche Telekom
Email: roland.schott@telekom.de Email: roland.schott@telekom.de
SungHoon Seo
Korea Telekom
Email: sh.seo@kt.com
 End of changes. 29 change blocks. 
79 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/