Subject: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

From: <[email-masked]>
Date: Wed, 3 May 2017 14:00:07 +0000

Dear all,
As announced yesterday we have uploaded the problem statement draft you find below.
Thanks for reading, discussing, commenting …!

Best Regards – also on behalf of all the authors

Behcet & Dirk

On Tue, May 2, 2017 at 4:25 PM, <[email-masked]<mailto:[email-masked]>> wrote:

A new version of I-D, draft-xyx-5gip-ps-00.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-xyx-5gip-ps
Revision:       00
Title:          5G IP Access Mobility and Session Management Protocols
Document date:  2017-05-02
Group:          Individual Submission
Pages:          14
URL:            https://www.ietf.org/internet-drafts/draft-xyx-5gip-ps-00.txt
Status:         https://datatracker.ietf.org/doc/draft-xyx-5gip-ps/
Htmlized:       https://tools.ietf.org/html/draft-xyx-5gip-ps-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-xyx-5gip-ps-00

Abstract:
   This document builds upon 5G IP issues work and - based on 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
   among various virtualized functions in a 5G network.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat

---

From: "Zhu, Jing Z" <[email-masked]>
Date: Wed, 3 May 2017 20:58:10 +0000

Hello Behcet and Dirk,

Thanks for the first draft. It looks pretty good. I just have a minor comment on the following sentence:  “[I-D.zhu-intarea-mams-user-protocol] gives an earlier 4G approach, ….” My understanding is that the trailer-based approach proposed in [I-D.zhu-intarea-mams-user-protocol] is generic, and not specific to any access technology. Maye we can change this paragraph to the following:
 IP level protocols need to be developed supporting connection  management in a 5G IP network.  An example is the trailer based approach [I-D.zhu-intarea-mams-user-protocol] integrating multiple connections into a single end to end IP connection.  A multiplexing trailer is added to the end of IP payload to flexibly support concatenation and fragmentation. gives an earlier 4G approach, There there could possibly be other similar approaches.
-Jing
From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, May 3, 2017 7:00 AM
To: [email-masked]
Subject: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Dear all,

Behcet & Dirk

Name:           draft-xyx-5gip-ps
Revision:       00

Abstract:

The IETF Secretariat

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 4 May 2017 19:39:30 +0900

Hi,

this draft mentions using ILA for mobility But ILA cannot be used as is for
UE addressing because ILA only supports mobility of individual IPv6
addresses, not prefixes. That contravenes IETF best practices for IPv6
address allocation, which say that networks should either allow hosts to
form IPv6 addresses at will, or to assign a /64 prefix to each host. See
RFC 7934.

All current 3G and 4G networks follow those best practices, because they
assign a /64 prefix to the UE. These are very widely deployed (hundreds of
millions of subscribers). We should ensure that 5G networks can do the same.

Cheers,
Lorenzo

On Wed, May 3, 2017 at 11:00 PM,  <[email-masked]> wrote:
> Dear all,
>
> As announced yesterday we have uploaded the problem statement draft you
find
> below.
> On Tue, May 2, 2017 at 4:25 PM, <[email-masked]> wrote:
>
>
> URL:
> https://www.ietf.org/internet-drafts/draft-xyx-5gip-ps-00.txt
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
>
>
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 4 May 2017 13:03:54 +0200 (CEST)

> Best Regards – also on behalf of all the authors

Thanks for writing this. My biggest goal with 5G has been simplification. 
I've been involved in running 3GPP networks for a long time, and they're 
hugely complicated and expensive.

>From my reading of this document, it seems that all traffic is still going 
to be tunneled, one way or another. It's good that the mobility functions 
is moved more towards the UE, because I imagine this will vastly simplify 
the network in between.

But why not take it one step further and only do access granting to the 
network resources, and then it's up to the UE to do whatever it 
wants/needs? Let's postulate that 90% of all traffic from devices is 
Internet traffic, and most of that is streaming video. If all network 
resources just is "IPv6 access to the Internet" as its primary service, 
then when the device connects (wifi, 5G, 4G, whatever), it gets IPv6 
Internet access. Access is granted based on a cryptographic signed token, 
where the token just is "my home network allowed me access to the network 
for X minutes". Then the base station, AP, whatever can just look at this 
token and grant access immediately without even talking to "core network". 
It just need to keep an updated list of cryptographic information to 
verify this token, or it needs to know where to verify it on demand.

Then you can (for instance) for streaming video, just start requesting 
video over this (new) connection. If it's MPTCP, just use that. When you 
need to hand over, just go to the new access method, attach, stop 
requesting data on the old one, start using the new address space. No 
handover is really needed. For traffic that needs handover, yes, you have 
to tunnel it using LISP, ILA, whatever (with the provision that Lorenzo 
pointed out, we need to have prefixes to be mobile, not individual 
addresses).

But my point here is, why tunnel most of the traffic, when most of the 
traffic actually doesn't need fast mobility? Most of the data on the 
Internet today is 1-2 seconds of streaming video, anyway. A lot of it can 
be pre-buffered, so having a few second outage during this "handover" 
(which isn't really a handover, just moving from one access to another) is 
no problem as far as I can see it.

If there is anything really broken with this idea, I'd like to understand 
why. Because I have pitched this idea in a few forums, and I've never 
heard why it wouldn't work and be a lot simpler than other proposals?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Ca By <[email-masked]>
Date: Thu, 04 May 2017 12:43:21 +0000

On Thu, May 4, 2017 at 3:39 AM Lorenzo Colitti <[email-masked]> wrote:

> Hi,
>
> this draft mentions using ILA for mobility But ILA cannot be used as is
> for UE addressing because ILA only supports mobility of individual IPv6

I fully agree with Lorenzo.  ILA does not have sufficient capabilities to
match GTP based mobility we have today. A step backwards is unacceptable.

It is also not clear how ILA would support slicing.  Being able to move the
mobility anchor / PPF dynamically will be a key component for many 5G
usecases.

Regards,
Cameron

> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-xyx-5gip-ps-00
> >
> >
> > Abstract:

---

From: Ca By <[email-masked]>
Date: Thu, 04 May 2017 12:56:28 +0000

On Thu, May 4, 2017 at 4:04 AM Mikael Abrahamsson <[email-masked]> wrote:

> find below.

It will work with existing network and 3gpp proposed 5G core. The key
concept is CUPS.

For the internet access use case you described, the PPF (PGW user plane in
5G) can exist at the cell site or somewhere close to the base station for
an internet access slice.  The 3GPP 5G generalizes these functions, and
because they are virtual, they can be instantiated at any arbitrary
location that make sense. Perhaps iot is a centralize public cloud for
least cost signaling  and perhaps vehicle to vehicle is terminated at the
base station for lowest latency.

3GPP already has this in the works afaik.

Cameron

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 4 May 2017 10:39:55 -0500

Hi Cameron,

Thanks for your constructive comments as always.
Please see inline.

On Thu, May 4, 2017 at 7:43 AM, Ca By <[email-masked]> wrote:

> match GTP based mobility we have today.
>

You mean ILA as in draft-herbert-nvo3-ila-04?
Absolutely.
As we describe in the PS, we need many revisions on that hopefully as part
of our 5G IP work.
Maybe the new protocol will need to be given a different name, not to
inherit all these comments :)

> A step backwards is unacceptable.
>
Sure.

>
> It is also not clear how ILA would support slicing.  Being able to move
> the mobility anchor / PPF dynamically will be a key component for many 5G
> usecases.
>
> You mean UPF? This is what we have in 5G architecture, yes it is
virtualized PGW.
Thanks for pointing the slicing issue, that is something we need to look
into.

Regards,

Behcet

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 5 May 2017 08:44:40 +0000

Good comments and I think we should rather talk about identifier-locator addressing as a principle not about a
particular specification at this point in time. Address re-write can be a suitable principle to steer traffic without the
need to encapsulate. I don’t see a problem applying the principle to both, per-host /64 and IPv6 addresses.

Btw, I see this as enabler to de-couple a serving anchor node from the actual IP address or per-host prefix
that it anchors. Traditionally the mobile device address/prefix is assigned from the anchor’s network (topologically
correct) hence serves as routable identifier up to the anchor node. Address/prefix re-write enables steering
downlink traffic to a new anchor node after anchor relocation (or anchor movement as pointed out below in
this eMail thread) in case IP address continuity is required by the device or its applications.

marco

From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Donnerstag, 4. Mai 2017 17:40
To: Ca By
Cc: [email-masked]; Lorenzo Colitti; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Hi Cameron,

On Thu, May 4, 2017 at 7:43 AM, Ca By <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, May 4, 2017 at 3:39 AM Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

this draft mentions using ILA for mobility But ILA cannot be used as is for UE addressing because ILA only supports mobility of individual IPv6 addresses, not prefixes. That contravenes IETF best practices for IPv6 address allocation, which say that networks should either allow hosts to form IPv6 addresses at will, or to assign a /64 prefix to each host. See RFC 7934.

All current 3G and 4G networks follow those best practices, because they assign a /64 prefix to the UE. These are very widely deployed (hundreds of millions of subscribers). We should ensure that 5G networks can do the same.

Cheers,
Lorenzo

I fully agree with Lorenzo.  ILA does not have sufficient capabilities to match GTP based mobility we have today.

You mean ILA as in draft-herbert-nvo3-ila-04?
Absolutely.
As we describe in the PS, we need many revisions on that hopefully as part of our 5G IP work.
Maybe the new protocol will need to be given a different name, not to inherit all these comments :)

It is also not clear how ILA would support slicing.  Being able to move the mobility anchor / PPF dynamically will be a key component for many 5G usecases.

You mean UPF? This is what we have in 5G architecture, yes it is virtualized PGW.
Thanks for pointing the slicing issue, that is something we need to look into.

Regards,

Behcet
Regards,
Cameron

On Wed, May 3, 2017 at 11:00 PM,  <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

---

From: <[email-masked]>
Date: Fri, 5 May 2017 08:46:01 +0000

Dear Cameron and Mikael,
Thanks a lot for your comments. We definitely have and want to simplify our approach for 5G – the described situation is IMO exactly what demands for slicing, i.e. a modular approach with complex and costly functionalities only for dedicated application driven logical sub-networks … whereas for a great deal of traffic the functions to be executed must be as simple as possible – and these functions at control plane level will steer and decide on the separate User Plane paths … with other words what CUPS is all about, right?

Whether 3GPP is really going for such utmost flexibility currently – that is … let’s say: questionable (IMHO)
;-/

Thanks and Best Regards
Dirk

