Subject: Re: [5gangip] Reviewing GTP (was: re: Notes from today's meeting)

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 May 2018 11:10:23 +0200

Hi,

I posted a draft about GTP.

In order to access the draft one needs IPv6:

http://petrescu.sandelman.ca/

Alex

Le 31/03/2018 à 04:05, Satoru Matsushima a écrit :
> Thank you Behcet,
> 
> Ok, I was supposed that Alex is going to make a reference doc for GTP in IETF, and John is going to review GTP in ETSI.
> 
> As I mentioned at last DMM meeting, investigating GTP-U by IETF experts’s eyes is highly appreciated. Please see following link and find some GTP-U info. Maybe IETF-friendly style explanation is helpful for you. :-)
> 
> https://datatracker.ietf.org/meeting/101/materials/slides-101-dmm-study-on-user-plane-protocol-at-3gpp-00
> 
> 
> I’m really happy to cooperate with all people those who are interested in to work on it.
> 
> Best regards,
> --satoru
> 
> 
> 
>> 2018/03/31 0:26、Behcet Sarikaya <[email-masked]>のメール:
>>
>> Hi Satoru,
>>
>> On Fri, Mar 30, 2018 at 12:12 AM, Satoru Matsushima <[email-masked]> wrote:
>> Hello John,
>>
>> If it would useful, I’d like to cooperate that GTP review work at user plane point of view. Thanks.
>>
>>
>>
>> Thanks for the offer but I think you are confused of what is going on below in the mails, so many people's mails including two John's, Jon Crowcroft and John Grant.
>>
>> Reviewing GTP is an idea we have in 5gangip and currently Alex is taking the lead.
>> As a GTP expert you are welcome to join him.
>>
>> Alex has this ambitious idea of writing a draft (not an RFC, we do not write RFCs, some drafts become RFCs) on GTP which could be used as a reference to GTP in IETF (to enable the operators  to run GTP in IPv6).
>>
>> In our case, we encourage writing a requirements document for end to end privacy enabled mapping system for 5G for which the starting point should be the GTP and address the issues of tunneling and other aspects.
>>
>> I believe this has nothing to do with what is going on in dmm.
>>
>> Regards,
>> Behcet
>>
>> Cheers,
>> --satoru
>>
>>> 2018/03/29 19:38、John Grant <[email-masked]>のメール:
>>>
>>> On Mon, Mar 26, 2018 at 4:49 AM, Alexandre Petrescu <alexandre.petrescu at gmail.com>
>>>   wrote:
>>>
>>>
>>>
>>> Le 23/03/2018 à 09:08, Jon Crowcroft a écrit :
>>> is there a technical reason we can't just re-visit MIPv6 in 5g in 2018?
>>>
>>> If it were up to me...
>>>
>>> To revisit, I would start looking at the tunnelling mechanism, identify
>>> what's missing from GTP, or how is it too heavy.
>>>
>>> That's something we're looking at in ETSI ISG NGP http://www.etsi.org/technologies-clusters/technologies/next-generation-protocols
>>>
>>> There's also a one-day workshop on the topic in Cambridge at the end of April https://www.cambridgewireless.co.uk/events/uk5g-death-ip-realising-opportunities-next-generat/
>>> --
>>> John Grant
>>> Nine Tiles, Cambridge, England
>>> +44 1223 862599 and +44 1223 511455
>>>
>>> http://www.ninetiles.com
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> 5gangip mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/5gangip
>>
>> _______________________________________________
>> 5gangip mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/5gangip
>>
> 
> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 14 May 2018 12:09:51 +0200 (CEST)

> http://petrescu.sandelman.ca/

If you're going to make an IETF submission, please post it using the 
normal IETF ID way.

If you're not making an IETF submission (which you don't seem to be since 
you've uploaded IETF draft formatted text to somewhere else), then please 
don't bring it up at IETF discussion groups and call it a "draft".

