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

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 24 Aug 2007 21:35:21 -0700

This is the adopted text for resolving the Timestamp vs Sequence
number issue. We have discussed this issue with Ahmad, Kilian, Marco,
Jean-Mickel and others some time back. I think, we have covered all
the cases. Please let us know, if we are still missing any other case.

This issue can be closed now.

Regards
Sri

5.5.  Timestamp Option for Message Ordering

   Mobile IPv6 [RFC-3775] uses the Sequence Number field in registration
   messages as a way for the home agent to establish sending order of
   the received signaling messages from a mobile node.  The home agent
   and the mobile node are required to manage this counter over the
   lifetime of a binding.  However, in Proxy Mobile IPv6, as the mobile
   node moves from one mobile access gateway to the other and in the
   absence of context transfer mechanism, the serving mobile access
   gateway will not be able to determine the sequence number that it
   needs to use in the signaling messages.  Hence, the sequence number
   scheme as specified in [RFC-3775], will not be sufficient for Proxy
   Mobile IPv6.

   If the local mobility anchor cannot determine the sending order of
   the received signaling messages, it may process an older message sent
   by a mobile access gateway, where the mobile node was previously
   anchored, resulting in incorrectly altering the current care-of
   address of the mobile node.

   This document requires the use of Timestamp Option, specified in
   Section 8.4, in all signaling messages exchanged between the local
   mobility anchor and the mobile access gateway.  The basic principle
   behind the use of Timestamp in mobility messages is that the node
   generating the message inserts the current time of the day, and the
   node receiving the message checks that this timestamp is greater than
   all previously accepted timestamps.  The following additional
   considerations apply:

   o  All the mobility entities in a Proxy Mobile IPv6 domain,
      exchanging signaling messages using Timestamp option must have
      adequately synchronized time-of-day clocks.  These nodes SHOULD
      synchronize their clocks to a common time source using Network
      Time Protocol [RFC-1305].

   o  When using the Timestamp option [Section 8.4] in mobility
      signaling messages, the timestamp field in the option MUST be set
      to a 64-bit value, formatted as specified by the Network Time

Gundavelli, et al.        Expires March 2, 2008                [Page 17]

Internet-Draft              Proxy Mobile IPv6                August 2007

      Protocol [RFC-1305].  The NTP timestamp is the representation of
      elapsed time in seconds, since, 1st January 1900.  This 64-bit
      timestamp as defined in NTP, consists of a 32-bit seconds part and
      a 32-bit fractional second part.  The low-order 32 bits represent
      fractional seconds, and those bits which are not available from a
      time source SHOULD be generated from a good source of randomness.

   o  Upon receipt of a Proxy Binding Update message with the Timestamp
      option, the local mobility anchor MUST check the timestamp field
      for validity.  In order for it to be considered valid, the
      timestamp value contained in the Timestamp option MUST be close
      enough to the local mobility anchor's time of day clock and the
      timestamp MUST be greater than all previously accepted timestamps
      in the Proxy Binding Update messages sent for that mobile node.

   o  If the Timestamp option is present in the received Proxy Binding
      Update message, the local mobility anchor MUST ignore the sequence
      number field in the message.  However, it MUST copy the sequence
      number from the received Proxy Binding Update message to the Proxy
      Binding Acknowledgement message.

   o  If the timestamp value in the received Proxy Binding Update is
      valid, the local mobility anchor MUST return the same timestamp
      value in the Timestamp option included in the Proxy Binding
      Acknowledgment message sent to the mobile access gateway.

   o  If the timestamp value in the received Proxy Binding Update is not
      valid, the local mobility anchor MUST reject the Proxy Binding
      Update and send a Proxy Binding Acknowledgement message with
      Status field set to TIMESTAMP_MISMATCH (Timestamp mismatch).  The
      message MUST also include the Timestamp option with the value set
      to the current time of the day on the local mobility anchor.

   o  If the Timestamp option is present in the received Proxy Binding
      Update message and the local mobility anchor does not support the
      timestamp option, the local mobility anchor MUST reject the Proxy
      Binding Update request and send a Proxy Binding Acknowledgement
      message with Status field set to TIMESTAMP_OPTION_NOT_SUPPORTED
      (Timestamp not supported).  It MUST also copy the sequence number
      from the received Proxy Binding Update message to the Proxy
      Binding Acknowledgement message.

   o  The use of Timestamp option in mobility signaling messages is
      OPTIONAL.  However, if the Timestamp option is present in the
      received Proxy Binding Update message, then the local mobility
      anchor MUST include a valid Timestamp option in the Proxy Binding
      Acknowledgment message that it sends to the mobile access gateway.
      Additionally, if the Timestamp option is not present in the

Gundavelli, et al.        Expires March 2, 2008                [Page 18]

Internet-Draft              Proxy Mobile IPv6                August 2007

      received Proxy Binding Update request, the local mobility anchor
      MUST NOT include the Timestamp option in the Proxy Binding
      Acknowledgment message that it sends to the mobile access gateway.

   o  If Timestamp based scheme is not used, the mobility entities
      exchanging the mobility signaling messages MUST use Sequence
      number based scheme, as per [RFC-3775].  The sequence number MUST
      be maintained on a per mobile node basis and MUST be synchronized
      between the serving mobile access gateways.  However, the specific
      details on how a mobile node's sequence number is synchronized
      between different mobile access gateways is outside the scope of
      this document.

   o  The identifier of the mobile node MUST always be present in the
      Proxy Binding Update and Proxy Binding Acknowledgement messages.
      The mobile access gateway MUST additionally use this identifier
      for matching the received Proxy Binding Acknowledgement message to
      the Proxy Binding Update message that it sent from its pending
      request queue.

