Subject: Re: SDL-News: PDU parsing in SDL
From: Rick Reed TSE (rickreed#tseng.co.uk)
Date: Mon Mar 01 2004 - 15:13:53 GMT
Become an SDL Forum Society member <http://www.sdl-forum.org/Society/members.htm>
The originator of this message is responsible for its content.
-----From Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews -----
livelonger#sohu.com at livelonger#sohu.com wrote on 02/29/04 05:21:
> Become an SDL Forum Society member
> <http://www.sdl-forum.org/Society/members.htm>
> The originator of this message is responsible for its content.
> -----From <livelonger#sohu.com> to sdlnews -----
>
> Hi ,everyone
> I have a problem in establishing a SDL model of a protocol . As we all know
> ,the PDUs in a protocol maybe in all kind of formats ,discriminated by a
> protoocol discriminator . The PDUs are enclosed in a primitive ,such as a
> DATA primitive . If the entity receives the primitive, it determines the
> format of the PDU by the discriminitor . Then the problem comes : All the
> signals in SDL have predefined parameter ,namely the PDU format . Then how to
> express the parsing process ?
> Thanks for answering me .
> Best regard .
Dear Steven,
This issue has been recognised by ITU-T and there is an extension to SDL in
progress dealing with the encoding of data in SDL: Z.104. This is to be
discussed at the next SG17 meeting 10-20 March 2004. In the work plan it is
to be consented for approval at that meeting, but in my opinion it is not
yet ready for approval.
Z.104 enables an ASN.1 PDU description to be used to specify the set of
signals that be received and the encoding rule used over the protocol
interface. Of course, this will only be a solution for the long term and
requires the proposal to implemented by tools before it is of practical for
users.
So in the meantime you will have to rely on tool or application specific
methods for encode/decode of PDU's and converting to signals.
Of course, it will help if the PDUs are defined in a way that makes it easy
to convert to SDL signals. It seems to be agreed that if a protocol is
properly defined in ASN.1 it should have a top level ABSTRACT-SYNTAX with
has a type that is a CHOICE of messages that the application can receive. In
general these are embedded in a value (of type EMBEDDED PDV or EXTERNAL) of
a lower level protocol, and so need to be decoded.
The usual way to do this using today's tools is to use encode/decode
functions and these are best generated using an ASN.1 compiler with the
appropriate encoding rule specified. The result is usually C, and one issu
is then to interface the C with SDL.
However, from an SDL viewpoint this occurs at the wrong place, because such
a function cannot be invoked when receiving signals. The user therefore
either has to decode the received messages in another - usually lower -
layer (which therefore violates the principle of separation of layers), or
needs to introduce an additional SDL state machine which simply unpacks the
messages from the PDUs and turns these into signals. In your terminology
this state machine (an SDL process in SDL-96) would take the PDU format from
the DATA primitive and create the necessary signals, then OUTPUT them to the
protocol handling state machine. Obviously, it is this state machine that
could use a decoder generated by an ASN.1 compiler.
One possibility to avoid introducing an extra process is to:
a) Receive the DATA primitive in all states (using asterisk state) and
always follow the decoding transition by a return to the same state
(NEXTSTATE -);
b) in the decode transition OUTPUT the decoded signals to SELF.
A refinement of this could be to receive the DATA primitive in a priority
INPUT, but I am not sure that would make much difference.
When sending the signals they have to wrapped up in the DATA primitive.
It is actually quite easy to do this in the sending state machine by calling
the encoding function to generate PDU format and using this as a parameter
of the DATA primitive in an OUTPUT. However, this has a couple of
disadvantages:
a) The sent message does not appear discretely anywhere;
b) The whole design is not symmetric.
On the other hand if instead the signals for the protocol are output
explicitly to SELF there is an issue of separating the sent and received
signals. The usual way of overcoming this issue is to use different names
for the sent compared with the received signals - such as the protocol
convention of ( _request, _indication) or ( _response, _confirmation)
suffixes to the names. If an extra process is used this would not be an
issue.
In any case, another issue to be wary of is the SDL semantics, if an state
machine can both send and receive the same signal. If it is not explicitly
stated that an OUTPUT is VIA a specific path, or TO a specific destination,
the signal can end up in the input queue of the sender.
When (and if) Z.104 is adopted and implemented all this will be simpler:
1. An ASN.1 description implying all the signal names in a CHOICE type can
be given;
2. encoding will take place just as a consequence of an OUTPUT of the signal
on a path that has encoding;
3. Similarly, decoding can take place when a message is received from such a
channel.
-- Rick Reed - rickreed#tseng.co.uk Tel:+44 15394 88462 Mob.:+44 7970 50 96 50--End text from Rick Reed TSE <rickreed#tseng.co.uk> to sdlnews --- For extra SDL Forum Society benefits join at <http://www.sdl-forum.org/Society/members.htm>
This archive was generated by hypermail 2a23 : Thu May 09 2013 - 16:05:50 GMT