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

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Wed, 24 Jan 2018 16:58:23 +0000

We have deployed more than 20k eNB’s that use IPv6 only transport for S1-U and all of our SGW’s and PGW’s support IPv6 transport for GTP-U and GTP-C. 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 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
[email-masked]<mailto:[email-masked]>
cell - (206)601-5157

From: 5gangip [mailto:[email-masked]] On Behalf Of Ca By
Sent: Wednesday, January 17, 2018 5:13 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; FIGURELLE, TERRY F <[email-masked]>; [email-masked]
Subject: Re: [5gangip] Problems I see

On Wed, Jan 17, 2018 at 12:33 AM <[email-masked]<mailto:[email-masked]>> wrote:
<dl> more ... </dl>

Sent from my iPhone
_____________________________
From: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, January 17, 2018 8:08 am

Subject: Re: [5gangip] Problems I see
To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Nick HEATLEY <[email-masked]<mailto:[email-masked]>>

Le 17/01/2018 à 08:51, [email-masked]<mailto:[email-masked]> 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__bt.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=7w99vYkJ60WM1FBGgy4J7mqT1275YbjBb8JT-wb3mnQ&s=Qbn7h7dkjelNV6G3WyrCCIkkGpi185TxTqR2v3Jnlas&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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/5gangip<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=7w99vYkJ60WM1FBGgy4J7mqT1275YbjBb8JT-wb3mnQ&s=PBB_TnejRlFpVc-8l3HLn7XqqqUGonk0Rug-1KLLim0&e=>

---

From: Vojislav Vucetic <[email-masked]>
Date: Wed, 24 Jan 2018 17:51:40 +0000

Let me just add to Terry's email:

Alex, could you please stop with the statement such as "*Cellular operator
does have answers about why they continue using IPv4 to transport IPv6
(instead of using IPv6 to transport IPv6*."

Leading US mobile carriers are ONLY using IPv6 to transport GTP-U (they do
not have IPv4 transport network between EPC elements, so it is "difficult"
to use IPv4). Let me repeat one more time: *GTP UDP/IPv6*.

You heard the same statement from others (i.e., ATT), but you constantly
and consistently ignoring that and keep repeating the same misleading
statements. There are carriers that are using IPv4 to transport GTP-u, but
that is their choice.

Vojislav

On Wed, Jan 24, 2018 at 4:58 PM, FIGURELLE, TERRY F <[email-masked]> wrote:

> We have deployed more than 20k eNB’s that use IPv6 only transport for S1-U
> and all of our SGW’s and PGW’s support IPv6 transport for GTP-U and GTP-C.
> 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 production networks. It’s very
> common in Asian countries too.
>
>
>
> *Terry Figurelle*
> *Lead Member of Technical Staff*
>
> *Wireless Network Arch. & Design*
>
> *Mobility Core*
>
> *AT&T Services*
>
> [email-masked]* <[email-masked]>
>
> *cell - (206)601-5157 <(206)%20601-5157>*
>
>
>
> *From:* 5gangip [mailto:[email-masked]] *On Behalf Of *Ca By
> *Sent:* Wednesday, January 17, 2018 5:13 AM
> *To:* [email-masked]
> *Cc:* [email-masked]; [email-masked]; FIGURELLE, TERRY F <
> [email-masked]>; [email-masked]
> *Subject:* Re: [5gangip] Problems I see
>
>
>
>
>
> On Wed, Jan 17, 2018 at 12:33 AM <[email-masked]> wrote:
>
> <dl> more ... </dl>
>
>
>
> Sent from my iPhone
>
> From: Alexandre Petrescu <[email-masked]>
> To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>, Nick HEATLEY <
> [email-masked]>
>
>
>
>
> Le 17/01/2018 à 08:51, [email-masked] a écrit :
> [...]
>
> refer, Nick HEATLEY from bt.com
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bt.com&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=7w99vYkJ60WM1FBGgy4J7mqT1275YbjBb8JT-wb3mnQ&s=Qbn7h7dkjelNV6G3WyrCCIkkGpi185TxTqR2v3Jnlas&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> 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.
>
>
>
> 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>
>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=7w99vYkJ60WM1FBGgy4J7mqT1275YbjBb8JT-wb3mnQ&s=PBB_TnejRlFpVc-8l3HLn7XqqqUGonk0Rug-1KLLim0&e=>
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Wed, 24 Jan 2018 18:36:51 +0000

You had me at “20k eNBs” ;)

Peter

From: 5gangip [mailto:[email-masked]] On Behalf Of FIGURELLE, TERRY F
Sent: Wednesday, January 24, 2018 11:58 AM
To: Ca By <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

Terry Figurelle

From: 5gangip [mailto:[email-masked]] On Behalf Of Ca By
Sent: Wednesday, January 17, 2018 5:13 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] Problems I see

Sent from my iPhone

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Jan 2018 20:48:58 +0100

