Subject: Re: [netlmm] The way forward as discussed during the WG meeting

From: Christian Vogt <[email-masked]>
Date: Fri, 25 Apr 2008 18:12:22 +0300

I am also interested in P-MIPv6 support for cross-interface
handovers and simultaneous multi-access.

- Christian

On Mar 19, 2008, at 1:23, Vijay Devarapalli wrote:

> I agree on this restricted scope. I am mainly interested in
> specifying how a mobile can use multiple interfaces
> simultaneously when it attaches to a PMIPv6 domain and how
> handovers across interfaces can be supported using PMIPv6.
>
> Vijay

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

---

From: Frank Xia <[email-masked]>
Date: Fri, 25 Apr 2008 10:38:14 -0500

Me too.

BR
Frank
  ----- Original Message ----- 
  From: Christian Vogt 
  To: NETLMM Mailing List 
  Cc: Vijay Devarapalli 
  Sent: Friday, April 25, 2008 10:12 AM
  Subject: Re: [netlmm] The way forward as discussed during the WG meeting

  - Christian

---

From: "Hui Deng" <[email-masked]>
Date: Sat, 26 Apr 2008 08:55:42 +0800

some operator like us need this scenario,
so I am also interested in this.

-Hui

---

From: "Ali Irfan-FIA225" <[email-masked]>
Date: Sat, 26 Apr 2008 11:20:32 +0100

I have the following comment on the logic for LMA, especially section
5.4.1.3 in the draft.
 
In LTE system, a MN may have one or more interfaces connected through
MAG to LMA. So correspondingly one or more BCE entries will be present
in LMA.
 
During inter-MAG HO, the target-MAG will in general not know either the
HNP(s) or the MN_LL_ID(s), and hence will set the HNP value to zero and
not include the MN_LL_ID field.
 
So the corresponding logic for lookup of BCE in the LMA is the one is
section 5.4.1.3 (HNP =0, No MN_LL_ID present). The PBU(MN_ID, HNP = 0,
HI = 3, no MN_LL_ID). The desired behavior at the LMA should be to
update the existing BCE(s) and also the LMA-MAG tunnel for the MN_ID
with the new MAG address.
 
Let us consider two cases: 
 
Case-1: only one interface per MN. Hence only one BCE in LMA for the
same MN_ID. So step 1 is met (one and only one BCE for the MN_ID).
However, neither steps 2 (HI == 2) or 3 (HI == 4) are met. Hence, Step 4
ends up creating a new BCE for the MN_ID, which is not the intent of the
PBU.
 
Case-2: more than one interface per MN connected to LMA (through MAG).
Hence, there are more than one BCE in LMA for the same MN_ID. Hence
step-1 (and also step-2 and step-3) which are a follow through for
step-1 are not met. Hence Step-4 ends up creating a new BCE for the
MN_ID, which is not the intent of the PBU.
 
I must have missed something basic here. But I have looked at this logic
for about two hours now and have not figured out what. 
 
Appreciate help.
 
Rgds
Irfan

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 26 Apr 2008 10:21:14 -0700 (PDT)

Hi Irfan,

There is just one requirement here, the MAG should have the ability
to identify a session that is being handed off and should convey
the same to the LMA. If HNP is O::0, MN-LL-Identifier is not present,
but the handoff hint suggests that its a handoff. There should be
some way for the LMA to identify the corresponding session and update
it. At this point, it can just apply heuristics and apply the check
for 1 BCE session and update it. Otherwise, the LMA has to create a
new session. Remember the multi-homing discussions and the focus on
not accidentally assigning the same prefix to two interfaces of the
mobile and resulting saga (offcourse I dont agree, but thats the
consensus to eliminate that possibility).

I realize that LTE terminals have no link-layer identifier, but I
assume atleast there is some inter-MAG CT and that should be used
to convey the prefix information. Or, should find ways to generate
link-layer identifiers for each of the connected radios. Without
this, there is no way we can magically identify the session. Given
the parameters and constraints, tell me, how we can identify the
session that is being handed off ? I can argue, if the MAG is able
to speicify HI=3, why cant it not know the other session params ?
How would it know, its a handoff and not a new attachment ?

Regards
Sri

---

From: "Ali Irfan-FIA225" <[email-masked]>
Date: Mon, 28 Apr 2008 09:02:13 +0100

Hi Sri,

Appreciate your detailed comments.  Few comments inline.

