Subject: RE: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?

From: "GAABAB Brahim RD-CORE-CAE" <[email-masked]>
Date: Mon, 12 Sep 2005 15:48:49 +0200

> De : Alexandru Petrescu
> Envoyé : vendredi 9 septembre 2005 16:40
> À : GAABAB Brahim RD-CORE-CAE
> Cc : Alexandru Petrescu; [email-masked]
> Objet : Re: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?
> 
> GAABAB Brahim RD-CORE-CAE wrote:
> 
> >> This is ambiguous and may be critical.  A tunnel endpoint on PAR 
> >> should precisely specify which is the other tunnel 
> endpoint.  If it  
> >> specifies NCoA as other tunnel endpoint then it will 
> forward packets 
> >> to NCoA and only the MN receiving it can decapsulate it, 
> NAR will not 
> >> decapsulate that packet because the destination address of that 
> >> packet is not any of the NAR's addresses (NAR will try to just 
> >> forward, not decapsulate).
> > 
> > 
> > Basically, FMIPv6 relies on one tunnel pAR == nCoA that is 
> a result of 
> > FBU/FBAck exchange. In the case when no nCoA can be 
> assigned to the MN 
> > (the MN continue usign its pCoA even on the nAR link), FMIPv6 uses 
> > another tunnel pAR == nAR (combined with the host route) 
> till the MN 
> > finishes configuring a nCoA.
> 
> Ok, I understand, thanks. Host-route on NAR to PCoA in 
> combination with tunnel PAR-NAR (instead of tunnel PAR-NCoA) 
> is used when no NCoA can be assigned by NAR or pre-cofingured by MN.
> 
> Still, it is not clear from the document when are the tunnel 
> endpoints created at PAR, NAR and MN.  And it is not clear 
> from the document when are the host-routes at NAR deleted.

Actions relating to nAR are defined in top of page 13, bullet 3: creation of host route and endpoint for the tunnel pAR-nAR. However, I cannot see where the endpoint for tunnel pAR-nAR is created at pAR. Noramally, after receiving a HAck indicating that no address can be assigned to MN neither proposed address is valid. 

> It is not clear from the document that the tunnel destination 
> for PAR's tunnel endpoint can be either NAR's address or 
> NCoA's address.
> 

There is no information about this in the spec !

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

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 14 Sep 2005 11:20:12 -0700

Folks,

> There is no information about this in the spec !

Page 11, in the paragraph beginning with "After a PrRtAdv.."

"In response to the
    FBU, the PAR establishes a binding between PCoA ("Home Address") and
    NCoA, and sends the FBack to the MN.  Prior to establishing this
    binding, PAR SHOULD send an HI message to NAR, and receive HAck in
    response."

This is for PAR - NCoA tunnel.

The PAR - NAR tunnel is also established in the same way depending on
the HI/HAck exchange. I guess we need to add a specific code value to
indicate host route support for PCoA and tunnel end-point being NAR.
Some context: the implicit assumption has been that support for PCoA on 
NAR should be a rare case.

Thanks,

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Wed, 14 Sep 2005 12:44:15 -0700

Rajeev,

Is there any reason why we couldn't simplify the protocol by getting rid of 
either the PAR-NAR tunnel or the PAR-NCoA tunnel?

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: "GAABAB Brahim RD-CORE-CAE" <[email-masked]>
Cc: <[email-masked]>; "Alexandru Petrescu" 
<[email-masked]>
Sent: Wednesday, September 14, 2005 11:20 AM
Subject: Re: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?

>>>It is not clear from the document that the tunnel destination for PAR's 
>>>tunnel endpoint can be either NAR's address or NCoA's address.
>>>
>>
>>

---

From: Rajeev Koodli <[email-masked]>
Date: Wed, 14 Sep 2005 16:57:34 -0700

Hi Jim,

the PAR - NCoA is the default, normal, _predominant_ mode of operation, 
and is required.

PAR - NAR tunnel is the fallback case when NCoA is not supported by NAR 
for whatever reason. This feature is a MAY. Sorry if this was not clear 
from my previous message.

-Rajeev

