Subject: Re: [multimob] Comments on draft-deng-multimob-pmip6-requirement-01.txt

From: "John.zhao" <[email-masked]>
Date: Tue, 04 Nov 2008 14:25:03 +0800

Hi,hui
 
    Forget to post the reply in maillist. See following comments.
    You are right. They are all need MN to send the request to join to
trigger the receive of multicast except the CMMB , I'm not sure. But it is
because we didn't have other methods to be used before. Currently, some
system just like IEEE802.16 is discussing about this kind of support via
layer-2, once it is ready, then the joinging in layer-3 can be omitted. In
another side, the DVB-H is another case, since it havn't the uplink , so
even mobile node want to send the joining request, but the request can't be
sent to network. It is a kind of "uni-direction link". I think it is useful
for operator to push some feature service within its domian .
    How about it?

    Best Rgds,
Thanks,

john.zhao

  _____  

Hi, John,

Sorry for my late reply, here you are suggesting that we would better
include network preconfigured multicast service which need infrastrucutre
support.

What I could remind is that normally such kind of service will be provided
by MBMS, BCMCS, especially mobile TV service they also could be based on
dedicated TV mechanism like CMMB.
 
thanks for your discussion.
 
-Hui

2008/10/24 John.zhao <[email-masked]>

Hello,Hui and all
 
    One comments on section 3.1 about "R2 - The mobile node is responsible
for initially subscribing to the multicast group(s)." . To some network
control multicast service, this subscribtion info can be got from policy
store or pre-configuration on MAG. I don't object MN can't initiate the
subscribtion,but the subscribtion is no need rely on the request come from
MN only. With only MN initiated subscription of multicast group(s),the
operator's network will:
 1.1)No network originated service support. All of any kind of multicast
service will be initiated from MN.But in fact, there are still some typical
service should be managed from network side.From the point of view of the MN
it is like a TV broadcast model. It is worth to handle this case too because
it may corresponds to DVB-H mobile TV service use-case.
 1.2)Cost additional wireless resource in wireless situation. Without it ,
we can save more resource not only during handover but also in network entry
progress. Espically, it is useful to those static multicast tree scenario.
    From the architecture perspective, the support of network management is
the base of MN management. Since other signal flow will be the same except
MAG need have the ability to deal with additional MLD report sent from MN.So
it is no more additional cost on current design but bring a better
scability.

    In detail, the progress of the management of multicast service by
network just like the following:
 When the MN just attachs to a MAG, the MAG will get the MN's profile and
will know some pre-configured multicast services need to be established,
then it will ask LMA to provide the respective service, in this case, the
method used to communicate to LMA from MAG can be either PMIP signals or MLD
report(join) messages etc. LMA will check about this request and do the
decision based on it's acknowledges about it.
     During handover, it will be very like current design. The CXT is expect
to provide necessary multicast infomation and if need, a 3-rd party policy
store is required. 
 
    On summary, considering and allowing network administrativly
subscription didn't impact on anything current we have considered and in
addition , it can bring a scalability to current requirement of proxy
multicast mobility.
 
    Best Rgds,
Thanks,

john.zhao

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

---

From: "von Hugo, Dirk" <[email-masked]>
Date: Tue, 4 Nov 2008 14:21:55 +0100

Dear all,

Not directly answering the threads but rather commenting on the topic from an other operator's viewpoint: 

As far as I understand it CMMB (China Multimedia Mobile Broadcasting) should be similar to Europe's DVB-SH (Satellite services to Handhelds) standard for DVB (digital video broadcast) which is based on a hybrid satellite/terrestrial downlink combined with a different return channel (e.g. via WLAN or 2G/3G) - such it should allow for normal MLD operation as in MBMS (Multimedia Broadcast/Multicast Service) within 3GPP/UMTS or 3GPP2 BCMCS (Broadcast and Multicast Services) which provides an approach to multicast for mobile, an overlay to mobile networks that provides multicast support ... - furthermore DVB-IP Phase 1.3 will include IPTV subscription via IGMP/MLD.

Concerning pure DVB there is an assumption that L3 at the MN does send an MLD to the interface (L2.x) such that the correspondingly addressed multicast packets within DVB stream are filtered and forwarded to L3.

