Subject: [netlmm] Issue: Timestamp vs Sequence Number based logic

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 24 Apr 2007 23:50:06 -0700

This issue was raised by Ahmad Muhanna. This is about the
Time Stamp option that we introduced in the Proxy Mobile IPv6
specification. Ahmad did not like the timestamp option and
suggested two other possible solutions and I've added two more
possible solutions to the list, in addition to the time stamp
based solution.
 
We have discussed with Ahmad offline and wanted to bring this
to the ML for getting some ideas. Please comment, if the
time stamp option what we have is better than the other options
or if we need to remove that.

Scenario:

        [LMA]
          |
          |
    -----(NET)----
    |            |
 [MAG-1]      [MAG-2]
    |
   MN1 ----->  

MN1 was attached to MAG-1
MAG-1 sends a PBU(1) to LMA and right then,

MN1 moves from MAG-1 and attaches to MAG-2.
MAG-2 sends a PBU(2) to LMA. 

LMA may or may not receive both the messages in
the same order as they were sent.

Correct Arriving Sequence: 
The correct sequence of packet arrival at the LMA is as 
follows: PBU(1) then PBU(2)

Possible Arriving Sequence: 
The possible sequence of packet arrival at the LMA is as 
follows: PBU(2) then PBU(1)

Impact:
LMA accepts PBU(2) and creates the tunnel to MAG-2. Immediately
it receives PBU(1) and it deletes the tunnel and creates a tunnel
to MAG-1.

Possible Solutions:
-------------------
Solution#1: Use of Time Stamp 

Source: Proxy Mobile IPv6 specification

1. Add the Time Stamp Option to the Proxy Binding Update message.

2. LMA should verify the time stamp value on the received PBU is
   later than the time stamp value in the currently accepted PBU.

3. If the time stamp in the received PBU is older than what was
   the time stamp in the currently accepted PBU, reject the request.

Advantages:
No special logic is required. Check the time stamp on the received PBU,

Disadvantages: 
Requires NTP service in the PMIP domain and the clocks on the LMA
and all the MAG's in the domain must be synced to millisecond accuracy.

Solution#2: 

Source: Ahmad Muhanna

1. When LMA receives a P-BU with a CoA different than the CoA in the
MN's BCE, LMA MUST do the following: 

1.1. LMA must verify that the sequence number in P-BU is more recent
than the last sequence number received from the same MAG which host
the CoA in the PBU. i.e. per Node SA.

1.2. If the PBU passes the sequencing check and other security checks,
LMA must update the BCE with the new CoA and the per-Node sequence
number counter as per the received seq. No.

1.3. LMA must starts a timer, for example, of 5 seconds and track the
old CoA(old). 

1.4. If LMA receives a PBU with a CoA = CoA(old) before the timer
expires, LMA ignore the P-BU waiting for the MAG1 to retransmit. If
MAG1 did not retransmit before the timer expires, LMA cancel the timer
and goes back to normal mode.

1.5. If LMA receives a retransmit of the P-BU before the timer expires,
LMA honors the P-BU. 

Disadvantages:

Any movements within 5 sec interval after anchoring will require
additional registration round trip ?

Solution#3: 

Source: Ahmad Muhanna

1. When LMA receives a PBU with a CoA different than the CoA in the
MN's BCE, LMA MUST do the following:

1.1. LMA must verify that the sequence number in P-BU is more recent
than the last sequence number received from the same MAG which host
the CoA received in the PBU. i.e. per Node SA.

1.2. If the PBU passes the sequencing check and other security checks,
LMA must update the BCE with the new CoA and the per-Node sequence
number counter as per the received seq. No.

1.3. LMA must starts a timer, for example, of 5 seconds and track
the old CoA(old). 

1.4. If LMA receives a PBU with a CoA = CoA(old) before the timer
expires, LMA rejects the PBU with an error code (for example: MN is
process of HO) This error code should make the MAG retransmit or
retry if the MN is really attached to it and it was not just a race
condition.

Disadvantages:

Any movements within 5 sec interval after anchoring will require
additional registration round trip ?

Solution#4:

Source: Sri Gundavelli

1. On detecting a mobile node on its access link. the MAG must send
the PBU. Once,	 the MAG receives a successful PBA, it must again
send a second PBU request after 1 sec. This method of sending two
consecutive PBU messages will ensure the binding request from the
currently anchored MAG survives against any network out of order
delivery conditions.