> There is just one requirement here, the MAG should have the 
> ability to identify a session that is being handed off and 
> should convey the same to the LMA. If HNP is O::0, 
> MN-LL-Identifier is not present, but the handoff hint 
> suggests that its a handoff. There should be some way for the 
> LMA to identify the corresponding session and update it. At 
> this point, it can just apply heuristics and apply the check 
> for 1 BCE session and update it. Otherwise, the LMA has to 
> create a new session. .

However, the logic in 5.4.1.3 should allow for this case, but it does
not currently. If we take the trivial case of 1 BCE and the MAG
providing HI=3, should be sufficient condition for the LMA to update the
existing BCE. Sorry, I have not followed in detail the multihoming
debate. There are stringent conditions on MAG on setting HI=3. The draft
is allowing for the LMA to search for BCE based on just the MN_ID.  If
that is true and there is only one BCE for the MN_ID and HI=3, then the
BCE is uniquely identified in the LMA and the PBU should be taken as a
request to updated the existing BCE and not create a new BCE. Hence,
this should be put in as a requirement into the logic. Currently, the
logic in 5.4.1.3 is ruling this out, since step 4 has a MUST in that
statement.

...

> I realize that LTE terminals have no link-layer identifier, 
> but I assume atleast there is some inter-MAG CT and that 
> should be used to convey the prefix information. Or, should 
> find ways to generate link-layer identifiers for each of the 
> connected radios. Without this, there is no way we can 
> magically identify the session. Given the parameters and 
> constraints, tell me, how we can identify the session that is 
> being handed off ? I can argue, if the MAG is able to 
> speicify HI=3, why cant it not know the other session params ?

