< draft-hsblss-attic-ps-00.txt   draft-hsblss-attic-ps-01.txt >
Network Working Group D. von Hugo Network Working Group D. von Hugo
Internet-Draft Deutsche Telekom Internet-Draft Deutsche Telekom
Intended status: Informational B. Sarikaya Intended status: Informational B. Sarikaya
Expires: January 1, 2018 Huawei Expires: July 10, 2018 Huawei
S. Bhatti S. Bhatti
University of St. Andrews University of St. Andrews
M. Liebsch M. Liebsch
NEC NEC
R. Schott R. Schott
Deutsche Telekom Deutsche Telekom
S. Seo S. Seo
Korea Telekom Korea Telekom
June 30, 2017 January 10, 2018
Access Technology Independent Connectivity and Mobility Control Problem Access Technology Independent Connectivity and Mobility Control Problem
Statement Statement
draft-hsblss-attic-ps-00 draft-hsblss-attic-ps-01
Abstract Abstract
This document attempts to make the case for new work involving This document attempts to make the case for new work involving
possibly a framework and protocols that need to be developed to be possibly a framework and protocols that need to be developed to be
used among various virtualized functions and the end user which may used among various virtualized functions and the end user which may
be moving. First a set of functional requirements are developed and be moving. First a set of functional requirements are developed and
then these requirements are further elaborated in terms of potential then these requirements are further elaborated in terms of potential
engineering and design constraints. The need for the new work is engineering and design constraints. The need for the new work is
described next. described next.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 1, 2018. This Internet-Draft will expire on July 10, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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
skipping to change at page 2, line 42 skipping to change at page 2, line 42
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
12.1. Normative References . . . . . . . . . . . . . . . . . . 8 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 8 12.2. Informative References . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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 (see e.g. [METIS]). Such a network
terms of 5G project being undertaken worldwide is expected to meet if realized in terms of 5G projects being undertaken worldwide is
the stringent requirements discussed in expected to meet the stringent requirements discussed in
[I-D.vonhugo-5gangip-ip-issues]. [I-D.vonhugo-5gangip-ip-issues].
In this document a system architecture which is composed of In this document a system architecture which is composed of
modularised adaptable network functions of control plane and data modularised adaptable network functions of control plane and data
plane and their interconnections is assumed. Much of this plane and their interconnections is assumed. 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.
The system architecture we consider brings new set of functional The system architecture we consider brings new set of functional
skipping to change at page 4, line 36 skipping to change at page 4, line 36
o Mobility for hosts / end-systems. o Mobility for hosts / end-systems.
o Mobility for networks / sites / routers. o Mobility for networks / sites / routers.
o Multi-homing for hosts / end-systems, including support for multi- o Multi-homing for hosts / end-systems, including support for multi-
path transport. path transport.
o Multi-homing for networks / sites / routers. o Multi-homing for networks / sites / routers.
o
o Support for network virtualisation / network partitioning. o Support for network virtualisation / network partitioning.
5. Non-Functional Requirements 5. Non-Functional Requirements
Next, we discuss non-functional requirements involving potential Next, we discuss non-functional requirements involving potential
engineering design constraints. They arise mainly from the need to engineering design constraints. They arise mainly from the need to
increase resource usage efficiency by reducing signalling overhead increase resource usage efficiency by reducing signalling overhead
and allowing for traffic shaping according to capacity availability. and allowing for traffic shaping according to capacity availability.
o No use of tunnels, either layer 2 or layer 3. o No use of tunnels, either layer 2 or layer 3.
o No use of middle boxes, i.e. no proxies. Anchor points perform o No use of middle boxes, i.e. no proxies. Anchor points perform
important duties such as policy, accounting etc. as well as important duties such as policy, accounting etc. as well as
mapping that cannot be ignored. In anchor-less mobility, without mapping that cannot be ignored. In anchor-less mobility, without
anchor points, UE is the only common device in the path to perform anchor points, UE is the only common device in the path to perform
these functions. When anchors are removed then it becomes a these functions. When anchors are removed then it becomes a
challenge to provide functions like security and trust. One challenge to provide functions like security and trust. One
option is to use the UE as the only remaining single anchor point option is to use the UE as the only remaining single anchor point
to perform its own accounting and policy and other functions. to perform its own accounting and policy and other functions.
Such an approch however may create further implications to network Such an approach however may create further implications to
operators which to our knowledge have not yet been dealt with. network operators which to our knowledge have not yet been dealt
with.
o Support for end-to-end privacy and security. There are secure o Support for end-to-end privacy and security. There are secure
execution environments/processors in UE's these days, where all execution environments/processors in UE's these days, where all
the finger print recognition, password encryption etc. is done and the finger print recognition, password encryption etc. is done and
perhaps it is possible to extend these to run secure network perhaps it is possible to extend these to run secure network
functions. However, a trusted federation between any UE and the functions. However, a trusted federation between any UE and the
corresponding/accessible network entities cannot be assumed corresponding/accessible network entities cannot be assumed
without doubt in any case. In view of this, virtualizing and without doubt in any case. In view of this, virtualizing and
distributing anchor point functions, e.g. mapping identifiers to distributing anchor point functions, e.g. mapping identifiers to
the most recent locators, security associations (SA), etc. so they the most recent locators, security associations (SA), etc. so they
skipping to change at page 5, line 33 skipping to change at page 5, line 34
o Flexible addressing / numbering, e.g. distinguishing between o Flexible addressing / numbering, e.g. distinguishing between
globalised addressing as well as localised addressing. globalised addressing as well as localised addressing.
o An end-to-end model (in support to the above four requirements). o An end-to-end model (in support to the above four requirements).
o Support for current IPv6 addressing, e.g. /64 prefix assignment. o Support for current IPv6 addressing, e.g. /64 prefix assignment.
o Support for Identifier-Locator separation, e.g. as discussed in o Support for Identifier-Locator separation, e.g. as discussed in
[RFC6115]. [RFC6115].
o Ability to use for mapping between identifiers and adresses an o Ability to use for mapping between identifiers and addresses an
existing name resolution system (e.g. DNS), but also to make use existing name resolution system (e.g. DNS), but also to make use
of new/future systems, e.g. Dynamic Hash Tables (DHT) [RFC7363]. of new/future systems, e.g. Dynamic Hash Tables (DHT) [RFC7363].
o Backwards compatibility for existing applications, e.g. support of o Backwards compatibility for existing applications, e.g. support of
socket API so that binaries do not need to be recompiled. socket API so that binaries do not need to be recompiled.
o Incremental deployment, e.g. only need to update those hosts that o Incremental deployment, e.g. only need to update those hosts that
require new capability (this implies mixed operation, possibly require new capability (this implies mixed operation, possibly
dual-stack, within a network). dual-stack, within a network).
skipping to change at page 7, line 5 skipping to change at page 7, line 5
7. Goals 7. Goals
From the requirements set forward above we will derive the goals that From the requirements set forward above we will derive the goals that
need to be achieved. The goals of the work will involve: need to be achieved. The goals of the work will involve:
o Align with the identifier usage, e.g. 64-bit identifier for UE, o Align with the identifier usage, e.g. 64-bit identifier for UE,
e.g. International Mobile Subscriber Identity (IMSI) as well as e.g. International Mobile Subscriber Identity (IMSI) as well as
IPv6 prefix usage, single or multiple unique /64 prefixes IPv6 prefix usage, single or multiple unique /64 prefixes
o Propose solution approaches to deal with operational problems such
as charging or policy and QoS enforcement in a framework not
relying on tunneling and the information in tunnel headers
o Develop a framework involving mobility management without o Develop a framework involving mobility management without
tunneling, IP sessions for session continuity, handoff tunneling, IP sessions for session continuity, handoff
improvements, support for virtual network identifiers to be used improvements, support for virtual network identifiers to be used
by virtualized network functions in data centers, and support for by virtualized network functions in data centers, and support for
legacy servers legacy servers
o Define a version of the protocol that supports data center o Define a version of the protocol that supports data center
execution for intercommunication among control plane virtualized execution for intercommunication among control plane virtualized
network functions network functions
skipping to change at page 8, line 15 skipping to change at page 8, line 19
the identifiers not as part of the IP header should be considered, the identifiers not as part of the IP header should be considered,
e.g. in the handling of legacy hosts. e.g. in the handling of legacy hosts.
11. Acknowledgements 11. 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 in general on this work (including Comments, constructive criticisms in general on this work (including
previous versions) from Christian Huitema, Cameron Bynes, Lorenzo previous versions) from Christian Huitema, Cameron Bynes, Lorenzo
Colitti, Mikael Abrahamsson, David Lake, Samita Chakrabarti, Jouni Colitti, Mikael Abrahamsson, David Lake, Samita Chakrabarti, Jouni
Korhonen, Zhu Jing are respectfully acknowledged. Korhonen, Zhu Jing are respectfully acknowledged.
12. References 12. References
12.1. Normative References 12.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>.
12.2. Informative References 12.2. Informative References
[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-intarea-ila-00 (work
progress), March 2017. in progress), October 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.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
 End of changes. 12 change blocks. 
16 lines changed or deleted 19 lines changed or added

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