Le 24/01/2018 à 18:51, Vojislav Vucetic a écrit :
> Alex, could you please stop with the statement such as "*Cellular 
> operator does have answers about why they continue using IPv4 to 
> transport IPv6 (instead of using IPv6 to transport IPv6*."

That's something I wrote on the v6ops email list, in the context of that 
discussion.

> Leading US mobile carriers are ONLY using IPv6 to transport GTP-U (they 
> do not have IPv4 transport network between EPC elements, so it is 
> "difficult" to use IPv4). Let me repeat one more time: *GTPUDP/IPv6*.
> 
> statements. There are carriers that are using IPv4 to transport GTP-u, 
> but that is their choice.

Well thank you for the example of the leading US mobile carriers.  It is 
a little bit surprising to me, but it is a good surprise.

If you provided a packet dump of a GTP-U UDP/IPv6 packet captured on PGW 
and coming from a UE, it would be even more convincing, thank you.

Alex

> 
> Vojislav
> 
> On Wed, Jan 24, 2018 at 4:58 PM, FIGURELLE, TERRY F <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     We have deployed more than 20k eNB’s that use IPv6 only transport
>     for S1-U and all of our SGW’s and PGW’s support IPv6 transport for
>     GTP-U and GTP-C. 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
>     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____*
> 
>     [email-masked]* <mailto:[email-masked]>____
> 
>     *cell - (206)601-5157 <tel:(206)%20601-5157>____*
> 
>     __ __
> 
>     *From:*5gangip [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Ca By
>     *To:* [email-masked] <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>;
>     FIGURELLE, TERRY F <[email-masked] <mailto:[email-masked]>>;
>     [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [5gangip] Problems I see____
> 
>     __ __
> 
>     __ __
> 
>     On Wed, Jan 17, 2018 at 12:33 AM <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         <dl> more ... </dl>____
> 
>         __ __
> 
>         Sent from my iPhone____
> 
>         Sent: Wednesday, January 17, 2018 8:08 am____
> 
> 
>         Subject: Re: [5gangip] Problems I see____
> 
>         Cc: <[email-masked] <mailto:[email-masked]>>, <[email-masked]
>         <mailto:[email-masked]>>, Nick HEATLEY <[email-masked]
>         <mailto:[email-masked]>>____
> 
> 
> 
> 
>         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?
>          >
>         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
> 
>         ____
> 
>         [email-masked] <mailto:[email-masked]>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=7w99vYkJ60WM1FBGgy4J7mqT1275YbjBb8JT-wb3mnQ&s=PBB_TnejRlFpVc-8l3HLn7XqqqUGonk0Rug-1KLLim0&e=>____
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/5gangip>
> 
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Jan 2018 20:49:51 +0100

> We have deployed more than 20k eNB’s that use IPv6 only transport for 

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 

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.
> 
> GTP-C|GTP-U. IPv6 GTP has been supported for several years in production 
> networks. It’s very common in Asian countries too.
> 
> [email-masked]* <mailto:[email-masked]>
> 
> *cell - (206)601-5157*
> 
> *From:*5gangip [mailto:[email-masked]] *On Behalf Of *Ca By
> *Cc:* [email-masked]; [email-masked]; FIGURELLE, TERRY F 
> <[email-masked]>; [email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     <dl> more ... </dl>
> 
>     Sent from my iPhone
> 
>     <mailto:[email-masked]>>
> 
> 
> 
> 
>     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?
>      >
>     between MME and SGW (S11 interface)   S1-MME (eNB to MME for control
>     plane uses SCTP.
> 
>     defined as yet (but will probably be SCTP as per current S1-MME).
> 
>     function has been broken out to AMF and SMF elements and it is the
>     SMF which communicates to the multiple UPF over N4.
> 
>     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>
> 
> might work.

---

From: Arashmid Akhavain <[email-masked]>
Date: Wed, 24 Jan 2018 19:54:04 +0000

S1U is 3GPP defined interface between eNB and SGW carrying user plane traffic.

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: 24 January 2018 14:50
To: FIGURELLE, TERRY F <[email-masked]>; Ca By <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

Which RFC is it?

Alex

> 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
> 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.
> 
> GTP-C|production
> *Cc:* [email-masked]; [email-masked]; FIGURELLE, TERRY 
> F <[email-masked]>; [email-masked]
> <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=>
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Jan 2018 20:59:16 +0100

> 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

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 24 Jan 2018 20:21:07 +0000

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.

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.

Ales

On 24 Jan 2018, at 20:59, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

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.

Alex

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: 24 January 2018 14:50
To: FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>>; Ca By <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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.).

*Terry Figurelle*

*Mobility Core*

*AT&T Services*

[email-masked]<mailto:[email-masked]>* <mailto:[email-masked]>

*cell - (206)601-5157*

*From:*5gangip [mailto:[email-masked]] *On Behalf Of *Ca By
*Sent:* Wednesday, January 17, 2018 5:13 AM
*To:* [email-masked]<mailto:[email-masked]>
*Cc:* [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; FIGURELLE, TERRY
F <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
*Subject:* Re: [5gangip] Problems I see

On Wed, Jan 17, 2018 at 12:33 AM <[email-masked]<mailto:[email-masked]>
<mailto:[email-masked]>> wrote:

    <dl> more ... </dl>

    Sent from my iPhone

    _____________________________
    From: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]>>
    Sent: Wednesday, January 17, 2018 8:08 am

    To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]>>
    Cc: <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]>>, Nick HEATLEY <[email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]>>

    Le 17/01/2018 à 08:51, [email-masked]<mailto:[email-masked]>
    <mailto:[email-masked]> a écrit :
    [...]

    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=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=7w99vYkJ60WM1FBGgy4J7mqT1275YbjBb8JT-wb3mnQ&s=Qbn7h7dkjelNV6G3WyrCCIkkGpi185TxTqR2v3Jnlas&e=>,
    who some times posts in v6ops WG. He
    often talks about IPv6.

    The protocol chosen for N4 is PFCP carrying dataplane programming
    verbs (eg OpenFlow).

It’s somewhat like trying to contribute to rocket science by attending
a cricket game.

    Alex

    [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

Zásady komunikace, které spolecnost T-Mobile Czech Republic a.s. užívá pri 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, nepredstavuje tato zpráva konecný návrh na uzavrení ci zmenu smlouvy ani prijetí 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.

---

From: <[email-masked]>
Date: Wed, 24 Jan 2018 20:46:12 +0000

-----Original Message-----
From: Lake D Mr (PG/R - Elec Electronic Eng) 
Sent: 24 January 2018 20:46
To: 'Alexandre Petrescu' <[email-masked]>
Subject: RE: [5gangip] IPv6 GTP-C/GTP-U

<dl> in-line </dl>

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: 24 January 2018 19:59
To: Arashmid Akhavain <[email-masked]>
Cc: [email-masked]
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

<dl> S1 comprises S1-U which is GTP (user plane traffic from eNB to SGW) and S1-MME (sometimes called S1-C) which is control-plane traffic SCTP from eNB to MME.

User-plane traffic between S-GW and P-GW is GTP in LTE.  This is the S5/S8 interface.  GTP labels (TEID) are swapped between S1-U and S5/S8.   Egress from the P-GW is SGi and is IP (of any flavour).

For completeness:

4G                   5G Equivalent                    Protocol

S1		N3			GTP
S5/S8		N9			Not yet defined
SGi		N6			IP
S11		N4			PFCP

</dl>

Alex

>> supports
>> direct connections (IPX
>> *Cc:* [email-masked]; [email-masked]; FIGURELLE, 
>> TERRY F <[email-masked]>; [email-masked]
>> attending a cricket game.
>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Jan 2018 22:02:01 +0100

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 
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>>
>>
>>> To: FIGURELLE, TERRY F <[email-masked] <mailto:[email-masked]>>; Ca 
>>> By <[email-masked] <mailto:[email-masked]>>; 
>>> [email-masked] <mailto:[email-masked]>
>>> Cc: [email-masked] <mailto:[email-masked]>; [email-masked] 
>>> <mailto:[email-masked]>
>>>> [email-masked] <mailto:[email-masked]>* 
>>>> <mailto:[email-masked]>
>>>>
>>>> *cell - (206)601-5157*
>>>>
>>>> FIGURELLE, TERRY
>>>> F <[email-masked] <mailto:[email-masked]>>; [email-masked] 
>>>> <mailto:[email-masked]>
>>>> <mailto:[email-masked]>
>>>>     Cc: <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>
>>>> <mailto:[email-masked]>
>>>>      > (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>
>>>>
>>>>     refer, Nick HEATLEY from bt.com <http://bt.com>
>>>>      >> and for CUPS in the lab.
>>>>      >
>>>>      > What is CUPS?
>>>>      >
>>>>      > <dl> Control User-Plane Split.
>>>>
>>>>      > 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>
>>>>
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> /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./
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Jan 2018 22:05:43 +0100

Le 24/01/2018 à 21:46, [email-masked] a écrit :
> User-plane traffic between S-GW and P-GW is GTP in LTE.  This is the S5/S8 interface.

If so, then it means that the statement from Terry that says "20k eNB’s 
that use IPv6 only transport for S1-U and all of our SGW’s and PGW’s 
support IPv6 transport for GTP-U and GTP-C" means nothing in terms of 
GTP-U being UDP/IPv6.

Maybe Terry talked about S1-U being IPv6, but what I need is the S5/S8 
interface to be IPv6.

So, maybe I should ask Terry whether the S5/S8 interface is IPv6?

Alex

   GTP labels (TEID) are swapped between S1-U and S5/S8.   Egress from 
the P-GW is SGi and is IP (of any flavour).

---

From: Charlie Perkins <[email-masked]>
Date: Wed, 24 Jan 2018 14:19:24 -0800

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.

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

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

Regards,
Charlie P.

On 1/24/2018 1:02 PM, Alexandre Petrescu wrote:
>> understand the architecture and learn where GTP can be used. S1-U is 
>> GTP based as Arashmid stated.
>
>> 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.
>
>>> 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.
>>>
>>>>> with
>>>>> they
>>>>> [email-masked] 
>>>>> <mailto:[email-masked]>; FIGURELLE, TERRY
>>>>>     To: Lake D Mr (PG/R - Elec Electronic Eng) 
>>>>> <[email-masked] <mailto:[email-masked]>
>>>>>      > <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>
>>>>>
>>>>> require
>>>>>      > allows different user-planes associated with a single 
>>>>> control plane,
>>>>> MME
>>>>> those
>>>>> attending
>> /Zásady komunikace, které společnost T-Mobile Czech Republic a.s. 
>> užívá při sjednávání smluv, jsou uvedeny //zde/ 
>> communication principles which T-Mobile Czech Republic a.s. applies 
>> when negotiating contracts are defined //here/ 
>> constitute the final offer to contract or an amendment of a contract 
>> or acceptance of such offer./
>>
>

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 25 Jan 2018 00:12:34 +0000

When SGW and PGW use S5 (on-net) both GTP-C and GTP-U are IPv6 since both address family end points are provided because the node must prefer IPv6.

So it’s all managed by data fill in APN DNS data fill. This allows handoffs between IP families. However, X2 can only be same family. Thus you end up with S1 instead of X2 handoffs when crossing families. In practice we always use same family in a tracking area and it was only during migration that we had this issue. Once the older eNB’s were converted to IPv6 (software update) that issue went away.

Due to costs we did not upgrade 3G to IPv6 or enable S4-SGSN with IPv6. So MME has to use its IPv4 address when acting as new or old SGSN during handoffs. We could have went with combined MME/SGSN but the value wasn’t there given the decline in 3G.

We actual will be turning 3G off in a few years and already gave notice to roaming partners.

Note that all of our SGW/PGW can be SGW only, PGW only or what Cisco calls SPGW and I call (S/P-GW or SAE-GW). In that combined node there is no S5 or GTP tunnel and the VM simply has S1 on one side and SGi on the other.

This was a requirement when I did RFP for LTE EPC. ALU, Affirmed, Cisco, Ericsson, Huawei, Juniper, Nokia, Nortel and Starent all offered solutions. Vendors also committed to support vEPC solution on Intel COTS hardware using OpenStack. We’ve pushed this as part of Open Networking Foundation. We have M-CORD in the lab and we call our solution as Virtual Networking Functions on AIC (AT&T Integrated Cloud). We also use ONAP which we contribute to the Open Source effort.

So we practice what we preach and are working closely with other heavy weights to push this as fast as we can.

Our Cricket subscribers are all supported by vEPC in production. We also use vEPC for our Auto VoLTE (Connected Car) solution that GM and BMW use (plus a number of others I can’t mention).

We partner with Bell Canada and Rogers to support Connected Car and other solutions which is why we know so much about each others implementation. We also leverage Jasper (now owned by Cisco) which helps us world wide. The European solution uses Cisco’s vEPC and we partner with select mobile operators to leverage their LTE RAN.

This is one of our IoT solutions and all will use virtualization.

Sent from my iPhone

On Jan 24, 2018, at 1:06 PM, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

Le 24/01/2018 à 21:46, [email-masked]<mailto:[email-masked]> a écrit :
-----Original Message-----
From: Lake D Mr (PG/R - Elec Electronic Eng)
Sent: 24 January 2018 20:46
To: 'Alexandre Petrescu' <[email-masked]<mailto:[email-masked]>>
Subject: RE: [5gangip] IPv6 GTP-C/GTP-U
<dl> in-line </dl>
-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: 24 January 2018 19:59
To: Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

If so, then it means that the statement from Terry that says "20k eNB’s that use IPv6 only transport for S1-U and all of our SGW’s and PGW’s support IPv6 transport for GTP-U and GTP-C" means nothing in terms of GTP-U being UDP/IPv6.

Maybe Terry talked about S1-U being IPv6, but what I need is the S5/S8 interface to be IPv6.

Alex

 GTP labels (TEID) are swapped between S1-U and S5/S8.   Egress from the P-GW is SGi and is IP (of any flavour).
For completeness:
4G                   5G Equivalent                    Protocol
S1        N3            GTP
S5/S8        N9            Not yet defined
SGi        N6            IP
S11        N4            PFCP
</dl>
Only an Internet Draft can lead to agree how this works.
Alex

-----Original Message-----
From: 5gangip [mailto:[email-masked]] On Behalf Of Alexandre
Petrescu
Sent: 24 January 2018 14:50
To: FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>>; Ca By <[email-masked]<mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

Which RFC is it?

Alex

has certified since the launch or UMS support IPv4 only, IPv6 only
and

*Terry Figurelle*

*Mobility Core*

*AT&T Services*

*cell - (206)601-5157*

*From:*5gangip [mailto:[email-masked]] *On Behalf Of *Ca By
*Sent:* Wednesday, January 17, 2018 5:13 AM
*To:* [email-masked]<mailto:[email-masked]>
*Cc:* [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; FIGURELLE,
TERRY F <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
*Subject:* Re: [5gangip] Problems I see

     <dl> more ... </dl>

     Sent from my iPhone

     Alex

     _______________________________________________
     5gangip mailing list
     [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>
     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=3gSGDmQ1E6H9-ERLu_06EK3j__jTRVKjQTTRsN1ctC0&s=vsjmu4JJ9MATdZdKbeBysg4-rGAEryAfGlOOi0eu_YI&e=       <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_ma>>> i
lman_listinfo_5gangip&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTx
w
l2paJIf4zw&m=7w99vYkJ60WM1FBGgy4J7mqT1275YbjBb8JT-wb3mnQ&s=PBB_TnejRl
F
pVc-8l3HLn7XqqqUGonk0Rug-1KLLim0&e=>

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
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=3gSGDmQ1E6H9-ERLu_06EK3j__jTRVKjQTTRsN1ctC0&s=vsjmu4JJ9MATdZdKbeBysg4-rGAEryAfGlOOi0eu_YI&e=
_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
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=3gSGDmQ1E6H9-ERLu_06EK3j__jTRVKjQTTRsN1ctC0&s=vsjmu4JJ9MATdZdKbeBysg4-rGAEryAfGlOOi0eu_YI&e=

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
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=3gSGDmQ1E6H9-ERLu_06EK3j__jTRVKjQTTRsN1ctC0&s=vsjmu4JJ9MATdZdKbeBysg4-rGAEryAfGlOOi0eu_YI&e=

---

From: Ca By <[email-masked]>
Date: Thu, 25 Jan 2018 02:25:09 +0000

Terry,

Very helpful info. Comments inline.

On Wed, Jan 24, 2018 at 8:59 AM FIGURELLE, TERRY F <[email-masked]> wrote:

> only, IPv6 only and currently IPv4v6 (deprecated by 3GPP).
>

Under what circumstance does a retail at&t consumer get an ipv6 only
configuration on a UE for default data apn?  Can you elaborate on what
transition method is used ?

This includes two UE operating systems which cover 97% of the market share.
> 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.
>
>
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 25 Jan 2018 09:59:25 +0100 (CET)

> and coming from a UE, it would be even more convincing, thank you.

Do you understand that you're accusing people of lying in your above 
statement?

Also, if they were indeed lying, falsifying a packet dump is very easy, so 
it would prove nothing.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Jan 2018 10:27:39 +0100

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 

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

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

> 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.
>>> 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.
>> 
>> The question I wonder is, if I write it, will anybody be interested
>> in co-authoring, or maybe discuss it publicly?
>> 
>> Alex
>> 
>>> 
>>> Ales
>>> 
>>> <[email-masked]
>>> <mailto:[email-masked]>> wrote:
>>> 
>>>> 
>>>> 
>>>> 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.
>>>> 
>>>>> -----Original Message----- From: 5gangip
>>>>> [mailto:[email-masked]] On Behalf Of Alexandre
>>>>> Petrescu Sent: 24 January 2018 14:50 To: FIGURELLE, TERRY F
>>>>> <[email-masked] <mailto:[email-masked]>>; Ca By
>>>>> <[email-masked] <mailto:[email-masked]>>; 
>>>>> [email-masked] <mailto:[email-masked]> Cc:
>>>>> [email-masked] <mailto:[email-masked]>;
>>>>> [email-masked] <mailto:[email-masked]> Subject: Re:
>>>>> [5gangip] IPv6 GTP-C/GTP-U Le 24/01/2018 à 17:58, FIGURELLE,
>>>>> TERRY F a écrit :
>>>>> 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
>>>>>> *From:*5gangip [mailto:[email-masked]] *On Behalf
>>>>>> Of *Ca By *Sent:* Wednesday, January 17, 2018 5:13 AM *To:*
>>>>>> [email-masked] <mailto:[email-masked]> *Cc:*
>>>>>> [email-masked] <mailto:[email-masked]>; 
>>>>>> <mailto:[email-masked]>; FIGURELLE, TERRY F
>>>>>> <[email-masked] <mailto:[email-masked]>>;
>>>>>> [email-masked] <mailto:[email-masked]> *Subject:*
>>>>>> Re: [5gangip] Problems I see
>>>>>> 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>> wrote:
>>>>>> 
>>>>>> <dl> more ... </dl>
>>>>>> 
>>>>>> Sent from my iPhone
>>>>>> 
>>>>>> _____________________________ From: Alexandre Petrescu
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>> Sent: Wednesday,
>>>>>> January 17, 2018 8:08 am
>>>>>> 
>>>>>> 
>>>>>> <mailto:[email-masked]>> Cc: <[email-masked]
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>>,
>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>> <mailto:[email-masked]>>, Nick HEATLEY
>>>>>> <[email-masked] <mailto:[email-masked]> 
>>>>>> Le 17/01/2018 à 08:51, [email-masked] 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> a
>>>>>> écrit : [...]
>>>>>> 
>>>>>> However, there may be some trials ongoing. One could ask,
>>>>>> if I may refer, Nick HEATLEY from bt.com <http://bt.com> 
>>>>>> 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?
>>>>>>> 
>>>>>>> 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
>>>>>>> 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
>>>>>>> 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>
>>>>>> 
>>>>>> <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.
>>>>>> 
>>>>>> 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>
>>>>>> 
>>>>>> _______________________________________________ 5gangip
>>>>>> mailing list [email-masked] <mailto:[email-masked]>
>>>>>> <mailto:[email-masked]> 
>>>>> _______________________________________________ 5gangip
>>>>> mailing list [email-masked] <mailto:[email-masked]> 
>>>> _______________________________________________ 5gangip mailing
>>>> list [email-masked] <mailto:[email-masked]> 
>>>  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/ 
>>>  constitute the final offer to contract or an amendment of a
>>> contract or acceptance of such offer./
>>> 
>> 
>> _______________________________________________ 5gangip mailing
>> list [email-masked]

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Jan 2018 10:33:01 +0100

Le 25/01/2018 à 09:59, Mikael Abrahamsson a écrit :
>> If you provided a packet dump of a GTP-U UDP/IPv6 packet captured on 
>> PGW and coming from a UE, it would be even more convincing, thank you.
> 
> Also, if they were indeed lying, falsifying a packet dump is very easy, 
> so it would prove nothing.

I am not accusing anyone, sorry if I sound so.  I excuse.

The tone of discussion was set by earlier posters, not by me.

Providing a packet dump for discussion is helpful.  If not possible, 
then not possible.

Alex

---

From: <[email-masked]>
Date: Thu, 25 Jan 2018 11:36:08 +0000

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:[email-masked]] On Behalf Of Alexandre Petrescu
Sent: Donnerstag, 25. Januar 2018 10:28
To: 
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

For draft-casati:

vs

Captured packet on PGW:
TEID: 0x8000C124, Message type: GTP_TPDU_MSG (0xFF) Sequence Number:: NA GTP HEADER FOLLOWS:
                   Tunnel ID: 0x8000C124 GTP HEADER ENDS.

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

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

Alex

>>>> that nobody can make me say it is a wrong
>>>>> [mailto:[email-masked]] On Behalf Of Alexandre Petrescu 
>>>>> Sent: 24 January 2018 14:50 To: FIGURELLE, TERRY F <[email-masked] 
>>>>> <mailto:[email-masked]>>; Ca By <[email-masked] 
>>>>> <mailto:[email-masked]>>; [email-masked] 
>>>>> <mailto:[email-masked]> Cc:
>>>>> [email-masked] <mailto:[email-masked]>; [email-masked] 
>>>>> <mailto:[email-masked]> Subject: Re:
>>>>> [5gangip] IPv6 GTP-C/GTP-U Le 24/01/2018 à 17:58, FIGURELLE, TERRY 
>>>>> F a écrit :
>>>>>> for S1-U
>>>>> 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.).
>>>>>> 
>>>>>> 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 
>>>>>> 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.
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> GTP-C|production networks. It’s very common in Asian countries 
>>>>>> too.
>>>>>> 
>>>>>> *From:*5gangip [mailto:[email-masked]] *On Behalf Of 
>>>>>> *Ca By *Sent:* Wednesday, January 17, 2018 5:13 AM *To:* 
>>>>>> <[email-masked] <mailto:[email-masked]>>; [email-masked] 
>>>>>> <mailto:[email-masked]> *Subject:*
>>>>>> <mailto:[email-masked]>> Sent: Wednesday, January 
>>>>>> 17, 2018 8:08 am
>>>>>> 
>>>>>> 
>>>>>> To: Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked] 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>> Cc: 
>>>>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked]>>, 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]>>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> <mailto:[email-masked]> <mailto:[email-masked]> a écrit 
>>>>>> : [...]
>>>>>> 
>>>>>> 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.
>>>>>> 
>>>>>> 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?
>>>>>>>

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Jan 2018 16:40:20 +0100

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

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

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Jan 2018 17:32:57 +0100

Le 25/01/2018 à 01:12, FIGURELLE, TERRY F a écrit :
[...]
> We also 
> use vEPC for our Auto VoLTE (Connected Car) solution that GM and BMW use 
> (plus a number of others I can’t mention).

For the Auto VoLTE one may be interested in the SAE Cellular V2X Tech 
Committee recently created and led by Qualcomm.  There is a recent 
liaison statement from SAE (Society of Automotive Engineers) to IETF's 
IPWAVE Working Group, attached.

One may wonder whether Auto VoLTE can fast route the SAE's BSM messages 
from one car to another, in a sort of "V2I2V" manner.

> We partner with Bell Canada and Rogers to support Connected Car and 
> other solutions which is why we know so much about each others 
> implementation.

This is great, come to IPWAVE: ietf.org/mailman/listinfo/its

Alex

Subject: [ipwave] New Liaison Statement, "LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces"
From: Liaison Statement Management Tool <[email-masked]>
To: Carlos Bernardos <[email-masked]>, Russ Housley <[email-masked]>
Cc: IP Wireless Access in Vehicular Environments Discussion List <[email-masked]>, <[email-masked]>, Russ Housley <[email-masked]>, Carlos Bernardos <[email-masked]>, <[email-masked]>, Suresh Krishnan <[email-masked]>, Terry Manderson <[email-masked]>
Date: Tue, 2 Jan 2018 10:26:30 -0800
List-Id: IPWAVE - IP Wireless Access in Vehicular Environments WG at IETF <its.ietf.org>

Title: LS on Establishment of SAE Cellular V2X Technical Committee and Associated Task Forces
Submission Date: 2018-01-02
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1552/

From: Jim Misener <[email-masked]>
To: Carlos Bernardos <[email-masked]>,Russ Housley <[email-masked]>
Cc: Russ Housley <[email-masked]>,Terry Manderson <[email-masked]>,Carlos Bernardos <[email-masked]>,IP Wireless Access in Vehicular Environments Discussion List <[email-masked]>,Suresh Krishnan <[email-masked]>
Response Contacts: [email-masked], [email-masked]
Technical Contacts: 
Purpose: For information

Body: 1. Overall Description:
The SAE Cellular V2X Technical Committee (C-V2X TC) was formed in June, 2017 with the following charter:

The SAE Cellular V2X Technical Committee reports to the Vehicle Engineering Systems Group of the Motor
Vehicle Council. The Committee is responsible for adapting, developing and maintaining SAE Standards,
Recommended Practices, and Information Reports that use cellular radio access technologies and specifically,
evolving 4G LTE and 5G cellular technologies that require interoperability and performance standards for road
vehicles and other road users in order to use the full capabilities of these technologies. The committee also
coordinates task force efforts to ensure efficient development and delivery of SAE documents, acts as liaison to
the other organizations involved in the with vehicular-oriented cellular standards and deployments, and
organizes efforts in gathering requirements for SAE standardization and assigns them to distributed task forces.
The C-V2X Technical Committee will work closely with the SAE DSRC Technical Committee and with their
documents to assure efficient reuse and adjustment as appropriate, e.g., strive to maintain a single data
dictionary. Participants in the SAE C-V2X TC include vehicle OEMs, vehicle suppliers, mobile network
operators, mobile network operator equipment suppliers, mobile handset manufacturers, chipset
manufacturers, road operators, traffic equipment suppliers, consulting firms, government, and other interested
parties.

At the current time, three Task Forces constitute the C-V2X TC. The Task Forces and charters are:

CV2X Advanced Applications Task Force: Develop definitions of terms, use cases, recommended practices,
guidelines, test methods, specifications and performance standards for vehicles connected using C-V2X,
focusing on advanced V2X applications (i.e., applications that cannot be supported by DSRC and Rel-14 LTEV2X)
that deal with 5G (3GPP NR and LTE evolution) to leverage enhanced mobile broadband, use of
millimeter wave and other anticipated radio access technologies, and the next generation core network
including enablers such as NFV/SDN, edge computing, and network slicing. The task force will encourage
research in these areas, and sponsor and facilitate the development of related standards. The work of this task
force will be coordinated with other task forces in C-V2X Technical Committee, as well as other V2X related
technical committees and standards organizations such as 3GPP, ATIS, GSM Association, DSRC Technical
Committee, On-Road Automated Driving (RAD) Technical Committee, ITU-T and ETSI.

CV2X Direct Communication Task Force: Develop definitions of terms, use cases, recommended practices
guidelines, test methods, specifications and performance standards for vehicles connected using C-V2X,
focusing on safety applications that include cooperative awareness, warning notification, safe lane change, safe
intersection and roundabout crossing, etc. Important topics of security, reliability, and quality of service will be
part of the charter. The task force will encourage research in these areas, and sponsor and facilitate the
development of related standards. The work of this task force will be coordinated with other task forces in CV2X
Technical Committee, as well as other V2X related technical committees and standards organizations
such as DSRC Technical Committee, On-Road Automated Driving (RAD) Technical Committee, 3GPP, ISO,
ITU-T and ETSI.

CV2X Road Operators Task Force: Work with the ground transportation operating community to identify its
high-level needs and develop standards, recommended practices, and information reports to address those
needs.

2. Actions:

To (SDOs and industry organizations):

ACTION: The SAE C-V2X welcomes mutual consideration and communication as we jointly standardize
applicable interoperability and performance specifications to fully leverage 4G LTE and 5G cellular
radio access technologies.

3. Date of Next SAE C-V2X Meetings:
3rd Wednesday of every month, 1000 Eastern Time US         WebEx
14-15 March, 2018                                                                          Southeast Michigan or Newark NJ (TBD)
Attachments:

    SAE 12302017-1- LS Announcing SAE C-V2X v2final.pdf
    https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-01-02-sae-cell-v2x-ipwave-ls-on-establishment-of-sae-cellular-v2x-technical-committee-and-associated-task-forces-attachment-1.pdf

_______________________________________________
its mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/its

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 Jan 2018 09:38:50 -0800

On Thu, Jan 25, 2018 at 7:40 AM, Alexandre Petrescu
<[email-masked]> wrote:
>> 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 think they list common characteristics of Internet tunnels, but they stop
> short from describing a particular tunnel in detail.  Rather, they refer to
> RFCs.
>
Alex,

I can give a perspective from a programmer of Internet protocols point of view.

In Linux, we have a lot of kernel support for IP/IP encapsulations
(IP/IP, GRE, MPLS, etc). We also support many UDP encapsulations (GUE,
Geneve, VXLAN, GRE/UDP, MPLS/UDP, etc.). A considerable amount of
effort has been done to optimize UDP encapsulations
(https://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf).
Mostly, implementation is straightforward: listen on a UDP socket,
handle checksum consistently, process encapsulation headers,
decapsulate and receive inner packet. Packet steering (ECMP), checksum
offload, and SW segmentation offload are common features. Typically,
there is a way to run an encapsulation as a simple virtual interface
(to isolate and develop datapath) with no control plane daemon and no
special hardware. Support for both IPv4 and IPv6 is expected from day
one.

GTP-U is nonconformant compared to other UDP encapsulations. Support
was added to Linux in 2016. This was IPv4 only and required a control
daemon (openggsn originally). It also lacked common accelerations of
other protocols. Last year, I worked on this to: 1) allow using GTP to
be configured as simple network interface 2) support common offloads
3) support IPv6 (v6/v4,v4/v6,v6/v6).