From: Ca By [mailto:[email-masked]]
Sent: Donnerstag, 4. Mai 2017 14:56
To: von Hugo, Dirk; Mikael Abrahamsson
Cc: [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

On Thu, May 4, 2017 at 4:04 AM Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:

It will work with existing network and 3gpp proposed 5G core. The key concept is CUPS.

For the internet access use case you described, the PPF (PGW user plane in 5G) can exist at the cell site or somewhere close to the base station for an internet access slice.  The 3GPP 5G generalizes these functions, and because they are virtual, they can be instantiated at any arbitrary location that make sense. Perhaps iot is a centralize public cloud for least cost signaling  and perhaps vehicle to vehicle is terminated at the base station for lowest latency.

Cameron

--
Mikael Abrahamsson    email: [email-masked]<mailto:[email-masked]>_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip

---

From: <[email-masked]>
Date: Fri, 5 May 2017 14:13:37 +0000

Dear Marco, and all,

Thanks for all the valuable comments – regarding many addressing ILA we saw that we need to clarify more our scope as mentioned in the PS draft to work on access connectivity and session management in case of multiple technologies – while mobility is only one aspect of (but for many use cases can be kind of neglected). Thus we believe to address an issue not yet dealt with elsewhere in IETF in that detail.
And BTW from ILA we basically want to inherit the concept and principle but need to change a lot … as you already discussed here.
Thanks!
Best Regards
Dirk

From: 5gangip [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Freitag, 5. Mai 2017 10:45
To: [email-masked]; Ca By
Cc: [email-masked]; von Hugo, Dirk; Lorenzo Colitti
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

marco

From: 5gangip [mailto:[email-masked]] On Behalf Of Behcet Sarikaya
Sent: Donnerstag, 4. Mai 2017 17:40
To: Ca By
Cc: [email-masked]<mailto:[email-masked]>; Lorenzo Colitti; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Hi Cameron,

Cheers,
Lorenzo

Regards,

Behcet
Regards,
Cameron

---

From: Tom Herbert <[email-masked]>
Date: Fri, 5 May 2017 08:43:09 -0700

On Thu, May 4, 2017 at 5:56 AM, Ca By <[email-masked]> wrote:
> 5G) can exist at the cell site or somewhere close to the base station for an
> internet access slice.  The 3GPP 5G generalizes these functions, and because
> they are virtual, they can be instantiated at any arbitrary location that
> make sense. Perhaps iot is a centralize public cloud for least cost
> signaling  and perhaps vehicle to vehicle is terminated at the base station
> for lowest latency.
>

>From the introduction:

"Current networking infrastructure is moving towards a converged
common core network serving wireline and wireless access networks to
which the end users are connected."

The implication of this statement for mobility seems to be that we'd
want devices to be able to seamlessly move not between just different
cells of a carrier, but between different carriers, and even between
completely different access technologies (WIFI, 802.11p, 5G, etc.).
The underlying principle here is that this is a problem of IP layer
mobility and so it should be solved as a layer independent of the
technology. AFAICT GTP is very much tied to one technology.

ILA is a means to implement and access independent means of mobility
and is good for being transparent to the network, but it is limited to
amount of information it carry so it doesn't solve all problems.
Encapsulation is needed when the there is more information to carry.
Then question for encapsulation becomes what is the nature of that
encapsulation, how generic it is, how extensible is it, etc.

Tom

>> Mikael Abrahamsson    email:
>> [email-masked]
>> 5gangip mailing list
>> [email-masked]

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 5 May 2017 11:42:41 -0500

Hi Tom,

> technology. AFAICT GTP is very much tied to one technology.

Agreed.

> amount of information it carry so it doesn't solve all problems.

I think we should give a name to the new protocol, 5GILA (5gila) or Mobile
ILA (mila)?

> encapsulation, how generic it is, how extensible is it, etc.

The argument for encapsulation is so-called slice isolation. So that should
probably define the information to carry?

Regards,

Behcet

---

From: Tom Herbert <[email-masked]>
Date: Fri, 5 May 2017 17:50:51 -0700

> I think we should give a name to the new protocol, 5GILA (5gila) or Mobile
If the intent to work across different access technologies then 5G in
the name doesn't make sense. ILA is a specific thing that is not
encapsulation so that wouldn't work in the name either. Maybe
something like Generic IP Mobility Protocol (GIMP)? Or XIMP,
eXtensible IP mobility protocol?

> probably define the information to carry?
Are network slices logically any different that virtual networks. For
instance, in GUE we have a optional VNID to identify a virtual
(overlay) network the packet is sent on; could this indicate a slice
in in 5G?

Tom

---

From: Padmadevi Pillay Esnault <[email-masked]>
Date: Sat, 6 May 2017 18:24:38 +0000

FYI The work for a common control plane architecture across all identifier-locator protocols is underway in IDEAS.
Here is a pointer to the PS and it references to companion documents in section 10 as well.

ideas-problem-statement-01<https://tools.ietf.org/html/draft-padma-ideas-problem-statement-01>

I am also copying the IDEAS alias.

Thanks
Padma

From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, May 05, 2017 7:14 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Dear Marco, and all,

marco

Hi Cameron,

Cheers,
Lorenzo

Regards,

Behcet
Regards,
Cameron

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 8 May 2017 09:27:44 +0900

> inherit all these comments :)

Well, but the core idea of ILA (and ILNP before it) is to use half of the
IPv6 address for the locator, and half for the identifier. That's
fundamentally incompatible with using half of the bits the the leaf network
(i.e., the applications running on the MN and any other hosts behind it and
virtual machines inside it).

You could certainly use ILA to assign the MN a /128 and then run a tunnel
over that, but that's not really ILA any more: the A in ILA stands for
Addressing, and if the user IPv6 addresses are assigned to a tunnel, then
they're not ILA addresses.

---

From: Tom Herbert <[email-masked]>
Date: Sun, 7 May 2017 18:59:07 -0700

> they're not ILA addresses.
Right, if address assignment precludes ILA then that's where
encapsulation can be used.

I am trying to figure out how GTP-U works in practice. It's pretty
complicated complete, with flags, sequence numbers, a length, and
extension headers.

Version: 3 bits
PT: 1 bit
(*): 1 bit
E: 1 bit
S: 1 bit
PN: 1bit

Message Type: 1 octet
Length: 2 octet
TEID: 4 octets
Seq number: 2 octets
N-PDU Number: 1 octets
Next ext. header type: 1 octets

For a simple encapsulated IP datagram which fields are actually needed?