> -----Original Message-----
> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Thursday, May 03, 2007 10:20 PM
> To: Sri Gundavelli; Kilian Weniger; Jean-Mickael Guerin; 
> Mohamed Khalil; Vijay Devarapalli
> Cc: [email-masked]
> Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number based logic
> 
> Hi Sri,
> Please allow me to edit the last two bullets slightly:
> 
> > - We will also continue to support Per-MN sequence number,
> >   and in the absence of time stamp option, this will be used. 
> >   However, the exact mechanism of how this is transferred
> >   between MAG's or context transfer scheme is out the scope
> >   for this document.
> 
>  - We will also continue to support Per-MN sequence number,
>    and in the absence of time stamp option, this will be used. 
>    However, the exact mechanism of how the Per-MN SQN state is 
>    transferred between MAG's or context transfer scheme is out 
>    of the scope for this document.
> 
> > - The PBA must return the MN-ID, for error code 135, for the
> >   MAG to be able to match the request to the response. As there
> >   may be a collision of sequence number for the pending requests
> >   for different mobiles, using their respective seq number.
>  
>  - The PBA must always return the MN-ID in order to for the MAG
>    to always be able to match the request to the response. As there
>    may be a collision of sequence number for the pending requests
>    for different mobiles, using their respective seq number.
> 
> 
> Regards,
> Ahmad
>  
> 
> > -----Original Message-----
> > From: Sri Gundavelli [mailto:[email-masked]] 
> > Sent: Friday, May 04, 2007 12:05 AM
> > To: Muhanna, Ahmad (RICH1:2H10); 'Kilian Weniger'; 
> > 'Jean-Mickael Guerin'; Khalil, Mohamed (RICH2:2S20); 'Vijay 
> > Devarapalli'
> > Cc: [email-masked]
> > Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number 
> based logic
> > 
> > Hi Ahmad:
> > 
> > Thanks for the clarification. So, I assume from all the 
> > offline and online email exchanges, the input is that:
> > 
> > - We can continue to have the time-stamp option as defined
> >   in the draft.
> > 
> > - We will also continue to support Per-MN sequence number,
> >   and in the absence of time stamp option, this will be used. 
> >   However, the exact mechanism of how this is transferred
> >   between MAG's or context transfer scheme is out the scope
> >   for this document.
> > 
> > - The PBA must return the MN-ID, for error code 135, for the
> >   MAG to be able to match the request to the response. As there
> >   may be a collision of sequence number for the pending requests
> >   for different mobiles, using their respective seq number.
> > 
> > I'm ok with this conclusion, if others agree.
> > 
> > Regards
> > Sri
> > 
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: Ahmad Muhanna [mailto:[email-masked]]
> > > Sent: Thursday, May 03, 2007 10:09 AM
> > > To: Sri Gundavelli; [email-masked]
> > > Cc: Kilian Weniger; Jean-Mickael Guerin; Mohamed Khalil; Vijay 
> > > Devarapalli
> > > Subject: RE: [netlmm] Issue: Timestamp vs Sequence Number 
> > based logic
> > > 
> > > 
> > > Hi Sri,
> > > 
> > > After some offline discussions, I would like to clarify one thing 
> > > about the use of SQN. I believe the per-MN SQN mechanism as per
> > > RFC3775 should
> > > work for PMIPv6 and it can address the race condition 
> specified in 
> > > this thread. For that cause, probably the following text 
> is a good 
> > > start for capturing this conclusion;
> > > 
> > > A Per-MN SQN mechanism, as per RFC3775, can address the 
> identified 
> > > race condition and also avoid a two round trip 
> registration during 
> > > inter-MAG handoff by using an out of scope mechanism to 
> > transfer the 
> > > MN session SQN state from the source MAG to the target MAG; e.g. 
> > > Context Transfer.
> > > 
> > > One last thing that probably an oversight of the PMIPv6 
> draft is the
> > > following: In order to enable a per-MN SQN mechanism in 
> the case of 
> > > PMIPv6, the MN-ID must be included in all P-BA, which is probably
> > > given.:)
> > > 
> > > Thanks for consideration.
> > > 
> > > Regards,
> > > Ahmad
> > >  
> > > 
> > > > -----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 ----->
> > > > 
> > > > 
> > > > 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
> > > > 
> > 

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Sat, 25 Aug 2007 00:00:09 -0500

Thanks Sri, looks good! 
I agree issue should be closed.

Regards,
Ahmad

> Sent: Friday, August 24, 2007 11:35 PM
> This is the adopted text for resolving the Timestamp vs 
> Sequence number issue. We have discussed this issue with 
> Ahmad, Kilian, Marco, Jean-Mickel and others some time back. 
> I think, we have covered all the cases. Please let us know, 
> if we are still missing any other case.
> 
> > 
> > 
> > To: Sri Gundavelli; Kilian Weniger; Jean-Mickael Guerin; Mohamed 
> > Khalil; Vijay Devarapalli
> > Cc: [email-masked]
> > > To: Muhanna, Ahmad (RICH1:2H10); 'Kilian Weniger'; 'Jean-Mickael 
> > > Guerin'; Khalil, Mohamed (RICH2:2S20); 'Vijay Devarapalli'
> > > Cc: [email-masked]
> offline and 
> > > online email exchanges, the input is that:
> > >

---

From: Vijay Devarapalli <[email-masked]>
Date: Sun, 26 Aug 2007 12:23:30 -0700

Sri Gundavelli wrote:

>    the received signaling messages from a mobile node.  

Re-write as

   Mobile IPv6 [RFC-3775] uses the Sequence Number field in the binding
   updates as a way for the home agent to process the binding updates in
   order they were sent by a mobile node.

>    address of the mobile node.

Suggest re-writing the above as

   If the local mobility anchor cannot determine the order in which the
   binding updates were sent, it may process an older binding update sent
   a MAG, resulting in an incorrect binding cache entry.

>    mobility anchor and the mobile access gateway.  

Shouldn't the above say required in the proxy binding update and proxy
binding ack? It says all messages between the LMA and the MAG. Is that
the intention?

>       Binding Acknowledgement message.

If the LMA does not support the timestamp option, it won't recognize
the option either. It will just ignore any mobility options that it
does not recognize. But why would an LMA not support the timestamp
option? Isn't support for the timestamp required? The use of the
option can ofcourse be optional.

>       the Proxy Binding Update message that it sent from its pending

Is this text out of place? The MN identifier being a must in all proxy
binding updates is already mentioned somewhere else, right? I suggest
deleting the above text.

Vijay

---

From: "Kilian Weniger" <[email-masked]>
Date: Mon, 27 Aug 2007 10:33:08 +0200

Hi Sri,

looks good, I just have two comments (please see inline).