2. This resending logic is required only for the first registration
request sent by a MAG after detecting a mobile node on its access
link.

Disadvantages:

1 extra packet (not round trip) sent for the first registration
after a mobile attaches to a new MAG.

Solution#5: 

Source: Julien Laganier

1. The LMA on receiving a PBU message from a new CoA, the LMA must
reject the request and provide the sequence number that the MAG should
use in the subsequent PBU message. Typically, the suggested value is
+2 than what is the currently accepted sequence number.

Disadvantages:

1. One additional round trip for all initial registrations from a new
MAG.

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

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 25 Apr 2007 10:59:39 +0200

Hi Sri,

what about the optional solution specified in the draft to synchronize
SNs between MAGs (i.e., transmitting the current SN from MAG1 to MAG2,
e.g., by context transfer)? Does this remain in the draft as an option
no matter which of the solutions listed below will be picked?

Kilian

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Mittwoch, 25. April 2007 08:50
> To: [email-masked]
> Subject: [netlmm] Issue: Timestamp vs Sequence Number based logic
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 25 Apr 2007 06:34:42 -0500

Hi Kilian,
Actually this option only works if we have a per-MN sequence number. In
the case when we have a per-Node sequence number, I do not see how it is
going to work.

Regards,
Ahmad

> From: Kilian Weniger [mailto:[email-masked]] 
> Sent: Wednesday, April 25, 2007 4:00 AM
> To: Sri Gundavelli
> Cc: [email-masked]
> Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic
> 
> Hi Sri,
> 
> what about the optional solution specified in the draft to 
> synchronize SNs between MAGs (i.e., transmitting the current 
> SN from MAG1 to MAG2, e.g., by context transfer)? Does this 
> remain in the draft as an option no matter which of the 
> solutions listed below will be picked?
> 
> Kilian
> 
> Time Stamp 
> > option that we introduced in the Proxy Mobile IPv6 specification. 
> > Ahmad did not like the timestamp option and suggested two other 
> > possible solutions and I've added two more possible 
> solutions to the 
> > list, in addition to the time stamp based solution.
> >  
> > We have discussed with Ahmad offline and wanted to bring 
> this to the 
> > ML for getting some ideas. Please comment, if the time stamp option 
> > what we have is better than the other options or if we need 
> to remove 
> > that.
> > 
> > 
> > 
> > Scenario:
> > 
> >         [LMA]
> >           |
> >           |
> >     -----(NET)----
> >     |            |
> >  [MAG-1]      [MAG-2]
> >     |
> >    MN1 ----->
> > 
> > 
> > LMA may or may not receive both the messages in the same 
> order as they 
> > were sent.
> > 
> > LMA accepts PBU(2) and creates the tunnel to MAG-2. Immediately it 
> > receives PBU(1) and it deletes the tunnel and creates a tunnel to 
> > MAG-1.
> > 
> > 
> > 
> > Possible Solutions:
> > -------------------
> > Requires NTP service in the PMIP domain and the clocks on 
> the LMA and 
> > all the MAG's in the domain must be synced to millisecond accuracy.
> > 
> > 
> > 
> > Solution#2: 
> > 
> > Source: Ahmad Muhanna
> > 
> > 1.5. If LMA receives a retransmit of the P-BU before the timer 
> > expires, LMA honors the P-BU.
> > 
> > 
> > Disadvantages:
> >

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 25 Apr 2007 07:29:33 -0500

Thanks Sri for the good summary.
I have some clarification and comments, please see inline.

Regards,
Ahmad

> Sent: Wednesday, April 25, 2007 1:50 AM
> To: [email-masked]
> suggested two other possible solutions and I've added two 
> more possible solutions to the list, in addition to the time 
> stamp based solution.
>  
> to the ML for getting some ideas. Please comment, if the time 
> stamp option what we have is better than the other options or 
> if we need to remove that.
> 
> 
> 
> Scenario:
> 
>         [LMA]
>           |
>           |
>     -----(NET)----
>     |            |
>  [MAG-1]      [MAG-2]
>     |
>    MN1 ----->  
> 
> 
> order as they were sent.
> LMA accepts PBU(2) and creates the tunnel to MAG-2. 
> Immediately it receives PBU(1) and it deletes the tunnel and 
> creates a tunnel to MAG-1.
> 
> 
> 
> Possible Solutions:
> -------------------
> Requires NTP service in the PMIP domain and the clocks on the 
> LMA and all the MAG's in the domain must be synced to 
> millisecond accuracy.
>
[Ahmad]
The whole idea here is that since the MAG and the LMA has a per-Node
security association, using sequence number for ordering the messages
should work based on a per-Node sequence number and no need for the
timestamp and NTP synchronization. IMO.
 