In LTE there is context transfer between MAGs, but it is through the
control-plane entity (MME). The MN does not "talk" directly with the MAG
in the CP. Another requirement that has been built into LTE is to handle
"split terminals", where the LTE modem is separated from the "host"
IP-stack, the modem provides the layer-2 connectivity and the host
provides layer-3. The specification allows the host to obtain an address
directly from the MAG (the address is actually provided by the LMA with
the MAG acting as a relay), after the layer-2 has been setup. So far,
there the specification has not required the MME to store the HNP
allocated to the UE. Hence, when HO occurs the target-MAG does not get
the HNP from the MME. Also, as you correcly noted the UE is not sending
a LL-identifier. Also, the specification allows for MN to get multiple
addresseses/HNP (operator requirement, don't ask ;-)). There is also
another requirement to support inter-technology handoff, in which case
two separate modems may be used to access the two technologies and
during HO the MN may not provided its HNP to the target system (or the
target system will not trust the IP address provided by the UE).

So how do we solve this problem. If we require that the MAG provide the
HNP(s) allocated to the MN to the MME, then this can solve the intra-LTE
HO issue, with the MME forwarding the HNP to the target-MAG. However,
this will not solve the inter-technology HO scenario, where even if the
UE provides HNP, the network may not accept it. However, I am not sure
if "trust" is an issue, since the HNP is only accepted for a HO
situation and the LMA will check if the HNP is already allocated to the
UE. So this is a possible solution, HNP provided by MAG to MME and UE
provides HNP to MME when it is performing inter-technology HO.

The other possibility is to use LL-identifier. This causes the problem
of how the UE can provide the same LL identifier during inter-technology
HO, when two different modems are used? The MME can create a
LL-identifier for the UE (called "default bearer id") and provide that
to the MAG, but such a solution will not work for inter-technology HO. 

From the specification, I do see that LL-identifier is allowed to change
on inter-technology HO (5.4.1.1 step 4, bullet 2). So the following
maybe the best solution:

1. When UE does inter-tech HO, the UE provides HNP to MME, otherwise
not.
2. In an "initial attach" (as opposed to HO attach), the MME only
provides LL-identifier (newly created default bearer identity) to the
MAG. The MAG will sends MN_ID, HNP (0::0) LL-identifier and HI = 1 to
the LMA and gets back HNP in PBA. In a "handover attach" the UE provides
HNP to MME. The MME provides HNP and LL-identifier to the MAG. The MAG
provides HNP, LL-identifier and HI=2 in PBU to LMA. The LMA checks that
the HNP and MN-ID match (check to make sure the UE is not lying) and if
they do sends a PBA to the MAG. The HNP is not stored in the MME (as
currently specified).

3. During intra-LTE HO, the target MAG only provides MN-ID and
LL-identity, HI= 3 (and ATT also) in PBU. The LMA finds the BCE (unique)
based on MN-ID, ATT, LL-identity (section 5.4.1.2) and updates the BCE.

Appreciate comments on the above approach. 

Regards
Irfan

---

From: "BLUME, Oliver" <[email-masked]>
Date: Mon, 28 Apr 2008 11:40:22 +0200

Hi Irfan,

what you are proposing to me basically looks like a  means to enable the MAG to discriminate between an initial attach (requiring a new HNP) or an HO attach. Putting this into MME signalling to the MAG is a valid approach, but note that it is an LTE specific approach shifting the difficulties from MAG to MME. How about the HO back from LTE to another technology? Or how about HO between two non-3GPP technologies?

For a general solution, all MAGs (not only MAGs in 3GPP networks) would be required to set the HI indicator to 2 or 3 during HO. It requires that the target interface technology specifies a means for the mobile terminal (or the network during context transfer) to indicate the attach reason during attachment. Only if this requirement is met (in a way specific for each interface technology and within the scope of the according standardisation body) PMIP can supply a smooth handover and provide the same HNP in the target interface. 

Would such a requirement be acceptable for PMIP? IMHO, this would not mean outside interference into other standardisations but simply would mean, without such amendment no HO with session continuty would be granted in PMIP domains, but instead HI=5 would have to be assumed and a new HNP would be assigned. 

Regards,

Oliver

********************************************************************************************************
Dr.-Ing. Oliver Blume
Alcatel-Lucent Deutschland AG
Bell Labs ZFZ/RA1
Radio Access, Department for System Optimisations 
Holderäckerstr. 35
D-70499 Stuttgart
Phone:  ++49-711-821-47177
Fax  :              -32185
Email:  [email-masked]   

Sitz der Gesellschaft: Stuttgart.   Amtsgericht: Stuttgart HRB 4026
Vorsitzender des Aufsichtsrats: Michael Oppenhoff
Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger, Alf Henryk Wulf
*********************************************************************************************************

-----Ursprüngliche Nachricht-----
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Ali Irfan-FIA225
Gesendet: Montag, 28. April 2008 10:02
An: Sri Gundavelli
Cc: NETLMM Mailing List
Betreff: Re: [netlmm] LMA logic in draft-ietf-netlmm-proxymip6-12.txt

Hi Sri,

> There is just one requirement here, the MAG should have the ability to 
> identify a session that is being handed off and should convey the same 
> to the LMA. If HNP is O::0, MN-LL-Identifier is not present, but the 
> handoff hint suggests that its a handoff. There should be some way for 
> the LMA to identify the corresponding session and update it. At this 
> point, it can just apply heuristics and apply the check for 1 BCE 
> session and update it. Otherwise, the LMA has to create a new session. 
> .

However, the logic in 5.4.1.3 should allow for this case, but it does not currently. If we take the trivial case of 1 BCE and the MAG providing HI=3, should be sufficient condition for the LMA to update the existing BCE. Sorry, I have not followed in detail the multihoming debate. There are stringent conditions on MAG on setting HI=3. The draft is allowing for the LMA to search for BCE based on just the MN_ID.  If that is true and there is only one BCE for the MN_ID and HI=3, then the BCE is uniquely identified in the LMA and the PBU should be taken as a request to updated the existing BCE and not create a new BCE. Hence, this should be put in as a requirement into the logic. Currently, the logic in 5.4.1.3 is ruling this out, since step 4 has a MUST in that statement.

...

> assume atleast there is some inter-MAG CT and that should be used to 
> convey the prefix information. Or, should find ways to generate 
> link-layer identifiers for each of the connected radios. Without this, 
> there is no way we can magically identify the session. Given the 
> parameters and constraints, tell me, how we can identify the session 
> that is being handed off ? I can argue, if the MAG is able to speicify 
> HI=3, why cant it not know the other session params ?

In LTE there is context transfer between MAGs, but it is through the control-plane entity (MME). The MN does not "talk" directly with the MAG in the CP. Another requirement that has been built into LTE is to handle "split terminals", where the LTE modem is separated from the "host"
IP-stack, the modem provides the layer-2 connectivity and the host provides layer-3. The specification allows the host to obtain an address directly from the MAG (the address is actually provided by the LMA with the MAG acting as a relay), after the layer-2 has been setup. So far, there the specification has not required the MME to store the HNP allocated to the UE. Hence, when HO occurs the target-MAG does not get the HNP from the MME. Also, as you correcly noted the UE is not sending a LL-identifier. Also, the specification allows for MN to get multiple addresseses/HNP (operator requirement, don't ask ;-)). There is also another requirement to support inter-technology handoff, in which case two separate modems may be used to access the two technologies and during HO the MN may not provided its HNP to the target system (or the target system will not trust the IP address provided by the UE).

So how do we solve this problem. If we require that the MAG provide the
HNP(s) allocated to the MN to the MME, then this can solve the intra-LTE HO issue, with the MME forwarding the HNP to the target-MAG. However, this will not solve the inter-technology HO scenario, where even if the UE provides HNP, the network may not accept it. However, I am not sure if "trust" is an issue, since the HNP is only accepted for a HO situation and the LMA will check if the HNP is already allocated to the UE. So this is a possible solution, HNP provided by MAG to MME and UE provides HNP to MME when it is performing inter-technology HO.

The other possibility is to use LL-identifier. This causes the problem of how the UE can provide the same LL identifier during inter-technology HO, when two different modems are used? The MME can create a LL-identifier for the UE (called "default bearer id") and provide that to the MAG, but such a solution will not work for inter-technology HO. 

From the specification, I do see that LL-identifier is allowed to change on inter-technology HO (5.4.1.1 step 4, bullet 2). So the following maybe the best solution:

1. When UE does inter-tech HO, the UE provides HNP to MME, otherwise not.
2. In an "initial attach" (as opposed to HO attach), the MME only provides LL-identifier (newly created default bearer identity) to the MAG. The MAG will sends MN_ID, HNP (0::0) LL-identifier and HI = 1 to the LMA and gets back HNP in PBA. In a "handover attach" the UE provides HNP to MME. The MME provides HNP and LL-identifier to the MAG. The MAG provides HNP, LL-identifier and HI=2 in PBU to LMA. The LMA checks that the HNP and MN-ID match (check to make sure the UE is not lying) and if they do sends a PBA to the MAG. The HNP is not stored in the MME (as currently specified).

3. During intra-LTE HO, the target MAG only provides MN-ID and LL-identity, HI= 3 (and ATT also) in PBU. The LMA finds the BCE (unique) based on MN-ID, ATT, LL-identity (section 5.4.1.2) and updates the BCE.

Regards
Irfan

---

From: "Ali Irfan-FIA225" <[email-masked]>
Date: Mon, 28 Apr 2008 17:21:30 +0100

Hi Oliver, 

In general I agree with your comments. I also think that the PMIPv6 spec currently requires MAG to figure out the correct conditions/requriements for setting HI and hence will enable PMIPv6 to be used for inter-tech HO.  I do not think anything more is needed on that front in the PMIPv6 draft. SDOs have to figure out how to provide the relevant information to the MAG. I do have a concern about logic in 5.4.1.3 that I would like to resolve

Also, what I was saying is done in LTE is not a proposal of how other technologies should handle passing information to the MAG. What I did realize by looking at PMIP draft in detail and using my understanding of LTE, was that there may be an issue providing the information required at the MAG for PMIP to work well for intra-LTE and inter-tech HO for LTE. That is what I am trying to resolve.

Regards
Irfan  

> -----Original Message-----
> From: BLUME, Oliver [mailto:[email-masked]] 
> Sent: Monday, April 28, 2008 12:40 PM
> To: Ali Irfan-FIA225; Sri Gundavelli
> Cc: NETLMM Mailing List; SIGLE, Rolf
> Subject: AW: [netlmm] LMA logic in draft-ietf-netlmm-proxymip6-12.txt
> 
>  
> Hi Irfan,
> 
> what you are proposing to me basically looks like a  means to 
> enable the MAG to discriminate between an initial attach 
> (requiring a new HNP) or an HO attach. Putting this into MME 
> signalling to the MAG is a valid approach, but note that it 
> is an LTE specific approach shifting the difficulties from 
> MAG to MME. How about the HO back from LTE to another 
> technology? Or how about HO between two non-3GPP technologies?
> 
> For a general solution, all MAGs (not only MAGs in 3GPP 
> networks) would be required to set the HI indicator to 2 or 3 
> during HO. It requires that the target interface technology 
> specifies a means for the mobile terminal (or the network 
> during context transfer) to indicate the attach reason during 
> attachment. Only if this requirement is met (in a way 
> specific for each interface technology and within the scope 
> of the according standardisation body) PMIP can supply a 
> smooth handover and provide the same HNP in the target interface. 
> 
> Would such a requirement be acceptable for PMIP? IMHO, this 
> would not mean outside interference into other 
> standardisations but simply would mean, without such 
> amendment no HO with session continuty would be granted in 
> PMIP domains, but instead HI=5 would have to be assumed and a 
> new HNP would be assigned. 
> 
> Regards,
> 
> Oliver
> 
> **************************************************************
> ******************************************
> Dr.-Ing. Oliver Blume
> Radio Access, Department for System Optimisations Holderäckerstr. 35
> D-70499 Stuttgart
> **************************************************************
> *******************************************
> 
> 
> 
> ability to 
> However, the logic in 5.4.1.3 should allow for this case, but 
> it does not currently. If we take the trivial case of 1 BCE 
> and the MAG providing HI=3, should be sufficient condition 
> for the LMA to update the existing BCE. Sorry, I have not 
> followed in detail the multihoming debate. There are 
> stringent conditions on MAG on setting HI=3. The draft is 
> allowing for the LMA to search for BCE based on just the 
> MN_ID.  If that is true and there is only one BCE for the 
> MN_ID and HI=3, then the BCE is uniquely identified in the 
> LMA and the PBU should be taken as a request to updated the 
> existing BCE and not create a new BCE. Hence, this should be 
> put in as a requirement into the logic. Currently, the logic 
> in 5.4.1.3 is ruling this out, since step 4 has a MUST in 
> that statement.
> 
> ...
> 
> In LTE there is context transfer between MAGs, but it is 
> through the control-plane entity (MME). The MN does not 
> "talk" directly with the MAG in the CP. Another requirement 
> that has been built into LTE is to handle "split terminals", 
> where the LTE modem is separated from the "host"
> IP-stack, the modem provides the layer-2 connectivity and the 
> host provides layer-3. The specification allows the host to 
> obtain an address directly from the MAG (the address is 
> actually provided by the LMA with the MAG acting as a relay), 
> after the layer-2 has been setup. So far, there the 
> specification has not required the MME to store the HNP 
> allocated to the UE. Hence, when HO occurs the target-MAG 
> does not get the HNP from the MME. Also, as you correcly 
> noted the UE is not sending a LL-identifier. Also, the 
> specification allows for MN to get multiple addresseses/HNP 
> (operator requirement, don't ask ;-)). There is also another 
> requirement to support inter-technology handoff, in which 
> case two separate modems may be used to access the two 
> technologies and during HO the MN may not provided its HNP to 
> the target system (or the target system will not trust the IP 
> address provided by the UE).
> 
> HNP(s) allocated to the MN to the MME, then this can solve 
> the intra-LTE HO issue, with the MME forwarding the HNP to 
> the target-MAG. However, this will not solve the 
> inter-technology HO scenario, where even if the UE provides 
> HNP, the network may not accept it. However, I am not sure if 
> "trust" is an issue, since the HNP is only accepted for a HO 
> situation and the LMA will check if the HNP is already 
> allocated to the UE. So this is a possible solution, HNP 
> provided by MAG to MME and UE provides HNP to MME when it is 
> performing inter-technology HO.
> 
> The other possibility is to use LL-identifier. This causes 
> the problem of how the UE can provide the same LL identifier 
> during inter-technology HO, when two different modems are 
> used? The MME can create a LL-identifier for the UE (called 
> "default bearer id") and provide that to the MAG, but such a 
> solution will not work for inter-technology HO. 
> 
> From the specification, I do see that LL-identifier is 
> allowed to change on inter-technology HO (5.4.1.1 step 4, 
> bullet 2). So the following maybe the best solution:
> 
> 2. In an "initial attach" (as opposed to HO attach), the MME 
> only provides LL-identifier (newly created default bearer 
> identity) to the MAG. The MAG will sends MN_ID, HNP (0::0) 
> LL-identifier and HI = 1 to the LMA and gets back HNP in PBA. 
> In a "handover attach" the UE provides HNP to MME. The MME 
> provides HNP and LL-identifier to the MAG. The MAG provides 
> HNP, LL-identifier and HI=2 in PBU to LMA. The LMA checks 
> that the HNP and MN-ID match (check to make sure the UE is 
> not lying) and if they do sends a PBA to the MAG. The HNP is 
> not stored in the MME (as currently specified).
> 
> 3. During intra-LTE HO, the target MAG only provides MN-ID 
> and LL-identity, HI= 3 (and ATT also) in PBU. The LMA finds 
> the BCE (unique) based on MN-ID, ATT, LL-identity (section 
> 5.4.1.2) and updates the BCE.
>

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 28 Apr 2008 10:14:27 -0700 (PDT)

Hi Irfan,

> logic in 5.4.1.3 is ruling this out, since step 4 has a MUST in that

I really expect either the HNP or the interface id to be presented
and allow the Proxy Mobile IPv6 system to properly identify a session,
rather than depending on special checks.

When the MAG request handoff by setting the HI flag, the LMA will
update the identified session. If the interface identifier is not
in use, truely the LMA or the Proxy Mobile IP system is unaware
of the true identify of the interface and just updates the session
as requested. The below rule allows the MAG to request that. Now,
if HI=2 or HI=3, its does not matter to LMA, as there is no interface
identifier and that was the intent when we consolidated both the
cases when we cleaned up this section. But, MAG should be able to
clearly specify HI=2 or HI=3, to be very specific. We can say below,
when HI=2 or HI=3, that distinction is fine.

5.4.1.3: Point-2.

"If there exists only one such entry (matching the MN-Identifier) and
the Handoff Indicator field in the Handoff Indicator option present
in the request is set to a value of 2 (Handoff between two different
interfaces of the mobile node), the request MUST be considered as a
request for updating that Binding Cache entry.  [PBU(HI) equals 2]".

Regards
Sri

---

From: "Ali Irfan-FIA225" <[email-masked]>
Date: Tue, 29 Apr 2008 15:02:03 +0100

Hi Sri,
 
> 
> I really expect either the HNP or the interface id to be 
> presented and allow the Proxy Mobile IPv6 system to properly 
> identify a session, rather than depending on special checks.
> 
> When the MAG request handoff by setting the HI flag, the LMA 
> will update the identified session. If the interface 
> identifier is not in use, truely the LMA or the Proxy Mobile 
> IP system is unaware of the true identify of the interface 
> and just updates the session as requested. The below rule 
> allows the MAG to request that. Now, if HI=2 or HI=3, its 
> does not matter to LMA, as there is no interface identifier 
> and that was the intent when we consolidated both the cases 
> when we cleaned up this section. But, MAG should be able to 
> clearly specify HI=2 or HI=3, to be very specific. We can say 
> below, when HI=2 or HI=3, that distinction is fine.
> 
> 
> 5.4.1.3: Point-2.
> 
> "If there exists only one such entry (matching the 
> MN-Identifier) and the Handoff Indicator field in the Handoff 
> Indicator option present in the request is set to a value of 
> 2 (Handoff between two different interfaces of the mobile 
> node), the request MUST be considered as a request for 
> updating that Binding Cache entry.  [PBU(HI) equals 2]".
> 
> 

If your proposal is to say HI=2 or HI=3 in the above Point-2, I am OK
with this change and resolves the issue that I raised in the chain.

About your suggestion of making sure that either HNP or LL_ID is
provided to LMA in PBU to enable BCE lookup based on these two fields
only, rather than depending on special check, I will try to see how to
enable that in LTE's use of PMIPv6.

Regards
IRfan

---

From: "Vijay Devarapallli" <[email-masked]>
Date: Tue, 29 Apr 2008 10:44:30 -0700

Hi Irfan, Sri,

>  How would it know, its a handoff and not a new attachment ?

This is discussed in section 3.1 of
draft-devarapalli-netlmm-multihoming-02.txt

   The Proxy Mobile IPv6 specification [2] does not specify any
   mechanism for MAG3 to figure out if the mobile node is performing a
   handover for if1 or if it is attaching to the Proxy Mobile IPv6
   domain for the first time via if1.  One option is for MAG3 to obtain
   this information via context transfer from MAG1.  This solution
   requires a context transfer interface between MAG1 and MAG3.  Another
   option is for MAG3 to be told by the AAA infrastructure as part of
   access authentication that the mobile node was previously attached to
   the Proxy Mobile IPv6 domain via if1.  However, this solution may not
   work in case the AAA infrastructure does not store interface related
   information or if the AAA infrastructure is not being used.  One
   solution that may work in most cases is for the mobile node to
   indicate to MAG3 that it already has sessions on top of the prefix
   assigned to if1 and it is performing a handover.  The mobile node
   conveys this information as part of Layer 2 setup.  When MAG3 gets
   this information, it sets the Handoff Indicator field in the Handoff
   Indicator option to indicate a handover for if1.

Basically, you need something beyond what is specified in the base
PMIPv6 specification. But you can do this in an SDO-specific manner
for now. I don't think IETF can produce anything very quickly to
address this. I wish we could, though.

Vijay