BR,

Kilian

> Sent: Samstag, 25. August 2007 06:35
> To: 'Ahmad Muhanna'; 'Kilian Weniger'; 'Jean-Mickael Guerin'; 
> 'Mohamed Khalil'; 'Vijay Devarapalli'
> Cc: [email-masked]

I think "This document requires the use of Timestamp Option" is strictly
speaking not correct. We should require the implementation of this
option, but not the use of this option, since it is not required in a
deployment that supports context transfer. How about something along the
lines of

"An implementation MUST support the use of Timestamp Option, specified
in..."

>    all previously accepted timestamps.  The following additional

We should mention the optional use of the SN context transfer mechanism
here.

"An alternative mechanism for re-odering signaling mechanisms is to use
a sequence number based scheme, as per [RFC-3775].  The sequence number
MUST be maintained on a per mobile node basis and MUST be synchronized
between the serving mobile access gateways.  However, the specific
details on how a mobile node's sequence number is synchronized between
different mobile access gateways is outside the scope of this document."

>       timestamp option, the local mobility anchor MUST reject 

I think this cannot happen, if we say "MUST support timestamp option"

> the Proxy

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

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Mon, 27 Aug 2007 11:51:24 +0200

Fine by me, thanks everyone.

Jean-Mickael

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 27 Aug 2007 13:39:31 +0300

Hi,
 (Chair hat off)
In addition to the comments already sent I had two comments (See below):
> "An implementation MUST support the use of Timestamp Option, specified
I think Killian is correct. However, I would like to emphasize in this 
section that already that usage of sequence numbers are allowed if they 
are kept syncronized. E.g. "An implementation either MUST support Time 
stamp option defined in 8.4, or MUST maintain the sequence numbering on 
a per mobile node basis and MUST synchronize the sequence numbers 
between the serving mobile access gateways".

I think the current wording seems to have kind of two parts, which seem 
to be in conflict with each other.

My other comment is more general. I would like to entertain the idea 
that the redundant text between sections should be minimized. If 
something is explained somewhere else, it shouldn't be explained here. 
E.g. the following:

   "Section 8.4, in all signaling messages exchanged between the local
   mobility anchor and the mobile access gateway. The basic principle
   behind the use of Timestamp in mobility messages is that the node
   generating the message inserts the current time of the day, and the
   node receiving the message checks that this timestamp is greater than
   all previously accepted timestamps."

If section 8.4 explains time stamps, IMHO it is enough in this section 
that there is a reference to the section. Trying to do a mini summary 
here will only be confusing and bloat the document. In addition, I would 
like to see some kind of editorial division between the bullet points 
that explain the requirement for the time stamps and the bullet points 
that explain the requirement for sequence numbers. This makes the 
document more easily readable.

Cheers,

Jonne.

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 17:14:18 +0200

> This issue can be closed now.

Maybe yes.

But I personally think the resolution text is too long.

Why do you recommend NTP and not SNTP for example?  Why that old NTP rfc 
when more recent rfcs and implementations exist out there?

Why forcing the use of time-synchronized entities on the use PMIPv6? 
Any other protocol you know forces its entities to be time-synchronized?

NTP has a precision in the order of milliseconds.  I think two 
out-of-order P-BUs can happen within that millisecond and thus still 
having ordering issues.

Is it possible to develop a mechanism between MAGs and LMA that keeps a 
unique distributed counter per MN-id, without time synchronization.  You 
don't need CTX transfer for that, just add some options in the P-BAck 
from LMA to MAG to synchronize that counter.  MAG proposes a counter 
value, and LMA replies back with the value it has, then MAG does +1 and 
LMA replies back ok... this should work, a similar mechanism was already 
specified for Binding Cache entry lifetime negotiation... check 
rfc3775...  I can't believe NTP can do any better than that.

Alex

>>>>> 1. One additional round trip for all initial 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 08:18:02 -0700

Alex,

Alexandru Petrescu wrote:

> LMA replies back ok... 

This would result in two round trips for sending a proxy BU every time 
the MN moves. Not desirable. This was considered earlier and discarded.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 18:29:39 +0200

Vijay Devarapalli wrote:
>> Is it possible to develop a mechanism between MAGs and LMA that keeps 
>> a unique distributed counter per MN-id, without time synchronization.  
>> You don't need CTX transfer for that, just add some options in the 
>> P-BAck from LMA to MAG to synchronize that counter.  MAG proposes a 
>> counter value, and LMA replies back with the value it has, then MAG 
>> does +1 and LMA replies back ok... 
> 
> the MN moves.

Because NTP has no roundtrips at all?

> Not desirable. This was considered earlier and discarded.

A-ha.

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 09:38:25 -0700

> Because NTP has no roundtrips at all?

NTP happens in parallel. The handover is not put on hold pending an NTP 
sync. You can configure on the MAG and the LMA on how often to do the sync.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 18:48:55 +0200

Vijay Devarapalli wrote:
>>> This would result in two round trips for sending a proxy BU every
>>>  time the MN moves.
>> 
> NTP happens in parallel.

"In parallel"?  What happens if the concurrent ntp process hasn't yet
synchronized the clock and your out of order P-BU leaves the MAG?

> The handover is not put on hold pending an NTP sync. You can
> configure on the MAG and the LMA on how often to do the sync.

I agree handovers are unpredictable and can't be put on hold.

What if one MAG's LiIon BIOS battery dies out and the ntp frequency is 
to happen every 15min?  Then sure all out-of-order P-BUs will remain out 
of order during 15min...

Alex

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 09:58:44 -0700

> synchronized the clock and your out of order P-BU leaves the MAG?

In that case, the LMA rejects the Proxy BU with status code 148 (Invalid 
Time Stamp Option in the received Proxy Binding Update message) and 
sends the right timestamp in the Proxy Binding Acknowledgement. This 
would result in two round trips. But this done only when clocks are out 
of sync at the MAG and the LMA. This specified in the current base spec.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 19:17:53 +0200

Vijay Devarapalli wrote:
>> "In parallel"?  What happens if the concurrent ntp process hasn't
>> yet synchronized the clock and your out of order P-BU leaves the
>> MAG?
> 
> In that case, the LMA rejects the Proxy BU with status code 148
> (Invalid Time Stamp Option in the received Proxy Binding Update
> message) and sends the right timestamp in the Proxy Binding
> Acknowledgement.