> 
> 
> Solution#2: 
> 
> Source: Ahmad Muhanna
> 
> 1. When LMA receives a P-BU with a CoA different than the CoA 
> in the MN's BCE, LMA MUST do the following: 
> 
> 1.1. LMA must verify that the sequence number in P-BU is more 
> recent than the last sequence number received from the same 
> MAG which host the CoA in the PBU. i.e. per Node SA.
> 
> 1.2. If the PBU passes the sequencing check and other 
> security checks, LMA must update the BCE with the new CoA and 
> the per-Node sequence number counter as per the received seq. No.
> 
> 1.3. LMA must starts a timer, for example, of 5 seconds and 
> track the old CoA(old). 
> 
> 1.4. If LMA receives a PBU with a CoA = CoA(old) before the 
> timer expires, LMA ignore the P-BU waiting for the MAG1 to 
> retransmit. If
> MAG1 did not retransmit before the timer expires, LMA cancel 
> the timer and goes back to normal mode.

[Ahmad]
I used a timer here as an example. But IMO, this is an implementation
specific and other mechanism can be used. For example, LMA can save its
own timestamp in the BCE at the time of successfully accepting a P-BU
which caused a CoA update (not needed for the initial P-BU nor
re-registration from the initial CoA). Then, LMA only compares the
timestamp when receiving another P-BU with a different CoA and check if
it is within 5 seconds, if it is, LMA ignore if not LMA process the P-BU
as normal.  
*** The same concept is applicable to Solution # 3.****

> 
> 1.5. If LMA receives a retransmit of the P-BU before the 
> timer expires, LMA honors the P-BU. 
> 
> 
> Disadvantages:
> 
> Any movements within 5 sec interval after anchoring will 
> require additional registration round trip ?

[Ahmad]
Just a minor correction on the Disadvantage. This solution requires a
retransmission of P-BU ONLY in the case if the MN moved back to the old
MAG, i.e. old CoA. In other words, this solution will only require the
MAG1 to retransmit if and only if that PBU was real and not a race
condition [i.e. P-BU(3) which is not shown in the figure above]. This
means that it will require an extra retransmitted P-BU only in the
following scenario: MN handoff from MAG1 to MAG2 and then immediately
back to MAG1. IMO, this scenario is VERY rare. 

> 
> 
> 
> Solution#3: 
> 
> Source: Ahmad Muhanna
> 
> 1. When LMA receives a PBU with a CoA different than the CoA 
> in the MN's BCE, LMA MUST do the following:
> 
> 1.1. LMA must verify that the sequence number in P-BU is more 
> recent than the last sequence number received from the same 
> MAG which host the CoA received in the PBU. i.e. per Node SA.
> 
> 1.2. If the PBU passes the sequencing check and other 
> security checks, LMA must update the BCE with the new CoA and 
> the per-Node sequence number counter as per the received seq. No.
> 
> 1.3. LMA must starts a timer, for example, of 5 seconds and 
> track the old CoA(old). 

[Ahmad]
Please see comment under solution 2.

> 
> 1.4. If LMA receives a PBU with a CoA = CoA(old) before the 
> timer expires, LMA rejects the PBU with an error code (for 
> example: MN is process of HO) This error code should make the 
> MAG retransmit or retry if the MN is really attached to it 
> and it was not just a race condition.
> 
> 
> Disadvantages:
> 
> Any movements within 5 sec interval after anchoring will 
> require additional registration round trip ?

[Ahmad]
The same comment above applies here too with the difference that, in
this case, a full round trip is required ONLY in the real case when MN
handoff from MAG1 to MAG2 and then back to MAG1, which is again VERY
rare.
 
> send a second PBU request after 1 sec. This method of sending 
> two consecutive PBU messages will ensure the binding request 
> from the currently anchored MAG survives against any network 
> out of order delivery conditions.
> 
> 2. This resending logic is required only for the first 
> registration request sent by a MAG after detecting a mobile 
> node on its access link.
> 
> 
> Disadvantages:
> 
> 1 extra packet (not round trip) sent for the first 
> registration after a mobile attaches to a new MAG.