I would assume that message type is set to G-PDU, length is redundant
to UDP length, sequence number probably no present (not needed for IP
and if it's like GRE probably rarely used anyway), TEID is probably
meaningful I would assume, N-PDU is not meaningful. Are these correct
assumptions?

Tom

---

From: Jouni <[email-masked]>
Date: Sun, 7 May 2017 19:07:19 -0700

As a generic note it is always a good educational data point to check what happened to IETF PMIPv6 within 3GPP when it was pushed as an alternative to GTP.. If there is desire to meet the GTP  functionality it is quite a stretch for any mobility protocol/solution.

- Jouni 

> On 07 May 2017, at 18:59, Tom Herbert <[email-masked]> wrote:
>

---

From: Christian Huitema <[email-masked]>
Date: Sun, 7 May 2017 19:14:02 -0700

There is also a privacy angle there. Mobility solutions tend to expose unique identifiers. A solution inside the mobile network exposes these identifiers to the network operator, which is not a big 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. That does not feel like a very good tradeoff.

-- Christian Huitema 

> On May 7, 2017, at 7:07 PM, Jouni <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Mon, 8 May 2017 07:41:56 +0000

Hi all,

Although I agree that an introduction needs to be short I am wondering whether “data integrity” and “confidentiality” should be this close together without more explanation.

“As these communications will most likely be unmonitored, there are
   concerns regarding their discovery (privacy) , accessibility
   (possible breach) and data integrity (confidentiality).
"

How about changing that sentence to

“As these communications will most likely be unmonitored, there are
   concerns regarding their discovery (privacy) , accessibility
   (possible breach) and data protection (confidentiality, integrity).
”

Cheers
Axel

From: Ideas [mailto:[email-masked]] On Behalf Of Padmadevi Pillay Esnault
Sent: Saturday, May 06, 2017 8:25 PM
To: [email-masked]; [email-masked]
Cc: Padmadevi Pillay Esnault
Subject: Re: [Ideas] [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Thanks
Padma

From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Friday, May 05, 2017 7:14 AM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Dear Marco, and all,

From: 5gangip [mailto:[email-masked]] On Behalf Of Marco Liebsch
Sent: Freitag, 5. Mai 2017 10:45
To: [email-masked]<mailto:[email-masked]>; Ca By
Cc: [email-masked]<mailto:[email-masked]>; von Hugo, Dirk; Lorenzo Colitti
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

marco

Hi Cameron,

Cheers,
Lorenzo

Regards,

Behcet
Regards,
Cameron

---

From: Tom Herbert <[email-masked]>
Date: Mon, 8 May 2017 08:09:35 -0700

> There is also a privacy angle there. Mobility solutions tend to expose unique identifiers. A solution inside the mobile network exposes these identifiers to the network operator, which is not a big…
Hi Christian,

TCP connections are not persistent across address change so in order
to have a web site be able to communicate using exposed locality
information it would need to participate in the IP mobility protocol.
There is no feasible solution that would update all hosts on the
Internet to do that. Neither is there a feasible solution to even
update all UEs to support IP mobility. So an IP mobility solution
would be scoped within a mobile network or possibly between
cooperating networks, at the UE and hosts outside the network the
mobility is transparent.

OTOH, QUIC connections are persistent across address change by virtual
of the connection identifier. That is a very powerful property and
makes QUIC inherently mobile even without any support form the network
(I suppose that could be termed transport layer mobility). Do you know
how the security tracking problem is addressed for QUIC?

Tom

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 8 May 2017 18:03:47 +0000

Tom;

On 08 May 2017, at 16:09, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

On Sun, May 7, 2017 at 7:14 PM, Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:
There is also a privacy angle there. Mobility solutions tend to expose unique identifiers. A solution inside the mobile network exposes these identifiers to the network operator, which is not a big 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. That does not feel like a very good tradeoff.

Hi Christian,

TCP connections are not persistent across address change

That is not quite true for ILNP: TCP connections can persist across
location changes, even though the location is exposed to end-systems,
as the bits used to name the location are not-part of the end-to-end
state in ILNP (e.g. see results in [1]).

so in order

Agreed, though ILNP could permit an option that an ILNP-aware site-border
router or access router could re-write locator values so that the server
is not exposed to the locator change. Again, this would not impact the
end-to-end state as only the locator value would change (I am sure other
header bit-fiddling would be required, e.g. re-writing checksum values).

There is no feasible solution that would update all hosts on the
Internet to do that. Neither is there a feasible solution to even
update all UEs to support IP mobility.

I am not sure what you mean here.

If you mean that deploying a new end-system (host-based) solution is
not feasible, then I would disagree. Not a few days go by without one
of the devices (hosts) that I use experiencing some sort of update of
the OS or applications, that is automagically wafted out to me over
the interwebcloud.

If you mean something else, then my apologies.

So an IP mobility solution
would be scoped within a mobile network or possibly between
cooperating networks, at the UE and hosts outside the network the
mobility is transparent.

There are advantages and disadvantages to both host-based and network-based
solutions, in my view.

For example, if not updating end-hosts, or maintaining control of some
state "within  the network" (i.e. away from the end-host) is important for
some reason (e.g. operational requirements, inability to update end hosts,
signalling overhead to the end-systems, etc), then a purely host-based
approach  might not be desirable: a network-based or hybrid approach
might be better.

My guess is that it would really depend on what the 5G sys/net/ops folk see
as requirements in regards to end-systems and real operation of 5G systems -
that is something that, alas, I am somewhat clueless about at the current
time, and wish I knew more about.

I cannot comment on QUIC, but ILNP can support both location privacy and
identity privacy (please see section 10 of RFC6740, sections 7 and 8 of
RFC6748, and section IV.A of [2]).

Cheers,
--/Saleem

[1] IP without IP addresses. ACM AINTEC 2016. Nov/Dec 2016.
open access on ACM digital library: http://dx.doi.org/10.1145/3012695.3012701

[2] Integrating Challenged Networks. IEEE MILCOM2011. Nov 2011.
IEEEXplore: http://dx.doi.org/10.1109/MILCOM.2011.6127596
pre-print at: https://saleem.host.cs.st-andrews.ac.uk/publications/2011/milcom2011/milcom2011-bak2011.pdf

Tom

---

From: Christian Huitema <[email-masked]>
Date: Mon, 8 May 2017 11:15:49 -0700

> how the security tracking problem is addressed for QUIC?
Google's prototype used a single 64 bit connection ID to identify the
connection. This is very useful to deal with NAT that flush UDP mapping
after a rather small timeout. The next client client packet after the
timeout will use the new mapping, but the server will be able to link it
to the connection context using the connection ID. This also provides
linkability when the client moves to a new IP address, which is both
good because the connection stays on, and bad because third parties can
observe the connection ID and identify the client's movements. The QUIC
WG is actively working on a solution.

The dominant idea is that the client will obtain a set of "equivalent"
connection ID provided by the server. When the client moves to a new
address, t will pick one of yet unused connection ID provided by the
server. It will also insert a random gap in the sequence number. This
will still enable servers to maintain the connection, but will remove
the linkability hole.

There is an issue with that solution: it does not protect the client
privacy if the client is not aware of the address change, e.g. if the
client is sitting behind a "mobile Wi-Fi" router that would keep the
IPv4 address behind the NAT constant but change the IPv4 address used
for routing packets. But this is very difficult to address -- the client
would need to use a different connection ID for every packet, and also
to encrypt the packet sequence number. That's a fair bit of complexity,
and there might be simpler solutions, such as for example having
NAT/routers notify clients when the natted address changes. In IPv6, the
router gets a new delegated prefix when it moves, so the problem is solved.

-- Christian Huitema

---

From: Tom Herbert <[email-masked]>
Date: Mon, 8 May 2017 14:36:48 -0700

On Mon, May 8, 2017 at 11:03 AM, Saleem Bhatti <[email-masked]> wrote:
> Tom;
>
> On 08 May 2017, at 16:09, Tom Herbert <[email-masked]> wrote:
>
> There is also a privacy angle there. Mobility solutions tend to expose
> unique identifiers. A solution inside the mobile network exposes these
> identifiers to the network operator, which is not a big 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. That
> does not feel like a very good tradeoff.
>
> Hi Christian,
>
AFAIK ILNP requires significant changes to transport and network
layers at end hosts.

> the OS or applications, that is automagically wafted out to me over
It's not just a matter of updating the OS, these things also have been
to be enabled-- this is at the whim of the OS vendors. For instance,
TCP Fast Open (TFO) was invented by my team while I was at Google and
put into Linux more than five years ago. Only now is it being enabled
in Android. That was a feature that we did in the in the same company
that owned the OS and it was still incredibly difficult to get it
enabled. Beyond that there are multiple OS vendors (Windows, IOS,
etc.) that have to be dealt with. What I mean is that it's going to be
a much shorter path to implement mobility if it is done completely
within the mobile infrastructure without external dependencies on
devices a carrier can't control.

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 May 2017 16:37:50 -0500

> millions of subscribers). We should ensure that 5G networks can do the same.
How about using something like ILNPv4 (RFC 6746), i.e use 64 bit prefix
assigned to the host but keep the identifier in an extension header?

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 8 May 2017 16:42:27 -0500

On Thu, May 4, 2017 at 6:03 AM, Mikael Abrahamsson <[email-masked]> wrote:

> It just need to keep an updated list of cryptographic information to verify
> this token, or it needs to know where to verify it on demand.
>
> why. Because I have pitched this idea in a few forums, and I've never heard
> why it wouldn't work and be a lot simpler than other proposals?
>
>
Thanks Mikael.

Do you have a draft on this that we can consider? Or any volunteers to
write something quick?

Regards,

Behcet

---

From: Saleem Bhatti <[email-masked]>
Date: Mon, 8 May 2017 22:08:51 +0000

Tom;

> On 08 May 2017, at 22:36, Tom Herbert <[email-masked]> wrote:
> 

There are network layer changes which I agree are significant, but not a
complete rewrite: code can be added to the existing packet processing
paths for IPv6 to implement ILNPv6, for example.

The transport layer changes are not as significant.

(All end hosts wanting to use ILNP would need to be updated, as we have
already discussed.)

> enabled.

TFO is an optimisation enhancement, so could be considered optional (TCP
can work without TFO). 

What we are discussing here, as far as I can tell, is possible core
functionality. Whatever is agreed (be it ILA, ILNP or something  else),
would be *required*.

So, there would be different imperatives for getting it deployed.

> Beyond that there are multiple OS vendors (Windows, IOS,
> etc.) that have to be dealt with.

Agreed - that would be a challenge (though, see my comment above
about imperatives).

> What I mean is that it's going to be
> within the mobile infrastructure

Quite possibly - an operator would probably have a better idea about
this than I would.

> without external dependencies on

Moving from 3G to 4G, end-systems had to change. The same is likely
to be true in moving from 4G to 5G. So, if we take the argument that
end-systems will likely have to change anyway, then perhaps updating
the end-system software is not such a major issue.

Cheers,
--/Saleem

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 9 May 2017 20:51:39 +0000

Hi Mikael,

        > But my point here is, why tunnel most of the traffic, when most of the traffic actually doesn't need fast mobility? Most of the data on the Internet today is 1-2 seconds of streaming video, anyway.

I am writing this and not to argue  about tunnel/not-to-tunnel but to indicate that,  assumption can be wrong with regards to fast mobility in 5G - as lot of M2M  communication can go on 5G connection.

               > A lot of it can be pre-buffered, so having a few second outage during this "handover" (which isn't really a handover, just moving from one access to another) is no problem as far as I can see it.

Any solution with outage would be a non-starter for 3GPP AFAICT.
Change of IP address can happen in both i.e.,  same/different access but solution space for same access HO should absolutely be transparent for  lot of machine critical applications on 5G (would be 5G).

Not sure any traffic based solution (for video in this case) would increase complexity from overall  solution pov.
But it's good to see your thoughts overall but not in 2 concise paragraphs as below.

--
Uma C.

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Thursday, May 04, 2017 4:04 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Thanks for writing this. My biggest goal with 5G has been simplification.
I've been involved in running 3GPP networks for a long time, and they're hugely complicated and expensive.

>From my reading of this document, it seems that all traffic is still
to be tunneled, one way or another. It's good that the mobility functions is moved more towards the UE, because I imagine this will vastly simplify the network in between.

But why not take it one step further and only do access granting to the network resources, and then it's up to the UE to do whatever it wants/needs? Let's postulate that 90% of all traffic from devices is Internet traffic, and most of that is streaming video. If all network resources just is "IPv6 access to the Internet" as its primary service, then when the device connects (wifi, 5G, 4G, whatever), it gets IPv6 Internet access. Access is granted based on a cryptographic signed token, where the token just is "my home network allowed me access to the network for X minutes". Then the base station, AP, whatever can just look at this token and grant access immediately without even talking to "core network".
It just need to keep an updated list of cryptographic information to verify this token, or it needs to know where to verify it on demand.

Then you can (for instance) for streaming video, just start requesting video over this (new) connection. If it's MPTCP, just use that. When you need to hand over, just go to the new access method, attach, stop requesting data on the old one, start using the new address space. No handover is really needed. For traffic that needs handover, yes, you have to tunnel it using LISP, ILA, whatever (with the provision that Lorenzo pointed out, we need to have prefixes to be mobile, not individual addresses).

But my point here is, why tunnel most of the traffic, when most of the traffic actually doesn't need fast mobility? Most of the data on the Internet today is 1-2 seconds of streaming video, anyway. A lot of it can be pre-buffered, so having a few second outage during this "handover"
(which isn't really a handover, just moving from one access to another) is no problem as far as I can see it.

If there is anything really broken with this idea, I'd like to understand why. Because I have pitched this idea in a few forums, and I've never heard why it wouldn't work and be a lot simpler than other proposals?

---

From: Uma Chunduri <[email-masked]>
Date: Tue, 9 May 2017 20:56:10 +0000

In-line [Uma]:

--
Uma C.

On Thu, May 4, 2017 at 5:39 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

How about using something like ILNPv4 (RFC 6746), i.e use 64 bit prefix assigned to the host but keep the identifier in an extension header?

[Uma]:  Not sure if https://tools.ietf.org/html/draft-ietf-lisp-mn-00 has been discussed. I see it has IPv6 support from beginning..

---

From: Tom Herbert <[email-masked]>
Date: Tue, 9 May 2017 14:28:02 -0700

On Tue, May 9, 2017 at 1:56 PM, Uma Chunduri <[email-masked]> wrote:
> form IPv6 addresses at will, or to assign a /64 prefix to each host. See RFC
> 7934.
>
Extension headers are end to end constructs and there is no obvious
way to limit their scope to a single network (there is a long ongoing
discussion about whether they can be inserted by intermediate nodes
but the camp that wants that doesn't seem likely prevail). Besides
that there is a good chance of packets with extension headers being
dropped. Encapsulation is straightforward, can be significantly
contained, isn't that much more overhead, and allows the option of
other features for the encapsulation (security, fragmentation,
checksum help, etc. like in draft-herbert-gue-extensions).

Tom

>
>
>
>
> [Uma]:  Not sure if https://tools.ietf.org/html/draft-ietf-lisp-mn-00 has
> been discussed. I see it has IPv6 support from beginning..
>
>

---

From: jouni korhonen <[email-masked]>
Date: Tue, 9 May 2017 18:16:00 -0700

One more point here regarding the mobility solution. The PDU Session mobility has to provide connectivity & mobility between the UE and the data network for session types of IP, Ethernet or unstructured (i.e. whatever). IP only solution is not enough.

- Jouni

> On May 7, 2017, at 6:59 PM, Tom Herbert <[email-masked]> wrote:
>

---

From: <[email-masked]>
Date: Wed, 10 May 2017 10:49:25 +0000

When discussing mobility, it needs to be remembered that delay/loss intolerant applications such as VoLTE rely on the static architecture (fixed length GTP tunnels which "pivot" to give the impression of mobility but where the UE and destinations do not re-bind) to effect quick handover.

Whilst today's 4G networks only typically offer two levels of service (best-effort on default bearer or guaranteed on a dedicated bearer although LTE allows many more levels of bearer QoS) one of the goals of 5G must be to be able to offer differentiated services (conjecture - we cannot rely on over-provision in 5G as it is just too expensive).

So the architecture must be able to allow for mobility of end sessions (that is the bound SIP stack - not just the IP stack) such that a mobility event between eNBs is as-seamless tomorrow as it is today (typical to lose one or two voice packets in a 20ms-based SIP session).

Ultimately, our goal should be to extend the ability to define graduated services to external actors - not just the SP-domain services as things are today.   Applications and their requirements come in many shapes-and-sizes.

There is another side to the current central anchor solution; it provides an excellent, single tap-point for LI.  We must consider the implications for detectability of a tap in the new architecture and design in from day 1.

As such, I think we need to consider mobility at a application level, not just a packet level.

My £0.02

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of jouni korhonen
Sent: 10 May 2017 02:16
To: Tom Herbert <[email-masked]>
Cc: [email-masked]; Behcet Sarikaya <[email-masked]>; [email-masked]; Ca By <[email-masked]>; Lorenzo Colitti <[email-masked]>
Subject: Re: [5gangip] New Version Notification for draft-xyx-5gip-ps-00.txt

- Jouni

>>>> I fully agree with Lorenzo.  ILA does not have sufficient 
>>>> capabilities to match GTP based mobility we have today.
>>> 
>>> 
>> fundamentally incompatible with using half of the bits the the leaf 
>> network (i.e., the applications running on the MN and any other hosts 
>> behind it and virtual machines inside it).
>> 
>> You could certainly use ILA to assign the MN a /128 and then run a 
>> tunnel over that, but that's not really ILA any more: the A in ILA 
>> stands for Addressing, and if the user IPv6 addresses are assigned to 
>> a tunnel, then they're not ILA addresses.
>>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 May 2017 13:33:09 +0200 (CEST)

> Any solution with outage would be a non-starter for 3GPP AFAICT.

Why? If the traffic can handle a 5 second outage, why not allow that to 
simplify the solution?

> Change of IP address can happen in both i.e., same/different access but 
> solution space for same access HO should absolutely be transparent for 
> lot of machine critical applications on 5G (would be 5G).

If the traffic needs to be tunneled, then tunnel it. What I am talking 
about is traffic that doesn't need to be tunneled.

Let's be more concrete:

When my video player starts playing video, it tends to buffer 10-20 
seconds of video (at least). So if there is 1-2 second outage (and now 
we're talking about the application getting signalled that there will be 
an outage, and when the outage is over) the application is fine with that. 
The user experience won't be affected.

Yes, there is other traffic that can't handle this kind of outage, but I 
am not talking about that kind of traffic. I am fine with M2M traffic 
being tunneled if it needs address persistance and fast-handovers to work.

But looking today and in the future, a big part of the traffic is Video on 
demand traffic, streamed unicast from some kind of CDN to the client. This 
traffic generally handles shorter outages very well. There is no need to 
tunnel this traffic, incurring encap penalties and requiring hardware that 
can do this kind of encapsulation.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 May 2017 13:33:54 +0200 (CEST)

> Do you have a draft on this that we can consider? Or any volunteers to 

Why more information would you want included to be able to consider it?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 May 2017 13:37:01 +0200 (CEST)

On Wed, 10 May 2017, [email-masked] wrote:

> There is another side to the current central anchor solution; it 
> provides an excellent, single tap-point for LI.  We must consider the 
> implications for detectability of a tap in the new architecture and 
> design in from day 1.

This is a great point. If we're going to limit ourselves to something that 
is easy to LI just because the older solutions were easy to LI, then 
that's going to hugely narrow the scope of what 5G can and can't be.

So is this really a requirement? Because if it is, I don't even see how 5G 
can be revolutionary, because this is a huge constraint.

---

From: <[email-masked]>
Date: Wed, 10 May 2017 11:45:13 +0000

If you take the word of one very large MNO I work with, then the requirement is:

The ability to tap a user without:

 a) The user being aware that he/she is being tapped
 b) "normal" (i.e. non-security-cleared) network operations staff being aware that there is a tap in place
 c) No discernible/demonstrable modification in network traffic which could be correlated to knowing that a specific user had a warrant against them.

In the case of the large MNO I am talking about, all traffic "north" of the SGi is taken through a security solution which only specific staff have access to and all taps are handled there.  No-one outside that environment has any knowledge or could deduce a tap.

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 10 May 2017 12:37
To: [email-masked]
Subject: Re: [5gangip] New Version Notification for draft-xyx-5gip-ps-00.txt

> implications for detectability of a tap in the new architecture and 

This is a great point. If we're going to limit ourselves to something that is easy to LI just because the older solutions were easy to LI, then that's going to hugely narrow the scope of what 5G can and can't be.

So is this really a requirement? Because if it is, I don't even see how 5G can be revolutionary, because this is a huge constraint.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 May 2017 14:03:09 +0200 (CEST)

> In the case of the large MNO I am talking about, all traffic "north" of the SGi is taken through a security solution which only specific staff have access to and all taps are handled there.  No-one…

If people expect this of 5G, then we might as well not design any 5G at 
all. This is fundamentally incompatible with most of the proposed changes 
and improvements of 5G.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 07:05:00 -0700

> Why? If the traffic can handle a 5 second outage, why not allow that to
Because not all traffic can handle such an outage. Live video chat or
voice calls cannot handle a 5 second outage. An alert for an immediate
road danger to my autonomous vehicle can't handle a that outage.
Flight control for drones won't want a 5 second outage. One of the
promises of 5G is a 1 millisecond latency, having 5000x latency cost
for mobility is prohibitive to using real-time applications. IMO the
target for mobility handover should be something like 100msecs or
less.

Tom

>> solution space for same access HO should absolutely be transparent for lot
>> of machine critical applications on 5G (would be 5G).
>
>
> If the traffic needs to be tunneled, then tunnel it. What I am talking about
> is traffic that doesn't need to be tunneled.
>
> Let's be more concrete:
>
> When my video player starts playing video, it tends to buffer 10-20 seconds
> of video (at least). So if there is 1-2 second outage (and now we're talking
> about the application getting signalled that there will be an outage, and
> when the outage is over) the application is fine with that. The user
> experience won't be affected.
>
> Yes, there is other traffic that can't handle this kind of outage, but I am
> not talking about that kind of traffic. I am fine with M2M traffic being
> tunneled if it needs address persistance and fast-handovers to work.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 May 2017 16:10:55 +0200 (CEST)

> Because not all traffic can handle such an outage. Live video chat or

Correct. So make sure the traffic that can handle such an outage isn't 
tunneled, and tunnel the traffic that actually need to be tunneled.

Designing a network so that all kinds of packets need to go the same way, 
and treat all of it the way the most sensitive traffic needs to be 
treated, doesn't make sense to me.

VoD traffic doesn't need 1ms handover times. Just because some other 
traffic needs 1ms failover/handover times, why should the VoD traffic be 
done in the same manner?

A lot of the M2M and/or interactive traffic that probably is sensitive to 
these kinds of outages, are most likely not as high bandwidth and bulk 
data as the ones that actually can tolerate a few seconds outage from time 
to time without bad customer experience.

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 10 May 2017 14:17:34 +0000

We need to move away from "one-size-fits-all" network architecture. 

https://www.gsmaintelligence.com/research/?file=141208-5g.pdf&download

.....

* 1-10Gbps connections to end points in the field (i.e. not theoretical maximum)
* 1 millisecond end-to-end round trip delay (latency)
* 1000x bandwidth per unit area
* 10-100x number of connected devices
* (Perception of) 99.999% availability
* (Perception of) 100% coverage
* 90% reduction in network energy usage
* Up to ten year battery life for low power, machine-type devices

"..whilst these eight requirements are often presented as a single list, no use case,
service or application has been identifed that requires all eight performance attributes
across an entire network simultaneously.."

==================
Regards,
Kalyani Bogineni
Verizon

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: Wednesday, May 10, 2017 10:11 AM
To: Tom Herbert
Cc: [email-masked]
Subject: [E] Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

> Because not all traffic can handle such an outage. Live video chat or

Correct. So make sure the traffic that can handle such an outage isn't tunneled, and tunnel the traffic that actually need to be tunneled.

Designing a network so that all kinds of packets need to go the same way, and treat all of it the way the most sensitive traffic needs to be treated, doesn't make sense to me.

VoD traffic doesn't need 1ms handover times. Just because some other traffic needs 1ms failover/handover times, why should the VoD traffic be done in the same manner?

A lot of the M2M and/or interactive traffic that probably is sensitive to these kinds of outages, are most likely not as high bandwidth and bulk data as the ones that actually can tolerate a few seconds outage from time to time without bad customer experience.

_______________________________________________
5gangip mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=hX5qDRanp7q2UlT9QjmrCdOVxfC0GbtViCVdLn8bSEk&s=3AmPfSwbG9qsYEwJRH3ExXMMidXmSeBVATkswcKrnYI&e=

---

From: <[email-masked]>
Date: Wed, 10 May 2017 14:30:56 +0000

Mikael

I'm going to agree with Tom.  If we are designing new, things should be at-least as-good as we have today.  In a VoLTE handover between cells, you will typically lose one, maybe two packets - that is ~20ms.

Whilst VoD today has massive buffers times, these are a REAL pain - we have to buffer in clients; there is a synchronisation issue between adjacent clients viewing the same content.

The handover in LTE works very well given the requirements - very low packet loss on handover plus the likelihood of re-ordering is low (due to the manner by which the tunnels are handled).

As I said earlier, what I'd like to see is the ability for the OTT be able to exercise the 5G core to deliver better outcomes just as VoLTE can today within the SP domain.   What we have today in terms of VoD is really a by-product of the current close-coupling of service and transport within the 3GPP architecture.

David

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 May 2017 16:44:01 +0200 (CEST)

On Wed, 10 May 2017, [email-masked] wrote:

> I'm going to agree with Tom.  If we are designing new, things should be 
> at-least as-good as we have today.  In a VoLTE handover between cells, 
> you will typically lose one, maybe two packets - that is ~20ms.

Yes, that's fine, but not all traffic needs that. And I definitely want 
that to work for the traffic that needs that kind of fast handover. As I 
have repeatedly stated.

> Whilst VoD today has massive buffers times, these are a REAL pain - we 
> have to buffer in clients; there is a synchronisation issue between 
> adjacent clients viewing the same content.

Please elaborate.

> The handover in LTE works very well given the requirements - very low 
> packet loss on handover plus the likelihood of re-ordering is low (due 
> to the manner by which the tunnels are handled).

What part of my email are you responding to here?

> As I said earlier, what I'd like to see is the ability for the OTT be 
> able to exercise the 5G core to deliver better outcomes just as VoLTE 
> can today within the SP domain.  What we have today in terms of VoD is 
> really a by-product of the current close-coupling of service and 
> transport within the 3GPP architecture.

We must be living in some kind of parallel universes, you and I.

VoD is done over the Internet. This is 99% (or more) of the traffic in my 
book. VoLTE over a dedicated bearer is a special case. I am trying to 
design a network that works well for all traffic types, which means it 
needs to be simple and cheap for the huge bulk of the traffic that have 
nowhere near the requirements you and Tom have presented here, and it also 
needs to work well for fast-handover requirements. But, creating a network 
that has fast-handover capabilities for all traffic means it's going to be 
unneccesarily expensive.

My settop-box connected to my TV isn't moving. It's doing VoD and 
downloading chunks of data 1 second at a time. If it has a 5G radio, the 
network might want it to start to use some other base station a few times 
an hour. It will have no problem taking this VoD traffic, pausing the 
download of it for 1-2 seconds while it attaches to some other base 
station. The user will never notice. At the same time, I am watching a VoD 
stream on my mobile phone. Same thing there, this traffic doesn't need 
fast handover. Now, I start a VoIP call. This traffic needs fast 
handovers, so that traffic would be tunneled to enable address persistence 
across handovers and to ensure that handovers are smooth without much 
packet loss. None of the VoD traffic needs to be tunneled, because it 
doesn't have these requirements.

This would mean very little amount of the total traffic would need to be 
tunneled and handled by the mobile core nodes.

---

From: <[email-masked]>
Date: Wed, 10 May 2017 15:02:03 +0000

Mikael

I'm not so sure we are so far away from each other, actually!!!!

The issue we have today is a one-size-fits-all network at least from an IP transport perspective outside of the SP Domain.

BUT, on the LTE side we DO have the ability to define different (up to 9) levels of service.  This is only used by one IP-based application.

What I am advocating is the ability to build multiple SLAs.   My personal belief is that the days of build-out of supply massively exceeding demand are over - we are not going to be able to "throw bandwidth" at the RF problem.   That means we have to manage demand and practically that mean mapping applications to QCI on the air interface and QoS beyond SGi.

So, we're in agreement; not all traffic requires the tunnel (as long as we can clear away the LI issues) but we do have to make sure we can protect classes of traffic.  The only way we do that today is by different APNs (dedicated bearer for VoLTE).

Maybe the way to tackle this is to try to break down into traffic profiles and see where the similarities are?

David

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]] 
Sent: 10 May 2017 15:44
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

