Subject: [netlmm] The Use of Timestamp in PMIPv6

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 2 Feb 2007 00:08:27 -0600

Hi Sri, et. al,

Sorry if some of these points have been addressed; at least from my
reading, I have not seen a posting which addressed them.

1. According to RFC3775 under section 6.1.8.: Binding Acknowledgement
Message, it reads:

"
   Sequence #

      The Sequence Number in the Binding Acknowledgement is copied from
      the Sequence Number field in the Binding Update.  It is used by
      the mobile node in matching this Binding Acknowledgement with an
      outstanding Binding Update.
"

I have not been able to find the details in the draft on how to use the
timestamp to accomplish the same thing at the side of the MAG. Is that
assumed to be an implementation specific?

2. The draft assumes that all Network nodes including all LMAs and MAGs
(using the latest terminologies) will have their clocks synchronized to
the second at all times. IMHO, this assumption is probably not that
reasonable. At least in one incident the draft listed a scenario in
which LMA needs to send a P-BA with an error code for invalid time
stamp. I believe we need to handle the scenarios when these boxes go out
of sync.

3. Correct me if I am wrong, my reading to the draft makes me believe
that the time stamp at the LMA is considered as a global variable. In
other words, LMA compares the timestamp in the BU to its clock time to
find the correct order of BUs?
Is that a correct assumption?

4. Under section 5.5.  Sequencing Number Considerations, it reads:

"
   In Proxy Mobile IPv6, the Binding Update messages that the home agent
   receives on behalf of a specific mobile, may not be from the same
   proxy mobile agent and thus the sequence number value in these
   messages will have little meaning and the home agent will not be
   predictably order the messages and thus may end up processing an
   older message while ignoring the latest binding update message.
"

To be honest, I do not understand how does the draft concludes that
sequence number has a little meaning here?

Regards,
Ahmad

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

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 1 Feb 2007 22:57:18 -0800 (PST)

Hi Ahmad,

> reading, I have not seen a posting which addressed them.

Yes. This was discussed couple of times. To summarize:

- In the absence of Context Transfer mechanism, it is not possible
   for the serving proxy mobile agent to detect the correct sequence
   number that it needs to use in the BU Messages.

- The home agent can always return the Seq Number that the proxy
   mobile agent needs to send in the BU messages, but that will
   always fail the first PBU message.

- As in Mobile IPv4 and also for replay protection in Auth Option
   draft, time stamp option needs to added to the PBU/PBA messages.
   Further, the entities can use NTP to synchronize the clocks.

- Also, when the mobile does the direct MIP6 signaling, its is
   not possible to sync the sequence number.

> assumed to be an implementation specific?

The entity sending the Proxy Binding Update/Ack should add a
Time Stamp option to the message. If the text is not clear, we
will certainly improve it.

> I believe we need to handle the scenarios when these boxes go out
> of sync.

Agreed. We can make the home agent return the correct time stamp
that the proxy should use.

> Is that a correct assumption?

Yes. When multiple entities are involved, the ordering of messages
can be established using time stamp options present in the Proxy
BU messages.

> sequence number has a little meaning here?

In the context of Proxy Model, its difficult to make the protocol work
using Sequence Numbers. We believe, time stamp fits well for the model.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 2 Feb 2007 01:55:45 -0600

Hi Sri,

Thanks for the quick response. Please see some comments/clarifications
below.

Regards,
Ahmad

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Friday, February 02, 2007 12:57 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]
> Subject: Re: The Use of Timestamp in PMIPv6
> 
> Hi Ahmad,
> 
> 
> 
> > I have not been able to find the details in the draft on how to use 
> > the timestamp to accomplish the same thing at the side of 
> the MAG. Is 
> > that assumed to be an implementation specific?
> >
> 
> Time Stamp option to the message. 

[Ahmad]
It is not a matter of each entity include the timestamp option here. The
problem is that the MAG needs to be able to use the timestamp somehow to
match the BA to the outstanding BU. I would recommend the following:

1. The draft needs to address the format of the timestamp in details. In
other words, what goes in the high order 32 bits and what in the low
order 32 bits. A good example of such format should be found in RFC3344.

2. In success scenarios, the LMA must copy the timestamp as is from the
timestamp option in BU and returns in the timestamp option P-BA, this
way the MAG will be able to match the BA to the outstanding P-BU. 

Now that the case in RFC3344 but in the case of P-MIPv6 we are talking
about two different agents here, LMA and MAG while in RFC3344 it is MN
<-> HA. i.e. In PMIP we could always return the LMA timestamp in the
high order 32 bits for example and keep the low 32 bits as is for the
MAG to use in matching P-BA to P-BU. This makes the MAG always aware of
the LMA timestamp.

