Subject: Re: [5gangip] [Ideas] Mapping System Requirements and draft-padma-ideas-problem-statement-00.txt

From: Jouni korhonen <[email-masked]>
Date: Mon, 3 Oct 2016 11:44:09 -0700

Obviously M1 is used to carry user plane multicast traffic. However, as said 36.445 is a starting point for a number of specs. 36.445 clause 5.1 says the transport bearer (i.e. the IP transport below GTP-U) is identified among others by IP multicast address. Continuing to referenced 29.281 clause 4.2.6 which is quite clear about multicast addressing of GTP-U messages, 23.246 clauses 5.5, 6.5 and finally 36.440 clause 5. Point-to-multipoint GTP-U messages that use multicast addressing have slightly different use & assignment of TEIDs than unicast GTP-Us. This stuff here on GTP-U applies to the transport network between MBMS-GW and eNBs (for EPS, 3G etc were slightly different).

Those nodes that cannot receive multicast addressed GTP-U messages (like some older RNCs) will receive unicast addressed GTP-U traffic carrying multicast user payload..

- Jouni

On Sep 30, 2016, at 2:31 PM, Behcet Sarikaya <[email-masked]> wrote:

> On Fri, Sep 30, 2016 at 2:49 PM, Jouni korhonen <[email-masked]> wrote:
>> 
>> On Sep 30, 2016, at 9:47 AM, Robert Moskowitz <[email-masked]> wrote:
>> 
>>> And one addition here.  I have not even concerned myself with multicast until we can vastly improve on GTP-U.  Maybe I am making more out of it than needed, but with everything going down a pipe to a coupe heads, something other than IP multicast may be a better approach.
>>> 
>>> And I was told that any proposal to change GTP-U within 3GPP is a non-starter.  So go figure.  But then someone may have better connections within 3GPP on this.
>> 
>> I take you are referring to GTP-Uv1. Depends what you want to change on it. Incremental stuff is usually doable as long as it does not break old stuff.
>> 
>> At the beginning of Rel-8 there were attempts to do bigger changes to GTP-U (like having a GTP-Uv2) but there was considerable push back.. AFAIR (it’s been long time ;) due GTP-U using boxes in RAN, not really in core network.
>> 
>> Btw, there is multicast (MBMS) flavor of GTP-U. Just look at TS36.445 as a starting point.
>> 
> 
> This is not multicast GTP-U, 36.445 says that GTP-U will be used to
> carry or tunnel IP multicast over M1 interface from eNB to the EPC,
> i.e. SGW.
> 
> Behcet
>> - Jouni
>> 
>> 
>>> 
>>> Bob
>>> 
>>> On 09/30/2016 12:13 PM, Behcet Sarikaya wrote:
>>>> I don't understand why this conversation is being hidden from the list.
>>>> 
>>>> Folks, I worked on multicast mobility.
>>>> I was co-chair of multicast mobility or Multimob WG from 2009 to 2014.
>>>> Multimob scope was adding multicast support to the unicast mobility
>>>> protocols of PMIPv6 and a bit of MIPv6.
>>>> 
>>>> We did work it out, found good solutions and successfully terminated
>>>> the WG (BTW, good lesson to long lasting WGs :)
>>>> .
>>>> However, there is a caveat, IETF did not give us any standard stack
>>>> RFCs, only experimental or informational.
>>>> 
>>>> So the message is clear, let us solve the unicast problem first and
>>>> them worry about multicast support.
>>>> 
>>>> Behcet
>>>> On Tehu, Sep 29, 2016 at 6:12 PM, Rex Buddenberg <[email-masked]> wrote:
>>>>> On Thu, 2016-09-29 at 18:46 -0400, Tom Herbert wrote:
>>>>>> On Sep 29, 2016 6:32 PM, "Padmadevi Pillay Esnault" <[email-masked]
>>>>>>> wrote:
>>>>>>> 
>>>>>>> See below
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: 5gangip [mailto:[email-masked]] On Behalf Of Rex
>>>>>> Buddenberg
>>>>>>> Sent: Thursday, September 29, 2016 10:35 AM
>>>>>>> To: [email-masked]; AshwoodsmithPeter
>>>>>>> Cc: [email-masked]; Ca By; Michael Menth; Dino Farinacci
>>>>>>> Subject: Re: [5gangip] Mapping System Requirements and draft-padma-
>>>>>> ideas-problem-statement-00.txt
>>>>>>> On Thu, 2016-09-29 at 11:03 -0500, Behcet Sarikaya wrote:
>>>>>>>> In short, multicast mobility type of work is difficult to justify
>>>>>> but
>>>>>>>> certainly technically challenging :)
>>>>>>> Not so (difficult to justify).
>>>>>>> [Padma Pillay Esnault]
>>>>>>> Agree here.
>>>>>>> 
>>>>>>> If you look at the nature of emergency services data, a great deal
>>>>>> of
>>>>>>> it is multicast in nature -- has to go >1 places.  Indeed if you
>>>>>> talk
>>>>>>> to EMS folks who's view of the world is Land Mobile Radio, they
>>>>>> have a
>>>>>>> different set of terminology, but it's multicast.
>>>>>>> 
>>>>>>> Yes, technically challenging relative to unicast.  But if you get
>>>>>> the
>>>>>>> multicast right, unicast is a simpler subset.
>>>>>>> 
>>>>>>> Belongs in scope.
>>>>>>> 
>>>>>>> [Padma Pillay Esnault] Agree. As we are moving towards a hyper-
>>>>>> connected society, more and more services will multicast in nature.
>>>>>> Do you really want to control/communicate to things as in internet of
>>>>>> things one by one?
>>>>>> Security and reliability make this really hard, especially for
>>>>>> critical information like hazard warnings to autonomous vehicles. I'm
>>>>>> not sure how well VANET solves this which would seem to want a lot of
>>>>>> multicast.
>>>>> Depends on what security you need.  Content authenticity?  Not too bad
>>>>> -- recipients all need the sendor's public key.  Content
>>>>> confidentiality is harder using the existing PKI procedures.
>>>>>     I can't think of many applications where authenticity is not a
>>>>> requirement, but there are a lot where confidentiality is not.
>>>>> 
>>>>> Reliability.  TCP is a unicast protocol.  Period.  But there are
>>>>> multicast transport protocols (NORM is one) that provide reliability in
>>>>> multicast environments.
>>>>> 
>>>>> Just because a problem is hard does not mean the requirements are not
>>>>> legit.
>>>>> 
>>>>> 
>>>>>> Tom
>>>>>>> _______________________________________________
>>>>>>> Ideas mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/listinfo/ideas
>>>> _______________________________________________
>>>> 5gangip mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/5gangip
>>>> 
>>> 
>>> _______________________________________________
>>> 5gangip mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/5gangip
>> 
>> _______________________________________________
>> 5gangip mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/5gangip

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 3 Oct 2016 14:51:03 -0500

