Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 10 Aug 2005 09:39:46 -0400

> I think whole issue is about the proxying is required at NAR or not.
 > 
 > oDAD says that the address is unique and MN can directly use it.
 > So lets assume that MN sends the FBU with the NCoA. then
 > what is the behaviour of the PAR?
 > 
 > 1) Does it sends the FBack immd to MN and tunnels the packets to NCoA
 > 
 > If it sends the FBack to the MN then MN can do the L2 
 > handoff and get the
 > forwarded packets in the new network.
 > 
 > But here the problem is when the FBack is lost and did not 
 > reached the
 > MN and MN does not go for the L2 Handoff. 

=> I don't understand this statement. You seem to imply 
that the MN will not move because it didn't receive the 
BA. The MN is moving regardless, if it doesn't receive the 
BA it will resend the BU.

  In this case the MN expects
 > that packets get buffered at NAR.So that the there will not 
 > be any packet 
 > loss.

=> The MN doesn't need to expect anything. It just moves and announces
its presence.

 > If the NAR has to do this it need to proxy for the address. 
 > so that the
 > 
 > 2) Does it sends the packet on both the links?

=> Yes you can do that. We had that in early FMIP revisions
and it was removed for no good technical reason.

Hesham

 > 
 > In this there is no need for the packet buffering at NAR as 
 > MN keep on 
 > getting the
 > packets on either of link. But again I am not sure there are any 
 > disadvantages for
 > this scheme (Hope I have not missed any scenario here).
 > 
 > Let me know your view on this.
 > 
 > Regards,
 > 
 > Wable R. U.
 > 
 > ----- Original Message ----- 
 > From: "Subba Reddy" <[email-masked]>
 > To: "Soliman, Hesham" <[email-masked]>; "James Kempf" 
 > <[email-masked]>; "Junghoon Jee" 
 > <[email-masked]>; "Koshiro 
 > MITSUYA" <[email-masked]>; "Alexandru Petrescu" 
 > <[email-masked]>
 > Cc: <[email-masked]>
 > Sent: Wednesday, August 10, 2005 11:31 AM
 > Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into 
 > Mobility Header (FNA)
 > 
 > 
 > > Hi Hesham,
 > >
 > >
 > > You're still assuming collisions for NCoA...The whole
 > > premise of oDAD is that with a decent RNG, there are no
 > > collisions for any practical deployment. It was already
 > > proven in draft-soto that it is more likely that the MN will
 > > be hit by lightning before a collision takes place.
 > >
 > > ---> Ok. If we don't assume collisions, proxying is not required.
 > >
 > > In this case there is no need for HI/Hack.
 > >
 > > ---> If HI/HAck exchange is not there, then it may be 
 > difficult for NAR
 > > to decide which packets to buffer. If HI/HAck exchange is 
 > present, then
 > > NAR can know NCoA's for which it needs to buffer.
 > > Am I missing something?
 > >
 > >
 > > In fact, the current spec does not mandate HI/Hack.
 > >
 > > ---> True. For confirming the address, spec is not mandating.
 > > But it mandates the implementation of HI, HAck.
 > >
 > > Section 3.1, last paragraph,
 > > "
 > > ...
 > >   Finally, the access routers
 > >   could transfer network-resident contexts, such as access control,
 > >   QoS, and header compression, in conjunction with 
 > handover.  For these
 > >   operations, the protocol provides "Handover Initiate (HI)" and
 > >   "Handover Acknowledge (HAck)" messages.  Both of these 
 > messages MUST
 > >   be supported and SHOULD be used.
 > > ..."
 > >
 > > Thanks & Regards,
 > > Subba Reddy
 > >
 > >
 > > _______________________________________________
 > > Mipshop mailing list
 > > [email-masked]
 > > https://www1.ietf.org/mailman/listinfo/mipshop
 > >
 > > 
 > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

From: Ranjitsinh Wable <[email-masked]>
Date: Thu, 11 Aug 2005 11:32:36 +0530

Hi Hesham,

----- Original Message ----- 
From: "Soliman, Hesham" <[email-masked]>
To: "Ranjitsinh Wable" <[email-masked]>; "Subba Reddy" 
<[email-masked]>; "James Kempf" <[email-masked]>; 
"Junghoon Jee" <[email-masked]>; "Koshiro MITSUYA" 
<[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 10, 2005 7:09 PM
Subject: RE: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

--->
I agree that if MN moves to the new link regardless it receive the
BAck but I was talking the case when the MN has not yet moved
to new link. In this case if it receives BAck MN can do the Layer2
handoff and get attached to new link. So that it can recieve the
packets on the new link( which PAR tunnels to NCoA).

=> The MN doesn't need to expect anything. It just moves and announces
its presence.
--->
Phrasing of the sentence may no be correct but I will try to put what
I mean out of it.

This is the case I talked when the MN is send the BU and did not recieved
BAack. MN is still in the old link. He has not yet done the L2 handoff.
As BU is successful the PAR will send the packets to the NCoA. MN will
strat loosing packets. MN may do the BU retransmission in this case.
But packets which are send to the new link will be lost. Again I got your
point that buffering done by ND will be useful here.

But again we need to depend on the ND buffering which may not be enough
to handle this loss if the packet flow is more.

If we do bicasting then we need not to worry about above scenario.
But then it should be mentioned as part of the RFC.

Regards,

Wable R. U.

Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is 
strictly
 prohibited.  If you are not the intended recipient please contact the 
sender
 and delete all copies.
===========================================================