The last point is where I hit problems. My expectation was that
supporting IPv6 should be straightforward, changing interfaces and
protocol implementations to use IPv6 addresses. This was not the case.
The feedback was that a lot is required in the control plane and many
3GPP specs need to be read. Unfortunately, I didn't have time to
pursue this so the patch set was dropped. To date, there's no IPv6 GTP
support and several common features are lacking relative to other UDP
encapsulations.

An RFC certainly would have be helpful in this exercise, if nothing
else to normalize GTP to make it seem like just another UDP
encapsulation (which is a good property). IMO, a GTP-U draft should be
standalone protocol specification so that anyway could implement it
and compare its behavior and properties to other UDP encapsulation
defined in IETF. I don't believe there could be normative references
to 3GPP documents, and this doesn't seem like a WG item but maybe
should be an independent submission.

> Or maybe the GTP-U description could go into that intarea-tunnels draft.
That seems reasonable as a bullet point in the intro with the list of
other protocols. Conversely, a GTP-U draft should reference the
intarea-tunnels draft as requirements of IP tunnels. It should also
reference other RFCs on interactions between tunneling and IP
protocols (e.g. RFC2983, RFC6040, RFC4459). The outer UDP checksum
needs careful consideration if it is to be set to zero. RFC6935 and
RFC6936 describe requirements for a zero UDPv6 checksum and RFC8086
(GRE/UDP) section 6.2 is an example of how a protocol applies these
requirements.

