Re: [Mobopts] Re: [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt

["James Kempf" <[e-mail]>]

> > I quickly read your Internet draft with interest and would like to
> > know if you will intend to discuss it on the mobopts mail list?
> >
> > I have been working on multicast to mobiles for some time and would
> > be happy to exchange ideas.
> >
Actually, we've found it the case of FMIPv4 on 802.11 that the performance
for reactive handover is perfectly adequate. There is some slight additional
delay and one loses packets during the L2 handover (if the proprietary
buffer fowarding at the AP is turned off) but other than that, it works
fine. Unfortuantely, I can't send the paper out because it is under
consideration for publication. We haven't specifically looked at multicast,
but I can't see how it could be a problem. The multicast traffic will get
forwarded through the tunnel until the mobile node does MLD for the group
with the new router, at which point the routing change will propagate. There
is of course an issue with the route propagating, and, in that sense, HMIP
might be better if the multicast routing tree is rooted in the MAP.

            jak


> >
> > Here are some early thoughts on your document:
> >
> > The problem and solution seem to do a good job for multicast
> > receivers.
> >
> A matter of debate could be, wether FMIPv6 is a well suited fundament
> for multicast distribution. FMIP must be eager to anticipate handovers
> (if it will work well), thus exhibiting a significant likelyhood of
> wrong predictions.
>
> In the multicast case this will lead to an unwanted quantity of uneeded
> remote subscriptions, unneccessary branches in the multicast trees ...
>
> ... from our point of view the smoother hmipv6 MAP architecture is much
> more appropriate as multicast agents ...
>
> > How does the PAR learn of the NAR address? (In the sense that: Is
> > there something that would be in scope for Multicast Fast Handover,
> > that's different from unicast/existing fast handover?)
> >
>
> If we understand correctly: This is just taken from FMIPv6's prediction.
>   There should be nothing exclusive to multicast.
>
> > Some discussion on IGMP/MLD-snooping and the role of access points as
> > switches could be appropriate too - to deal with the situation where
> > AP changes but AR does not.
>
> Mhmm, this might be more a concern of underlying L2 specification. The
> FMIPv6 approach leaves L2 specs to additional documents.
> >
> > Also, there are several security risks. Of particular trouble are the
> > DoS possibilities of setting up state in many "NARs" by a
> > broken/malicious "MN", and sending to multiple ARs malicious
> > multicast data (e.g. to destroy usability of the "expected service").
> > SSM is worth mentioning and also access control. As far as I am
> > certain there are 2 ongoing activities on multicast (AR) access
> > control: MCOP, IGAP. And I think there's a 3rd in MAGMA - so no need
> > to address the whole access control solution, just explain the impact
> > and use for this fast multicast handover. (I guess you already have
> > these ideas for the 01 draft :)
> >
> > Tunnelling multicast from PAR to NAR is not so scalable, this should
> > be mentioned. Perhaps suggest a means to time-out these tunnels so
> > that the tunnelling is only transitory since using the "PAR" as the
> > tunnel other-end point reduces scalability of that AR.
> >
> Tunneling in this approach only occurs, if NAR refuses to subscribe to
> the wanted multicast group ... question is: when will this happen? On
> which bases would a NAR decide not to support a specific group?
>
> Cheers,
>
> Thomas & Matthias
>
>
> <more of the previous mails to come for mobopts folks:>
>
> > The differentiation between receiver-only, sender-only and
> > reciever+sender MNs would be a good discussion item too. For
> > instance, I think your solution is great for receivers, but for
> > senders (especially send-only non-group-members) it does not solve
> > the problem. Perhaps this is just an issue of limiting the scope to
> > receiver mobility. Maybe it is currently helping readability to not
> > cover sender mobility in this draft, so one option is to consider
> > these aspects in a separate draft - at the same time or a later
> > stage.
> >
> > Also, one small NIT: please make it explicit which references are
> > normative (essential) and which are informative (I guess all 4 are
> > normative)?
> >
> > Have you had any earlier feedback or discussion on the MIPSHOP (or
> > other WG) email lists?
> >
> >
> > Cheers, Rod.
> >
> >
> >
> > -----Original Message----- From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of ext Kyungjoo Suh Sent:
> > Wednesday, March 03, 2004 3:05 PM To: [e-mail] ; ??? Subject:
> > [Mip6] NEW ID ACTION:draft-suh-mipshop-fmcast-mip6-00.txt
> >
> >
> > Hi,
> >
> > New draft is available which is Fast multicast protocol.
> >
> > This document defines the Fast Multicast Protocol for Mobile IPv6 [2]
> > in the Fast Handovers environments whereby a mobile node (MN) can
> > receive multicast data with reduced loss and delay after handoffs.
> >
> > Please refer to following document.
> >
> > sincerely, Kyungjoo Suh (Joo)
> >
> >
> >
> >
============================================================================
=======================
> >
> >
> > I-D ACTION:draft-suh-mipshop-fmcast-mip6-00.txt
> >
>
> --------------------------------------------------------------------------
------
> >
> >
> > To: IETF-Announce: ; Subject: I-D
> > ACTION:draft-suh-mipshop-fmcast-mip6-00.txt From: Internet-Drafts at
> > ietf.org Date: Fri, 06 Feb 2004 15:41:59 -0500 Reply-to:
> > Internet-Drafts at ietf.org Sender: owner-ietf-announce at ietf.org
> >
>
> --------------------------------------------------------------------------
------
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > Title : Fast Multicast Protocol for Mobile IPv6 Author(s) : K. Suh
> > Filename : draft-suh-mipshop-fmcast-mip6-00.txt Pages : 13 Date :
> > 2004-2-6  This document defines the Fast Multicast Protocol for
> > Mobile IPv6 [2] in the Fast Handovers environments whereby a mobile
> > node (MN) can receive multicast data with reduced loss and delay
> > after handoffs. The proposed protocol can be implemented by the
> > simple modification of the Fast Handovers protocol [1] so that it can
> > be easily applied to the Fast Handovers for Mobile IPv6. This
> > document does not need a certain assumption of a specific multicast
> > routing protocol, so that any existing multicast routing protocol can
> > be used with the proposed protocol.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt
> >
> >
> > To remove yourself from the IETF Announcement list, send a message to
> >  ietf-announce-request with the word unsubscribe in the body of the
> > message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username "anonymous" and a password of your e-mail address. After
> > logging in, type "cd internet-drafts" and then "get
> > draft-suh-mipshop-fmcast-mip6-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html or
> > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to: [e-mail]. In the body type: "FILE
> > /internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt".  NOTE: The
> > mail server at ietf.org can return the document in MIME-encoded form
> > by using the "mpack" utility.  To use this feature, insert the
> > command "ENCODING mime" before the "FILE" command.  To decode the
> > response(s), you will need "munpack" or a MIME-compliant mail reader.
> > Different MIME-compliant mail readers exhibit different behavior,
> > especially when dealing with "multipart" MIME messages (i.e.
> > documents which have been split up into multiple messages), so check
> > your local documentation on how to manipulate these messages.   Below
> > is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
<ftp://ftp.ietf.org/internet-drafts/draft-suh-mipshop-fmcast-mip6-00.txt>
> >
> >
> >
> > _______________________________________________ Mip6 mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/mip6
> >
> > _______________________________________________ Mip6 mailing list
> > [e-mail] https://www.ietf.org/mailman/listinfo/mip6
> >
>
> _______________________________________________
> Mobopts mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/mobopts
>


_______________________________________________
Mobopts mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mobopts