ISO/IEC TR 9571:1989
(Main)Information technology — Open Systems Interconnection — LOTOS description of the session service
Information technology — Open Systems Interconnection — LOTOS description of the session service
Traitement de l'information — Interconnexion de systèmes ouverts — Description en LOTOS du service de session
General Information
Standards Content (Sample)
TECHNICAL ISO/IEC
REPORT TR 9571
First edition
1989-09-1 5
Information technology - Open Systems
Interconnection - LOTOS description of the
session service
Traitement de l'information - Interconnexion de systèmes ouverts - Description
en LOTOS du service de session
Reference number
ISO/IEC/TR 9571 : 1989 (E)
---------------------- Page: 1 ----------------------
ISO/IEC/TR 9571 : 1989 (E)
Contents
iii
Foreword
iv
Introduction
1
1 Scope
1
Normative references
2
2
3 De finitions
2
Symbols and abbreviations
4
2
5 Conventions
3
6 Introduction to the formal description
4
7 Global constraints of the session service
5
8 Provision of a single session connection
6
9 Local constraints at a session connection endpoint
6
9.1 interface data types
24
9.2 Processes for local constraints
35
10 End-to-end constraints for a session connection
36
10.1 Association data types
41
10.2 Processes for end-to-end constraints
44
11 Identification of session connections
46
12 Acceptance of session connections
46
B ackpressure flowcontrol
13
O ISO/IEC 1989
All rights reserved. No part of this publication may be reproduced or utilized in any form or by any
means, electronic or mechanical, including photocopying and microfilm, without permission in
writing from the publisher.
ISO/IEC Copyright Office 0 Case postale 56 0 CH-I211 Genève 20 O Switzerland
Printed in Switzerland
ii
---------------------- Page: 2 ----------------------
ISO/IEC/TR 9571 : 1989 (E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) together form a system for worldwide
standardization as a whole. National bodies that are members of IS0 or IEC
participate in the development of International Standards through technical
committees established by the respective organization to deal with particular
fields of technical activity. IS0 and IEC technical committees collaborate in
fields of mutual interest. Other international organizations, governmental and
IS0 and IEC, also take part in the work.
non-governmental, in liaison with
In the field of information technology, IS0 and IEC have established a joint
technical committee, ISO/IEC JTC 1.
The main task of a technical committee is to prepare International Standards but
in exceptional circumstances, the publication of a technical report of one of the
following types may be proposed:
- type 1, when the necessary support within the technical committee cannot
be obtained for the publication of an International Standard, despite
repeated efforts;
- type 2, when the subject is still under technical development requiring
wider exposure;
- type 3, when a technical committee has collected data of a different kind
an International Standard ('state
ïrom that which is normally published as
of the art', for example).
Technical reports of types 1 and 2 are subject to review within three years of
publication, to decide whether they can be transformed into International
Standards. Technical reports of type 3 do not necessarily have to be reviewed
or useful.
until the data they provide are considered to be no longer valid
ISO/IEC/ïR 9571, which is a technical report of type 2, was prepared by ISO/IEC
Information technology.
JTC 1,
iii
---------------------- Page: 3 ----------------------
ISO/IEC/TR 9571 : 1989 (E)
Introduction
In view of the complexity and widespread use of Open Systems Interconnection
standards it is imperative to have precise and unambiguous definitions of these
standards. Formal Description Techniques form an important approach for
providing such definitions. The use of Formal Description Techniques in this area
is however relatively new and their application on a wide scale cannot be
expected overnight. Formal descriptions should be introduced gradually in
standards if initially the number of Member Bodies that are able to contribute to
their development is too small, thus allowing time to gain experience and to
develop educational material.
An ad-hoc group for the formal description of the Session Layer, i.e. of the
Session Service IS0 8326 and the Session Protocol IS0 8327, was established in
November 1985. This group applied the Formal Description Technique LOTOS,
defined in IS0 8807, which at that time was still under development. In
September 1986 two Working Documents were produced which contained the
LOTOS draft specifications of IS0 8326 and IS0 8327 respectively. As a
also produced a number of Defect Reports on the standards,
byproduct, the group
most of which have been accepted and incorporated in the standards.
A Ballot was then issued requesting Member Bodies to state their position
concerning the progression of the formal descriptions. Based on this Ballot, SC21
decided in June 1987 to progress both formal descriptions as Type 2 Technical
Reports. The main reason for not incorporating them into the standards was that
of expertise on the subject. It seemed
Member Bodies expressed their current lack
a period of time passed, during which the formal
therefore appropriate that
decriptions can be read and compared with the standards, and after which the
status and progression of the formal descriptions can be re-evaluated.
The purpose of this Technical Report is to provide a complete, consistent and
unambiguous description of IS0 8326. It forms therefore a companion document
to IS0 8326. It takes account of the Defect Reports incorporated in the standard
(annex A of IS0 8326), however, it does not necessarily take account of
subsequent amendments or addenda to the standard.
iv
---------------------- Page: 4 ----------------------
TECHNICAL REPORT ISOIIECTTR 9571 : 1989 (E)
I
Information technology - Open Systems Interconnection -
LOTOS description of the session service
1 Scope
0 This Technical Report contains a formal description of the OS1 Basic Connection Oriented Session Service
defined in IS0 8326. The formal definitions presented in this Technical Report are expressed in the formal
description technique LOTOS, which is defined in IS0 8807.
These formal definitions are applicable for use in formal descriptions in LOTOS of the OS1 Connection
Oriented Session Protocol defined in IS0 8327, namely ISO/IEC TR 9572, and of the OS1 Connection
Oriented Presentation Protocol defined in IS0 8823.
The formal description is not limited to a single session connection, but also describes the service instances
that result from multiple session connections either in parallel or in sequence. It therefore also formalizes
aspects of multiplicity which are not presented in IS0 8326 directly, but by way of reference to the OS1
1
I
Basic Reference Model, IS0 7498.
2 Normative references
The foliowing standards contain provisions which, through reference in this text, constitute provisions of
I
I
this Technical Report. At the time of publication, the editions indicated were valid. All standards are
l
subject to revision, and parties to agreement based on this Technical Report are encouraged to investigate
the possibility of applying the most recent editions of the standards listed below. Members of IS0 and IEC
I
maintain registers of currently valid International Standards.
I
l 1
IS0 7498: 1984, Information processing systems - Open Systems Interconnection - Basic Reference Model.
IS0 8326: 1987, Information processing systems - Open Systems Interconnection - Basic connection
I
l oriented session service definition.
I
l
IS0 8327: 1987, Information processing systems - Open Systems Interconnection - Basic connection
oriented session protocol specif cation.
1
ISORR 8509: 1987, Information processing systems - Open Systems Interconnection - Service conventions.
I
IS0 8807: 1988, Information processing systems - Open Systems Interconnection - LOTOS - A formal
t
,
description technique based on the temporal ordering of observational behaviour.
1
---------------------- Page: 5 ----------------------
ISOAECTTR 9571: 1989 (E)
IS0 8823: 1988, Information processing systems - Open Systems Interconnection - Connection oriented
presentation protocol specification.
ISO/IEC/ïR 9572: 1989, Information processing systems - Open Systems Interconnection - LOTOS
description of the session protocol.
ISO/IEC/ïR 10023: - 11, Information processing systems - Open Systems Interconnection - LOTOS
description of the transport service.
3 Definitions
For the purpose of this Technical Report the definitions given in IS0 8326 apply.
4 Symbols and abbreviations
This Technical Report uses the symbols defined in clause 6 (formal syntax) and annex A (data type library)
0
of IS0 8807, and uses the abbreviations contained in clause 4 of IS0 8326.
are employed in this Techical Report:
The following additional abbreviations
SC session connection
SCEP session connection endpoint
SCE1 session connection endpoint identifier
SSP session service primitive
5 Conventions
Clauses 6 through 13 of this Technical Report constitute LOTOS text. All informai explanations in these
clauses form LOTOS comments. They are thus separated from the LOTOS specifications (of data types and
dynamic behaviour) according to the rules for comment delimitation. Moreover, informal explanations
precede the formal definitions to which they refer and contain a final line of only "-" characters. Informal
0
explanations following formal definitions contain a first line of only "-" characters.
Formal definitions, as well as formal symbols and identifiers referenced in informal explanations, are
printed in italics.
The conventions defined in ISO/ïR 8509 are adopted.
1) To be published.
2
---------------------- Page: 6 ----------------------
ISO/IEC/TR 9571 : 1989 (E)
6 Introduction to the formal description
The formal description relates to the dynamic behaviour observable at the SS boundary. The whole service
boundary is formally represented by a single gate s. Events at s consist of three values, of sort SAddress,
SCE/ and SSP, respectively. The first value identifies the SSAP where the event occurs. The second value
identifies the SCE1 within that SSAP where the event occurs. The third value represents the SSP executed
in the event.
NOTE - An event is an atomic form of interaction. SSPs are thus represented as atomic interactions, which is
consistent with IS0 8326. However, for reasons of consistency with the formal description of the session protocol,
where flow control and segmenting require a finer granularity of those SSPs that can carry an unlimited amount of
user data, this representation may have to be changed.
The possibility of multiple concurrent and consecutive SCs is represented by the formal description. Since
this multiplicity is not restricted other than by nondeterministic decisions to not service certain requests and
e by the requirement of unambiguous use of SCEIs, the behaviour described is that of a non-terminating SS-
provider.
A constraint-oriented style is adopted for the specification: different "types" of constraints in the service
definition are specified in separate processes; these processes are appropriately composed, either
synchronized or unsynchronized, in the specification to represent the total set of constraints. The
decomposition in separate constraints is done at several levels.
The top level decomposition shows a structuring of the global constraints of the session service into the
following separate constraints:
The dynamic behaviour of all potential SCs (described by process SConnections). This constraint
is explicitly not concerned with the constraints below, i.e. it assumes no limits on the SS-provider
capacity and does not care about administrative concerns for connection identification.
The correct allocation of SCEIs (described by process SCldenfification). It seems to be an explicit
choice of IS0 7498 not to specify any requirement on local identification of connection endpoints,
other than the obvious one that connection endpoint identifiers locally provide the means of
distinguishing connections at the same service access point. This constraint applies precisely to
this requirement.
The acceptance vs. refusal of new SCs by the SS-provider (described by process SCAccepfance).
In spite of the "independence" of concurrent connections, finiteness of resources implies that
interdependencies may exist. Such interdependencies concern the availability of resources to new
connections in the same end-system, i.e. the ability of the service provider to accept an additional
connection.
The backpressure flow control exerted by the SS-provider (described by process SBackpressure).
This constraint relates to the fact that existing connections may be temporary blocked by the
service provider, e.g. for reasons of resource shortage.
Constraint a) above is further decomposed into constraints related to the dynamic behaviour of a
single SC (described by process SConnecfion). Each of these, in turn, is decomposed into "local"
and "end-to-end" constraints (described by process SCEP and process SCEPAssociafion,
3
---------------------- Page: 7 ----------------------
ISO/IEC/TR 9571: 1989 (E)
rcspectively). Local constraints are constraints which are local to a SCEP, whereas end-to-end
constraints concern the end-to-end relations which result from the exchange via the SS-provider.
Figure 1 gives an overview of the processes used for the formal definition of the Session Service and their
relations (some of the lowest level processes are omitted). It also indicates the clauses where the definition
of these processes can be found.
Sessionsetvice (7)
SConnéctions SCidehfication SCAcZeptance SBa2 siressure
(7) (11) (1 2) (1 3)
..
0
(9.2.1) (1 0.2.2)
I l
ConstantSCEi S SSPEvent
(9.2.1 ) Propose (9.2.3) Accept(9.2.3) Reject (9.2.3) Abort (9.2.3) (1 0.2.3)
SCEPData Transfer
(9.2.4)
(9.2.4.1) (9.2.4.2) (9.2.4.3)
Figure 1 - Processes related by a tree structure: each "father" process contains (or is constructed
from) one or more instances of its immediate "descendant" process(es)
The definition of data types precedes the definition of the dynamic behaviour in which these data types are
used. Apart from standard data types, which are imported from the LOTOS library of data types, and some
"ad-hoc" data types, two groupings of data types are identified, namely interface data types and association
data types. Interface data types are used in the specification of local constraints, and are to be shared with
the formal descriptions that may interwork with the present one, namely those of the Session Protocol and
of the Presentation Protocol. Association data types are used in the specification of the end-to-end
constraints; they abstract from the underlying protocol and are therefore probably not re-usable in other
formal descriptions.
7 Global constraints of the session service
Standard data types for the construction of a boolean, a natural number, a generic set, a string of octets, and
representations of a natural number (including the decimal representation) are imported from the LOTOS
library of data types by means of the libraryconstruct.
4
---------------------- Page: 8 ----------------------
ISO/IEC/TR 9571 : 1989 (E)
!
The specification of the behaviour of the SS-provider consists of the conjunction of four separate
constraints, as explained in clause 6. SConnections is described as being able to support a potentially
infinite number of independent SCs. Concurrency is here represented by multiple instances of
SSuccConnections, where each instance describes a succession of SCs. An SC is represented by a distinct
instance of SConnection. Each instance of SConnection can terminate. The composites SConnections and
SSuccConnections can never terminate because the possibility always exists that a new instance of
SConnection is invoked. Thus, at any time, any number of SCs can be active. The SS-provider's
nondeterminacy in limiting this potentially infinite concurrency is specified as a separate constraint, viz. by
SCAcceptance (see clause 12). SCldentification prescribes unique identification of SCEPs (see clause 11).
SBackpressure enforces the constraint relating the SS-provider's backpressure (see clause 13).
...............................................................................................................................
*>
specification SessionService [s]: noexit
library FBoolean, Boolean, NaturalNumber, Element, Set, Octetstring, NatRepresentations endlib
behaviour
SConnections [s] // SCldentification [s] // SCAcceptance [s] // SBackpressure [s]
0
where
process SConnections [s]: noexft := SSuccConnections [s] /// SConnections [s]
where
process SSuccConnections [s]: noexit := SConnection [s] >> SSuccConnections [s] endproc
endproc (* SConnections *)
8 Provision of a session connection
Two separate constraints are distinguished with respect to the behaviour of a single SC, namely local
constraints and end-to-end constraints. Local constraints apply to the possible behaviour at each SCEP
taking only into account the history of SSPs executed at that SCEP. End-to-end constraints, on the other
hand, relate the possible behaviour at each SCEP to the history of SSPs at the other SCEP (that is, the other
end of the SC).
Local constraints are represented by two parallel instances of SCEP (see 9.2) that apply to the interaction
with the Calling SS-user and with the Called SS-user, respectively. The type SSUserRole presents two
constants that distinguish between these roles (see 9.1.5.1 for the definition of Doublet). End-to-end
constraints are represented by an instance of SCEPAssociation (see 10.2).
The end of the SC lifetime is represented by termination of the two instances of SCEP, they force the
instance of SCEPAssociation, a non-terminating process, to be disabled.
...............................................................................................................................
"1
type SSUserRole is Doublet renamedby
sortnames SSUserRole for Doublet
opnnames calling for constant 7 called for constant2
endtype
process SConnection [SI: exit :=
( SCEP [s] (calling) /// SCEP [s] (called) ) // ( SCAssociation is] [. exit )
endproc
5
---------------------- Page: 9 ----------------------
ISO/IEC/TR 9571: 1989 (E)
9 Local constraints at a session connection endpoint
9.1 Interface data types
The interface data types consist of definitions for the construction of a Session (Service Access Point)
address (see 9.1.1), a SCEI (see 9.1.2), and a SSP (see 9.1.3 and 9.1.4). A number of auxiliary definitions of
general use are presented in 9.1.5.
Almost all type definitions include the definition of two infix boolean functions, e9 and ne, for testing the
equality and unequality, respectively, of two values of some sort.
9.1.1 Session address
No structure of the (Calling, Called or Responding) Session Address parameter is defined by IS0 8326. The
following definition allows to represent an infinite number of Session Address values.
____________________----------~-~~~~~~~~-----~-~--------.~~~~~~~~-~~~~-------------~~-~--~--~-----~----------------------------
*I
type SessionAddress is Boolean
sorts SAddress
opns
someAddress: -> SAddress
AnotherAddress: SAddress -> SAddress
- e9-, -ne-: SAddress, SAddress -> Boo1
eqns forall a,a 1 :SAddress ofsort Boo1
al nea=not(al eqa); someAddress e9 someAddress = true;
someAddress eq AnotherAddress (a) = false; AnotherAddress (a) eq someAddress = false;
AnotherAddress (a I) e9 AnotherAddress (a) = a 1 e9 a;
endtype
9.1.2 Session connection endpoint identifier
No structure of SCEIs is defined by IS0 8326. The following definition allows to represent an infinite
number of SCEI values.
9.1.3 Session service primitive
The specification of the SSP type is accomplished by way of a number of hierarchical type definitions.
First, the basic construction of SSP values is presented (see 9.1.3.1), then a classification of SSPs (see
9.1.3.2), and subsequently a number of additional functions on SSPs (see 9.1.3.3 through 9.1.3.5). The
individual SSP parameters are defined in 9.1.4.
6
---------------------- Page: 10 ----------------------
ISO/IEC/TR 9571 : 1989 (E)
9.1.3.1 Session service primitive basic construction
The construction of SSP values in type BasicSSP is a direct formulation of table 5 through 7 of IS0 8326.
The functions that yield SSP values are referred to as "constructor" functions. This definition imports the
definitions that relate to SSP parameters (see 9.1.4).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
)
type BasicSSP is
SCldentifier, SessionAddress, SQuality, SConnectResult, SRequirements, SSynchronizationNumber,
STokensAssignment, SData, STokens, SSyncMinorType, SResynchronizeType, SPExceptionReason,
I
SUExceptionReason, SActivityldentifier, SReleaseResult, SPAbortReason
sorts SSP
opns
SCONreq, SCONind: SCRef, SAddress, SAddress, SOOS, SFUs, SSPSN, STsAss, SData -> SSP
,
SCONrsp, SCONcnf: SCRef, SAddress, SConResult, SOOS, SFUs, SSPSN, STsAss, SData -> SSP
I
SDTreq, SDTind, SEXreq, SEXind, STDreq, STDind, SCDreq, SCDind, SCDrsp, SCDcnf, SSYNMarsp,
SSYNMacnf,SUABreq, SUABind, SACTErsp, SACTEcnf, SRELreq, SRELind: SData -> SSP
I
SGTreq, SGTind: STokens -> SSP
SPTreq, SPTind: STokens, SData -> SSP
0
SCGreq, SCGind, SACTlrsp, SACTlcnf, SACTDrsp, SACTDcnf: -> SSP
SSYNmreq, SSYNmind: SSyncType, SSPSN, SDa ta -> SSP
SSYNmrsp, SSYNmcnf, SSYNMareq, SSYNMaind, SACTEreq, SACTEind: SSPSN, SData -> SSP
-> SSP
SRSYNreq, SRSYNind: SResynType, SSPSN, STsAss, SData
SRSYNrsp, SRSYNcnf: SSPSN, STSASS, SData -> SSP
SPERind: SPExcReason -> SSP
SUERreq, SUERind: SUExcReason, SData -> SSP
,
SACTSreq, SACTSind: SActld, SData -> SSP
1
SACTRreq, SACTRind: SActld, SActld, SSPSN, SCRef, SData -> SSP
1 SACTlreq, SACTlind, SACTDreq, SACTDind: SUExcReason -> SSP
SRELrsp, SRELcnf: SRelResult, SData -> SSP
~
SPABind: SPAbReason -> SSP
I endtype
9.1.3.2 Session service primitive classification
~
Type SSPConsfant defines a classification of SSPs. Each class, or "type", of SSP is represented by a
constant with a name similar to the name used in table 5 through 7 of IS0 8326 to represent the SSP. The
auxiliary function h that maps these constants to natural numbers is defined in order to simplify the
dcfinition of equality on SSP classes (and on SSP values, see 9.1.3.4). The boolean function IsConstantReq
determines whether its argument is a constant indicating a request or response SSP. Similarly,
IsConstantlnd characterizes indication or confirm SSPs. Even and Odd are auxiliary functions used in the
definition of IsConstantReq and IsConstantlnd. Succ is dcfincd by the standard type NaturalNumber and
yields the successor of a given natural number.
Type SSPBasicClassifiers is a functional enrichment of type BasicSSP. It defines a function k that yields
the constant corresponding to its argument SSP (thus relating abbreviated SSP names to their full names;
the abbreviated names correspond with those defined in annex A of IS0 8326, except SSYNMa which
corresponds with SSYNM). Furthermore, "recognizer" functions are defined that test whether their
SSP is of a certain class. There are functions to test whether a SSP is a request, indication,
argument
response, or confirm of a particular service. In addition, there are functions that test whether a SSP is either
a request or indication, or either a response or confirm of a particular service. IsReq and lslnd recognize
whether the argument SSP is respectively a request or response and an indication or confirm;
IsProvGenerated recognizes whether the argument SSP is generated by the SS-provider.
I 7
---------------------- Page: 11 ----------------------
ISO/IECTTR 9571 : 1989 (E)
________________________________________----------~~~~~--.~-----_~-_"~_~~----------------~~-----~---~---------------------------
"1
type SSPConstant is NaturalNumber
sorts SSPConstant
opns
S-CONNECTrequest, S-CONNECTindication, S-CONNECTresponse, S-CONNECTconfirm,
S- DA TArequest, S- DA TAindication, S- EXPEDITED- DA TArequest, S- EXPEDITED- DA TAindication,
S- TYPED-DATArequest, S- TYPED-DATAindication, S-CAPABILITY-DATArequest,
S-CA PABlL ITY- DA TAindication, S-CAPABIL ITY- DA TAresponse, S-CA PABlL ITY- DA TAconfirm,
S- TOKEN-GIVErequest, S- TOKEN-GIVEindication, S- TOKEN- PL EASErequest,
S- TOKEN-PL EASEindication, S-CONTROL-GIVErequest, S-CONTROL-GIVEindication,
S-SYNC-MINORrequest, S-SYNC-MINORindication, S-SYNC-MINORresponse,
S-SYNC-MINORconfirm, S-SYNC-MAJORrequest, S-SYNC-MAJORindication,
S-SYNC-MAJORresponse, S-SYNC-MAJORconfirm, S-RESYNCHRONIZErequest,
S-RESYNCHRONlZEindication, S- RESYNCHRONlZEresponse, S- RESYNCHRONlZEcon firm
S- P-EXCEPTION-REPORTindication, S- U-EXCEPTION-REPORTrequest,
S-U-EXCEPTION-REPORT-indication, S-ACTIVITY-STARTrequest, S-ACTIVITY-STARTindication,
S-A C TI VI TY- R ES UM Erequest, S-A C TI VI TY- R ESUM Eindication, S-A C TI VITY-IN TER R UP Trequest,
S-ACTIVITY-INTERRUPTindication, S-ACTIVITY-INTERRUPTresponse,
S-A C TI VITY-IN TER RUPTcon firm, S-A CTI VITY- DlSCA R Drequest, S-ACT1 VITY- DlSCA RDindication,
S-ACTIVITY-DISCARDresponse, S-ACTIVITY-DISCARDconfirm, S-ACTIVITY-ENDrequest,
S- ACT1 VITY- ENDindication, S- ACT1 VITY- ENDresponse, S- ACT1 VITY- ENDcon firm,
S-RELEASErequest, S-REL EASEindication, S-RELEASEresponse, S-REL EASEconfirm,
S-U-ABORTrequest, S-U-ABORTindication, S- P-ABORTindication: -> SSPConstant
Even, Odd: Nat -> Bool
h: SSPConstant -> Nat
IsConstantReq, IsConstantlnd: SSPConstant -r Bool
- eq-, -ne-: SSPConstant, SSPConstant -> Bool
eqns forall c,cl:SSPConstant, n:Nat
ofsort Nat
h(S-CONNECTrequest) = O;
h(S-CONNECTindication) = Succ (h(S-CONNECTrequest));
h(S-CONNECTresponse) = Succ (h(S-CONNECTindication));
h(S-CONNECTcon firm) = Succ (h(S-CONNECTresponse));
h(S-DA TArequest) = Succ (h(S-CONNECTcon firm));
h(S-DA TAindication) = Succ (h(S- DATArequest));
h(S- EXPEDITED- DATArequest) = Succ (h(S-DATAindication));
h(S-EXPEDITED- DATAindication) = Succ (h(S-EXPEDITED-DATArequest));
h(S- TYPED- DATArequest) = Succ (h(S-EXPEDITED-DATAindication));
h(S-TYPED-DATAindication) = Succ (h(S-TYPED-DATArequest));
h(S-CAPABILITY-DATArequest) = Succ (h(S-TYPED-DATAindication));
h(S- CAPABIL I TY- DA TAindication) = Succ (h(S- CA PA BlL I TY- DA TA reques t)) ;
h(S-CAPABILITY- DATAresponse) = Succ (h(S-CAPABILITY-DATAindication));
h(S- CAPABIL ITY- DA TAcon firm) = Succ (h(S- CA PA BIL I TY- DA TAresponse)) ;
h(S-TOKEN-GIVErequest) = Succ (h(S-CAPABILITY- DATAconfirm));
h(S- TOKEN-GlVEindication) = Succ (h(S- TOKEN-GIVErequest));
h(S- TOKEN- PL EASErequest) = Succ (h(S- TOKEN-GIVEindication));
h(S- TOKEN- PL EASEindication) = Succ (h(S- TOKEN- PL EASErequest));
h(S-CONTROL-GIVErequest) = Succ (h(S- TOKEN-PL EASEindication));
h(S-CONTROL-GIVEindication) = Succ (h(S-CONTROL-GIVErequest));
h(S-SYNC-MINORrequest) = Succ (h(S-CONTROL-GlVEindication));
h(S-SYNC-MINORindication) = Succ (h(S-SYNC-MINORrequest));
h(S-SYNC-MINORresponse) = Succ (h(S-SYNC-MINORindication));
h(S-SYNC-MINORconfirm) = Succ (h(S-SYNC-MINORresponse));
h(S-SYNC-MAJORrequest) = Succ (h(S-SYNC-MINORconfirm));
h(S-SYNC-MAJORindication) = Succ (h(S-SYNC-MAJORrequest));
h(S-SYNC-MAJORresponse) = Succ (h(S-SYNC-MAJORindication));
h(S-SYNC-MAJORconfirm) = Succ (h(S-SYNC-MAJORresponse));
h(S-RESYNCHRONIZErequest) = Succ (h(S-SYNC-MAJORcon firm));
h(S-RESYNCHRONlZEindication) = Succ (h(S- RESYNCHRONlZErequest));
h(S-RESYNCHRONIZEresponse) = Succ (h(S- RESYNCHRONIZEindication));
h(S- RESYNCHRONlZEconfirm) = Succ (h(S-RESYNCHRONIZEresponse));
h(S-P-EXCEPTION- REPORTindication) = Succ (Succ (h(S-RESYNCHRONIZEconfirm)));
8
---------------------- Page: 12 ----------------------
ISO/IEC/TR 9571 : 1989 (E)
h(S-U-EXCEPTION-REPORTrequest) = Succ (h(S-P-EXCEPTION-REPORTindication));
h(S-U-EXCEPTION-REPORTindication) = Succ (h(S-U-EXCEPTION-REPORTrequest));
h(S-ACT1 VITY-S TAR Trequest) = Succ (h(S- U- EXCEPTION- REPOR Tindication));
h(S-A CTI VITY-STA R Tindication) = Succ (h(S- ACTIVITY-STAR Trequest));
h(S-ACTIVITY-RESUMErequest) = Succ (h(S-ACTIVITY-STARTindication));
h(S-ACTIVITY-RESUMEindication) = Succ (h(S-ACTIVITY-RESUMErequest));
h(S-ACTIVITY-INTERRUPTrequest) = Succ (h(S-ACTIVITY-RESUMEindication));
h(S-ACTIVITY-INTERRUPTindication) = Succ (h(S-ACTIVITY-INTERRUPTrequest));
h(S- ACT1 VITY-IN TER RUPTresponse) = Succ (h(S-ACTIVI TY-IN TER RUPTindication));
h(S-ACTIVITY-INTERRUPTconfirm) = Succ (h(S-ACTIVITY-INTERRUPTresponse));
h(S-ACTIVITY-DISCARDrequest) = Succ (h(S-ACTIVITY-INTERRUPTcon firm));
h(S-ACTIVITY-DlSCARDindication) = Succ (h(S-ACTIVITY-DISCARDrequest));
h(S-ACTIVITY- DISCARDresponse) = Succ (h(S-ACTIVITY- DISCARDindication));
h(S-ACTIVITY-DlSCARDcon firm) = Succ (h(S-ACTIVITY-DISCARDresponse));
h(S- AC TI VITY- EN Drequ est) = Succ (h(S-A C TI VI TY- DlSCAR Dcon firm)) ;
h(S-ACTIVITY- ENDindication) = Succ (h(S-ACTIVITY- ENDrequest));
h(S-AC TI VITY- ENDresponse) = Succ (h(S-AC TI VITY-ENDindication));
h(S-ACTIVITY-ENDconfirm) = Succ (h(S-ACTIVITY-ENDresponse));
h(S-REL EASErequest) = Succ (h(S-ACTIVITY-ENDconfirm));
h(S-REL EASEindication) = Succ (h(S-REL EASErequest));
0 h(S-RELEASEresponse) = Succ (h(S-RELEASEindication));
h(S-REL EASEconfirm) = Succ (h(S-RELEASEresponse));
h(S-U-ABORTrequest) = Succ (h(S-REL EASEconfirm));
h(S-U-ABORTindication) = Succ (h(S-U-ABORTrequest));
h(S- P-ABORTindication) = Succ (Succ (h(S-U-ABORTindication)));
ofsori Boo1
Even (Succ (O)) = false; Even (Succ (Succ (n))) = Even (n);
Even (O) = true;
IsConstantReq (c) = Eve
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.