Subject: [Mipshop] Question on uplink packet in draft-yokota-mipshop-pfmipv6-00

From: "Desire Oulai" <[email-masked]>
Date: Wed, 10 Sep 2008 15:33:11 -0400

Hi Hidetoshi, 

> In section 4 of the draft, it is written 
> 
>    For the uplink packets from the MN after handover
>    in (i), the NAR forwards the packets to the PAR through the tunnel
>    established in step (d).  The PAR then decapsulates and sends them
> to
>    the LMA.
> 
> I have concerns regarding the uplink packets. In PMIP, before being
> able to use MN-HoA on the N-MAG, the PBU/PBA exchange must be
> completed. That means the PMIP tunnel between LMA and MAG is setup
> before advertising the HNP on the link. In this case, the uplink
> packets must be forwarded using PMIP tunnel between NMAG and LMA.
> Otherwise, you need to give more clarification on the capability to
> send packets before the PBU/PBA completion.
> 
> BR
> 
	Desire

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

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 10 Sep 2008 14:44:34 -0500

Hi Desire,

The UL packets are being sent via the bi-directional tunnel established
between the pMAG and nMAG.
It is the pMAG that forwards the UL packets to the LMA which has the BCE for
the CoA of the pMAG and hence processes the packets.
UL packets from the nMAG are sent only after completing PBU/Pback signaling
with the LMA.

-Basavaraj

On 9/10/08 2:33 PM, "ext Desire Oulai" <[email-masked]> wrote:

>>    established in step (d).  The PAR then decapsulates and sends them to
>>    the LMA. 
>> 
>> I have concerns regarding the uplink packets. In PMIP, before being able to
>> use MN-HoA on the N-MAG, the PBU/PBA exchange must be completed. That means
>> the PMIP tunnel between LMA and MAG is setup before advertising the HNP on
>> the link. In this case, the uplink packets must be forwarded using PMIP
>> tunnel between NMAG and LMA. Otherwise, you need to give more clarification
>> on the capability to send packets before the PBU/PBA completion.
>> 
>> BR 
>> 
>> Desire 
> 
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 10 Sep 2008 15:51:29 -0400

Hi Desire,

The uplink packets are forwarded using the Inter-MAG tunnel until the
New-MAG - LMA tunnel established. 

Once the PMIP tunnel is in place, packet forwarding takes place using
that tunnel. 

This is exactly like in RFC 5268 where once the MIP tunnel is in place,
it is used for all packet forwarding. 

Regards,

-Rajeev

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Desire Oulai
Sent: Wednesday, September 10, 2008 12:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Mipshop] Question on uplink packet
indraft-yokota-mipshop-pfmipv6-00

Hi Hidetoshi, 

   the LMA. 

I have concerns regarding the uplink packets. In PMIP, before being able
to use MN-HoA on the N-MAG, the PBU/PBA exchange must be completed. That
means the PMIP tunnel between LMA and MAG is setup before advertising
the HNP on the link. In this case, the uplink packets must be forwarded
using PMIP tunnel between NMAG and LMA. Otherwise, you need to give more
clarification on the capability to send packets before the PBU/PBA
completion.

BR 

Desire

---

From: "Desire Oulai" <[email-masked]>
Date: Wed, 10 Sep 2008 15:53:35 -0400

HI Basavaraj,
 
   Maybe I need some clarification here. My question is to know if the
MN will keep sending packets with MN-HoA directly after L2 attach? Or
will it wait to receive the HNP on the new link, figure that the link
"didn't change" when receiving the HNP, then sends packets using MN-HoA?
If it is the second option, the uplink packets are forwarded directly
via PMIP tunnel, aren't they?
 
Desire

	From: Basavaraj Patil [mailto:[email-masked]] 
	Sent: September 10, 2008 3:45 PM
	To: Desire Oulai; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Mipshop] Question on uplink packet in
draft-yokota-mipshop-pfmipv6-00

	Hi Desire,
	
	The UL packets are being sent via the bi-directional tunnel
established between the pMAG and nMAG. 
	It is the pMAG that forwards the UL packets to the LMA which has
the BCE for the CoA of the pMAG and hence processes the packets. 
	UL packets from the nMAG are sent only after completing
PBU/Pback signaling with the LMA.
	
	-Basavaraj

	On 9/10/08 2:33 PM, "ext Desire Oulai"
<[email-masked]> wrote:

			Hi Hidetoshi, 

			  For the uplink packets from the MN after
handover 
			  in (i), the NAR forwards the packets to the
PAR through the tunnel 
			  established in step (d).  The PAR then
decapsulates and sends them to 
			  the LMA. 
			
			I have concerns regarding the uplink packets. In
PMIP, before being able to use MN-HoA on the N-MAG, the PBU/PBA exchange
must be completed. That means the PMIP tunnel between LMA and MAG is
setup before advertising the HNP on the link. In this case, the uplink
packets must be forwarded using PMIP tunnel between NMAG and LMA.
Otherwise, you need to give more clarification on the capability to send
packets before the PBU/PBA completion.
			
			BR 
			
			Desire

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Sep 2008 15:05:28 -0500

Hi Desire,
hmmm... you are raising a very good point.
 
Let me try to understand what you just said. After the link layer is
established, the Mobile node for sure it knows that it has handed over
to a new link BUT can not be sure that this link does support the same
HNP that was supported on the previous link.
 
Also, since the UE does not have a client MIP6 on it, it will be best
for the UE to wait until it receives a RA to confirm that it still on
the same link and that link for sure support the same HNP.
 
Is my understanding of your question correct?
 
Cheers!

Regards, 
Ahmad 

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Desire Oulai
	Sent: Wednesday, September 10, 2008 2:54 PM
	To: Basavaraj Patil; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Mipshop] Question on uplink packet in
draft-yokota-mipshop-pfmipv6-00

	HI Basavaraj,
	 
	   Maybe I need some clarification here. My question is to know
if the MN will keep sending packets with MN-HoA directly after L2
attach? Or will it wait to receive the HNP on the new link, figure that
the link "didn't change" when receiving the HNP, then sends packets
using MN-HoA? If it is the second option, the uplink packets are
forwarded directly via PMIP tunnel, aren't they?
	 
	Desire

		
		Hi Desire,
		
		The UL packets are being sent via the bi-directional
tunnel established between the pMAG and nMAG. 
		It is the pMAG that forwards the UL packets to the LMA
which has the BCE for the CoA of the pMAG and hence processes the
packets. 
		UL packets from the nMAG are sent only after completing
PBU/Pback signaling with the LMA.
		
		-Basavaraj

				Hi Hidetoshi, 

				  For the uplink packets from the MN
after handover 
				  in (i), the NAR forwards the packets
to the PAR through the tunnel 
				  established in step (d).  The PAR then
decapsulates and sends them to 
				  the LMA. 
				
				I have concerns regarding the uplink
packets. In PMIP, before being able to use MN-HoA on the N-MAG, the
PBU/PBA exchange must be completed. That means the PMIP tunnel between
LMA and MAG is setup before advertising the HNP on the link. In this
case, the uplink packets must be forwarded using PMIP tunnel between
NMAG and LMA. Otherwise, you need to give more clarification on the
capability to send packets before the PBU/PBA completion.
				
				BR 
				
				Desire

---

From: "Desire Oulai" <[email-masked]>
Date: Wed, 10 Sep 2008 16:10:31 -0400

Hi Ahmad,
 
 It is correct. That's why i believe the inter-MAG tunnel is not needed
for uplink traffic.
 
BR
 
Desire

	From: Ahmad Muhanna [mailto:[email-masked]] 
	Sent: September 10, 2008 4:05 PM
	To: Desire Oulai; Basavaraj Patil; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Mipshop] Question on uplink packet in
draft-yokota-mipshop-pfmipv6-00

	Hi Desire,
	 
	Let me try to understand what you just said. After the link
layer is established, the Mobile node for sure it knows that it has
handed over to a new link BUT can not be sure that this link does
support the same HNP that was supported on the previous link.
	 
	Also, since the UE does not have a client MIP6 on it, it will be
best for the UE to wait until it receives a RA to confirm that it still
on the same link and that link for sure support the same HNP.

	Cheers!

	Regards, 
	Ahmad 

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Desire Oulai
		Sent: Wednesday, September 10, 2008 2:54 PM
		To: Basavaraj Patil; [email-masked]
		Cc: [email-masked]
		Subject: Re: [Mipshop] Question on uplink packet in
draft-yokota-mipshop-pfmipv6-00

		HI Basavaraj,
		 
		   Maybe I need some clarification here. My question is
to know if the MN will keep sending packets with MN-HoA directly after
L2 attach? Or will it wait to receive the HNP on the new link, figure
that the link "didn't change" when receiving the HNP, then sends packets
using MN-HoA? If it is the second option, the uplink packets are
forwarded directly via PMIP tunnel, aren't they?
		 
		Desire

			From: Basavaraj Patil
[mailto:[email-masked]] 
			Sent: September 10, 2008 3:45 PM
			To: Desire Oulai; [email-masked]
			Cc: [email-masked]
			Subject: Re: [Mipshop] Question on uplink packet
in draft-yokota-mipshop-pfmipv6-00

			Hi Desire,
			
			The UL packets are being sent via the