On Mon, Oct 3, 2016 at 1:44 PM, Jouni korhonen <[email-masked]> wrote:
>
>
> Obviously M1 is used to carry user plane multicast traffic. However, as said 36.445 is a starting point for a number of specs. 36.445 clause 5.1 says the transport bearer (i.e. the IP transport below GTP-U) is identified among others by IP multicast address.

Fine

>Continuing to referenced 29.281 clause 4.2.6 which is quite clear about >multicast addressing of GTP-U messages, 23.246 clauses 5.5, 6.5 and >finally 36.440 clause 5. Point-to-multipoint GTP-U messages that use >multicast addressing have slightly different use & assignment of TEIDs than > unicast GTP-Us.

GTP-U header is of 12 bytes long with 4 bytes of TEID.
I guess they came up with "multicast" TEIDs,
it is weird though because the packet has multicast IP address already
as the destination address which should come before GTP-U header in
the packet. Since they don't want to route based on that, they came up
with this multicast TEID trick, is this transport level multicast?

Maybe we can say that this is 3GPP's way of using identifiers and locators.

> This stuff here on GTP-U applies to the transport network between MBMS-GW and eNBs (for EPS, 3G etc were slightly different).
>

You are right, I noticed that they don't have SGW in eMBMS, they have MBMS GWs.
They use multicast TEID "identifiers" to route multicast traffic
towards MBMS-GWs that they want.

Behcet

---

