Flemming is right. Even if we assumed reliable transport or had a sequence numbering scheme built into the protocol's lower layer we would have this problem. It's a race condition and we have to deal with it. On the surface I can't think of a better way of doing it than the RequestID for events.
Rex
Flemming Andreasen wrote:
There is actually a good reason for the RequestID. It basically enables you to determine whether a notification was issued before or after the reception of a given request for the notification. As an example where this is important, consider what we refer to as "lockstep mode". It essentially states that a given request can at most generate one Notify, which implies that after receiving a Notify you must send down a new request. Without a RequestID you cannot determine whether that request has already been received or not. This is not only protocol-wise important but semantically as well, as your new request may contain instructions to look for a new set of events that all of a sudden either became important to know about, or you no longer want to hear about. Thus we should keep the RequestID.
Regards
Flemming AndreasenBrian Rosen brosen@ENG.FORE.COM on 04/09/99 08:18:46 AM
Please respond to Mailing list for parties associated with ITU-T Study Group 16 ITU-SG16@mailbag.cps.intel.com
To: ITU-SG16@mailbag.cps.intel.com cc: (bcc: Flemming Andreasen/Bellcore) Subject: Re: Event reporting (was audio call Thursday: Minutes)
As the protocol is currently defined, there is thus thing we called a RequestID. You supply a RequestID with the EventDescriptor, and it is returned by the Notify. A RequestID is a 32 bit integer. The syntax defines the requestID, and uses it in the Notify, but does not show it in the EventDescriptor. That should be fixed, but...
As I noted, TerminationID + EventName is logically equivalent to an MGC assigned RequestID if you can only have one instance of an event on a termination. Implementation seems to be simple in either case at both ends. At the MG, storing the requestID is easy, but not storing is easier. At the MGC, the RequestID would be a separate table, but it would have to have TerminationID and EventName at least implicitly, and probably explicitly in it. Searching a structure by TerminationID and then EventName (or the other way around) is also easy.Thinking about it overnight, if it really is the same, then it would be best to eliminate the RequestID artifice and use Termination ID + EventName.
At the time, I believed we thought that there were circumstances where there was not uniqueness. Right now, I can't see how that can occur.
Brian
-----Original Message----- From: Chip Sharp [mailto:chsharp@cisco.com] Sent: Thursday, April 08, 1999 5:46 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Event reporting (was audio call Thursday: Minutes)
Yes that was my understanding as well. The TerminationID would be used to associate the event to the termination. Thus the event report would contain the Termination ID and the event ID.
Chip
At 02:21 PM 4/8/99 -0700, Rex Coldren wrote:
Actually I believe this item was not correctly written. I
believe the
discussion was about how you associate a reported event to a given Termination. There was talk that notifications come back with a RequestID, which must be somehow associated to a Termination. Paul suggested using TerminationID directly.
Christian Huitema wrote:
- event handling
- currently an event is identified to the MGC with an
eventId - Paul
Sijben suggested that it would be better to use a terminationId
Sorry for missing the call, but let's comment on that
specific point. We
discussed the event reporting model at length during the
IETF meetings and
in the following week, and I don't beleive that there is
any advantage in
opening the debate again.
Termination Id and event names just do not belong to the
same space.
Terminations are defined on a per MG basis; events are defined independently of the MG, and in many cases independently of the termination class.
The current notifications identify both the termination on
which the event
was observed and the name of the event. There is a lot of
experience to
show that this is a very efficient decomposition, and I
don't see any
reason whatsoever for ditching the experience in favor of
an unproven
theoretical design.
-- Christian Huitema
Please note my new address: huitema@research.telcordia.com http://www.telcordia.com/
Chip Sharp voice: +1 (919) 851-2085 Cisco Systems Consulting Eng. - Telco Reality - Love it or Leave it.