Re: [5gangip] IPv6 GTP-C/GTP-U

[<[e-mail]>]

Hi Alex and Charlie,
what came to my mind was to ask authors of draft https://tools.ietf.org/html/draft-ietf-intarea-tunnels-08, Joe and Mark, whether they would agree to also include 3GPP protocol GTP (description and issues) in that a draft … what do you think?
Perhaps for that we could rely on existing old drafts mentioned below?
Thanks!
Best Regards
Dirk 

-----Original Message-----
From: 5gangip [mailto:[e-mail]] On Behalf Of Alexandre Petrescu
Sent: Donnerstag, 25. Januar 2018 10:28
To: 
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

Le 24/01/2018 à 23:19, Charlie Perkins a écrit :
> Hello Alex and all,
> 
> Long ago, we did write an Internet Draft describing GTP-U and 
> submitted it to Mobile IP working group as an alternative 
> encapsulation mechanism.  It was pretty easy to write but no one 
> cared.

Hi Charlie, it is good to know.

I think you mean this draft?
draft-casati-gtp-00.txt

There is also this draft, but I dont think you mean this:
draft-perkins-mext-gtpdata-00.txt

For draft-casati:
- we could update to say "GPRS Tunneling Protocol" instead of "Generic
   Tunneling Protocol"
- we could make sure the packet header described in the draft is the
   same as the packet header captured on PGW.

Described packet in draft-casati-gtp-00:
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Ver|*|*|*|S|R|     Type      |          Length               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Tunnel          Identifier                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Sequence Number         |          Resv/Exp             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

vs

Captured packet on PGW:
Thursday November 30 2017
INBOUND>>>>>  15:42:56:069 Eventid:142004(3)
GTPU Rx PDU, from IPv4_Address:40000 to IPv4_Address_2:2152 (159) TOS:a
TEID: 0x8000C124, Message type: GTP_TPDU_MSG (0xFF) Sequence Number:: NA GTP HEADER FOLLOWS:
              Version number: 1
               Protocol type: 1 (GTP C/U)
        Extended header flag: Not present
        Sequence number flag: Not present
            NPDU number flag: Not present
                Message Type: 0xFF (GTP_TPDU_MSG)
              Message Length: 0x0097 (151)
                   Tunnel ID: 0x8000C124 GTP HEADER ENDS.

> Writing a draft for GTP-C would be a tedious task, and I didn't see 
> anyone clamoring for it.

I agree, there seems to be clamor (shout) against it rather than for it :-)

If GTP-Control is difficult, maybe GTP-User is easier.

> Unless IETF would have change control, such drafts would be purely 
> informational.
 >
> And then if published as an Informational RFC, why would someone refer 
> to the RFC instead of the 3GPP document?

Because I suppose programmer is accessing a txt Internet Draft easier than a zip 3GPP document, technically and legally.

Because IETF rather than 3GPP, more precisely IANA, allocates the UDP port numbers in order to attain interoperability.  It is thanks to these numbers that GTP-U implementers put there meaningful numbers.

For example, if one looks at IANA allocation port number for GTP-U, one sees number 2152 decimal, but there is nothing in column Reference.

On another hand, if one looks at IANA allocation port number for SSH, one sees number 22 decimal, with reference to RFC4251 (SSH Archi).

To me that represents a demand for an Internet Draft for GTP.

> Even so, if there becomes a need for an IETF document I am willing to 
> help.  On the other hand, if someone wants a version of GTP-U or GTP-C 
> for which IETF has control of revisions, that would quite interesting, 
> even simply to understand the motivation.

I agree.  Let me make the xml based from Behcet source and share with you.

Alex