On Wed, 10 May 2017, [email-masked] wrote:

> I'm going to agree with Tom.  If we are designing new, things should 
> be at-least as-good as we have today.  In a VoLTE handover between 
> cells, you will typically lose one, maybe two packets - that is ~20ms.

Yes, that's fine, but not all traffic needs that. And I definitely want that to work for the traffic that needs that kind of fast handover. As I have repeatedly stated.

Please elaborate.

VoD is done over the Internet. This is 99% (or more) of the traffic in my book. VoLTE over a dedicated bearer is a special case. I am trying to design a network that works well for all traffic types, which means it needs to be simple and cheap for the huge bulk of the traffic that have nowhere near the requirements you and Tom have presented here, and it also needs to work well for fast-handover requirements. But, creating a network that has fast-handover capabilities for all traffic means it's going to be unneccesarily expensive.

My settop-box connected to my TV isn't moving. It's doing VoD and downloading chunks of data 1 second at a time. If it has a 5G radio, the network might want it to start to use some other base station a few times an hour. It will have no problem taking this VoD traffic, pausing the download of it for 1-2 seconds while it attaches to some other base station. The user will never notice. At the same time, I am watching a VoD stream on my mobile phone. Same thing there, this traffic doesn't need fast handover. Now, I start a VoIP call. This traffic needs fast handovers, so that traffic would be tunneled to enable address persistence across handovers and to ensure that handovers are smooth without much packet loss. None of the VoD traffic needs to be tunneled, because it doesn't have these requirements.