James Kempf wrote:
> Rajeev,
> 
> Is there any reason why we couldn't simplify the protocol by getting rid 
> of either the PAR-NAR tunnel or the PAR-NCoA tunnel?
> 
>            jak
> 
> ----- Original Message ----- From: "Rajeev Koodli" <[email-masked]>
>>>> It is not clear from the document that the tunnel destination for 
>>>> PAR's tunnel endpoint can be either NAR's address or NCoA's address.
>>>>
>>>
>>>
>> Some context: the implicit assumption has been that support for PCoA 
>> on NAR should be a rare case.
>>
>> Thanks,
>>
>> -Rajeev
>>
>>

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Sep 2005 10:17:08 -0700

> the PAR - NCoA is the default, normal, _predominant_ mode of operation,

Yes, this is necessary.

> from my previous message.

Why is this needed?

Here's the cases;

predictive handover, address autoconfigured - If the address proposed from 
the old link is rejected, the MN fails over to reactive handover and uses 
oDAD on the new link to get a new one, sends another FBU from the new link. 
PAR waits for that one before initiating tunneling.

predictive handover, DHCP - no issue. The address is assigned by the new 
link.

reactive handover, address autoconfigured - The host uses oDAD on the new 
link, fails over to a new address if oDAD fails, but still gets its tunneled 
packets.

reactive handover, DHCP - no issue. The address is assigned by the new link.

I think we could simplify the protocol be removing this.

             jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 15 Sep 2005 12:36:23 -0700

James Kempf wrote:

>> PAR - NAR tunnel is the fallback case when NCoA is not supported by 
>> NAR for whatever reason. This feature is a MAY. Sorry if this was not 
>> clear from my previous message.
>> 
> Why is this needed?

It's there as an option.

> 
> Here's the cases;
> 
> predictive handover, address autoconfigured - If the address proposed 
> from the old link is rejected, the MN fails over to reactive handover 
> and uses oDAD on the new link to get a new one, sends another FBU from 
> the new link. PAR waits for that one before initiating tunneling.
> 

However, the MN would not know that proposed NCoA is rejected if it 
leaves without receiving FBack. So, it sends FNA and NAR informs that 
NCoA is not to be used. With tunnel support between PAR - NAR, packets 
can be forwarded right after processing FNA. There is no need to 
configure another NCoA, send FBU and wait for packets to arrive.
In other words, it is still predictive mode.

-Rajeev

> reactive handover, address autoconfigured - The host uses oDAD on the 
> new link, fails over to a new address if oDAD fails, but still gets its 
> tunneled packets.
>

---

From: "James Kempf" <[email-masked]>
Date: Thu, 15 Sep 2005 16:18:20 -0700

>> from the old link is rejected, the MN fails over to reactive handover and 
>> uses oDAD on the new link to get a new one, sends another FBU from the 
>> new link. PAR waits for that one before initiating tunneling.
>>
>
> However, the MN would not know that proposed NCoA is rejected if it leaves 
> without receiving FBack. So, it sends FNA and NAR informs that NCoA is not 
> to be used. With tunnel support between PAR - NAR, packets can be 
> forwarded right after processing FNA. There is no need to configure 
> another NCoA, send FBU and wait for packets to arrive.

Assume that we are bicasting the FBack to PAR and NAR, as per the draft. 
Then either:

1) The MN gets the FBack on the PAR, in which case it can take the action 
above.

2) The MN gets the FBack on the NAR as the first packet when it arrives on 
the link, in which case the MN can take the action above.

3) The MN doesn't get an FBack, presumably because the queue timed out on 
NAR. This is an error case, and the MN can either choose to do reactive 
handover signaling, i.e. send another FBU because the first got lost (or the 
FBAck did), or it can just give up and continue with MIP6 handover, leaving 
the packets drop.

        jak

---

From: Rajeev Koodli <[email-masked]>
Date: Thu, 15 Sep 2005 19:18:38 -0700

James Kempf wrote:
> 1) The MN gets the FBack on the PAR, in which case it can take the 
> action above.

Okay. In this case (according to the current spec), the MN knows that 
PAR - NAR tunnel is set up already. So, all it has to do is to announce 
itself to the NAR and receive packets. And, send packets using PCoA.
In essence, predictive handover.

> 
> 2) The MN gets the FBack on the NAR as the first packet when it arrives 
> on the link, in which case the MN can take the action above.
> 

Before the MN receives FBack, it would have sent FNA to which the NAR 
would respond NAACK. In any event, the tunnel is already set up (hence 
FBack is waiting in the queue).