> 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.
>
draft-casati-gtp-00 is very scant and nothing close to being a
specification that someone could take and implement. It would need a
lot of work to be a useful reference.

Tom

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 25 Jan 2018 19:36:46 +0000

Dumps contain subscriber personal information (SPI) and we have policies on how that should be treated and who can have access to that. Removing that information is not enough to avoid the policy constraint.

Most employees are not allowed to see any production traffic. Plus, it’s a pain to setup specific MSISDN captures using test SIM’s and operations has better things to do.

I could wait until the next IMS issue and use one of those test with permission but I’d have to go thru legal and departmental approval plus they may reject the reason for sharing with a group not under specific NDA.

I provided the paragraph in 3GPP specification where it states it should be supported.

Feel free to contact any of the major vendors and ask them if their eNB supports IPv6 for S1-U; SGW IPv6 on S1-U/S5; and PGW IPv6 on S5/Gn/S8/Gp. You could also ask them for a list of operators using IPv6 for 3GPP function interfaces.

Sent from my iPhone

On Jan 25, 2018, at 1:33 AM, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

Le 25/01/2018 à 09:59, Mikael Abrahamsson a écrit :
On Wed, 24 Jan 2018, Alexandre Petrescu wrote:
If you provided a packet dump of a GTP-U UDP/IPv6 packet captured on PGW and coming from a UE, it would be even more convincing, thank you.
Do you understand that you're accusing people of lying in your above statement?
Also, if they were indeed lying, falsifying a packet dump is very easy, so it would prove nothing.

