Hi Sérgio
> 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].
>[Luis>>] This seems not to be a problem of the IP mobility solutions
handling multicast traffic with mobility tunnels in general, but a problem
of considering several upstream paths ending on the same mobility access
router as a consequence of extending tunnels from previousMAR to newMAR to
forward the multicast traffic.
> [SF] Exactly. Which is more than likely to happen in a DMM solution,
where all "mobility entities" may act as "mobility access routers", and,
after mobility, we want to take advantage of the tunnel for the
subscription. In those cases, care must be taken in order to not greatly
magnify convergence problem observed e.g. in RFC6224.
[Luowen] According to the above discussion, I believe the PS6 is based on
the usage scenarios discussed in
draft-sfigueiredo-multimob-use-case-dmm-03. But, it seems to me the usage
scenarios in this draft is based on a assumed dmm unicast solution and
architecture. IMHO, the PS should be based on current existing protocol
(e.g. RFC) or current deployment, not a assumed solution.
BR
Luowen
Sérgio Figueiredo <[email protected]>
发件人: [email protected]
2012/11/21 07:21
收件人
[email protected]
抄送
主题
Re: [DMM] Multicast PS to requirements
Hi Luis,
A few more comments on this inline:
Em 20-11-2012 19:46, LUIS MIGUEL CONTRERAS MURILLO escreveu:
Hi Anthony,
some comments in line
Best regards,
Luis
De: [email protected] [mailto:[email protected]] En nombre de h chan
Enviado el: martes, 20 de noviembre de 2012 18:51
Para: Sérgio Figueiredo; [email protected]
Asunto: [DMM] Multicast PS to requirements
Let us also use another thread to check for consensus of the PS from
multimob.
PS1 (revised): Non-optimal routes
Routing via a centralized anchor often results in a longer route. The
problem is especially manifested when accessing a local server or servers
of a Content Delivery Network (CDN), or when receiving / sending IP
multicast packets.
[Luis>>] This is correct if the multicast content is locally available.
However this could not be always the case for multicast listeners, for a
number of reasons (for instance, conflict in the multicast address
allocation between the Home Network and the DMM domain).
[SF] Sure, and the same applies to "accessing a local server a CDN" - it
is implicit that the content is locally available. But it can be improved
as "when receiving locally available IP multicast or sending IP
multicast".
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].
[Luis>>] This seems not to be a problem of the IP mobility solutions
handling multicast traffic with mobility tunnels in general, but a problem
of considering several upstream paths ending on the same mobility access
router as a consequence of extending tunnels from previousMAR to newMAR to
forward the multicast traffic.
[SF] Exactly. Which is more than likely to happen in a DMM solution, where
all "mobility entities" may act as "mobility access routers", and, after
mobility, we want to take advantage of the tunnel for the subscription. In
those cases, care must be taken in order to not greatly magnify
convergence problem observed e.g. in RFC6224.
Regards,
Sérgio
H Anthony Chan
From: [email protected] [mailto:[email protected]] On Behalf Of
Sérgio Figueiredo
Sent: Monday, November 19, 2012 5:24 PM
To: [email protected]
Subject: Re: [DMM] Multicast requirements
Hi Anthony,
Thank you for trying to progress on this matter. I mostly agree with your
analysis.
As for the question you posed, first I would like to exactly understand
what you mean with "multicast distribution scenario" in "DMM solutions
should enable multicast services which are compatible with multicast
distribution scenario, etc.". It seems like there is no major difference
between this and the "DMM solutions should enable solutions to support
multicast services." requirement? Aren't both expressing the need to
enable multicast in a DMM solution?
As you stated, "neglecting" the requirement 7.1 we proposed, leads to the
PSs you referred. So, while 7.2 and 7.3 express the need for DMM
solutions to allow deployment of multicast services, 7.1 concerns "how"
IP multicast should be enabled in order to avoid the aforementioned PSs.
The usage of the word "flexible"is explained by:
"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".
In other words, compatibility with "multicast distribution scenario"
doesn't necessarily avoid PS1 and PS6.
Thank you and best regards,
Sérgio
On 11/19/2012 10:28 PM, h chan wrote:
There are 3 proposals for multicast requirements. Before comparing these
proposals, let us understand what are the problems first. Two problem
statements have been proposed:
PS1 (revised): Non-optimal routes
Routing via a centralized anchor often results in a longer route. The
problem is especially manifested when accessing a local server or servers
of a Content Delivery Network (CDN), or when receiving / sending IP
multicast packets.
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].
Then, let us see whether all the 3 REQ proposals have the same intention.
In the following, I rephrase them to highlight their similarities.
REQ7.1: Flexible multicast distribution
DMM solutions should be compatible with flexible multicast distribution
scenario. Etc.
The Motivation is to allow flexibility in (enable) multicast solutions to
solve the problems PS1 and PS6 as explained in use cases already presented
and discussed in multimob wg.
REQ7.2:
DMM solutions should enable solutions to support multicast traffic.
(Original wording was "The DMM (unicast) solution MUST be specified in
such a way that it can be extended to also support multicast traffic." I
rephrase it to highlight the similarity with the other proposals and also
changed the must to should.)
REQ7.3:
DMM solutions should enable solutions to support multicast services.
Original wording was “DMM solutions should support multicast services …
etc. Given that it is the scope of multimob and not dmm wg to provide the
multicast solution, I think “support” here means “enable” solutions to
be developed (by multimob).
Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable
multicast services. Yet the explanation in REQ7.1 seems to indicate not
just to enable any one multicast solution but also needs the flexibility
in multicast solution. Not all multicast solutions are the same. Some of
them results in PS1 or PS6.
Are there any are essential differences between:
In REQ7.1, DMM solutions should be compatible with flexible multicast
distribution scenario, etc.
Versus
DMM solutions should enable multicast services which are compatible with
multicast distribution scenario, etc.
H Anthony Chan
From: [email protected] [mailto:[email protected]] On Behalf Of Seil
Jeon
Sent: Monday, November 19, 2012 5:15 AM
To: [email protected]
Cc: [email protected]
Subject: Re: [DMM] Multicast requirements
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: [email protected] [mailto:[email protected]]
Sent: Monday, November 19, 2012 8:55 AM
To: '[email protected]'; [email protected];
[email protected]
Cc: [email protected]
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 : [email protected] [mailto:[email protected]] De la part de
[email protected]
Envoyé : samedi 17 novembre 2012 13:01
À : [email protected]; [email protected]
Cc : [email protected]
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: [email protected] [[email protected]] namens Seil Jeon [
[email protected]]
Verzonden: vrijdag 16 november 2012 22:25
To: 'Zuniga, Juan Carlos'
Cc: [email protected]
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: [email protected] [mailto:[email protected]] On Behalf Of
Zuniga, Juan Carlos
Sent: Friday, November 16, 2012 8:14 PM
To: Stig Venaas; [email protected]
Subject: Re: [DMM] Multicast requirements
> -----Original Message-----
> From: Stig Venaas [mailto:[email protected]]
> Sent: Friday, November 16, 2012 3:01 PM
> To: jouni korhonen
> Cc: [email protected]; Zuniga, Juan Carlos; Konstantinos Pentikousis;
> Peter McCann; [email protected]
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
nuestra política de envío y recepción de correo electrónico en el enlace
situado más abajo.
This message is intended exclusively for its addressee. We only send and
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.