Subject: RE: [Mipshop] New I-D

From: xiayangsong 24512 <[email-masked]>
Date: Thu, 19 Oct 2006 11:33:32 +0800

Hi Osvaldo
  
    Welcome your comments.
 
    Please see the in-line reply

BR
Frank

----- 原邮件 -----
发件人: Osvaldo Gonsa <[email-masked]>
日期: 星期四, 十月 19日, 2006 上午0:16
主题: RE: [Mipshop] New I-D

> 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 
> wouldmake un-necessary that the AR keeps that state.

 Sure,some current practice is statically configured service.
 As the IPTV bandwith increasing (such as HDTV), and programs 
 increasing,the practice will not cost-efficient.
 Anyway, I think that static configuration does not fit for wide-
 scope deployment.

> 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.

 Probably, in some time, MN would have two copies of a packet, 
 but I dont think it is obvious harmful to upper layer.

> 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 
> wouldyou 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.

 Just as unicast tunnel maitenance. We can use the lifetime field 
 of FBU to age the tunnel.  
 Some active alternative can be designed, such as
 HAck convey the lifetime of the multicast tunnel. 
 Even a dedicated message can be designed to 
 notify the PAR to destroy the unicast/multicast tunnel.
 We can discuss.

> 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... 

 not mandatory.
 If the MN is not the last multicast member, it's leaving has not 
 any affect to the router.
 Otherwise, MLDv2 has mechanism to age multicast members.

> regards
> 
> Osvaldo
> 
> 
> 
> 
> >-----Original Message-----
> >From: Behcet Sarikaya [[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 
> >
> >FMIPv6 extension for Multicast Handover
> >which is now available at:
> >http://www.ietf.org/internet-drafts/draft-xia-mipshop-fmip-mult
> >icast-00.txt
> >
> >Comments welcome.
> >
> >--behcet
> >
> >
> 
> 

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