[Ahmad]
Agree. This solution requires an extra round trip for any inter-MAG
movement to address a rare race condition scenario.

> 
> 
> 
> 
> Solution#5: 
> 
> Source: Julien Laganier
> 
> 1. The LMA on receiving a PBU message from a new CoA, the LMA 
> must reject the request and provide the sequence number that 
> the MAG should use in the subsequent PBU message. Typically, 
> the suggested value is
> 1. One additional round trip for all initial registrations 
> from a new MAG.

[Ahmad]
Agree. This solution requires an extra round trip for any movement
inter-MAG to address a rare race condition scenario. 

In general: Solutions 4 & 5, introduces 2 round trip concept during
inter-MAG handoff which IMO, very expensive and undesirable. Reminds me
with (MIP4) Dynamic HA based on 2-round trip registration. Although,
this is a little worse. Since Dynamics HA only happens during initial
registration but this happens during inter-MAG handoff.

---

From: "Mohamed Khalil" <[email-masked]>
Date: Wed, 25 Apr 2007 09:10:54 -0500

another solution: if we use the concept of simultaneous binding, then
there is no problem of having multiple MAGs (theoretically any number)
to register in any order. The one which doesn't update it lifetime
binding will expires with minimal impact of data interruption while MN
is handing off. This solution is good in delay sensitive applications. 

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 1:50 AM
To: [email-masked]
Subject: [netlmm] Issue: Timestamp vs Sequence Number based logic

This issue was raised by Ahmad Muhanna. This is about the
Time Stamp option that we introduced in the Proxy Mobile IPv6
specification. Ahmad did not like the timestamp option and suggested two
other possible solutions and I've added two more possible solutions to
the list, in addition to the time stamp based solution.
 
We have discussed with Ahmad offline and wanted to bring this to the ML
for getting some ideas. Please comment, if the time stamp option what we
have is better than the other options or if we need to remove that.

Scenario:

        [LMA]
          |
          |
    -----(NET)----
    |            |
 [MAG-1]      [MAG-2]
    |
   MN1 ----->  

Impact:
LMA accepts PBU(2) and creates the tunnel to MAG-2. Immediately it
receives PBU(1) and it deletes the tunnel and creates a tunnel to MAG-1.

Possible Solutions:
-------------------

Advantages:

Disadvantages: 
Requires NTP service in the PMIP domain and the clocks on the LMA and
all the MAG's in the domain must be synced to millisecond accuracy.

Solution#2: 

Source: Ahmad Muhanna

1.1. LMA must verify that the sequence number in P-BU is more recent
than the last sequence number received from the same MAG which host the
CoA in the PBU. i.e. per Node SA.

1.4. If LMA receives a PBU with a CoA = CoA(old) before the timer
expires, LMA ignore the P-BU waiting for the MAG1 to retransmit. If MAG1
did not retransmit before the timer expires, LMA cancel the timer and
goes back to normal mode.

Disadvantages:

Solution#3: 

Source: Ahmad Muhanna

1. When LMA receives a PBU with a CoA different than the CoA in the MN's
BCE, LMA MUST do the following:

1.1. LMA must verify that the sequence number in P-BU is more recent
than the last sequence number received from the same MAG which host the
CoA received in the PBU. i.e. per Node SA.

1.4. If LMA receives a PBU with a CoA = CoA(old) before the timer
expires, LMA rejects the PBU with an error code (for example: MN is
process of HO) This error code should make the MAG retransmit or retry
if the MN is really attached to it and it was not just a race condition.

Disadvantages:

Solution#4:

Source: Sri Gundavelli

2. This resending logic is required only for the first registration
request sent by a MAG after detecting a mobile node on its access link.

Disadvantages:

1 extra packet (not round trip) sent for the first registration after a
mobile attaches to a new MAG.

Solution#5: 

Source: Julien Laganier

Disadvantages:

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 25 Apr 2007 16:31:03 +0200

Hi Ahmad,

ok, but according to draft-ietf-netlmm-proxymip6-00.txt every MAG
maintains a Binding Udpate List (BUL) as defined in RFC3775 (plus some
additional fields) for each currently attached MN. 

So a per-MN sequence number is always available at the MAG and can be
used to order PBUs in case a mechanism to synchronize the SNs between
MAGs (e.g., contex transfer) is in place, no? 

Regards,