I agree that operator requirements for network preconfigured multicast service would include handover support (subscription on behalf of MN to save resources or strengthen the unreliable message transport) and may cover specific control or management services (e.g. notification of available multicast streams to subscribe to such as DVB's ESG -  Electronic Servuice Guide or for operator-distributed additional support services such as authorisation keys for decoding content)

Best regards 

Dirk 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von John.zhao
Gesendet: Dienstag, 4. November 2008 07:25
An: 'Hui Deng'
Cc: [email-masked]
Betreff: Re: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-01.txt

Hi,hui

    You are right. They are all need MN to send the request to join to trigger the receive of multicast except the CMMB , I'm not sure. But it is because we didn't have other methods to be used before. Currently, some system just like IEEE802.16 is discussing about this kind of support via layer-2, once it is ready, then the joinging in layer-3 can be omitted. In another side, the DVB-H is another case, since it havn't the uplink , so even mobile node want to send the joining request, but the request can't be sent to network. It is a kind of "uni-direction link". I think it is useful for operator to push some feature service within its domian .

    How about it?

    Best Rgds,

Thanks,

john.zhao

  _____  

Hi, John,

Sorry for my late reply, here you are suggesting that we would better include network preconfigured multicast service which need infrastrucutre support.

What I could remind is that normally such kind of service will be provided by MBMS, BCMCS, especially mobile TV service they also could be based on dedicated TV mechanism like CMMB.

-Hui

Hello,Hui and all

    One comments on section 3.1 about "R2 - The mobile node is responsible for initially subscribing to the multicast group(s)." . To some network control multicast service, this subscribtion info can be got from policy store or pre-configuration on MAG. I don't object MN can't initiate the subscribtion,but the subscribtion is no need rely on the request come from MN only. With only MN initiated subscription of multicast group(s),the operator's network will:

 1.1)No network originated service support. All of any kind of multicast service will be initiated from MN.But in fact, there are still some typical service should be managed from network side.From the point of view of the MN it is like a TV broadcast model. It is worth to handle this case too because it may corresponds to DVB-H mobile TV service use-case.
 1.2)Cost additional wireless resource in wireless situation. Without it , we can save more resource not only during handover but also in network entry progress. Espically, it is useful to those static multicast tree scenario.
    From the architecture perspective, the support of network management is the base of MN management. Since other signal flow will be the same except MAG need have the ability to deal with additional MLD report sent from MN.So it is no more additional cost on current design but bring a better scability.

    In detail, the progress of the management of multicast service by network just like the following:
 When the MN just attachs to a MAG, the MAG will get the MN's profile and will know some pre-configured multicast services need to be established, then it will ask LMA to provide the respective service, in this case, the method used to communicate to LMA from MAG can be either PMIP signals or MLD report(join) messages etc. LMA will check about this request and do the decision based on it's acknowledges about it.
     During handover, it will be very like current design. The CXT is expect to provide necessary multicast infomation and if need, a 3-rd party policy store is required. 

    On summary, considering and allowing network administrativly subscription didn't impact on anything current we have considered and in addition , it can bring a scalability to current requirement of proxy multicast mobility.

    Best Rgds,

Thanks,

john.zhao

---

From: "John.zhao" <[email-masked]>
Date: Thu, 06 Nov 2008 16:01:26 +0800

Hi,Dirk
 
        Thanks for your explanation. See my comments inline.
    
    Best Rgds,
Thanks,

john.zhao

Dear all,

Not directly answering the threads but rather commenting on the topic from
an other operator’s viewpoint: 

As far as I understand it CMMB (China Multimedia Mobile Broadcasting) should
be similar to Europe's DVB-SH (Satellite services to Handhelds) standard for
DVB (digital video broadcast) which is based on a hybrid
satellite/terrestrial downlink combined with a different return channel
(e.g. via WLAN or 2G/3G) – such it should allow for normal MLD operation as
in MBMS (Multimedia Broadcast/Multicast Service) within 3GPP/UMTS or 3GPP2
BCMCS (Broadcast and Multicast Services) which provides an approach to
multicast for mobile, an overlay to mobile networks that provides multicast
support … - furthermore DVB-IP Phase 1.3 will include IPTV subscription via
IGMP/MLD.
[John.zhao] So inteactive return channel is optional and the support of
IGMP/MLD is for future,right?

