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

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 10 Aug 2005 01:47:42 -0400

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. 
In this case there is no need for HI/Hack. In fact, the 
current spec does not mandate HI/Hack.

Hesham

 > -----Original Message-----
 > From: Subba Reddy [mailto:[email-masked]]
 > Sent: Wednesday, August 10, 2005 1:15 AM
 > To: Soliman, Hesham; James Kempf; Junghoon Jee; Koshiro MITSUYA;
 > Alexandru Petrescu
 > Cc: [email-masked]
 > Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into 
 > Mobility Header
 > (FNA)
 > 
 > 
 > Hi Hesham,
 > 
 >  > => I don't think so. The MN can form its CoA before it move
 >  > (predictive) or after (reactive). In either case the CoA
 >  > would be defended with oDAD. I don't see where the difference
 >  > is.
 >  > 
 >  > ----> I am mentioning about the predictive case as specified 
 >  > in FMIPv6 RFC.
 >  > If we want to send FBU in PAR's link, then proxying may be 
 >  > still required.
 >  > I think, oDAD is more useful in reactive handoffs.
 > 
 > => It might be better if you explain why you think oDAD
 > will not work in this case. It's not clear how you came 
 > to that conclusion.
 > 
 > ---->Sorry for not being clear. 
 > In predictive case,
 > If MN anticipates handoff, MN will send FBU to PAR with 
 > prospective NCoA when MN is still connected to PAR's link.
 > PAR will send HI with NCoA. NAR will verify NCoA.
 > If NCoA is already in use, NAR may assign new CoA.
 > NAR will send HAck to PAR. 
 > 
 > If NAR specifies address in HAck,
 > (i.e, either accepted the NCoA in HI or proposed new CoA), NAR
 > needs to do proxy for NCoA, till MN comes to NAR's link (so that
 > nodes in the NAR link will not configure during handoff of MN).
 > PAR will send FBack.
 > 
 > So, I think,  oDAD may not come into picture in predictive case.
 > 
 > Thanks & Regards,
 > Subba Reddy
 > 

===========================================================
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: Subba Reddy <[email-masked]>
Date: Wed, 10 Aug 2005 11:31:10 +0530

Hi Hesham,

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

---

From: Ranjitsinh Wable <[email-masked]>
Date: Wed, 10 Aug 2005 12:25:37 +0530

Hi Hesham,

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. In this case the MN expects
that packets get buffered at NAR.So that the there will not be any packet 
loss.
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?

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)

---

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Aug 2005 08:17:50 -0700

Most implementations of IPv6 routers have a buffer of a few packets to allow
a node to finish address configuration. I think what Hesham is proposing is
to drop HI/HAck and use an extension of that buffer. The length might be
made configurable so that the network operator could allow slightly more
packets to be buffered depending on deployment circumstance.

            jak

----- Original Message -----
From: "Subba Reddy" <[email-masked]>
To: "Soliman, Hesham" <[email-masked]>; "James Kempf"
Sent: Tuesday, August 09, 2005 11:01 PM

---

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Aug 2005 08:22:49 -0700

> If the NAR has to do this it need to proxy for the address. so that the

FMIP is an optimization, it isn't required. If the FBack is lost, the MN can
simply fall back to standard MIP6 handover. I think it makes more sense to
simplify the protocol if we can.

> this scheme (Hope I have not missed any scenario here).

I can't follow this.

        jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Aug 2005 18:18:56 +0200

> simplify the protocol if we can.

Let me follow up on this particular issue ("simplify the protocol...").

In one sense - yes, I believe it should be simplified, at least in order
to be easier to grasp by a programmer.

Paradoxically, the strange thing about it is that the protocol as
described depends on at least three other potential protocols that are
not described anywhere:

-how do the ARs learn about each other's AR-Info.
-how do the ARs learn their APs' "AP-ID"s, when AP and AR are disjoint.
-what's "assigned addressing" that NAR uses to assign addresses.

Also, the protocol relies a lot on variable-length link-layer addresses.
 That's ok but it means it won't work with 0-length link-layer