This would mean very little amount of the total traffic would need to be tunneled and handled by the mobile core nodes.

---

From: "Bogineni, Kalyani" <[email-masked]>
Date: Wed, 10 May 2017 15:21:23 +0000

There is also a new concept of 'network slicing' that could allow different IP connectivity
models - tunneled/non-tunneled; centralized/distributed, local services/traffic offload, etc. 

Kalyani

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, May 10, 2017 11:02 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [E] Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Mikael

David

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]]
Sent: 10 May 2017 15:44
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Please elaborate.

_______________________________________________
5gangip mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwICAg&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=IdiSODh8aDRjdCeGgd9MznLHMYKgKcs_YSwXBDiaofh47oilzaXYRYETcBynUdpT&m=6sg3dRu-QtnkHV0ZLeOahTvrhiTcxRs8lKYcTL-oaHc&s=hWFS7dgJnllQxokB7hk3NqqDZ_WIm5IIbt4Y-6HE1SY&e=

---

From: <[email-masked]>
Date: Wed, 10 May 2017 15:23:09 +0000

And IP/non-IP (very important for IoT...)

David

-----Original Message-----
From: Bogineni, Kalyani [mailto:[email-masked]] 
Sent: 10 May 2017 16:21
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

There is also a new concept of 'network slicing' that could allow different IP connectivity models - tunneled/non-tunneled; centralized/distributed, local services/traffic offload, etc. 

Kalyani

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, May 10, 2017 11:02 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [E] Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Mikael

David

-----Original Message-----
From: Mikael Abrahamsson [mailto:[email-masked]]
Sent: 10 May 2017 15:44
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Please elaborate.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 08:44:07 -0700

On Wed, May 10, 2017 at 7:10 AM, Mikael Abrahamsson <[email-masked]> wrote:
> and treat all of it the way the most sensitive traffic needs to be treated,
> doesn't make sense to me.
>
I take it your not a big believer in net neutrality then.

> VoD traffic doesn't need 1ms handover times. Just because some other traffic
> needs 1ms failover/handover times, why should the VoD traffic be done in the
> same manner?
>
Why shouldn't it be done in the same manner? A 1ms handover won't hurt
VoD traffic. Efficient IP layer handover would serve all applications
equally well.

> these kinds of outages, are most likely not as high bandwidth and bulk data
> as the ones that actually can tolerate a few seconds outage from time to
> time without bad customer experience.
>
That's only taking into account current application which have been
designedto run on slow, unreliable Internet. If we are to believe in
the promise of 5G then there is no reason to believe M2M applications
won't higher bandwidth at real time when such uses become feasible.

Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 May 2017 17:49:41 +0200 (CEST)

> I take it your not a big believer in net neutrality then.

Then you take it wrong.

> Why shouldn't it be done in the same manner?

Because it's expensive and complicated.

Why is Wifi radio much cheaper than 3GPP radio? Because it's less 
complicated, less IPR, less most things I can think of.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 08:54:17 -0700

> Maybe the way to tackle this is to try to break down into traffic profiles and see where the similarities are?
That's a fundamental problem. The network does not have visibility
into what service an application is using especially in light of TLS
encryption. You would need to rely on some meta information provided
by the application. There has already been a lot of discussion around
this issue (in SPUD proposal for instance), but there seems to be
little traction. Any proposed signaling for content is a privacy
concern and raises the possibility of abuse (e.g. someone says their
doing real-time video when they're not). Unless these problems are
solved I don't see that applications will play along.

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 08:58:43 -0700

On Wed, May 10, 2017 at 8:49 AM, Mikael Abrahamsson <[email-masked]> wrote:
>>> traffic
So having two methods instead of one makes things simpler?

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 10 May 2017 18:01:01 +0200 (CEST)

> So having two methods instead of one makes things simpler?

Yes, if one method relies on the other for transport.

You have one fundamental transport type, which is "IP packets". Then on 
top of that, you produce multiple services, of which one is "encapsulated 
packets for mobility".

---

From: <[email-masked]>
Date: Wed, 10 May 2017 16:08:02 +0000

3GPP Rel 13 allows for Non-IP Data Delivery.  It was specifically added for IoT devices.   

Data transfer uses the LTE bearer but it forwarded through the Control Plane, not the User Plane. 

David

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Mikael Abrahamsson
Sent: 10 May 2017 17:01
To: Tom Herbert <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

You have one fundamental transport type, which is "IP packets". Then on top of that, you produce multiple services, of which one is "encapsulated packets for mobility".

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 May 2017 11:34:01 -0500

On Tue, May 9, 2017 at 8:16 PM, jouni korhonen <[email-masked]>
wrote:

> One more point here regarding the mobility solution. The PDU Session
> mobility has to provide connectivity & mobility between the UE and the data
> network for session types of IP, Ethernet or unstructured (i.e. whatever).
> IP only solution is not enough.
>
>
OK, we will solve those too.
We promise the heaven :)

Behcet

> network
> tunnel

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 May 2017 11:37:32 -0500

On Tue, May 9, 2017 at 4:28 PM, Tom Herbert <[email-masked]> wrote:

> for
> RFC
Why end to end is not OK?
Encapsulation is to me defeats the purpose, you tunnel to where? Anchor
point? Then we have distributed anchors?

Behcet

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 May 2017 11:40:34 -0500

Mikael,

> top of that, you produce multiple services, of which one is "encapsulated
I think you now got a lot of feedback. I think you can put all those in
draft format.
Please do so, we will take it as one of the inputs.

Behcet

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 10:19:20 -0700

> Why end to end is not OK?

Because that would imply that for any host the Internet to talk to a
mobile host it would have to implement the extension header and
mobility protocol. Any solution that requires updating all the hosts
on the Internet to support some functionality is a non-starter.

> point? Then we have distributed anchors?

For a host talking to a UE I would implement encapsulation or ILA from
a carrier's gateway to the eNodeB. Process would look something like:

1) Host sends packet to UE's (virtual) address.
2) Packet routed over Internet to a gateway of the carrier
3) Gateway looks destination in mapping table, returns a locator
(physical address) of UE's current eNodeB
4) Packet is encapsulated (or ILA translated) with destination for eNodeB
5) Packet is routed over RAN to eNobeB
6) At eNodeB remove encpasulation (or reverse translate ILA)
7) Deliver packet to UE. This is now the same packet that the Internet
host sent.

                                                   ←----
Encapsulation/ILA path---->
                            _______                              _____
+-------+               (             )     +-------------+       (
    )     +-----------+     +------+