Concerning pure DVB there is an assumption that L3 at the MN does send an
MLD to the interface (L2.x) such that the correspondingly addressed
multicast packets within DVB stream are filtered and forwarded to L3.
[John.zhao] If are you mean that MN will send MLD from L3 to interface in L2
to inform about related multicast address etc . But L2 may filter it and
didn't send it out if no return channel available?

I agree that operator requirements for network preconfigured multicast
service would include handover support (subscription on behalf of MN to save
resources or strengthen the unreliable message transport) and may cover
specific control or management services (e.g. notification of available
multicast streams to subscribe to such as DVB’s ESG -  Electronic Servuice
Guide or for operator-distributed additional support services such as
authorisation keys for decoding content)
[John.zhao] Yes. Agree. 

Best regards 

Dirk 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag
von John.zhao
Gesendet: Dienstag, 4. November 2008 07:25
An: 'Hui Deng'
Cc: [email-masked]
Betreff: Re: [multimob] Comments
ondraft-deng-multimob-pmip6-requirement-01.txt

Hi,hui

    How about it?

    Best Rgds,

Thanks,

john.zhao

  _____  

Hi, John,

-Hui

Hello,Hui and all

    Best Rgds,

Thanks,

john.zhao

---

From: "von Hugo, Dirk" <[email-masked]>
Date: Thu, 6 Nov 2008 09:06:19 +0100

Dear John,

exactly that's what I wanted to say ...

Thanks and best regards

Dirk 

-----Ursprüngliche Nachricht-----
Von: John.zhao [mailto:[email-masked]] 
Gesendet: Donnerstag, 6. November 2008 09:01
An: von Hugo, Dirk; [email-masked]
Cc: [email-masked]
Betreff: RE: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-01.txt

Hi,Dirk

    Best Rgds,

Thanks,

john.zhao

Dear all,

As far as I understand it CMMB (China Multimedia Mobile Broadcasting) should be similar to Europe's DVB-SH (Satellite services to Handhelds) standard for DVB (digital video broadcast) which is based on a hybrid satellite/terrestrial downlink combined with a different return channel (e.g. via WLAN or 2G/3G) - such it should allow for normal MLD operation as in MBMS (Multimedia Broadcast/Multicast Service) within 3GPP/UMTS or 3GPP2 BCMCS (Broadcast and Multicast Services) which provides an approach to multicast for mobile, an overlay to mobile networks that provides multicast support ... - furthermore DVB-IP Phase 1.3 will include IPTV subscription via IGMP/MLD.
[John.zhao] So inteactive return channel is optional and the support of IGMP/MLD is for future,right?

Concerning pure DVB there is an assumption that L3 at the MN does send an MLD to the interface (L2.x) such that the correspondingly addressed multicast packets within DVB stream are filtered and forwarded to L3.
[John.zhao] If are you mean that MN will send MLD from L3 to interface in L2 to inform about related multicast address etc . But L2 may filter it and didn't send it out if no return channel available?

Best regards 

Dirk 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von John.zhao
Gesendet: Dienstag, 4. November 2008 07:25
An: 'Hui Deng'
Cc: [email-masked]
Betreff: Re: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-01.txt

Hi,hui

    How about it?

    Best Rgds,

Thanks,

john.zhao

  _____  

Hi, John,

-Hui

Hello,Hui and all

    Best Rgds,

Thanks,

john.zhao

---

From: "John.zhao" <[email-masked]>
Date: Thu, 06 Nov 2008 17:58:18 +0800

Hi, Dirk

        In addition, why not set network to promiscuous mode, since the
IGMP/MLD will not be sent to network? In that mode, application can got all
of packets sent to it and it can deal with them in application layer.
Although that will make the development a little complict.
 
        Best Rgds,
Thanks,    

john.zhao

Dear John,

exactly that’s what I wanted to say …

Thanks and best regards

Dirk 

-----Ursprüngliche Nachricht-----
Von: John.zhao [mailto:[email-masked]] 
Gesendet: Donnerstag, 6. November 2008 09:01
An: von Hugo, Dirk; [email-masked]
Cc: [email-masked]
Betreff: RE: [multimob] Comments

Hi,Dirk

    Best Rgds,

Thanks,

john.zhao

Dear all,

Best regards 

Dirk 

