Subject: [netlmm] About the use of Timestamp to match a request

From: Nicolas Dichtel <[email-masked]>
Date: Thu, 17 Jan 2008 17:09:08 +0100

Hi all,

Section 6.9.1, Paragraph "Receiving Binding Registration Reply", bullet 5
(page 41):

   "5.   If the Timestamp option is present in the received Proxy Binding
         Acknowledgement message and with the Status field value set to
         any value other than TIMESTAMP_MISMATCH (Invalid Timestamp), the
         mobile access gateway MAY use the timestamp value for matching
         the response to the request message that it sent recently."

However, due to Section 5.5, bullet 8 (page 30) timestamp cannot be used to
match the request if status of the BA is TIMESTAMP_LOWER_THAN_PREV_ACCEPTED:

   "8.  If the timestamp value in the received Proxy Binding Update is
        lower than the previously accepted timestamp in the Proxy Binding
        Update messages sent for that mobility binding, the local
        mobility anchor MUST reject the Proxy Binding Update request and
        send a Proxy Binding Acknowledgement message with Status field
        set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than
        previously accepted timestamp).  The message MUST also include
        the Timestamp option with the value set to the current time-of-
        day on the local mobility anchor."

Regards,
Nicolas

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 17 Jan 2008 09:15:37 -0800 (PST)

Hi Nicolas,

>        day on the local mobility anchor."

We added this new error code (TIMESTAMP_LOWER_THAN_PREV_ACCEPTED)
recently, for providing more granularity for the timestamp mismatch.
Now, when returning any of these two error codes as supposed to one,
we return a new stamp and sure it cant be used matching the req/reply.
Will add both the error codes to 6.9.1 (#5).

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 18 Jan 2008 07:54:58 -0600

Sri,

Why is that the case?

Are you saying that, for example, in RFC3344 (MIP4) when the RRP has a
timestamp mismatch, the RRP is not used for matching the RRQ?

Please clarify.

Regards,
Ahmad

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Thursday, January 17, 2008 11:16 AM
> To: Nicolas Dichtel
> Cc: 'netlmm'
> Subject: Re: [netlmm] About the use of Timestamp to match a request
> 
> Hi Nicolas,
> 
> > Section 6.9.1, Paragraph "Receiving Binding Registration Reply", 
> > bullet 5 (page 41):
> >
> > However, due to Section 5.5, bullet 8 (page 30) timestamp cannot be 
> > used to match the request if status of the BA is 
> TIMESTAMP_LOWER_THAN_PREV_ACCEPTED:
> >
> Now, when returning any of these two error codes as supposed 
> to one, we return a new stamp and sure it cant be used 
> matching the req/reply.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 22 Jan 2008 09:34:51 -0800

Hi Ahmad,

> From: Ahmad Muhanna [mailto:[email-masked]] 
> Sent: Friday, January 18, 2008 5:55 AM
> To: Sri Gundavelli; Nicolas Dichtel
> Cc: netlmm
> Subject: RE: [netlmm] About the use of Timestamp to match a request
> 
> Sri,
> 
> Why is that the case?
> 

When the LMA returns its own timestamp in case of mismatch, we just had
one return code in the past. Per discussions with Kilian/ML, in -06 version
of the draft we defined one more specific error code. Now, the MAG on
receiving either of the error codes, it should know the timestamp is the
LMA's timestamp and the consideration w.r.t bullet 5 (Sec 6.9.1) for both
the error codes, as supposed to one.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 22 Jan 2008 15:39:31 -0600

Hi Sri,

If the timestamp is used for ordering and matching P-BA to the
outstanding P-BU, the timestamp mechanism should provide the ability for
the MAG to identify the outstanding P-BU which matches the received
P-BA. In case of collision, then the MAG can use other parameters to
find the exact match.

I did not look at the section 6.9.1. lately but my understanding is that
the timestamp format consists of the timestamp up to the second and the
rest is used as a fraction of the second or a random number, which is
returned by the LMA in the P-BA as is, even in the case of timestamp
mismatch error.

Regards,
Ahmad

> Sent: Tuesday, January 22, 2008 11:35 AM
> To: Muhanna, Ahmad (RICH1:2H10); 'Nicolas Dichtel'
> Cc: 'netlmm'
> When the LMA returns its own timestamp in case of mismatch, 
> we just had one return code in the past. Per discussions with 
> Kilian/ML, in -06 version of the draft we defined one more 
> specific error code. Now, the MAG on receiving either of the 
> error codes, it should know the timestamp is the LMA's 
> timestamp and the consideration w.r.t bullet 5 (Sec 6.9.1) 
> for both the error codes, as supposed to one.
> 
> Regards
> Sri
> 
> 
> 
> > Please clarify.
> > 
> > Regards,
> > Ahmad
> >  
> >

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 22 Jan 2008 13:59:43 -0800 (PST)

Hi Ahmad,

> P-BA. In case of collision, then the MAG can use other parameters to

Sure. The MAG can use the timestamp in the reply to match the
request, except in cases when it returns its own timestamp. In
such scenario, the MAG can use the MN-Id to identify the request
to the reply. Optionally, it can also use a monotonically
increasing sequence number in the request and the LMA will
always ignore the seq number field when timestamp option is
present, but will copy the seq number from request to the reply.
As supposed to splitting the timestamp into upper and lower
halfs and overloading the option, as the sequence number field
is unused, this approach was chosen, if you remember.

Regards
Sri