bi-directional tunnel established between the pMAG and nMAG. 
			It is the pMAG that forwards the UL packets to
the LMA which has the BCE for the CoA of the pMAG and hence processes
the packets. 
			UL packets from the nMAG are sent only after
completing PBU/Pback signaling with the LMA.
			
			-Basavaraj

					Hi Hidetoshi, 

				
				
				BR 
				
				Desire

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 10 Sep 2008 15:20:01 -0500

Hi Desire,

It depends on the implementation. If the link change is hidden the MN
continues to send packets using MN-HoA.
If the link change needs to be handled, then the MN may send an RS and wait
for an RA before continuing to send packets with the MN-HoA.

Your assumption is that the PMIP tunnel between the nMAG and LMA is
established as a result of receiving an RS from the MN.
It need not be the case. Because of the bi-directional tunnel that has been
established between the nMAG and pMAG, the nMAG may delay establishing the
PMIP tunnel and instead send respond to the RS with an RA with the prefix
received from the pMAG during the HI/HAck signaling.

-Raj

On 9/10/08 2:53 PM, "ext Desire Oulai" <[email-masked]> wrote:

> HI Basavaraj,
>  
>    Maybe I need some clarification here. My question is to know if the MN will
> keep sending packets with MN-HoA directly after L2 attach? Or will it wait to
> receive the HNP on the new link, figure that the link "didn't change" when
> receiving the HNP, then sends packets using MN-HoA? If it is the second
> option, the uplink packets are forwarded directly via PMIP tunnel, aren't
> they?
>  
> Desire
> 
>>  
>>  
>> 
>>>> means the PMIP tunnel between LMA and MAG is setup before  advertising the
>>>> HNP on the link. In this case, the uplink packets must be  forwarded using
>>>> PMIP tunnel between NMAG and LMA. Otherwise, you need to  give more

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 10 Sep 2008 16:19:51 -0400

Hi Desire,

The MN should be able to keep sending packets after the L2 attach. Why
should we _make_ the MN wait?

Sure, it may perform ND, but there is no need to pause packet
transmission. Otherwise, what is the point of fast handover?

We dealt with this in FMIP previously..

Regards,

-Rajeev

Sent: Wednesday, September 10, 2008 12:54 PM

HI Basavaraj,

Desire

	Hi Desire,

	-Basavaraj

	Hi Hidetoshi, 

	  For the uplink packets from the MN after handover 
	  in (i), the NAR forwards the packets to the PAR through the
tunnel 
	  established in step (d).  The PAR then decapsulates and sends
them to 
	  the LMA. 
	
	I have concerns regarding the uplink packets. In PMIP, before
being able to use MN-HoA on the N-MAG, the PBU/PBA exchange must be
completed. That means the PMIP tunnel between LMA and MAG is setup
before advertising the HNP on the link. In this case, the uplink packets
must be forwarded using PMIP tunnel between NMAG and LMA. Otherwise, you
need to give more clarification on the capability to send packets before
the PBU/PBA completion.
	
	BR 
	
	Desire

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Sep 2008 15:21:21 -0500

Hi Desire,
 
I agree!
 
On the other hand, in order to solve this issue that you just raised,
which is applicable to 3GPP, I believe all what we need here is some
kind of a pre-registration mechanism as has once been defined in
"draft-muhanna-netlmm-pmip6-support-transient-coa-reg".
 
do you agree?

Regards, 
Ahmad 

	From: Desire Oulai [mailto:[email-masked]] 
	Sent: Wednesday, September 10, 2008 3:11 PM
	To: Muhanna, Ahmad (RICH1:2H10); Basavaraj Patil;
[email-masked]
	Cc: [email-masked]
	Subject: RE: [Mipshop] Question on uplink packet in
draft-yokota-mipshop-pfmipv6-00

	Hi Ahmad,
	 
	 It is correct. That's why i believe the inter-MAG tunnel is not
needed for uplink traffic.
	 
	BR
	 
	Desire

		Hi Desire,
		 
		Let me try to understand what you just said. After the
link layer is established, the Mobile node for sure it knows that it has
handed over to a new link BUT can not be sure that this link does
support the same HNP that was supported on the previous link.
		 
		Also, since the UE does not have a client MIP6 on it, it
will be best for the UE to wait until it receives a RA to confirm that
it still on the same link and that link for sure support the same HNP.

		Cheers!

		Regards, 
		Ahmad 

			HI Basavaraj,
			 
			   Maybe I need some clarification here. My
question is to know if the MN will keep sending packets with MN-HoA
directly after L2 attach? Or will it wait to receive the HNP on the new
link, figure that the link "didn't change" when receiving the HNP, then
sends packets using MN-HoA? If it is the second option, the uplink
packets are forwarded directly via PMIP tunnel, aren't they?
			 
			Desire

				From: Basavaraj Patil
[mailto:[email-masked]] 
				Sent: September 10, 2008 3:45 PM
				To: Desire Oulai; [email-masked]
				Cc: [email-masked]
				Subject: Re: [Mipshop] Question on
uplink packet in draft-yokota-mipshop-pfmipv6-00

				Hi Desire,
				
				The UL packets are being sent via the
bi-directional tunnel established between the pMAG and nMAG. 
				It is the pMAG that forwards the UL
packets to the LMA which has the BCE for the CoA of the pMAG and hence
processes the packets. 
				UL packets from the nMAG are sent only
after completing PBU/Pback signaling with the LMA.
				
				-Basavaraj

					Hi Hidetoshi, 

				
				
				BR 
				
				Desire

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 10 Sep 2008 16:21:33 -0400

UL data transport between the MAGs is absolutely needed. There are
systems out there where there is no explicit L2 between the MN and the
MAG/AR. Also, there are handover cases where the new MAG gets context
info from the old MAG and it can maintain the link with the MN w/o the
MN detecting any change at all. In this case, the MN will continue to
send UL packets via the target system w/o waiting.

-Kuntal

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Desire Oulai
Sent: Wednesday, September 10, 2008 3:11 PM
To: Ahmad Muhanna; Basavaraj Patil; [email-masked]
Cc: [email-masked]
Subject: Re: [Mipshop] Question on uplink packetin
draft-yokota-mipshop-pfmipv6-00

Hi Ahmad,

BR

Desire

	Hi Desire,

	Cheers!

	Regards, 
	Ahmad 

		HI Basavaraj,

		Desire

			From: Basavaraj Patil

			Hi Desire,

			-Basavaraj

			Hi Hidetoshi, 

			
			
			BR 
			
			Desire

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Sep 2008 15:28:40 -0500

Hi Kuntal,
 
Sure, however, any solution that IETF is going to adopt for PMIPv6
handover optimization need to take in consideration all different type
of access technologies and SDOs. NO? Otherwise, we are specifying an SDO
specific solution. The fact is that during HO, the MN MAY very well know
that it had moved to a new link and the MN is NOT sure if that link
support the same HNP that has been advertised on the previous link. 

Regards, 
Ahmad 

	From: Chowdhury, Kuntal [mailto:[email-masked]] 
	Sent: Wednesday, September 10, 2008 3:16 PM
	To: Muhanna, Ahmad (RICH1:2H10); Desire Oulai; Basavaraj Patil;
[email-masked]
	Cc: [email-masked]
	Subject: RE: [Mipshop] Question on uplink packetin
draft-yokota-mipshop-pfmipv6-00

	There are cases where L2 attach during handover simply means the
MN got its radio link established with the target radio access system.
The MN will be agnostic to the fact that the new radio access system is
connected to a new MAG/AR. In this scenario, the MN will continue to
send UL packets......

	I think the term L2 attach is very access technology specific.
There is no single interpretation of this term.

	BR,

	Kuntal

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Ahmad Muhanna
	Sent: Wednesday, September 10, 2008 3:05 PM
	To: Desire Oulai; Basavaraj Patil; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Mipshop] Question on uplink packetin
draft-yokota-mipshop-pfmipv6-00

	Hi Desire,

	Cheers!

	Regards, 
	Ahmad 

		HI Basavaraj,

		Desire

			From: Basavaraj Patil

			Hi Desire,

			-Basavaraj

			Hi Hidetoshi, 

			
			
			BR 
			
			Desire 

	"This email message and any attachments are confidential
information of Starent Networks, Corp. The information transmitted may
not be used to create or change any contractual obligations of Starent
Networks, Corp. Any review, retransmission, dissemination or other use
of, or taking of any action in reliance upon this e-mail and its
attachments by persons or entities other than the intended recipient is
prohibited. If you are not the intended recipient, please notify the
sender immediately -- by replying to this message or by sending an email
to [email-masked] -- and destroy all copies of this
message and any attachments without reading or disclosing their
contents. Thank you."

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 10 Sep 2008 16:27:07 -0400

Ahmad,

This draft that you mention below is not needed by 3GPP as per the
frozen Rel-8 spec.

Thank you,

Kuntal

Behalf Of Ahmad Muhanna
Sent: Wednesday, September 10, 2008 3:21 PM

Hi Desire,

I agree!

do you agree?

Regards, 
Ahmad 

	Hi Ahmad,

	BR

	Desire

		Hi Desire,

		Cheers!

		Regards, 
		Ahmad 

			HI Basavaraj,

			Desire

				From: Basavaraj Patil

				Hi Desire,

				-Basavaraj

				Hi Hidetoshi, 

				
				
				BR 
				
				Desire

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 10 Sep 2008 15:35:24 -0500