Also, after reading the document, it's impossible to understand what 
you're even trying to do with it, much less what you're trying to 
standardize (considering it says "standards track".

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 May 2018 12:44:45 +0200

Hi Mikael,

Thank you for having read the draft.

Le 14/05/2018 à 12:09, Mikael Abrahamsson a écrit :
> If you're not making an IETF submission (which you don't seem to be 
> since you've uploaded IETF draft formatted text to somewhere else), then 
> please don't bring it up at IETF discussion groups and call it a "draft".

Whether or not it becomes an IETF submission depends on the readers.  If 
enough people show interest then so it will be, otherwise no.

At this time, I keep it on IPv6 access.

As for not calling it a 'draft' - it is a good idea.  I will think about it.

> standardize (considering it says "standards track".

Well, please see below the goals I have with this draft.

Do you think GTP does not deserve be documented in an Internet Draft?

The goals:

GTP is a protocol that is not documented at IETF.  It is described in 
3GPP documents.  This lack of IETF documentation generates a lot of 
problems.

One such problem immediately visible is the following: people claim 
IPv6-only access when actually their GTP is on IPv4 and just transports 
IPv6.

If there were an IETF document that said that GTP on IPv6 acts this and 
that way then there would be no confusion.

For example, we never confuse DHCPv4 for DHCPv6 or vice-versa, nor RIPng 
for RIP, nor ND for ARP,  because we have distinct IETF documents for each.

Another aspect that may be interesting is the following: IANA reserves a 
port number for GTP, but GTP is not specified at IETF.  This would 
probably be clarified, _if_ there were a document.

As for the 'Standards Track' intention - I think it would be the right 
track because GTP is in widespread use.  It is true that GTP-IPv6 is not 
deployed anywhere, and that would not make it even a 'Proposed Standard' 
status.  But in order to understand that, then one may need to 
understand what is GTP-IPv6 first.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 14 May 2018 13:07:31 +0200 (CEST)

On Mon, 14 May 2018, Alexandre Petrescu wrote:

> One such problem immediately visible is the following: people claim IPv6-only 
> access when actually their GTP is on IPv4 and just transports IPv6.

GTP uses UDP. UDP can be carried over both IPv4 and IPv6. It's IP version 
agnostic. I don't understand why you keep going on and on about this 
distinction nobody else makes.

> If there were an IETF document that said that GTP on IPv6 acts this and that 
> way then there would be no confusion.

There is no confusion generally.

> As for the 'Standards Track' intention - I think it would be the right track 
> because GTP is in widespread use.  It is true that GTP-IPv6 is not deployed 
> anywhere, and that would not make it even a 'Proposed Standard' status.  But 
> in order to understand that, then one may need to understand what is GTP-IPv6 
> first.

Yes, keep on calling people who claim they use GTPoUDPoIPv6 liars. It's a 
great way to make friends.

---

From: John Grant <[email-masked]>
Date: Mon, 14 May 2018 12:13:47 +0100

On 14/05/2018 11:44, Alexandre Petrescu wrote:

[snip]

> 3GPP documents.  This lack of IETF documentation generates a lot of 
Why? Anyone can download 3GPP documents for free (even if they're still 
using IPv4).

Most SDOs can make normative reference to other groups' documents 
provided (a) the documents are publicly available and (b) there's an 
identifiable mechanism for maintaining them. Republishing as parallel 
text is a bad idea; IEEE 802 and ISO 8802 were never in sync, for instance.

> IPv6-only access when actually their GTP is on IPv4 and just 
> transports IPv6.
GTP provides a tunnel between the User Equipment and the Packet GateWay, 
which is a work-around for IP identifying the point of attachment 
instead of the device, devices frequently changing their point of 
attachment, and the lack of a clean interface between layers 3 and 4. 
There's no reason to use the same technology to implement the tunnel as 
is used for the packets it carries. Switching the layers below GTP to 
IPv6 would make no difference apart from increasing overheads because 
IPv6 headers are bigger.

-- 
John Grant
Chair, ETSI ISG NGP

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 14 May 2018 13:19:34 +0200 (CEST)

> IPv6 would make no difference apart from increasing overheads because 

The important part is that there is no problem to solve here. A vendor or 
operator can implement GTP over IPv4 or IPv6, and this is already being 
done. 3GPP documents are completely address family agnostic and there is 
no confusion amongst vendors of equipment how all of this should be done 
if they decide to implement GTPoUDPoIPv6 and/or GTPoUDPoIPv4.

This has been pointed out to Alexandre by me and others, numerous times. I 
don't understand why this keeps coming up.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 May 2018 13:30:27 +0200

Le 14/05/2018 à 13:07, Mikael Abrahamsson a écrit :
> GTP uses UDP. UDP can be carried over both IPv4 and IPv6. It's IP 
> version agnostic. I don't understand why you keep going on and on about 
> this distinction nobody else makes.

Er?

Because UDP of GTP _can_ run over IPv6 does not mean it does.

>> If there were an IETF document that said that GTP on IPv6 acts this 
>> and that way then there would be no confusion.
> 
>> track because GTP is in widespread use.  It is true that GTP-IPv6 is 
>> not deployed anywhere, and that would not make it even a 'Proposed 
>> Standard' status.  But in order to understand that, then one may need 
>> to understand what is GTP-IPv6 first.
> 
> Yes, keep on calling people who claim they use GTPoUDPoIPv6 liars. It's 
> a great way to make friends.

No again, I am not impolite and I dont call anyone liar.

Can I see GTPoUDPoIPv6?  What is the port number?

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 May 2018 13:31:17 +0200

Le 14/05/2018 à 13:19, Mikael Abrahamsson a écrit :
[...]
> This has been pointed out to Alexandre by me and others, numerous times. 

Please remind me, sorry I missed?

Alex

> I don't understand why this keeps coming up.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Mon, 14 May 2018 13:43:44 +0200 (CEST)

> Please remind me, sorry I missed?

We can start with:

https://www.ietf.org/mail-archive/web/5gangip/current/msg01013.html

You keep saying there is no GTP over IPv6, so it means you're saying these 
people are lying when they claim to be doing GTP over IPv6.

---

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 14 May 2018 14:32:37 +0200

Le 14/05/2018 à 13:13, John Grant a écrit :
>> GTP is a protocol that is not documented at IETF.  It is described
>> in 3GPP documents.  This lack of IETF documentation generates a lot
>> of problems.
> 
> Why? Anyone can download 3GPP documents for free (even if they're
> still using IPv4).

Yes, it is free access (no money).  But it is Word .doc documents.

At this time I am inclined for IPv6 access to ASCII files, instead of 
IPv4 access to .doc documents.

>  identifiable mechanism for maintaining them. Republishing as
> parallel text is a bad idea;

I wonder which of those two parallel documents would IANA refer when
reserving a port number?

> IEEE 802 and ISO 8802 were never in sync, for instance.

I did not know ISO 8802 existed.

> GTP provides a tunnel between the User Equipment and the Packet

Well, again, at the risk of upsetting Mikael, I do not think GTP happens
to UE.  I think neither the baseband processor in the UE nor the 
application processor in the UE are GTP endpoints.

You may think differently, but if you say so, I will ask you to explain
me why you think so.

For my part, the UEs I use give me a certain level of control to the
application processor and to the baseband processor (modem) and they
dont seem to run GTP.

We explained this in a draft posted to the IETF official website.  In
that draft we say that GTP runs between the SGW and the PGW.

https://tools.ietf.org/html/draft-shytyi-v6ops-danir-01

It says this:
> To reach the PGW from the UE the DHCPv6 packets are encapsulated by
> SGW into UDP/IPv4 packets; this encapsulation is for the GTP-U
> tunnel.

If you think this is wrong (GTP is not run on SGW) then please explain 
why you think so and then we will correct the draft.

> attachment,

IP identifies an address.

I do not understand what do you mean by IP identifying a point of 
attachment, instead of identifying a device.

> and the lack of a clean interface between layers 3 and 4.
>  There's no reason to use the same technology to implement the tunnel
> as is used for the packets it carries. Switching the layers below GTP
> to IPv6 would make no difference apart from increasing overheads
> because IPv6 headers are bigger.

Well, yes, but if the overall increase is 1% then it is not that worrysome.

But mentioning there could be overhead may mean that some GTP does 
prefer to not use IPv6 because of that overhead?

Alex

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Mon, 14 May 2018 16:24:28 +0000

> -----Original Message-----
> From: 5gangip <[email-masked]> On Behalf Of Alexandre
> Petrescu
> Sent: Monday, May 14, 2018 5:33 AM
> To: [email-masked]
> Subject: Re: [5gangip] Reviewing GTP (was: re: Notes from today's meeting)
> 
> 
> 
> > text is a bad idea;
> Well, again, at the risk of upsetting Mikael, I do not think GTP happens to UE.
> I think neither the baseband processor in the UE nor the application
> processor in the UE are GTP endpoints.
> 
> You may think differently, but if you say so, I will ask you to explain me why
> you think so.
> 
> For my part, the UEs I use give me a certain level of control to the application
> processor and to the baseband processor (modem) and they dont seem to
> run GTP.
> 
> We explained this in a draft posted to the IETF official website.  In that draft
> we say that GTP runs between the SGW and the PGW.
[[email-masked]] Two tunnels one GTP-U tunnel from eNB to SGW (control plane comes via MME using GTP-C) and (if remote) and second set (GTP-U & GTP-C) to PGW. Often it is possible to collapse the SGW and PGW and that often eliminates the actual GTP tunnel between them because it is typically a combined process SPGW which just completely eliminates that extra work.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__tools.ietf.org_html_draft-2Dshytyi-2Dv6ops-2Ddanir-
> 2D01&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=Wcd4JNmbXOU7PaD
> V-b4IZFZ32-
> 2PaZpXkReSES0kQNk&s=sv02HpZNwhRpNmKWryKi9Zf2lSxH_LNplQRu9mY9Z
> QQ&e=
> 
> It says this:
> > SGW into UDP/IPv4 packets; this encapsulation is for the GTP-U tunnel.
> 
> If you think this is wrong (GTP is not run on SGW) then please explain why
> you think so and then we will correct the draft.
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIGaQ&c=LFYZ-
> o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=Wcd4JNmbXOU7PaD
> V-b4IZFZ32-
> 2PaZpXkReSES0kQNk&s=o78cLtNuGwQgido1D1X78zIVHItj8ubxR4BYVF9dpF8
> &e=

---

From: Shunsuke Homma <[email-masked]>
Date: Tue, 15 May 2018 19:28:01 +0900

Hi Alex,

I think that there is no sense if its goal is republication of existing 
document (even if it's one of other SDO), but it would be useful if the 
document discribes clarification of issues/problems which GTP has in 
current mobile networks. And, it would be work which should be proceeded 
in 5gangip.

Regards,

Shunsuke

On 2018/05/14 19:44, Alexandre Petrescu wrote:
>> since you've uploaded IETF draft formatted text to somewhere else), 
>> then please don't bring it up at IETF discussion groups and call it a 
>> "draft".
> 

-- 
----------------------------------
Shunsuke Homma
<[email-masked]>
TEL: +81 422 59 3486
FAX: +81 422 60 7460

NTT Network Service Systems Labs.
Musashino city, Tokyo, Japan
----------------------------------

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 15 May 2018 20:13:38 +0200

Thank you for the half-half direction.  I agree with the second half: 
identify GTP issues.

I would like to express that this represents some work to do.

The easiest way to perform this work is to analyze a packet dump, and 
describe it in English.  A packet dump is like a radiography of a 
protocol: we see many things inside and understand what is going on, 
without much speculation.

For this reason, I would like to ask you, if you ever have some chance 
to come see a packet dump of GTPoUDPoIPv6, or even over IPv4, then that 
would be of significant help.

For my part, I can obtain packet dumps of GTPoUDPoIPv4 captured on the PGW.

This will help us to make clear between which entities GTP runs (PGW is 
sure, but UE?  SGW?  eNodeB?), its MTU and other aspects.

Even the simplest fact that somebody else than me shows a GTP packet 
dump is very helpful - it shows there is interoperability.

That would be a significant help.

Alex

Le 15/05/2018 à 12:28, Shunsuke Homma a écrit :
>> Whether or not it becomes an IETF submission depends on the readers.  
>> If enough people show interest then so it will be, otherwise no.
>>
>> For example, we never confuse DHCPv4 for DHCPv6 or vice-versa, nor 
>> RIPng for RIP, nor ND for ARP,  because we have distinct IETF 
>> documents for each.
>>
>> Another aspect that may be interesting is the following: IANA reserves 
>> a port number for GTP, but GTP is not specified at IETF.  This would

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 May 2018 21:22:35 +0200 (CEST)

> sure, but UE?  SGW?  eNodeB?), its MTU and other aspects.

GTP never runs to the UE.

3G:

SGSN/GGSN <-GTP-> RNC <-RLC-> eNB <-RLC-> UE

LTE:

SPGW <-GTP-> eNB <-RLC-> UE

Its MTU will depend on operational decisions for the unique deployment. 
Same thing with if it's running over IPv4 or IPv6. It doesn't matter to 
the end user. It can be a network with some eNB connecting via IPv4 and 
some via IPv6.

It just doesn't matter. It's all UDP.

http://dpdk-test-plans.readthedocs.io/en/latest/ddp_gtp_test_plan.html#gtp-u-data-packet-types-ipv6-transport-ipv6-payload

Does this help for you to understand how these packets are put together?

For v6:

p=Ether()/IPv6()/UDP(dport=2152)/GTP_U_Header()/IPv6()/Raw('x'*20)

for v4:

p=Ether()/IP()/UDP(dport=2152)/GTP_U_Header()/IPv6()/Raw('x'*20)

It's the same thing, it's all UDP with GTP as payload. The only thing that 
changes is if it's IPv4 or IPv6 on the outside.

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 15 May 2018 12:32:46 -0700

> SPGW <-GTP-> eNB <-RLC-> UE

Acroymn overload. With enough thrust anything can fly.  ;-)

Dino

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 15 May 2018 21:44:05 +0200

Le 15/05/2018 à 21:22, Mikael Abrahamsson a écrit :
>> This will help us to make clear between which entities GTP runs (PGW 
>> is sure, but UE?  SGW?  eNodeB?), its MTU and other aspects.
> 

IT is good to know.

I think we are now safe to say so in the GTP draft.  Most opinions that 
I have read do say so.

This is very important to know when talking to UE (modem) manufacturers. 
  They are _not_ concerned by GTP.

> Does this help for you to understand how these packets are put together?

It is useful.  I have to look at it in more detail.

But it looks like a test plan, something somebody generates in order to 
test some equipment.  It's not a packet dump in a real operating network?

> p=Ether()/IP()/UDP(dport=2152)/GTP_U_Header()/IPv6()/Raw('x'*20)

YEs, they look - conceptually - like my packet dumps.  It's great!

But my packet dumps show the src port too to be 2152.  Do they use the same?

> It's the same thing, it's all UDP with GTP as payload. The only thing 
> that changes is if it's IPv4 or IPv6 on the outside.

Yes, in principle.

In IETF tunnelling protocols there is a field that tells which protocol 
IPv4 or IPv6 is carried.  For GTP, I have to study dumps to see whether 
there is such a field in GTP header too.  Or you may know better.

That is the difference between IPv4 and IPv6 carried in GTP.

You may find it minor but for me it is worth exploring.

Alex

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 May 2018 21:48:16 +0200 (CEST)

On Tue, 15 May 2018, Alexandre Petrescu wrote:

> I think we are now safe to say so in the GTP draft.  Most opinions that I 
> have read do say so.
>

Instead of trying to poll opinions in this WG regarding these facts, why 
don't you instead read the 3GPP documents to get the actual design? It's 
freely available.

> test some equipment.  It's not a packet dump in a real operating 

No, and it seems nobody is interested in giving you that. So either you 
keep going on and on and on about it, or you just read the documentation 
on how it's designed and supposed to work, and trust that.

> In IETF tunnelling protocols there is a field that tells which protocol IPv4 
> or IPv6 is carried.  For GTP, I have to study dumps to see whether there is 
> such a field in GTP header too.  Or you may know better.
>

So read the 3GPP documentation. I have several times historically pointed 
you to documents where this is described. Instead of trying to reverse 
engineer things from packet dumps, read the design documents.

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 15 May 2018 21:58:01 +0200

Le 15/05/2018 à 21:48, Mikael Abrahamsson a écrit :
>> I think we are now safe to say so in the GTP draft.  Most opinions 
>> that I have read do say so.
>>
>> This is very important to know when talking to UE (modem) 
>> manufacturers. They are _not_ concerned by GTP.
> 
>> But it looks like a test plan, something somebody generates in order 
>> to test some equipment.  It's not a packet dump in a real operating 
>> network?
> 
>> In IETF tunnelling protocols there is a field that tells which 
>> protocol IPv4 or IPv6 is carried.  For GTP, I have to study dumps to 
>> see whether there is such a field in GTP header too.  Or you may know 
>> better.
>>
> So read the 3GPP documentation. I have several times historically 
> pointed you to documents where this is described. Instead of trying to 
> reverse engineer things from packet dumps, read the design documents.

Mikael - thank you for the pointers up to now.

Let us see later.

Alex

---

From: Shunsuke Homma <[email-masked]>
Date: Wed, 16 May 2018 17:04:03 +0900

Hi Alex,

Thank you for your reply.

Regarding GTP packet format, if there are some differences between dump 
and the standard document or the standard document has several parts 
where is not clearly described, dump example would be helpful to 
understand actual GTP-based network structure. Especially, non network 
operator can hardly see such dump, and it would be useful. However, 
please note that it shouldn't be vender specific but should be general one.

In addition, I'd like to know architectural benefits and issues on GTP. 
For example, why current GTP-based network makes some anchor points or 
why ID/LOC protocols would be sperior to GTP-based forwarding mechanism. 
The clarification would be beneficial to improve ID/LOC and it would be 
also help to propose ID/LOC to mobile network.

Regards,

Shunsuke

On 2018/05/16 3:13, Alexandre Petrescu wrote:
>> I think that there is no sense if its goal is republication of 
>> existing document (even if it's one of other SDO), but it would be 
>> useful if the document discribes clarification of issues/problems 
>> which GTP has in current mobile networks. And, it would be work which 
>> should be proceeded in 5gangip.
>>
>> Regards,
>>
>> Shunsuke
>>
>>
>>>> then please don't bring it up at IETF discussion groups and call it 
>>>> a "draft".
>>>
>>> Another aspect that may be interesting is the following: IANA 
>>> reserves a port number for GTP, but GTP is not specified at IETF.  
>>> This would probably be clarified, _if_ there were a document.
>>>
>>> As for the 'Standards Track' intention - I think it would be the 
>>> right track because GTP is in widespread use.  It is true that 
>>> GTP-IPv6 is not deployed anywhere, and that would not make it even a 
>>> 'Proposed Standard' status.  But in order to understand that, then 
>>> one may need to understand what is GTP-IPv6 first.
>>>
>>> Alex
>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 May 2018 12:41:47 +0200

Hi Mikael,

This is my reply.

Le 15/05/2018 à 21:48, Mikael Abrahamsson a écrit :
>>>> This will help us to make clear between which entities GTP runs
>>>> (PGW is sure, but UE?  SGW?  eNodeB?), its MTU and other
>>>> aspects.
>>> 
> Instead of trying to poll opinions in this WG regarding these facts,
> why don't you instead read the 3GPP documents to get the actual
> design? It's freely available.

Because some times the specs are not implemented as intended by the 
specifier.

But I agree with you in an ideal world it is is much easier to read the 
spec to understand the behaviour, rather than reverse engineering 
reading the packets and write the spec.  It would be so easy.

>> But it looks like a test plan, something somebody generates in
>> order to test some equipment.  It's not a packet dump in a real
>> operating network?
> 
> No, and it seems nobody is interested in giving you that. So either
> you keep going on and on and on about it, or you just read the
> documentation on how it's designed and supposed to work, and trust
> that.

I trust that to a large extent, but some times there are issues.

For example, the 3GPP spec says "The UDP Source Port is a locally
allocated port number at the sending GSN/RNC."

In my BSD socket Unix inclined parlance 'locally allocated' means that
the kernel randomly chooses such a number.

However, my packet dump shows that Source Port to be precisely the same
as the Destination Port, i.e. 2152, which is not 'locally allocated' but
'centrally allocated', at IANA.

What do you think about this?

By chance is the DPDK test plan also using Source Port precisely the
same as the Destination Port?

Alex

>> protocol IPv4 or IPv6 is carried.  For GTP, I have to study dumps
>> to see whether there is such a field in GTP header too.  Or you may
>> know better.
>> 
> pointed you to documents where this is described. Instead of trying
> to reverse engineer things from packet dumps, read the design
> documents.
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 May 2018 13:38:22 +0200 (CEST)

> reading the packets and write the spec.  It would be so easy.

Yes, so why not try it?

For instance:

http://www.cse.unt.edu/~rdantu/FALL_2013_WIRELESS_NETWORKS/LTE_Alcatel_White_Paper.pdf

"4. Protocol architecture, figure 6".

It has a nice overview of where the GTP tunnel is terminated. If you would 
have read that, you wouldn't have to ask whether the GTP tunnel goes to 
the UE or not.

> What do you think about this?

I think you're focusing on irrelevant minute details that are probably 
implementation specific or there is just some best common practice.

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 May 2018 13:50:37 +0200

Le 16/05/2018 à 13:38, Mikael Abrahamsson a écrit :
>> But I agree with you in an ideal world it is is much easier to read 
>> the spec to understand the behaviour, rather than reverse engineering 
> It has a nice overview of where the GTP tunnel is terminated. If you 
> would have read that, you wouldn't have to ask whether the GTP tunnel 
> goes to the UE or not.
> 
>> However, my packet dump shows that Source Port to be precisely the 
>> same as the Destination Port, i.e. 2152, which is not 'locally 
>> allocated' but 'centrally allocated', at IANA.
>>

Probably these are implementation specific, or just some best common 
practice.

I will now write down that, contrary to the 3GPP spec, the src port 
number MUST be 2152.

I hope you will not mind that.

Alex

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Wed, 16 May 2018 12:32:14 +0000

Hi Alex,

A short intro - I am Sridhar Bhaskaran. 3GPP CT4 delegate.

On,
>> allocated' but 'centrally allocated', at IANA.

"Locally allocated" means the sender of the packet determines the src port based on local configuration. It can be any ephemeral source port or it can be any fixed source port determined by configuration. It is a matter of deployment / implementation decision.

On the other hand specifying:

>> I will now write down that, contrary to the 3GPP spec, the src port number MUST be 2152.

Is completely wrong. 3GPP spec is not mandating that source port MUST be 2152. GTPU is used within walled gardens of an operator. Why does what source port an operator use matter at all?

On a general note: I agree with the sentiments of many in this thread. Reverse engineering and specifying an already well defined protocol will tread down the path of duplicate work + also risk getting into gross contradictions (like the one you are intending above).

Thanks
Sridhar

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, May 16, 2018 5:21 PM
To: Mikael Abrahamsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] Reviewing GTP (was: re: Notes from today's meeting)

> implementation specific or there is just some best common practice.

Probably these are implementation specific, or just some best common practice.

I will now write down that, contrary to the 3GPP spec, the src port number MUST be 2152.

Alex

---

From: Sridhar Bhaskaran <[email-masked]>
Date: Wed, 16 May 2018 12:37:47 +0000

To highlight further - 3GPP TS 29.281 (http://www.3gpp.org/ftp/Specs/archive/29_series/29.281/29281-f20.zip) clearly states:

4.4.2.0	General
For the messages described below, the UDP Source Port (except as specified for the Echo Response message) may be allocated either statically or dynamically by the sending GTP-U entity.
 >>> NOTE:	Dynamic allocation of the UDP source port can help balancing the load in the network, depending on network deployments and network node implementations. <<<

4.4.2.2	Echo Response Message
The UDP Destination Port value shall be the value of the UDP Source Port of the corresponding request message.
>>The UDP Source Port shall be the value from the UDP Destination Port of the corresponding request message.<<

There is a clear informative NOTE that using dynamic source port helps in load balancing (for e.g use 5 tuple hash based path selection). If you now mandate that 2152 MUST be used as source port it breaks this.

Thanks
Sridhar
-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Sridhar Bhaskaran
Sent: Wednesday, May 16, 2018 6:02 PM
To: Alexandre Petrescu <[email-masked]>; Mikael Abrahamsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] Reviewing GTP (was: re: Notes from today's meeting)

Hi Alex,

On,

Thanks
Sridhar

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Wednesday, May 16, 2018 5:21 PM
To: Mikael Abrahamsson <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] Reviewing GTP (was: re: Notes from today's meeting)

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 May 2018 15:34:00 +0200

Hi,

FWIW: the message in my packet dump is not a response, but an initiation.

With respect to load-balancing: I can agree.

But with respect to security, do you agree that GTP messages should be 
secured?

Alex

Le 16/05/2018 à 14:37, Sridhar Bhaskaran a écrit :
> To highlight further - 3GPP TS 29.281
> (http://www.3gpp.org/ftp/Specs/archive/29_series/29.281/29281-f20.zip)
> clearly states:
> 
> 4.4.2.0	General For the messages described below, the UDP Source Port
> (except as specified for the Echo Response message) may be allocated
> either statically or dynamically by the sending GTP-U entity.
>>>> NOTE:	Dynamic allocation of the UDP source port can help
>>>> balancing the load in the network, depending on network
>>>> deployments and network node implementations. <<<
> 
> 4.4.2.2	Echo Response Message The UDP Destination Port value shall be
> the value of the UDP Source Port of the corresponding request
> message.
>>> The UDP Source Port shall be the value from the UDP Destination
>>> Port of the corresponding request message.<<
> 
> There is a clear informative NOTE that using dynamic source port
> helps in load balancing (for e.g use 5 tuple hash based path
> selection). If you now mandate that 2152 MUST be used as source port
> it breaks this.
> 
> Thanks Sridhar -----Original Message----- From: 5gangip
> [mailto:[email-masked]] On Behalf Of Sridhar Bhaskaran 
> Sent: Wednesday, May 16, 2018 6:02 PM To: Alexandre Petrescu
> <[email-masked]>; Mikael Abrahamsson
> <[email-masked]> Cc: [email-masked] Subject: Re: [5gangip]
> Reviewing GTP (was: re: Notes from today's meeting)
> 
> Hi Alex,
> 
> "Locally allocated" means the sender of the packet determines the src
> port based on local configuration. It can be any ephemeral source
> port or it can be any fixed source port determined by configuration.
> It is a matter of deployment / implementation decision.
> 
> Is completely wrong. 3GPP spec is not mandating that source port MUST
> be 2152. GTPU is used within walled gardens of an operator. Why does
> what source port an operator use matter at all?
> 
> On a general note: I agree with the sentiments of many in this
> thread. Reverse engineering and specifying an already well defined
> protocol will tread down the path of duplicate work + also risk
> getting into gross contradictions (like the one you are intending
> above).
> 
> Thanks Sridhar
> 
> -----Original Message----- From: 5gangip
> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu 
> Sent: Wednesday, May 16, 2018 5:21 PM To: Mikael Abrahamsson
> <[email-masked]> Cc: [email-masked] Subject: Re: [5gangip]
> Reviewing GTP (was: re: Notes from today's meeting)
> 
> 
> 
>>> But I agree with you in an ideal world it is is much easier to
>>> read the spec to understand the behaviour, rather than reverse
>>> engineering reading the packets and write the spec.  It would be
>>> so easy.
>> 
>> Yes, so why not try it?
>> 
>> For instance:
>> 
>> http://www.cse.unt.edu/~rdantu/FALL_2013_WIRELESS_NETWORKS/LTE_Alcatel
>>
>> 
_White_Paper.pdf
>> It has a nice overview of where the GTP tunnel is terminated. If
>> you would have read that, you wouldn't have to ask whether the GTP
>> tunnel goes to the UE or not.
>> 
>>> However, my packet dump shows that Source Port to be precisely
>>> the same as the Destination Port, i.e. 2152, which is not
>>> 'locally allocated' but 'centrally allocated', at IANA.
>>> 
>> I think you're focusing on irrelevant minute details that are
>> probably implementation specific or there is just some best common
>> practice.
> 
> _______________________________________________ 5gangip mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/5gangip 
> _______________________________________________ 5gangip mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 May 2018 15:35:59 +0200

Hi Sridhar,

Thank you for your message.

I am happy a 3GPP representative looks at this.

> It is a matter of deployment / implementation decision.

That sounds a little bit weird to me.

> be 2152.

YEt that's what implementation does.  The src port is always 2152.  I 
would love to see a packet dump in which the src port number is not 2152.

> GTPU is used within walled gardens of an operator.

Yes.

> Why does

I find surprising that question is asked.  The GTP specification should 
say what port numbers are used.  And the implementation should follow 
it, not?

> getting into gross contradictions (like the one you are intending

Let me assure you I am not looking into creating problems.  I am more 
into solving issues.

Alex

_White_Paper.pdf

---

From: Tom Herbert <[email-masked]>
Date: Wed, 16 May 2018 07:12:51 -0700

> say what port numbers are used.  And the implementation should follow

Other UDP encapsulation protocols (GUE, LISP, Geneve, VXLAN, etc.) set the
source port to be an entropy value corresponding to the encapsulated inner
flow-- something like a hash over the encapsulated four tuple. This is done
to get flow based ECMP routing through the network. It works quite well.

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 May 2018 16:23:41 +0200

Le 16/05/2018 à 16:12, Tom Herbert a écrit :
> 
> 
> On Wed, May 16, 2018, 6:36 AM Alexandre Petrescu 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi Sridhar,
> 
> Other UDP encapsulation protocols (GUE, LISP, Geneve, VXLAN, etc.) set 
> the source port to be an entropy value corresponding to the encapsulated 
> inner flow-- something like a hash over the encapsulated four tuple. 
> This is done to get flow based ECMP routing through the network. It 
> works quite well.

We could consider that too.

We could also consider QUIC instead of UDP for GTP.

I guess QUIC was invented for some reason that would apply to GTP as well...

Alex

>      > [mailto:[email-masked]
>     <mailto:[email-masked]>] On Behalf Of Alexandre Petrescu
>      > <[email-masked] <mailto:[email-masked]>> Cc: [email-masked]
>     <mailto:[email-masked]> Subject: Re: [5gangip]
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 16 May 2018 09:33:22 -0500

Again cleaned up the cc list which was getting crowded.

On Wed, May 16, 2018 at 9:23 AM, Alexandre Petrescu <
[email-masked]> wrote:

>> [email-masked] <mailto:[email-masked]>>
>> wrote:
>>
>>     Hi Sridhar,
>>
>> inner flow-- something like a hash over the encapsulated four tuple. This
>> is done to get flow based ECMP routing through the network. It works quite
>> well.
>>
>
As Shunsuke said this document should not aim at improving GTP but rather
it should point out the issues, problems that its causes and should
hopefully pave the way for a better data plane protocol that is not
tunneling based.

Regarding getting a packet dump, since GTP-U operates inside an operator
network the data would probably contain somewhat private information to the
operator and that points to difficulties in getting such data. Before
giving out such data they should clean it up, let's see if we can have any
luck on that.

Maybe Terry can help.

Behcet

---

From: Tom Herbert <[email-masked]>
Date: Wed, 16 May 2018 08:02:43 -0700

> I guess QUIC was invented for some reason that would apply to GTP as well...
Alexandre,

QUIC is a UDP based transport protocol at the same level as TCP. It
might be appropriate for the control plane, but not as a user plane
encapsulation.

If the GTPU protocol were being developed from scratch in IETF today
we would probably be pushing to use an an existing UDP encapsulation,
such as GUE, that is extensible for use case specific options and has
thought through the issues of IP encapsulation (UDP checksum handling,
ECMP, diffserv propagation, tunnel MTU and fragmentation, congestion
control, header security, performance optimizations, cost of TLVs in
the datapath, etc.). But this clearly isn't the case with GTP. It's a
well entrenched protocol for a narrow use case and not an IETF
protocol. Honestly, I'm not sure that an effort in IETF to improve
upon it or even document it in an RFC would have any effect.

Tom

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 16 May 2018 10:37:17 -0500

Hi Alex,

On Wed, May 16, 2018 at 10:02 AM, Tom Herbert <[email-masked]> wrote:

> the
Right.

I think the soft belly of GTP is the 14 bits they have added to UDP header.
They should be discussed in the draft as to why they are there and their
use, touching from QoS to mobility control, policy, etc. This discussion
could point to packet dumps if we get them.

Then some of the above considerations from Tom's mail.
Finally it should point out the issues mainly because of UDP tunneling and
so on.

I don't know if it would have any effect but I expect it could be useful to
us.

Behcet

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 May 2018 19:38:34 +0200

> upon it or even document it in an RFC would have any effect.

I do not intend to improve the GTP protocol.

I intend to document how works a very small part of GTP, namely 
GTP-U-over-UDP-over-IPv4 that transports IPv6.  That's all I have.

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 16 May 2018 19:39:22 +0200

Le 16/05/2018 à 17:37, Behcet Sarikaya a écrit :
> Hi Alex,
> 
> 
> On Wed, May 16, 2018 at 10:02 AM, Tom Herbert <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>      >> <[email-masked]
>     <mailto:[email-masked]>
>     <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >>
>      >>     Hi Sridhar,
>      >>
>      >>      > Hi Alex,
>      >>      >
>      >>      > A short intro - I am Sridhar Bhaskaran. 3GPP CT4 delegate.
>      >>      >
>      >>      > On,
>      >>      >>>>> However, my packet dump shows that Source Port to be
>      >>      >>>>> precisely the
>      >>      >>> same as the Destination Port, i.e. 2152, which is not
>     'locally
>      >>      >>> allocated' but 'centrally allocated', at IANA.
>      >>      >
>      >>      > "Locally allocated" means the sender of the packet
>     determines the
>      >> src
>      >>      > port based on local configuration. It can be any
>     ephemeral source
>      >>      > port or it can be any fixed source port determined by
>      >> configuration.
>      >>      > It is a matter of deployment / implementation decision.
>      >>
>      >>      > On the other hand specifying:
>      >>      >
>      >>      >>> I will now write down that, contrary to the 3GPP spec,
>     the src
>      >>      >>> port number MUST be 2152.
>      >>      >
>      >>      > Is completely wrong. 3GPP spec is not mandating that
>     source port
>      >> MUST
>      >>      > be 2152.
>      >>
>      >>     would love to see a packet dump in which the src port number
>     is not
>      >>     2152.
>      >>
>      >>      > GTPU is used within walled gardens of an operator.
>      >>
>      >>     Yes.
>      >>
>      >>      > Why does
>      >>      > what source port an operator use matter at all?
>      >>
> I think the soft belly of GTP is the 14 bits they have added to UDP 
> header. They should be discussed in the draft as to why they are there 
> and their use, touching from QoS to mobility control, policy, etc. This 
> discussion could point to packet dumps if we get them.
> 
> Finally it should point out the issues mainly because of UDP tunneling 
> and so on.
> 
> I don't know if it would have any effect but I expect it could be useful 
> to us.

I agree.

Alex