So, when PAR - NCoA tunnel fails (very rarely I would think), PAR - NAR 
tunnel is already set up providing the predictive handover features when 
the MN shows up on NAR's link.

-Rajeev

> 3) The MN doesn't get an FBack, presumably because the queue timed out 
> on NAR. This is an error case, and the MN can either choose to do 
> reactive handover signaling, i.e. send another FBU because the first got 
> lost (or the FBAck did), or it can just give up and continue with MIP6 
> handover, leaving the packets drop.
> 
>        jak
> 
>

---

From: "James Kempf" <[email-masked]>
Date: Fri, 16 Sep 2005 08:31:43 -0700

> In essence, predictive handover.

If the proposed CoA was accepted, then the tunnel runs from PAR to nCoA on 
the MN. If not, then the current spec runs the tunnel to the NAR.

I'm proposing to modify this. The modification is that the specification of 
a tunnel to NAR is dropped. Instead, the specification requires the MN to do 
oDAD on the new link and send FBU to the PAR again from the new link with 
the new CoA, treating the handover as reactive.

> FBack is waiting in the queue).

I'm proposing the FBack is only sent through NAR to the nCoA if the proposed 
nCoA is accepted (it is always sent through PAR to the oCoA). If the 
proposed nCoA is not accepted, no FBack is sent and the MN must again 
failover to reactive handover.

As a separate issue, we can discuss NAR and NAACK v.s. a simple NS.

> the MN shows up on NAR's link.

Right. I'm proposing that since this is a very rare event, we drop this 
additional feature with the attendant code and additional complexity and 
instead use features that are already part of the protocol and necessary for 
other reasons (i.e. reactive handover) to solve the problem, thereby 
simplifying the protocol.

Would you like me to make a proposal in the issue data base on this?

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Sep 2005 10:42:35 -0700

Hi Jim,

ya, I was showing how the PAR - NAR tunnel could still provide 
predictive handover feature. I agree that you can live with reactive 
handover. Note that:

- PAR - NAR tunnel set up is optional (MAY, not required).
- there will not be two different tunnels.

Would you object to having it as an option?

-Rajeev

James Kempf wrote:
>> PAR - NAR tunnel is set up already. So, all it has to do is to 
>> announce itself to the NAR and receive packets. And, send packets 
>> using PCoA.
> If the proposed CoA was accepted, then the tunnel runs from PAR to nCoA 
> on the MN. If not, then the current spec runs the tunnel to the NAR.
> 
> I'm proposing to modify this. The modification is that the specification 
> of a tunnel to NAR is dropped. Instead, the specification requires the 
> MN to do oDAD on the new link and send FBU to the PAR again from the new 
> link with the new CoA, treating the handover as reactive.
> 
>>>
>>> 2) The MN gets the FBack on the NAR as the first packet when it 
>>> arrives on the link, in which case the MN can take the action above.
>>>
>>
> I'm proposing the FBack is only sent through NAR to the nCoA if the 
> proposed nCoA is accepted (it is always sent through PAR to the oCoA). 
> If the proposed nCoA is not accepted, no FBack is sent and the MN must 
> again failover to reactive handover.
> 
>> So, when PAR - NCoA tunnel fails (very rarely I would think), PAR - 
>> NAR tunnel is already set up providing the predictive handover 
>> features when the MN shows up on NAR's link.
>>
> 
> instead use features that are already part of the protocol and necessary 
> for other reasons (i.e. reactive handover) to solve the problem, thereby

---

From: "James Kempf" <[email-masked]>
Date: Fri, 16 Sep 2005 10:54:09 -0700

I'd like to simplify the protocol. I don't think an additional tunneling 
mode is necessary. I don't think it makes a difference if it's a MAY or not.

If nobody else is interested in this, I'm willing to drop it. Is anyone else 
interested in simplifying the protocol by getting rid of the PAR-NAR tunnel?

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: "GAABAB Brahim RD-CORE-CAE" <[email-masked]>; 
<[email-masked]>; "Alexandru Petrescu" <[email-masked]>
Sent: Friday, September 16, 2005 10:42 AM
Subject: Re: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?

>
> Hi Jim,
>
> ya, I was showing how the PAR - NAR tunnel could still provide predictive 
> handover feature. I agree that you can live with reactive handover. Note 
> that:
>
>> of a tunnel to NAR is dropped. Instead, the specification requires the MN 
>> to do oDAD on the new link and send FBU to the PAR again from the new 
>> proposed nCoA is accepted (it is always sent through PAR to the oCoA). If 
>> the proposed nCoA is not accepted, no FBack is sent and the MN must again

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Sep 2005 11:10:02 -0700