addresses, like point-to-point ppp and successors.  Which is fine, but
should probably be noted somewhere.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Wed, 10 Aug 2005 13:02:13 -0700

> -what's "assigned addressing" that NAR uses to assign addresses.

None of this is necessary with reactive handover. The MN learns about the
NAR's link address and subnet information from a (solicted or unsolicited)
RA after it is up on the new link, constructs an address, sends FBU back to
the PAR with NAR's address for forwarding. The RtSolPrxy and PrxyRtAdv
aren't necessary.

For predictive handover, the MN has to know the NAR's address before it
moves, and also subnet information, which is where these messages come in.
But it isn't necessary to use predictive handover (and not possible for some
link types).

> should probably be noted somewhere.

I don't think anyone has made a serious study of how FMIP would be used by
PPP, so it would probably be worthwhile to do so.

            jak

---

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

Hi Jak,

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

> simplify the protocol if we can.
There is mechanism in the FMIPv6 to deal with the problem of lost FBack.
But my concern was about the packet loss. The case which occurs when
we don't do the FBack is lost and the MN is not done L2 handover and
no proxying and buffering is done at NAR.

>> this scheme (Hope I have not missed any scenario here).
I was talking about the bicasting here.

Regards,

Wable R. U.

---

From: Greg Daley <[email-masked]>
Date: Thu, 11 Aug 2005 16:32:45 +1000

Hi Wable,

[cut]
> I was talking about the bicasting here.

Let's be careful with bicasting, as the primary
algorithm for handling spurious duplicate Acks - common in
bicasting (the Eifel Algorithm) is being moved out of the
"Recommended to Implement" TCP algorithms by the TCPM WG.

This is apparently due to the presentation of a schedule of
licensing fees from an IPR holder to an implementor of
the algorithm.

Greg

---

From: Ranjitsinh Wable <[email-masked]>
Date: Thu, 11 Aug 2005 13:19:34 +0530

Hi Greg,

Thanks for the information. It will be good for us to think over it while
discussing any solution which relies on the bicasting.

Also I remember, few days back there was a dicussion on mailing list over
the issue that in TCP connection, the packet loss is prefered over the
duplicate packets. So we should be careful about it.

Thanks and Regards,

Wable R. U.