3. In case of error related to timestamp and sequencing, LMA always
copies the low 32 bit of the timestamp option in BU into the low  32
bits of timestamp option in the P-BA and inserts its correct timestamp
in the high order 32 bits.

4. One last thing, the draft has to clearly document what is going to
happen for retransmitted packets.

**If you would like me to help with the needed text, I will be happy to
do so.**

> If the text is not clear, 
> we will certainly improve it.
> 
> > I believe we need to handle the scenarios when these boxes 
> go out of 
> > sync.
> 
> Agreed. We can make the home agent return the correct time 
> stamp that the proxy should use.

[Ahmad]
Please see details above.
> Yes. When multiple entities are involved, the ordering of 
> messages can be established using time stamp options present 
> in the Proxy BU messages.

[Ahmad]
The MAG could send many BUs for different MNs per minute to the same
LMA. There is nothing guarantees that these BUs will arrive in sequence.
What the LMA is supposed to do, accept the first one and drop the rest.
I mean this needs to be clarified. In order to reduce IOT overhead
activities and for this to work, we need the details. In other words,
how the LMA<->MAG will use the timestamp in order for this protocol to
work.

> In the context of Proxy Model, its difficult to make the 
> protocol work using Sequence Numbers. We believe, time stamp 
> fits well for the model.

[Ahmad]
Of course if we look at the replay protection as if it is per MN issue,
we will have a problem. However, you guys in order to make this protocol
to work, you chose to have a per-Node SA. Excellent, then why not use a
per Node replay protection for this protocol. What I mean here is we can
treat the sequence number per a pair of MAG<->LMA.

What I meant to say, I believe SQN could be made to work and the
statement that it will have little meaning is not accurate.

Finally, since SQN is already in the P-BU/P-BA, Is it a good idea to use
the combination of both SQN and timestamp? It will make the protocol
more robust to problems that may arise from timestamp synchronization.

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 2 Feb 2007 11:17:58 -0800 (PST)

Hi Ahmad,

Thanks for the detailed questions. Agree, we need to
add more text and be detailed on this. We have fixed
some things in the latest rev and will talk to you
more on this to ensure, we are not missing any thing.

Regards
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 2 Feb 2007 23:55:44 -0600

Hi Sri,
Sure. However, you probably missed my earlier response with the details
that the draft did not address. 
Just in case you did not see it, I am attaching it for your reference. 

Regards,
Ahmad

> Sent: Friday, February 02, 2007 1:18 PM
> Thanks for the detailed questions. Agree, we need to add more 
> text and be detailed on this. We have fixed some things in 
> the latest rev and will talk to you more on this to ensure, 
> we are not missing any thing.
> 
> Regards
> Sri
> 
> > 2. The draft assumes that all Network nodes including all LMAs and 
> > MAGs (using the latest terminologies) will have their clocks 
> > synchronized to the second at all times. IMHO, this assumption is 
> > probably not that reasonable. At least in one incident the draft 
> > listed a scenario in which LMA needs to send a P-BA with an 
> error code 
> > for invalid time stamp. I believe we need to handle the 
> scenarios when 
> > these boxes go out of sync.
> >

Subject: RE: The Use of Timestamp in PMIPv6
From: "Muhanna, Ahmad \(RICH1:2H10\)" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 2 Feb 2007 01:55:45 -0600

Hi Sri,

Regards,
Ahmad

[Ahmad]

[Ahmad]

[Ahmad]

[Ahmad]

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 3 Feb 2007 09:48:52 -0800 (PST)

Hi Ahmad,

Please see inline..

> match the BA to the outstanding BU. I would recommend the following:

Ok. We just wanted to use the timestamp mechanism as in Mobile IPv4.
Some details are certainly missing as you have pointed out. We need
to fix them.

> order 32 bits. A good example of such format should be found in RFC3344.

Ok

> way the MAG will be able to match the BA to the outstanding P-BU.

Ok

> MAG to use in matching P-BA to P-BU. This makes the MAG always aware of

Ok

> in the high order 32 bits.

Ok

> happen for retransmitted packets.

In the next rev, we did some work on this. With this input, we will
fix the details.

> **If you would like me to help with the needed text, I will be happy to

Thanks. We will talk to you. Just want to close up on few highlever 
issues and can focus on the details.

> how the LMA<->MAG will use the timestamp in order for this protocol to