-----Ursprüngliche Nachricht-----

Hi,hui

    How about it?

    Best Rgds,

Thanks,

john.zhao

  _____  

Hi, John,

-Hui

Hello,Hui and all

    Best Rgds,

Thanks,

john.zhao

---

From: "von Hugo, Dirk" <[email-masked]>
Date: Thu, 6 Nov 2008 16:50:06 +0100

Hi John,

do you mean that _all_ received packets will be forwarded by L2 to application layer without any filtering? Additionally to complexity as you already mentioned I think that may impose security concerns also ... wouldn't it be more efficient if L2 could interprete IGMP/MLD such that IP Multicast addresses are mapped to corresponding MAC addresses  - and thus L2 interface would forward only wanted traffic to higher layers?

BTW this may be a marginal problem only for multimob.

Best regards 

Dirk 

-----Ursprüngliche Nachricht-----
Von: John.zhao [mailto:[email-masked]] 
Gesendet: Donnerstag, 6. November 2008 10:58
An: von Hugo, Dirk; [email-masked]
Cc: [email-masked]
Betreff: RE: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-01.txt

Hi, Dirk

        In addition, why not set network to promiscuous mode, since the IGMP/MLD will not be sent to network? In that mode, application can got all of packets sent to it and it can deal with them in application layer. Although that will make the development a little complict.

        Best Rgds,

Thanks,    

john.zhao

Dear John,

Thanks and best regards

Dirk 

-----Ursprüngliche Nachricht-----
Von: John.zhao [mailto:[email-masked]] 
Gesendet: Donnerstag, 6. November 2008 09:01
An: von Hugo, Dirk; [email-masked]
Cc: [email-masked]
Betreff: RE: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-01.txt

Hi,Dirk

    Best Rgds,

Thanks,

john.zhao

Dear all,

Best regards 

Dirk 

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von John.zhao
Gesendet: Dienstag, 4. November 2008 07:25
An: 'Hui Deng'
Cc: [email-masked]
Betreff: Re: [multimob] Comments ondraft-deng-multimob-pmip6-requirement-01.txt

Hi,hui

    How about it?

    Best Rgds,

Thanks,

john.zhao

  _____  

Hi, John,

-Hui

Hello,Hui and all

    Best Rgds,

Thanks,

john.zhao

---

From: "John.zhao" <[email-masked]>
Date: Fri, 07 Nov 2008 09:40:52 +0800

Hi,Dirk
 
    If will the netcard be set as promiscuous mode, the user need do the
filter program by itself. And some this kind of program can be set up by
user freely, such as wireshark etc. From network, we can't prevent it. To
security, it is not a big problem, since transport and application security
mechanism can gurantee about it. Even if some encoded packets are captured,
it can't be decoded normally without the relevant SAs. 
    In addition, this mode is worst in shared-link. In that case, those
broadcast or packets for others can be got by this host. So if promiscuous
is set , so many un-related will make the application on this host trouble.
On the contrary , to p2p link , since all of packets destined to this host
is filtered and controled by MAG. So basically, those packets should be
handled by this host. Thus, receive them didn't waste any other resources.
>From performance perspective, I think it is the same as APIs provided by os.
    To my understand, it can be used to those p2p kind of link , and
uni-direction link seems also belong to this scope. So, can it also
applicable to DVB-H style network?
 
    Best Rgds,
Thanks,

john.zhao

Hi John,

do you mean that _all_ received packets will be forwarded by L2 to
application layer without any filtering? Additionally to complexity as you
already mentioned I think that may impose security concerns also … wouldn’t
it be more efficient if L2 could interprete IGMP/MLD such that IP Multicast
addresses are mapped to corresponding MAC addresses  - and thus L2 interface
would forward only wanted traffic to higher layers?

Best regards 

Dirk 

-----Ursprüngliche Nachricht-----
Von: John.zhao [mailto:[email-masked]] 
Gesendet: Donnerstag, 6. November 2008 10:58
An: von Hugo, Dirk; [email-masked]
Cc: [email-masked]
Betreff: RE: [multimob] Comments

Hi, Dirk

        Best Rgds,

Thanks,    

john.zhao

Dear John,

Thanks and best regards

Dirk 