| Host |--------------(   Internet  )---|  Gateway |------( RAN
)------| Enodeb |-----|  UE  |
+------+                (_______)     +-------------+       (____)
  +-----------+    +-------+

Packets in the reverse direction, from UE to Host should need any
encapsulation or ILA. The can be sent as is and just following routing
to get to appropriate egress gateway.

When a UE moves to a new UE all the mapping tables need to be updated
this will take time. To mitigate that hit, I would probably place a
COA at the old eNodeB to forward packets (using encapsulation) to the
new location for some period of time.

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 May 2017 13:23:41 -0500

> on the Internet to support some functionality is a non-starter.
I think you are saying that we need proxies.

> Encapsulation/ILA path---->
Yes

> new location for some period of time.
These are all fine.

I was talking about ILA case without proxy and that's where we can consider
 extension header with a destination option.

I think that ILA as in data center use case (draft-herbert-nvo3) can also
find its niche in 5G world. Marco Liebsch had some ideas about that and I
am expecting he is going to post them in the list.

Behcet

Tom

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 11:39:20 -0700

> extension header with a destination option.
Segment routing extension header might "just work" for that case
(https://tools.ietf.org/html/draft-ietf-spring-segment-routing-11)

Tom

> find its niche in 5G world. Marco Liebsch had some ideas about that and I am
> expecting he is going to post them in the list.
>
> Behcet
>
>> Tom
>>
>> >
>> >
>> > Behcet
>> >>
>> >> Tom
>> >>
>> >> >
>> >> >
>> >> >
>> >> >

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 10 May 2017 13:14:34 -0700

On Wed, 2017-05-10 at 15:02 +0000, [email-masked] wrote:
> 
> VoD is done over the Internet. This is 99% (or more) of the traffic
> in my book.

Mikael,

I disagree with this observation.  Particularly if you wipe some of the
steam off the crystal ball and look forward.

For several years, I've been following the sorry progression of
emergency services communications out of its varied stovepipes.  The
shaggy stories of why it's taken so long notwithstanding, the future of
emergency services comms will be over the internet just like everything
else.  (If anyone wants some of these shaggy tales, ping me off line).
    The characteristics that we can forecast here will be quite
different from Video on Demand, although that will clearly be one data
type (example, video originating from a cop-toted camera).  A lot of
emergency services data is short query/response messages.  For example,
license plate lookups or want/warrant checks.  The messages require
only a few datagrams/frames.  Often just one.  A lot of the most
critical traffic consists of these very short messages.
     This means that things like early-open transport protocol is
useful.  Caching DNS servers topologically close to users. Content
authenticity is ALWAYS a requirement.  Etc.  

Mentioning this because I'd claim that the emergency services segment
of the traffic profile is not likely to add up to lots of bits.  But
the few bits that are there are important ones.  For all of us.

QoS.  If you want to get into an almost violent discussion, get 1) cops
and firemen and 2) the word 'pre-empt' together.

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 10 May 2017 13:18:48 -0700

Hi Dirk,

Thank you and the co-authors to start with the writeup of this draft as a
collection of possible protocols for 5G networks.

Here are some comments/observations: [ I am catching up with many comments
already discussed in this thread]

* Figure -1 is helpful -- Is it aligned with 5G work in 3GPP or is it going
to be an input to 3GPP ?

* From the draft, I assume the scope of multi-access technologies are :
LTE, 5G-Cellular, Wifi and 3G radios; Thus the underlying assumption is
that small IOT devices will always have a gateway to talk to 5G access
which will speak one of the above technologies or more. Or they would have
to individually acquire a /64 prefix or /128 bit assigned IP(v6)-address
and have a 3GPP supported UE interface.

* Since 3GPP assigns /64 IPv6 prefix to each UE, if that needs to be
supported, then addressing for thousands of small IOT devices would be a
challenge unless they are considered local  and use IPv6 ULA for local
communication and use a proxy/Mapper UE (gateway) to access the Internet

* ILA comes handy here. I agree with many commenters in this list that
trying to overhaul 3GPP architecture to something radically different will
not be practical. [ History : MIPv6, MIPv4 in 3GPP2]

* I would think we need a data-plane function (MADP+) which can fan-out
data as per policy programmed by MAMS like management protocol, such as :
  1) Data flowing to Corporate network ( via VPN)
  2) Fat pipe of data flowing through the Operators' network with proper QoS
            - Some investigation is needed if ILA with GUE tunneling can
offer appropriate SLA
  3) Tunnel data with GTP slowpath that wants to go via traditional route
  4) IOT specific data with proper latency requirement for immediate action
or sending to cloud analytics

* 3GPP 5G is working on bringing Core-components (P-GW, Access functions,
Policy functions) to the 5G Edge sitting along with RBS.
             - Do they still need complicated GTP tunnel setup procedure or
could that be handled easily with identity-locator based tunelling?

             - If the P-GW resides near the edge, the user subscription
handling part of PGW may be separated from its dataplane components,
however if the data goes to cloud [ as opposed to usual cell-phone to
cell-phone data] which might be the case for IOT devices /Connected Cars we
need to make sure proper security and QoS are applied from P_GW to the
Application sitting at the Customer Data Center.

As for ILA, I think I like the concept of ILA mapping at the ACCESS and at
the Destination edge  with a simple tunneling like GUE. Of-course, we need
to understand the security methods to protect the data too. This part is
missing in the current version of the document. At least, the document can
mention security as a line item.

How the data is routed in the backhaul or WAN, perhaps should be out of
scope for this document.

In IETF IOT area, I co-chair 6lo WG which discusses many IOT L2
technologies such as BT, ZigBee, NFC, PLC etc. -- they have small
throughput, but in Industrial scale they can send data in  high volume to
5G networks via corresponding gateways which can speak either LTE/5G-radio
or Wifi towards the Access network. Please consider this scenario as well
in your architecture diagram.

Thanks,
-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 10 May 2017 13:28:02 -0700

Good point Cameron!
5G architecture consideration of distributed Core functions need to be
considered in the overall architecture consideration.
Also slicing can be possible from Cloud application all the way to MADP and
 IOT-GW ( For example autonomous driving entity's gateway or a car-gw,
industrial IOT-GW in Enterprise etc.). We can assume that the IOT-GW is an
end-point for the sliced service.

If the cloud controller and the MAMS control unit co-ordinate, the
end-2-end slice can be configured.

-Samita

On Thu, May 4, 2017 at 5:56 AM, Ca By <[email-masked]> wrote:

>> Mikael Abrahamsson    email: [email-masked]
>> _________________________________
>> 5gangip mailing list
>> [email-masked]

---

From: <[email-masked]>
Date: Wed, 10 May 2017 20:29:32 +0000

Rex

Totally agree.   Look at the issues with the Airwave (TETRA) replacement issues in the UK.   The TETRA network provides almost total coverage and very quick call set-up times for PTT sessions.   Yes, it is circuit-switched and data is horribly slow (which is why it is being replaced), but QoS and latency are the two major issues hampering its replacement by LTE.

VoLTE is notorious for slow call setup.   Services such as Skype and WhatsApp are OTT and work fine all the time we rely on massive over-provision on the transport network (as we have been getting-away with for a number of years on the wired Internet).

However, the economics of RF access are totally different to wireline and we are already in a position where we are having to manage contention (as I suspect we will have to in a few years' time on the wired Internet as well, btw).

All video is not equal to VoD either - a real-time video conference requires different treatment of the various elements to ensure synchronisation between talkers and a usable experience.

My own suspicion is that we are moving to a single utility model for access over the long-term much in the way that the electricity supply network works, rail transport, etc.  We have to be able to expose desired customer outcomes and grades of services to the operators independent of the transport network just as we do for rail, gas, electricity, etc.

David

-----Original Message-----
From: Rex Buddenberg [mailto:[email-masked]] 
Sent: 10 May 2017 21:15
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

On Wed, 2017-05-10 at 15:02 +0000, [email-masked] wrote:
> 
> VoD is done over the Internet. This is 99% (or more) of the traffic in 
> my book.

Mikael,

I disagree with this observation.  Particularly if you wipe some of the steam off the crystal ball and look forward.

For several years, I've been following the sorry progression of emergency services communications out of its varied stovepipes.  The shaggy stories of why it's taken so long notwithstanding, the future of emergency services comms will be over the internet just like everything else.  (If anyone wants some of these shaggy tales, ping me off line).
    The characteristics that we can forecast here will be quite different from Video on Demand, although that will clearly be one data type (example, video originating from a cop-toted camera).  A lot of emergency services data is short query/response messages.  For example, license plate lookups or want/warrant checks.  The messages require only a few datagrams/frames.  Often just one.  A lot of the most critical traffic consists of these very short messages.
     This means that things like early-open transport protocol is useful.  Caching DNS servers topologically close to users. Content authenticity is ALWAYS a requirement.  Etc.  

Mentioning this because I'd claim that the emergency services segment of the traffic profile is not likely to add up to lots of bits.  But the few bits that are there are important ones.  For all of us.

QoS.  If you want to get into an almost violent discussion, get 1) cops and firemen and 2) the word 'pre-empt' together.

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 10 May 2017 13:34:12 -0700

Hi Dirk/Behcet:

Is there a short presentation or whitepaper talking about 3GPP 5G transport
architecture ?
Would be very useful to have that side by side while 5gangip tries to come
up with new protocols.
Perhaps it was already discussed, I am coming late in the game...

Thanks,
-Samita

On Fri, May 5, 2017 at 1:46 AM, <[email-masked]> wrote:

> Dear Cameron and Mikael,
>
> Thanks a lot for your comments. We definitely have and want to simplify
> our approach for 5G – the described situation is IMO exactly what demands
> for slicing, i.e. a modular approach with complex and costly
> functionalities only for dedicated application driven logical sub-networks
> … whereas for a great deal of traffic the functions to be executed must be
> as simple as possible – and these functions at control plane level will
> steer and decide on the separate User Plane paths … with other words what
> CUPS is all about, right?
>
>
>
> *From:* Ca By [mailto:[email-masked]]
> *Sent:* Donnerstag, 4. Mai 2017 14:56
> *To:* von Hugo, Dirk; Mikael Abrahamsson
> *Cc:* [email-masked]
> *Subject:* Re: [5gangip] FW: New Version Notification for
> draft-xyx-5gip-ps-00.txt
>
>
>
>
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 10 May 2017 13:44:53 -0700

> technology. AFAICT GTP is very much tied to one technology.

Agree. ILA mapping has potential for non-IP enabled devices support.

> encapsulation, how generic it is, how extensible is it, etc.
As for mobility, it'd be wise to compare the gaps, feature difference from
existing PDN-GW GTP based mobility and analyse whether to add ILA mapping
and mobility function for the non-LTE based 5G technologies to begin with.

-Samita

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 13:48:22 -0700

> Agree. ILA mapping has potential for non-IP enabled devices support.
Hi Samita,