> 
> Regards, Charlie P.
> 
> 
> On 1/24/2018 1:02 PM, Alexandre Petrescu wrote:
>> 
>> 
>> Le 24/01/2018 à 21:21, Vízdal Aleš a écrit :
>>> Please check the 3GPP technical spec 23.401 at 
>>> http://www.3gpp.org/ftp/Specs/archive/23_series/23.401/23401-f20.zip
>>> to understand the architecture and learn where GTP can be used.
>>> S1-U is GTP based as Arashmid stated.
>> 
>> Thanks for the reference.  I may cite it in the Internet Draft.
>> 
>> But it would be more useful if you provided a packet dump as I 
>> requested, instead of an architecture document.
>> 
>>> I share the view that an I-D on GTP over IPv4/6 is not needed, 
>>> however if you want one, noone can stop you from writing it.
>> 
>> The question I wonder is, if I write it, will anybody be interested 
>> in co-authoring, or maybe discuss it publicly?
>> 
>> Alex
>> 
>>> 
>>> Ales
>>> 
>>> On 24 Jan 2018, at 20:59, Alexandre Petrescu 
>>> <[e-mail] <mailto:[e-mail]>> 
>>> wrote:
>>> 
>>>> 
>>>> 
>>>> Le 24/01/2018 à 20:54, Arashmid Akhavain a écrit :
>>>>> S1U is 3GPP defined interface between eNB and SGW carrying user 
>>>>> plane traffic.
>>>> 
>>>> Well that is not where GTP runs as far as I know.
>>>> 
>>>> I understand GTP runs between SGW and PGW.  The GTP packet captures 
>>>> I have are made on PGW and contain a packet sent by the UE.  And 
>>>> that nobody can make me say it is a wrong
>>>> statement: it is a fact of matter.
>>>> 
>>>> Only an Internet Draft can lead to agree how this works.
>>>> 
>>>> Alex
>>>> 
>>>>> -----Original Message----- From: 5gangip 
>>>>> [mailto:[e-mail]] On Behalf Of Alexandre Petrescu 
>>>>> Sent: 24 January 2018 14:50 To: FIGURELLE, TERRY F <[e-mail] 
>>>>> <mailto:[e-mail]>>; Ca By <[e-mail] 
>>>>> <mailto:[e-mail]>>; [e-mail] 
>>>>> <mailto:[e-mail]> Cc:
>>>>> [e-mail] <mailto:[e-mail]>; [e-mail] 
>>>>> <mailto:[e-mail]> Subject: Re:
>>>>> [5gangip] IPv6 GTP-C/GTP-U Le 24/01/2018 à 17:58, FIGURELLE, TERRY 
>>>>> F a écrit :
>>>>>> We have deployed more than 20k eNB’s that use IPv6 only transport 
>>>>>> for S1-U
>>>>> What is S1-U?  Is it between PGW and SGW?
>>>>>> and all of our SGW’s and PGW’s support IPv6 transport for GTP-U 
>>>>>> and GTP-C.
>>>>> Which RFC is it? Alex We actually are working with Syniverse for 
>>>>> IPv6 IPX for S8. We
>>>>>> already have inter lab over production Syniverse IPX between AT&T 
>>>>>> and six other major telecoms (Bell Canada, Rogers, DoCoMo, etc.).
>>>>>> 
>>>>>> We are running  production VoLTE (ims APN) using IPv6
>>>>>> GTP-U|GTP-C with UE IPv6 only and the common general
>>>>>> purpose APN (nxtgenphone) supports IPv4 only, IPv6 only and 
>>>>>> currently IPv4v6 (deprecated by 3GPP). This includes two UE 
>>>>>> operating systems which cover 97% of the market share. Only 
>>>>>> handful of devices where certified for IPv4v6. All devices AT&T 
>>>>>> has certified since the launch or UMS support IPv4 only, IPv6 
>>>>>> only and “IPv4 or IPv6”. AT&T’s device requirements are 
>>>>>> considered the gold standard in the mobile industry. All of the 
>>>>>> major vendors for EPC support IPv6 GTP transport and we have 42 
>>>>>> million active subscribers running on a virtualize EPC (Intel 
>>>>>> COTS hardware, hypervisor,
>>>>>> etc.) that supports IPv6 GTP. Verizon, T-Mobile (USA) and Sprint 
>>>>>> also use IPv6.
>>>>>> 
>>>>>> GM’s OnStar uses IPv6 only VoLTE over IPv6 GTP-U in North America 
>>>>>> they use UE IPv4 only for the other APN’s but those still use 
>>>>>> IPv6 GTP-U in North America. BMW and other auto companies also 
>>>>>> support IPv6 GTP-U in North America. AT&T was the first to 
>>>>>> support LTE roaming and we helped Bell Canada and Rogers support 
>>>>>> it. We can use direct connections (IPX bypass) or Syniverse IPX 
>>>>>> for LTE roaming. There are a number of country specific IPX but 
>>>>>> Syniverse now supports interop with a large number of telecoms 
>>>>>> via their IPX or in conjunction with country specific IPX.
>>>>>> 
>>>>>> Ericson, Huawei, Samsung and Nokia all support IPv6 GTP-U eNB’s. 
>>>>>> Spirent, Tektronix and other test tool vendors all support IPv6 
>>>>>> GTP-C|GTP-U. IPv6 GTP has been supported for several years in 
>>>>>> GTP-C|production networks. It’s very common in Asian countries 
>>>>>> too.
>>>>>> 
>>>>>> Hopefully this ends the IPv6 GTP thread!!!
>>>>>> 
>>>>>> *Terry Figurelle*
>>>>>> 
>>>>>> *Lead Member of Technical Staff*
>>>>>> 
>>>>>> *Wireless Network Arch. & Design*
>>>>>> 
>>>>>> *Mobility Core*
>>>>>> 
>>>>>> *AT&T Services*
>>>>>> 
>>>>>> *[e-mail] <mailto:[e-mail]>* 
>>>>>> <mailto:[e-mail]>
>>>>>> 
>>>>>> *cell - [phone]*
>>>>>> 
>>>>>> *From:*5gangip [mailto:[e-mail]] *On Behalf Of 
>>>>>> *Ca By *Sent:* Wednesday, January 17, 2018 5:13 AM *To:* 
>>>>>> [e-mail] <mailto:[e-mail]> *Cc:* 
>>>>>> [e-mail] <mailto:[e-mail]>; 
>>>>>> [e-mail] 
>>>>>> <mailto:[e-mail]>; FIGURELLE, TERRY F 
>>>>>> <[e-mail] <mailto:[e-mail]>>; [e-mail] 
>>>>>> <mailto:[e-mail]> *Subject:*
>>>>>> Re: [5gangip] Problems I see
>>>>>> 
>>>>>> On Wed, Jan 17, 2018 at 12:33 AM <[e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>
>>>>>> wrote:
>>>>>> 
>>>>>> <dl> more ... </dl>
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>> _____________________________ From: Alexandre Petrescu 
>>>>>> <[e-mail] 
>>>>>> <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]>> Sent: Wednesday, January 
>>>>>> 17, 2018 8:08 am
>>>>>> 
>>>>>> 
>>>>>> Subject: Re: [5gangip] Problems I see
>>>>>> 
>>>>>> To: Lake D Mr (PG/R - Elec Electronic Eng) <[e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>> Cc: 
>>>>>> <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>>, 
>>>>>> <[e-mail] <mailto:[e-mail]> 
>>>>>> <mailto:[e-mail]>>, Nick HEATLEY <[e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]>>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Le 17/01/2018 à 08:51, [e-mail] 
>>>>>> <mailto:[e-mail]> <mailto:[e-mail]> a écrit 
>>>>>> : [...]
>>>>>> 
>>>>>>> (I am not asking whether they offer IPv6 service to
>>>>>> smartphone - I do
>>>>>>> know many operators offer IPv6 service to smartphone)
>>>>>>> 
>>>>>>> <dl> Utterly non-scientific test involving 5 mobile
>>>>>> contracts from 4
>>>>>>> of the UK operators (3 MNOs, one MVNO) shows not one
>>>>>> support IPv6 to
>>>>>>> the UE. </dl>
>>>>>> 
>>>>>> So, I learn in UK there is no IPv6 as a service offered to  
>>>>>> smartphones.
>>>>>> 
>>>>>> However, there may be some trials ongoing. One could ask, if I 
>>>>>> may refer, Nick HEATLEY from bt.com <http://bt.com> 
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bt.com&d=DwM
>>>>>> FaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=7w99vYkJ6
>>>>>> 0WM1FBGgy4J7mqT1275YbjBb8JT-wb3mnQ&s=Qbn7h7dkjelNV6G3WyrCCIkkGpi1
>>>>>> 85TxTqR2v3Jnlas&e=>,
>>>>>> 
>>>>>> 
>>>>>> who some times posts in v6ops WG. He often talks about IPv6.
>>>>>> 
>>>>>> <dl> quick call to friend at UK MvNO - they offer a fixed
>>>>>> IPv6 service at a cost - this allows a /64 to be allocated 
>>>>>> against an endpoint and apparently is used for IOT applications 
>>>>>> which require two-way connectivity.  This is a separate APN. 
>>>>>> </dl>
>>>>>> 
>>>>>> 
>>>>>>>> and for CUPS in the lab.
>>>>>>> 
>>>>>>> What is CUPS?
>>>>>>> 
>>>>>>> <dl> Control User-Plane Split.
>>>>>> 
>>>>>> Thanks for the definition.
>>>>>> 
>>>>>>> Fundamental building-block of 5G core architecture based which 
>>>>>>> allows different user-planes associated with a single
>>>>>> control plane,
>>>>>>> thereby allowing differing "services" to be offered across the 
>>>>>>> user-planes. HOWEVER, this is where the arguments start
>>>>>> (see IETF
>>>>>>> Netslices proto-WG list for nearly 2 years of arguments and 
>>>>>>> counter-arguments) as no-one is actually sure what the
>>>>>> "services"
>>>>>>> are. One theory is that we could offer different protocol
>>>>>>> 
>>>>>> support
>>>>>>> on different user-plane slices, but this is problematic now
>>>>>> that N3
>>>>>>> and N6 have been defined. The other is that we could offer
>>>>>> different
>>>>>>> grades of service but this presupposes that we can split
>>>>>>> 
>>>>>> traffic from
>>>>>>> the UE on a "session by session" or "application by
>>>>>> application"
>>>>>>> basis.
>>>>>>> 
>>>>>>> CUPS in 5G is the action of multiple UPFs against single
>>>>>>> 
>>>>>> AMF/SMF (or
>>>>>>> some combination of AMF+SMF leading to a single control-plane 
>>>>>>> instance). This allows scaling/placement of the UPF
>>>>>> independently of
>>>>>>> the control-plane elements.
>>>>>>> 
>>>>>>> CUPS is also being retro-fitted to 4G with the concept of
>>>>>>> 
>>>>>> SGWc/PGWc
>>>>>>> in the control plane and multiple SGWu/PGWu in the user-plane.
>>>>>> </dl>
>>>>>> 
>>>>>> Is GTP part of control plane or of data plane?
>>>>>> 
>>>>>> <dl> For 4G, Both.   GTP-u used on the S1 user-plane leg; 
>>>>>> GTP-c used between MME and SGW (S11 interface)   S1-MME
>>>>>> (eNB to MME for control plane uses SCTP.
>>>>>> 
>>>>>> In 5G, the interface from gNB to AMF is N2 which I haven’t
>>>>>> seen defined as yet (but will probably be SCTP as per
>>>>>> current S1-MME).
>>>>>> 
>>>>>> However, there is no functional equivalent to S11 in 5G as
>>>>>> the MME function has been broken out to AMF and SMF
>>>>>> elements and it is the SMF which communicates to the
>>>>>> multiple UPF over N4.
>>>>>> 
>>>>>> The protocol chosen for N4 is PFCP carrying dataplane
>>>>>> programming verbs (eg OpenFlow).
>>>>>> 
>>>>>> At least, this is my current understanding and I remain to
>>>>>> be corrected by anyone who knows more detail/recent
>>>>>> information.
>>>>>> 
>>>>>> I do not attend 3gpp so I rely on collecting information
>>>>>> from those around me who do - it is such a vast
>>>>>> organisation that it is sometime very difficult to keep
>>>>>> up-to-date.  </dl>
>>>>>> 
>>>>>> It’s somewhat like trying to contribute to rocket science
>>>>>> by attending a cricket game.
>>>>>> 
>>>>>> Both  rockets and cricket use physics, and anyone can
>>>>>> comment how it might work.
>>>>>> 
>>>>>> 
>>>>>> Alex
>>>>>> 
>>>>>> _______________________________________________ 5gangip
>>>>>> mailing list [e-mail] <mailto:[e-mail]>
>>>>>> <mailto:[e-mail]> 
>>>>>> https://www.ietf.org/mailman/listinfo/5gangip 
>>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mai
>>>>>> 
>>>>>> 
>>>>>> lman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxw
>>>>>> 
>>>>>> 
>>>>>> l2paJIf4zw&m=7w99vYkJ60WM1FBGgy4J7mqT1275YbjBb8JT-wb3mnQ&s=PBB_TnejRlF
>>>>>> 
>>>>>> 
>>>>>> pVc-8l3HLn7XqqqUGonk0Rug-1KLLim0&e=>
>>>>>> 
>>>>> _______________________________________________ 5gangip
>>>>> mailing list [e-mail] <mailto:[e-mail]> 
>>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>> 
>>>> _______________________________________________ 5gangip mailing
>>>> list [e-mail] <mailto:[e-mail]> 
>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>> 
>>> /Zásady komunikace, které společnost T-Mobile Czech Republic a.s.
>>>  užívá při sjednávání smluv, jsou uvedeny //zde/ 
>>> <http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_cz.pdf>/.
>>>  Není-li v zásadách uvedeno jinak, nepředstavuje tato zpráva
>>> konečný návrh na uzavření či změnu smlouvy ani přijetí takového
>>> návrhu.//The communication principles which T-Mobile Czech
>>> Republic a.s. applies when negotiating contracts are defined
>>> //here/ 
>>> <http://www.t-mobile.cz/dcpublic/Zasady_komunikace_pri_sjednavani_smluv_en.pdf>/.
>>>  Unless otherwise stated in the principles, this message does not
>>>  constitute the final offer to contract or an amendment of a
>>> contract or acceptance of such offer./
>>> 
>> 
>> _______________________________________________ 5gangip mailing
>> list [e-mail] 
>> https://www.ietf.org/mailman/listinfo/5gangip
> 
> 

_______________________________________________
5gangip mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/5gangip