In this case LMA doesn't need to have the actual time in the
'timestamp' fields.  A free running increasing counter is sufficient. 
If LMA receives a count less than it already has then it rejects it.

> This would result in two round trips. But this done only when clocks
> are out of sync at the MAG and the LMA. This specified in the current
> base spec.

And puts the NTP requirement on the whole system.

You'll still have to convince people to deploy NTP on their systems, 
IEEE 80216 doesn't.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 27 Aug 2007 13:03:11 -0500

> In that case, the LMA rejects the Proxy BU with status code 
> 148 (Invalid Time Stamp Option in the received Proxy Binding 
> Update message) and sends the right timestamp in the Proxy 
> Binding Acknowledgement. This would result in two round 
> trips. But this done only when clocks are out of sync at the 
> MAG and the LMA. This specified in the current base spec.

[Ahmad]
Can you elaborate on what you think the MAG will do in the second round
of BU/BA and how?
Also, do we need to capture that in the base protocol?

> > to happen every 15min?  Then sure all out-of-order P-BUs 
> will remain 
> > out of order during 15min...
> > 
> > Alex
> > 
> > 
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 11:05:44 -0700

> Also, do we need to capture that in the base protocol?

The MAG will use the updated timestamp from the LMA with that particular 
LMA. I think this is mentioned already in the base spec.

Vijay

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 27 Aug 2007 14:07:59 -0400

Hi Sri,
   While I think this text adequately covers the LMA operation, I don't 
think that it does so for the MAG operation. Especially, it does not 
cover the process of the MAG recovering from the case where the LMA does 
not support the timestamp option. I would propose adding the following 
text (or something like it).

o  If the MAG receives a Proxy Binding Acknowledgement
    message with Status field set to TIMESTAMP_OPTION_NOT_SUPPORTED
    (Timestamp not supported), it MUST resend the PBU to the LMA
    but it MUST NOT include the Timestamp option in the new PBU. The
    MAG SHOULD NOT send further PBU messages with the timestamp option
   to this LMA.

Thanks
Suresh

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 11:10:42 -0700

Suresh,

This may not be an issue. To my understanding, the support for Timestamp 
option at the LMA is a MUST. So I don't see 
TIMESTAMP_OPTION_NOT_SUPPORTED ever being returned in a Proxy Binding Ack.

In case the LMA does not support this option, it means that it does not 
recognize this option and it would skip this option. RFC 3775 says you 
skip any mobility option that you don't understand.

Vijay

Suresh Krishnan wrote:
>>> From: Ahmad Muhanna [mailto:[email-masked]] Sent: Thursday, May 
>>> 03, 2007 10:20 PM
>>> transferred between MAG's or context transfer scheme is out    of the 
>>> scope for this document.
>>>
>>>> From: Sri Gundavelli [mailto:[email-masked]] Sent: Friday, May 
>>>> 04, 2007 12:05 AM
>>>> Thanks for the clarification. So, I assume from all the offline and 
>>>>>> Correct Arriving Sequence: The correct sequence of packet arrival 
>>>>>> at the LMA is as
>>>>>> Possible Arriving Sequence: The possible sequence of packet 
>>>>>> arrival at the LMA is as
>>>>>> 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:
>>>>>> -------------------
>>>>>> Disadvantages: Requires NTP service in the PMIP domain and the clocks 
>>> on the LMA
>>>>>> the PBU. Once,     the MAG receives a successful PBA, it must again

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 20:13:36 +0200

Ahmad Muhanna wrote:
>> Acknowledgement. This would result in two round trips. But this
>> done only when clocks are out of sync at the MAG and the LMA. This
>> specified in the current base spec.
> 
> [Ahmad] Can you elaborate on what you think the MAG will do in the
> second round of BU/BA and how? Also, do we need to capture that in
> the base protocol?

Hi Ahmad, sorry I don't know who you're asking.  I think Vijay said this
is already spec'ed somehow.

I'm thinking I'm suggesting to remove out of the base spec all reliance
on NTP, all time syncing.  And then look to make P-BU/P-BAck reliable
with respect to ordering, without CTX transfer between MAGs.

Upon MN arrival MAG sends P-BU to LMA and if LMA already has a counter
for that MN-id then send it back to MAG, if not record it.  If MAG
receives a counter in the P-BAck then send to MAG that counter+1.  This
should work.  It's not 100% reliable but it's at least as reliable as if
ntp was used.

In the second round of BU/BAck MAG and LMA have already established a
counter level for a certain MN-id.  Where do you see a problem?

I think the mechanism could be rendered more reliable than just that but
even then time syncing is not needed.  TCP is very reliable and doesn't
rely on time syncing.

Alex

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

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 27 Aug 2007 14:52:39 -0400

Hi Vijay,

> TIMESTAMP_OPTION_NOT_SUPPORTED ever being returned in a Proxy Binding Ack.

So what is this text for in Sri's suggested resolution :-)?

       Binding Acknowledgement message. Vijay Devarapalli wrote:

If the authors agree that this option is a MUST for the LMA, you need to 
remove the above section. If it is optional, you need to add some text 
similar to the one I suggested.

Cheers
Suresh

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 27 Aug 2007 13:56:18 -0500

> >> Acknowledgement. This would result in two round trips. But 
> this done 
> >> only when clocks are out of sync at the MAG and the LMA. This 
> > second round of BU/BA and how? Also, do we need to capture 
> that in the 
> > base protocol?
> 
> Hi Ahmad, sorry I don't know who you're asking.  I think 
> Vijay said this is already spec'ed somehow.

Hi Alex,
Actually I was asking Vijay and he answered(-:-)
I do not recall seeing such text in the base but that is ok. I will be
checking the latest revision draft after Sri submit the new revision.
 