Ahmad,

At what layer the MN knows that it has switched links is a relevant point.
However MNs may hide link changes to upper layers especially in the context
of handovers between networks where PMIP6 is being used in both. It is an
implementation issue. If you think of a scenario where the MN is on a shared
link where multiple routers exist, the MN may receive an RA from another
router on that link. Does that mean the previous router to which the MN was
attached is no longer available? The MN will need to do NUD to determine
that it has lost connectivity to the previous router. Just because a new
link comes up does not automatically imply that the MN has lost connectivity
with the previous router. And that is what the inter-MAG tunnel enables.

-Raj

On 9/10/08 3:28 PM, "ext Ahmad Muhanna" <[email-masked]> wrote:

> Hi Kuntal,
>  
> Sure, however, any solution that IETF is going to adopt for PMIPv6 handover
> optimization need to take in consideration all different type of access
> technologies and SDOs. NO? Otherwise, we are specifying an SDO specific
> solution. The fact is that during HO, the MN MAY very well know that it had
> moved to a new link and the MN is NOT sure if that link support the same HNP
> that has been advertised on the previous link.
> Regards, 
> Ahmad 
> 
>  
> 
>>  
>>  
>> 
>> There are cases where  L2 attach during handover simply means the MN got its
>> radio link established  with the target radio access system. The MN will be
>> agnostic to the fact that  the new radio access system is connected to a new
>> MAG/AR. In this scenario,  the MN will continue to send UL packetsŠŠ
>>  
>>  
>>  
>> I think the term L2  attach is very access technology specific. There is no
>> single interpretation  of this term.
>>  
>>  
>>  
>> BR,
>>  
>> Kuntal
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>>  
>> 
>>  
>>  
>> 
>> From:  [email-masked] [mailto:[email-masked]] On Behalf
>> Of Ahmad Muhanna
>> established, the  Mobile node for sure it knows that it has  handed over to a
>> new link BUT can not be sure that this link does support the  same HNP that
>> was supported on the previous  link.
>>  
>>  
>> 
>>  
>>  
>>  
>> 
>> Also, since the UE  does not have a client MIP6 on it, it will be best for
>> the UE to wait until it  receives a RA to confirm that it still on the same
>> link and that link for sure  support the same HNP.
>>  
>>  
>> 
>>  
>>  
>>  
>> 
>>> From:  [email-masked] [mailto:[email-masked]] On Behalf
>>> Of Desire Oulai
>>>    Maybe  I need some clarification here. My question is to know if the MN
>>> will keep  sending packets with MN-HoA directly after L2 attach? Or will it
>>> wait  to receive the HNP on the new link, figure that the link "didn't
>>> change"  when receiving the HNP, then sends packets using MN-HoA? If it is
>>> the second  option, the uplink packets are forwarded directly via PMIP
>>> tunnel,  aren't they?
>>>  
>>>  
>>>  
>>> Desire
>>>  
>>>>  
>>>>  
>>>>  
>>>>  
>>>> 
>>>>  
>>>>  
>>>> 
>>>> It is the pMAG that forwards  the UL packets to the LMA which has the BCE
>>>> for the CoA of the pMAG and  hence processes the packets.
>>>> UL packets from the nMAG are sent only  after completing PBU/Pback
>>>> signaling with the  LMA.
>>>> 
>>>> -Basavaraj
>>>> 
>>>> 
>>>> "This email message and any attachments are confidential information of
>>>> Starent Networks, Corp. The information transmitted may not be used to
>>>> create  or change any contractual obligations of Starent Networks, Corp.
>>>> Any review,  retransmission, dissemination or other use of, or taking of
>>>> any action in  reliance upon this e-mail and its attachments by persons or
>>>> entities other  than the intended recipient is prohibited. If you are not
>>>> the intended  recipient, please notify the sender immediately -- by
>>>> replying to this message  or by sending an email to
>>>> [email-masked] -- and destroy all  copies of this message
>>>> and any attachments without reading or disclosing their  contents. Thank
>>>> you." 
>>>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Sep 2008 15:36:02 -0500

Hi Kuntal,
Please see inline.

Regards, 
Ahmad

	From: Chowdhury, Kuntal [mailto:[email-masked]] 
	Sent: Wednesday, September 10, 2008 3:22 PM
	To: Desire Oulai; Muhanna, Ahmad (RICH1:2H10); Basavaraj Patil;
[email-masked]
	Cc: [email-masked]
	Subject: RE: [Mipshop] Question on uplink packetin
draft-yokota-mipshop-pfmipv6-00

	UL data transport between the MAGs is absolutely needed. There
are systems out there where there is no explicit L2 between the MN and
the MAG/AR. 

	[Ahmad]

	Sure. On the other hand, there are systems out there where the
MN is very well aware of the link change. What these systems need to do?

	find another solution?

	Also, there are handover cases where the new MAG gets context
info from the old MAG and it can maintain the link with the MN w/o the
MN detecting any change at all. In this case, the MN will continue to
send UL packets via the target system w/o waiting.

	-Kuntal

	Hi Ahmad,

	BR

	Desire

		Hi Desire,

		Cheers!

		Regards, 
		Ahmad 

			HI Basavaraj,

			Desire

				From: Basavaraj Patil

				Hi Desire,

				-Basavaraj

				Hi Hidetoshi, 

				
				
				BR 
				
				Desire

---

From: "Desire Oulai" <[email-masked]>
Date: Wed, 10 Sep 2008 16:47:16 -0400

Hi Raj and Kuntal,
 
  A solution for fast handover should work for both type of
implementation behaviour. This discussion should be considered for this
draft. On the other hand, the transient BCE approach of
draft-muhanna-netlmm-pmip6-support-transient-coa-reg is another
interesting way to optimize the handover. 
 
Desire

From: Basavaraj Patil [mailto:[email-masked]] 
Sent: September 10, 2008 4:35 PM
To: ext Ahmad Muhanna; Chowdhury, Kuntal; Desire Oulai;
[email-masked]
Cc: [email-masked]
Subject: Re: [Mipshop] Question on uplink packetin
draft-yokota-mipshop-pfmipv6-00

	Ahmad,
	
	At what layer the MN knows that it has switched links is a
relevant point. However MNs may hide link changes to upper layers
especially in the context of handovers between networks where PMIP6 is
being used in both. It is an implementation issue. If you think of a
scenario where the MN is on a shared link where multiple routers exist,
the MN may receive an RA from another router on that link. Does that
mean the previous router to which the MN was attached is no longer
available? The MN will need to do NUD to determine that it has lost
connectivity to the previous router. Just because a new link comes up
does not automatically imply that the MN has lost connectivity with the
previous router. And that is what the inter-MAG tunnel enables. 
	
	-Raj

	On 9/10/08 3:28 PM, "ext Ahmad Muhanna" <[email-masked]>
wrote:

		Hi Kuntal,
		
		Sure, however, any solution that IETF is going to adopt
for PMIPv6 handover optimization need to take in consideration all
different type of access technologies and SDOs. NO? Otherwise, we are
specifying an SDO specific solution. The fact is that during HO, the MN
MAY very well know that it had moved to a new link and the MN is NOT
sure if that link support the same HNP that has been advertised on the
previous link. 
		Regards, 
		Ahmad 

			

			From: Chowdhury, Kuntal
[mailto:[email-masked]] 
			Sent: Wednesday, September  10, 2008 3:16 PM
			To: Muhanna, Ahmad (RICH1:2H10); Desire Oulai;
Basavaraj Patil; [email-masked]
			Cc:  [email-masked]
			Subject: RE: [Mipshop] Question on uplink
packetin  draft-yokota-mipshop-pfmipv6-00

			There are cases where  L2 attach during handover
simply means the MN got its radio link established  with the target
radio access system. The MN will be agnostic to the fact that  the new
radio access system is connected to a new MAG/AR. In this scenario,  the
MN will continue to send UL packets......

			I think the term L2  attach is very access
technology specific. There is no single interpretation  of this term.

			BR,
			
			Kuntal

			 

			

			
			From:  [email-masked]
[mailto:[email-masked]] On Behalf Of Ahmad Muhanna
			Sent: Wednesday, September 10, 2008 3:05  PM
			To: Desire Oulai;  Basavaraj Patil;
[email-masked]
			Cc: [email-masked]
			Subject: Re: [Mipshop] Question on uplink
packetin draft-yokota-mipshop-pfmipv6-00

			Hi  Desire,

			

			
			Let me try to  understand what you just said.
After the link layer is established, the  Mobile node for sure it knows
that it has  handed over to a new link BUT can not be sure that this
link does support the  same HNP that was supported on the previous
link.

			 
			
			Also, since the UE  does not have a client MIP6
on it, it will be best for the UE to wait until it  receives a RA to
confirm that it still on the same link and that link for sure  support
the same HNP.

			 

			

			
			Cheers!
			
			Regards,  
			Ahmad 

			

				

				
				
				Sent: Wednesday, September 10, 2008
2:54 PM
				
				HI  Basavaraj,

				  Maybe  I need some clarification here.
