Subject: RFC 2961 - detectoin of out-of-order msg

From: "Feng, Mark" <[email-masked]>
Date: Wed, 11 Jul 2001 14:41:55 -0700

Hi,

RFC 2961 describes a mechanism to detect out-of-order messages for a
particular state (Please see the quote below). I am not sure the mechanism
works all the time. The test should work if the new number does not wrap
around too far. However, since the message ID is per generator's IP address,
it could be sent to multiple receivers; and there could be numbers of
connections/states on each receiver. In this case, if a particular state
does not experience any change of state for a substantial long period of
time, the next state change could result in the receiver getting a trigger
message with a message ID that wraps around far enough so that the test will
fail (e.g. let's say old id is 0x8fffffff, the new value is 0x00000002, the
test fails)

Please correct me if I am wrong.

Thanks in advance.

Mark

   "Nodes processing incoming MESSAGE_ID objects SHOULD check to see if a
   newly received message is out of order and can be ignored.  Out of
   order messages SHOULD be ignored, i.e., silently dropped.  Out of
   order messages can be identified by examining the values in the Epoch
   and Message_Identifier fields.  To determine ordering, the received
   Epoch value must match the value previously received from the message
   sender.  If the values differ then the receiver MUST NOT treat the
   message as out of order.  When the Epoch values match and the
   Message_Identifier value is less than the largest value previously
   received from the sender, then the receiver SHOULD check the value
   previously received for the state associated with the message.  This
   check should be performed for any message that installs or changes
   state.  (Includes at least: Path, Resv, PathTear, ResvTear, PathErr
   and ResvErr.)  If no local state information can be associated with
   the message, the receiver MUST NOT treat the message as out of order.
   If local state can be associated with the message and the received
   Message_Identifier value is less than the most recently received
   value associated with the state, the message SHOULD be treated as
   being out of order.

   Note that the 32-bit Message_Identifier value MAY wrap.  To cover the
   wrap case, the following expression may be used to test if a newly
   received Message_Identifier value is less than a previously received
   value:

       if ((int) old_id - (int) new_id > 0) {
          new value is less than old value;
       }
   "

---

From: Ping Pan <[email-masked]>
Date: Fri, 13 Jul 2001 21:28:42 -0700

> Please correct me if I am wrong.

Mark,

One solution is that when the message id becomes too big, the router
simply changes the epoch value, and start to send the id from a low
number again. In this case, if you use the Ack-extension only, the
receiving node will simply update the states to the new id's in the next
refresh cycle. If you use the summary-refresh extension, the receiving
node will nack the summary-refresh messages due to epoch change. The
sending node will have to reply a bunch of messages to sync up the id's.

I know the RFC said something like epoch value should not change unless
the router has restarted.... Well, the router does restart the message
id now. :-)

- Ping