The BU's received by the home agent from the proxy mobile agent for
different MN's do not have to be ordered. The home agent needs to
process all the BU's. Also, the BU's are protected by IPSec ESP header
and there is a ESP sequence number.

> treat the sequence number per a pair of MAG<->LMA.

The issue is not related to replay protection. That is assured by the
IPSec ESP header. We need sequencing to cover the scenario, where a
mobile keeps moving between two PMA's and the PMA's starts sending
PBU's, if the messages reach the home agent in out of order, the
home agent may accept an older registration. Since, the IPSec sessions
for the two PMA's are different, the sequence number in the ESP
header is not sufficient.

> statement that it will have little meaning is not accurate.

This is in the context of the sequence number present in the BU.
For the protocol to support both PMIP and CMIP modes, for PMIP
we rather use a different scheme and that was the comment.

> more robust to problems that may arise from timestamp synchronization.

Agreed. Appreciate your attention to the details. Now we will focus
on these finer details.

Thanks
Sri

---

From: "Mohamed Khalil" <[email-masked]>
Date: Mon, 5 Feb 2007 09:59:49 -0600

Ya Dr. Ahamd, AA I think we should keep the issues of massive BY from
MAG which we discussed last Friday from sharing in the mailing list
until we patent the issues and solutions. We have discussed some
solutions such as Time stamp and SN combination.

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Saturday, February 03, 2007 11:49 AM
To: Muhanna, Ahmad (RICH1:2H10)
Cc: [email-masked]
Subject: [netlmm] RE: The Use of Timestamp in PMIPv6

Hi Ahmad,

Please see inline..

>>
>> The entity sending the Proxy Binding Update/Ack should add a Time 
>> Stamp option to the message.
>
> [Ahmad]
> It is not a matter of each entity include the timestamp option here. 
> The problem is that the MAG needs to be able to use the timestamp 
> somehow to match the BA to the outstanding BU. I would recommend the 
> following:
>

Ok. We just wanted to use the timestamp mechanism as in Mobile IPv4.
Some details are certainly missing as you have pointed out. We need to
fix them.

> 1. The draft needs to address the format of the timestamp in details. 
> In other words, what goes in the high order 32 bits and what in the 
> low order 32 bits. A good example of such format should be found in 
> RFC3344.
>

Ok

> 2. In success scenarios, the LMA must copy the timestamp as is from 
> the timestamp option in BU and returns in the timestamp option P-BA, 
> this way the MAG will be able to match the BA to the outstanding P-BU.
>

Ok

> MAG to use in matching P-BA to P-BU. This makes the MAG always aware 
> of the LMA timestamp.
>

Ok

Ok

> happen for retransmitted packets.

In the next rev, we did some work on this. With this input, we will fix
the details.

> **If you would like me to help with the needed text, I will be happy 
> to do so.**
>

>> Agreed. We can make the home agent return the correct time stamp that

>> the proxy should use.
>> can be established using time stamp options present in the Proxy BU 
>> messages.
>
> [Ahmad]
> LMA. There is nothing guarantees that these BUs will arrive in 
> sequence. What the LMA is supposed to do, accept the first one and 
> drop the rest. I mean this needs to be clarified. In order to reduce 
> IOT overhead activities and for this to work, we need the details. In 
> other words, how the LMA<->MAG will use the timestamp in order for 
> this protocol to work.
>

>
> [Ahmad]
> Of course if we look at the replay protection as if it is per MN 
> issue, we will have a problem. However, you guys in order to make this

> protocol to work, you chose to have a per-Node SA. Excellent, then why

> not use a per Node replay protection for this protocol. What I mean 
> here is we can treat the sequence number per a pair of MAG<->LMA.
>

The issue is not related to replay protection. That is assured by the
IPSec ESP header. We need sequencing to cover the scenario, where a
mobile keeps moving between two PMA's and the PMA's starts sending
PBU's, if the messages reach the home agent in out of order, the home
agent may accept an older registration. Since, the IPSec sessions for
the two PMA's are different, the sequence number in the ESP header is
not sufficient.

> statement that it will have little meaning is not accurate.

This is in the context of the sequence number present in the BU. For the
protocol to support both PMIP and CMIP modes, for PMIP we rather use a
different scheme and that was the comment.

> Finally, since SQN is already in the P-BU/P-BA, Is it a good idea to 
> use the combination of both SQN and timestamp? It will make the 
> protocol more robust to problems that may arise from timestamp 
> synchronization.
>
>>

Agreed. Appreciate your attention to the details. Now we will focus on
these finer details.

Thanks
Sri