My question is to know if the MN will keep  sending packets with MN-HoA
directly after L2 attach? Or will it wait  to receive the HNP on the new
link, figure that the link "didn't change"  when receiving the HNP, then
sends packets using MN-HoA? If it is the second  option, the uplink
packets are forwarded directly via PMIP tunnel,  aren't they?

				Desire

				

				
				
				From:  Basavaraj Patil

				Hi  Desire,

				-Basavaraj

				Hi  Hidetoshi, 
				
				In section 4 of the  draft, it is
written 

				
				BR  
				
				Desire  

				

	

			"This email message and any attachments are
confidential information of  Starent Networks, Corp. The information
transmitted may not be used to create  or change any contractual
obligations of Starent Networks, Corp. Any review,  retransmission,
dissemination or other use of, or taking of any action in  reliance upon
this e-mail and its attachments by persons or entities other  than the
intended recipient is prohibited. If you are not the intended
recipient, please notify the sender immediately -- by replying to this
message  or by sending an email to [email-masked] -- and
destroy all  copies of this message and any attachments without reading
or disclosing their  contents. Thank you."

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 10 Sep 2008 16:38:54 -0400

Ahmad,

This is not a religious debate. The L2 technologies that we have to work
with are not developed in IETF. We cannot assume that L2 attach means:
the MN needs to stop/pause all activities. If so, there won't be any
reason for fast handover.

At least the three major systems: WiMAX, eHRPD, and LTE....the MN will
not even know that it changed MAG area, unless the new MAG explicitly
tells the MN about the change.

BR,

Kuntal

From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Wednesday, September 10, 2008 3:29 PM
To: Chowdhury, Kuntal; Desire Oulai; Basavaraj Patil; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] Question on uplink packetin
draft-yokota-mipshop-pfmipv6-00

Hi Kuntal,

Regards, 
Ahmad 

	BR,

	Kuntal

	Hi Desire,

	Cheers!

	Regards, 
	Ahmad 

		HI Basavaraj,

		Desire

			From: Basavaraj Patil

			Hi Desire,

			-Basavaraj

			Hi Hidetoshi, 

			
			
			BR 
			
			Desire

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Wed, 10 Sep 2008 16:15:40 -0400

There are cases where L2 attach during handover simply means the MN got
its radio link established with the target radio access system. The MN
will be agnostic to the fact that the new radio access system is
connected to a new MAG/AR. In this scenario, the MN will continue to
send UL packets......

I think the term L2 attach is very access technology specific. There is
no single interpretation of this term.

BR,

Kuntal

Hi Desire,

Cheers!

Regards, 
Ahmad 

	HI Basavaraj,

	Desire

		Hi Desire,

		-Basavaraj

		Hi Hidetoshi, 

		  For the uplink packets from the MN after handover 
		  in (i), the NAR forwards the packets to the PAR
through the tunnel 
		  established in step (d).  The PAR then decapsulates
and sends them to 
		  the LMA. 
		
		I have concerns regarding the uplink packets. In PMIP,
before being able to use MN-HoA on the N-MAG, the PBU/PBA exchange must
be completed. That means the PMIP tunnel between LMA and MAG is setup
before advertising the HNP on the link. In this case, the uplink packets
must be forwarded using PMIP tunnel between NMAG and LMA. Otherwise, you
need to give more clarification on the capability to send packets before
the PBU/PBA completion.
		
		BR 
		
		Desire

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Sep 2008 15:47:43 -0500

Hi Rajeev,

 Hi Desire,

	The MN should be able to keep sending packets after the L2
attach. Why should we _make_ the MN wait?

	[Ahmad]

	IMO, FMIP is a little different than PFMIP. In this context, it
is probably as the difference between Client MI6 and Proxy MIP6.

	Regards,

	Ahmad

	Regards,

	-Rajeev

	HI Basavaraj,

	Desire

		Hi Desire,

		-Basavaraj

		Hi Hidetoshi, 

		
		
		BR 
		
		Desire

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 10 Sep 2008 16:43:48 -0400

Hi Ahmed,

[RKo:>] Well, when a MN detects a link change, it performs NUD, and
probes the reachability of its default router. This is because the
presumed new link could well be served by the same default router. In
the meanwhile the interface is active, which means the packets keep
coming out. You don't want these packets to be dropped or worse paused
because the MN is verifying the reachability of its default router. This
is the reason why we support uplink packets in FMIP and this is the
reason here as well. If you took a look at the design goals of FMIP, one
of them is to disengage the delay due to movement detection from the
critical path. 

There is nothing SDO-specific about this design. It is a matter of
allowing uplink packets to be served while the MN is involved in
protocol operations (including movement detection and (P)MIP).

Regards,

-Rajeev

Regards, 
Ahmad 

	BR,

	Kuntal

	Hi Desire,

	Cheers!

	Regards, 
	Ahmad 

		HI Basavaraj,

		Desire

			From: Basavaraj Patil

			Hi Desire,

			-Basavaraj

			Hi Hidetoshi, 

			
			
			BR 
			
			Desire

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 10 Sep 2008 17:01:18 -0400

Hi Ahmed,

	[Ahmad]

	[RKo:>] Does not matter. The issue is still the same: what
happens to the MN's uplink packets as it verifies reachability of its
default router. There is no reason why it would stop sending packets as
it verifies reachability because the new link could well be served by
the same default router. This is not specific to, umm.. Client MIP6 or
Proxy MIP6 :-)

	Regards,

	-Rajeev

	Regards,

	Ahmad

	Regards,

	-Rajeev

	HI Basavaraj,

	Desire

		Hi Desire,

		-Basavaraj

		Hi Hidetoshi, 

		
		
		BR 
		
		Desire

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Sep 2008 16:06:36 -0500

Hi Raj,
please see inline.

Regards, 
Ahmad

	From: Basavaraj Patil [mailto:[email-masked]] 
	Sent: Wednesday, September 10, 2008 3:35 PM
	To: Muhanna, Ahmad (RICH1:2H10); Chowdhury, Kuntal; Desire
Oulai; [email-masked]
	Cc: [email-masked]
	Subject: Re: [Mipshop] Question on uplink packetin
draft-yokota-mipshop-pfmipv6-00

	Ahmad,
	
	At what layer the MN knows that it has switched links is a
relevant point. However MNs may hide link changes to upper layers
especially in the context of handovers between networks where PMIP6 is
being used in both. It is an implementation issue.  
	[Ahmad]
	Does that mean that we are mandating a specific implementation
on the handset to be able to work with PMIPv6?
	 
	If you think of a scenario where the MN is on a shared link
where multiple routers exist, the MN may receive an RA from another
router on that link. Does that mean the previous router to which the MN
was attached is no longer available? The MN will need to do NUD to
determine that it has lost connectivity to the previous router. Just
because a new link comes up does not automatically imply that the MN has
lost connectivity with the previous router. And that is what the
inter-MAG tunnel enables.  
	 
	[Ahmad]
	It also does not mean that it is still connected to the same
link where the same Prefix is supported. 
	
	-Raj

		Hi Kuntal,

		

			From: Chowdhury, Kuntal

			

			BR,
			
			Kuntal

			 

			

			

			Hi  Desire,

			

			

			 

			

			

			 
			
			Cheers!
			
			Regards,  
			Ahmad 

			

				

				

				HI  Basavaraj,

				
				Desire

				

				
				
				From:  Basavaraj Patil

				Hi  Desire,

				-Basavaraj

				Hi  Hidetoshi, 

				
				
				BR  
				
				Desire

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Wed, 10 Sep 2008 14:11:06 -0700

Hi folks,

I think the difference between FMIPv6 and PFMIPv6 is that in FMIPv6 the MN always sends packets using its NCoA from the new link. So the MN is still sending packets with a topologically correct address from the new link. In the case of PFMIPv6, the MN starts sending packets using its HoA without knowing if it is reachable through that address in the new link (unless I miss something in the protocol)

Gerardo

From: [email-masked] [mailto:[email-masked]] On Behalf Of Koodli, Rajeev
Sent: Wednesday, September 10, 2008 1:44 PM
To: Ahmad Muhanna; Chowdhury, Kuntal; Desire Oulai; Basavaraj Patil; [email-masked]
Cc: [email-masked]
Subject: Re: [Mipshop] Question on uplink packetindraft-yokota-mipshop-pfmipv6-00

Hi Ahmed,

Sure, however, any solution that IETF is going to adopt for PMIPv6 handover optimization need to take in consideration all different type of access technologies and SDOs. NO? Otherwise, we are specifying an SDO specific solution. The fact is that during HO, the MN MAY very well know that it had moved to a new link and the MN is NOT sure if that link support the same HNP that has been advertised on the previous link.

[RKo:>] Well, when a MN detects a link change, it performs NUD, and probes the reachability of its default router. This is because the presumed new link could well be served by the same default router. In the meanwhile the interface is active, which means the packets keep coming out. You don't want these packets to be dropped or worse paused because the MN is verifying the reachability of its default router. This is the reason why we support uplink packets in FMIP and this is the reason here as well. If you took a look at the design goals of FMIP, one of them is to disengage the delay due to movement detection from the critical path.

There is nothing SDO-specific about this design. It is a matter of allowing uplink packets to be served while the MN is involved in protocol operations (including movement detection and (P)MIP).