> 
> I'm thinking I'm suggesting to remove out of the base spec 
> all reliance on NTP, all time syncing.  And then look to make 
> P-BU/P-BAck reliable with respect to ordering, without CTX 
> transfer between MAGs.
> 
> Upon MN arrival MAG sends P-BU to LMA and if LMA already has 
> a counter for that MN-id then send it back to MAG, if not 
> record it.  If MAG receives a counter in the P-BAck then send 
> to MAG that counter+1.  This should work.  It's not 100% 
> reliable but it's at least as reliable as if ntp was used.
> 
> In the second round of BU/BAck MAG and LMA have already 
> established a counter level for a certain MN-id.  Where do 
> you see a problem?

[Ahmad]
I was not commenting on that:-)
However, what you are proposing probably is close to using "timestamp +
sequence number" together to guarantee in order sequencing. 

> 
> I think the mechanism could be rendered more reliable than 
> just that but even then time syncing is not needed.  TCP is 
> very reliable and doesn't rely on time syncing.
> 
> Alex
> 
> > 
> >> Vijay
> >>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 27 Aug 2007 13:54:17 -0700

Suresh Krishnan wrote:
> Hi Vijay,
> 
>> Suresh,
>>
>> This may not be an issue. To my understanding, the support for 
>> Timestamp option at the LMA is a MUST. So I don't see 

Not needed I think. I already commented on this.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Aug 2007 10:05:34 +0200

> Any other protocol you know forces its entities to be

FWIW, at least SEND requires time-synchronization so that freshness of 
unsolicited ND signalling can be verified through the use of timestamp. 

--julien

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Tue, 28 Aug 2007 18:01:27 +0900

Hi Sri,

I basically agree on your proposed texts, thanks.
here are some comments.

- As vijay and other said, LMA MUST support timestamp option.
- You may update this parts
   "These nodes SHOULD synchronize their clocks to a common time  
source using Network Time Protocol [RFC-1305]."
   NTP is just an example. You can introduce NTP but not with SHOULD.

regards,
ryuji

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Aug 2007 11:33:46 +0200

Julien Laganier wrote:
>> Why forcing the use of time-synchronized entities on the use
>> PMIPv6? Any other protocol you know forces its entities to be 
>> time-synchronized?
> 
> FWIW, at least SEND requires time-synchronization so that freshness
> of unsolicited ND signalling can be verified through the use of
> timestamp.

Hmmm, interesting... I think it could be done without real time stamps,
just sequence numbers.

FWIW, I _think_ IKEv2 doesn't use timestamps;  sure ND and MIP6
including RR don't use timestamps in messages.

Alex

---

From: Julien Laganier <[email-masked]>
Date: Tue, 28 Aug 2007 12:50:58 +0200

On Tuesday 28 August 2007, Alexandru Petrescu wrote:
> Hmmm, interesting... I think it could be done without real time
> stamps, just sequence numbers.
>

That's beyond the point. You asked "Any other protocol you know forces 
its entities to be time-synchronized?", so the the answer is yes. 
period.

--julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Aug 2007 13:58:45 +0200

> its entities to be time-synchronized?", so the the answer is yes. 

Hi Julien, I respect your point of view.  But I don't see any period 
anywhere.

SeND has a very nice statement on the use of NTP:
>    o  Attacks against time synchronization protocols such as NTP [23]
>       may cause SEND nodes to have an incorrect timestamp value.  This
>       can be used to launch replay attacks, even outside the normal
>       window of vulnerability.  To protect against these attacks, it is
>       recommended that SEND nodes keep independently maintained clocks
>       or apply suitable security measures for the time synchronization
>       protocols.

I'd substitute PMIPv6 for SeND and paste in the PMIPv6 document.

But that's beyond the point, as you say... I think relying on NTP or any 
other time synchronization for inner PMIPv6 working brings more trouble 
than help.

Please remove all timesynch reliance from PMIPv6.

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 28 Aug 2007 05:54:05 -0700

Hi Kilian,

> From: Kilian Weniger [mailto:[email-masked]] 
> Sent: Monday, August 27, 2007 1:33 AM
> To: Sri Gundavelli; Ahmad Muhanna; Kilian Weniger; 
> Jean-Mickael Guerin; Mohamed Khalil; Vijay Devarapalli
> Cc: [email-masked]

> "An implementation MUST support the use of Timestamp Option, specified

I agree with your reasoning. Implementations must support Timestamp option.

> different mobile access gateways is outside the scope of this 

Ok.

> I think this cannot happen, if we say "MUST support timestamp option"

Yes. We can remove that error code.

Thanks
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 28 Aug 2007 06:08:31 -0700

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Sunday, August 26, 2007 12:24 PM
> To: Sri Gundavelli
> Cc: 'Ahmad Muhanna'; 'Kilian Weniger'; 'Jean-Mickael Guerin'; 
> 'Mohamed Khalil'; [email-masked]
> Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic
> 
> Sri Gundavelli wrote:
> 

Ok. 

>    a MAG, resulting in an incorrect binding cache entry.

Fine.

> binding updates is already mentioned somewhere else, right? I suggest

In the message formats, we did identify the mandatory fields and that
includes the NAI. First part can be taken out. However, the use of
MN-Identifier for matching requests to response should be mentioned
here, cant rely on just by matching the timestamp value.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 28 Aug 2007 06:08:31 -0700

Hi Alex,

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Monday, August 27, 2007 8:14 AM
> To: Sri Gundavelli
> 'Mohamed Khalil'; 'Vijay Devarapalli'; [email-masked]

When we discussed this issue, I've listed the 5 possible solutions
(based on inputs from various people), you can see that email to
this email thread well. The consensus was to adopt the timestamp
based mechanism.

W.r.t the references to NTP, also as Ryuji pointed out, I agree 
NTP is just a reference. Deployments can adopt other methods for
synchronizing the clocks on the mobility entities in a PMIP6 
domain. 

Thanks
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 28 Aug 2007 06:08:31 -0700

Hi Suresh,

> From: Suresh Krishnan [mailto:[email-masked]] 
> Sent: Monday, August 27, 2007 11:08 AM
> To: Sri Gundavelli

With the suggestion from Kilian on mandating the implementation of
Timestamp option, I guess we can ignore this case. From the point of
view of the MAG,

- If there is a TS option in the PBU, LMA has to support it.
- If there is seq num in the PBU (no Timestamp), the LMA can either
  accept the PBU (if seq num is valid) or reject the PBU with the 135
  error code (Sequence number out of window)