Kilian 

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Mittwoch, 25. April 2007 13:35
> To: Kilian Weniger; Sri Gundavelli
> Cc: [email-masked]
> Immediately it 
> > > No special logic is required. Check the time stamp on the 
> received 
> > > PBU,
> > > 
> > > Disadvantages: 
> > security checks, 
> > track the 
> > security checks,
> registration
> > from a new

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 25 Apr 2007 09:46:17 -0700

Hi Kilian,
 
If context transfer mechanisms are in place, certainly,
the sequence number state of a mobile can be moved between
MAG's. However, the base draft does not deal with
context transfers and so we need to have a solution
assuming no context transfer support. But, the draft
does not prevent implementations from solving the
sequence number issue using SDO specific context transfer
schemes.

Thanks
Sri

-----Original Message-----
From: Kilian Weniger [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 2:00 AM
To: Sri Gundavelli
Cc: [email-masked]
Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic

Hi Sri,

Kilian

> received PBU,

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 25 Apr 2007 12:21:21 -0500

Hi Sri,

One more clarification I would like to make. I am not against using
timestamp as an option. I believe allowing both mechanisms is the best
choice. However, as per your posting, solution No. 1 handles the race
condition assuming that MAG and LMA are always in sync. Now, if we
believe that MAG and LMA can possibly go out of sync, then solution 1
will work for ordering PBU and PBA but needs one of the other solutions
listed (2-5) to address the race condition. (In these solutions SN is
replaced by the timestamp.)

I still believe solutions 2 and 3 are more contained, much less
expensive, and does not mandate an extra round trip for every inter-MAG
handoff.

+++++++++++

Probably the options should be like this, Sri, please confirm if you
agree on this minor adjustment: 

Assuming that either timestamp or Sequence number is used for ordering
the PBU and PBA, in order to address the inter-MAG handoff race
condition, which of the following solutions best fit the need?

Solution 1: MAG and LMA are always in sync. (Applicable ONLY in the case
of timestamp)

(The following solutions applicable to SQ Number and Timestamp in case
MAG and LMA MAY go out of sync.)

Solution No. 2: 
Solution No. 3:
Solution No. 4:
Solution No. 5:

I hope I did not make it worse:-) 

Regards,
Ahmad

> From: Muhanna, Ahmad (RICH1:2H10) 
> Sent: Wednesday, April 25, 2007 7:30 AM
> To: Sri Gundavelli; [email-masked]
> > Immediately it receives PBU(1) and it deletes the tunnel 
> and creates a 
> > tunnel to MAG-1.
> > 
> > 
> > 
> > Possible Solutions:
> > -------------------
> The whole idea here is that since the MAG and the LMA has a 
> per-Node security association, using sequence number for 
> ordering the messages should work based on a per-Node 
> sequence number and no need for the timestamp and NTP 
> synchronization. IMO.
>  
> > 
> > 
> > Solution#2: 
> > 
> > Source: Ahmad Muhanna
> > 
> I used a timer here as an example. But IMO, this is an 
> implementation specific and other mechanism can be used. For 
> example, LMA can save its own timestamp in the BCE at the 
> time of successfully accepting a P-BU which caused a CoA 
> update (not needed for the initial P-BU nor re-registration 
> from the initial CoA). Then, LMA only compares the timestamp 
> when receiving another P-BU with a different CoA and check if 
> it is within 5 seconds, if it is, LMA ignore if not LMA 
> process the P-BU as normal.  
> Just a minor correction on the Disadvantage. This solution 
> requires a retransmission of P-BU ONLY in the case if the MN 
> moved back to the old MAG, i.e. old CoA. In other words, this 
> solution will only require the
> MAG1 to retransmit if and only if that PBU was real and not a 
> race condition [i.e. P-BU(3) which is not shown in the figure 
> above]. This means that it will require an extra 
> retransmitted P-BU only in the following scenario: MN handoff 
> from MAG1 to MAG2 and then immediately back to MAG1. IMO, 
> this scenario is VERY rare. 
> 
> > 
> > 
> > 
> > Solution#3: 
> > 
> > Source: Ahmad Muhanna
> > 
> > expires, LMA rejects the PBU with an error code (for
> > example: MN is process of HO) This error code should make the MAG 
> > retransmit or retry if the MN is really attached to it and 
> it was not 
> > just a race condition.
> > 
> > 
> > Disadvantages:
> > 
> The same comment above applies here too with the difference 
> that, in this case, a full round trip is required ONLY in the 
> real case when MN handoff from MAG1 to MAG2 and then back to 
> MAG1, which is again VERY rare.
>  
> > 
> > 
> > 
> > 
> > Solution#4:
> > 
> > Source: Sri Gundavelli
> > 
> Agree. This solution requires an extra round trip for any 
> inter-MAG movement to address a rare race condition scenario.
> 
> > 
> > 
> > 
> > 
> > Solution#5: 
> > 
> > Source: Julien Laganier
> >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 25 Apr 2007 19:41:39 -0700