Regards,

-Rajeev

Regards,
Ahmad

________________________________
From: Chowdhury, Kuntal [mailto:[email-masked]]
Sent: Wednesday, September 10, 2008 3:16 PM
To: Muhanna, Ahmad (RICH1:2H10); Desire Oulai; Basavaraj Patil; [email-masked]
Cc: [email-masked]
Subject: RE: [Mipshop] Question on uplink packetin draft-yokota-mipshop-pfmipv6-00
There are cases where L2 attach during handover simply means the MN got its radio link established with the target radio access system. The MN will be agnostic to the fact that the new radio access system is connected to a new MAG/AR. In this scenario, the MN will continue to send UL packets......

I think the term L2 attach is very access technology specific. There is no single interpretation of this term.

BR,
Kuntal

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ahmad Muhanna
Sent: Wednesday, September 10, 2008 3:05 PM
To: Desire Oulai; Basavaraj Patil; [email-masked]
Cc: [email-masked]
Subject: Re: [Mipshop] Question on uplink packetin draft-yokota-mipshop-pfmipv6-00

Hi Desire,

Let me try to understand what you just said. After the link layer is established, the Mobile node for sure it knows that it has handed over to a new link BUT can not be sure that this link does support the same HNP that was supported on the previous link.

Also, since the UE does not have a client MIP6 on it, it will be best for the UE to wait until it receives a RA to confirm that it still on the same link and that link for sure support the same HNP.

Cheers!

Regards,
Ahmad

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Desire Oulai
Sent: Wednesday, September 10, 2008 2:54 PM
To: Basavaraj Patil; [email-masked]
Cc: [email-masked]
Subject: Re: [Mipshop] Question on uplink packet in draft-yokota-mipshop-pfmipv6-00
HI Basavaraj,

   Maybe I need some clarification here. My question is to know if the MN will keep sending packets with MN-HoA directly after L2 attach? Or will it wait to receive the HNP on the new link, figure that the link "didn't change" when receiving the HNP, then sends packets using MN-HoA? If it is the second option, the uplink packets are forwarded directly via PMIP tunnel, aren't they?

Desire

Subject: Re: [Mipshop] Question on uplink packet in draft-yokota-mipshop-pfmipv6-00

Hi Desire,

The UL packets are being sent via the bi-directional tunnel established between the pMAG and nMAG.
It is the pMAG that forwards the UL packets to the LMA which has the BCE for the CoA of the pMAG and hence processes the packets.
UL packets from the nMAG are sent only after completing PBU/Pback signaling with the LMA.

-Basavaraj

I have concerns regarding the uplink packets. In PMIP, before being able to use MN-HoA on the N-MAG, the PBU/PBA exchange must be completed. That means the PMIP tunnel between LMA and MAG is setup before advertising the HNP on the link. In this case, the uplink packets must be forwarded using PMIP tunnel between NMAG and LMA. Otherwise, you need to give more clarification on the capability to send packets before the PBU/PBA completion.

BR

Desire

"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to [email-masked] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
_______________________________________________
Mipshop mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mipshop

---

From: "Desire Oulai" <[email-masked]>
Date: Wed, 10 Sep 2008 17:18:21 -0400

Hi Rajeev,
 
  I don't want the MN to wait. As was mentioned earlier, some MN
implementation may choose to behave differently because of the link
change. I don't necessarily think this is a good behaviour, but the fast
handover design should consider that.
 
BR
 
Desire

	From: Koodli, Rajeev [mailto:[email-masked]] 
	Sent: September 10, 2008 5:04 PM
	To: Desire Oulai; Basavaraj Patil; ext Ahmad Muhanna; Chowdhury,
Kuntal; [email-masked]
	Cc: [email-masked]
	Subject: RE: [Mipshop] Question on uplink
packetindraft-yokota-mipshop-pfmipv6-00

	Hi Desire,

	Could you explain why you want the MN to wait? If you do wait,
could you explain why that would be a good *fast handover* design?

	-Rajeev

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Desire Oulai
	Sent: Wednesday, September 10, 2008 1:47 PM
	To: Basavaraj Patil; ext Ahmad Muhanna; Chowdhury, Kuntal;
[email-masked]
	Cc: [email-masked]
	Subject: Re: [Mipshop] Question on uplink
packetindraft-yokota-mipshop-pfmipv6-00

	Hi Raj and Kuntal,

	Desire

		Ahmad,
		
		At what layer the MN knows that it has switched links is
a relevant point. However MNs may hide link changes to upper layers
		
		-Raj

		On 9/10/08 3:28 PM, "ext Ahmad Muhanna"
<[email-masked]> wrote:

		Hi Kuntal,

		

		From: Chowdhury, Kuntal

		There are cases where  L2 attach during handover simply
means the MN got its radio link established  with the target radio
access system. The MN will be agnostic to the fact that  the new radio
access system is connected to a new MAG/AR. In this scenario,  the MN
will continue to send UL packets......

		I think the term L2  attach is very access technology
specific. There is no single interpretation  of this term.

		BR,
		
		Kuntal

		 

		

		

		Hi  Desire,

		

		
		Let me try to  understand what you just said. After the
link layer is established, the  Mobile node for sure it knows that it
has  handed over to a new link BUT can not be sure that this link does
support the  same HNP that was supported on the previous  link.

		 
		
		Also, since the UE  does not have a client MIP6 on it,
it will be best for the UE to wait until it  receives a RA to confirm
that it still on the same link and that link for sure  support the same
HNP.

		 

		

		
		Cheers!
		
		Regards,  
		Ahmad 

			 

			
			
packet in draft-yokota-mipshop-pfmipv6-00
			
			HI  Basavaraj,

			
			Desire

				
				
				From:  Basavaraj Patil

				Hi  Desire,

				-Basavaraj

				Hi  Hidetoshi, 

				
				
				BR  
				
				Desire  

				

	

		"This email message and any attachments are confidential
information of  Starent Networks, Corp. The information transmitted may
not be used to create  or change any contractual obligations of Starent
Networks, Corp. Any review,  retransmission, dissemination or other use
of, or taking of any action in  reliance upon this e-mail and its
attachments by persons or entities other  than the intended recipient is
prohibited. If you are not the intended  recipient, please notify the
sender immediately -- by replying to this message  or by sending an
email to [email-masked] -- and destroy all  copies of
this message and any attachments without reading or disclosing their
contents. Thank you."

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 10 Sep 2008 17:03:37 -0400

Hi Desire,

Could you explain why you want the MN to wait? If you do wait, could you
explain why that would be a good *fast handover* design?

-Rajeev

Hi Raj and Kuntal,

Desire

	Ahmad,

	-Raj

	Hi Kuntal,
	
	Sure, however, any solution that IETF is going to adopt for
PMIPv6 handover optimization need to take in consideration all different
type of access technologies and SDOs. NO? Otherwise, we are specifying
an SDO specific solution. The fact is that during HO, the MN MAY very
well know that it had moved to a new link and the MN is NOT sure if that
link support the same HNP that has been advertised on the previous link.

	Regards, 
	Ahmad 

	

	 

	There are cases where  L2 attach during handover simply means
the MN got its radio link established  with the target radio access
system. The MN will be agnostic to the fact that  the new radio access
system is connected to a new MAG/AR. In this scenario,  the MN will
continue to send UL packets......

	
	BR,
	
	Kuntal

	 

	

	

	Hi  Desire,

	

	

	 
	
	Also, since the UE  does not have a client MIP6 on it, it will
be best for the UE to wait until it  receives a RA to confirm that it
still on the same link and that link for sure  support the same HNP.

	 

	

	
	Cheers!
	
	Regards,  
	Ahmad 

		 

		

		HI  Basavaraj,

		  Maybe  I need some clarification here. My question is
to know if the MN will keep  sending packets with MN-HoA directly after
L2 attach? Or will it wait  to receive the HNP on the new link, figure
that the link "didn't change"  when receiving the HNP, then sends
packets using MN-HoA? If it is the second  option, the uplink packets
are forwarded directly via PMIP tunnel,  aren't they?

		Desire

			
			
			From:  Basavaraj Patil

			Hi  Desire,

			-Basavaraj

			Hi  Hidetoshi, 

			
			I have concerns  regarding the uplink packets.
In PMIP, before being able to use MN-HoA on  the N-MAG, the PBU/PBA
exchange must be completed. That means the PMIP  tunnel between LMA and
MAG is setup before advertising the HNP on the  link. In this case, the
uplink packets must be forwarded using PMIP tunnel  between NMAG and
LMA. Otherwise, you need to give more clarification on  the capability
to send packets before the PBU/PBA  completion.
			
			BR  
			
			Desire

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Wed, 10 Sep 2008 17:31:59 -0400

Hi,

[RKo:>] In other words, you agree that it is suboptimal to make the MN
wait. Yet you want the PFMIPv6 protocol to incorporate this behavior? 

If there are MN implementations that choose to wait for whatever
(seemingly questionable) reasons, they do not gain from the design of
PFMIP where we do support better performance for uplink packets. It does
not make sense to impose that restriction here and change a perfectly
good design into a poorer one. I do not agree.

Regards,

-Rajeev

BR