Providing a packet dump for discussion is helpful.  If not possible, then not possible.

Alex

_______________________________________________
5gangip mailing list
[email-masked]<mailto:[email-masked]>
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=1rP_FKiAGC42R0hlskaKm2YW0Qk3BipWFAg0DOtDEwI&s=kFN-j5I4lUA_-YiKhj941A75FB_3W4uHJsgQoE2oMRc&e=

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Jan 2018 21:34:51 +0100

Le 25/01/2018 à 20:36, FIGURELLE, TERRY F a écrit :
> Dumps contain subscriber personal information (SPI)

It depends on the dumps.  There are dumps performed on PGW on Cisco 
command line that do not contain SPI (subscriber personal information) 
even if some may contain SPI (security parameter index) which is public 
anyways.

> and we have policies 
> on how that should be treated and who can have access to that. Removing 
> that information is not enough to avoid the policy constraint.

I agree on the policies.  They must be followed.

> Most employees are not allowed to see any production traffic. 

I agree, and it is very good that way.

> Plus, it’s 
> a pain to setup specific MSISDN captures using test SIM’s and operations 
> has better things to do.

I agree it is a pain, or so I am told too by others.  But it is 
possible.  Maybe the engineer I worked with to achieve it was so fed up 
with my requests that he scripted it somehow, so it became less tedious.