----- Original Message ----- 
From: "Greg Daley" <[email-masked]>
To: "Ranjitsinh Wable" <[email-masked]>
Cc: "James Kempf" <[email-masked]>; "Subba Reddy" 
<[email-masked]>; "Soliman, Hesham" <[email-masked]>; 
"Junghoon Jee" <[email-masked]>; "Koshiro MITSUYA" 
<[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>; <[email-masked]>
Sent: Thursday, August 11, 2005 12:02 PM
Subject: Re: [Mipshop] FMIPv6 - Encapsulating FBU into Mobility Header (FNA)

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Aug 2005 15:16:19 +0200

> the PAR with NAR's address for forwarding. The RtSolPrxy and PrxyRtAdv

The "reactive" handover as described above seems simple to understand
for me.  If it only uses FBU/FBack and oDAD and does not employ HI/HAck
nor RtSolPrxy/PrxyRtAdv then it may even happen independently of Mobile
IPv6.

> But it isn't necessary to use predictive handover (and not possible for some

The document is very ambiguous about the necessity of either predictive
or reactive.  I think many features are there as MUST and SHOULD.

> PPP, so it would probably be worthwhile to do so.

For point-to-point connections (ppp-like is used on GPRS) there are no
link-layer addresses nor headers.  I don't think FMIPv6 could be used on
an IPv6-enabled GPRS (other than maybe the FBU/FBack exchanges).

Otherwise,

I think FMIP unnecessarily uses variable-length link-layer addresses.
It should use fixed-length link-layer addresses.

What other than 48-bit-length link-layer addresses are known and used in
the mobility space?  None.

What other than 48-bit-length address link-layer runs under a known IPv6
implementation, that is relevant in the mobility space.  None.

Alex

---

From: "James Kempf" <[email-masked]>
Date: Thu, 11 Aug 2005 08:26:12 -0700

> or reactive.  I think many features are there as MUST and SHOULD.

The reason is that whether or not reactive or predictive should be used is
tightly tied to what support is available at the link layer. But I agree
that it might be useful to clean this up in the bis version.

> implementation, that is relevant in the mobility space.  None.

What about using a TIMSI on GPRS?

In general, I don't think that one can definitively say that the address
with be 48 bits. There is EUI-64 (64 bit link addresses) for example. Also,
a link layer may come along that has a different type address. The IP layer
is supposed to be an abstraction above the link layer.

            jak

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 11 Aug 2005 18:20:10 +0200

James Kempf wrote:

>> The document is very ambiguous about the necessity of either 
>> predictive or reactive.  I think many features are there as MUST 
>> and SHOULD.
>> 
> 
> 
> The reason is that whether or not reactive or predictive should be 
> used is tightly tied to what support is available at the link layer. 
> But I agree that it might be useful to clean this up in the bis 
> version.
> 
> 
> 
>>>> Also, the protocol relies a lot on variable-length link-layer 
>>>> addresses. That's ok but it means it won't work with 0-length 
>>>> link-layer addresses, like point-to-point ppp and successors. 
>>>> Which is fine, but should probably be noted somewhere.
>>>> 
>>> 
>>> I don't think anyone has made a serious study of how FMIP would 
>>> be used
> 
> by
> 
>> For point-to-point connections (ppp-like is used on GPRS) there are
>>  no link-layer addresses nor headers.  I don't think FMIPv6 could
>> be used on an IPv6-enabled GPRS (other than maybe the FBU/FBack 
>> exchanges).
>> 
>> Otherwise,
>> 
>> I think FMIP unnecessarily uses variable-length link-layer 
>> addresses. It should use fixed-length link-layer addresses.
>> 
>> What other than 48-bit-length link-layer addresses are known and 
>> used in the mobility space?  None.
>> 
>> What other than 48-bit-length address link-layer runs under a known
>>  IPv6 implementation, that is relevant in the mobility space.
>> None.
>> 
>> 
> 

GPRS uses ppp (and family) for IP connectivity (regardless of TIMSI
being used or not).  With point-to-point links there's no Neighbour
Discovery.  With ppp there is no proxy-NA, no Router Advertisements.  So
many features of FMIPv6 can't work with ppp nor GPRS, regardless of
TIMSI addresses.

> In general, I don't think that one can definitively say that the 
> address with be 48 bits. There is EUI-64 (64 bit link addresses) for 
> example. Also, a link layer may come along that has a different type 
> address. The IP layer is supposed to be an abstraction above the link
>  layer.

>From what I see, many new IEEE protocols try to have 48-bit
addresses (802.stuff, LAN, PAN).  RFCs for IPv6-over-stuff use 48-bit
mainly.

A new link-layer that may come along and that is relevant to the
mobility space (so that fast mobility is needed) will definitely be
wireless, and there are already many WLAN/WPAN/WWAN proposals that have
48-bit addresses.

If that happens (49-bit foo link-layers, IEEE-Extended) then
FMIPv6-over-foo-49bit may de designed.

Variable-length addresses are so difficult to tackle (encoding and
programming-wise) that it may be better to define additional fixed
lengths when new ones appear.  If one thinks TIMSI is needed, then have
a TIMSILLA fixed length 50bits option and a MACLLA fixed-length-48bit.

Just some thoughts...

Alex

---

From: Greg Daley <[email-masked]>
Date: Fri, 12 Aug 2005 10:09:15 +1000

Hi Wable,

> duplicate packets. So we should be careful about it.

It depends what you mean...

Sometimes packet loss is OK (and can be repaired in a few RTTs (1
segment per RTT in newreno)).  Sometimes the holes are so big
that losses will lead to 3 duplicate acks anyway (correctly).

I guess FMIPv6 is trying to make the holes small enough to patch
quickly using SACK or newreno.  Ultimately, if things are done
correctly, and the buffers are sized right, there should be no
holes.

I think this is doable if prediction is available, even without
bicasting.

Greg