Desire

	Hi Desire,

	-Rajeev

	Hi Raj and Kuntal,

	Desire

		Ahmad,

		-Raj

		Hi Kuntal,

		

		From: Chowdhury, Kuntal

		

		BR,
		
		Kuntal

		 

		

		

		Hi  Desire,

		

		

		 

		

		

		 
		
		Cheers!
		
		Regards,  
		Ahmad 

			 

			

			HI  Basavaraj,

			
			Desire

				
				
				From:  Basavaraj Patil

				Hi  Desire,

				-Basavaraj

				Hi  Hidetoshi, 

				
				
				BR  
				
				Desire

---

From: Julien Laganier <[email-masked]>
Date: Thu, 11 Sep 2008 10:22:22 +0900

Folks,

I've reviewed the draft and this thread and I have the following input:

The draft specifies inclusion of the MN-HoA in FPMIPv6 signaling while 
in PMIPv6 the granularity of addressing is that of an IPv6 prefix. Thus 
I think the Home Network Prefix (HNP) rather than MN-HoA should be 
present in FPMIPv6 signaling (and the IPv4-MN-HoA if the networks 
support IPv4 mobile nodes.)

Regarding the MN pausing transmission of packets after an L2 handoff, 
when the L2 doesn't hide entirely the L2 handoff, we have to rely on 
IP-layer movement detection concluding that no IP-layer movement occured:

- For an IPv6 MN, if the HNP is transferred from the pMAG to the nMAG 
(in the HI for predictive mode, and in the HAck in reactive mode), the 
nMAG can then send an RA including the HNP to the MN as soon as the MN 
completes L2 attachment. As a result, the MN would immediately start to 
transmit uplink packets to the nMAG -- see draft-ietf-dna-simple-02.

- For an IPv4-only MN, it's not clear to me how that can be made to work 
since we don't have RAs. RFC4436/DNAv4 relies on unicast ARP probes sent 
to a previous router but it looks like none of the link layers supported 
by PMIPv6 will use ARP, and even if it did, trying to make DNAv4 
conclude that the IP link hasn't changed would imply that different nMAG 
and pMAG have the same link layer address.

Thoughts?

--julien

