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

[Alexandre Petrescu <[e-mail]>]

Le 25/01/2018 à 12:36, [e-mail] a écrit :
> 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?

I find the idea pertinent.

I looked at the intarea-tunnels draft.

I think they list common characteristics of Internet tunnels, but they 
stop short from describing a particular tunnel in detail.  Rather, they 
refer to RFCs.

The draft intarea-tunnels does talk about design issues in UDP 
encapsulation, issues which are pertinent to GTP, e,g, checksums, 
fragmentation, etc.

Maybe the intarea-tunnels could benefit from a draft that describes GTP-U.

Or maybe the GTP-U description could go into that intarea-tunnels draft.

> Perhaps for that we could rely on existing old drafts mentioned below?

Maybe the intarea-tunnels draft could refer to draft-casati-gtp-00 of 
year 2000. But if we suggest this to them, I am afraid they would 
object, because typically one needs all the References in a draft to be 
up to date before being able to advance that draft.

Let us see.

Alex

> 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
>