Perhaps a better question might be "are there objections to having it as 
an option"?

I am okay either way. Just that if someone wishes to keep an option, we 
should not disallow it (assuming it is not overly complex of course!).

Thanks,

-Rajeev

James Kempf wrote:
> If nobody else is interested in this, I'm willing to drop it. Is anyone 
> else interested in simplifying the protocol by getting rid of the 
> PAR-NAR tunnel?
> 
>            jak
> 
>>>> Okay. In this case (according to the current spec), the MN knows 
>>>> that PAR - NAR tunnel is set up already. So, all it has to do is to 
>>> If the proposed CoA was accepted, then the tunnel runs from PAR to 
>>> nCoA on the MN. If not, then the current spec runs the tunnel to the 
>>> NAR.
>>>
>>> I'm proposing to modify this. The modification is that the 
>>> specification of a tunnel to NAR is dropped. Instead, the 
>>> specification requires the MN to do oDAD on the new link and send FBU 
>>> to the PAR again from the new link with the new CoA, treating the 
>>> handover as reactive.
>>>
>>>>>
>>>> Before the MN receives FBack, it would have sent FNA to which the 
>>>> NAR would respond NAACK. In any event, the tunnel is already set up 
>>>> (hence FBack is waiting in the queue).
>>>>
>>>
>>> proposed nCoA is accepted (it is always sent through PAR to the 
>>> oCoA). If the proposed nCoA is not accepted, no FBack is sent and the 
>>> MN must again failover to reactive handover.
>>>
>>> Right. I'm proposing that since this is a very rare event, we drop 
>>> this additional feature with the attendant code and additional 
>>> complexity and instead use features that are already part of the 
>>> protocol and necessary for other reasons (i.e. reactive handover) to 
>>> solve the problem, thereby simplifying the protocol.
>>>

---

From: Theodoros Pagtzis <[email-masked]>
Date: Sat, 17 Sep 2005 08:34:37 +0100

I am also in favour of dropping the tunnel as per my original suggestions..

theodoros

-- 
theo
Nets & Mobile Systems Group
UCL-CS

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 19 Sep 2005 11:49:23 +0200

James Kempf wrote:

> I'd like to simplify the protocol. I don't think an additional
> tunneling mode is necessary. I don't think it makes a difference if
> it's a MAY or not.
> 
> If nobody else is interested in this, I'm willing to drop it. Is
> anyone else interested in simplifying the protocol by getting rid of
> the PAR-NAR tunnel?

After reading the discussion on this topic - yes I'm interested in
keeping only one mode of tunnelling, and get rid of the PAR-NAR tunnel.

Alex

> 
> jak
> 
> ----- Original Message ----- From: "Rajeev Koodli"
> <[email-masked]> To: "James Kempf" <[email-masked]> 
> <[email-masked]>; "Alexandru Petrescu"
> <[email-masked]> Sent: Friday, September 16, 2005
> 10:42 AM Subject: Re: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?
> 
> 
> 
>> 
>> Hi Jim,
>> 
>> predictive handover feature. I agree that you can live with
>> reactive handover. Note that:
>> 
>> - PAR - NAR tunnel set up is optional (MAY, not required). - there
>> will not be two different tunnels.
>> 
>>>> Okay. In this case (according to the current spec), the MN
>>>> knows that PAR - NAR tunnel is set up already. So, all it has
>>>> to do is to announce itself to the NAR and receive packets.
>>>> And, send packets using PCoA. In essence, predictive handover.
>>>> 
>>> 
>>> If the proposed CoA was accepted, then the tunnel runs from PAR
>>> to nCoA on the MN. If not, then the current spec runs the tunnel
>>> to the NAR.
>>> 
>>> specification requires the MN to do oDAD on the new link and send
>>> FBU to the PAR again from the new link with the new CoA, treating
>>> the handover as reactive.
>>> 
>>>>> 
>>>>> 2) The MN gets the FBack on the NAR as the first packet when
>>>>> it arrives on the link, in which case the MN can take the
>>>>> action above.
>>>>> 
>>>> 
>>>> Before the MN receives FBack, it would have sent FNA to which
>>>> the NAR would respond NAACK. In any event, the tunnel is
>>>> already set up (hence FBack is waiting in the queue).
>>>> 
>>> 
>>> I'm proposing the FBack is only sent through NAR to the nCoA if
>>> the proposed nCoA is accepted (it is always sent through PAR to
>>> the oCoA). If the proposed nCoA is not accepted, no FBack is sent
>>> and the MN must again failover to reactive handover.
>>> 
>>>> So, when PAR - NCoA tunnel fails (very rarely I would think),
>>>> PAR - NAR tunnel is already set up providing the predictive
>>>> handover features when the MN shows up on NAR's link.
>>>> 
>>> 
>>> Right. I'm proposing that since this is a very rare event, we
>>> drop this additional feature with the attendant code and
>>> additional complexity and instead use features that are already
>>> part of the protocol and necessary for other reasons (i.e.
>>> reactive handover) to solve the problem, thereby simplifying the
>>> protocol.
>>>