Koodli, Rajeev wrote:
> */[RKo:>] In other words, you agree that it is suboptimal to make the MN 
> wait. Yet you want the PFMIPv6 protocol to incorporate this behavior? /*
> 
> */If there are MN implementations that choose to wait for whatever 
> good design into a poorer one. I do not agree./*
> 
> */ /*
> 
> */Regards,/*
> 
> */ /*
> 
> */-Rajeev/*
> 
> */ /*
> 
>  
> 
> BR
> 
>  
> 
> Desire
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* Koodli, Rajeev [mailto:[email-masked]]
>     *Sent:* September 10, 2008 5:04 PM
>     *To:* Desire Oulai; Basavaraj Patil; ext Ahmad Muhanna; Chowdhury,
>     *Cc:* [email-masked]
>     *Subject:* RE: [Mipshop] Question on uplink
>     Could you explain why you want the MN to wait? If you do wait, could
>     you explain why that would be a good **fast handover** design?
> 
>      
> 
>     -Rajeev
> 
>      
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Desire Oulai
>     *Sent:* Wednesday, September 10, 2008 1:47 PM
>     *To:* Basavaraj Patil; ext Ahmad Muhanna; Chowdhury, Kuntal;
>     [email-masked]
>     *Cc:* [email-masked]
>     *Subject:* Re: [Mipshop] Question on uplink
>     implementation behaviour. This discussion should be considered for
>     this draft. On the other hand, the transient BCE approach of
>     ------------------------------------------------------------------------
> 
>     *From:* Basavaraj Patil [mailto:[email-masked]]
>     *Sent:* September 10, 2008 4:35 PM
>     *To:* ext Ahmad Muhanna; Chowdhury, Kuntal; Desire Oulai;
>     [email-masked]
>     *Cc:* [email-masked]
>     *Subject:* Re: [Mipshop] Question on uplink packetin
>         relevant point. However MNs may hide link changes to upper
>         layers especially in the context of handovers between networks
>         where PMIP6 is being used in both. It is an implementation
>         issue. If you think of a scenario where the MN is on a shared
>         link where multiple routers exist, the MN may receive an RA from
>         another router on that link. Does that mean the previous router
>         to which the MN was attached is no longer available? The MN will
>         need to do NUD to determine that it has lost connectivity to the
>         previous router. Just because a new link comes up does not
>         automatically imply that the MN has lost connectivity with the
>         PMIPv6 handover optimization need to take in consideration all
>         different type of access technologies and SDOs. NO? Otherwise,
>         we are specifying an SDO specific solution. The fact is that
>         during HO, the MN MAY very well know that it had moved to a new
>         link and the MN is NOT sure if that link support the same HNP
>         ------------------------------------------------------------------------
> 
>         *From:* Chowdhury, Kuntal  [mailto:[email-masked]]
>         *Sent:* Wednesday, September  10, 2008 3:16 PM
>         *To:* Muhanna, Ahmad (RICH1:2H10); Desire Oulai;  Basavaraj
>         Patil; [email-masked]
>         *Cc:*  [email-masked]
>         *Subject:* RE: [Mipshop] Question on uplink packetin
>         the MN got its radio link established  with the target radio
>         access system. The MN will be agnostic to the fact that  the new
>         radio access system is connected to a new MAG/AR. In this
>         scenario,  the MN will continue to send UL packets……
> 
> 
> 
>         ------------------------------------------------------------------------
> 
> 
> 
>         *From:*  [email-masked]
>         [mailto:[email-masked]] *On Behalf Of *Ahmad Muhanna
>         *Sent:* Wednesday, September 10, 2008 3:05  PM
>         *To:* Desire Oulai;  Basavaraj Patil; [email-masked]
>         *Cc:* [email-masked]
>         *Subject:* Re: [Mipshop] Question on uplink  packetin
>         layer is established, the  Mobile node for sure it knows that it
>         has  handed over to a new link BUT can not be sure that this
>         link does support the  same HNP that was supported on the
>         previous  link.
> 
>          
> 
> 
> 
>          
> 
>         be best for the UE to wait until it  receives a RA to confirm
>         that it still on the same link and that link for sure  support
>         the same HNP.
> 
>          
> 
> 
> 
>          
> 
>             ------------------------------------------------------------------------
> 
> 
> 
>             *From:*  [email-masked]
>             [mailto:[email-masked]] *On Behalf Of *Desire Oulai
>             *Sent:* Wednesday, September 10, 2008  2:54 PM
>             *To:* Basavaraj  Patil; [email-masked]
>             *Cc:* [email-masked]
>             *Subject:* Re: [Mipshop] Question on  uplink packet in
>               Maybe  I need some clarification here. My question is to
>             know if the MN will keep  sending packets with MN-HoA
>             directly after L2 attach? Or will it wait  to receive the
>             HNP on the new link, figure that the link "didn't change"
>              when receiving the HNP, then sends packets using MN-HoA? If
>             it is the second  option, the uplink packets are forwarded
>             directly via PMIP tunnel,  aren't they?
> 
> 
> 
>             Desire
> 
>                  
> 
>                  
> 
>                 ------------------------------------------------------------------------
> 
> 
> 
>                 *From:*  Basavaraj Patil [mailto:[email-masked]]
>                 *Sent:* September 10, 2008 3:45  PM
>                 *To:* Desire Oulai;  [email-masked]
>                 *Cc:*  [email-masked]
>                 *Subject:*  Re: [Mipshop] Question on uplink packet in
>                 which has the BCE for the CoA of the pMAG and  hence
>                 processes the packets.
>                 before being able to use MN-HoA on  the N-MAG, the
>                 PBU/PBA exchange must be completed. That means the PMIP
>                  tunnel between LMA and MAG is setup before advertising
>                 the HNP on the  link. In this case, the uplink packets
>                 must be forwarded using PMIP tunnel  between NMAG and
>                 LMA. Otherwise, you need to give more clarification on
>                  the capability to send packets before the PBU/PBA
>                  completion.
> 
>                 BR  
> 
>                 Desire  
>                  
>                  
>                  
> 
>                  
> 
>                 ------------------------------------------------------------------------
> 
> 
> 
>         information of  Starent Networks, Corp. The information
>         obligations of Starent Networks, Corp. Any review,
>          retransmission, dissemination or other use of, or taking of any
>         action in  reliance upon this e-mail and its attachments by
>         persons or entities other  than the intended recipient is
>         prohibited. If you are not the intended  recipient, please
>         notify the sender immediately -- by replying to this message  or
>         by sending an email to [email-masked] -- and
>         destroy all  copies of this message and any attachments without
>         reading or disclosing their  contents. Thank you."
> 
>          
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 10 Sep 2008 23:49:39 -0500

Hi Julien,
 
> The draft specifies inclusion of the MN-HoA in FPMIPv6 
> signaling while in PMIPv6 the granularity of addressing is 
> that of an IPv6 prefix. Thus I think the Home Network Prefix 
> (HNP) rather than MN-HoA should be present in FPMIPv6 
> signaling (and the IPv4-MN-HoA if the networks support IPv4 
> mobile nodes.)
> 
> Regarding the MN pausing transmission of packets after an L2 
> handoff, when the L2 doesn't hide entirely the L2 handoff, we 
> have to rely on IP-layer movement detection concluding that 
> no IP-layer movement occured:
> 
> - For an IPv6 MN, if the HNP is transferred from the pMAG to 
> the nMAG (in the HI for predictive mode, and in the HAck in 
> reactive mode), the nMAG can then send an RA including the 
> HNP to the MN as soon as the MN completes L2 attachment.
 
[Ahmad]
I basically read your comment inline with the need for some
pre-registration mechanism to make sure that the MAG exchange PBU/PBA
with the LMA to ensure successful registration of the HNP before sending
the RA message. 

Regards,
Ahmad

> As a 
> result, the MN would immediately start to transmit uplink 
> packets to the nMAG -- see draft-ietf-dna-simple-02.
> 
> - For an IPv4-only MN, it's not clear to me how that can be 
> made to work since we don't have RAs. RFC4436/DNAv4 relies on 
> unicast ARP probes sent to a previous router but it looks 
> like none of the link layers supported by PMIPv6 will use 
> ARP, and even if it did, trying to make DNAv4 conclude that 
> the IP link hasn't changed would imply that different nMAG 
> > change. I don't necessarily think this is a good behaviour, but the 
> > fast handover design should consider that.
> > 
> >  
> > 
> > */[RKo:>] In other words, you agree that it is suboptimal 
> to make the 
> > MN wait. Yet you want the PFMIPv6 protocol to incorporate this 
> > behavior? /*
> > 
> > PFMIP where we do support better performance for uplink packets. It 
> > does not make sense to impose that restriction here and change a 
> > perfectly good design into a poorer one. I do not agree./*
> > 
> > */ /*
> > 
> > */Regards,/*
> > 
> > */ /*
> > 
> > */-Rajeev/*
> > 
> > */ /*
> > 
> >  
> > 
> > BR
> > 
> >  
> > 
> > Desire
> > 
> >      
> > 
> >     
> > 
> simply means
> >         scenario,  the MN will continue to send UL packets......
> > 
> > 
> > 
> technology specific.
> question is to
> packets to the LMA
> packets. In PMIP,

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 11 Sep 2008 16:13:38 +0900

Hi Desire,

> handover design should consider that.

Let me summarize your concern and the situations we need to consider:

1) If the link change is completely hidden from the MN, it will start
sending UL packets immediately after the L2 attachment. The MN doesn't
know or care if this is a handover or temporally wireless link
unavailability (the network knows it, of course). PFMIPv6 handles this
situation well by forwarding the UL packets to the pMAG before the PMIP
tunnel establishment between the nMAG and LMA.

2) If the MN is aware of the link change and performs NUD, the nMAG can
successfully respond to it since it knows that the MN is coming in
advance by the HI/HAck (in the proactive mode). The MN is rest assured
that he can send the UL packets, which are then forwarded to the pMAG
until the PMIP tunnel is established between the nMAG and LMA.

3) If the MN is aware of the link change and waits until it receives the
RA, the nMAG can promptly send it with the MN-HoA, which is transferred
from the pMAG before establishing the PMIP tunnel between the nMAG and
LMA. The UL packets will be forwarded to the pMAG until the PMIP tunnel
is established.

4) If the MN is aware of the link change and the nMAG is configured not
to send the RA until it establishes the PMIP tunnel with the LMA, then
the MN will not send the UL packets until it receives the RA. In this
case, the UL packets will not be forwarded to the pMAG since the PMIP
tunnel has been established. From the perspective of PFMIPv6, this is
still ok. The bi-directional tunnel between the MAGs is not just used in
the UL direction.

In a nutshell, PFMIPv6 covers all cases. Is it ok if we clarify this in
the draft?

Regards,
-- 
Hidetoshi

---

From: Hidetoshi Yokota <[email-masked]>
Date: Thu, 11 Sep 2008 16:22:39 +0900

Hi Desire,

> RA, the nMAG can promptly send it with the MN-HoA, which is transferred

This should be HNP not MN-HoA. Sorry.

Regards,
-- 
Hidetoshi

---

From: Julien Laganier <[email-masked]>
Date: Thu, 11 Sep 2008 21:08:44 +0900

Hello Ahmad,

> with the LMA to ensure successful registration of the HNP before sending

Hmm...

The nMAG could opportunistically assume that the PBU will be accepted by 
the LMA (and maybe I'm assuming that should be the case in correct 
deployments) and send the RA with a PIO containing the HNP and validity 
and preferred lifetime of zero resulting in the address(es) formed from 
the HNP being marked as deprecated.

In case the PBAck confirms registration everything is fine and another 
RA can be sent with a PIO containing the HNP and validity lifetime and 
preferred lifetime configured by the administrator, thus making 
addresses formed from the HNP preferred.

If that's not the case:

- the PBAck indicates an error then the nMAG could advertize the local 
prefix(es) to the MN

- the PBAck contains a different HNP that what was received from HI/HAck 
and sent in RA

Then the MAG send another RA with that prefix and validty and preferred 
lifetime configured by the administrator, thus making these addresses 
the preferred ones.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 11 Sep 2008 09:53:59 -0500

Hello Julien,

I believe we went through this exercise before during the course of base
PMIPv6 standardization. If I remember correctly, the detailed scenario
you presented was also discussed. However, it was decided for many
reasons that RA needs to be sent after a successful PBU/PBA exchange. On
the other hand, we need to take in consideration that what we have is an
active handoff.

At any rate, in case the nMAG sends a RA without a successful PBU/PBA,
Do you agree that is a change from base PMIPv6 protocol?

Cheers!

Regards,
Ahmad

> -----Original Message-----
> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Thursday, September 11, 2008 7:09 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: Koodli, Rajeev; Desire Oulai; Basavaraj Patil; Chowdhury, 
> Kuntal; [email-masked]; [email-masked]
> >> The draft specifies inclusion of the MN-HoA in FPMIPv6 signaling 
> >> while in PMIPv6 the granularity of addressing is that of an IPv6 
> >> prefix. Thus I think the Home Network Prefix
> signaling (and 
> >> the IPv4-MN-HoA if the networks support IPv4 mobile nodes.)
> >>
> >> (in the HI for predictive mode, and in the HAck in reactive mode), 
> >> the nMAG can then send an RA including the HNP to the MN 
> as soon as 
> >> the MN completes L2 attachment.
> >  
> > [Ahmad]
> > with the LMA to ensure successful registration of the HNP before 
> > sending the RA message.
> 
> Hmm...
> 
> The nMAG could opportunistically assume that the PBU will be 
> accepted by the LMA (and maybe I'm assuming that should be 
> the case in correct
> deployments) and send the RA with a PIO containing the HNP 
> and validity and preferred lifetime of zero resulting in the 
> address(es) formed from the HNP being marked as deprecated.
> 
> In case the PBAck confirms registration everything is fine 
> and another RA can be sent with a PIO containing the HNP and 
> validity lifetime and preferred lifetime configured by the 
> administrator, thus making addresses formed from the HNP preferred.
> 
> If that's not the case:
> 
> - the PBAck contains a different HNP that what was received 
> from HI/HAck and sent in RA
> 
> Then the MAG send another RA with that prefix and validty and 
> preferred lifetime configured by the administrator, thus 
> making these addresses the preferred ones.
> 
> --julien
>

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Thu, 11 Sep 2008 12:56:27 -0400

Hi Julien,

> support IPv4 mobile nodes.)

[RKo:>] Yes. I had revised the ID with this just before the Dublin
meeting. This will be clear once we submit it the 00 version.

> IP-layer movement detection concluding that no IP-layer movement
occured:

[RKo:>] I would say that the MN behavior should be unchanged from a
"normal" IPv6 behavior. 

> transmit uplink packets to the nMAG -- see draft-ietf-dna-simple-02.
[RKo:>] This (nMAG supplying the HNP) is possible, although it has not
been our intent here. It is used by nMAG to perform PMIP registration. 

The general design principle of FMIP is that protocol operations of
co-existing protocols should be kept separate; we may enable something
but not actually perform operations that would otherwise be done by a
different protocol. This allows some predictable behavior for each
protocol even when they co-exist (and hopefully assist each other), and
vastly simplifies implementation. 

> and pMAG have the same link layer address.
[RKo:>] Is this specific to PFMIP? How is it done in IPv4 support for
PMIPv6? (The same comment as above for co-existence here as well)

Thanks for your input.

-Rajeev

> > change. I don't necessarily think this is a good behaviour, but the
fast
> > PFMIP where we do support better performance for uplink packets. It
does
> > good design into a poorer one. I do not agree./*
--------------------------------------------------------------------
> ----
could
> >     you explain why that would be a good **fast handover** design?
--------------------------------------------------------------------
> ----
[mailto:[email-masked]]
> >     interesting way to optimize the handover.
--------------------------------------------------------------------
> ----
<[email-masked]>
> >         that has been advertised on the previous link.
----------------------------------------------------------------
> --------
means
> >         I think the term L2  attach is very access technology
specific.
> >         There is no single interpretation  of this term.
----------------------------------------------------------------
> --------
will
> >         Is my understanding  of your question correct?
------------------------------------------------------------
> ------------
to
> >             directly via PMIP tunnel,  aren't they?
--------------------------------------------------------
> ----------------
completing
> >                  established  in step (d).  The PAR then
decapsulates
> >                 I have concerns  regarding the uplink packets. In
PMIP,
> >                  the capability to send packets before the PBU/PBA
--------------------------------------------------------
> ----------------

---

From: Julien Laganier <[email-masked]>
Date: Fri, 12 Sep 2008 20:19:06 +0900

Hello Ahmad,

> Do you agree that is a change from base PMIPv6 protocol?

My (probably controversial) view is that when and how to send RA doesn't
belong to the base PMIPv6 protocol that runs between MAG and LMA (which
is incidentally the reason the NETLMM WG had an *informational* MN-AR
interface document, but I'm digressing probably :)

Thus my opinion is that sending a RA, etc. is not a change from base
PMIPv6 protocol.

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 12 Sep 2008 08:24:31 -0500

Hello Julien,

> My (probably controversial) view is that when and how to send RA 
> doesn't belong to the base PMIPv6 protocol that runs between MAG and 
> LMA (which is incidentally the reason the NETLMM WG had an 
> *informational* MN-AR interface document, but I'm digressing probably 
> :)

[Ahmad]
In general I agree that sending RA does not belong to PMIPv6 base
protocol. However, we are talking about the specifics related to sending
the RA with the HNP included as defined in PMIPv6 base protocol. Is that
a little better description? :)

Also, the MN-AR document is expired and seems in its way out and if that
is the case, then what else other than PMIPv6 base protocol document to
be referenced when RA contains a HNP?

Cheers!

Regards,
Ahmad

---

From: Julien Laganier <[email-masked]>
Date: Fri, 12 Sep 2008 23:40:48 +0900

Hello Ahmad,

Ahmad Muhanna wrote:
>> My (probably controversial) view is that when and how to send 
>> RA doesn't belong to the base PMIPv6 protocol that runs 
>> between MAG and LMA (which is incidentally the reason the 
>> NETLMM WG had an *informational* MN-AR interface document, 
>> but I'm digressing probably :)
> 
> [Ahmad]
> :)

Yes, and I think that's orthogonal to the PMIPv6 protocol. PMIPv6 does
network based mobility signaling. When and how to send RA is something
different.

To start with, there are some situations where the nMAG might well never
send any RA at all after handover (e.g. L2 handoff is hidden by the
system, or untrusted non-3GPP accesses where the link between the MN and 
the MAG is an IPsec tunnel, and MN address configuration is done with 
IKE configuration payloads).

> be referenced when RA contains a HNP?

I think it belongs to system architectures specification or to
deployments. The Router Discovery is another protocol and thus the 
NETLMM spec should only tell how the MAG gets the MN's HNP - when the 
RAs are fired is a different story IMHO.

Cheers,

--julien

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 12 Sep 2008 13:13:50 -0500

Hi Hidetoshi,

Please allow me to comment on the cases that you are proposing.

I believe capturing something on those lines is quite a very good idea.
However, I see we can capture the intention probably in three bullets.
Let me try to list those scenarios and please let me know what you
think.

1. No. 1 is as your No. 1, But probably more investigation is needed to
make sure that all cases are addressed by this point, which I am not
sure about. E.g., inter-technology handoff using the same interface,
intra-technology, etc.

2. If when the MAG receives a RS or after the link is up, the MAG has
already successfully exchanged the PBU/PBA with the LMA, the MAG can
immediately send the RA with the HNP included. The mechanism for
allowing the nMAG to register the target pCoA with the LMA while the LMA
continue to maintain a binding for the same HNP to the previous pCoA is
out-of-scope of this document.

3. If the MAG is configured to send the RA before successfully exchange
PBU/PBA with the LMA, then the MAG sends the RA immediately after the
link is up or whenever receiving an RS before exchanging the PBU/PBA
with the LMA. In this case, the target MAG uses the inter-MAG tunnel to
forward uplink traffic to the LMA through the previous MAG.

Best Regards,
Ahmad

> 1) If the link change is completely hidden from the MN, it 
> will start sending UL packets immediately after the L2 
> attachment. The MN doesn't know or care if this is a handover 
> or temporally wireless link unavailability (the network knows 
> it, of course). PFMIPv6 handles this situation well by 
> forwarding the UL packets to the pMAG before the PMIP tunnel 
> establishment between the nMAG and LMA.
> 
> 2) If the MN is aware of the link change and performs NUD, 
> the nMAG can successfully respond to it since it knows that 
> the MN is coming in advance by the HI/HAck (in the proactive 
> mode). The MN is rest assured that he can send the UL 
> packets, which are then forwarded to the pMAG until the PMIP 
> tunnel is established between the nMAG and LMA.
> 
> 3) If the MN is aware of the link change and waits until it 
> receives the RA, the nMAG can promptly send it with the 
> MN-HoA, which is transferred from the pMAG before 
> establishing the PMIP tunnel between the nMAG and LMA. The UL 
> packets will be forwarded to the pMAG until the PMIP tunnel 
> is established.
> 
> 4) If the MN is aware of the link change and the nMAG is 
> configured not to send the RA until it establishes the PMIP 
> tunnel with the LMA, then the MN will not send the UL packets 
> until it receives the RA. In this case, the UL packets will 
> not be forwarded to the pMAG since the PMIP tunnel has been 
> established. From the perspective of PFMIPv6, this is still 
> ok. The bi-directional tunnel between the MAGs is not just 
> used in the UL direction.
> 
> In a nutshell, PFMIPv6 covers all cases. Is it ok if we 
> clarify this in the draft?
> 
> Regards,
> --
> Hidetoshi
> 
> > BR
> >  
> > Desire
> > 
> >

---

From: "Desire Oulai" <[email-masked]>
Date: Fri, 12 Sep 2008 16:04:37 -0400

Hi Hidetoshi,

  I think your analysis is interesting in many points. Authors needs to
update the draft at least to point out the different cases and the PFMIP
beehaviour related to each case. In the 4th bullet, only the downlink
packets delivery will be optimized, not the uplink.

Cheers

Desire

> From: Hidetoshi Yokota [mailto:[email-masked]] 
> Sent: September 11, 2008 3:14 AM
> To: Desire Oulai
> Cc: Koodli, Rajeev; Basavaraj Patil; ext Ahmad Muhanna; 
> Chowdhury, Kuntal; [email-masked]

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 12 Sep 2008 16:26:45 -0500

Hello Julien,

> > protocol. However, we are talking about the specifics related to 
> > sending the RA with the HNP included as defined in PMIPv6 base 
> > protocol. Is that a little better description? :)
> 
> Yes, and I think that's orthogonal to the PMIPv6 protocol. 
> PMIPv6 does network based mobility signaling. When and how to 
> send RA is something different.
> 
> To start with, there are some situations where the nMAG might 
> well never send any RA at all after handover (e.g. L2 handoff 
> is hidden by the system, or untrusted non-3GPP accesses where 
> the link between the MN and the MAG is an IPsec tunnel, and 
> MN address configuration is done with IKE configuration payloads).

[Ahmad]
Sure.
> 
> > Also, the MN-AR document is expired and seems in its way out and if 
> > that is the case, then what else other than PMIPv6 base protocol 
> > document to be referenced when RA contains a HNP?
> 
> I think it belongs to system architectures specification or 
> to deployments. The Router Discovery is another protocol and 
> thus the NETLMM spec should only tell how the MAG gets the 
> MN's HNP - when the RAs are fired is a different story IMHO.

[Ahmad]
Conceptually, I kind of agree with what you just said about the system
architecture. On the other hand, the fact is: this special RA contains
the "HNP" which is not a regular locally advertised Prefix. It is very
reasonable for PMIPv6 protocol to specify the requirement or the
perquisites' for advertising such prefix. Otherwise, it may not become
routable.

I am glad that you described your proposed scenario as "controversial"
:)

Have a great weekend!

Regards,
Ahmad

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 17 Sep 2008 14:16:57 +0900

Hi Ahmad,

> sure about. E.g., inter-technology handoff using the same interface,

In the case of a handover with the same interface, I think the situation
will be easier than that of a handover with multiple interfaces. There
is no ambiguity about which interface will be used after the handover.

> out-of-scope of this document.

The assumption I made in this case was the proactive mode, which I wrote
in parenthesis, so the inter-MAG tunnel should be established before the
PBU/PBA exchange. In the case of the reactive mode, the PBU/PBA could be
made possible to be exchanged before the HI/HAck exchange; however, it
will be more beneficial if the inter-MAG tunning can be established as
soon as possible, whereby the packets left the LMA toward the pMAG can
also be saved.

> forward uplink traffic to the LMA through the previous MAG.

That's right. If the MN requires the RA on the new link and someone
wants to make the better of PFMIPv6, this is the way to go, I think.

Regards,
-- 
Hidetoshi

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 17 Sep 2008 14:40:48 +0900

Hi Desire,

> packets delivery will be optimized, not the uplink.

Thanks for your understanding, but I'm just wondering why those who want
to minimize the handover delay and packet loss would select the 4th
option... I tried to list up all possible cases to show PFMIPv6 doesn't
cause any inconvenience, but this doesn't mean that I recommend all of
them. I think the draft should focus on how to achieve the fast handover
by all means. If there is a special reason to delay the RA, we will
think about it, though.

Regards,
-- 
Hidetoshi