ISO/IEC 8886:1992

Information technology — Telecommunications and information exchange between systems — Data link service definition for Open Systems Interconnection

Traitement de l'information — Télécommunications et échange d'informations entre systèmes — Définition du service de liaison de données pour l'interconnexion de systèmes ouverts

General Information

• Status: Withdrawn
• Publication Date: 10-Jun-1992
• Withdrawal Date: 10-Jun-1992
• ICS: 35.100.20 - Data link layer
• Technical Committee: ISO/IEC JTC 1/SC 6 - Telecommunications and information exchange between systems
• Drafting Committee: ISO/IEC JTC 1/SC 6/WG 1 - Physical and data link layers
• Current Stage: 9599 - Withdrawal of International Standard
• Start Date: 05-Sep-1996
• Completion Date: 12-Feb-2026

Relations

• Revised: ISO/IEC 8886:1996 - Information technology — Open Systems Interconnection — Data link service definition
• Effective Date: 15-Apr-2008

Standards Content (Sample)

ISO/IEC
I NTE R NAT1 O NA L
STAN DAR D
First edition
1992-06-1 5
Information technology - Telecommunications
and information exchange between systems -
üata link service definition for Open Systems
Interconnection
Traitement de l'information - Télécommunications et échange
d'informations enfre systèmes - Définition du service de liaison de
données pour l'interconnexion de systèmes ouverts
-___
Reference number
ISOllEC 8886:1992(E)
Contents
Section 1 - General
vi
O Introduction
1 1
Scope
2 Normative references 1
3 Definitions 2
O
3.1 Basic Reference Model definitions 2
3.2 Service conventions definitions 2
3.3 Reference Model connectionless-mode data transmission definitions 2
4 Abbreviations 2
5 Convent ions 3
5.1 General conventions
5.2 Parameters 3
Overview of the Data Link Service 3
7 Classes and types of Data Link Service 4
Section 2 - Definition of connection-mode service 4
Features of the connection-mode Data Link Service 4
9 Model of the connection-mode Data Link Service 5
9.1 DLC endpoint connection identification 5
9.2 Model of a Data-link-connection
9.2.1 Queue model concepts
9.2.2 DLC establishment
9.2.3 Data transfer
9.2.4 Reset
9.2.5 DLC release
O ISOllEC 1992
All rights reserved. No part of this publication may be reproduced or utiii?ed in any foirn
or by any nieans, electronic or mechanical, iiiciudinq photocopying and microfilni, wittioiit
permission in writing horn the publisher.
ISOllEC Copyright Office Case Postale 56 CH-I211 Genéve 70 Switzerland
Printed in Switzerland
ii
ISWIEC 8886:1992(E)
1 O Quality of connection-mode service
10.1 Determination of QûS for connection-mode service 9
10.2 Definition of QûS parameter 10
10.2.1 Throughput 10
10.2.2 Transit delay 11
10.2.3 Residual error rate 11
1 O. 2.4 Resilience 12
10.2.5 Protection 12
10.2.6 Priority 12
11 Sequence of primitives
1 1.1 Concepts used to define the connection-mode Data Link Service
1 1.2 Constraints on sequence of primitives
1 1.2.1 Relation of primitives at the two DLC endpoints
1 1.2.2 Sequence of primitives at one DLC endpoint
12 Connection establishment phase
12.1 Function 17
12.2 Types of primitives and parameters 17
12.2.1 Addresses 18
12.2.2 Called address 18
12.2.3 Calling address 18
12.2.4 Responding address 18
12.2.5 Quality of Service parameter set 18
12.3 Sequence of primitives
13 Connection release phase 19
13.1 Function 19
13.2 Types of primitives and parameters 19
13.2.1 Originator 20
13.2.2 Reason 20
13.3 Sequence of primitives when releasing an established DLC 20
13.4 Sequence of primitives in a DLS user rejection of DLC establishment attempt 21
13.5 Sequence of primitives in a DLS provider rejection of DLC establishment
attempt
13.6 Sequence of primitives in a DLS user abort of a DLC establishment attempt 22
14 Data transfer phase 23
14.1 Data transfer 23
14.1.1 Function 23
14.1.2 Types of primitives and parameter 23
14.1.3 Sequence of primitives 24
iii
ISOllEC 8886:1992(E)
14.2 Reset service 24
14.2.1 Function 24
14.2.2 Types of primitives and parameters 24
14.2.3 Sequence of primitives 25
Section 3 - Definition of connectionless-mode service
Features of the connectionless-mode primitives 27
Model of the connectionless-mode data link service 27
16.1 Model of a Data-link-connectionless-m& data transmission
17 Quality of connectionless-mode service 29
17.1 Determination of QOS for connectionless-mode service
17.2 Definition of connectionless-mode QOS parameters 29
17.2.1 Transit delay 30
17.2.2 Residual error rate 30
17.2.3 Protection 31
17.2.4 Priority 31
Sequence of connectionless-mode primitives at one DLSAP.
18 31
19 Data transfer 32
19.1 Function
19.2 Types of primitives and parameters
19.2.1 Addresses
19.2.2 Quality of service
19.2.3 DLS user-data
19.3 Sequence of primitives
Annex A
ISOllEC 88861 992(E)
Foreword
IS0 (the International Organization for Standardization) and IEC (the
International Electrotechnical Commission) form the specialised system
for worldwide standardization. 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 com-
mittees collaborate in fields of mutual interest. Other international or-
ganizations, governmental and non-governmental, in liaison with IS0
and IEC, also take part in the work.
IÇO and IEC have established a
In the field of information technology,
joint technical committee, ISOIIEC JTC 1. Draft International Standards
adopted by the joint technical committee are circulated to national bod-
ies for voting. Publication as an International Standard requires ap-
proval by at least 75 Oh of the national bodies casting a vote.
International Standard ISO/IEC 8886 was prepared by Joint Technical
Committee ISO/IEC JTC 1, lnformation technology.
Annex A of this International Standard is for information only.
V
ISOliEC 8886:1992(E)
Introduction
This International Standard is one of a set of International Standards produced to facilitate the
interconnection of information processing systems. It is related to other standards in the set as
defined by IS0 7498. The Reference Model (IS0 7498) subdivides the area of standardization
for Open Systems Interconnection(OS1) into a series of layers of specification, each of a
manageable size.
Standard defines the service provided by the Data Link Layer to the Network
between the Data Link and Network Layers of the OS1 Basic Reference
Model. It provides for the designers of network protocols a definition of the Data Link Service
@LS) existing to support the network protocol and for designers of Data Link Protocols a
defiriition of the services to be made available through the action of the Data Link Protocol over the
underlying service. The relationship is shown in figure 1.
- uses Data Link
Network L
Protocol
Service
Data Link Service
Data Link -
Protocol
- provides Data Link
Service
Figure 1 - Relationship of this International Standard to other OS1 Standards
Throughout the set of OS1 standards, the term “service” refers to the abstract capability provided
by one layer of the OS1 Basic Reference Model to the layer immediately above. Thus, the Data
Link Service defined in this document is a conceptual architectural service, in-dependent of
administrative divisions.
vi
INTERNATIONAL STANDARD ISOllEC 8886:1992(E)
Information technology - Telecommunications and
information exchange between systems - Data link service
definition for Open Systems Interconnection
Section 1 : General
1 Scope
This International Standard defines the OS1 Data Link Service in terms of
a) the primitive actions and events of the service;
b) the parameters associated with each primitive action and event, and the form which they
take; and
c) the inter-relationship between, and the valid sequences of, these actions and events.
The principle objective of this International Standard is to specify the characteristics of a
conceptual Data Link Service and thus, supplement the Basic Reference Model in guiding the
development of Data Link protocols.
This International Standard does not specify individual implementation or products, nor does it
constrain the implementation of Data Link entities and interfaces within an information processing
system.
There is no conformance of equipment to this Data Link Service Definition Standard. Instead,
conformance is achieved through implementation of conforming Data Link Protocols that fulfill the
Data Link Service defined in this International Standard.
2 Normative references
The following standards contain provisions which, through reference in this text, constitute
provisions of this International Standard.
At the time of publication, the editions indicated were valid. All standards are subject to revision,
and parties to agreements based on this International Standard are encouraged to investigate the
possibility of applying the most recent editions of the standards listed below. Members of EC and
IS0 maintain registers of currently valid International Standards.
IS0 7498: 1984, Information processing systems - Open Systems Interconnection - Basic
Reference Model (see also CCIïT Recommendation X.200).
IS0 7498JAdd.l: 1984, Information processing systems - Open Systems Interconnection - Basic
Reference Model - Addendum I Connectionless-rnode data transmission.
ISOfïR 8509: 1987, Information processing systems - Open Systems Interconnection - Service
Conventions (see also CCITT Recommendation X.210).
3 Definitions
3.1 Basic Reference Model definitions
This International Standard is based on the concepts developed in IS0 7498 and makes use of the
following terms defined in it:
a) Data link entity
b) DataLinkLayer
c) Data Link Service
d) Data-link-service-access-point
e) Data-link-service-access-point-address
f) Data-link-service-dunit
g) Reset
3.2 Service conventions definitions
This International Standard makes use of the following terms defined in ISO/TR 8509, as they
e
apply to the Data Link Layer:
a) Data Link Service User
b) Data Link Service Provider
c) Pnmitive
d) Request
e) Indication
f) Response
g) Confrm
3.3 Data Link Service definitions
This International Standard makes use of the following terms defined in IS0 7498 and
IS07498/Add. 1 , as they apply to the Data Link Layer:
a) Data-link-connection
b) Data-link-connection-mode data transmission
c) Data-link-connectionless-mode data transmission
O
4 Abbreviations
DL Data Link
DLC Data-link-connection
DU DataLinkLayer
DU Data Link Service
DLSAP Data-link-service-access-point
DLSDU Data-link-service-data-u~t
OS1 Open Systems Interconnection
QOS Quality of Service
ISOItEC 88861 992(E)
5 Conventions
5.1 General conventions
This International Standard uses the descriptive conventions given in ISO/TR 8509.
The service model, service primitives, and time-sequence diagrams used are entirely abstract
descriptions; they do not represent a specification for implementation.
5.2 Parameters
Service primitives, used to represent service user/service provider interactions (1SOlï.R 8509),
convey parameters which indicate information available in the user/provider interaction.
The parameters which apply to each group of Data Link Service primitives are set out in tables in
clauses 12 to 14 and 19. Each “X’ in the tables indicates that the primitive labelling the column in
which it fails may carry the parameter labelling the row in which it fails.
Some entries are further qualified by items in brackets. These may be
a) A Parameter specific constraint:
(=) indicates that the value supplied in an indication or confirm primitive is always
identical to that supplied in a previous request or response primitive issued at the peer
service-access-point.
b) Indication that some note applies to the entry:
(see note X) indicates that the referenced note contains additional information pertaining
to the parameter and its use.
In any particular interface, not all parameters need be explicitly stated. Some may be implicitly
associated with the DLSAP at which the primitive is issued.
6 Overview of the Data Link Service
The DLS provides for the transparent and reliable transfer of data between DLS users. It makes
invisible to these DLS users the way in which supporting communications resources are utilized to
achieve this transfer.
In particular, the DLS provides for the following:
a) Independence of underlying Physical Layer - the DLS relieves DLS users from all concerns
regarding which configuration is available (e.g., point-to-point connection) or which
physical facilities are used (e.g., half-dulpex transmission).
b) Transparency of transferred information - the DLS provides for the transparent transfer of
DLS user-data. It does not resmct the content, format or coding of the information, nor
does it ever need to interpret its structure or meaning.
- the DLS relieves the DLS user from loss, insertion, corruption
c) Reliable transfer of data
or, if requested, misordering of data which may occur. In some cases of unrecoverable
errors in the Data Link Layer, duplication or loss of DLSDUs may occur.
ISOllEC 88861992(E)
Note - Detection of duplicate or lost DLSDUs may be performed by DU users.
d) Quality of Service (QOS) selection - the DLS makes available to DLS users a means to
request and to agree upon a quality of service for the transfer of data. QOS is specified by
means of QûS parameters representing characteristics such as; throughput, transit delay,
accuracy and reliability,
e) Addressing.- The DLS allows the DLS user to identify itself and to specify the DLSAP to
which a DLC is to be established whenever more than two DLSAPs are supported by the
DLS provider. Data link addresses have only local significance within a specific data link
configuration over a single transmission medium (point-to-point or multi-point physical
connection) or a group of parallel transmission media (multi-link or splitting function).
Therefore, it is not appropriate to defme a global addressing structure.
Note - The DLS is required to differentiate between the individual systems that are physically or logically
connected to a multi-point data link and to differentiate between connections when the Data Link Layer
includes a multiplexing function. For commonality with other service definitions, this mechanism is
referred to as addressing and the objects used to differentiate between systems are referred to as addresses.
7 Classes and types of Data Link Service
There are no distinct classes of Data Link Service defined.
There are two types of DLS:
a) a connection-mode service (defined in section 2), and
b) a connectionless-mode service (defined in section 3).
When making reference to this International Standard, a user or provider of Data Link Service shall
state which types of service it expects to use or provide.
Section 2 : Definition connection-mode service
Features of the connection-mode Data Link Service
The DLS provides the following features to the DLS user:
a) The means to establish a DLC with another DLS user for the purpose of exchanging
DLSDUs.
b) The establishment of an agreement between the initiating DLS user and the DLS provider
for a certain Quality of Service (QOS) associated with each DLC.
c) The means of transferring DLSDUs of restricted length on a DLC. The transfer of
DLSDUs is transparent, in that the boundaries of DLSDUs and the content of DLSDUs are
preserved unchanged by the DLS, and there are no constraints on the DLSDU content
imposed by the DLS.
Note - The length of a DLSDU may be limited because of internal mechanisms employed by the Data
Link Protocol (see sub-clause 7.6.3.2 of IS0 7498).
d) The means by which the receiving DLS user may flow control the rate at which the sending
DLS user may send DLSDUs.
e) The means by which a DLC can be returned to a defined state and the activities of the two
DLS users synchronized by use of a Reset service element.
f) The unconditional, and therefore possibly destructive, release of a DLC by either of the
DLS users or by the DLS provider.
9 Model of the connection-mode Data Link Service
This International Standard uses the abstract model for a layer service defined in clause 4 of
ISODR 8509. The model defines the interactions between the DLS users and the DLS provider
which take place at the two DLSAPs. Information is passed between the DLS user and the DLS
by service primitives, which may convey parameters.
provider
9.1 DLC endpoint connection identification
If a DLS user needs to distinguish among several DLCs at the same DLSAP, then a local
connection endpoint identification mechanism shall be provided. All primitives issued at such a
DLSAP within the context of a DLC would be required to use this mechanism to identify this DLC.
an implicit identification is not described in this international Standard.
Such
9.2 Model of a Data-link-connection
Between the two endpoints of a DLC, there exists a flow control function that relates the behaviour
of the DLS user receiving data to the ability of the other DLS user to send data. As a means of
specifying this flow control feature and its relationship with other capabilities provided by the
connection-mode DLS, the queue model of a DLC, which is described in the following clauses, is
used.
This queue model of a DLC is discussed only to aid in the understanding of the end-to-end service
features perceived by DLS users. It is not intended to serve as a substitute for a precise, formal
description of the DLS, nor as a complete specification of all allowable sequences of DLS
also the note below.) In
primitives. (Allowable primitive sequences are specified in clause 11, see
addition, this model does not attempt to describe all the functions or operations of DL entitles that
used to provide the DLS. No attempt to specify or constrain DLS implementations is implied
are
Note - The internal mechanisms which support the operation of the DLS are not visible to the DLS user. In
addition to the interactions between service primitives described by this model (e.g., the issue of a DL-RESET
request primitive at a DLSAP may prevent the receipt of a DL-DATA indication primitive, corresponding to a
previously issued DL-DATA request primitive, by the peer DLS user) there may also be:
a) constraints applied locally on the ability to invoke primitives;
b) service procedures defining particular sequencing constraints on some primitives.
I SO/ I EC 8886 1 992( E)
9.2.1 Queue model concepts
The queue model represents the operation of a DLC in the abstract by a pair of queues linking the
two DLSAPs. There is one queue for each direction of information flow (see figure 2).
DLS User E?
DLS User A
I
I
0 I
0 I
I I
I I
Queue from A to E?
Queue from E? to A
Figure 2 - Queue Model of a DLC
Each queue represents a flow control function in one direction of transfer. The ability of a DLS
user to add objects to a queue will be determined by the behaviour of the other DLS user in
removing objects from the queue and the state of the queue. Objects are entered or removed from
the queue as a result of interactions at the two DLSAPs.
The pair of queues is considered to be available for each potential DLC.
The following objects may be placed in a queue by a DLS user (see clauses 12 to 14):
a) a connect object, representing a DL-CONNECT primitive and its parameters;
b) a data object, representing a DL-DATA primitive and its parameters;
c) a reset object, representing a DL-RESET primitive and its parameters; and
d) a disconnect object, representing a DL-DISCONNECT primitive and its parameters.
The following objects may be placed in a queue by the DLS-provider (see clauses 12 to 14):
1) a reset object, representing a DL-RESET primitive and its parameters;
2) a synchronization mark object (see 9.2.4); and
3) a disconnect object, representing a DL-DISCONNECT primitive and its parameter.
are defined to have the following general properties:
The queues
i) a queue is empty before a connect object has been entered and can be returned to this state,
with loss of its contents, by the DLS provider;
ii) objects are entered into a queue by the sending DLS user, subject to control by the DLS
provider. Objects may also be entered by the DLS provider;
iii) objects are removed from the queue, under the control of the receiving DLS user;
iv) objects are normally removed in the same order that they were entered (however, see
9.2.3); and
v) a queue has a limited capacity, but this capacity is not necessarily either fixed or
determinable.
9.2.2 DLC establishment
A pair of queues is associated with a DLC between two DLSAPs when the DLS provider receives
a DL-CONNECT request primitive at one of the DLSAPs, and a connect object is entered into one
From the standpoint of the DLS users of the DLC, the queues remain associated
of the queues.
with the DLC until a disconnect object representing a DL-DISCONNECT primitive is either entered
or removed from the queue.
DLS user A, who initiates a DLC establishment by entering a connect object representing a DL-
CONNECT request primitive into the queue from DLS user A to DLS user B, is not allowed to
enter any other object, other than a disconnect object, into the queue until after the connect object
representing the DL-CONNECT confirm primitive has been removed from the DLS user B to DLS
user A queue. In the queue from DLS user B to DLS user A, objects can be entered only after
DLS user B has entered a connect object representing a DL-CONNECT response primitive.
The properties exhibited by the queues while the DLC exists represent the agreements reached
among the DLS users and the DLS provider during this connection establishment procedure
concerning QOS.
9.2.3 Data transfer
Flow control on the DLC is represented in this queue model by the management of the queue
capacity, allowing objects to be added to the queues. The addition of a object may prevent the
a further object.
addition of
Once objects are in the queue, the DLS provider may manipulate pairs of adjacent objects, resulting
in deletion. An object may be deleted if, and only if, the object which follows it is defined to be
destructive with respect to the object. If necessary, the last object on the queue will be deleted to
allow a destructive object to be entered - they may therefore always be added to the queue.
Disconnect objects are defined to be destructive with respect to all other objects. Reset objects are
defined to be destructive with respect to all other objects except connect and disconnect objects.
The relationships between objects which may be manipulated in the above fashion are summarized
1.
in table
Whether the DLS provider performs actions resulting in deletion or not will depend upon the
QOS for DLC. In general, if a DLS user does not
behaviour of the DLC users and the agreed
remove objects from a queue, the DLS provider shall, after some unspecified period of time,
perform all the permitted deletions.
ISOllEC 88861992(E)
Table 1 - Relationships between Oueue Model ob-iects
The following
Synchron-
object Y Is
\ respect to defined
Discon-
Reset ization
Connect Data
Mark nect
the preceding
obiect X.
NIA DES
N/A
Connect
NIA DES
DES
N/A
Data
DES
DES
NIA
Reset
Synchroniurtlon
DES NIA DES
NIA
mark
~~
DES
NIA NIA NIA
NIA
Disconnect
NIA : X will not precede Y in a valid state of a queue
Key :
- : not to be destructive nor to be able to advance ahead
DES : to be destructive to the preceding object
9.2.4 Reset
In order to accurately model the reset service a synchronization mark object is required. The
synchronization mark object exhibits the following properties:
a) It cannot be removed from a queue by a DLS-user;
b) A queue appears empty to a DLS-user when a synchronization mark object is the next
object in the queue;
c) A synchronization mark can be destroyed by a Disconnect object (see table 1).
d) When a Reset object is immediately preceded by a synchronization mark object, both the
Reset object and the synchronization mark object are deleted from the queue.
The initiation of a reset procedure is represented in the two queues as follows:
i) initiation of a reset procedure by the DLS provider is represented by the introduction into
each queue of a reset object followed by a synchronization mark object;
ii) a reset procedure initiated by a DLS user is represented by the addition, by the DLS
provider, of a reset object into the queue from the Reset initiator to the peer DLS user and
the insertion of a reset object followed by a synchronization mark object into the other
queue.
ISO/I€C 8886:1992(E)
Unless destroyed by a disconnect object, a synchronization mark object remains in the queue until
the next object following it in the queue is a reset object. Both the synchronization mark object and
the following reset object are then deleted by the DLS provider.
Note - Associated with the initiation of a reset procedure are restrictions on the issuance of certain other types of
primitives. These restrictions will result in restrictions on the entry of certain object types into the queue until the
reset procedure is completed (see 14.2.3).
9.2.5 DLC release
The insertion into a queue of a disconnect object, which may occur at any time, represents the
initiation of a DLC release procedure. The release procedure may be destructive with respect to
other objects in the two queues and eventually results in the emptying of the queues and the
disassociation of the queues with the DLC.
The insertion of a disconnect object may -also represent the rejection of a DLC establishment
attempt or the failure to complete DLC establishment. In such cases, if a connect object
representing a DL-CONNECT request primitive is deleted by a disconnect object, then the
disconnect object is also deleted. The disconnect object is not deleted when it deletes any other
object, including the case where it deletes a connect object representing a DL-CONNECT
response.
10 Quality of connection-mode Data Link Service
The term “Quality of Service” (QOS) refers to certain characteristics of a DLC as observed between
the connection end-points. QOS describes aspects of a DLC which are attributable solely to the
DLS provider.
Once a DLC is established, the DLS users at the two ends have the same knowledge and
QOS over the DLC is.
understanding of what the
1 O. 1 Determination of QOS for connection-mode service
QOS is described in terms of QOS parameters. These parameters give DLS users a method of
specifying their needs, and give the DLS provider a basis for protocol selection.
The QOS parameters can be divided into the following two types, based upon the way in which
their values are determined:
a) those QOS parameters which may be selected on a per-connection basis during the
establishment phase of a DLC.
b) those QOS parameters which are not selected during DLC establishment but whose values are
known by other methods.
There are three QOS parameters, through put, protection and priority (as defined in 10.2.1, 10.2.5
and 10.2.6 respectively), which are of the type actually selected during DLC establishment. The
selection procedures for these parameters are described in detail in 12.2.5. Once the DLC is
established, throughout the lifetime of the DLC, the agreed QOS values are not reselected at any
point in time and their is no guarantee that the original values will be maintained. The DLS users
should also be aware that changes in QOS on a DLC are not explicitly signalled by the DLS
provider.
ISOllEC 88861992(E)
The remaining QOS characteristics that are identified as parameters, but for which there is no
selection during DLC establishment, are defined in 10.2.2 through 10.2.4 respectively. The
values of these parameters for a particular DLC are determined by other methods such as, a priori
knowledge and agreement.
If selection is allowed, certain measures of QOS are requested by the sending DLS user when the
DL-CON primitive action is initiated. The requested measures (or parameter value and options) are
based on a priori knowledge by the DLS user of the service(s) available to it by the DLS provider.
Knowledge of the characteristics and type of service provided (i.e., the parameter, formats, and
options that effect the transfer of data) is made available to a DLS user through some layer
management interaction prior to (any) invocation of the DL connection-mode service. Thus, the
of the service it can expect to be provided
DLS user has explicit knowledge of the characteristics
with for each invocation of the service.
The DLS provider may also provide information on the current QOS independently of access to the
service by a DLS user. This seemingly dynamic aspect of QOS determination is not a negotiation
but provided with knowledge of the characteristics of the service currently outside of any instance
of the invocation of the service.
1 O. 2 Definition of connection-mode QOS parameters
QûS parameters can be classified as:
a) parameters that express DLS performance, as shown in table 2.
~ RI
r A A
SPEED
Throughput Residual Error Rate
Transit Delay (corruption, duplication / loss)
Resilience
b) parameters that express other DLS characteristics, as shown in table 3.
Table 3 - performance
Protection
Note - Some QOS parameters are defined in terms of the issuance of DLS primitives. Reference to a DLS
primitive refers to the complete execution of that DLS primitive at the appropriate DLSAP.
10.2.1 Throughput
Throughput is defined as the total number of DLSDU bits successfully transferred by a DL-DATA
request/DL-DATA indication primitive sequence divided by the inpudoutput time for that sequence.
ISOllEC 8886:1992(E)
Successful transfer of the bits in a transmitted DLSDU is defined to occur when the bits are
delivered to the intended receiving DLS user without error, in the proper sequence, prior to release
by the receiving DLS user.
of the DLC
The input/output time for a DL-DATA request/DL-DATA indication primitive sequence is the
greater of the two times in the following list.
a) The time between the first and the last DLDATA request in the sequence.
b) The time between the first and the last DL-DATA indication in the sequence.
Throughput is only meaningful for a sequence of complete DLSDUs.
Throughput is specified independently for each direction of transfer. In general, each throughput
specification will define both the desired target value and the minimum acceptable value (or lowest
acceptable QOS) for a DLC. Each specification is an average rate and will be based on a
previously stated average DLSDU size.
Either the input or the output of a sequence of DLSDUs may be delayed excessively by the DLS
users. Occurrences of delay caused by the DLS users are excluded in calculating average
throughput values.
1 O. 2.2 Transit delay
Transit delay is the elapsed time between DL-DATA request primitives and the corresponding DL-
DATA indication primitives. Elapsed time values are calculated only on DLSDUs that are
successfully transferred.
Successful transfer of a DLSDU for the purposes of the QûS parameters, is defined to occur when
the DLSDU is transferred from the sending DLS user to the intended receiving DLS user without
error, and in the proper sequence prior to release of the DLC by the receiving DLS user.
For connection-mode transfer, transit delay is specified independently for each direction of
transfer. Each specification will be based on a previously stated average DLSDU size.
The transit delay for an individual DLSDU may be increased if the receiving DLS user exercises
interface flow control. Such occurrences are excluded in calculating transit delay values.
10.2.3 Residual Error Rate
Residual error rate is the ratio of total incorrect, lost and duplicate DLSDUs to total DLSDUs
transferred across the DLS boundary during a measurement period. The relationship among these
quantities is defined, for particular DLS user pair, as shown in figure 3.
ISOllEC 8886:1992(E)
DLSDUs received
DLSDUs
sent
I
I
t I
(-**-*----------*---*~
Ic--- Total DLSDUs transferred 6 DL +
DL(I)+ DL(e) + DL(x)
RER=
DL
Figure 3 - Components of Residual Error Rate
1 O. 2.4 Resilience
This parameter specifies the probability of
a) a DLS provider initiated DLC release (i.e. the issuance of a DL-DISCONNECT indication
primitive with no prior DL-DISCONNECT request primitive); or
b) a DLS provider initiated reset (Le., the issuance of a DL-RESET indication primitive with
no prior DL-RESET request primitive);
during a specified time interval on an established DLC.
10.2.5 Protection
Protection is the extent to which a DLS provider attempts to prevent unauthorized monitoring or
manipulation of DLS user originated information. Protection is specified by a minimum and
maximum protection option within a range of three possible protection options:
a) no protection features;
b) protection against passive monitoring; and
c) protection against modification, replay, addition or deletion.
Within the specified range, a DLS user selects a particular value during DLC establishment.
Each protection feature addresses a particular type of privacy or security threat, and each is
typicaily provided by a different DLS provider mechanism.
1 O. 2.6 Priority
e specification of priority is concerned with the relationship between DLCs.
is parameter specifies the relative importance of a DLC with respect to