So, not sure, if we are still missing any case from the MAG's operational
point of view when dealing with timestamp/seq numbers in signaling 
messages.

Thanks
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 28 Aug 2007 16:40:20 +0200

Hi Sri, I have some remarks... let me list some issues I have with
relying PMIPv6 on time synchronization... thanks for your email.

Sri Gundavelli wrote:
[...]
>> Is it possible to develop a mechanism between MAGs and LMA that 
>> keeps a unique distributed counter per MN-id, without time 
>> synchronization.  You don't need CTX transfer for that, just add 
>> some options in the P-BAck from LMA to MAG to synchronize that 
>> counter.  MAG proposes a counter value, and LMA replies back with 
>> the value it has, then MAG does +1 and LMA replies back ok... this
>>  should work, a similar mechanism was already specified for Binding
>>  Cache entry lifetime negotiation... check rfc3775...  I can't 
>> believe NTP can do any better than that.
>> 
> 
> 
> (based on inputs from various people), you can see that email to this
>  email thread well. The consensus was to adopt the timestamp based 
> mechanism.

I am not part of that consensus and I'm opposing any time-synch based
PMIPv6 and time-synch based authopt (this is another issue in mip6).

> W.r.t the references to NTP, also as Ryuji pointed out, I agree NTP 
> is just a reference. Deployments can adopt other methods for 
> synchronizing the clocks on the mobility entities in a PMIP6 domain.

I think Ryuji was right to suggest that but I don't think the solution
is enough to just call NTP just a possible solution.

NTP represents time in a certain manner and PMIPv6 uses that manner to
encode timestamps in PMIPv6 messages (64bit floatingpoint seconds since
1900).  If a deployer syncs his/her MAGs and LMAs with something else
than NTP (let's say with a dumb GPS receiver) then the format of time
representation may be completely different than NTP.

Or, that deployer doesn't implement NTP, so that deployer has to write
some NTP code in order to have PMIPv6 code to work.

Also, 80216 access networks use TIME protocol to send the time to the
client.  TIME represents time differently than NTP.  A 80216 deployer
wishing to sync time will have the choice of either TIME throughout
his/her network or write conversion software TIME-NTP.  I bet s/he will
choose the easier way: use TIME throughout.

ISO C 200X standard represents time in a different manner, counting
mainly since 1972; this making it more complicated to write PMIPv6
compatible software easily.

Finally, this is building into PMIPv6 the limit of 2^32 seconds since
1900, which means PMIPv6 may expose some overflowing issues in
a certain flag year (I believe it to be circa 2036, but not sure my
conversion is ok).  I don't think one wants PMIPv6 to have Y2K-like issues.

Thanks,

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 28 Aug 2007 09:48:08 -0700

Hi Alex,

Please see inline.

> Sent: Tuesday, August 28, 2007 7:40 AM
> To: Sri Gundavelli
> Cc: 'Alexandru Petrescu'; 'Ahmad Muhanna'; 'Kilian Weniger'; 
> 'Jean-Mickael Guerin'; 'Mohamed Khalil'; 'Vijay Devarapalli'; 
> [email-masked]

I did see that you did not state your preference on this earlier. 
IMO, we should not reopen this thread. Quite a few people agreed to
this. Also, the motivation factor for this approach is Mobile IPv4.
Today, many MIP4 deployments use Timestamp based approach and it works
quite well. Besides this, I'm certain almost all deployments will solve
this issue using context transfer schemes and so this solution in the
base draft is sufficient, IMO. Also, there is some cost with all the
other solutions as well.

> representation may be completely different than NTP.

I had this explicitly stated, so there is no confusion to implementors.
"The NTP timestamp is the representation of elapsed time in seconds, since,
1st January 1900." 
Because, unix systems give elapsed time since 1972. Implementations have
to add the appropriate delta to the generated timestamp, when it is based
on some other reference point. But, this is a simple delta generation logic
and MIP4 windows clients do that as well. 

> conversion is ok).  I don't think one wants PMIPv6 to have 

There will be a rollover after 2036. That's given with NTP format.
But, implementations should be able to handle this.
 
Thanks
Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 28 Aug 2007 11:51:57 -0700

Hi Jonne,

> From: Soininen Jonne (NSN - FI/Espoo) [mailto:[email-masked]] 
> Sent: Monday, August 27, 2007 3:40 AM
> To: ext Kilian Weniger
> Cc: Sri Gundavelli; Ahmad Muhanna; Jean-Mickael Guerin; 
> Mohamed Khalil; Vijay Devarapalli; [email-masked]
> The home agent
> here will only be confusing and bloat the document. 

Ok. I see your point. Will do that. In some places, a one line repeat
of some earlier text gives the completeness to the section and keeps
the continuity. But, will try to avoid this.

In 
> addition, I would 

Ok.
 
Thanks
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Aug 2007 14:24:43 +0200

Hi Sri,
[...]
> Today, many MIP4 deployments use Timestamp based approach and it 
> works quite well.

I elaborate below on the MIP4 aspect...

> Besides this, I'm certain almost all deployments will solve this 
> issue using context transfer schemes and so this solution in the base
>  draft is sufficient, IMO.

It is so strange to says so... why do you say so?  If a deployment 
doesn't use neither timestamps nor seqnos to ensure proper ordering then 
why don't we suggest _that_ behaviour?

> Also, there is some cost with all the other solutions as well.

I agree to this, there's always cost in some new not yet specified
mechanism.