I'm not sure how ILA would do this. ILA only works with IPv6, or IPv4
if you're willing to do protocol translation. For non-IP packets it
seems like we need encapsulation that can carry different protocols
(GUE has a protocol field for this purpose).

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 10 May 2017 15:48:36 -0500

Hi Samita,

On Wed, May 10, 2017 at 3:34 PM, Samita Chakrabarti <[email-masked]>
wrote:

> Hi Dirk/Behcet:
>
> Is there a short presentation or whitepaper talking about 3GPP 5G
> transport architecture ?
>

If you are looking for a white paper and have lots of time, check this one:

https://5g-ppp.eu/wp-content/uploads/2014/02/5G-PPP-5G-Architecture-WP-July-2016.pdf

How much it is synchronized with the latest SA2 5G work I don't know.

I don't know what you mean by 5G Transport architecture but I know that 5G
System Architecture is defined by SA2 in TS 23.501 which we have taken as
reference (the latest version is v0.4.0).

http://www.3gpp.org/ftp//Specs/archive/23_series/23.501/23501-040.zip

Figure 1 in the draft is a simplified version of Fig. 4.2.3.2 (in reference
point representation).

Behcet.

>> For the internet access use case you described, the PPF (PGW user plane
>> in 5G) can exist at the cell site or somewhere close to the base station
>> for an internet access slice.  The 3GPP 5G generalizes these functions, and

---

From: <[email-masked]>
Date: Wed, 10 May 2017 20:49:00 +0000

Samita

3GPP 5G architecture is defined in http://www.3gpp.org/DynaReport/23501.htm

You’ll notice on page 90 that the protocols in the User Plane are not currently defined and that the concept of a central anchor is retained, at least for the PDU service.

David

From: 5gangip [mailto:[email-masked]] On Behalf Of Samita Chakrabarti
Sent: 10 May 2017 21:34
To: [email-masked]
Cc: [email-masked]; Ca By <[email-masked]>; Mikael Abrahamsson <[email-masked]>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Hi Dirk/Behcet:

Is there a short presentation or whitepaper talking about 3GPP 5G transport architecture ?
Would be very useful to have that side by side while 5gangip tries to come up with new protocols.
Perhaps it was already discussed, I am coming late in the game...

Thanks,
-Samita

On Fri, May 5, 2017 at 1:46 AM, <[email-masked]<mailto:[email-masked]>> wrote:
Dear Cameron and Mikael,
Thanks a lot for your comments. We definitely have and want to simplify our approach for 5G – the described situation is IMO exactly what demands for slicing, i.e. a modular approach with complex and costly functionalities only for dedicated application driven logical sub-networks … whereas for a great deal of traffic the functions to be executed must be as simple as possible – and these functions at control plane level will steer and decide on the separate User Plane paths … with other words what CUPS is all about, right?

Thanks and Best Regards
Dirk

