Subject: [Mipshop] Questions and remarks concerning the FMIPv6 draft

From: Martin André <[email-masked]>
Date: Wed, 12 Jan 2005 10:36:44 +0100

Dear all,

We are working at the Louis Pasteur University on an FMIPv6 
implementation for Linux and we have a few questions and remarks 
concerning the FMIPv6 draft:

* Our first remark is about the NAR sending an HAck message upon receipt 
of an HI message with code value of 1. Part 4 makes it pretty unclear, 
while part 6.2.2 clears the doubt.

 From part 4:

    ...
     4. provides the status of handover request in Handover Acknowledge
        (HAck) message.

    When the Code value in HI is 1, NAR MUST skip the above operations
    ...

 From part 6.2.2:

    The Handover Acknowledgment message is a new ICMPv6 message that MUST
    be sent (typically by NAR to PAR) as a reply to the Handover Initiate
    message.
    ...
    When responding to a HI message containing a Code value 1, the Code
    values 1, 2, and 4 in the HAck message are not relevant.
    ...

* There is no indication on how long one should wait before resending an 
FBU message. Is it left to implementor's appreciation? Do we have to 
adopt the same behavior as the one for RtSolPr messages?

* FMIPv6 draft doesn't specify how to deal with the case in which 
HI_RETRIES retransmission of HI message is reached. Must PAR assume that 
NAR does not support fast handover and send apropriate FBack message to MN?

* The last point concerns Experimental Mobility Protocol Type. It 
doesn't rely directly on FMIPv6 draft, but someone on this list may have 
the response. Is it defined yet? Where can we find it? A BSD FMIPv6 
implementation has set it to 154, but we couldn't find any trace of it.

Thank you for your clarification.
Martin

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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 12 Jan 2005 11:01:48 -0800

Hello Martin,

Martin Andri wrote:

>
> * Our first remark is about the NAR sending an HAck message upon 
> receipt of an HI message with code value of 1. Part 4 makes it pretty 
> unclear, while part 6.2.2 clears the doubt.
>
> From part 4:
>
>    ...
What would like to see? I didn't get your point.

> * There is no indication on how long one should wait before resending 
> an FBU message. Is it left to implementor's appreciation? Do we have 
> to adopt the same behavior as the one for RtSolPr messages?
>
The FBU Retransmit timer is "assumed" to be derived from the BU 
Retransmit timer. This should be made clear in the draft. In addition, 
an FBU is resent as soon as a new link connectivity is established if no 
FBack has been received. It is not clear to me what the exact timer 
value should be since staying on the previous link 100+ ms after sending 
the FBU is perhaps not optimal, _and_ an FBU is resent anyway 
immediately after the new subnet attachment. If your experiments yield a 
better answer, I would be glad to hear from you.

> HI_RETRIES retransmission of HI message is reached. Must PAR assume 
> that NAR does not support fast handover and send apropriate FBack 
> message to MN?
>
Failure to receive a HAck even after HI_RETRIES is not a deinitive 
indicatior of NAR's inability to support fast handover. For instance, if 
PAR has received a HAck in the past but is not able to receive one 
later, then perhaps an FBack with "Insufficient Resources" is more apt. 
Otherwise, you could use the lack of response to HI as an indication of 
inability to support fast handover. In any case, sending an FBack is a 
good idea.

> doesn't rely directly on FMIPv6 draft, but someone on this list may 
> have the response. Is it defined yet? Where can we find it? A BSD 
> FMIPv6 implementation has set it to 154, but we couldn't find any 
> trace of it.
>
I don't think the EXP Type has been defined by IANA yet. Which BSD 
implementation are you referring to ?

Thanks,

-Rajeev

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 12 Jan 2005 11:52:07 -0800

> implementation has set it to 154, but we couldn't find any trace of it.

just pick a value for now between 138-252 (thats what the BSD 
implementation has done). you have to wait for IANA assignments.
http://www.iana.org/assignments/protocol-numbers

Vijay

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Jan 2005 14:23:54 -0800

The Seamoby IANA document, where the Experimental Mobility Type is
allocated, has yet to make it off the RFC Editor Queue. I spoke with
Michelle Cotton of IANA about this last fall, so I don't understand what the
holdup is (though it looks to me like it may be a circular dependency in the
references). I sent email to the RFC Editor asking what the problem is.

Sorry about the delay.

            jak

---

From: Martin André <[email-masked]>
Date: Thu, 13 Jan 2005 14:28:23 +0100

Hello Rajeev,

Thanks for your prompt reply. Comments inline.

> What would like to see? I didn't get your point.

No big deal really. It's just that when I first read the draft I 
understood that part the following way:

if HI.code == 0 then do points 1, 2, 3, 4

else if HI.code == 1 then don't do 1,2,3,4

the trouble is that one might easily read point 4 the following way:

     4. Send an HAck with the status of the handover request

and hence "don't do 4" might be understood as:

     Don't send an HAck with the status of the handover request (or in 
other words - don't send an HAck at all)

The following would probably clear the doubt

     4. provides the status of handover request in the Handover 
Acknowledge (HAck) triggered by the HI message.

Again, no big deal. It's just that I was a bit confused when I first 
read it.

> better answer, I would be glad to hear from you.

We should have results by the end of march.

> implementation are you referring to ?

The Tarzan implementation developed at Keio University, Japan.

Thanks again
Martin