---

From: "Junghoon Jee" <[email-masked]>
Date: Wed, 21 Sep 2005 10:46:26 +0900

Hi Rajeev,

I'm in favor of keeping this option.
I think this tunnel from PAR to NAR can allow the buffered packet at PAR can
traverse up to NAR even in the reactive mode.

Thanks,
Junghoon

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Rajeev Koodli
> Sent: Saturday, September 17, 2005 3:10 AM
> To: James Kempf
> Cc: [email-masked]; Alexandru Petrescu
> Perhaps a better question might be "are there objections to 
> having it as an option"?
> 
> I am okay either way. Just that if someone wishes to keep an 
> option, we should not disallow it (assuming it is not overly 
> complex of course!).
> 
> Thanks,
> 
> -Rajeev
> 
> 
> 
> 
> James Kempf wrote:
> > <[email-masked]>
> >>> oCoA). If the proposed nCoA is not accepted, no FBack is sent and 
> >>> the MN must again failover to reactive handover.
> >>>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 20 Sep 2005 19:58:44 -0700

Can you explain this?

In reactive mode, the MN sends the FBU from the NAR to the PAR. At the time 
it sends the FBU, the MN must have a new CoA. Therefore, there should be no 
problem running the tunnel from the PAR to the nCoA. The PAR can't start the 
tunnel until it receives the FBU.

           jak

----- Original Message ----- 
From: "Junghoon Jee" <[email-masked]>
To: "'Rajeev Koodli'" <[email-masked]>; "'James Kempf'" 
<[email-masked]>
Cc: <[email-masked]>; "'Alexandru Petrescu'" 
<[email-masked]>
Sent: Tuesday, September 20, 2005 6:46 PM
Subject: RE: [Mipshop] FMIPv6 - NAR sets up tunnel endpoint?

---

From: "Junghoon Jee" <[email-masked]>
Date: Wed, 21 Sep 2005 14:39:15 +0900

Okay,

My rationale to keep this tunnel from PAR to NAR is based on the recommended
packet forwarding point in the predictive mode.
The recommended packet forwarding point is when PAR receives the "Ack" to
use the proposed NCoA through the HI/HAck exchange with NAR 
not just receiving FBU from MN.

In this recommended case, the packet forwarding from PAR can not start when
the proposed NCoA is invalid or in-use by other node.
Therefore, we need to deliver the buffered packet by making a PCoA/NCoA
binding by FBU at PAR through reactive mode.
On the contrary, if we can set up the tunnel between PAR and NAR by the
exchange of HI/HAck to forward the packets sent with PCoA as source IP, 
packets arriving at PAR can traverse up to NAR regardless of the proposed
NCoA confirmation result.

Thanks,
Junghoon

> From: James Kempf [mailto:[email-masked]] 
> Sent: Wednesday, September 21, 2005 11:59 AM
> To: Junghoon Jee; 'Rajeev Koodli'
> Cc: [email-masked]; 'Alexandru Petrescu'
> In reactive mode, the MN sends the FBU from the NAR to the 
> PAR. At the time it sends the FBU, the MN must have a new 
> CoA. Therefore, there should be no problem running the tunnel 
> from the PAR to the nCoA. The PAR can't start the tunnel 
> until it receives the FBU.
> 
>            jak
> 
> 
> > I think this tunnel from PAR to NAR can allow the buffered 
> packet at PAR 
> > can