Hi Pierrick,
I’ve many times thought about your question. I would say how effectively should we deploy/support multicast over distributed mobility rather than distributed mobile multicast. As a result, you can find this deployment use case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 presented in multimob several times. In unicast DMM, main innovation is to distribute the anchor function at many access routers from single core. Following architectural concept of DMM, flexible multicast distribution is one of multicast requirement resulted from the draft described above. REQ8: Flexible multicast distribution "DMM solutions SHOULD be compatible with flexible multicast distribution scenarios. This flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints". Motivation: The motivation for this requirement is to enable flexibility in multicast distribution. The multicast solution may therefore avoid having multicast-capable access routers being restricted to manage all IP multicast traffic relative to a host via a single endpoint (e.g. regular or tunnel interface), which would lead to the problems described in PS1 and PS6. PS6: Duplicate multicast traffic IP multicast distribution over architectures using IP mobility solutions may lead to convergence of duplicated multicast subscriptions towards the tunnel’s downstream entity (e.g. MAG in PMIPv6). Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03]. Regards, Seil From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com] Sent: Monday, November 19, 2012 8:55 AM To: 'karag...@cs.utwente.nl'; seilj...@av.it.pt; juancarlos.zun...@interdigital.com Cc: dmm@ietf.org Subject: RE: [DMM] Multicast requirements Hi all, I tend to agree with Georgious, however I still do not figure out what is the use-case for distributed mobile multicast (other than academic considerations)? Can someone give concrete example? I haven’t real all messages from this thread. So, maybe I missed important points. BR, Pierrick De : dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] De la part de karag...@cs.utwente.nl Envoyé : samedi 17 novembre 2012 13:01 À : seilj...@av.it.pt; juancarlos.zun...@interdigital.com Cc : dmm@ietf.org Objet : Re: [DMM] Multicast requirements Hi all, I also agree that the DMM solution should somehow consider muticast deployment. However, I do not thnk that the DMM WG is the right WG to provide the multicast based DMM solution! One alternative solution will be to have a multicast requirement that emphasizes the need of having extensibility hooks (possibilities) that can be used later on by the multimob WG to provide a a multicast enabled DMM solution! So a requirement that specifies something like the following could be used for this purpose: "The DMM (unicast) solution MUST be specified in such a way that it can be extended to also support multicast traffic." Best regards, Georgios _____ Van: <mailto:dmm-boun...@ietf.org> dmm-boun...@ietf.org [dmm-boun...@ietf.org] namens Seil Jeon [seilj...@av.it.pt] Verzonden: vrijdag 16 november 2012 22:25 To: 'Zuniga, Juan Carlos' Cc: <mailto:dmm@ietf.org> dmm@ietf.org Onderwerp: Re: [DMM] Multicast requirements Hi Juan, I've been looked at changed flow of your proposed text but sorry now that my comment is posted. At first time, I couldn't make sure however, on hearing Stig's description, it seems quite reasonable at the first step, not giving any restrictions but leaving some-specific for the DMM solution it does not support multicast. On the other hand, it remains at a basic stage for the DMM solution to support multicast. So I think additional requirements need to be made for the DMM solution, accordingly. But of course, this should not also give any specific limitation and restriction but should be made towards the direction not limiting the benefits provided by distributed deployment. I hope to get more comments on this. Regards, Seil -----Original Message----- From: <mailto:dmm-boun...@ietf.org> dmm-boun...@ietf.org [ <mailto:dmm-boun...@ietf.org> mailto:dmm-boun...@ietf.org] On Behalf Of Zuniga, Juan Carlos Sent: Friday, November 16, 2012 8:14 PM To: Stig Venaas; <mailto:dmm@ietf.org> dmm@ietf.org Subject: Re: [DMM] Multicast requirements > -----Original Message----- > From: Stig Venaas [ <mailto:s...@venaas.com> mailto:s...@venaas.com] > Sent: Friday, November 16, 2012 3:01 PM > To: jouni korhonen > Cc: <mailto:sarik...@ieee.org> sarik...@ieee.org; Zuniga, Juan Carlos; > Konstantinos Pentikousis; > Peter McCann; <mailto:dmm@ietf.org> dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > On 11/15/2012 3:17 AM, jouni korhonen wrote: > > > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote: > > > >> > >> I think we are reading too much into multicast and unicast should be > >> designed in an integrated manner. > >> > >> The fact is that multicast is considered as an area of > specialization, > >> it requires knowledge of very different protocols than we are > >> accustomed to in mobility. > > > > "Requirement: DMM solutions SHOULD support multicast services. If a > specific DMM solution does not support multicast services, an > explanation MUST be provided." > > This sounds good to me. > > The main thing I want to achieve is what was describes as motivation > earlier in this thread. Multicast should at least be considered when > looking into DMM solutions, and not just an afterthought once the > solution is decided. > > Stig [JCZ] I fully agree with this. That was the intention of the proposed text. Regards, Juan Carlos > > > To me that reads basically "do not break foundations for multicast > unless you have a valid & documented reason for it". If we look e.g. > into RFC625 multicast wording that is there very briefly but gives a > hint to a developer where to head to. That is the level I would expect > DMM documents should aim to. > > > > - Jouni > > > > > >> Let dmm deal with its current charter that does not include a word > of > >> multicast and if everything goes well we can come back and discuss > dmm > >> multicast. > >> > >> Regards, > >> > >> Behcet _______________________________________________ dmm mailing list <mailto:dmm@ietf.org> dmm@ietf.org <https://www.ietf.org/mailman/listinfo/dmm> https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list <mailto:dmm@ietf.org> dmm@ietf.org <https://www.ietf.org/mailman/listinfo/dmm> https://www.ietf.org/mailman/listinfo/dmm _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