From: Ca By [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Donnerstag, 4. Mai 2017 14:56
To: von Hugo, Dirk; Mikael Abrahamsson
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

Cameron

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 10 May 2017 14:04:55 -0700

> (GUE has a protocol field for this purpose).

Right, Tom.

I was thinking of a little bit of implementation extension.

Some legacy IOT-type devices may not be capable of running IP but they can
send data over L2 and they have a L2-identifier. If ILA-capable
translator/aggregator can provide a /64 prefix for all such nodes, then it
can provide some address translation function as well  and act as a proxy
IP-endpoint.
Though it is not relevant to the ILA protocol as it is, but it could
leverage the ID-part.
This will enable the proxy device to talk to an IP-application on behalf of
the non-IP devices. While VXLAN, GUE would tunnel L2 packets to the other
end.

 -Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Wed, 10 May 2017 14:06:13 -0700

Thanks Behcet!
TS 23.501 should work.
-Samita

On Wed, May 10, 2017 at 1:48 PM, Behcet Sarikaya <[email-masked]>
wrote:

> Hi Samita,
>
>
> On Wed, May 10, 2017 at 3:34 PM, Samita Chakrabarti <
> [email-masked]> wrote:
>
>> Hi Dirk/Behcet:
>>
> Figure 1 in the draft is a simplified version of Fig. 4.2.3.2 (in
> reference point representation).
>
> Behcet.
>
>

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 10 May 2017 22:57:43 +0000

> Because that would imply that for any host the Internet to talk to a mobile host it would have to implement the extension header and mobility protocol. Any solution that requires 
                               > updating all the hosts on the Internet to support some functionality is a non-starter.

If you want a cleaner long term solution, IMO changing host stack  which doesn't impact the network in between is a better way forward..(LISP, ILNP, HIP..)

		>When a UE moves to a new UE all the mapping tables need to be updated this will take time. To mitigate that hit, I would probably place a COA at the 
                                > old eNodeB to forward packets (using encapsulation) to the new location for some period of time.

if UE gets new IP here, I didn't see any session continuity in this solution (COA at old eNodeB to save packets is secondary..)
--
Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 16:17:15 -0700

> if UE gets new IP here, I didn't see any session continuity in this solution (COA at old eNodeB to save packets is secondary..)

The UE does not get a new IP address, only its locator changes.

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 10 May 2017 23:31:05 +0000

>The UE does not get a new IP address, only its locator changes.

For TCP @ UE this is still a new SRC IP (locator portion of the IP), no?? And also did you talk about, how the other end (host) gets this update??

--
Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 16:39:57 -0700

> For TCP @ UE this is still a new SRC IP (locator portion of the IP), no?? And also did you talk about, how the other end (host) gets this update??

No, the source address does not change, TCP connections don't break.
Please see my example I posted previously. Overlay networks (tunnels)
are used between EnodeBs and gateways. A distributed mapping service
is run that these nodes share, so the Internet can communicate with
mobile hosts and mobile hosts can communicate between themselves. This
method is transparent to hosts including UEs and there are no changes
need to transport layer. It's a fairly straightforward use of
tunneling once an efficient mapping system is in place.

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 10 May 2017 23:47:04 +0000

>No, the source address does not change, TCP connections don't break.

Source address can change if UE moves from UPF serving area. 
But, now I see your case is (R)AN mobility case (same UPF serving area).

	>Please see my example I posted previously. Overlay networks (tunnels) are used between EnodeBs and gateways. 
                >A distributed mapping service is run that these nodes share, so the Internet can communicate with mobile hosts and mobile hosts can communicate between themselves. 
               >This method is transparent to hosts including UEs and there are no changes need to transport layer. It's a fairly straightforward use of tunneling once an efficient mapping system is in place.

I get that.  

Then this is may be good for 4G, but I guess we are talking about 5G here and I assumes PGW/UPF mobility and hence the Source IP address change is considered in your solution.

--
Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 16:59:55 -0700

> Then this is may be good for 4G, but I guess we are talking about 5G here and I assumes PGW/UPF mobility and hence the Source IP address change is considered in your solution.
In that case the TCP connection would break regardless. Transport
layer mobility, like QUIC, might then be solution.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 11 May 2017 00:10:39 +0000

+ IDEAS

https://tools.ietf.org/html/draft-padma-ideas-use-cases-00 

Section 7 covers this use case - I saw you are part of this (may be this use case didn't come from you)

This is being worked out  and solution would be put forth soon..

--
Uma C.

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Wednesday, May 10, 2017 5:00 PM
To: Uma Chunduri <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>; Lorenzo Colitti <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

> Then this is may be good for 4G, but I guess we are talking about 5G here and I assumes PGW/UPF mobility and hence the Source IP address change is considered in your solution.
In that case the TCP connection would break regardless. Transport layer mobility, like QUIC, might then be solution.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 17:58:04 -0700

> This is being worked out  and solution would be put forth soon..
Okay, I think I see the confusion.

In an Identifier/Locator split there are two addresses that are
associate with a node. One is the identifier that expresses the
logical and persistent address of the node ("who")-- this what
applications see and what might returned from DNS if an addressed is
looked by domain name. The other address is the locator, this
expresses where the node is current at ("where"). As a mobile node
moves from place to place it's location changes so it's locator
changes. But, it's identifier address does not change-- that uniquely
identifies the node regardless of where it's at. In order to send to a
node (by it's identifier address, a some point in the path, someone
needs to know to that to reach the addressed node the packet has to be
sent to its locator address. So there is a mapping from identifier to
locator and then packet is forwarded to locator address (by
encapsulation, segment routing, ILA, etc.). This really equivalent to
virtual to physical address mapping, or home address to mobile
address.

So it's really the locator address for a node that changes, not the
the identifier. The system needs to ensure that packets delivered to
the application always get the identifier address and that keeps
source address persistent.

Tom

---

From: Rex Buddenberg <[email-masked]>
Date: Wed, 10 May 2017 20:07:17 -0700

Herewith a suggested substitute for existing section 8.  Rationale
below:

<start>
8 Security considerations.

At the problem statement level of abstraction it's important to
identify the issues within scope.  And equally important to identify
those outside scope.  

5g represents infrastructure at layers 1, 2, and 3 of the ISO model.
Each of those layers contains security issues.  

But 5G does not include issues at layers 4 and up.  Therefore the
security issues here are outside scope:
  - authenticity, integrity and confidentiality of content data (aka
payload) is outside scope.  These are layer 6 and 7 issues, almost
always end-to-end (meaning beyond reach of 5g).  
  - connection integrity encompasses two issues: identity of the end
system that a subscriber is connecting to and reliable delivery of all
packets.  The former has been handled, with greater or lesser security
with DNS and the connection setup protocols in TCP (as an example of a
transport protocol).  Scope (see if I'm reading this right): these
requirements and features are not changed and they are outside 5g
scope. That said, the volatility of the infrastructure (rapid address
changes) makes the problem harder and cascading requirements may
emerge.
  - layer 3 security concerns include authenticity of infrastructure
nodes (is this router bogus or true?).  This is where the VPN language
belongs (Tom Herbert's comments from Friday, for example).  These are
within scope.
  - layer 2 security issues include a host of possibilities.  But frame
address integrity is clearly in scope, and suitable for
standardization.
  - layer 1 security issues are outside scope, largely because they are
1) single vendor issues and 2) volatile technological issues not
suitable for standardization.

<end>

Rationale.  First, security should not be bolted on after we thrash
everything else; needs to be built in.  The existing rather boilerplate
is not, IMHO, very appropriate to get this started.
   Secondly, even before considering requirements, some scoping (or, if
it suits you, a sorting model) is necessary to organize things.  In my
experience the ISO Reference Model is made to order.
   Pick at whether this or that is in scope or out, but we need to
thrash that early, like now, before we progress to requirements and
from there to proposed solutions.

Help?

---

From: Christian Huitema <[email-masked]>
Date: Wed, 10 May 2017 20:20:49 -0700

> source address persistent.
And this stable identifier has horrendous privacy issues. Or can have,
especially if you were to have a design in which a mobile device has
just one such identifier and keeps it all the time. It becomes a
beautiful tracking beacon.

-- Christian Huitema

---

From: Tom Herbert <[email-masked]>
Date: Wed, 10 May 2017 21:17:20 -0700

> beautiful tracking beacon.
Identifiers (anything that is persistent over time that can be
tracked) needs to be obfuscated to prevent the tracking. I believe
WAVE already has done some good work towards that end.

Tom

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 11 May 2017 05:36:26 +0000

In-line [Uma]:

--
Uma C.

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Wednesday, May 10, 2017 5:58 PM
To: Uma Chunduri <[email-masked]>
Cc: Behcet Sarikaya <[email-masked]>; Lorenzo Colitti <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

[Uma]: I don't see any confusion.
               I was just saying the solution you described here https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html
               doesn't solve IP address change case (UPF change) but only addresses (R)AN mobility.

In an Identifier/Locator split there are two addresses that are associate with a node. One is the identifier that expresses the logical and persistent address of the node ("who")-- this what applications see and what might returned from DNS if an addressed is looked by domain name. The other address is the locator, this expresses where the node is current at ("where"). As a mobile node moves from place to place it's location changes so it's locator changes. But, it's identifier address does not change-- that uniquely identifies the node regardless of where it's at. In order to send to a node (by it's identifier address, a some point in the path, someone needs to know to that to reach the addressed node the packet has to be sent to its locator address. So there is a mapping from identifier to locator and then packet is forwarded to locator address (by encapsulation, segment routing, ILA, etc.). This really equivalent to virtual to physical address mapping, or home address to mobile address.
So it's really the locator address for a node that changes, not the the identifier. The system needs to ensure that packets delivered to the application always get the identifier address and that keeps source address persistent.

[Uma]: Precisely  and I don't see how you get that stable identifier in ILA where you split Identity and Locator (ILA) logically  in the same UE address where your host on the other end is communicating to (in your example https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html )

Tom

> Cc: Behcet Sarikaya <[email-masked]>; Lorenzo Colitti
> <[email-masked]>; [email-masked]; [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 11 May 2017 07:37:10 +0200 (CEST)

On Wed, 10 May 2017, Rex Buddenberg wrote:

> Mentioning this because I'd claim that the emergency services segment of 
> the traffic profile is not likely to add up to lots of bits.  But the 
> few bits that are there are important ones.  For all of us.

Fully agreed. I never said it wasn't. I'm just saying that the bulk of the 
traffic doesn't have this requirement. So designing a network so that all 
traffic is treated the same way is not optimal.

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 11 May 2017 05:45:00 +0000

>And this stable identifier has horrendous privacy issues. Or can have, especially if you were to have a design in which a mobile 
                >device has just one such identifier and keeps it all the time. It becomes a beautiful tracking beacon.

Fully agree and this must be considered as one of the mandatory security aspect in the solution space (HIP solves this by anonymizing by generating the hashes for identifiers)

--
Uma C.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 11 May 2017 18:04:41 +0900

> will still enable servers to maintain the connection, but will remove

Have people thought about how to implement such a scheme in hardware
load-balancers? Seems like it would require

   - The network be able to guarantee stable hashing for a set of
   connection IDs much larger than the total number of connections.
   - The server to be able to predict how the network will hash given
   connection IDs.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 11 May 2017 18:16:02 +0900

> traffic needs 1ms failover/handover times, why should the VoD traffic be

I think Mikael is right. A network that does 1ms handover times for all
traffic is going to be way more expensive than one that only does it for 1%
of traffic. Why do we want customers to have to pay for that?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 11 May 2017 18:17:52 +0900

> communication and use a proxy/Mapper UE (gateway) to access the Internet

Any scheme we design must either support /64 to the UE or explain why it
violates the IPv6 addressing best practices documented in RFC 7934.

---

From: <[email-masked]>
Date: Thu, 11 May 2017 09:31:18 +0000

Dear all,
Exactly that is IMO the basic differentiator of 5G – to provide efficiently a service-specific logical network (slice) which fulfills the respective performance requirements – and very often this will result in an either-or: low latency or large data rate or high reliability …
Best Regards
Dirk
From: 5gangip [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Donnerstag, 11. Mai 2017 11:16
To: Mikael Abrahamsson
Cc: Tom Herbert; [email-masked]
Subject: Re: [5gangip] FW: New Version Notification for draft-xyx-5gip-ps-00.txt

On Wed, May 10, 2017 at 11:10 PM, Mikael Abrahamsson <[email-masked]<mailto:[email-masked]>> wrote:
VoD traffic doesn't need 1ms handover times. Just because some other traffic needs 1ms failover/handover times, why should the VoD traffic be done in the same manner?

I think Mikael is right. A network that does 1ms handover times for all traffic is going to be way more expensive than one that only does it for 1% of traffic. Why do we want customers to have to pay for that?

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 11 May 2017 09:31:45 -0500

> source address persistent.
Folks, these are Tom's personal thinking. Those that are not mentioned in
the PS draft are not in scope.

Behcet

> > Cc: Behcet Sarikaya <[email-masked]>; Lorenzo Colitti <
> [email-masked]>; [email-masked]; [email-masked]
> >>         >Please see my example I posted previously. Overlay networks
> (tunnels) are used between EnodeBs and gateways.
> >>                 >A distributed mapping service is run that these nodes
> share, so the Internet can communicate with mobile hosts and mobile hosts
> can communicate between themselves.
> >>                >This method is transparent to hosts including UEs and
> there are no changes need to transport layer. It's a fairly straightforward
> use of tunneling once an efficient mapping system is in place.
> >>
> >> I get that.
> >>
> >> Then this is may be good for 4G, but I guess we are talking about 5G
> here and I assumes PGW/UPF mobility and hence the Source IP address change
> is considered in your solution.
> >>
> > In that case the TCP connection would break regardless. Transport layer
> mobility, like QUIC, might then be solution.
> >
> >> --
> >> Uma C.
> >>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 11 May 2017 14:04:23 -0500

> the PS draft are not in scope.

Let me clarify. I apologize if I offended anybody. No offense folks.
We are not in the business of policing people.
In our list mails are written freely and people write whatever they think,
i.e. it is an IETF list.

Regards,

Behcet

---

From: jouni korhonen <[email-masked]>
Date: Thu, 11 May 2017 14:08:58 -0700

The protocol choice will usually take place in “stage-3 groups". In this case it would be RAN3 afair. Their current working assumption for NG data transport (with a disclaimer) is already GTP - check TS38.414 & 38.424. Like it was with rel-8 the interesting & hectic part of the mobility takes place in RAN. Out of all efforts in rel-8 PMIP never made it into RAN par of the network. Too much legacy there. If there’s a desire to revert the TR38.801 decision on using GTP, the timeframe is getting tight. The good point is that RAN (S1, X2, etc) never used GTP-C as a control plane.

- Jouni

> On May 10, 2017, at 1:49 PM, [email-masked] wrote:
> 
> Samita
> 
>  
> 
> Mikael Abrahamsson    email: [email-masked]
> 5gangip mailing list
> [email-masked]

---

From: Tom Herbert <[email-masked]>
Date: Thu, 11 May 2017 16:12:40 -0700

On Wed, May 10, 2017 at 10:36 PM, Uma Chunduri <[email-masked]> wrote:
> <[email-masked]>; [email-masked]; [email-masked];
> [email-masked]
>                I was just saying the solution you described here
> https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html
> In an Identifier/Locator split there are two addresses that are associate
> with a node. One is the identifier that expresses the logical and persistent
> address of the node ("who")-- this what applications see and what might
> returned from DNS if an addressed is looked by domain name. The other
> address is the locator, this expresses where the node is current at
> ("where"). As a mobile node moves from place to place it's location changes
> so it's locator changes. But, it's identifier address does not change-- that
> uniquely identifies the node regardless of where it's at. In order to send
> to a node (by it's identifier address, a some point in the path, someone
> needs to know to that to reach the addressed node the packet has to be sent
> to its locator address. So there is a mapping from identifier to locator and
> then packet is forwarded to locator address (by encapsulation, segment
> routing, ILA, etc.). This really equivalent to virtual to physical address
> mapping, or home address to mobile address.
> So it's really the locator address for a node that changes, not the the
> identifier. The system needs to ensure that packets delivered to the
> application always get the identifier address and that keeps source address
> persistent.
>
> [Uma]: Precisely  and I don't see how you get that stable identifier in ILA
> where you split Identity and Locator (ILA) logically  in the same UE address
> where your host on the other end is communicating to (in your example
> https://www.ietf.org/mail-archive/web/5gangip/current/msg00488.html )
>

The procedures are described in the ILA draft also
(https://datatracker.ietf.org/doc/draft-herbert-nvo3-ila). For
instance Scenario 7 shows Internet host to tenant system.
>>> Then this is may be good for 4G, but I guess we are talking about 5G here
>>> and I assumes PGW/UPF mobility and hence the Source IP address change is
>>> considered in your solution.
>>>

---

From: Uma Chunduri <[email-masked]>
Date: Thu, 11 May 2017 23:36:01 +0000

>The protocol choice will usually take place in “stage-3 groups". In this case it would be RAN3 afair. Their current working assumption for NG data transport (with a disclaimer) is already GTP - check TS38.414 & 38.424. 
                >Like it was with rel-8 the interesting & hectic part of the mobility takes place in RAN. Out of all efforts in rel-8 PMIP never made it into RAN par of the network. 
                >Too much legacy there.

+1. Indeed too much..
Mobility is always built on anchor based solution and AFAIS, even today it's difficult to move away even 
virtual use plane/EPC and non-3GPP access and few more items put pressure to have a different outcome.  
May be too much at stake for the deployed base..(remember 4G upgrade is still happening).

                >If there’s a desire to revert the TR38.801 decision on using GTP, the timeframe is getting tight. 
                >The good point is that RAN (S1, X2, etc) never used GTP-C as a control plane.

GTP is used on S1 (S1-C) and X2 for inter eNodeB data transfer during mobility (eNodeB).

--
Uma C.

---

From: Christian Huitema <[email-masked]>
Date: Thu, 11 May 2017 18:06:43 -0700

On 5/11/2017 2:04 AM, Lorenzo Colitti wrote:

> On Tue, May 9, 2017 at 3:15 AM, Christian Huitema <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>   * The network be able to guarantee stable hashing for a set of
>   * The server to be able to predict how the network will hash given
>     connection IDs.
>
Would it not be better to discuss that on the QUIC WG's mailing list?

-- Christian Huitema

---

From: Jouni <[email-masked]>
Date: Thu, 11 May 2017 19:10:32 -0700

> On 11 May 2017, at 16:36, Uma Chunduri <[email-masked]> wrote:
> 

Both S1-MME and X2-AP are protocols directly over SCTP. Nothing to do with GTP-C afair.

- Jouni