From: Jouni korhonen <[email-masked]>
Date: Mon, 3 Oct 2016 13:23:10 -0700

I don’t understand what TEID tricks you are referring here.. routing is based on the transport (multicast) IP addresses. C-TEIDs and TEIDs are meaningful for nodes that originate/terminate tunnels.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 3 Oct 2016 15:47:06 -0500

> I don’t understand what TEID tricks you are referring here.. routing is based on the transport (multicast) IP addresses. C-TEIDs and TEIDs are meaningful for nodes that originate/terminate tunnels.

This was what I had said before, right?

So GTP-U tunnels multicast packet from eNodeB to MBMS-GW using TEIDs
specific to this purpose, there is no multicasting of any sort at that
level.
So there is no point-to-multipoint GTP-U messages.

---

From: Jouni korhonen <[email-masked]>
Date: Mon, 3 Oct 2016 23:44:18 -0700

> So GTP-U tunnels multicast packet from eNodeB to MBMS-GW using TEIDs

Unless something changed since Rel-13 it is to downlink and toward eNBs..

> So there is no point-to-multipoint GTP-U messages.

I don’t know how you ended up with these conclusions..  

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 4 Oct 2016 15:28:20 -0500

We need to debunk MBMS or eMBMS.
It is downlink based multicast/broadcast distribution technology.
Distribution starts at the BM-SC (broadcast/multicast-service center)
at the PDN GW level. BM-SC is connected to the content providers.

The next level is MBMS GW which is at the SGW level. And then there
comes the base stations of eNodeBs. MBMS was introduced in Release 6.
MBMS in LTE is called Evolved MBMS or eMBMS. eMBMS brings a lot of
improvements to MBMS, mostly in lower layers, called MBSFN, multicast
broadcast single frequency network, it is single frequency multicell
synchronized transmission network. MBMS Service Area is hierarchically
divided into MBSFN areas each composed of multiple cells. One eNodeB
can belong to upto 8 MBSFN areas.
There is MCE, multicell/multicast coordination entity which takes care
of radio scheduling and configuration of eNodeBs in the MBSFN area,
normally responsibility of eNodeBs in unicast case. M2 interface
connects eNodeB to MCE.
Downlink user data transmission is over M1 which connects MBMS GW to eNodeB.

MBMS is SSM system, i.e. source-specific multicast. For membership
management, IGMPv3 and MLDv2 are supported.

Coming to M1 interface, as TS 29.281 Section 4.2.6 explains, downlink
user plane data is distributed using GTP-U multicast tunnels. The IP
multicast source is MBMS GW and eNodeBs are IP multicast listeners.
The common Tunnel Endpoint ID (C-TEID) indicate which tunnel a
particular data packet belongs to. There is one C-TEID allocated per
MBMS bearer service and allocated at the source, MBMS GW. C-TEID is
carried in TEID field in GTP header.

Important point is the destination address in the outer GTPv1-U IP
header is a multicast address in SSM range. Participating eNodeBs join
the IP multicast group using proper IGMP/MLD join messages.

This point to multipoint "tunnel" between MBMS GW and subscribed
eNodeBs does not use unicast path management messages like Echo
Request/Response, Error Indication and the message End Marker.

So eMBMS carries multicast data in UDP (see RFC 5135), mainly to
indicate the tunnel ID or C-TEID.

Uplink is not specified. UE receives service announcements in RRC
System Information Block (SIB) message containing multicast group
address and UDP port.  The service could be file download or
streaming. FLUTE process for downloading and VLC process for streaming
are created with IP address and UDP port numbers and when the user
selects a specific service these processes take care of the streaming
or downloading on the UE side.

As for mobility,  service continuity is provided within the same MBSFN area.
Both MBMS cells and non-MBMS cells provide MBMS service area IDs (SAI)
of the current frequencies and of neighbour frequencies in system
information to the UEs. UE sends MBMS interest indications to the
network.

In short, as Cameron said eMBMS is a multicast file download or
streaming service which uses IP multicast in SSM mode, with UDP and
features point to multipoint downstream "tunnels" in GTP-U as
described above.

I expected all this provided to us by Jouni but it seems like his
interest was more to argue than to inform.

Behcet