Hi Ahmad,

Yes, I agree, supporting both the schemes might be a good
idea. I think we should keep the time stamp based approach
and support one other approach. Lets hear some comments from
others on the proposed 5 approaches and take it from there.

Regards
Sri

-----Original Message-----
From: Ahmad Muhanna [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 10:21 AM
To: Ahmad Muhanna; Sri Gundavelli; [email-masked]
Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic

Hi Sri,

+++++++++++

Solution No. 2: 
Solution No. 3:
Solution No. 4:
Solution No. 5:

Regards,
Ahmad

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 26 Apr 2007 08:52:52 +0200

Hi Sri,

I agree that the draft should specify a solution that works without
context transfer. But the current draft has text about two solutions:
the first is independent of context transfer (using timestamp for
ordering PBUs). The second depends on context transfer (using SNs for
ordering PBUs) and can be used by SDOs that have context transfer anyway
in their architecture. 

My question was whether the discussion about changing the first solution
has any implications on the text in the draft related to the second
solution.

Kilian

> Sent: Mittwoch, 25. April 2007 18:46
> To: 'Kilian Weniger'
> Cc: [email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 26 Apr 2007 03:03:23 -0700

Well, IMO solution #1 is sufficient. Not sure why we need to add another 
solution.

Vijay

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Thu, 26 Apr 2007 12:18:51 +0200

Maybe another solution or an option to optimize current proposals: if 
LMA could hold both tunnels, it might receive data from MN1 via the 
tunnel to which MN1 is actually attached, and then uses this information 
to choose the right tunnel and cancel the other.
Also LMA has the option to mirror traffic to MN1 via both tunnels.

Disadvantages
- it looks like MCOA support in LMA
- it could be hard for LMA to learn that MN1 is sending traffic
- not useful for MN that does not send traffic

Jean-Mickael

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 26 Apr 2007 06:59:32 -0500

Hi Kilian,
Please see comments inline. 
I will have more discussion in the response to your other email.

Regards,
Ahmad

> Sent: Thursday, April 26, 2007 1:53 AM
> To: Sri Gundavelli
> Cc: [email-masked]
> I agree that the draft should specify a solution that works 
> without context transfer. But the current draft has text 
> about two solutions:
> the first is independent of context transfer (using timestamp 
> for ordering PBUs). The second depends on context transfer 
> (using SNs for ordering PBUs) and can be used by SDOs that 
> have context transfer anyway in their architecture. 

I did not see any mentioning of this in the base draft and I disagree to
mention that anyway.
Both mechanisms are the same and I did not see anything specify per-MN
ordering mechanism. Timestamp in itself is a per-Node mechanism. MAG is
using its own timestamp for all sessions. No?
In the case of SQ, If per-Node SN is used, no dependency on context
transfer either.

> 
> My question was whether the discussion about changing the 
> first solution has any implications on the text in the draft 
> related to the second solution.
> 
> Kilian
> 
> > If context transfer mechanisms are in place, certainly, the 
> sequence 
> > number state of a mobile can be moved between MAG's. 
> However, the base 
> > draft does not deal with context transfers and so we need to have a 
> > solution assuming no context transfer support. But, the 
> draft does not 
> > prevent implementations from solving the sequence number 
> issue using 
> > SDO specific context transfer schemes.
> > 
> > Thanks
> > Sri
> > 
> synchronize 
> > > what we have is better than the other options or if we need to 
> > > remove that.
> > > 
> > > 
> > > 
> > > Scenario:
> > > 
> > >         [LMA]
> > >           |
> > >           |
> > >     -----(NET)----
> > >     |            |
> > >  [MAG-1]      [MAG-2]
> > >     |
> > >    MN1 ----->
> > > 
> > > 
> > > LMA may or may not receive both the messages in the same order as 
> > > they were sent.
> > > 
> example: MN is

---

From: "Kilian Weniger" <[email-masked]>
Date: Thu, 26 Apr 2007 14:26:52 +0200

Hi Ahmad, 

> I did not see any mentioning of this in the base draft and I 

I referred to the following text in section 5.5 of
draft-ietf-netlmm-proxymip6-00.txt:

  "In the absence of Time Stamp option in the Proxy Binding Update, the
   entities can fall back to Sequence Number scheme for message
   ordering, as defined in RFC-3775.  However, the specifics on how
   different mobile access gateways synchronize the sequence number is
   outside the scope of this document."

Furthermore, section 6.2. says

  "Every mobile access gateway maintains a Binding Update List for each
   currently attached mobile node.  The Binding Update List is a
   conceptual data structure, described in Section 11.1 of Mobile IPv6
   base specification [RFC-3775]. "

and section 11.1 of RFC3775 says:

  "o  The maximum value of the Sequence Number field sent in previous
      Binding Updates to this destination.  The Sequence Number field is
      16 bits long and all comparisons between Sequence Number values
      MUST be performed modulo 2**16 (see Section 9.5.1)."

So I assume that the sequence number mentioned in section 5.5 of
draft-ietf-netlmm-proxymip6-00.txt is a per-MN sequence number. 

Regards,

Kilian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 26 Apr 2007 17:06:55 +0300

Sri Gundavelli wrote:
> [...]

FWIW, I added it to the issues tracker.

- Christian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 26 Apr 2007 09:14:54 -0500

Hi kilian,

Thanks for the details from the draft. However, see comments inline.

Regards,
Ahmad

> Sent: Thursday, April 26, 2007 7:27 AM
> To: Muhanna, Ahmad (RICH1:2H10); Sri Gundavelli
> Cc: [email-masked]

[Ahmad]
I guess this is the most important piece. I am not going to split hair
here. Yes, I agree that the draft has in mind per-MN SN mechanism.
However, look at the following text (just for clarification): " However,
the specifics on how different mobile access gateways synchronize the
sequence number is outside the scope of this document." I believe there
is a reason for including that text, probably because they do not want
to reference Context transfer.

On the other hand, the PMIP base protocol justified the use of Per-Node
IPsec SA. IMO, SQN is part of the security association between the peers
(MAG and LMA). It makes a lot of sense to apply the same concept used
for IPsec to SQN. No?

Let us agree here on one thing. The PMIP base draft reference RFC3775
but still leaves the details outside the scope of the draft. I believe
people need to choose between per-MN vs. Per-Node SQN based on the
advantages and disadvantages of the two mechanisms. 

However, I see an IOT problem here and probably we need to decide on
this here. i.e. Per-Node vs. per-MN.

I may add one more advantage to the per-Node SQN, in case of MAG looses
track of sessions with any LMA while the LMA still have record of these
sessions, MAG will only need one session to have two round trip
registration to sync the rest of the sessions. In the case of per-MN
SQN, every session will have to have 2 round trips for re-establishment.

> So I assume that the sequence number mentioned in section 5.5 
> of draft-ietf-netlmm-proxymip6-00.txt is a per-MN sequence number. 
> 
> Regards,
> 
> Kilian
> 
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 26 Apr 2007 11:32:30 -0500

Hi Jean, 
Yes, I think that solution was proposed by MK earlier. Simultaneous
binding.

Regards,
Ahmad

> From: Jean-Mickael Guerin [mailto:[email-masked]] 
> Sent: Thursday, April 26, 2007 5:19 AM
> To: [email-masked]
> Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic
> 
> Maybe another solution or an option to optimize current 
> proposals: if LMA could hold both tunnels, it might receive 
> data from MN1 via the tunnel to which MN1 is actually 
> attached, and then uses this information to choose the right 
> tunnel and cancel the other.

---

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 26 Apr 2007 12:13:59 -0500

see my inline

> - it could be hard for LMA to learn that MN1 is sending traffic
Mohamed >> why the LMA need to know if the MN is sending trsffic or not?
> - not useful for MN that does not send traffic

Mohamed>> this mechanism, as I mentioned before, is useful to minimize
packet data loss during handoff for applications sensitive to data loss
such as VoIP.

> > [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> > 
> > 
> 
> 
>

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Thu, 26 Apr 2007 21:54:27 +0200

OK sorry for not being clear:
- the idea is not based on bi-casting and PBU retransmission.
- the idea is to listen to traffic sent by MN for a while as soon as 
second PBU is received. Because if data is still received from the 
previous tunnel, it means that the MN is actually attached to it, ie the 
PBU are out of sequence.

Bi-casting is just an optimization in this idea, the same as you 
mentioned and I fully agree the advantages.

As far as VoIP is concerned, can we assume that MN is continuously 
sending traffic ?

Thanks,

Jean-Mickael

> packet data loss during handoff for applications sensitive to data loss

In this idea bi-casting is only an option.  useful since LMA is not sure 
to choose the right tunnel when second PBU is received.

With VoIP, MN should send traffic
The main

---

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 26 Apr 2007 15:02:59 -0500

not necessary

-----Original Message-----
From: Jean-Mickael Guerin [mailto:[email-masked]] 
Sent: Thursday, April 26, 2007 2:54 PM
To: Khalil, Mohamed (RICH2:2S20); Muhanna, Ahmad (RICH1:2H10)
Cc: [email-masked]
Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic

PBU are out of sequence.

Thanks,

Jean-Mickael

> packet data loss during handoff for applications sensitive to data 
> loss such as VoIP.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 26 Apr 2007 19:49:49 -0700

Hi Kilian,

Please see inline.. 

-----Original Message-----
From: Kilian Weniger [mailto:[email-masked]] 
Sent: Wednesday, April 25, 2007 11:53 PM
To: Sri Gundavelli
Cc: [email-masked]
Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic

Hi Sri,

[Sri] This is a good question. Certainly, what ever mechanism(s) we
end up supporting after the close of discussions on this thread, I
assume we will still allow context transfer schemes. The method of
enabling one method or the other can be a simple configuration knob
on the LMA and on the MAG and so we should be able to accommodate
multiple schemes.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 26 Apr 2007 20:00:31 -0700

Bi-casting is an optimization and the basic make-before-the-break
logic can always be built. I do not think this will address the
problem completely. The sequence number proposals are for ensuring
the local mobility anchor does not accept a binding request from
a MAG that the mobile was previously anchored and the packet got
delivered out of order. Bi-casting sets up both the paths, but
does not provide the ability for the LMA to determine where the
mobile is currently anchored, till the subsequent registration.
Also, if we extrapolate a bit and add a 3 MAG in the picture,
the scenario gets worse.

Sri

-----Original Message-----
From: Jean-Mickael Guerin [mailto:[email-masked]] 
Sent: Thursday, April 26, 2007 12:54 PM
To: Mohamed Khalil; [email-masked]
Cc: [email-masked]
Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic

Thanks,

Jean-Mickael

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 26 Apr 2007 20:35:08 -0700

Hi Jean-Mickel,

> - the idea is to listen to traffic sent by MN for a while as soon as 

LMA is the aggregation point, potentially anchoring 100's of thousands
of mobile nodes. Packet inspection will be very expensive.

First point, the scenario is really a corner case, the mobile
moving rapidly between MAG's and the PBU's being sent in a very
close space and the packet arrivals in out of order. Its quite
drammatics, but, we need to address it. So, I'd think the solutions
#3 or #4 should be simple to implement and very inexpensive.

Thanks
Sri

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Fri, 27 Apr 2007 10:34:19 +0200

Hi Sri,

> of mobile nodes. Packet inspection will be very expensive.

LMA should already do packet inspection when handling reverse tunneled 
packets, by checking source IP address. This is recommend for HA in RFC 
3775 10.4.5.
When the check fails it should mean we face the corner case.
Then a notification can be sent from dataplane to LMA function.

And to minimize further the number of notifications, LMA can mark 
"stale" the first BCE, in order to trigger the event only when the 
lookup matches a stale entry.
When LMA module receives a notification, it can update the route for MN 
back to the right tunnel.

Anyway, I'm not saying this is a total solution, I just want to stress 
that the information "receiving data from the wrong tunnel" should be 
proposed to help LMA to resolve the corner case, ie it can be helpful to 
any solution.

Jean-Mickael

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 27 Apr 2007 16:41:12 +0200

I also think that the timestamp solution is only a compromise,
which should be possible to switch off in case future versions
support more appropriate solutions. As a general design goal,
I think that we should avoid adding too much complexity to
nodes, such as solution #2 and #3.

Even though solution #5 might imply double handshake between
nMAG and LMA before the new registration can be accepted, it
looks like the most clean solution. It can easily be
omitted in future versions, allowing the nMAG to
use a correct sequence number from the beginning. Maybe the
first PBU from the nMAG can create a 'tentative' registration,
which is then approved by the correct one. This would at least
allow packets to be forwarded from the beginning.

marco