It is possible to setup specific captures per-MSISDN (aka 'phone number').

If I had a SIM card from you and you asked me, I would say right away: 
yes, please set a MSISDN setup for my SIM card and show me the packet 
capture.  I agree to that.

For example, operator sets an APN for me, I buy a SIM card, I 
communicate the MSISDN to operator and then operator captures data on 
PGW filtered on my MSISDN.  Operator decides what to capture, what to 
show, etc.

What I want to see here is not _all_ the data, but the GTP on UDP/IPv6.

> I could wait until the next IMS issue and use one of those test with 
> permission but I’d have to go thru legal and departmental approval plus 
> they may reject the reason for sharing with a group not under specific NDA.

I agree to wait until the next IMS issue.

If it takes too much time for NDA, maybe you could ask here for someone 
situated in America and who has a SIM card already for your operator, 
agree to the terms of the packet dump, and test it.  It is you operator 
who produce dumps, so up to you to select what gets shown.

It is something like: call for interoperability, who can interoperate 
with me, or something like that.

It is worth the effort.

> I provided the paragraph in 3GPP specification where it states it should 

I agree with you.  Many operators say just that: go to 3GPP documents 
whenever some functionality is doubted.

> Feel free to contact any of the major vendors and ask them if their eNB 
> supports IPv6 for S1-U; SGW IPv6 on S1-U/S5; and PGW IPv6 on 
> S5/Gn/S8/Gp. You could also ask them for a list of operators using IPv6 
> for 3GPP function interfaces.

That is too theoretical.  To that theoretical question many operators 
answer: yes support, read 3GPP, and it's NDA.

There are many 3GPP-related RFCs at IETF that are results of that kind 
of informative work.

Alex
PS: that's packet dumps, but imagine I asked for the source code :-)

> 
> Sent from my iPhone
> 
> On Jan 25, 2018, at 1:33 AM, Alexandre Petrescu

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 25 Jan 2018 23:05:28 +0000

I am done with this thread and feel no obligation to prove to you we use IPv6.

Its trivial to capture traces directly from the Tektronix probes but I intentionally gave up all access to production and lab systems. My job now is to look 3-5 years out and not get dragged into the day to day. Since I was the lead engineer that lead the design, testing and deployment for LTE using IPv6 networking; operations would think it's a joke if I requested a capture for that reason.

Trust me or don't trust me. I no longer care and you're now on my junk list.
	
Terry Figurelle
AT&T Labs Technical Fellow
Wireless Network Arch. & Design
Mobility Core
AT&T Services
[email-masked]
cell - (206)601-5157

-----Original Message-----
From: Alexandre Petrescu [mailto:[email-masked]] 
Sent: Thursday, January 25, 2018 12:35 PM
To: FIGURELLE, TERRY F <[email-masked]>
Cc: Mikael Abrahamsson <[email-masked]>; [email-masked]
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

> Plus, it's 
> a pain to setup specific MSISDN captures using test SIM's and operations 
> has better things to do.

> permission but I'd have to go thru legal and departmental approval plus 

It is worth the effort.

Alex

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Thu, 25 Jan 2018 23:51:05 +0000

HSS has a setting on what IP address family is provisioned on an APN for the given IMSI. It supports IPv4 only; IPv6 only; IPv4 or IPv6; IPv4 or iPv6 or IPv4v6. It can adjust that based on service area (typically on-net, domestic or international). Plus we learn both 3GPP QoS support and address family support while roaming then adjust on a per PLMN regular expression (configuration entry).

The UE can request a number of things including address family (uses an all zero IPv4 or IPv6 address), DNSv4 IP’s, DNSv6 IP’s, MTU, P-CSCF IP. There also is support for UE to attach with no IP requested then do a DHCPv4|DHCPv6 broadcast request. We only have that setup via our business unit (getting close to breaking 10k APN’s).

The PGW passes the parameters back in the PCO in the create response which get back to the UE. If the mobile doesn’t request something, by standard the PGW doesn’t send it. That cause some challenges when some vendors UE’s didn’t request DNS. Another feature and PGW sends DNS even when it wasn’t requested. This is the stuff that drives me crazy.

Right now we are working with vendors, mobile device requirements and on a 3GPP submission to allow PGW to modify MTU on the fly and device must switch to the new MTU. Not all transport networks support larger than 1500 byte MTU and all of the possible encapsulations can result in GTP fragmentation. Besides the performance hit there are issues when there are too many packets between fragments. At the higher speeds this breaks flows so we got vendors to implement configurable size but we can’t fix non-TCP services that break. We adjust the MSS for TCP.

We are pushing hard on MTU2000 but in some places you have only one choice for transport (e.g. Alaska). Even AT&T doesn’t have the resources to run fiber to all locations in North America. Mexico is a bit of a pain. We can justify microwave relay in many places but not all (too costly for too little pop coverage).

Yes, we spent a lot of time trying to get MTU discovery to work in all situations.

We have some pretty fancy roaming controls on PCRF too.

Terry Figurelle

From: Ca By [mailto:[email-masked]]
Sent: Wednesday, January 24, 2018 6:25 PM
To: FIGURELLE, TERRY F <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

Terry,

On Wed, Jan 24, 2018 at 8:59 AM FIGURELLE, TERRY F <[email-masked]<mailto:[email-masked]>> wrote:
We have deployed more than 20k eNB’s that use IPv6 only transport for S1-U and all of our SGW’s and PGW’s support IPv6 transport for GTP-U and GTP-C. 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).

Under what circumstance does a retail at&t consumer get an ipv6 only configuration on a UE for default data apn?  Can you elaborate on what transition method is used ?

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.

Terry Figurelle