>> I think Ryuji was right to suggest that but I don't think the 
>> solution is enough to just call NTP just a possible solution.
>> 
>> NTP represents time in a certain manner and PMIPv6 uses that manner
>>  to encode timestamps in PMIPv6 messages (64bit floatingpoint 
>> seconds since 1900).  If a deployer syncs his/her MAGs and LMAs 
>> with something else than NTP (let's say with a dumb GPS receiver) 
>> then the format of time representation may be completely different
>>  than NTP.
>> 
> 
> I had this explicitly stated, so there is no confusion to 
> implementors. "The NTP timestamp is the representation of elapsed 
> time in seconds, since, 1st January 1900." Because, unix systems give
>  elapsed time since 1972. Implementations have to add the appropriate
>  delta to the generated timestamp, when it is based on some other 
> reference point. But, this is a simple delta generation logic and 
> MIP4 windows clients do that as well.

MIP4?

I am not sure a MIP4 or PMIPv4 software can easily be reused for
P-MIPv6... there are so many changes that should be made for IPv6.

New software for P-MIPv6 has to be written from scratch, it's obvious,
and not migration or porting from P-MIPv4.

A good path to develop P-MIPv6 is to start with MIPv6 implementation and
extend it, not to start with MIP4.  MIP4 implementation is a good start
for PMIPv4.

This is IMHO.

I think the timestamp feature present in MIP4 is not necessarily a good
advantage in porting to P-MIPv6.

>> Finally, this is building into PMIPv6 the limit of 2^32 seconds 
>> since 1900, which means PMIPv6 may expose some overflowing issues 
>> in a certain flag year (I believe it to be circa 2036, but not sure
>>  my conversion is ok).  I don't think one wants PMIPv6 to have 
>> Y2K-like issues.
>> 
> 

If we'd like the PMIPv6 spec to survive rollovers at year 2036 then we
should write in the spec how to do it, right?  Otherwise acknowledge
there may be some handover issues in year 2036, right?  Isn't this too
much a burden?  Isn't it simpler to simply not rely on timestamps?

Thanks,

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Wed, 29 Aug 2007 05:55:48 -0700

Hi Alex,

> Sent: Wednesday, August 29, 2007 5:25 AM
> To: Sri Gundavelli

My point is that the delta generation logic is simple. When I say,
MIP4 does it, the idea is not about porting MIP4. But, to show that
its a trivial logic to generate a timestamp in NTP format, even
when other formats are in use. Its about representation of elapsed
time, since reference point A or reference point B.

We can certainly state that the the LMA will see an incorrect seq
in re-registrations received for all mobile node's (mobile nodes that
have active sessions). The LMA must factor this rollover is determining
the validity of the seq number. 

There are other ways to deal with this issue. The LMA can revoke all
bindings are send a notification message to mobile nodes to re-register
after 2036. All of this, if PMIP6 comes out and survives till 2036 :).

Hope you are ok with this.

Regards
Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Aug 2007 15:12:04 +0200

Sri Gundavelli wrote:
[...]
>>>>  since 1900, which means PMIPv6 may expose some overflowing 
>>>> issues in a certain flag year (I believe it to be circa 2036, 
>>>> but not sure my conversion is ok).  I don't think one wants 
>>>> PMIPv6 to have Y2K-like issues.
>>>> 
>>> There will be a rollover after 2036. That's given with NTP 
>>> format. But, implementations should be able to handle this.
>> If we'd like the PMIPv6 spec to survive rollovers at year 2036 then
>>  we should write in the spec how to do it, right?  Otherwise 
>> acknowledge there may be some handover issues in year 2036, right?
>>  Isn't this too much a burden?  Isn't it simpler to simply not rely
>>  on timestamps?
>> 
> 
> its a trivial logic to generate a timestamp in NTP format, even when
>  other formats are in use. Its about representation of elapsed time,
>  since reference point A or reference point B.

Yes, but if we start implementing PMIPv6 from a MIPv6 base then the
timestamp implementation is certainly a new feature to be implemented,
new code to be written both for HA and MAG.

Even if you and me agree that the delta generation could be simple.

> We can certainly state that the the LMA will see an incorrect seq in
>  re-registrations received for all mobile node's (mobile nodes that 
> have active sessions). The LMA must factor this rollover is 
> determining the validity of the seq number.

I think this is too complicated, to manage the yr2036 timestamp rollover
by relying on seqnos... I thought we were assuming that either one or
the other is used.

It's obviously redundant to implement both seqnos and timestamps.

> bindings are send a notification message to mobile nodes to 
> re-register after 2036.

A-ha... another reason to use binding revocation (check mip6 WG call for
draft adoption on binding revocation).  It seems a bit to introduce
service disruption at midnight.  But if people agree to use binding
revocation that and only that should be specified in the pmipv6 spec
(and not timestamps), I think.

> All of this, if PMIP6 comes out and survives till 2036 :).

