SSCOP Protocol Throughput Evaluation
– Simulation Based on Estelle Specification
Cristian Negulescu, Eugen Borcoci
POLITEHNICA University of Bucharest,
Electronics and Telecomm. Faculty, Telecomm. Dept., 1-3 Bvd.Iuliu Maniu,
Bucharest -6, 77202, Romania
E-mail: ncristi@first.elcom.pub.ro
eugenbo@first.elcom.pub.ro
ABSTRACT
The contribution applies the performance evaluation (PE) methodology, based on
annotated Estelle specification simulation, to a real protocol - the Service Specific
Connection Oriented Protocol (SSCOP) - approved as B-ISDN ATM Adaptation
Layer (AAL) protocol standard by ITU- T. The complete Estelle SSCOP specification
was written, conforming the ITU-T Reccomendation Q.2110/1994 and validated for the
main connection management and data transfer related functions.The PE are performed
on the Estelle Development Tool (EDT/XEDT) developed at Institut National des
Télécommunications - Evry, France. We mainly studied - the SSCOP throughput,for
different parameters of the user and underlying layer and for different protocol
configurations. We obtained similar results to those reported in other studies ( but they
used simplified analytical models and/or simulation done on separate models). Our PE
run on the real protocol and for extended range of environment conditions, using the rich
set of predefined functions of XEDT and appropriated observers. Extensive simulation in
severe error conditions have revealed some specification errors and even flow control
inefficiencies of the SDL protocol definition Q.2110. Therefore the PE simulations can
additionally be used as a complement to the validation process by verification automata
and can lead to improvement of the protocol definition. Some simple adaptive flow
control policies are proposed and experimented by the authors and show an improved
throughput and less control packets overhead. The general conclusion is that the
methodology accompanied by a poweful tool is valuable for real life systems design since
it gives a user a possibility to evaluate performance in the early stage of protocol
development.
I INTRODUCTION
The performance related features of the communication protocols are currently of increasing
interest, especially in the context of high speed networks and new application, like real-time and
multimedia traffic carried by such networks.
This paper continues some previous work devoted to performance evaluation (PE) and parameter
tailoring of complex communication protocols by simulation of their Estelle formal specifications. The
general objective is to apply and further develop the Estelle - based methodology for complex protocol
1
design with early performance evaluation. While using the same formal specification as written for
validation and implementation of the protocol, predictions on the performance figures can be obtained by
simulation, in the early stage of the protocol development. We already applied this methodology to XTP
4.0 protocol, [BMB97] [BCM96] [BMC97]
A new case study is considered in this paper i.e., the Service Specific Connection Oriented
Protocol (SSCOP) - approved as B-ISDN ATM Adaptation Layer (AAL) protocol standard by ITU-T
(Q.2110) in 1994. The Estelle specification of the complete SSCOP protocol was written by the
authors and validated for the main connection management and data transfer related functions. Then
the specification was annotated in order to do PE, based on the Estelle Development Tool
(EDT/XEDT) developed at Institut National des Télécommunications - Evry, France, [SB92], [SB98].
The specific aim of this work is evaluating the SSCOP throughput capabilities in different link
conditions: loss probability of frames, round trip time, medium rate, etc., while varying the protocol
parameters ( poll interval and policies, flow control window, data unit size, etc.). Variations of user
layer parameters (sevice data unit size, rate) have also been taken into account, w.r.t different
choices of the protocol parameters. A comparison is done to other analytical and simulation ( using
different approach i.e. specially defined simulating environment ) results reported by different
authors. Some inefficiencies of the Q.2110-defined protocol have been found.
The main contributions and results reported by this study consist in:
- enriching the methodology and experience of real network complex protocols design - specifically
SSCOP performance evaluation based on formal description techniques (FDT) specifications and the
appropriate tools (EDT/XEDT),
- showing that applying the above methodology, the main results are similar to those of other
authors, e.g. [TH95 ], obtained analytically ( for simplified assumptions) or by simulations based on
separate PE -oriented models. The difference is that our PE are performed in extended working condition
range, in contrast to the simplified ones supposed in analytical studies, e.g. high error conditions - are not
manageable analytically in simple way,
- prediction on the protocol implementation performance characteristics ( because of work on the
same specification as used for implementation ) by introducing finite speed processing parameters in the
simulation sessions (nonzero - transition execution times, system management times),
- adding the PE oriented simulation as a complement to the protocol validation activity. Some
hidden errors in the formal specification can exist e.g. when manipulating some complex data structures as
retransmission lists or building complex status report packets, in the buffer management, etc.
- using the PE oriented simulations the inefficiency of some mechanisms or even some errors in the
initial non-formal or other FDT specifications presented in Standards/ Reccomendations drafts can be
emphasized. Therefore the PE simulation can help to correct/improve the initial system specifications.
The organization of the paper is the following: Section I is an introduction. Section II shortly
recalls some topics on protocol PE while using their formal specifications and appropriate tools to perform
PE. Section III presents a brief description of the SSCOP main characteristics. Section IV defines the
problems to be studied and the simulation environment. Section V presents the Estelle architecture of the
SSCOP developed by the authors and then completed to do PE. The main characteristics of the experiments
and some samples of results are given in the Section VI. In Section VII the general conclusions are given
and further work outlines.
II PERFORMANCE EVALUATION ON ESTELLE
SPECIFICATIONS
Communication protocol PE, performed early in the design process, is already an applied idea
([BMS96], [HB96], [DHM96], [BMB97]), based on analytical models or by simulation. We focus on
FDT-based simulations, because of the complexity of the studied protocol. The dynamic annotation
approach developed by S.Budkowski and M.Hendaz, [HB96], and the EDT tool have been selected to be
2
used.The Estelle Debugger (Edb) of EDT(see [HB95], [HB96], [SB98]) has PE facilities which mainly
consist in offering the user a possibility to:
• dynamically add to the simulated model the following information needed for performance evaluation:
•Transition execution time intervals
•System management time intervals
•Different distribution laws for the above intervals (Uniform, Exponential, Geometric, Poisson)
•Relative execution probabilities for non-deterministic transitions
• collect and display the measured results using dedicated Edb commands; some measurements are
independent with respect to the studied specification ( statistics on fired transitions, queue contents, etc.),
while other are specification related (throughput, response times, etc.).
The specification should be first functionally validated and then annotated and completed for PE.
The main steps to follow in order to prepare PE have been discussed in [BMB97], [BCM96], [BMC97].
Specifically to do PE for a protocol machine, the environment must be built (upper layer, lower layer,
management layer, all formally specified. The environment layers can be the same as used for the protocol
validation. Additionally to permit PE these layers should additionally accomplish:
- upper (user) layer: generating and receiving data units primitives at given rates and lengths (
fixed/random), conforming to an interface flow control policy if this is defined, performing some custom
ststistics which are not offered directly by the tool facilities.
- lower (medium) layer: possibility to vary the propagation delay, to loose/duplicate or reorder the
transferred packets with probabilities at choice.
At the protocol layer itself, one should process the real data length and introduce some transfer
delays and vary different policies or configuration parameters to obtain different conditions for the
simulation scenarios.
The XEDT permits PE oriented simulation, giving the possibility to collect information on
performance features. In the case of complex protocol evaluation there is necessary to add some "custom"
features the simulation in order to get information on some protocol mechanisms, using some special
defined variables or procedures/functions.
One must care that the additions to the already validated specification must not change its
behavior in order to keep on the previous validation. The minor modification to be done are only
"passive" ones: they consist in defining some special variables to collect specific results during the
simulation execution and compute (in atomic actions) some statistics. Neither new states nor new
transition are introduced.
Here are the steps we followed in order to do PE oriented simulations:
- normalized all time related parameters/values to an Estelle time unit, representing a real time value,
- completed (if necessary) the specification with additional
variables/functions/procedures to
set/generate/measure PE related values:
at user layer - to generate appropriate data units, at given rates, and to receive/count them,
at protocol layer , e.g.: processing the real data length and introduce some transfer delays,
at medium layer, e.g.: possibility to vary the propagation delay, to loose/reorder/duplicate the
packets with some given probabilities.
- defined which parameters have to be initialized:
- at compilation time
- before each new simulation (sub)session using Edb facilities (macros)
- wrote the macro/observers in order to do :
- (re)initialization of system parameters;
- activate /inactivate protocol features;
- observe events and stop/continue the simulations;
- assigning transition execution and system management times;
- tracing values for tmcurve/fscurve diagrams;
- run repeated simulation.
3
III SSCOP PROTOCOL MAIN CHARACTERISTICS
The SSCOP - is part of ATM Adaptation Layer ( combined with AAL5 the SSCOP forms the
signaling AAL, i.e. SAAL, but SSCOP can be useful also for other purposes than signaling). SSCOP is
an example of a lightweight high speed oriented protocol. It provides basically the same services as LAPDISDN or MTP2 (Message Transfer Part - layer 2) in Signaling System No.7., plus new features not
encountered in these protocols.
3.1 General features
The SSCOP protocol incorporates many features of a high speed connection oriented protocol
with reduced ( lightweight) processing. Initially it was devoted to accomplish the functions of a data link
layer protocol in the ATM Adaptation Layer stack, [ITU4], see Fig.3.1. The first two SSCF have been
defined to support UNI and NNI signaling in ATM networks. Due to its features, other more general usage
are currently in study ( Frame Relay, wireless networks, etc.), [TH95].
SAAL primitives
Service Specific
Convergence Sublayer
(SSCS) (3)
SAAL -SAP
Peer-to-peer PDUs
SSCF
AA-signals
SSCOP
Peer-to-peer PDUs
AAL5
Common Part AAL
Functions
(CPAAL)
CPCS
SAR
ATM primitives
Peer-to-peer PDUs
ATM -SAP
Fig. 3.1 The AAL Protocol stack
SSCF = Service Specific Coordination Function; SSCOP = Service Specific Connection Oriented
Protocol; CPCS = Common Part Convergence Sub-layer; SAR = Segmentation and Re-assembly;
ATM-SAP = ATM Service Access Point
The main functions of the SSCOP are:
a. Connection control and user-to-user information transfer (non-guaranteed delivery mode).
b. Transfer of user data in two modes :
- assured mode : point-to-point, connection oriented transfer with sequence integrity (SD data
units); error correction by selective retransmission, window based flow control, local data
retrieval - by the local SSCOP user,
- non-assured mode :possible in any state of the protocol, for point to point or broadcast
connectionless transfer.
c. Transfer of management data: in non-assured mode.
4
d. Protocol supervision :
- protocol error detection and recovery; - error reporting to Layer Management
- keep alive - this function verifies that the two peer SSCOP entities previously interconnected
in a link, are still in connection; - status reporting - transmitter and receiver entities exchange
status information.
3.2 SSCOP interfaces
3.2.1 The SSCOP/SSCF interface
The service offered by SSCOP is defined mainly in [ITU-T4]. Some other related documents
offer additional information [ITU-T 1,2,3,5]. The service primitives are defined for:
- connection setup and release
- sequenced and not-sequenced data transfer
- others: resynchronization requested the application level ( here we denote by "application" or
"user", the next upper sub-layer SSCF ), data retrieve by the user, recovery primitives ( at the initiative of
the protocol in case of serious errors ).
3.2.2 The management interface
SSCOP is design to interact with a management module of the SSCS via a set of special
primitives. It also offer unassured mode transfer for data exchange between management entities. The
primitives have the following functions:
- error reports by the protocol (MAA-ERROR.ind)
- data exchange between management entities ( MAA-UNITDATAreq/ind)
3.2.3 The lower interface
The service required by SSCOP from the lower layer is the most simple connectionless service,
based on two primitives CPCS-UNITDATA.invoke and CPCS-UNITDATA.signal.
3.3 The SSCOP functionality
Because of our objectives, we will basically present only the SSCOP data transfer characteristics especially for SD data units, and the related mechanisms (for details -see the above mentioned documents).
SSCOP itself belongs to the class of synchronous bit-oriented protocols. In assured mode
SSCOP orderly transfers data units PDUs - carried in SD frames, each having a sequence number, after
the connection establishment. Transfer of unnumbered individual data units (non-assured mode ) is possible
in any state of the protocol machine. No address fields nor connection identifiers are present in the SSCOP.
SSCOP opens ( full service, having four primitives), maintains and ends( non-graceful close,
bidirectional) point to point connections. The sequenced data (SD) transfer is performed after connection
setup and is mandatory terminated by connection release request primitives. The link between the two
entities is balanced, any one can initiate or terminate a connection.
An important point in the SSCOP design philosophy is the transmitter control principle in the
sense that usually the receiver responds with status reports only it is asked for, by interrogating (POLL)
frames sent by the sender. There is however an additional working mode, for faster recovery, in which the
receiver generates unsollicited status reports requesting retransmission, when it discover new
discontinuities in the received sequence of packets.
Resynchronization of the two pair entities could be performed if required by the user. While in
data transfer state some unrecoverable errors are discovered by the protocol, then SSCOP itself, enters a
recvery state informing the user on it. After user and peer responses, the data transfer can be resumed.
The SSCOP state machines at SSCF interfaces and of the protocol itself are presented in
[ITU-T4] Q.2110 Reccomendations, Fig 2/Q.2110 and Fig 17/Q.2110.
3.3.1 Protocol data unit (PDUs) frames
SSCOP uses the following type of frames:
5
a. Establishment (setup): BGN, BGAK - connection confirmed establishment . BGN requests the
clearing of peer Tx and Rx buffers and variables initialization. The peer SSCOP may reject the connection
by using BGREJ.
b. Release: END, ENDAK is a peer of PDU used for connection confirmed release.
c. Assured data transfer
SD - transfers across a SSCOP connection, sequentially numbered PDUs of variable length,
containing information fields provided by the SSCOP user.
POLL, STAT is a peer of PDUs, used for explicit periodical status reuest (POLL) by the Tx and
status-response (STAT) sent bacwards by Rx. POLL PDUs are numbered independently of the SD PDU,
permitting powerful error recovery procedures. The STATs and their responses can be paired by using
special sequence numbers N(PS).
STAT PDU contains information regarding: reception status (acknowledges for received sequence)
of SD PDUs, credit info for the peer Tx, the sequence number N(PS) of the POLL PDU to which it is in
response.
USTAT is used to send backwards unsolicited status -info, when the receiver detects one or more
new missing SD PDUs (verifying-the sequence numbers N(S)). It contains simmilar type of info as STAT .
d. Resynchronization: RS is used to resynchronize the buffers and data transfer state variables
and RSAK is acknowledge the acceptance of a resynchronization requested by the peer SSCOP entity.
e. Recovery: ER is used by the SSCOP entity that has detected a sequence number probem, to
inform its peer to recover. ERAK is a response to acknowledge the recovery from protocol errors.
f. Unacknowledged data transfer: UD - for unassured data transfer between SSCOP users (*).
g. Management data transfer: - MD - for unassured data transfer between two management
entities (*).
(*) Transmitting of an UD / MD does not affect the SSCOP state variable. UDs / MDs are not
numbered, therefore they may be lost without any notification.
3.3.2 The error control
The transmission errors are corrected by selective retransmission requested by the receiver (list
of the existing gaps the flow received) reports by STAT/USTAT frames. The basic error correcting
mechanism is:
- the transmitter periodically (POLL_Timer) sends POLLs to the receiver, or after sending a given
amuont of data (preventive policy to buffer overflow),
- the receiver has a reordering buffer in which it keeps the uncomplete sequence of frames until
they are completed and can be delivered to the user. The receiver observes the existing gaps in the received
sequence and if rquested by POLL it returns the list of the gaps to the sender in the STAT frame paired to
the previous POLL. Also the POLL contains the main receiver variable value Vrr to acknowledge all the
seq. numbers up to Vrr - 1.
-optionally the receiver may be reactive to the new discontinuities observed in the data flow by
returning USTAT - retransmission request. USTAT has almost the same structure of fields as STAT but it
is not associated to a previous POLL and does not contain the complete list of gaps, but only the most
recent one discovered by the receiver. A retransmission can only once invoked by USTAT; if the frame is
lost again anew USTAT will not be generated. This frame will be recovered via POLL-STAT dialogue.
- SSCOP has a mechanism to avoid redundant retransmissions. Each SD frame transmitted or
retransmitted is kept in the transmitter buffer ( until acked), associated with a "time-stamp" wich indicate
6
the last moment of its transmission or retransmission. The POLL/STAT pairs have also fields "time-stamp"
filled with the values taken from the same "clock". If a STAT is received, its time_stamp ( which is the
same as its previous corresponding POLL) is compared to the SD. If the STAT "time_stamp" is greater than
those of the buffered SD, then this is indicating a more recent retransmission request than the moment of
last transmission of the SD. It is only in this case that the retransmission is performed. Examples for this
mechanism are given in Q.2110- Appendix II and in [TH95]. The "clock" itself is not a continuous one; it
is the value of a nondecreasing function given by the POLL sequence numbers. (each new POLL receives
an incremented value of a counter N(PS).
We recall that if not asked, and if no data are transmitted, the receiver does not send back to the
sender any control packet. Therefore, the transmitter policy to interrogate the receiver is essential
w.r.t. the data transfer progress. The intervals between the interrogations are determined by the
POLL_timer (TP) , if the link is active. In Q.2110 this is a fix value, which we will show that is a rather
rigid solution, especially when the round trip time (RTT) is fluctuating or loss error percentage is high.
If no retransmissions have to be performed and no new data have to be sent and no frames are
waiting acknowledge , then the protocol enters in a keep_alive state and the intervals between POLLs are
increased, determined by other timers (Timer_Keep_Alive (TKA), Timer_Idle (TI) ), [ITU-T4] Q.2110.
3.3.3 SSCOP credit and flow control
Peer-to-peer flow control
Flow control is performed on the basis of adjustable sliding window. The receiver grants a credit
window to the transmitter by indicated the maximum value of the sequence number [VR(MR) -1 ] that it
can accept. The value of credit can be dynamically modified (increased or decreased ) by the receiver. The
main characteristics of the flow control policy are:
-credit is granted by the SSCOP receiver (transmitted backwards by VR(MR). Due to the fact that
knowing the credit is very important, many frames have been choosed to carry it, in one field dedicated to
the VR(MR) value: BGN, BGAK, RS, RSAK, ER, ERAK, STAT, USTAT,
- previously granted credit could be reduced, but not under the value VR(H)- the next maximum
sequence number expected,
- possible to grant credit value greater than the RecBuf available capacity (risks exists of
discarding data sent in excess),
- determination of the credit values and its dynamic adjustments are implementation dependent.
Local flow control
The congestion detection in the lower layers and subsequent actions of the SSCOP- are non
standardized.They are (implementation dependent). The SSCOP local flow control at SSCOP / SSCF
user interface -is also implementation dependent.
IV THE SIMULATION ENVIRONMENT
We considered point to point simplex or full duplex assured modes of communication between two
SSCOP entities linked by an underlying medium having losses. The main synthetical performance feature
studied has been the SSCOP throughput (Thp), evaluated by Estelle specification simulation in various
working conditions. Thp was defined in our study as the ratio of the mean receiving rate observed by the
receiving user, to the mean sending rate observed by the sending user.
The main parameters/policies have been varied during these simulation:
- at user (SSCF) layer: the data unit length (l) e.g. 1024, 2048, 4096 bytes, - fixed or random size
data units and the sending rate (Rs) - e.g. 10, 20, Mbit/s,
- at the protocol layer:
- general protocol parameters like : window size (W), timer-poll (Tp) interval for status
requests (POLL frames) sent by the transmitter to the receiver, etc.
- tradeoffs of status reports STAT/USTAT style of usage have been investigated,
- the influence of the nonzero transition execution times and system management times
have been evaluated in order to make some prediction on the future implementation
performance.
7
- at medium (CPAAL) layer: the bandwidth-round trip time product (BRtt), the loss and
duplicating probabilities (e).
In order to compare our results to some other authors' results we investigated the influence of the
channel environment ( BRtt, e ) and the protocol parameters ( W, Tp, l, etc.) on the throughput values.
We mainly present in the section VI the influence of the flow control policy in severe error
conditions and limited buffer capacities on the overall throughput of the protocol. Some critical remarks on
the SDL reference specification Q.2110 are given and some solution proposed to enhance the flow control.
We will also give examples of how the PE oriented simulation can be used as a complement to the
validation of the protocol. Diagrams collected by observing the evolution of some key protocol variables
can reveal in some scenarios the existence of errors in the specification and indicates the functional
"regions" where the errors are plausible to exist. These information are valuable because they can reduce
drastically the area of error search; the found area can be further investigated by using verification
automata based on macros/observers.
V THE ESTELLE SPECIFICATION ARCHITECTURE
5.1 The general architecture
module USER2:
USER SSCF
module USER1: USER_SSCF
module MNG1:
ip SSCF_SSCOPip
SSCS_MNG
ip SSCOP_SSCFip
ESTind/conf
RELind/conf
RESYNCind/conf
RECOVERind
DATAind
UNITDATAind
RETRIEVEind
ESTreq/resp
RELreq
RESYNCreq/resp
RECOVERresp
DATAreq
UNITDATAreq
RETRIEVEreq
RETRIEVE_COMPLind
BUSY (x)
TRS_AVAILABLE (x)
SSCF_SSCOPchn
M_ERRind
M_UNITDATAind
ip SSCF_SSCOPip
SSCOP_SSCFchn
ip SSCOP_SSCFip
channel
module SSCOP: SSCOPm
MNGchn
ip SSCOP_MNGip
M_UNITDATAreq
SSCOP
PDUs
module
SSCOP:
SSCOPm
ip SSCOP_CPAALip
channel CPAALchn
[CPCS_UNITDATAind
[CPCS_UNITDATAreq
ip MNG_SSCOPip
ip CPAAL_SSCOPip[1]
module CPAAL
ip CPAAL_SSCOPip[2]
Fig. 1 The ESTELLE SSCOP protocol specification architecture
(x) - not defined in Q.2110
(* Fig.1 in [EB94])
The complete SSCOP Estelle specification, has been written by the authors. The protocol module
works on top of a medium module ( Common Part Adaptation Layer - CPAAL ). On top of SSCOP, the
upper layer module simulating has been built (Service Specific Coordination Function - SSCF ) -as user
layer.
The ESTELLE architecture of the SSCOP protocol and the surrounding modules SSCF, CPAAL
defined for our simulation are presented in Fig.5.1 (* Fig.1 in [EB94]). Taking into account the experience
gained from [EB94], [BMC97], [CB96], [CLB97], we have chosen the build a single Estelle module for
8
the main protocol engine (transmitter and receiver) in order to avoid module multiplication and the inherent
excessive message transfer between two separate modules. The price paid is considerable complexity of the
SSCOP itself, but better performances have been achieved. The modules are linked by Estelle channels bidirectional or unidirectional. The structure of the specification is static, i.e. no module is dynamically
created or destroyed. SSCOP is further divided into upper main protocol submodule and a lower coderdecoder submodule, to build the real packets.
Two supplementary signals, are defined between SSCOP/SSCF to perform a flow control at
SSCF/ SSCOP user interface. They are generated by SSCOP module and shows the availability of space in
the transmission queue of the sender.
The modules are :
- USER1, USER2 :
- SSCOP1, SSCOP2 :
- MNG1, MNG2 :
- CPAAL0 :
USER_SSCF
SSCOP
MNG
CPAAL
- systemprocess
- systemprocess
- systemprocess
- systemprocess
The channels connecting the modules are :
-two unidirectional channels between SSCOP and USER_SSCF:
-one bidirectional channel between SSCOP and MNG:
-one bidirectional channel between SSCOP and CPAAL:
Another difference to Q.2110 specifications is that data units sent down by SSCF to SSCOP,
are each associated with a reference number (different from N(S) ). This reference number serve to identify
the SSCOP SDU. Additionally, the retrieve number is in this reference numbers range. SSCOP executes a
mapping of reference number of an SDU to its current sequence number .
5.2 The SSCOP module
This specification version has chosen the solution of a single transmitter-receiver module , because
the tightly coupling of the Tx and Rx and to remove the overhead of a communication channel between
them. The penalty is the complexity of TR-module. It contains (Fig.5.2):
Modules:
TRi: TR - activity
{transmitter - receiver}
CODECi : CODEC - activity
{coder - decoder}
Channels:
- one bidirectional channel between TR and CODEC
TR_CODECchn (trec, codc)
Fig.5.3 (* Fig. 3.3 in [EB94) shows the transmitter queues organizations. Conceptually the Q.2110
presumes five queues ( data buffers):
- Transmitter queue (TrsQ) for not yet transmitted frames
- Transmitter buffer (TrsBuf) for transmitted and not yet acknowledged frames
- Retransmission queue (RtrsQ) for frames to be retransmitted
- Management Data unit queue
- Unnumbered Data unit queue.
9
USER_SSCF module
channel
SSCF_SSCOPchn
channel
SSCOP_SSCFchn
ip SSCF_SSCOPip
ip SSCOP_SSCFip
channel
SSCF_SSCOPchn
channel
SSCOP_SSCFchn
*
*
signals
signals
ipTRSip
ip RECip
module
SSCOP
SSCS_MNG
module TR
ip SSCOP8MNGip
protocol PDUs
ip TR_MNGip
module
MNGchn
MNGchn
SSCOP PDUs
BGN, BGAK, BGREJ
ip TR_CODECip
END, ENDAK
SD, POLL, STAT, USTAT
channel TR_CODECchn
RS, RSAK
ip CODEC_TRip
module CODEC
ip CODEC_CPAALip
ER, ERAK
UD
MD
channel
CPAALchn
ip SSCOP_CPAALip
*
see the signals defined in general configuration
channel
CPAALchn
CPAAL module
Fig. 5.2 SSCOP Estelle module structure
For efficiency, most of the buffers have circular organization. This choice makes easier modeling
of protocol windows. To avoid the excessive data transfer, in the current version of the specification the
retransmission queue is included as a part of the transmission buffer; this solution reduces the amount of
frame transfer between the queues. After PE simulation we decided to build also the TrsQ and TrsBuf in
the same buffer structure to completely avoid data frames moving inside the SSCOP module.
10
SSCF
AA_UNITDATA.req
AA_DATA.req
wait
transmission
-transmitted
-wait ack
TrsBuf
transmitter
window
STAT received
N(S)
DATA
wait
transmission
information
VT(A)
*
n
n +1
n +2
oldest SD PDU
seq. no.
.
.
m
VT(S) = m
VT(PS)
seq. no. not allowed
VT(MS)
current POLL PDU
seq.no.
N(S)=l
*
first not allowed SD PDU seq.no.
Data
N(S)=l
...
RtrsQ
SSCOP
SD PDU
SD PDU
SD PDU
N(PS)
UDTrsQ
wait
retransmission
next SD PDU seq.no.
...
N(S)=m
POLL PDU
POLL PDU
Maximum number of SD PDU = MaxPD
MANAGEMENT
(3)
(2)
(1)
(4)
wait
MUX
transmission
MNGTrsQ
CPAAL
*
updated using received information on the reverse channel
Fig.3-3 SSCOP transmitter structure
11
5.3 The state machine. Estelle specification style
The SSCOP Estelle state machine was obtained by translating the textual specification Q.2110, [ITUT4], and the associated SDL (GR) specification, into Estelle code. Due to differences between the construction
of the two languages this has been a non trivial activity. The main states of the SSCOP extended finite state
machine (EFSM) are, Fig.17/Q.2110:
Idle,
Outgoing_Connection_Pending, Incoming_Connection_Pending,
Outgoing_Disconnection_Pending,
Outgoing_Resynchronization_Pending, Incoming_Resynchronization_Pending
Outgoing_Recovery_Pending, Recovery_Response_Pending, Incoming_Recovery_Pending,
Data_Transfer_Ready.
Our simulations are mainly focused on the Data_Transfer_Ready related activities but the full
management of connection setup and release have been activated.
One of the problem of translation the SDL specification is related to :
- complicated unstructured ( go to excessively used) arithmetical/logical processing, combined with
decisions inside the transition bodies of some SDL transitions and terminated in different target next states.
Examples are the list processing of POLL, USTAT, STAT frames.
- the missing of the NextState clause in Estelle to permit ending branches to a next state after
performing some part of the transition body.
The solution found for solving this have been:
1. - including as much as possible of the logical conditions in the PROVIDED clause- this is not
always possible. In fact in the example above, there are many situations when this cannot be applied. The
disadvantage of this can be the complexity of PROVIDED clause having implications on the time of transition
selection of the real system.
2. - introducing intermediate new states in some of the decision points (if ..then..else..) of those
bodies which not permit the first solution. In this way new PROVIDED branches can be introduced allowing
going to different next states after execution of one part of the initial body. The first version of the SSCOP
Estelle specification [EB94] used this solution.
This splitting of a body (which is by itself just an atomic processing) increases, in some way
artificially, the count of the system main states. This can lead in principle to the increase of the system
management times. Also this solution is potentially dangerous because it can introduce significant
(sometimes non correct !!) changes of the EFSM behavior. Particularly, care must be taken to :
- assign high priorities to the intermediate transitions to fasten the overall execution equivalent of
the initial atomic action,
- to declare some STATESETs equivalent to the former only one initial state, in order to permit the
timer driven (delay) transitions to be executed while the system is in an intermediate state,
- to avoid treating some input messages while in an intermediate state, if they use some data
structures involved in the processing , because of possible data inconsistencies.
3. - a better solution seems to be to find an equivalent of a NEXT_STATE clause for Estelle
specification without having neither to excessively complicate the logical conditions in the PROVIDED clause,
nor introduce many intermediate, (potentially dangerous ) main states. We present the solution in Fig.5.4 in
graphical form to be more suggestive at one glance.
12
b
0
y
c
d
x
a
b
i=2
z
1
y
c
d
f
e
i=4
i=3
z
f
e
4
3
0'
i
2
4
3
2
Fig. 5.4 The realization of an equivalent of a NEXTSTATE clause
A switch integer variable i is defined, which permits to obtain branches to the next states 2,3,4 by
introducing only one intermediate next state 0' and preserving the atomicity of the processing that include the
tasks b,c,d,e,f. The swiching on value of i is performed by PROVIDED clauses in the state 0'.
If timers expirations are possible in the state 0 then one have to declare a STATSET, containing the
states 0 and 0' in which the timer is validated.
VI THE PERFORMANCE EVALUATION EXPERIMENTS
The objectives of PE simulation have been presented in the Section I and IV. Because of limited space
we shall only present the results of three kind of experiments (samples of our simulations) to illustrate their
use during the protocol design development process.
6.1 Using the PE simulation as a complement to the protocol validation
Usually the functional behavior of the protocol machines are verified and validated before doing
PE with a sufficient coverage factor. In the case of compex protocols, the number of protocol variables is very
large. Including all these in verification automata is difficult because the latter should be kept enough simple to
have itself a correct behavior w.r.t the desired properties. In such cases after a first validation of the principal
functions of the protocol, some PE simulations performed in severe and random conditions of the environment
( to determine the machine to follow complicated trajectories of its evolution) can be useful to discover some
residual errors especially related to wrong data structures menipulations.
The efect of these errors may be reflected in the system performance and can be observed during PEs.
The PE oriented random simulations, if focused on given mechanisms of the protocol can offer, due to their
13
integrating character, information on "regions" of functionality in which some errors can exist. A further
detailed verification method in those regions can show precisely the errors.
Fig.6.1 Trs.-3: available credit
Fig. 6.2 Trs.-3 : frame count in the TrsBuf
Fig 6.3 SD trs./retrs/ POLL transition use
Fig 6.4 Sending POLL transition use
Fig 6.5
Fig 6.6
SD receive transition use
POLL receive transition use
14
Fig 6.7 USTAT receive transition use
Fig 6.8 STAT receive transition use
Fig 6.1 - 6.8 Discovering protocol errors using the PE simulations
We give as an example how a PE simulation can put into evidence some hidden errors in the formal
specification that still exist e.g. when manipulating some complex data structures as retransmission lists or
building complex status report packets, in the buffer management, etc.
The SSCOP full duplex data transfer is simulated. The protocol instances are Transmitter -3 and
Receiver-6. We observe, using tmcurve ( ) commands of XEDT simulator the behavior w.r.t data transfer of
the two communicating instances after the connection setup. To do this we collect the values of key variables
in the Transmitter and receiver. The time evolution of the following variables are observed:
Fig 6.1
Fig 6.2
3->credit_avail - transmitter available credit granted by the receiver ( frame count)
3->TsBuf.count - the transmitter buffer fill ( frames sent and not yet acknowledged)
The following curves observe the number of use for main transitions involved in the data transfer:
Fig 6.3
Fig 6.4
Fig 6.5
Fig 6.6
Fig 6.7
Fig 6.8
$trnbuse(3->435) - SD transmission/retransmission, or POLL transmission if a given
amount of data has been sent and not acknowledged
$trnbuse(3->368) - periodical sending of POLLs frames to request ACKs and credit
$trnbuse(6->438) - receiver transition for SD reception
$trnbuse(6->448) - receiver transition for receeption of POLL
$trnbuse(3->440) - transmitter reception of USTAT responses returned by the receiver
$trnbuse(3->456) - transmitter reception of STAT responses returned by the receiver
All diagrams are represented versus $tsimt- simulation time of the tool.
The simulation has been done in severe error condition in the medium that is loss frame probability =
0.3 ( for 1024 byte/frame that corresponds roughly to to 3*10-3 bit error probability)- chosen especially to put
the protocol in the situation to build and interpret complex retransmission lists of gaps. The count of user
SDU is finite and limted at 50. Normally, even in this very lossy environment, the protocol, after many
retransmissions should terminate the acknowledged transfer for the 50 packets. It is not so.
A parallel examination of the above diagrams shows some bugs in the specification sscopx4.stl. One
can see that after for $tsimt > 1500 the transmitter 3 enters in a kind of livelock condition:
The transmission does not progress any more if $tsimt > 1500 despite that :
15
- credit exists (Fig 6.1)
- the TrsBuf is non-empty , which means that retransmissions should still exists (Fig.6.2)
- the transmitter no more sends other frames (Fig.6.3) or POLLs forced by data sent amount
- the transmitter still transmit periodically POLLs frames (Fig.6.4)
- the receiver no more receives any SD (Fig.6.5)
- the receiver still receive some of the POLLs (Fig.6.6), less than those sent because of high loss
- the transmitter receives no mre USTAT frames (Fig.6.6); this is normal because it has not sent any
more data after $tsimt > 1500
- the transmitter still receives some status responses in STAT frames (Fig.6.8).
Combining all this information one comes to the conclusion that after an interval of good behavior, the
transmitter does no more perform retransmissions ( it did it before, but the diagram showing that is not
represented here) despite they are necessary, and despite it receives STATUS frames. The conclusion is
that the content of STATUS frames becomes wrong ( they have been good before $tsimt = 1500 !) and some
errors can exist in the list building process at the receiver. Indeed it was the case. After put a "zoom"
verification on that part of the specification, one found out that the receiver had problems when building some
complex retransmission lists (this situation would not have been appeared if were not severe loss in the
medium) - because some errors in the repeated loop of list construction. The example above showed how one
can find detail errors in the specification using PE simulation.
One important question has be answered: how can one know what to observe/monitor, during these
experiments? A general precise answer cannot be done. But in principle one have to:
- define dedicated experiments to observe the main functions of the protocol: data transfer flow and
sequence number error control, flow control, resynchronization, protocol error control, etc.
- define the key variables whose evolution has to be watched. Here we mention the main data and flow
control variables: buffer manager variables, window limits at transmitter and receiver, sequence numbers, etc.
- create an hostile environment for the protocol machine to put in in adverse conditions able to sollicit
the whole functions of the protocol. Especially we mention the lower layer which can be able to behave very
badly w.r.t data and control packets and to vary the RTT values. The probabilities of errors ( loss, duplication,
order reversal), events must be significantly higher than in normal conditions.
- execute random simulation experiments.
Following these principles is very probable that the protocol will follow a high number of its possible
trajectories and PE diagrams show, if they exist, wrong behaviors.
The general conclusion is that using the PE simulation in extensive range conditions can reveal
some deeply hidden errors that are difficult to fixed while using the conventional automata verification
methods.
6.2 Using the PE simulation to find inefficiencies/errors in the protocol
definition
PE can be used to find some possible errors in the protocol definition if they are related to the data
transfer functions. One should perform PE in an extensive range of conditions. Here we give an example of
this kind of error present in Q.2110 Reccomendation.
The conditions of the experiment have been realized on a duplex data transfer :
Configuration ( instance number involved):
(User-11) - (Protocol-3) - (Medium-10) - (Protocol-6) (User-12)
Note: 1 ETU ( Estelle Unit Time ) is a conventional time value unit we have used in our simulations; it is
corresponding to 10 µs of physical time. All time values are represented in ETU, including the delays, packet
durations, round trip time (RTT), etc.
USER layer:
User output rate = 4000KB/s ( 32Mbit/s)
SDU length = 1024 Bytes - fixed length , 50 frames transmitted in each direction.
tdly = 26 ETU - delay between two successive SDUs given by the user layer, corresponding to the above rate.
16
PROTOCOL layer :
Transmitter buffer length = receiver buffer length = W (maximum transmitting window) = 20 frames
Timer Poll-3 = 1000 ETU for Protocol-3; Timer Poll-6 = 500 ETU for Protocol-6, twice less than the
former. We have chosen two different values of the Timer POLL for the two instances of the protocol modules
expecting different behavior w.r.t the efficiency of the flow control function.
vtpd = 5 - the maximum number of frames that are allowed to be sent by the transmitter, between two POLLs.
This is an additional flow-control related protection mechanism of the protocol, in order to avoid the excessive
accumulation of the sent and not-acknowledged packets in the Transmitter Buffer.
MEDIUM layer :
The ideea is to select such values that we intentionally put the protocol in very hostile environment
conditions w.r.t buffer fill, credit, need to make numerous retransmissions of data and control frames and
process complex retransmission list structures. This increases significantly the coverage factor of the
trajectories followed by the protocol machine. Related to this is the choice to have the Timer POLL values
significantly greater than RTT.
Propagation delay 10->pdly:=30 ETU. If neglecting some other delays this corresponds to a RTT = 60 ETU.
Loss probability of the frame: 10->prob[lost]:=0.3
Medium rate = 40Mbit/s which corresponds to 20 ETU delay for transmission of one packet of 1024 Bytes
Of course, in such adverse conditions one expect a poor performance of the protocol. Indeed this the
case, i.e. we obtained the following rates measured at the user level:
Sender User-11 / Receiver User-12
Rates in [KBytes/s]
Sender User-12/ Receiver User-11
Rates in [KBytes/s]
3938.46 / 461.45
efficiency: 11 %
3861.23 / 1102.76
efficiency: 28 %
We started assumming that the Q.2110 Recommendation Reference SDL diagrams are fully correct.
But we discovered during PE, that the vtpd - based mechanism is not at all working in high fill
transmitter buffer and lack of credit working conditionn. The only remaining hope for the transmitter is getting
new credit based on periodically sent POLL frames. But if the Timer POLL is considerably greater than RTT,
this will slow significantly the data process. In fact there is one branch of Fig 20/Q.2110 (sheet 38 of 51 transition devoted to process SD (re) transmission or POLL send in case of low credit), which should work in
lack of credit conditions that can never be executed. Specifically the branch defined in the transition body by
[VT(S) < VT(MS)] = false, that is lack of credit - condition, can never be executed because in the former
provided clause there is one condition [VT(S) < VT(MS)] = true.
Another Q.2110 SSCOP SDL specification problem is its non-uniformity. While the processing of the
retransmission lists is fully SDL specified including deep details ( which would have been better left to the
implementation), Q.2110 says nothing on the protocol sender behavior - w.r.t.control flow, in full transmitter
buffer condition ( e.g. the same transition Fig 20/Q.2110 sheet 38 of 51). The full buffer condition is as well
potential dangerous as lack of credit and it should be treated explicitely in the standard.
The above facts have been revealed, first by PE simulations done in the above described conditions, by
observing that the only mechanism still active in high transmitter overload and lack of credit condition is Timer
POLL periodically sending mechanism. This explains why in the experiment the efficiency of 11->12 sense is
much worse (11 %) than in the reverse sense 11<-12, see the greater Timer POLL value of protocol
transmitter -3; the transmitter-3 is working in harder condition that transmitter-6.
The above cosiderations are illustrated by the diagrams Fig.6-9 to 6-16.
17
Fig.6.9 Trs.-3: available credit
Fig.6.10 Trs.-6: available credit
Fig. 6.12 Trs.-6 frame count in the TrsBuf
Fig. 6.11 Trs.-3 frame count in the TrsBuf
Fig. 6.14 Trs.-3 frame count in the TrsQ
Fig. 6.13 Trs.-3 frame count in the TrsQ
18
Fig. 6.15 Rec.-6 SD receive transition use
Fig. 6.16 Rec.-3 SD receive transition use
Fig. 6-9 to - 6.16 show that during the 50 packets transfer the both protocol instances suffer of lack
of credit and the transmission buffer is full. In these conditions new frames can be sent only if new credit is
obtained based on periodical POLL sending, because the data amount driven POLL mechanism is no more
active. If the some POLLs are lost due to medium errors then the protocol throughput will decrease
significantly. That is why the instance
6.3 FDT-based PE results compared with those of other methods
Because we base on random simulations, it is important to know if if results are comparable to other
methods results reported elsewhere. The simulation experiments following the above presented principles and
the configuration described in the previous sections, have been conducted to study the throughput
characteristics of the SSCOP in different medium conditions and protocol parameters / policies. We compared
the FDT base PE results to those presented in [HT95].
It is shown in [HT95] by analytical study and simulation on a separate model, that there exist three
regions in which the protocol can work w.r.t. the efficiency of flow control. We verified in our simulation that
these regions exists. The additional results of our study are: - the simulation are done on the real specification
of the protocol not on a simplified separate model ; - we can simulate the functioning at very severe error
conditions ( e.g. prob(loss) = 0.1, or 0.2, per frame).
The parameter involved are ( measured in frame count, for given rate of the medium and fixed length
of the packets): W= transmitter window granted by the receiver ; TR = bandwidth-delay product ; TP =
timer-poll-interval of the sender to request credit from the receiver. All the three values are normalized by
division of the real value to the duration of the frame transmission in the medium. The latter itself depends on
the medium rate value.
Simplyfying assumptions are given in [HT95], in order to permit analytical treatment of the process.
The main ones are:
- the frame loss is sufficiently low ( p < 10-3), all retransmmisions are successful at the first try
- the control packets are not affected by errors, this is evidently not true in real cases
- all times are deterministic
- the open flow control loop is assummed , the window offered by the receiver (W) is no more than
the receiver buffer available.
If the above hypotheses hold then paper [HT95] shows that the three regions are:
(1) W < TR + TP ;
(2) TR + TP ≤ W ≤ 2*TR + TP ;
(3) 2*TR + TP ≤ W
19
If (1) is true then the protocol sender sometimes stop because the lack of credit. In (2) the sender will
stop only if errors are encountered, that is frame loss. In (3) the protocol never stops even in error conditions.
The FDT based PE evaluation is no more constrained by the above simplyfing assumptions. We
have kept only the fourth hypothesis true.We give just some samples of our results in the table below.
Here are the rate results given by our simulations.
General conditions :
User : packet length = 1024 Bytes, user-rate = 32 Mbit/s, 100 packets, bidirectional transfer
Protocol: W= 20, different values for TR, TP ( see the following table)
Medium : p = prob(medium-loss) = 0.05; 0.1; medium-rate = 40 Mbit /s
Sender measured rate in all cases : 3899 Kbytes/s
The following table 6.1 shows the throughputs mesured at the receivers after the acknowledged
complete transfer of the 100 packets in both directions. The throughput is measured as a fraction given by the
receiver rate versus corresponding sender rate. The values, rather high wrt the error probability are explanined
by the fact that the amount of transferred data is limited at 100 packets that is for a short connection.
Region
(1) W < TR + TP
TR = 10, TP = 20
(2) TR + TP ≤ W ≤
2*TR + TP
TR = 10, TP = 5
(3) 2*TR + TP ≤ W
TR = 3, TP = 5
Rec. USER-11 rates [KBytes /s]
p = 0.05
p = 0.1
0.90
0.65
Rec.USER-12 rates [KBytes /s]
p = 0.05
p = 0.1
0.84
0.62
0.96
0.74
0.89
0.70
0.97
0.94
0.94
0.92
Table 6.1 The flow control regions results
One can see the different results for the three regions. The differences between the rates of the two
receivers are due to the non uniform distribution of the errors on the two directions and some delays measured
additionally by the User-11 (this is supposed to start and end the connection and the establishment and release
time is added to the total value spent by the receiver).
The following diagrams Fig.6.17 show the variation in time for the credit_available variable of the
transmitter and the corresponding current buffer fill at the sender in high error conditions ( prob[loss] =
0.1)for work in the three region described above. On can see that there are significant differences between the
values especially we see the worst condition in the region (1). The conclusion is that one have to avoid enetring
in this region. But the fixed value supposed by the standard for the Timer POLL leads to difficulties in
variable RTT conditions ( excessive number of redundant POLLs in one limit case or not enough POLLs in
the other case).
That is why in the next section some simple adaptive algorithm is proposed for the Timer POLL.
Other simulation have been done to evaluate the influence of non-zero processing times on the
throughput.
The conclusion is that one can select the best sets of parameters for protocol configuration based on
the results of PE done on formal specification simulations.
20
Fig. 6.17 Variation of credit_available and current transmitter buffer fill in the three regions.
6.4 Enhanced flow control policy for SSCOP
Realizing the fact that the throughput of the standard protocol is essentially based on the periodically
sent of POLL frames, that is on the Timer POLL value and taking into account the inefficiency presented in
the Section 6.2, we experimented a simple adaptive adjustment of the Timer POLL in order to increase the
independency of the sender on the fixed value defined in the standard.
The complete analysis of the new solution will be presented in another paper. We note the fact that the
efficacity of the proposed solution is higher especially in hard work conditions ( high loss, limited capacity of
buffers). The main ideeas of the adjustment algorithm are the following:
- if the sender becomes congested (transmission buffer (TrsBuf) is full or it has no more available
credit) then it sends a POLL and enters a special phase in which the Timer POLL value is reduced at a
minimum value. The frequency of POLLs increases, hoping that in that way the receiver will respond with
some credit.
- if the congestion condition disappears then the Timer POLL is linearly increased up to a maximum
value provided no new congestion does not appear.
The solution does not modifies the general behavior of the protocol, keeping the compatibility to other
standard SSCOP implementations. Also extension of the algorithm can be easily done by correlation of the
minimum and maximum values of Timer POLL with RTT measuring algorithms (e.g. Van Jacobson, etc.).
We present in the following diagrams comparative results between the behaviors of the standard flow
control policy and the adaptive one, in high error condition ( prob[loss] = 0.3).The initial TimerPOLL values
for teh two experiments is the same Timer POLL = 500 ETU and RTT = 60 ETU
The Fig. shows the result: the receiver buffer in the adaptive case is emptied faster by a 1.3 f&actor.
Th differences are higher if the initial values of the Timer POLL are larger.
21
Fig.6.18 The transmitter buffer fill for the standard (first fig.) and adaptive flow control (second fig.)
Fig. 6.19 The credit available at the transmitter ( up - adaptive; bottom- standard)
22
The Fig.6.19 diagram shows why the adaptive algorithm is better: the transmitter obtains faster new
credit, going out faster from the congested condition.
VII CONCLUSIONS
The conclusions of this study are:
- the main performance related results on the studied real case - SSCOP protocol behavior are similar
to those obtained by other techniques, this approach having the advantage of no need to construct a separate
model but using the specification itself,
- protocol configuration hints can be obtained,
- PE can be used as a complement to validation methods,
- PE can lead to discover some inefficiencies of the protocol definition,
- some prediction on the implementation performance can be obtained,
- other future protocol extension features (e.g. rate control, working on top of a connectionless
medium , etc.) can be easily added and studied on the same basic specification, without having to build a new
simulation model.
REFERENCES
[ABB93] B.Alkechi, M.Benalycherif, S.Budkowski, O.Catrina, P.Dembinski, M.Gardie, E.Lallet, J.P.Mouchel la
Fosse, Y.Souissi, Formal Specification, Validation and Performance Evaluation of the Xpress Transfer Protocol(XTP),
Research Report 931004, INT Evry, France, 1993.
[SB92] S.Budkowski, «Estelle Development Toolset.» Computer Networks and ISDN Systems Journal, Special
Issue on FDT Concepts and Tools, vol.25, no.1, 1992.
[BMB97] E.Borcoci,N.Munteanu,S.Budkowski, «L’evaluation des performances pour des protocoles de
communication à haute complexite en utilisant les specifications Estelle», Actes du Colloque Francophone sur
l’Ingenerie des Protocoles, Hermes, 1997, pp. 349-364.
[BCM96] E. Borcoci, O. Catrina, N. Munteanu «Efficiency evaluation of flow control policies for the Xpress
Transport Protocol», 4.04th International Conference on Telecommunication and Information Systems, TIS'96 Zilina,
Slovakia, 4-6 September 1996.
[BMC97] E. Borcoci, N. Munteanu, O. Catrina, «Experiments with Performance Evaluation of XTP4.0»,
Deliverable Doc., COP62/WP.2/7 -1/2, COP62/WP.2/7 -2/2, Feb 1997 .
[BMS96] M.Bütow, M.Mestern, C.Schapiro, P.S.Kritzinger, «Performance Modelling with the Formal
Specification Language SDL», Formal Description Techniques IX, edited by R.Gotzhein,
J.Bredereke,
Chapman & Hall 1996.
[CB96] O.Catrina, E.Borcoci, XTP specifications in Estelle, Deliv., COP62/WP.2/1, COP62/WP.2/2, 1996.
[CLB97] O.Catrina, E.Lallet, S.Budkowski XTP Prototype Implementation, Deliverable Doc., COP62/WP.2/9,
Feb. 1997.
[DHM96] M.Diefenbruch, J.Hintelman, B.Müller-Closterman , The QUEST_Approach for the Performance
Evaluation of SDL Systems, Formal Description Techniques IX, edited by R.Gotzhein, J.Bredereke, Chapman&Hall
1996.
[EB94] E.Borcoci, "Contributions to the formal specifications of the signaling protocol SSCOP for ATM
networks", Internal Research Report, Institut National des Télécommunications, 1994.
[HB96] M.Hendaz, S.Budkowski, Efficiency Evaluation Tool for Estelle, Deliverable COP62/WP2/5, 1996.
[HB96a] M. Hendaz, S. Budkowski Edb: Un Simulateur Estelle pour l'Evalution de Performance, CFIP'96 ,
Oct.1996, Rabat, Maroc.
[SB98] S.Budkowski et al., EDT - Estelle Development Toolset - Version 4.1, INT, Evry, France, 1998.
[TH95] T.R.Henderson, Design Principles and Performance Analysis of SSCOP: a new ATM Adaptation Layer
Protocol, ACM SIGCOMM Computer Communication Review, vol.25, No.2, April 1995.
[B98] S.Budkowski et al., EDT - Estelle Development Toolset - Version 4.1, INT, Evry, France, 1998.
[ITU-T1] ITU-T Recommendation I.150 - BISDN ATM Functional Characteristics
[ITU-T2] ITU-T Recommendation I.361- BISDN ATM Layer Specification
[ITU-T3] ITU-T Recommendation Q.2931 - BISDN Acces Signaling System DSS2
[ITU-T4] ITU-T Recommendation Q.2110 - Service Specific Connection Oriented Protocol (SSCOP)
[ITU-T5] ITU-T Recommendation Q.2100 - BISDN Signaling ATM Adaptation Layer (SAAL) Overview
Description
23