From: 5gangip [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ca By

Sent from my iPhone

Alex

---

From: Tom Herbert <[email-masked]>
Date: Thu, 25 Jan 2018 16:11:44 -0800

On Thu, Jan 25, 2018 at 3:51 PM, FIGURELLE, TERRY F <[email-masked]> wrote:
> HSS has a setting on what IP address family is provisioned on an APN for the
> given IMSI. It supports IPv4 only; IPv6 only; IPv4 or IPv6; IPv4 or iPv6 or
> IPv4v6. It can adjust that based on service area (typically on-net, domestic
> or international). Plus we learn both 3GPP QoS support and address family
> support while roaming then adjust on a per PLMN regular expression
> (configuration entry).
>
>
>
> The UE can request a number of things including address family (uses an all
> zero IPv4 or IPv6 address), DNSv4 IP’s, DNSv6 IP’s, MTU, P-CSCF IP. There
> also is support for UE to attach with no IP requested then do a
> DHCPv4|DHCPv6 broadcast request. We only have that setup via our business
> unit (getting close to breaking 10k APN’s).
>
>
>
> The PGW passes the parameters back in the PCO in the create response which
> get back to the UE. If the mobile doesn’t request something, by standard the
> PGW doesn’t send it. That cause some challenges when some vendors UE’s
> didn’t request DNS. Another feature and PGW sends DNS even when it wasn’t
> requested. This is the stuff that drives me crazy.
>
>
>
> Right now we are working with vendors, mobile device requirements and on a
> 3GPP submission to allow PGW to modify MTU on the fly and device must switch
> to the new MTU. Not all transport networks support larger than 1500 byte MTU
> and all of the possible encapsulations can result in GTP fragmentation.
> Besides the performance hit there are issues when there are too many packets
> between fragments. At the higher speeds this breaks flows so we got vendors
> to implement configurable size but we can’t fix non-TCP services that break.
> We adjust the MSS for TCP.
>
Terry,

The idea that all networks are using jumbo frames so that
fragmentation is not a problem any more is another myth that seems to
perpetuate. I've also seen fragmentation in the datacenter networks
caused by encapsulation. I would point out that one advantage of ILA
is that it transforms addresses without increasing packet size so
there's no issues with MTU or fragmentation.

Tom

>
>
> We are pushing hard on MTU2000 but in some places you have only one choice
> for transport (e.g. Alaska). Even AT&T doesn’t have the resources to run
> fiber to all locations in North America. Mexico is a bit of a pain. We can
> justify microwave relay in many places but not all (too costly for too
> little pop coverage).
>
>
>
> 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
> 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
> but Syniverse now supports interop with a large number of telecoms via their
> IPX or in conjunction with country specific IPX.
>
>
>
> Tektronix and other test tool vendors all support IPv6 GTP-C|GTP-U. IPv6 GTP
> has been supported for several years in production networks. It’s very
> Cc: <[email-masked]>, <[email-masked]>, Nick HEATLEY <[email-masked]>
>
>
>
>
> refer, Nick HEATLEY from bt.com, 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> 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.
>
>
>
> 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.
>
>
>

---

From: Ca By <[email-masked]>
Date: Fri, 26 Jan 2018 01:03:20 +0000

Terry,

Thanks again. Very interesting. But i will repost my original question.  A
possible answer is that under no circumstance will an at&t retail
subscriber will receive only an ipv6 address on the UE default apn — like
464xlat or HEv2.  I know TMUS and Sprint use 464xlat today in the usa.

Regarding your mtu woes, i believe Android responds to the the MTU passed
in the IPv6 RA.

Thanks again
CB

On Thu, Jan 25, 2018 at 3:51 PM FIGURELLE, TERRY F <[email-masked]> wrote:

> HSS has a setting on what IP address family is provisioned on an APN for
> the given IMSI. It supports IPv4 only; IPv6 only; IPv4 or IPv6; IPv4 or
> iPv6 or IPv4v6. It can adjust that based on service area (typically on-net,
> domestic or international). Plus we learn both 3GPP QoS support and address
> family support while roaming then adjust on a per PLMN regular expression
> (configuration entry).
>
>
>
> The UE can request a number of things including address family (uses an
> all zero IPv4 or IPv6 address), DNSv4 IP’s, DNSv6 IP’s, MTU, P-CSCF IP.
> There also is support for UE to attach with no IP requested then do a
> get back to the UE. If the mobile doesn’t request something, by standard
> the PGW doesn’t send it. That cause some challenges when some vendors UE’s
> 3GPP submission to allow PGW to modify MTU on the fly and device must
> switch to the new MTU. Not all transport networks support larger than 1500
> byte MTU and all of the possible encapsulations can result in GTP
> fragmentation. Besides the performance hit there are issues when there are
> too many packets between fragments. At the higher speeds this breaks flows
> so we got vendors to implement configurable size but we can’t fix non-TCP
> services that break. We adjust the MSS for TCP.
>
>
>
> *From:* Ca By [mailto:[email-masked]]
> *Sent:* Wednesday, January 24, 2018 6:25 PM
>
>
> *To:* FIGURELLE, TERRY F <[email-masked]>
>
> *Cc:* [email-masked]; [email-masked]; [email-masked];
> [email-masked]
>
>
> *Subject:* Re: [5gangip] IPv6 GTP-C/GTP-U
>
> Terry,
>
>
>
> 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
> “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

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Fri, 26 Jan 2018 04:55:31 +0000

Yeah, there are some really weird locations even in continental US. Where some ma & pa setup owns rights for tiny but critical locations. Other places you can't get any right of way to run fiber.  Satellite relays adds too much latency (GEO adds ~7 seconds but LEO is viable if you deploy a large enough constellation). Other places we have to worry about destruction of the cell site. Others need to be self-sufficient (on site power generation).

On encapsulation -

Except we still have WiFi encapsulation (IPsec VPN) and active handoffs so the MTU size can still be wrong. Small cell also uses IPsec VPN, so we have those bullets to deal with. But MTU size is one of the reasons to look at options to remove GTP.

Terry Figurelle

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Thursday, January 25, 2018 4:12 PM
To: FIGURELLE, TERRY F <[email-masked]>
Cc: Ca By <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

Terry,

Tom

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=-pf_I4wMueLB_hK7U9ZbBgPjxiOHflepyyvf9DxkF8Q&s=kZ2z_C4ENST3-UdI-nO_gN5tlkpo4DJ3qrBOS5HB2VQ&e= 
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_5gangip&d=DwIFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=tO_sNxa2NTxwl2paJIf4zw&m=-pf_I4wMueLB_hK7U9ZbBgPjxiOHflepyyvf9DxkF8Q&s=kZ2z_C4ENST3-UdI-nO_gN5tlkpo4DJ3qrBOS5HB2VQ&e= 
>

---

From: "FIGURELLE, TERRY F" <[email-masked]>
Date: Fri, 26 Jan 2018 05:33:57 +0000

That includes small cell but our commitments due to our FirstNet win have us building as fast as we can. Besides risk avoidance this was one of the biggest reasons we used multiple vendors. We really tapped out some vendor’s resources and now we have Mexico buildouts too. I remember when 50 sites/month was a great number so when we first topped 1000, I was stunned. The downside is that when everyone slows down you have a lot of excess people looking for work.

A lot of vendors are counting on 5G to get the books back in the black. The whole industry looks different than it did just a few years ago. I’m feeling my age and not sure how long before I choose to retire. The bleeding edge is exciting but not really the best place to stay for so long.

Terry Figurelle

From: AshwoodsmithPeter [mailto:[email-masked]]
Sent: Wednesday, January 24, 2018 10:37 AM
To: FIGURELLE, TERRY F <[email-masked]>; Ca By <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [5gangip] IPv6 GTP-C/GTP-U

Peter

From: 5gangip [mailto:[email-masked]] On Behalf Of FIGURELLE, TERRY F
Sent: Wednesday, January 24, 2018 11:58 AM
To: Ca By <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

Terry Figurelle

Sent from my iPhone

Alex

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Jan 2018 08:39:32 +0100

Le 26/01/2018 à 02:03, Ca By a écrit :
> Terry,
> 
> Thanks again. Very interesting. But i will repost my original question.  
> A possible answer is that under no circumstance will an at&t retail 
> subscriber will receive only an ipv6 address on the UE default apn — 
> like 464xlat or HEv2.  I know TMUS and Sprint use 464xlat today in the usa.
> 
> Regarding your mtu woes, i believe Android responds to the the MTU 
> passed in the IPv6 RA.

If any interest, I can confirm that the linux kernel in general responds 
well to variations of the MTU size in RA.  Reduce the MTU size in RA and 
the kernel starts fragmenting the IP packet.  Even more on WiFi: fill in 
802.11 fields that say it's a fragment.  I suppose 3GPP wants to do 
something similar to 802.11 but on 3GPP MAC headers.

I presented a slide at IETF about this IP over 802.11 fragmentation when 
MTU changes in RA.

Alex

> 
> Thanks again
> CB
> 
> 
> On Thu, Jan 25, 2018 at 3:51 PM FIGURELLE, TERRY F <[email-masked] 
>     HSS has a setting on what IP address family is provisioned on an APN
>     for the given IMSI. It supports IPv4 only; IPv6 only; IPv4 or IPv6;
>     IPv4 or iPv6 or IPv4v6. It can adjust that based on service area
>     (typically on-net, domestic or international). Plus we learn both
>     3GPP QoS support and address family support while roaming then
>     adjust on a per PLMN regular expression (configuration entry).____
> 
>     __ __
> 
>     The UE can request a number of things including address family (uses
>     an all zero IPv4 or IPv6 address), DNSv4 IP’s, DNSv6 IP’s, MTU,
>     P-CSCF IP. There also is support for UE to attach with no IP
>     requested then do a DHCPv4|DHCPv6 broadcast request. We only have
>     that setup via our business unit (getting close to breaking 10k
>     APN’s).____
> 
>     __ __
> 
>     The PGW passes the parameters back in the PCO in the create response
>     which get back to the UE. If the mobile doesn’t request something,
>     by standard the PGW doesn’t send it. That cause some challenges when
>     some vendors UE’s didn’t request DNS. Another feature and PGW sends
>     DNS even when it wasn’t requested. This is the stuff that drives me
>     crazy.____
> 
>     __ __
> 
>     Right now we are working with vendors, mobile device requirements
>     and on a 3GPP submission to allow PGW to modify MTU on the fly and
>     device must switch to the new MTU. Not all transport networks
>     support larger than 1500 byte MTU and all of the possible
>     encapsulations can result in GTP fragmentation. Besides the
>     performance hit there are issues when there are too many packets
>     between fragments. At the higher speeds this breaks flows so we got
>     vendors to implement configurable size but we can’t fix non-TCP
>     services that break. We adjust the MSS for TCP.____
> 
>     __ __
> 
>     We are pushing hard on MTU2000 but in some places you have only one
>     choice for transport (e.g. Alaska). Even AT&T doesn’t have the
>     resources to run fiber to all locations in North America. Mexico is
>     a bit of a pain. We can justify microwave relay in many places but
>     not all (too costly for too little pop coverage).____
> 
>     __ __
> 
>     Yes, we spent a lot of time trying to get MTU discovery to work in
>     all situations.____
> 
>     __ __
> 
>     We have some pretty fancy roaming controls on PCRF too.____
> 
>     __ __
> 
>     *Terry Figurelle*____
> 
>     *cell - (206)601-5157____*
> 
>     __ __
> 
>     *From:*Ca By [mailto:[email-masked] <mailto:[email-masked]>]
>     *To:* FIGURELLE, TERRY F <[email-masked] <mailto:[email-masked]>>
> 
>     [email-masked] <mailto:[email-masked]>;
>     *Subject:* Re: [5gangip] IPv6 GTP-C/GTP-U____
> 
>     Terry,____
> 
>     __ __
> 
>     Very helpful info. Comments inline. ____
> 
>     __ __
> 
>     On Wed, Jan 24, 2018 at 8:59 AM FIGURELLE, TERRY F <[email-masked]
>     <mailto:[email-masked]>> wrote:____
> 
>         We have deployed more than 20k eNB’s that use IPv6 only
>         transport for S1-U and all of our SGW’s and PGW’s support IPv6
>         transport for GTP-U and GTP-C. 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.). ____
> 
>         ____
> 
>         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). ____
> 
>     __ __
> 
>     configuration on a UE for default data apn?  Can you elaborate on
>     what transition method is used ?____
> 
>     __ __
> 
>         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
>         virtualize EPC (Intel COTS hardware, hypervisor, etc.) that
>         supports IPv6 GTP. Verizon, T-Mobile (USA) and Sprint also use
>         IPv6.____
> 
>         ____
> 
>     __ __
> 
>     __ __
> 
>         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.____
> 
>         ____
> 
>         *Lead Member of Technical Staff*____
> 
>         *Wireless Network Arch. & Design*____
> 
>         *Mobility Core*____
> 
>         *AT&T Services*____
> 
>         *cell - (206)601-5157*____
> 
>         ____
> 
>             <[email-masked] <mailto:[email-masked]>>
>             Cc: <[email-masked] <mailto:[email-masked]>>,
>             <[email-masked] <mailto:[email-masked]>>, Nick HEATLEY
>             <[email-masked] <mailto:[email-masked]>>____
> 
> 
> 
> 
>             separate APN. </dl>____
>             which
>             across the
>             now that N3
>             offer different
>             control-plane
>             user-plane. </dl>
>             GTP-c used between MME and SGW (S11 interface)   S1-MME (eNB
>             to MME for control plane uses SCTP.____
> 
>             ____
> 
>             current S1-MME).____
>             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.____
> 
>             ____
> 
>             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>____
> 
>         ____
> 
>         Both  rockets and cricket use physics, and anyone can comment
>         how it might work. ____
> 
>         ____
> 
>         ____
> 
>         ____
> 
> 
>             Alex____
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 26 Jan 2018 08:40:20 +0100

