Subject: [Mipshop] New I-D

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 16 Oct 2006 23:10:44 -0700 (PDT)

Dear all,

We submitted an I-D on 
FMIPv6 extension for Multicast Handover
which is now available at:
http://www.ietf.org/internet-drafts/draft-xia-mipshop-fmip-multicast-00.txt

Comments welcome.

--behcet

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "Osvaldo Gonsa" <[email-masked]>
Date: Wed, 18 Oct 2006 18:16:23 +0200

Behcet,
I have read your draft with interest and I have the following questions,

on section 3 first paragraph you wrote as the scenario that you
consider: "In Multicast Fast Handover (MFH), the mobile node joins
multicast groups such as IPTV sessions using its care-of address (CoA).
MLD state consisting of the multicast group address and addresses of
each sender resulting from MN's multicast communication is kept in AR."
although I see the necessity of the AR to keep this amount of state for
your defined procedure, I am wondering about the applicability to IPTV
sessions as they are envisioned right now by operators (because I
assumed you mean Mobile IPTV), since the current trend is probably to
have more of statically configured service areas with session starts and
stops announced and the interested mobile nodes join at will, this would
make un-necessary that the AR keeps that state.

on section 3.1 the step 6 says: "When multicast delivery trees are
constructed, the PAR stops delivering multicast traffic to MN while the
NAR delivers multicast traffic directly"  I am wondering how the PAR
knows when the NAR has already constructed the multicast tree so the PAR
can stop forwarding multicast data. This is because I think the HAck
would not tell the PAR anything about the multicast but rather that the
network layer handover has ended but the multicast tree may still not be
finished depending on the "size" of the tree (number of hops). Or would
you require that the NAR waits until the tree is finalised to send the
HAck, if so I wonder if this will not affect unicast streams.

Finally, I was also wondering if the MN should send a state change
report to its previous PAR? it is not depicted on the figures... 

regards

Osvaldo

>-----Original Message-----
>From: Behcet Sarikaya [mailto:[email-masked]] 
>Sent: Dienstag, 17. Oktober 2006 08:11
>To: [email-masked]
>Subject: [Mipshop] New I-D
>
>Dear all,
>
>We submitted an I-D on 
>