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

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 27 Aug 2007 08:41:04 -0700 (PDT)

Hi Alex,
  Sorry but I disagree. Why should we not force (or require) MAGs to be time synchronized? Even most laptops implement time synchronization these days once they are connected to the Internet. Why not MAGs?
  On the mechanism you mentioned in RFC 3775, is it binding lifetime (BINDING_REFRESH)? Which section of 3775 is it specified? I don't think there is a compatible mechanism used in RFC 3775 that we can adopt in PMIP.

Regards,

Behcet

----- Original Message ----
From: Alexandru Petrescu <[email-masked]>
To: Sri Gundavelli <[email-masked]>
Cc: Kilian Weniger <[email-masked]>; [email-masked]; Vijay Devarapalli <[email-masked]>
Sent: Monday, August 27, 2007 10:14:18 AM
Subject: Re: [netlmm] Issue: Timestamp vs Sequence Number based logic

Sri Gundavelli wrote:
> 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.

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

> 
> 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
> 

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

_______________________________________________
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: Alexandru Petrescu <[email-masked]>
Date: Mon, 27 Aug 2007 18:34:49 +0200

Behcet Sarikaya wrote:
> Hi Alex, Sorry but I disagree. Why should we not force (or require) 
> MAGs to be time synchronized?

BEcause no other protocol does.

> Even most laptops implement time synchronization these days once they
>  are connected to the Internet. Why not MAGs?

Because MAGs are infrastructure and laptops are endusers.

Someone's hand watch can be NTP synchronized too, but because its main 
function is to show the time...

> On the mechanism you mentioned in RFC 3775, is it binding lifetime
> (BINDING_REFRESH)? Which section of 3775 is it specified? I don't
> think there is a compatible mechanism used in RFC 3775 that we can
> adopt in PMIP.

The 3775 BU proposes a lifetime and the HA accepts or suggests another 
one in the BAck (search 'lifetime').  Same thing could be for sequence 
numbers per mn id.

Relying on time synchronization is not a good tool to design reliable 
protocols.  This is my humble oppinion and feel free to vote against it.

Alex

---

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

On Monday 27 August 2007, Alexandru Petrescu wrote:
> > Even most laptops implement time synchronization these days once
> > they are connected to the Internet. Why not MAGs?
>

And that's exactly because MAGs are infrastructure that we can expect 
them to be time synchronized thru the use of another piece of the 
infrastructure (NTP).

MAGs are NOT random unmanaged laptops.

--julien