Le 26/01/2018 à 00:51, FIGURELLE, TERRY F a écrit :
[...]

> DHCPv4|DHCPv6 broadcast request.

I note DHCPv6 in another operator's network.

Alex

---

From: <[email-masked]>
Date: Fri, 26 Jan 2018 07:46:05 +0000

<off-topic>

“A lot of vendors are counting on 5G to get the books back in the black”

This concerns me in the days of rapidly falling ARPUs and mobile plans being sold with the weekly groceries at the supermarket for virtually nothing.   Mobile service is essentially free in many parts of the world now…

I’m not sure how much longer we can carry on building-out competitive infrastructure; the well-publicised “not-spots” and political hype around serving the under-served (the “national roaming” which never happened for example) really point-out that national infrastructure has never worked in a competitive model (c.f. electricity grids, railways, water, roads) and at some point they all collapse to shared ownership models of one sort or another.

My technical concern is that we predicate the 5G architecture on the previous 4G/3G/2G architectures and as operator-based silos, an assumption which I suspect will be incorrect along the life of 5G.

</off-topic>

From: FIGURELLE, TERRY F [mailto:[email-masked]]
Sent: 26 January 2018 05:34
To: AshwoodsmithPeter <[email-masked]>; Ca By <[email-masked]>; Lake D Mr (PG/R - Elec Electronic Eng) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [5gangip] IPv6 GTP-C/GTP-U

Terry Figurelle

Peter

Terry Figurelle

Sent from my iPhone

Alex

---

From: <[email-masked]>
Date: Fri, 26 Jan 2018 07:50:11 +0000

Satellite backhaul, 4g as backhaul for 3g, and femto vpn encapsulation all add to mtu challenges in the UK. Impact to performance and scale if it is not managed. Nick

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: FIGURELLE, TERRY F <[email-masked]>
Sent: Friday, January 26, 2018 4:55:31 AM
To: Tom Herbert
Cc: Ca By; [email-masked]; [email-masked]; Heatley,N,Nick,TQB R
Subject: RE: [5gangip] IPv6 GTP-C/GTP-U

On encapsulation -

Terry Figurelle

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]]
Sent: Thursday, January 25, 2018 4:12 PM
To: FIGURELLE, TERRY F <[email-masked]>
Cc: Ca By <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [5gangip] IPv6 GTP-C/GTP-U

Terry,

Tom

---

From: Alexandre Petrescu <[email-masked]>
Date: Tue, 30 Jan 2018 11:50:36 +0100

This table is valuable, because it speaks to the 3GPP-inclined and to 
IETF-inclined.  It says "GTP" and also "IP".  It is also valuable 
because it says "Not yet defined" which can be interpreted as something 
to work on.

       Generation of Mobile Network vs Protocol

4G           5G Equivalent            Protocol
-------------------------------------------------------
S1		N3			GTP
S5/S8		N9			Not yet defined
SGi		N6			IP
S11		N4			PFCP

Alex