(Sri, I think PMIP6 will come out, there's no doubt about that... :-)
(and about surviving into 2036... NTP RFC was issued in 1992
  and 15years later we still feel like needing to use it.)

Alex

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 29 Aug 2007 16:11:58 +0300

Hello everybody,

<chairman hat on>
There has been the consensus in the past that time-stamp option can be 
used to understand, which BU came first as the PMIP base spec does not 
specify the way to synchronize the MAGs. There is also the option to use 
sequence numbers, if you remember to synchronize the sequence numbers.

Thus, if somebody wants to challenge the consensus (having just one 
person actively being against the consensus does not change the 
consensus), please, put out new arguments why the consensus should be 
reversed. Saying that NTP is not good is not enough.

<chairman hat off>

Cheers,

Jonne.
ext Sri Gundavelli wrote:
>>> issue using context transfer schemes and so this solution 
>>>       
>> in the base
>>     
>>> time in seconds, since, 1st January 1900." Because, unix 
>>>       
>> systems give
>>     
>>>  elapsed time since 1972. Implementations have to add the 
>>>       
>> appropriate
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Aug 2007 15:20:17 +0200

Soininen Jonne (NSN - FI/Espoo) wrote:
> Hello everybody,
> 
> <chairman hat on> There has been the consensus in the past that
> time-stamp option can be used to understand, which BU came first as
> the PMIP base spec does not specify the way to synchronize the MAGs.
> There is also the option to use sequence numbers, if you remember to
> synchronize the sequence numbers.
> 

Hi Jonne, thanks, I've just listed the item by item, please pick one:

-use of NTP timestamp format is incompatible with ISO C 200X.
-use of NTP protocol for syncing is incompatible with IEEE 802.16
  requiring TIME instead of NTP.
-use of timestamps to avoid sequencing issues upon handovers is new
  software development (if starting from MIP6 and going to PMIP6),
  whereas the problem could be solved with seqno tools from MIP6.
-use of NTP timestamps obviously has problems of solving the sequencing
  problem in year 2036.

Thanks,

Alex

> 
> Cheers,
> 
> Jonne. ext Sri Gundavelli wrote:
>> Hi Alex,
>> 
>> 
>> 
>>> -----Original Message----- From: Alexandru Petrescu
>>> [mailto:[email-masked]] Sent: Wednesday, August 29,
>>> 2007 5:25 AM To: Sri Gundavelli Cc: 'Alexandru Petrescu'; 'Ahmad
>>> Muhanna'; 'Kilian Weniger'; 'Jean-Mickael Guerin'; 'Mohamed
>>> Khalil'; 'Vijay Devarapalli'; [email-masked] Subject: Re:
>>> [netlmm] Issue: Timestamp vs Sequence Number based logic
>>> 
>>> Hi Sri, [...]
>>> 
>>>> I did see that you did not state your preference on this
>>>> earlier. IMO, we should not reopen this thread. Quite a few
>>>> people agreed to this. Also, the motivation factor for this
>>>> approach is Mobile IPv4. Today, many MIP4 deployments use
>>>> Timestamp based approach and it works quite well.
>>>> 
>>>> Besides this, I'm certain almost all deployments will solve
>>>> this issue using context transfer schemes and so this solution
>>>> 
>>> in the base
>>> 
>>> It is so strange to says so... why do you say so?  If a
>>> deployment doesn't use neither timestamps nor seqnos to ensure
>>> proper ordering then why don't we suggest _that_ behaviour?
>>> 
>>> 
>>> I agree to this, there's always cost in some new not yet
>>> specified mechanism.
>>> 
>>> 
>>>>>> W.r.t the references to NTP, also as Ryuji pointed out, I
>>>>>> agree NTP is just a reference. Deployments can adopt other
>>>>>> methods for synchronizing the clocks on the mobility
>>>>>> entities in a PMIP6 domain.
>>>>>> 
>>>>> NTP represents time in a certain manner and PMIPv6 uses that
>>>>> manner to encode timestamps in PMIPv6 messages (64bit
>>>>> floatingpoint seconds since 1900).  If a deployer syncs
>>>>> his/her MAGs and LMAs with something else than NTP (let's say
>>>>> with a dumb GPS receiver) then the format of time
>>>> implementors. "The NTP timestamp is the representation of
>>>> elapsed time in seconds, since, 1st January 1900." Because,
>>>> unix
>>> systems give
>>> 
>>>> delta to the generated timestamp, when it is based on some
>>>> other reference point. But, this is a simple delta generation
>>>> logic and MIP4 windows clients do that as well.
>>>> 
>>> MIP4?
>>> 
>>> New software for P-MIPv6 has to be written from scratch, it's
>>> obvious, and not migration or porting from P-MIPv4.
>>> 
>>> A good path to develop P-MIPv6 is to start with MIPv6
>>> implementation and extend it, not to start with MIP4.  MIP4
>>> implementation is a good start for PMIPv4.
>>> 
>>> This is IMHO.
>>> 
>>> I think the timestamp feature present in MIP4 is not necessarily
>>> a good advantage in porting to P-MIPv6.
>>> 
>>> 
>>>>> Finally, this is building into PMIPv6 the limit of 2^32
>>>>> seconds since 1900, which means PMIPv6 may expose some
>>>>> overflowing issues in a certain flag year (I believe it to be
>>>>> circa 2036, but not sure my conversion is ok).  I don't think
>>>>> one wants PMIPv6 to have Y2K-like issues.
>>>>> 
>>>>> 
>>> If we'd like the PMIPv6 spec to survive rollovers at year 2036
>>> then we should write in the spec how to do it, right?  Otherwise
>>> acknowledge there may be some handover issues in year 2036,
>>> right?  Isn't this too much a burden?  Isn't it simpler to simply
>>> not rely on timestamps?
>>> 
>>> 
>> 
>> in re-registrations received for all mobile node's (mobile nodes
>> that have active sessions). The LMA must factor this rollover is
>> determining the validity of the seq number. There are other ways to
>> deal with this issue. The LMA can revoke all bindings are send a
>> notification message to mobile nodes to re-register after 2036. All
>> of this, if PMIP6 comes out and survives till 2036 :).
>> 
>> Regards Sri

---

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Wed, 29 Aug 2007 16:35:59 +0300

Alex,

<chairman hat on>

It is not me you have to convince, but the WG. Currently, I don't see 
support for you. Of course, if people are interested in Alex'es point of 
view or somebody thinks this is major problem, consensus can be of 
course changed. However, it is not clear that at the moment such a 
support exists.

<chairman hat off>

Cheers,

Jonne.
ext Alexandru Petrescu wrote:
>>> re-registrations received for all mobile node's (mobile nodes

---

From: Julien Laganier <[email-masked]>
Date: Thu, 30 Aug 2007 17:13:52 +0200

On Wednesday 29 August 2007, Alexandru Petrescu wrote:
> -use of NTP timestamps obviously has problems of solving the
> sequencing problem in year 2036.

May I suggest that we solve that specific issue brought up by Alex by 
adopting a timestamp format similar to that of SEND [RFC3971] that will 
still work for the next 8 million years while still preserving a 
precision that seems more than sufficient:

>
>   Timestamp
>
>       A 64-bit unsigned integer field containing a timestamp.  The
>       value indicates the number of seconds since January 1, 1970,
>       00:00 UTC, by using a fixed point format.  In this format, the
>       integer number of seconds is contained in the first 48 bits of
>       the field, and the remaining 16 bits indicate the number of
>       1/64K fractions of a second.
>
>       Implementation note: This format is compatible with the usual
>       representation of time under UNIX, although the number of bits
>       available for the integer and fraction parts may vary.

Thoughts?

--julien

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 30 Aug 2007 08:53:12 -0700

Hi Julien,

> From: Julien Laganier [mailto:[email-masked]] 
> Sent: Thursday, August 30, 2007 8:14 AM
> To: [email-masked]
> Cc: 'Kilian Weniger'; 'Vijay Devarapalli'

I hate to make changes at this point. But, this is a simple change
and the format is still 64-bit, and infact I did think about this,
but, I preferred to keep it closer to the MIP4 format. If others
dont have an issue, I will make this change and we will publish the
draft. Hopefully, this will fix Alex's concerns.

Sri