Re: [EFM] OAM event sequence number
Clause 57 contains the normative technical description of the OAMPDU frame format, external interfaces and the internal behavior of the OAM sublayer. Additionally, it also provides some *guidelines* for recommended behavior of the OAM client. As you have pointed out, 22.214.171.124 provides some of these guidelines. They are by no means exhaustive. The case of the sequence number wrapping from 0xFFFF to 0x0000 is, for example, also not listed.
Here is an excerpt from 802.3ah-2004/D3.3/126.96.36.199:
"As described in 57.2.3, the OAM client may send duplicate Event Notification OAMPDUs to increase the likelihood the remote DTE receives a particular event. The OAM client increments the Sequence Number for each unique Event Notification OAMPDU formed by the OAM client. A particular Event Notification OAMPDU may be sent multiple times with the same sequence number. It is recommended that any duplicate Event Notification OAMPDUs follow its original without a different, intervening Event Notification OAMPDU. A duplicate Event Notification OAMPDU should not be transmitted if a new Event Notification OAMPDU has already followed the original OAMPDU."
Sublayers below OAM will not re-order frames, nor will they re-transmit frames after successful successive frames have been sent. Following this principle, the OAM client should ensure that Event Notification OAMPDUs are not delivered out of order. If received, I would suggest the OAM client discard them as old. There is a little bit of logic in the OAM client required to detect new vs. old vs. wrap condition.
Editor, EFM OAM sub-task force
[mailto:owner-stds-802-3-efm@LISTSERV.IEEE.ORG]On Behalf Of Stephen
Sent: Wednesday, June 23, 2004 12:35 PM
Subject: [EFM] OAM event sequence number
188.8.131.52 only says that OAM client compares the event sequence number with
the last received one and ignore the event when the sequence numbers are equal.
It does not specify what to do when it receives an event with a sequence number
less than the last received one.
The scenario that I'm thinking about:
A sends event 1, 2, 3, 4, 5 and 3 gets dropped. Later event 3 gets retransmitted and received
at the other end. What should the receiver do?