-----Ursprüngliche Nachricht-----
Von: John.zhao [mailto:[email-masked]] 
Gesendet: Donnerstag, 6. November 2008 09:01
An: von Hugo, Dirk; [email-masked]
Cc: [email-masked]
Betreff: RE: [multimob] Comments

Hi,Dirk

    Best Rgds,

Thanks,

john.zhao

Dear all,

Best regards 

Dirk 

-----Ursprüngliche Nachricht-----

Hi,hui

    How about it?

    Best Rgds,

Thanks,

john.zhao

  _____  

Hi, John,

-Hui

Hello,Hui and all

    Best Rgds,

Thanks,

john.zhao

---

From: "Hui Deng" <[email-masked]>
Date: Sun, 9 Nov 2008 23:47:56 +0800

Hi, John,

sorry for my late reply, inline

2008/11/4 John.zhao <[email-masked]>

> layer-2, once it is ready, then the joinging in layer-3 can be omitted.
>
what kind of support layer-2, if you are talking about layer-2, it means
something happened
between network and mobile.

>  In another side, the DVB-H is another case, since it havn't the uplink ,
> so even mobile node want to send the joining request, but the request can't
> be sent to network.
>
DVB-H will not use proxy MIP6, right?

>  It is a kind of "uni-direction link". I think it is useful for operator
> to push some feature service within its domian .
>      How about it?
>
>
I will try to reply based on below email,

-Hui

>
>     Best Rgds,
> Thanks,
>
>
>
> john.zhao
>  ------------------------------
> Hi, John,
>
>
>>     One comments on section 3.1 about "R2 - The mobile node is
>> responsible for initially subscribing to the multicast group(s)." . To some
>> network control multicast service, this subscribtion info can be got from
>> policy store or pre-configuration on MAG. I don't object MN can't initiate
>> the subscribtion,but the subscribtion is no need rely on the request come
>> from MN only. With only MN initiated subscription of multicast group(s),the
>> operator's network will:
>>     From the architecture perspective, the support of network management
>> is the base of MN management. Since other signal flow will be the same
>> except MAG need have the ability to deal with additional MLD report sent
>> from MN.So it is no more additional cost on current design but bring a
>> better scability.
>>
>>      During handover, it will be very like current design. The CXT is
>> expect to provide necessary multicast infomation and if need, a 3-rd party
>> policy store is required.
>>

---

From: "Hui Deng" <[email-masked]>
Date: Sun, 9 Nov 2008 23:52:45 +0800

Hi, Dirk and John

thanks for the discussion.

If we set it as promiscuous mode, then something smart has to be done in the
client side,
then we couldn't call it pure network support without client involvement.

for wireshark, we couldn't prevent it happen, but normally it is hard for
operator to support it,
What we can do is more simple way for subscriber to use it.

thanks again

-Hui

2008/11/7 John.zhao <[email-masked]>

> already mentioned I think that may impose security concerns also … wouldn't
> *Von:* John.zhao [mailto:[email-masked]]
> *Gesendet:* Donnerstag, 6. November 2008 10:58
> *An:* von Hugo, Dirk; [email-masked]
> *Cc:* [email-masked]
> *Betreff:* RE: [multimob] Comments
> exactly that's what I wanted to say …
>
> Thanks and best regards
>
> Dirk
>
> *Von:* John.zhao [mailto:[email-masked]]
> *Gesendet:* Donnerstag, 6. November 2008 09:01
> *An:* von Hugo, Dirk; [email-masked]
> *Cc:* [email-masked]
> *Betreff:* RE: [multimob] Comments
> an other operator's viewpoint:
>
>
>
> As far as I understand it CMMB (China Multimedia Mobile Broadcasting)
> should be similar to Europe's DVB-SH (Satellite services to Handhelds)
> standard for DVB (digital video broadcast) which is based on a hybrid
> [John.zhao] If are you mean that MN will send MLD from L3 to interface in
> L2 to inform about related multicast address etc . But L2 may filter it and
> multicast streams to subscribe to such as DVB's ESG -  Electronic Servuice
> *Von:* [email-masked] [mailto:[email-masked]] *Im
> Auftrag von *John.zhao
> *Gesendet:* Dienstag, 4. November 2008 07:25
> *An:* 'Hui Deng'
> *Cc:* [email-masked]
> *Betreff:* Re: [multimob] Comments