ISOllEC 88861992(E)
a) the order in which DLCs are to have their QOS degraded, if necessary; and
b) the order in which DLCs are to be released to recover resources, if necessary.
Priority is specified by a minimum and a maximum within a given range. Within the specified
range, a DLS user selects a particular value during DLC establishment.
This parameter only has meaning in the context of some management entity or structure able to
judge relative importance. The number of priority levels is limited.
11 Sequence of primitives
11.1 Concepts used to define the connection-mode Data Link Service
The service definition uses the following concepts:
a) DLC that can be dynamically established or terminated between the DLS users for the
purpose of exchanging data.
b) associated with each DLC, certain measures of QOS that are agreed between the DLS
provider and the DLS users when the DLC is established.
c) the DLC allows transmission of data and preserves its division into DLSDUs; the
transmission of this data is subject to flow control.
d) the DLC can be returned to a defined state, and the activities of the two DLS users
synchronized by the use of a Reset Service.
e) failure to provide the requested service may be signalled to the DLS user. There are three
classes of failure:
1) failures involving termination of the DLC;
2) failures involving loss or duplication of user data, but without loss of DLC; and
3) failures to provide the requested QOS without loss or duplication of user data or loss of
the DLC.
11.2 Constraints on sequence of primitives
This subclause defines the constraints on the sequence in which the primitives defined in clauses
12 to 14 may occur. The constraints determine the order in which primitives occur, but do not
fully specify when they may occur. Other constraints, such as flow control of data, will affect the
ability of a DLS user or a DLS provider to issue a primitive at any particular time.
The connection-mode primitives and their parameters are summarized in table 4.
ISOllEC 88861 992(E)
Table 4 - Summary of data-link-connection-mode primitives and parameters
_- ~
Service Primitive Parameters
Phase
-
~
DL-CONNECT request (Called address, calling
DLC >LC
:stablishment address, parameter set)
establishment
(Called address, calling
DL-CONNECT indication
address, parameter set)
DL-CONNECT response (Responding address, QOS
parameter set)
(Responding address, QOS
DL-CONNECT confirm
parameter set)
DLDATA request (DLS user-data)
lata Transfer gomal Data
ransfer
DLDATA indication (DLS user-data)
teset DL-RESET request (Reason)
(Originator, reason)
DL-RESET indication
DL-RESET response
DLRESET confm
ILC release DL-DISCONNECT request (Reason)
DLC release
DLDISCONNECT indication (Originator, reason)
Relation of primitives at the two DLC endpoints
11.2.1
A primitive issued at one DLC endpoint will, in general, have consequences at the other DLC
endpoint. The relations of primitives of each type at one DLC endpoint to primitives at the other
DLC endpoint are defined in the appropriate subclause in clauses 12 to 15; all these relations are
summarized in the diagrams in figure 4.
However, a DL-DISCONNECT request or indication primitive may terminate any of the other
sequences before completion.
ISOllEC 88861992(E)
a) Successful DLC
b) DLC establishment
c) DLS User Invoked
Establishment
collision
DLC Release
DL-CONNECT
request DL-CONNECT DL-CONNECT
DL-CONNECT DL-DISCONNECT
indication request
DL-DISCONNECT
indication
DL-CONNECT DL-CONNECT
confirm
confirm
d) Simultaneous DLS User
DLS Provider invoked
e)
9 Simuitaneous DLS User and DLS
Invoked DLC Release DLC Release Provider invoked DLC Release
DL-DISCONNECT DL-DISCONNECT DL-DISCONNECT DL-DISCONNECT
request jyrequest
1-1 ~ request 44 indicatE
DL-DISCONNECT DL-DISCONNECT
indication indication
g) DLS User rejection of a
h) DLS Provider rejection of a
I) Normal
DLC establishment attempt
DLC establlshment attempt
data transfer
DL-CONNECT DL-CONNECT
request
request
DL-DATA
indication
indication
-
j) DLS User invoked
k) Simultaneous DLS User
I) DLS Provider Invoked
Reset invoked Reset Reset
-Rc rIest DL-RESET ITue; DL-RESET iwtion DL-RESET r[dicatE DL-RESET
request
indication
DL-RESET
DL- ESET
response -%
confirm DL-RESET DL-RESET DL-RESET
DL-RESET
confirm confirm response response
m) Simultaneous DLS User and
DLS Provider Invoked Reset
DL-RESET DL-RESET
request indication
DL-RESET
confirm response
Figure
4 - Summary of Data-link-connection-mode service primitive time-
sequence diagrams
ISOllEC 8886:1992(E)
11.2.2 Sequence of primitives at one DLC endpoint
The possible overall sequences of primitives at a DLC endpoint are defined in the state transition
5. In the diagram
diagram, figure
request
DL-RESET
confirm
DL-RESET ?ESET
D ~ L-RES ET
indication I na cat ion
request request
U
A A
1 DL-DATA request or indication'
i request or indication'
Figure 5 - State transition diagram for sequences of Data-link-connection-
mode service primitives at a DLC end-point
ISO/IEC 88861 992(E)
a) The labelling of the states “DLS user initiated reset pending” (5) and “DLS provider
initiated reset pending” (6) indicate the party that started the local interaction, and dues not
necessarily reflect the value of the originator parameter.
b) The “idle state” (1) reflects the absence of a DLC. It is the initial and final state of any
sequence, and once it has been re-entered, the DLC is released.
c) The use of a state transition diagram to describe the allowable sequences of service
primitives does not impose any requirements or constraints on the internal organization of
any implementations of the service.
Table 5 - DLC establishment and parameters
Primitive
Parameter DL-CONNECT DL-CONNECT DL-CONNECT DL-CONNECT
request indica tion response confm
Called address
X X(=)
(see note 2)
Calling address
X X(=)
(see note 2)
>
Responding address
X X(=)
(see notes 1,2)
Quality of service
parameter set X X X X
Notes
ISOlIEC 88861992(E)
12.2.1 Addresses
The parameters which take addresses as values (see 12.2.2 to 12.2.4) all refer to DLSAP-
addresses.
Note - If the configuration allows any of these addresses to be known by the DL Entity on an a-priori basis, then
these DLSAP address(es) need not be explicitly conveyed in the protocol.
12.2.2 Called address
The called address parameter conveys an address identifying the DLSAP to which the DLC is to be
established.
12.2.3 Calling address
The calling address parameter conveys the address of the DLSAP from which the DLC has been
requested.
12.2.4 Responding address
The responding address parameter conveys the address of the DLSAP to which the DLC has been
established.
Quality of Service parameter set
12.2.5
The use of the QOS parameters selection is not required when only one level of QOS is offered by
the DLS provider.
12.2.5.1 Throughput
Two QOS sub-parameters “target” and “lowest quality acceptable”, which are in the agreed range,
are passed to the DLS provider in the DL-CONNECT request primitive. The DLS provider will
indicate to the DLS users, the “available” throughput in the DL-CONNECT confirm, and DL-
CONNECT indication. The “available” parameter shall be a value from the range between the
“target” and the “lowest quality acceptable” (see 10.2.1).
12.2.5.2 Selected protection
The parameter specifies a particular degree of protection, within the agreed range (see 10.2.5), for
the DLSDU of any subsequently submitted DL-DATA request primitive transferred on the DLC.
12.2.5.3 Selected priority
The parameter specifies a particular priority, within the agreed range (see 10.2.6), for the DLSDU
of any subsequent DL-DATA request primitive transferred on the DLC.
12.3 Sequence of primitives
The sequence of primitives in a successful DLC establishment is defined by the time-sequence
in figure 6.
diagram
ISOllEC 88861992(E)
DL-CONNECT
request
D DL-CO N N ECT DL-CONNECT
DL-CONNECT
indication
DL-CONNECT
response DL-CONNECT
I confirm confirm
DL-CONNECT
confirm
b) Initiated simultaneously by both DLS
users
a) Initiated by a single DLS user
Figure 6 - DLC establishment
These DLC establishment procedures may fail either due to the inability of the DLS provider to
establish a DLC or due to the unwillingness of the called DLS user to accept a DL-CONNECT
indication primitive (for these cases, see DLC release service, clauses 13.4 and 14.5).
13 Connection release phase
13.1 Function
The DLC release service primitives are used to release a DLC. The release may be initiated by any
of the following:
a) either or both of the DLS users, to release an established DLC;
b) the DLS provider to release an established DLC; all failures to maintain a DLC are indicated
in this way;
c) the DLS user, to reject a DL-CONNECT indication;
d) the DLS provider, to indicate its inability to establish a requested DLC; or
e) the DLS user which sent the DL-CONNECT request, to abandon the DLC establishment
attempt before the DLC has been made available for use by receipt of a DL-CONNECT
confirm primitive.
Initiation of the release service element is permitted at any time regardless of the current phase of
the DLC. Once a release service has been initiated, the DLC will be disconnected. A DL-
DISCONNECT request cannot be rejected. The DLS does not guarantee delivery of any DLSDU
associated with the DLC once the release phase is entered.
13.2 Types of primitives and parameters
Table 6 indicates the types of primitives and the parameters needed for DLC release.
ISOllEC 8886:1992(E)
Primitive
-P
Parameters request indication
ûriginator X
Reason X
The originator parameter indicates the source of the release. Its value indicates either the DLS user,
the DLS provider, or that the originator is unknown.
13.2.2 Reason
The reason parameter gives information about the cause of the release. The value conveyed in this
as follows:
parameter will be
a) when the originator parameter indicates a DLS provider generated release, the value is one of:
1) “disconnection-permanent condition”;
2) “disconnection-transient condition”;
3) “connection rejection-DLS AP address unknown”;
...