ISO/IEC 8886:1996

Information technology — Open Systems Interconnection — Data link service definition

The purpose is to specify the characteristics of a conceptual Data Link Service and thus supplement the OSI Reference Model in guiding the development of Data Link Protocols.

Technologies de l'information — Interconnexion de systèmes ouverts (OSI) — Définition du service de liaison de données

La présente Recommandation | Norme internationale définit le service de liaison de données OSI sous forme a) d'actions et d'événements spécifiés par les primitives de service; b) de paramètres associés à chaque primitive spécifiant une action ou un événement, et de la forme qu'ils revêtent; c) de relations entre ces actions et événements et d'enchaînements valides d'actions et d'événements. Le principal objectif de la présente Recommandation | Norme internationale est de spécifier les caractéristiques d'un service de liaison de données conceptuel et compléter, de ce fait, le modèle de référence OSI en fournissant des lignes directrices pour l'élaboration de protocoles de liaison de données. La présente Recommandation | Norme internationale ne spécifie pas de forme particulière de réalisations ou de produits, et n'impose aucune contrainte de réalisation pour les entités de liaison de données et interfaces d'un système de traitement de l'information. Il n'est donc pas spécifié de conditions de conformité d'équipements à la présente Recommandation | Norme internationale «Définition du service de liaison de données». Par contre, la conformité est obtenue par la mise en oeuvre de protocoles de liaison de données conformes à l'OSI, qui assurent le service de liaison de données défini dans la présente Recommandation | Norme internationale.

General Information

• Status: Published
• Publication Date: 04-Sep-1996
• 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 - Telecommunications and information exchange between systems
• Current Stage: 9093 - International Standard confirmed
• Start Date: 13-Aug-2001
• Completion Date: 12-Feb-2026

Relations

• Revises: ISO/IEC 8886:1992 - Information technology — Telecommunications and information exchange between systems — Data link service definition for Open Systems Interconnection
• Effective Date: 15-Apr-2008

Overview

ISO/IEC 8886:1996 - "Information technology - Open Systems Interconnection - Data link service definition" - is a conceptual, architectural definition of the Data Link Service (DLS) in the OSI Reference Model. It specifies the primitives, parameters and valid sequences that describe how the Data Link Layer provides services to the Network Layer. The standard is abstract (not an implementation specification) and is identical to ITU‑T Recommendation X.212. Its purpose is to guide designers of Data Link Protocols and Network Protocols in achieving interoperable, reliable data transfer.

Key topics and technical requirements

• Service model and conventions
  • Formalizes service primitives (Request, Indication, Response, Confirm) and their parameters.
  • Defines service conventions consistent with ITU‑T X.210 / ISO/IEC 10731.
• Connection-mode and connectionless-mode
  • Describes features, models and primitives for both connection-mode Data Link Service (establishment, release, transfer, reset) and connectionless-mode Data Link Service (single-shot transmissions without a maintained logical association).
• Data‑link‑connection (DLC) and addressing
  • Defines a DLC as an association providing identification and agreed services for a set of transmissions.
  • Introduces DLSAP (Data‑link‑service‑access‑point), local addressing, and DLSDU (Data‑link‑service‑data‑unit).
• Sequence-of-primitives
  • Specifies valid time‑sequence diagrams and constraints for primitives across establishment, data transfer, release, abort and rejection scenarios.
• Quality of Service (QoS)
  • Mechanisms for negotiation and specification of QoS parameters (throughput, delay, reliability characteristics) for both connection and connectionless services.
• Design constraints
  • Emphasizes independence from physical layer details and transparent transfer of user data; clarifies where duplication, loss or reordering may be handled.

Practical applications

• Guiding the design and specification of data link protocols (protocol state machines, frame formats abstracted from physical media).
• Defining service interfaces between the Data Link Layer and Network Layer in OSI‑based architectures.
• Establishing interoperability targets for vendors implementing link-layer functionality, especially for systems requiring explicit QoS negotiation.
• Informing test and conformance profiles where implementations must realize the abstract DLS via concrete protocols.

Who should use this standard

• Network architects and protocol designers
• Firmware and driver developers for link-layer implementations
• Standards developers and technical committees
• Test laboratories and system integrators focused on interoperability and QoS at the link layer

Related standards

• ISO/IEC 7498‑1 (ITU‑T X.200) - OSI Reference Model: The Basic Model
• ISO/IEC 10731 (ITU‑T X.210) - Conventions for the definition of OSI services
• ITU‑T Recommendation X.212 - identical text to ISO/IEC 8886

Keywords: ISO/IEC 8886, Data Link Service, OSI, data link layer, DLS, QoS, connection‑mode, connectionless‑mode, DLSAP, DLSDU, data‑link‑connection.

Standards Content (Sample)

INTERNATIONAL lSO/IEC
STANDARD 8886
Second edition
1996-09-I 5
Information technology - Open Systems
Interconnection - Data link service
definition
Technologies de /‘information - lnterconnexion de s yst&mes ouverts
(09) - Dgfinition du service de liaison de don&es
Reference number
lSO/IEC 8886:1996(E)
PSWIEC 8886: W%(E)
Contents
Page
1 Scope .
.....................................................................................................................................
2 Normative references
........................................................................
2.1 Identical Recommendations I International Standards
Definitions .
.......................................................................................................
31 OS1 Reference Model definitions
.........................................................................................................
3:2 Service Conventions definitions
.............................................................................................................
33 . Data Link Service definitions
4 Abbreviations .
....................................................................................................................................................
5 Conventions
............................................................................................................................
51 General conventions
...........................................................................................................................................
512 Parameters
Overview of the Data Link Service .
.........................................................................................................
Classes and types of Data Link Service
.....................................................................................
Features of the connection-mode Data Link Service
........................................................................................
Model of the connection-mode Data Link Service
...........................................................................................
9.1 DLC Endpoint Connection Identification
........................................................................................................
9.2 Model of a Data-link-connection
.............................................................................................
10 Quality of connection-mode Data Link Service
........................................................................
10.1 Determination of QOS for Connection-mode Service
Definition of connection-mode QOS parameters .
10.2
11 Sequence of primitives .
...................................................... 10
11.1 Concepts used to define the connection-mode Data Link Service
................................................................................................ 10
11.2 Constraints of Sequence of Primitives
....................................................................................................................
12 Connection establishment phase
..............................................................................................................................................
12.1 Function
....................................................................................................
12.2 Types of primitives and parameters
........................................................................................................................
1.2.3 Sequence of primitives
;g ISO/IRC f 996
LTI iights .;eserved. Unless otherwise specified, no part 0% tRis publication may ‘be reproduced or
d~ixcj in any i’orm or by any means, electronic or mechanical, including photocopying and
’ nkxkilm, tiii/ithoU:Jt permission in writing from the publisher.
WWIEC Copyright 0ffice Q Case postale 56 l Cl-i-121 1 Gerkve 20 e Switzedand
i’einted i. n &d tzerlmd
@ ISO/IEC ISO/IEC 8886: 1996(E)
............................................................................................................................... 14
13 Connection release phase
.............................................................................................................................................. 14
13.1 Function
13.2 Types of primitive and parameters . 15
13.3 Sequence of primitives when releasing an established DLC . 16
13.4 Sequence of primitives in a DLS user rejection of DLC establishment attempt . 17
13.5 Sequence of primitives in a DLS provider rejection of a DLC establishment attempt . 17
Sequence of primitives in a DLS user abort of a DLC establishment attempt
13.6 . 17
.........................................................................................................................................
14 Data transfer phase
14.1 Data transfer .
14.2 Reset service .
. . . . . .*. 21
15 Features of the Connectionless-mode Data Link Service
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16 Model of the Connectionless-mode Data Link Service
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16.1 Model of a data-link-connectionless-mode data transmission
Quality of Connectionless-mode Service .
17.1 Determination of QOS for Connectionless-mode Service .
17.2 Definition of connectionless-mode QOS parameters .
Sequence of connectionless-mode primitives at one DLSAP .
...................................................................................................................................................
19 Data transfer
19.1 Function .
....................................................................................................
19.2 Types of primitives and parameters
19.3 Sequence of primitives .
. . .
ISO/IEC 8886: 1996(E) o ISO/IEC
Foreword
IS0 (the International Organization for Standardization) and IEC (the International Electrotechnical Commission) form
the specialized 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 committees collaborate in fields of mutual interest.
Other international organizations, governmental and non-governmental, in liaison with IS0 and IEC, also take part in the
work.
In the field of information technology, IS0 and IEC have established a joint technical committee, ISO/IEC JTC 1. Draft
International Standards adopted by the joint technical committee are circulated to national bodies for voting. Publication
as an International Standard requires approval by at least 75 % of the national bodies casting a vote.
International Standard ISO/IEC 8886 was prepared by Joint Technical Committee ISO/IEC JTC 1, Information
technology, Subcommittee SC 6, Telecommunications and information exchange between systems, in collaboration with
ITU-T. The identical text is published as ITU-T Recommendation X.212.
This second edition cancels and replaces the first edition (ISOKEC 8886: 1992), which has been technically revised.
iv
@ ISO/IEC ISO/IEC 8886:1996(E)
Introduction
This Recommendation I International Standard is one of a set of Recommendations I International Standards produced to
facilitate the interconnection of information processing systems. It is related to other Recommendations I International
Standards in the set as defined by ITU-T Rec. X.200 I ISO/IEC 7498-1, OS1 Reference Model - The Basic Model. The
reference model described by ITU-T Rec. X.200 I ISO/IEC 7498-l subdivides the area of standardization for Open
Systems Interconnection (OSI) into a series of layers of specification, each of a manageable size.
This Recommendation I International Standard defines the services provided by the Data Link Layer to the Network
Layer at the boundary between the Data Link and Network Layers of the OS1 Reference Model. It provides for the
designers of network protocols a definition of the Data Link Service existing to support the network protocol and for the
designers of Data Link Protocols a definition of the services to be made available through the action of the Data Link
Protocol over the underlying service. The relationship is illustrated in Figure Intro. 1.
Throughout the set of OS1 Recommendations I International Standards, the term “service” refers to the abstract
capability provided by one layer of the OS1 Reference Model to the layer immediately above. Thus, the Data Link
Service defined in this Recommendation I International Standard is a conceptual architectural service, independent of
administrative divisions.
Uses Data Link Service
Network Layer ,
Network Protocol
Data Link Service
Provides Data Link Service
Data Link Protocol Data Link Layer 1
TO721760-95/dOl
Figure Intro. 1 - Relationship of this Recommendation I International Standard
to other OS1 Recommendations I International Standards

This page intentionally left blank

ISO/IEC 8886 : 1996 (E)
INTERNATIONAL STANDARD
ITU-T RECOMMENDATION
INFORMATION TECHNOLOGY - OPEN SYSTEMS INTERCONNECTION -
DATA LINK SERVICE DEFINITION
1 Scope
This Recommendation I International Standard defines the OS1 Data Link Service in terms of:
the primitive actions and events of the service;
a>
the parameters associated with each primitive action and event, and the form that they take; and
W
the interrelationship between, and the valid sequences of these actions and events.
C>
The principal objective of this Recommendation I International Standard is to specify the characteristics of a conceptual
Data Link Service and thus, supplement the OS1 Reference Model in guiding the development of Data Link Protocols.
not specify individ ual implementation or products, nor does it
This Recommendation I International Standard does
of Data Link entities and interfaces w ithin an information processing system.
con strain the implementation
There is no conformance of equipment to this Data Link Service Definition Recommendation I International Standard.
Instead, conformance is achieved through implementation of conforming Data Link Protocols that fulfil the Data Link
Service defined in this Recommendation I International Standard.
2 Normative references
The following Recommendations and International Standards contain provisions which, through reference in this text,
constitute provisions of this Recommendation I International Standard. At the time of publication, the editions indicated
were valid. All Recommendations and International Standards are subject to revision, and parties to agreements based on
this Recommendation I International Standard are encouraged to investigate the possibility of applying the most recent
edition of the Recommendations and Standards listed below. Members of IEC and IS0 maintain registers of currently
valid International Standards. The Telecommunication Standardization Bureau maintains a list of currently valid ITU-T
Recommendations.
21 . Identical Recommendations I International Standards
-
ITU-T Recommendation X.200 (1994) I ISO/IEC 7498-l : 1994, Information technology - Open Systems
Interconnection - Basic Reference Model: The Basic Model.
-
ITU-T Recommendation X.210 (1993) I ISO/IEC 1073 1: 1994, Information technology - Open Systems
Interconnection - Basic Reference Model: Conventions for the definition of OSI services.
- GENERAL
PART 1
3 Definitions
31 . OS1 Reference Model definitions
This Recommendation I International Standard is based on the concepts developed and makes use of the following terms
defined in ITU-T Rec. X.200 I ISO/IEC 749% 1:
a) Data link entity;
b) Data Link Layer;
c) Data Link Service;
d) Data-link-service-access-point;
ITU-T Rec. X.212 (1995 E) 1
ISO/IEC 8886 : 1996 (E)
e) Data-link-service-access-point-address;
f) Data-link-service-data-unit;
g) Reset.
32 . Service Conventions definitions
This Recommendation I International Standard makes use of the following terms defined in ITU-T Rec. X.210 I
ISO/IEC 10731, as they apply to the Data Link Layer:
a) Data Link Service Users;
b) Data Link Service Provider;
c) Primitive;
d) Request;
e) Indication;
f) Response;
g) Confirm.
Data Link Service definitions
33 .
This Recommendation I International Standard makes use of the following terms:
a) data-link-connection
An association established by a Data Link Layer between two or more Data Link Service Users for the
transfer of data, which provides explicit identification of a set of Data Link data transmissions and
agreement concerning the Data Link data transmission services to be provided for the set.
NOTE - This definition clarifies the definition given in ITU-T Rec. X.200 I ISOLEC 749% 1.
data-link-connection-mode data transmission
b)
The transmission of a Data-link-service-data-unit within the context of a Data-link-connection that has
been previously established.
c) data-link-connectionless-mode data transmission
The transmission of a Data-link-service-data-unit not in the context of a Data-link-connection and not
required to maintain any logical relationship among multiple invocations.
4 Abbreviations
For this purposes of this Recommendation I International Standard, the following abbreviations apply:
DL Data Link
DLC Data-link-connection
DLL Data Link Layer
Data Link Service
DLS
Data-link-service-access-point
DLSAP
DLSDU Data-link-service-data-unit
OS1 Open Systems Interconnection
Quality of Service
QOS
5 Conventions
51 . General conventions
This Recommendation I International Standard uses the descriptive conventions given in ITU-T Rec. X.210 I
ISOIIEC 1073 1.
The service model, service primitives, and time-sequence diagrams used are entirely abstract descriptions; they do not
represent a specification for implementation.
2 ITU-T Rec. X.212 (1995 E)
ISO/IEC 8886 : 1996 (E)
52 . Parameters
Service primitives, used to represent service user/service provider interactions (see ITU-T Rec. X.210 I ISO/IEC 10731),
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 falls may carry the parameter
labelling the row in which it falls.
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
primitive issued
supplied in a previous request or response 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
between DLS users. It makes invisible to these
The DLS provides for the transparent and reliable transfer of data
utilized to achieve this transfer.
DLS users the way in which supporting communications resources are
In particular, the DLS provides for the following:
Independence of underlying Physical Layer - The DLS relieves DLS users from all concerns regarding
a)
which configuration is available (e.g. point-to-point connection) or which physical facilities are used
(e.g. half-duplex transmission).
Transparency ?f transferred information - The DLS provides for the transparent transfer of DLS user-
b)
data. It does not restrict the content, format or coding of the information, nor does it ever need to interpret
its structure or meaning.
Reliable transfer of data - The DLS relieves the DLS user from loss, insertion, corruption or, if
Cl
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.
NOTE 1 - Detection of duplicate or lost DLSDUs may be performed by DLS users.
Quality of Service selection - The DLS makes available to DLS users a means to request and to agree
d)
upon a quality of service for the transfer of data. QOS is specified by means of QOS parameters
representing characteristics such as throughput, transit delay, accuracy and reliability.
Addressing - The DLS allows the DLS user to identify itself and to specify the DLSAP to which a DLC
e)
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 define a global
addressing structure.
NOTE 2 - 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 Data Link Service:
a connection-mode service (defined in Part 2); and
a)
a connectionless-mode service (defined in Part 3).
W
When making reference to this Recommendation I International Standard, a user or provider of Data Link Service shall
state which types of service it expects to use or provide.
ITU-T Rec. X.212 (1995 E)
ISO/IEC 8886 : 1996 (E)
PART 2 - DEFINITION OF THE 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
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 contents 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 ITU-T Rec. X.200 I ISO/IEC 7498-1,7.6.3.5.2).
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 Recommendation I International Standard uses the abstract model for a layer service defined in clause 4 of
ITU-T Rec. X.210 I ISO/IEC 1073 1. 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 provider by service
primitives, which may convey parameters.
91 l 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 must 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. Such an implicit identification is not described in this
Recommendation I International Standard.
92 . 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 primitives. (Allowable primitive sequences are specified in clause 11.
See also the Note below.) In addition, this model does not attempt to describe all the functions or operations of DL
entities that are used to provide the DLS. No attempt to specify or constrain DLS provider implementations is implied.
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 an DLSAP
may prevent the receipt of a DL-DATA indication primitive, corresponding to a previously issued DE-DATA request primitive, by
the peer DLS user) there may also be:
constraints applied locally on the ability to invoke primitives;
a>
service procedures defining particular sequencing constraints on some primitives.
b)
4 ITU-T Rec. X.212 (1995 E)
ISO/IEC 8886 : 1996 (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 1).
DLSAP DLSAP ’
Queue from A to B
Queue from B to A
DLS provider
T0721770-95/d02
Figure 1 - 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. 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-14):
a connect object, representing a DL-CONNECT request or response primitive and its parameters;
a>
a data object, representing a DL-DATA request primitive and its parameters;
b)
a reset object, representing a DL-RESET request or response primitive and its parameters; and
C>
d) a disconnect object, representing a DL-DISCONNECT request primitive and its parameters.
The following objects may be placed in a queue by the DLS provider (see clauses 12-14):
1) a reset object;
2) a synchronization mark object (see 9.2.4); and
a disconnect object.
The queues are defined to have the following general properties:
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
a queue has a limited capacity, but this capacity is not necessarily either fixed or determinable.
V>
DLC establishment
9.2.2
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 of the queues. From the standpoint
of the DLS users of the DLC, the queues remain associated with the DLC until a disconnect object representing
a DL-DISCONNECT request or indication primitive is either entered or removed, respectively, 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 data objects can
be entered only after DLS user B has entered a connect object representing a DL-CONNECT response primitive.
ITU-T Rec. X.212 (1995 E) 5
ISO/IEC 8886 : 1996 (E)
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 an object may prevent addition of a further object.
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 in 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, disconnect objects.
The relationships between objects which may be manipulated in the above fashion are summarized in Table 1.
Whether the DLS provider performs actions resulting in deletion or not will depend upon the behaviour of the
DLC users and the agreed QOS for the DLC. In general, if a DLS user does not remove objects from a queue, the
DLS provider shall, after some unspecified period of time, perform all the permitted deletions.
Table 1 - Relationships between queue model objects
Synchronization
Connect Data Reset Disconnect
mark
preceding object x
- -
Connect N/A N/A DES
-
Data N/A DES N/A DES
-
-
N/A DES DES
Reset
-
DES
Synchronization mark N/A DES N/A
Disconnect N/A N/A N/A N/A DES
N/A x will not precede y in a valid state of a queue
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:
it cannot be removed from a queue by a DLS user;
a)
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 object 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:
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 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 by the peer DLS user.
.
ITU-T Rec. X.212 (1995 E)
ISO/IEC 8886 : 1996 (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
primitive.
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
endpoints. QOS describes aspects of a DLC that are attributable solely to the DLS provider.
Once a DLC is established, the DLS users at the two ends have the same knowledge and understanding of what the QOS
over the DLC is.
10.1 Determination of QOS for Connection-mode Service
QOS is determined 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 DLS QOS parameters can be divided into the following two types, based upon the way in which their values are
determined:
those QOS parameters which may be selected on a per-connection basis during the establishment phase of
a)
a DLC;
those QOS parameters which are not selected during DLC establishment but whose values are known
b)
by
other methods.
There are three QOS parameters, throughput, protection, and priority (as defined in 10.2.1, 10.2.5 and 10.2.6
respectively), which are of the type that may be selected during DLC establishment. The selection procedures for these
parameters are described in detail in 12.25. Once the DLC is established, throughout the lifetime of the DLC, the agreed
QOS values are not reselected at any point, and there 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.
The remaining QOS characteristics that are identified as parameters, but for which there is no selection during DLC
establishment, are transit delay, residual error rate and resilience (as 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-CONNECT
request primitive action is initiated. The requested measures (or parameter values and options) are based on a priori
knowledge by the DLS user of the service(s) made available to it by the DLS provider. Knowledge of the characteristics
and type of service provided (i.e. the parameters, formats, and options that affect 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 DLS user has explicit knowledge of the characteristics of the service it can expect to be provided with each
invocation of the service.
The DLS provider may also provide information on the current QOS independently of access to the service by the
DES 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.
ITU-T Rec. X.212 (1995 E) 7
ISO/IEC 8886 : 1996 (E)
Definition of connection-mode QOS parameters
10.2
QOS parameters can be classified as:
a) parameters that express DLS performance, as shown in Table 2.
b) parameters that express other DLS characteristics, as shown in Table 3.
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.
Table 2 - Classification of performance QOS parameters
Performance criterion
Accuracy/reliability
Speed
Throughput Residual error rate (corruption, duplication/loss)
Resilience
Transit delay
Table 3 - QOS parameters not associated with performance
/I
Priority
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 input/output time for that sequence.
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 of the DLC by the receiving DLS user.
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:
the time between the first and the last DL-DATA request in the sequence;
a)
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.
10.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 QOS parameter 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 is
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.
ITU-T Rec. X.212 (1995 E)
ISOAEC 8886 : 1996 (E)
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 a particular DLS user
pair, as shown in Figure 2.
DLSDUs received
DLSDUs sent
Successf uily
Incorrect
Extra
transferred
Lost DLSDUs
DLSDUs =
DLSDUs =
DLSDUs =
= DL(&)
DL(&) + DL(e) + DL(x)
We)
wx)
Ws)
Total DLSDUs transferred = DL
Figure 2 - Components of Residual Error Rate
10.2.4 Resilience
This parameter specifies the probability of:
a DLS provider initiated DLC release (i.e. the issuance of a DL-DISCONNECT indication primitive with
a>
no prior DL-DISCONNECT request primitive); or
b) a DLS provider initiated reset (i.e. 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:
no protection features;
a)
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 if available is typically
provided by a different DLS provider mechanism.
10.2.6 Priority
The specification of priority is concerned with the relationship between DLCs.
This parameter specifies the relative importance of a DLC with respect to:
the order in which DLCs are to have their QOS degraded, if necessary; and
a)
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 of structure able to judge relative
importance. The number of priority levels is limited.
ITU-T Rec. X.212 (1995 E) 9
ISO/IEC 8886 : 1996 (E)
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 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 connection is established;
the DLC allows transmission of data and preserves its division into DLSDUs; the transmission of this data
C)
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 of Sequence of Primitives
This clause defines the constraints of the sequence in which the primitives defined in clauses 12-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.
Table 4 - Summary of data-link-connection-mode primitives and parameters
Primitive Parameters
Phase Service
DLC DL-CONNECT request (Called address, calling address, QOS
DLC
establishment establishment parameter set, DLS user-data)
DL-CONNECT indication (Called address, calling address, QOS
parameter set, DLS user-data)
I
DL-CONNECT response (Responding address, QOS parameter set,
DLS user- data)
DL-CONNECT confirm (Responding address, QOS parameter set,
DLS user-data)
DL-DATA request (DLS user-data)
Data transfer Normal data
transfer
DL-DATA indication (DLS user-data)
Reset DL-RESET request (Reason)
DLC release
10 IT&T Rec. X.212 (1995 E)
ISO/IEC 8886 : 1996 (E)
11.2.1 Relation of primitives at the two endpoints
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
subclauses of clauses 12-15; all of these relations are summarized in the diagrams in Figure 3.
However, a DL-DISCONNECT request or indication primitive may terminate any of the other sequences before
completion.
a) Successful DLC Establishment b) DLC Collision
c) DLS User invoked Release
DL-CONNECT DL-DISCONNECT
f) Simultaneous DLS User and
e) DLS Provider invoked DLC Release
d) Simultaneous DLS User
DLS Provider invoked DLC Release
invoked DLC Release
DL-DISCONNECT
Ir) DL-DISCONNECT
l
request
DL-DISCONNECT
request
DL-DISCONNECT
request
indication
l
/\/
DL-DISCONNECT
indic~F[ b pEcT
-i
i) Normal Data Transfer
h) DLS Provider Rejection of a
g) DLS User Rejection of a
DLC Establishment attempt
DLC Establishment attempt
DL-CONNECT
DL-DATA
DL-CONNECT I I
B
request
4 HeNEcYZ.-;-i~~EcT
DL-DISCONNECT
indication
k) Simultaneous DLS User invoked Reset I) DLS Provider invoked Reset
j) DLS User Invoked Reset
DL-RESET DL-RESET DL-RESET DL-RESET
DL-RESt
l 4
D DL-RESET
?J %
request indication
request request indication
indication
\
I I r
DL-RESET
DL-RESET
DL-RESET
XJ
4 b
response
%
i
DL-RESta response response
confirm
m) Simultaneous DLS User and
DLS Provider Involved Reset
T0721790-95/d04
+ELiE-iok
confirm response
Figure 3 - Summary of Data-iink-connection-mode Service
Primitive Time-sequence Diagram
ITU-T Rec. X.212 (1995 E) 11
ISOAEC 8886 : 1996 (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
...

NORME lSO/CEI
INTERNATIONALE
Deuxième édition
1996-09-I 5
Technologies de l’information -
Interconnexion de systèmes ouverts
(OSI) - Définition du service de liaison de
données
Open Systems In terconnection - Data link
Informa tien technolog y -
service definition
Numéro de référence
ISO/CEI 8886:1996(F)
ISOKEI 8886: 1996(F)
Sommaire
Page
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Domaine d’application
...................................................................................................................................
2 Références normatives
...................................................................... 1
2.1 Recommandations I Normes internationales identiques
......................................................................................................................................................
3 Définitions
3.1 Définitions du modèle de référence OS1 .
................................................................................
32 Définitions relatives aux conventions de service
Définitions relatives au service de liaison de données .
3:3
4 Abréviations . . . . . . .~.~~~~~.~.~.~.~.~.
....................................................................................................................................................
5 Conventions
Conventions génerales .
...........................................................................................................................................
5:2 Paramètres
Présentation du service de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types et classes pour le service de liaison de données
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Caractéristiques du service de liaison de données en mode connexion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modéle du service de liaison de données en mode connexion
Identification d’extrémité de connexion de liaison de données . . . . . . . .C.
91 .
Modèle d’une connexion de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92 .
.......................................................................
10 Qualité du service de liaison de données en mode connexion
....................................................................
10.1 Détermination de la QS pour le service avec connexion
........................................................................
10.2 Définition des param&res de QS en mode connexion
..........................................................................................................................
11 Enchdnement des primitives
..................... 10
11.1 Concepts utilisés pour améliorer le service de liaison de données en mode connexion
....................................................................... 11
11.2 Contraintes imposées à l’enchaînement des primitives
...............................................................................................................
12 Phase d’établissement de connexion
12.1 Fonction .
......................................................................................... 14
12.2 Types de primitives et paramètres associés
................................................................................................................ 15
12.3 Enchaînement de primitives
0 ISOKEI 1996
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne
peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou
mécanique, y compris la photocopie et les microfilms, sans l’accord écrit de l’éditeur.
ISO/CEI Copyright Office l Case postale 56 l CH-121 1 Genève 20 l Suisse
Version française tirée en 1997
Imprimé en Suisse
ii
@ ISOKEI ISOKEI 8886: 1996(F)
Phase de liberation de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1 Fonction . . . . . . . . . . . . . . . . . . . . . . .*. 15
13.2 Types de primitives et paramètres associés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3 Enchaînement de primitives échangées au moment de la liberation d’une connexion de liaison de
données établie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.4 Enchaînement de primitives correspondant au rejet, par un utilisateur du service de liaison de
données, d’une tentative d’établissement de connexion de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.5 Enchaînement de primitives correspondant au rejet, par le fournisseur du service de liaison de
données, d’une tentative d’établissement de connexion de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.6 Enchamement de primitives correspondant à la coupure, par un utilisateur du service de liaison de
données, d’une tentative d’établissement de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14 Phase de transfert de données 19
14.1 Transfert de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.2 Service de reinitialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Fonctionnalités du service de liaison de données en mode sans connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
............................................................... 23
16 Modèle du service de liaison de donnees en mode sans connexion
................. 23
16.1 Modèle d’une transmission de données en mode sans connexion sur liaison de données.
...................................................................................................
17 Qualité du service en mode sans connexion
......................................................
17.1 Détermination de la QS pour le service en mode sans connexion
................................................................ 24
’
17.2 Définition des param&res de QS en mode sans connexion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
18 Enchaînement de primitives en mode sans connexion au niveau d’un DLSAP
......................................................................................................................................
19 Transfert de données
19.1 Fonction .
.........................................................................................
19.2 Types de primitives et paramètres associes
19.3 Enchaînement de primitives .
. . .
ISOKEI 8886: 1996(F) @ ISOKEI
Avant-propos
LIS0 (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de 1’ISO ou de la CE1 participent au développement de Normes inter-
nationales par l’intermédiaire des comités techniques créés par l’organisation
concernée afin de s’occuper des différents domaines particuliers de l’activité
technique. Les comités techniques de 1’ISO et de la CE1 collaborent dans des
domaines d’intérêt commun. D’autres organisations internationales, gouverne-
mentales ou non gouvernementales, en liaison avec 1’ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l’information, I’ISO et la CE1 ont créé un
comité technique mixte, I’ISOKEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 8886 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de l’information, sous-comité SC 6, TéLé-
informatique, en collaboration avec l’UIT-T. Le texte identique est publié en tant
que Recommandation UIT-T X.2 12.
Cette deuxième édition annule et remplace la première édition (ISO/CEI 8886: 1992),
qui a fait l’objet d’une révision technique.
1v .
@ ISOKEI ISOKEI 8886: 1996(F)
Introduction
La présente Recommandation I Norme internationale appartient à une série de Recommandations I Normes
internationales élaborées pour faciliter l’interconnexion de systèmes de traitement de l’information. Elle appartient à un
ensemble de Recommandations I Normes internationales dont les relations sont définies par la Rec. UIT-T X.200 I
ISOKEI 7498-1, modèle de référence OS1 - modèle de base. Le modèle décrit par la Rec. UIT-T X.200 I
ISOKEI 7498-l divise le domaine de la normalisation, en vue de l’interconnexion des systèmes ouverts (OSI), en une
série de couches de spécifications, dont chacune est d’une taille maîtrisable.
La présente Recommandation I Norme internationale définit le service fourni par la couche liaison de données à la
couche réseau, à la frontière entre ces deux couches du modèle de référence OSI. Elle fournit aux concepteurs de
protocoles de réseau une définition du service de liaison de données disponible pour la mise en œuvre du protocole de
réseau, et aux concepteurs de protocoles de liaison de données une définition des services devant être fournis par
l’intermédiaire du protocole de liaison de données à partir du service de la couche de niveau inférieur. Cette relation est
représentée à la Figure Intro. 1.
Dans le contexte de l’ensemble des Recommandations OS1 I Normes internationales, le terme «service» se réfère à la
capacité abstraite fournie par une couche du modèle de référence OS1 à la couche immédiatement supérieure. Le service
de liaison de donnees défini dans la présente Recommandation I Norme internationale est donc un service architectural
conceptuel, independant des divisions administratives.
couche utilise le setwice
protocole de r&eau
r6seau
de liaison de donMes
service de liaison de donn&s
fournit le service de liaison
protocole de liaison couche liaison
de donMes dedonnbes dedonn6es
TO721760-95/dOl
Figure Intro. 1 - Relation entre la présente Recommandation I Norme
internationale et d’autres Recommandations OS1 I Normes internationales

Page blanche
ISOKEI 8886 : 1996 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION - INTERCONNEXION DE SYSTÈMES
DÉFINITION DU SERVICE DE LIAISON DE DONNÉES
OUVERTS (OSI) -
Domaine d’application
Recommandation Norme internationale définit le service de liaison de données os1 sous forme
La présente
d’actions et d’événements spécifiés par les primitives de service;
a)
b) de paramètres associés à chaque primitive spécifiant une action ou un événement, et de la forme qu’ils
revêtent;
c) de relations entre ces actions et événements et d’enchaînements valides d’actions et d’événements.
Le principal objectif de la présente Recommandation I Norme internationale est de spécifier les caractéristiques d’un
service de liaison de données conceptuel et compléter, de ce fait, le modele de référence OS1 en fournissant des lignes
directrices pour l’élaboration de protocoles de liaison de données.
La présente Recommandation I Norme internationale ne spécifie pas de forme particulière de réalisations ou de produits,
et n’impose aucune contrainte de réalisation pour les entités de liaison de données et interfaces d’un système de
traitement de l’information.
Il n’est donc pas spécifie de conditions de conformité d’équipements à la présente Recommandation I Norme
internationale «Définition du service de liaison de données». Par contre, la conformité est obtenue par la mise en œuvre
de protocoles de liaison de données conformes à I’OSI, qui assurent le service de liaison de données défini dans la
présente Recommandation I Norme internationale.
2 Références normatives
Les Recommandations et Normes internationales suivantes contiennent des dispositions qui, par suite de la référence qui
y est faite, constituent des dispositions valables pour la présente Recommandation I Norme internationale. Au moment
de la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à révision
et les parties prenantes aux accords fondés sur la présente Recommandation I Norme internationale sont invitées à
rechercher la possibilité d’appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de I’UIT tient à jour une liste des Recommandations de I’UIT-T en vigueur.
21 Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l: 1994 - Technologies de Z’information -
Interconnexion des systèmes ouverts - Modèle de référence de base: le modèle de référence de base.
-
Recommandation UIT-T X.210 (1993) I ISOKEI 1073 1: 1994 - Technologies de I?nformation -
Interconnexion des systèmes ouverts - Modèle de référence de base: conventions pour la définition des
services de l’interconnexion des systèmes ouverts.
Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
PARTIE 1 - GÉNÉRALITÉS
Définitions
Définitions du modèle de référence OS1
31 .
La présente Recommandation I Norme internationale est fondée sur les concepts élaborés dans la Rec. UIT-T X.200 I
ISOKEI 7498-l et utilise les termes suivants, qui y sont définis:
entité de liaison de données;
a)
b) couche liaison de données;
service de liaison de données;
C)
d) point d’accès au service de liaison de données;
e) adresse de point d’accès au service de liaison de données;
unite de données du service de liaison de données;
f)
g) réinitialisation.
Définitions relatives aux conventions de service
32 l
La présente Recommandation I Norme internationale utilise les termes et expressions suivants définis dans la
Rec. UIT-T X.210 I ISOKEI 10731, tels qu’ils s’appliquent à la couche liaison de données:
utilisateur du service de liaison de données;
a)
b) fournisseur du service de liaison de données;
c) primitive;
d) demande;
indication;
e)
réponse;
confirmation.
33 . Définitions relatives au service de liaison de données
La présente Recommandation I Norme internationale utilise les termes suivants:
connexion de liaison de données
a>
Association établie par une couche liaison de donnees entre deux ou plusieurs utilisateurs du service de
liaison de données pour le transfert de données, assurant l’identification explicite d’un ensemble de
transmissions de donnees sur la liaison de données, ainsi que l’acceptation concernant les services de
transmission de données sur la liaison de données devant être fournis audit ensemble.
Cette definition apporte des précisions à la définition donn6e dans la Rec. UIT-T X.200 I
NOTE -
ISOKEI 7498- 1.
b) transmission de données en mode avec connexion sur la liaison de données
Transmission d’une unité de données du service de liaison de données dans le contexte d’une connexion
de liaison de données établie précédemment.
c) transmission de données en mode sans connexion sur la liaison de données
Transmission d’une unité de données du service de liaison de données hors du contexte d’une connexion
de liaison de données et non nécessaire pour maintenir une relation logique quelconque entre des appels
multiples.
4 Abréviations
Pour les besoins de la présente Recommandation I Norme internationale, les abreviations suivantes sont utilisées.
DL Liaison de donnees (data Zink)
DLC Connexion de liaison de donnees (data link-connection)
Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
DLL Couche liaison de données (data link layer)
DLS Service de liaison de données (data link service)
DLSAP Point d’accès au service de liaison de donnees (data-Zink-service-access-point)
DLSDU Unité de données du service de liaison de données (data link-service-data-unit)
os1 Interconnexion des systèmes ouverts (open systems interconnection)
Qualite de service
QS
5 Conventions
Conventions générales
51 l
La présente Recommandation I Norme internationale utilise les conventions descriptives définies dans la
Rec. UIT-T X.210 I ISOKEI 10731.
les diagrammes d’enchaînement sont des descriptions purement
Le modèle d .u service, les primitives de service et
ne constituent pas une spécifi cation en v ‘ue d’une réalisation.
abstraites; i .lS
Paramètres
52 .
Les primitives de service, utilisées pour représenter les interactions entre utilisateur et fournisseur du service
(Rec. UIT-T X.210 I ISOKEI 10731), véhiculent des paramètres qui indiquent les informations disponibles pour
l’interaction entre l’utilisateur et le fournisseur.
Les paramètres associés à chaque groupe de primitives du service de liaison de données sont indiqués dans les tableaux
des articles 12 à 14 et 19. Les colonnes de ces tableaux correspondent aux primitives et les lignes aux paramètres. Les
parametres pouvant être associés à une primitive donnée sont indiqués par un «X» à l’intersection de la ligne et de la
colonne correspondantes.
Certains de ces «X» sont qualifiés par un élément entre parenthèses. Il peut s’agir
de contraintes spécifiques à un paramètre:
(=) indique que la valeur fournie dans une primitive d’indication ou de confirmation est toujours identique
à celle fournie dans la précédente primitive de demande ou de repense émise au niveau du point d’accès
au service homologue;
d’indication de renvoi à une note concernant cette case du tableau:
b)
(voir la Note X) indique que la note en référence contient des informations supplémentaires concernant le
paramètre et son utilisation.
donnée. Certains
Il n’est pas nécess #aire que tou .s les paramètres soient explicitement présents pour une interface
implicitement au DLSAP au niveau duquel la primitive est émise.
paramètres peuvent être associés
6 Présentation du service de liaison de données
Le DLS assure le transfert transparent et fiable de données entre utilisateurs du DLS. Il leur rend invisible la façon dont
les ressources de communication mises en œuvre sont utilisées pour réaliser ce transfert.
Le DLS assure en particulier
a) l’indépendance par rapport à la couche physique sous-jacente - Le DLS dégage les utilisateurs de ce
service de toute préoccupation concernant la configuration disponible (par exemple, connexion point à
point) ou les moyens physiques utilisés (par exemple, transmission semi-duplex);
b) la transparence des informations transférées - Le DLS assure le transfert transparent de données de
l’utilisateur du DLS. Il n’impose aucune restriction quant au contenu, au format ou au codage des
informations, et n’a même pas besoin d’interpréter leur structure ou leur signification;
c) le transfert fiable des données - Le DLS met les utilisateurs de ce service à l’abri des pertes, insertions,
mutilations ou, le cas échéant, d’altérations de l’ordre des données. Dans certains cas d’impossibilité de
reprise sur erreur dans la couche liaison de données, il peut se produire un dédoublement ou une perte
de DLSDU;
NOTE 1 - La dkction des DLSDU d6doublées ou perdues peut être effectuh par les utilisateurs du DLS.
Rec. UIT-T X.212 (1995 F) 3
ISOKEI 8886 : 1996 (F)
d) le choix de la qualité de service - Le DLS offre aux utilisateurs la possibilité de demander ou d’accepter
une certaine qualité de service pour le transfert de données. La qualité de service est spécifiée par des
paramètres de QS exprimant des caractéristiques telles que le débit, le temps de transit, l’exactitude et la
fiabilité;
e) adressage - Le DLS permet à l’utilisateur de s’identifier et d’indiquer le DLSAP à destination duquel une
DLC doit être etablie, chaque fois que plus de deux DLSAP sont acceptés par le fournisseur du DLS. Les
adresses de liaison de données n’ont qu’une signification locale à l’intérieur d’une configuration spécifique
de liaison de donnees, sur un support de transmission unique (connexion physique point à point ou
multipoint) ou sur un faisceau de supports de transmission parallèles (multiliaison ou fonction
d’éclatement). En conséquence, il n’est pas opportun de définir une structure d’adressage globale.
NOTE 2 - Le DLS est tenu de faire la distinction entre les divers systèmes reliés physiquement ou logiquement
à une liaison de donnees multipoint et également la distinction entre des connexions dans le cas où la couche liaison
de données possède une fonction de multiplexage. Aux fins de la communaute de conception avec les définitions
d’autres services, ce mécanisme est appelé adressage et les objets servant à faire la distinction entre des systemes sont
appelés adresses.
7 Types et classes pour le service de liaison de données
défini de classes distinctes pour le service de liaison de données. Il existe deux de service de liaison
Il n’a pas été
types
de données:
un service en mode connexion (défini dans la Partie 2);
un service en mode sans connexion (défini dans la Partie 3).
b)
Lorsqu’il fait référence à la présente Recommandation I Nom .e international un utilisateur ou un fournisseur du
es,
service de liaison de données doit indiquer quel type de ser vice il entend utiliser ou fournir.
PARTIE 2 - DÉFINITION DU SERVICE EN MODE CONNEXION
8 Caractéristiques du service de liaison de données en mode connexion
Le DLS offre les possibilités suivantes à ses utilisateurs:
a) le moyen pour un utilisateur du DLS d’établir une DLC avec un autre utilisateur, afin d’échanger des
DLSDU;
b) le moyen de convenir, entre l’utilisateur demandeur et le fournisseur du DLS, une certaine qualité de
service associee à chaque DLC;
c) le moyen de transférer des DLSDU de longueur limitée sur une connexion de liaison de données. Le
transfert des DLSDU est transparent: le DLS ne modifie en rien les limites et le contenu des DLSDU et
n’impose aucune contrainte au contenu de ces DLSDU;
NOTE - La longueur d’une DLSDU peut se trouver limitée du fait des mecanismes utilises par le protocole de
liaison de donnees (voir la Rec. UIT-T X.200 I ISOKEI 749%1,7.6.3.5.2).
d) un moyen pour l’utilisateur du DLS destinataire de contrôler la cadence à laquelle l’utilisateur du DLS
expéditeur peut envoyer des DLSDU;
e) la possibilité d’utiliser un service de réinitialisation pour remettre la DLC dans un état défini et
synchroniser les activités des deux utilisateurs du DLS;
f) la libération inconditionnelle, et donc éventuellement destructive, d’une DLC, soit par l’un des utilisateurs
du DLS, soit par le prestataire du DLS.
9 Modèle du service de liaison de données en mode connexion
La présente Recommandation I Norme internationale utilise le modele abstrait de service d’une couche défini à l’article 4
de la Rec. UIT-T X.210 I ISOKEI 10731. Ce modèle définit les interactions entre les utilisateurs et le fournisseur
du DLS, qui ont lieu aux deux DLSAP. Les informations sont echangees entre l’utilisateur et le fournisseur du DLS au
moyen de primitives de service, qui peuvent transporter des parametres.
4 Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
91 0 Identification d’extrémité de connexion de liaison de données
Si un utilisateur du DLS doit faire la distinction entre plusieurs DLC en un même DLSAP, il faut prévoir un mécanisme
local d’identification d’extrémité de la connexion. Toutes les primitives émises au DLSAP considéré dans le cadre d’une
DLC seraient tenues d’utiliser ce mécanisme pour identifier la DLC. Cette identification implicite n’est pas décrite dans
la présente Recommandation I Norme internationale.
Modèle d’une connexion de liaison de données
92 0
La fonction de contrôle de flux, exercee entre les deux extremités d’une DLC, établit une relation entre le comportement
de l’utilisateur du DLS qui reçoit des données à une extrémité et l’aptitude de son homologue, a l’autre extrémité, à
expédier des donnees. Le modele de files d’attente d’une DLC, decrit dans les paragraphes suivants, est utilisé pour
spécifier les caractéristiques de ce contrôle de flux et ses relations avec les autres capacités fournies par le DLS en mode
connexion.
Ce modèle de files d’attente d’une DLC est développé à seule fin d’aider à la compréhension des caractéristiques du
service de bout en bout, telles qu’elles sont perçues par les utilisateurs du DLS. Ce modèle n’est pas destiné à se
substituer à une description formelle précise du DLS, ni a une spécification complète de tous les enchaînements autorisés
de primitives du DLS. (Les enchaînements autorises de primitives sont spécifies a l’article 11. Voir également la Note
ci-après.) En outre, ce modèle ne vise pas à décrire toutes les fonctions ou opérations des entités DL qui sont utilisées
pour fournir le DLS. Il n’implique aucune spécification de réalisation du DLS et n’impose pas de contraintes quant à
cette réalisation.
NOTE - Les m6canismes internes qui interviennent dans le fonctionnement du DLS ne sont pas visibles à l’utilisateur de ce
service. En plus des interactions entre primitives de service decrites dans ce modele (par exemple, Mmission d’une primitive de
demande DL-RESET en un DLSAP peut empêcher la réception par l’utilisateur homologue du DLS d’une primitive d’indication
DL-DATA correspondant a une demande de donnees de DL précédente), il peut y avoir également:
des contraintes susceptibles de limiter, au niveau local, la capacité d’appeler les primitives;
a>
b) des procédures de service imposant des contraintes d’enchaînement particulieres à certaines primitives.
9.2.1 Principes du modèle de files d’attente
Le modèle de files d’attente représente de façon abstraite le fonctionnement d’une DLC par deux files d’attente reliant les
deux DLSAP. Une file d’attente est associée à chaque sens de transfert d’information (voir la Figure 1).
utilisateur A de DLS utilisateur B de DLS
DLSAP DLSAP
A A
file d’attente de A vers B
file d’attente de B vws A
fournisseur du service de liaison de donn6es
I
TO721770-95/dO2
Figure 1 - Modèle de files d’attente d’une connexion de liaison de données
Chaque file d’attente représente une fonction de contrôle de flux qui s’exerce dans un sens de transfert. La possibilité qu’a
un utilisateur du DLS d’ajouter des objets dans une file d’attente est déterminée par le comportement de l’autre utilisateur
qui retire des objets de la même file d’attente et par l’état de cette file d’attente. L’introduction d’objets dans une file
d’attente et l’extraction d’objets de celle-ci résultent des interactions au niveau des deux DLSAP.
On considère qu’une paire de files d’attente est disponible pour chaque DLC potentielle.
Les objets pouvant être placés dans une file d’attente par un utilisateur du DLS (voir les articles 12 à 14) sont:
un objet relatif à la connexion, représentant une primitive de demande ou de réponse DL-CONNECT et
a>
ses paramètres;
b) un objet relatif aux données, représentant une primitive de demande DL-DATA et ses paramètres;
Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
c) un objet relatif a la réinitialisation, représentant une primitive de demande ou de réponse DL-RESET et
ses paramètres;
d) un objet relatif à la déconnexion, représentant une primitive de demande DL-DISCONNECT et ses
paramètres.
Les objets qui peuvent être placés dans une file d’attente par le fournisseur du DLS (voir les articles 12 à 14) sont:
1) un objet relatif à la reinitialisation;
un repère de synchronisation (voir 9.2.4);
2)
3) un objet relatif à la déconnexion.
Par définition, les files d’attente ont les propriétes générales suivantes:
une file d’attente est vide jusqu’à ce qu’un objet relatif à la connexion y soit introduit; elle peut être remise
dans cet état, avec perte de son contenu, par le fournisseur du DLS;
ii) les objets sont introduits dans une file d’attente l’utilisateur du DLS source, sous le contrôle du
Par
introduits par le
fournisseur du DLS; des objets peuvent également être fournisseur du DLS;
iii) les objets sont retirés de la file d’attente sous le contrôle de l’utilisateur du DLS destinataire;
les objets sont normalement retirés dans l’ordre ou ils ont été introduits (voir toutefois 9.2.3);
iv)
une file d’attente a une capacité limitée, mais cette capacité n’est pas nécessairement fixée ni determinable.
9.2.2 Etablissement de connexion de liaison de données
Une paire de files d’attente est associée à une DLC entre deux DLSAP, lorsque le fournisseur du DLS reçoit une
primitive de demande DL-CONNECT au niveau de l’un des DLSAP et qu’un objet relatif à la connexion est introduit
dans l’une des files d’attente. Pour les utilisateurs de la DLC, ces files d’attente demeurent associées à cette DLC jusqu’à
ce qu’un objet relatif à la déconnexion (représentant une primitive de demande ou d’indication DL-DISCONNECT) soit
introduit ou retiré de la file d’attente.
Si un «utilisateur du DLS A» engage l’Établissement d’une DLC en introduisant un objet relatif à la connexion
(représentant une primitive de demande DL-CONNECT) dans la file d’attente de l’utilisateur A vers l’utilisateur B, alors
l’utilisateur A n’est autorisé à introduire dans la file d’attente aucun autre objet relatif à la déconnexion, tant que l’objet
relatif à la connexion (représentant la primitive de confirmation DL-CONNECT) n’a pas été retire de la file d’attente de
l’utilisateur B vers l’utilisateur A. Dans cette file d’attente, des objets ne peuvent être introduits qu’après que
l’utilisateur B a introduit un objet relatif à la connexion, représentant une primitive de réponse DL-CONNECT.
Les proprietes des files d’attente pendant l’existence de la DLC correspondent à l’accord établi entre les utilisateurs et le
fournisseur du service DLS au cours de la procédure d’établissement de cette connexion en ce qui concerne la qualité de
service.
9.2.3 Transfert de données
Le contrôle de flux exerce sur la DLC est représenté dans ce modele de files d’attente par la gestion de la capacité de la
file d’attente: cette gestion de la capacité autorise l’addition d’objets aux files d’attente. L’addition d’un certain objet est
susceptible d’empêcher l’addition d’un autre objet.
Des paires d’objets adjacents se trouvant en file d’attente peuvent être manipulées par le fournisseur du DLS, à des fins
de suppression. Un objet peut être supprimé si et seulement si l’objet suivant est défini comme étant destructif à l’égard
de celui qui le précède. Le dernier objet de la file d’attente est supprimé, si nécessaire, pour permettre l’introduction d’un
objet destructif - un objet destructif peut donc toujours être ajouté à la file d’attente. Les objets relatifs à la déconnexion
sont par définition destructifs à l’égard de tous les autres objets. Par définition, les objets relatifs à la réinitialisation sont
destructifs à l’égard de tous les autres objets, sauf ceux relatifs à la connexion et à la déconnexion.
Les relations entre objets déterminant les possibilités de manipulations de type ci-dessus sont récapitulées dans le
Tableau 1.
Le comportement des utilisateurs de la DLC et la QS adoptée pour celle-ci déterminent si le fournisseur du DLS effectue
ou non des actions se traduisant par des suppressions. En général, si des objets n’ont pas été retires de la file d’attente par
un utilisateur du service DLS, le fournisseur du service effectue, après un certain délai non spécifié, toutes les
suppressions autorisées.
6 Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
Tableau 1 - Relations entre objets de modèle de files d’attente
relation entre
l’objet y
relatif a la relatif a la repère de relatif à la
donnees
connexion
reinitialisation synchronisation deconnexion
et l’objet x
précédent
relatif à la connexion NIA NIA
DES
NIA
donnees DES NIA DES
relatif à la reinitialisation NIA DES DES
rep&e de synchronisation NIA DES NIA DES
relatif a la déconnexion NIA NIA 1 NIA NIA DES
I I I I 1 I
NIA x ne peut précéder y dans un État valide d’une file d’attente
l’objet n’est ni destructif a l’égard de l’autre objet, ni capable de le dépasser
DES destructif à l’égard de l’objet précédent
9.2.4 Réinitialisation
Pour modéliser avec précision le service de réinitialisation, il faut disposer d’un objet «repère de synchronisation». Cet
objet a les propriétés suivantes:
a) il ne peut pas être retire d’une file d’attente par un utilisateur du DLS;
b) une file d’attente est considérée comme vide par un utilisateur quand l’objet suivant dans cette file
d’attente est un objet «repère de synchronisation»;
un objet «repère de synchronisation» peut être détruit par un objet relatif a la déconnexion (voir le
C)
Tableau 1);
d) quand un objet relatif à la réinitialisation est précédé immediatement par un objet «repère de
synchronisation», les deux objets sont supprimés de la file d’attente.
Le déclenchement d’une procédure de réinitialisation est représenté dans les deux files d’attente comme suit:
i) le déclenchement d’une procédure de réinitialisation par le fournisseur du DLS est représenté par
l’introduction dans chacune des files d’attente d’un objet relatif à la réinitialisation, suivi d’un objet «repère
de synchronisation»;
ii) le déclenchement d’une procédure de réinitialisation par un utilisateur du DLS est représenté par
l’addition, par le fournisseur du DLS, d’un objet relatif à la réinitialisation dans la file d’attente allant de
celui qui a déclenché la réinitialisation vers l’utilisateur homologue du DLS, et par l’insertion dans l’autre
file d’attente d’un objet relatif à la réinitialisation suivi d’un objet «repère de synchronisation».
A moins qu’il ne soit détruit par un objet relatif à la déconnexion, un objet “repère de synchronisation» demeure dans la
file d’attente jusqu’à ce que l’objet qui le suit soit un objet relatif à la réinitialisation. Cet objet relatif à la réinitialisation
et l’objet «repère de synchronisation» sont alors tous deux supprimés par le fournisseur du DLS.
NOTE - Des restrictions concernant l’émission de certains types de primitives sont associées au déclenchement d’une
procédure de réinitialisation. Elles se traduisent par des limitations portant sur l’introduction de certains types d’objets dans la file
d’attente tant que la procédure de reinitialisation n’est pas terminée (voir 14.2.3).
9.2.5 Libération de connexion de liaison de données
L’introduction dans une file d’attente d’un objet relatif à la déconnexion, qui peut avoir lieu à tout moment, représente
l’engagement d’une procédure de libération de connexion de DLC. Cette procédure peut être destructive à l’égard des
objets se trouvant déjà dans les deux files d’attente et entraîner éventuellement le vidage des files d’attente et leur
dissociation de la DLC.
L’insertion d’un objet relatif à la déconnexion peut également représenter le refus ou l’échec d’une tentative
d’établissement de DLC. Dans ces cas, si un objet relatif a la connexion représentant une primitive de demande
DL-CONNECT est supprimé par un objet relatif à la déconnexion, ce dernier est également supprimé. L’objet relatif à la
déconnexion n’est pas supprimé quand il supprime tout autre objet, y compris dans le cas où il supprime un objet relatif à
la connexion représentant une primitive de réponse DL-CONNECT.
Rec. UIT-T X.212 (1995 F)
ISO/CEI 8886 : 1996 (F)
10 Qualité du service de liaison de données en mode connexion
L’expression «qualité de service» (QS) se rapporte à certaines caracteristiques d’une DLC, telles qu’elles sont observées
entre ses extrémités. Les caracteristiques d’une DLC décrites par la QS relèvent de la seule responsabilité du fournisseur
du DLS.
Quand une DLC est établie, les utilisateurs du DLS aux deux extrémités ont les mêmes connaissances et interprétations
de la QS offerte sur la DLC.
10.1 Détermination de la QS pour le service avec-connexion
La QS est déterminée en termes de paramètres de QS. Ces paramètres permettent aux utilisateurs du DLS de disposer
d’une méthode pour specifïer leurs exigences, et au fournisseur du DLS de disposer d’une base pour le choix du
protocole.
Les paramètres de QS du DLS se répartissent en deux types, selon la façon dont leurs valeurs sont déterminées:
a) ceux qui peuvent être choisis pour chaque connexion au cours de la phase d’établissement d’une DLC;
b) ceux qui ne sont pas choisis au cours de l’Établissement de la DLC mais dont les valeurs sont connues par
d’autres méthodes.
Trois paramètres de QS du service de liaison de données, le «débit», la «protection» et la «priorité» (tels que définis
respectivement aux 10.2.1, 10.2.5 et 10.2.6) sont du type de ceux qui peuvent être choisis lors de l’établissement de
la DLC. Les procédures de choix de ces paramètres sont décrites en détail au 12.2.5. Quand la DLC est établie, et
pendant toute sa durée de vie, les valeurs des paramètres QS adoptées ne peuvent être «rechoisies» à aucun moment, et il
n’est pas garanti que les valeurs d’origine soient conservées. L’utilisateur du DLS doit également être averti que les
modifications de QS d’une DLC ne sont pas signalées explicitement par le fournisseur du DLS.
Les autres caractéristiques de la QS qui correspondent à des paramètres, mais qui ne donnent pas lieu à un choix au
cours de l’établissement de DLC, sont le temps de transit, le taux d’erreur résiduel et la robustesse (comme cela est défini
dans les paragraphes 10.2.2 à 10.2.4). Les valeurs de ces paramètres pour une DLC donnée sont déterminées par d’autres
méthodes.
Si le choix est permis, certaines mesures de la QS sont demandées par l’utilisateur d’origine du DLS lorsque l’action
primitive de demande DL-CONNECT est engagée sur la DLC. Les mesures (ou valeurs de paramètres et options)
demandees sont fondées sur la connaissance a priori, par l’utilisateur du DLS, du ou des services mis à sa disposition par
le fournisseur du DLS. La connaissance des caracteristiques et le type de service fourni (les paramètres, formats et
options qui ont une influence sur le transfert des données) sont mis à la disposition d’un utilisateur du DLS par le moyen
d’une interaction de gestion de couche préalablement à (tout) appel du service de liaison de données en mode connexion.
De cette manière, l’utilisateur obtient une connaissance explicite des caractéristiques du service qu’il peut s’attendre à
recevoir pour chaque appel du service.
Le fournisseur du service de liaison de donnees peut aussi donner des informations sur la qualité du service actuelle, que
l’utilisateur accede a ce service ou pas. Cet aspect apparemment dynamique de la détermination de la QS n’est pas une
négociation; il s’agit de la fourniture de renseignements sur les caractéristiques du service, indépendamment de toute
instance d’appel du service.
Définition des paramètres de QS en mode connexion
10.2
Les paramètres de QS peuvent être classés de la manière suivante:
a) les paramètres qui expriment des performances du DLS, indiqués dans le Tableau 2;
b) les param&res qui expriment d’autres caractéristiques du DLS, indiqués dans le Tableau 3.
NOTE - Certains paramètres de QS sont definis en termes d’émission des primitives du DLS. La spécification d’une
primitive du DLS se rapporte h l’exkcution complète de cette primitive au DLSAP correspondant.
Tableau 2 - Classification des paramètres de QS relatifs aux performances du service
critère de performance
rapidité
prkision/fiabilité
debit taux d’erreur residuel (altération, duplication ou perte de donnees)
temps de transit probabilité de rupture de connexion
8 Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
Tableau 3 - Paramètres de QS non relatifs à la performance du service
protection
priorité
L
10.2.1 Débit
Le débit est défini par le nombre total de bits de DLSDU transferes avec SUC&S par un enchaînement de primitives de
demande DL-DATA/d’indication DL-DATA, divisé par le temps entréekortie correspondant à cet enchaînement.
Par définition, un transfert de bits dans une DLSDU transmise est réussi si les bits sont remis à l’utilisateur du DLS
destinataire prévu, sans erreur, en bon ordre et avant la libération de la DLC par cet utilisateur de DLS destinataire.
Pour un enchaînement de primitives de demande DL-DATA/d’indication DL-DATA, le temps entreekortie est le plus
grand des deux temps suivants:
le temps qui s’écoule entre la première et la dernière demande DL-DATA de l’enchaînement;
b) le temps qui s’écoule entre la première et la dernière indication DL-DATA de l’enchaînement.
Le débit n’a un sens que pour une suite de DLSDU complètes.
Le débit est spécifie indépendamment pour chaque sens de transfert. En général, chaque spécification de débit définit la
valeur «cible» et la valeur minimale acceptable (ou plus faible QS acceptable) désirées pour une DLC. Chaque
spécification représente un taux moyen, basé sur une taille moyenne de DLSDU indiquée préalablement.
susceptibles d’introduire des retards excessifs dans l’entrée ou la sortie d’une suite de
Les utilis
...

NORME lSO/CEI
INTERNATIONALE
Deuxième édition
1996-09-I 5
Technologies de l’information -
Interconnexion de systèmes ouverts
(OSI) - Définition du service de liaison de
données
Open Systems In terconnection - Data link
Informa tien technolog y -
service definition
Numéro de référence
ISO/CEI 8886:1996(F)
ISOKEI 8886: 1996(F)
Sommaire
Page
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Domaine d’application
...................................................................................................................................
2 Références normatives
...................................................................... 1
2.1 Recommandations I Normes internationales identiques
......................................................................................................................................................
3 Définitions
3.1 Définitions du modèle de référence OS1 .
................................................................................
32 Définitions relatives aux conventions de service
Définitions relatives au service de liaison de données .
3:3
4 Abréviations . . . . . . .~.~~~~~.~.~.~.~.~.
....................................................................................................................................................
5 Conventions
Conventions génerales .
...........................................................................................................................................
5:2 Paramètres
Présentation du service de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Types et classes pour le service de liaison de données
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Caractéristiques du service de liaison de données en mode connexion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modéle du service de liaison de données en mode connexion
Identification d’extrémité de connexion de liaison de données . . . . . . . .C.
91 .
Modèle d’une connexion de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
92 .
.......................................................................
10 Qualité du service de liaison de données en mode connexion
....................................................................
10.1 Détermination de la QS pour le service avec connexion
........................................................................
10.2 Définition des param&res de QS en mode connexion
..........................................................................................................................
11 Enchdnement des primitives
..................... 10
11.1 Concepts utilisés pour améliorer le service de liaison de données en mode connexion
....................................................................... 11
11.2 Contraintes imposées à l’enchaînement des primitives
...............................................................................................................
12 Phase d’établissement de connexion
12.1 Fonction .
......................................................................................... 14
12.2 Types de primitives et paramètres associés
................................................................................................................ 15
12.3 Enchaînement de primitives
0 ISOKEI 1996
Droits de reproduction réservés. Sauf prescription différente, aucune partie de cette publication ne
peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou
mécanique, y compris la photocopie et les microfilms, sans l’accord écrit de l’éditeur.
ISO/CEI Copyright Office l Case postale 56 l CH-121 1 Genève 20 l Suisse
Version française tirée en 1997
Imprimé en Suisse
ii
@ ISOKEI ISOKEI 8886: 1996(F)
Phase de liberation de connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1 Fonction . . . . . . . . . . . . . . . . . . . . . . .*. 15
13.2 Types de primitives et paramètres associés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13.3 Enchaînement de primitives échangées au moment de la liberation d’une connexion de liaison de
données établie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.4 Enchaînement de primitives correspondant au rejet, par un utilisateur du service de liaison de
données, d’une tentative d’établissement de connexion de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.5 Enchaînement de primitives correspondant au rejet, par le fournisseur du service de liaison de
données, d’une tentative d’établissement de connexion de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
13.6 Enchamement de primitives correspondant à la coupure, par un utilisateur du service de liaison de
données, d’une tentative d’établissement de liaison de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14 Phase de transfert de données 19
14.1 Transfert de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.2 Service de reinitialisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Fonctionnalités du service de liaison de données en mode sans connexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
............................................................... 23
16 Modèle du service de liaison de donnees en mode sans connexion
................. 23
16.1 Modèle d’une transmission de données en mode sans connexion sur liaison de données.
...................................................................................................
17 Qualité du service en mode sans connexion
......................................................
17.1 Détermination de la QS pour le service en mode sans connexion
................................................................ 24
’
17.2 Définition des param&res de QS en mode sans connexion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
18 Enchaînement de primitives en mode sans connexion au niveau d’un DLSAP
......................................................................................................................................
19 Transfert de données
19.1 Fonction .
.........................................................................................
19.2 Types de primitives et paramètres associes
19.3 Enchaînement de primitives .
. . .
ISOKEI 8886: 1996(F) @ ISOKEI
Avant-propos
LIS0 (Organisation internationale de normalisation) et la CE1 (Commission
électrotechnique internationale) forment ensemble un système consacré à la
normalisation internationale considérée comme un tout. Les organismes nationaux
membres de 1’ISO ou de la CE1 participent au développement de Normes inter-
nationales par l’intermédiaire des comités techniques créés par l’organisation
concernée afin de s’occuper des différents domaines particuliers de l’activité
technique. Les comités techniques de 1’ISO et de la CE1 collaborent dans des
domaines d’intérêt commun. D’autres organisations internationales, gouverne-
mentales ou non gouvernementales, en liaison avec 1’ISO et la CE1 participent
également aux travaux.
Dans le domaine des technologies de l’information, I’ISO et la CE1 ont créé un
comité technique mixte, I’ISOKEI JTC 1. Les projets de Normes internationales
adoptés par le comité technique mixte sont soumis aux organismes nationaux pour
approbation, avant leur acceptation comme Normes internationales. Les Normes
internationales sont approuvées conformément aux procédures qui requièrent
l’approbation de 75 % au moins des organismes nationaux votants.
La Norme internationale ISOKEI 8886 a été élaborée par le comité technique
mixte ISOKEI JTC 1, Technologies de l’information, sous-comité SC 6, TéLé-
informatique, en collaboration avec l’UIT-T. Le texte identique est publié en tant
que Recommandation UIT-T X.2 12.
Cette deuxième édition annule et remplace la première édition (ISO/CEI 8886: 1992),
qui a fait l’objet d’une révision technique.
1v .
@ ISOKEI ISOKEI 8886: 1996(F)
Introduction
La présente Recommandation I Norme internationale appartient à une série de Recommandations I Normes
internationales élaborées pour faciliter l’interconnexion de systèmes de traitement de l’information. Elle appartient à un
ensemble de Recommandations I Normes internationales dont les relations sont définies par la Rec. UIT-T X.200 I
ISOKEI 7498-1, modèle de référence OS1 - modèle de base. Le modèle décrit par la Rec. UIT-T X.200 I
ISOKEI 7498-l divise le domaine de la normalisation, en vue de l’interconnexion des systèmes ouverts (OSI), en une
série de couches de spécifications, dont chacune est d’une taille maîtrisable.
La présente Recommandation I Norme internationale définit le service fourni par la couche liaison de données à la
couche réseau, à la frontière entre ces deux couches du modèle de référence OSI. Elle fournit aux concepteurs de
protocoles de réseau une définition du service de liaison de données disponible pour la mise en œuvre du protocole de
réseau, et aux concepteurs de protocoles de liaison de données une définition des services devant être fournis par
l’intermédiaire du protocole de liaison de données à partir du service de la couche de niveau inférieur. Cette relation est
représentée à la Figure Intro. 1.
Dans le contexte de l’ensemble des Recommandations OS1 I Normes internationales, le terme «service» se réfère à la
capacité abstraite fournie par une couche du modèle de référence OS1 à la couche immédiatement supérieure. Le service
de liaison de donnees défini dans la présente Recommandation I Norme internationale est donc un service architectural
conceptuel, independant des divisions administratives.
couche utilise le setwice
protocole de r&eau
r6seau
de liaison de donMes
service de liaison de donn&s
fournit le service de liaison
protocole de liaison couche liaison
de donMes dedonnbes dedonn6es
TO721760-95/dOl
Figure Intro. 1 - Relation entre la présente Recommandation I Norme
internationale et d’autres Recommandations OS1 I Normes internationales

Page blanche
ISOKEI 8886 : 1996 (F)
NORME INTERNATIONALE
RECOMMANDATION UIT-T
TECHNOLOGIES DE L’INFORMATION - INTERCONNEXION DE SYSTÈMES
DÉFINITION DU SERVICE DE LIAISON DE DONNÉES
OUVERTS (OSI) -
Domaine d’application
Recommandation Norme internationale définit le service de liaison de données os1 sous forme
La présente
d’actions et d’événements spécifiés par les primitives de service;
a)
b) de paramètres associés à chaque primitive spécifiant une action ou un événement, et de la forme qu’ils
revêtent;
c) de relations entre ces actions et événements et d’enchaînements valides d’actions et d’événements.
Le principal objectif de la présente Recommandation I Norme internationale est de spécifier les caractéristiques d’un
service de liaison de données conceptuel et compléter, de ce fait, le modele de référence OS1 en fournissant des lignes
directrices pour l’élaboration de protocoles de liaison de données.
La présente Recommandation I Norme internationale ne spécifie pas de forme particulière de réalisations ou de produits,
et n’impose aucune contrainte de réalisation pour les entités de liaison de données et interfaces d’un système de
traitement de l’information.
Il n’est donc pas spécifie de conditions de conformité d’équipements à la présente Recommandation I Norme
internationale «Définition du service de liaison de données». Par contre, la conformité est obtenue par la mise en œuvre
de protocoles de liaison de données conformes à I’OSI, qui assurent le service de liaison de données défini dans la
présente Recommandation I Norme internationale.
2 Références normatives
Les Recommandations et Normes internationales suivantes contiennent des dispositions qui, par suite de la référence qui
y est faite, constituent des dispositions valables pour la présente Recommandation I Norme internationale. Au moment
de la publication, les éditions indiquées étaient en vigueur. Toutes Recommandations et Normes sont sujettes à révision
et les parties prenantes aux accords fondés sur la présente Recommandation I Norme internationale sont invitées à
rechercher la possibilité d’appliquer les éditions les plus récentes des Recommandations et Normes indiquées ci-après.
Les membres de la CE1 et de I’ISO possèdent le registre des Normes internationales en vigueur. Le Bureau de la
normalisation des télécommunications de I’UIT tient à jour une liste des Recommandations de I’UIT-T en vigueur.
21 Recommandations I Normes internationales identiques
-
Recommandation UIT-T X.200 (1994) I ISOKEI 7498-l: 1994 - Technologies de Z’information -
Interconnexion des systèmes ouverts - Modèle de référence de base: le modèle de référence de base.
-
Recommandation UIT-T X.210 (1993) I ISOKEI 1073 1: 1994 - Technologies de I?nformation -
Interconnexion des systèmes ouverts - Modèle de référence de base: conventions pour la définition des
services de l’interconnexion des systèmes ouverts.
Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
PARTIE 1 - GÉNÉRALITÉS
Définitions
Définitions du modèle de référence OS1
31 .
La présente Recommandation I Norme internationale est fondée sur les concepts élaborés dans la Rec. UIT-T X.200 I
ISOKEI 7498-l et utilise les termes suivants, qui y sont définis:
entité de liaison de données;
a)
b) couche liaison de données;
service de liaison de données;
C)
d) point d’accès au service de liaison de données;
e) adresse de point d’accès au service de liaison de données;
unite de données du service de liaison de données;
f)
g) réinitialisation.
Définitions relatives aux conventions de service
32 l
La présente Recommandation I Norme internationale utilise les termes et expressions suivants définis dans la
Rec. UIT-T X.210 I ISOKEI 10731, tels qu’ils s’appliquent à la couche liaison de données:
utilisateur du service de liaison de données;
a)
b) fournisseur du service de liaison de données;
c) primitive;
d) demande;
indication;
e)
réponse;
confirmation.
33 . Définitions relatives au service de liaison de données
La présente Recommandation I Norme internationale utilise les termes suivants:
connexion de liaison de données
a>
Association établie par une couche liaison de donnees entre deux ou plusieurs utilisateurs du service de
liaison de données pour le transfert de données, assurant l’identification explicite d’un ensemble de
transmissions de donnees sur la liaison de données, ainsi que l’acceptation concernant les services de
transmission de données sur la liaison de données devant être fournis audit ensemble.
Cette definition apporte des précisions à la définition donn6e dans la Rec. UIT-T X.200 I
NOTE -
ISOKEI 7498- 1.
b) transmission de données en mode avec connexion sur la liaison de données
Transmission d’une unité de données du service de liaison de données dans le contexte d’une connexion
de liaison de données établie précédemment.
c) transmission de données en mode sans connexion sur la liaison de données
Transmission d’une unité de données du service de liaison de données hors du contexte d’une connexion
de liaison de données et non nécessaire pour maintenir une relation logique quelconque entre des appels
multiples.
4 Abréviations
Pour les besoins de la présente Recommandation I Norme internationale, les abreviations suivantes sont utilisées.
DL Liaison de donnees (data Zink)
DLC Connexion de liaison de donnees (data link-connection)
Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
DLL Couche liaison de données (data link layer)
DLS Service de liaison de données (data link service)
DLSAP Point d’accès au service de liaison de donnees (data-Zink-service-access-point)
DLSDU Unité de données du service de liaison de données (data link-service-data-unit)
os1 Interconnexion des systèmes ouverts (open systems interconnection)
Qualite de service
QS
5 Conventions
Conventions générales
51 l
La présente Recommandation I Norme internationale utilise les conventions descriptives définies dans la
Rec. UIT-T X.210 I ISOKEI 10731.
les diagrammes d’enchaînement sont des descriptions purement
Le modèle d .u service, les primitives de service et
ne constituent pas une spécifi cation en v ‘ue d’une réalisation.
abstraites; i .lS
Paramètres
52 .
Les primitives de service, utilisées pour représenter les interactions entre utilisateur et fournisseur du service
(Rec. UIT-T X.210 I ISOKEI 10731), véhiculent des paramètres qui indiquent les informations disponibles pour
l’interaction entre l’utilisateur et le fournisseur.
Les paramètres associés à chaque groupe de primitives du service de liaison de données sont indiqués dans les tableaux
des articles 12 à 14 et 19. Les colonnes de ces tableaux correspondent aux primitives et les lignes aux paramètres. Les
parametres pouvant être associés à une primitive donnée sont indiqués par un «X» à l’intersection de la ligne et de la
colonne correspondantes.
Certains de ces «X» sont qualifiés par un élément entre parenthèses. Il peut s’agir
de contraintes spécifiques à un paramètre:
(=) indique que la valeur fournie dans une primitive d’indication ou de confirmation est toujours identique
à celle fournie dans la précédente primitive de demande ou de repense émise au niveau du point d’accès
au service homologue;
d’indication de renvoi à une note concernant cette case du tableau:
b)
(voir la Note X) indique que la note en référence contient des informations supplémentaires concernant le
paramètre et son utilisation.
donnée. Certains
Il n’est pas nécess #aire que tou .s les paramètres soient explicitement présents pour une interface
implicitement au DLSAP au niveau duquel la primitive est émise.
paramètres peuvent être associés
6 Présentation du service de liaison de données
Le DLS assure le transfert transparent et fiable de données entre utilisateurs du DLS. Il leur rend invisible la façon dont
les ressources de communication mises en œuvre sont utilisées pour réaliser ce transfert.
Le DLS assure en particulier
a) l’indépendance par rapport à la couche physique sous-jacente - Le DLS dégage les utilisateurs de ce
service de toute préoccupation concernant la configuration disponible (par exemple, connexion point à
point) ou les moyens physiques utilisés (par exemple, transmission semi-duplex);
b) la transparence des informations transférées - Le DLS assure le transfert transparent de données de
l’utilisateur du DLS. Il n’impose aucune restriction quant au contenu, au format ou au codage des
informations, et n’a même pas besoin d’interpréter leur structure ou leur signification;
c) le transfert fiable des données - Le DLS met les utilisateurs de ce service à l’abri des pertes, insertions,
mutilations ou, le cas échéant, d’altérations de l’ordre des données. Dans certains cas d’impossibilité de
reprise sur erreur dans la couche liaison de données, il peut se produire un dédoublement ou une perte
de DLSDU;
NOTE 1 - La dkction des DLSDU d6doublées ou perdues peut être effectuh par les utilisateurs du DLS.
Rec. UIT-T X.212 (1995 F) 3
ISOKEI 8886 : 1996 (F)
d) le choix de la qualité de service - Le DLS offre aux utilisateurs la possibilité de demander ou d’accepter
une certaine qualité de service pour le transfert de données. La qualité de service est spécifiée par des
paramètres de QS exprimant des caractéristiques telles que le débit, le temps de transit, l’exactitude et la
fiabilité;
e) adressage - Le DLS permet à l’utilisateur de s’identifier et d’indiquer le DLSAP à destination duquel une
DLC doit être etablie, chaque fois que plus de deux DLSAP sont acceptés par le fournisseur du DLS. Les
adresses de liaison de données n’ont qu’une signification locale à l’intérieur d’une configuration spécifique
de liaison de donnees, sur un support de transmission unique (connexion physique point à point ou
multipoint) ou sur un faisceau de supports de transmission parallèles (multiliaison ou fonction
d’éclatement). En conséquence, il n’est pas opportun de définir une structure d’adressage globale.
NOTE 2 - Le DLS est tenu de faire la distinction entre les divers systèmes reliés physiquement ou logiquement
à une liaison de donnees multipoint et également la distinction entre des connexions dans le cas où la couche liaison
de données possède une fonction de multiplexage. Aux fins de la communaute de conception avec les définitions
d’autres services, ce mécanisme est appelé adressage et les objets servant à faire la distinction entre des systemes sont
appelés adresses.
7 Types et classes pour le service de liaison de données
défini de classes distinctes pour le service de liaison de données. Il existe deux de service de liaison
Il n’a pas été
types
de données:
un service en mode connexion (défini dans la Partie 2);
un service en mode sans connexion (défini dans la Partie 3).
b)
Lorsqu’il fait référence à la présente Recommandation I Nom .e international un utilisateur ou un fournisseur du
es,
service de liaison de données doit indiquer quel type de ser vice il entend utiliser ou fournir.
PARTIE 2 - DÉFINITION DU SERVICE EN MODE CONNEXION
8 Caractéristiques du service de liaison de données en mode connexion
Le DLS offre les possibilités suivantes à ses utilisateurs:
a) le moyen pour un utilisateur du DLS d’établir une DLC avec un autre utilisateur, afin d’échanger des
DLSDU;
b) le moyen de convenir, entre l’utilisateur demandeur et le fournisseur du DLS, une certaine qualité de
service associee à chaque DLC;
c) le moyen de transférer des DLSDU de longueur limitée sur une connexion de liaison de données. Le
transfert des DLSDU est transparent: le DLS ne modifie en rien les limites et le contenu des DLSDU et
n’impose aucune contrainte au contenu de ces DLSDU;
NOTE - La longueur d’une DLSDU peut se trouver limitée du fait des mecanismes utilises par le protocole de
liaison de donnees (voir la Rec. UIT-T X.200 I ISOKEI 749%1,7.6.3.5.2).
d) un moyen pour l’utilisateur du DLS destinataire de contrôler la cadence à laquelle l’utilisateur du DLS
expéditeur peut envoyer des DLSDU;
e) la possibilité d’utiliser un service de réinitialisation pour remettre la DLC dans un état défini et
synchroniser les activités des deux utilisateurs du DLS;
f) la libération inconditionnelle, et donc éventuellement destructive, d’une DLC, soit par l’un des utilisateurs
du DLS, soit par le prestataire du DLS.
9 Modèle du service de liaison de données en mode connexion
La présente Recommandation I Norme internationale utilise le modele abstrait de service d’une couche défini à l’article 4
de la Rec. UIT-T X.210 I ISOKEI 10731. Ce modèle définit les interactions entre les utilisateurs et le fournisseur
du DLS, qui ont lieu aux deux DLSAP. Les informations sont echangees entre l’utilisateur et le fournisseur du DLS au
moyen de primitives de service, qui peuvent transporter des parametres.
4 Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
91 0 Identification d’extrémité de connexion de liaison de données
Si un utilisateur du DLS doit faire la distinction entre plusieurs DLC en un même DLSAP, il faut prévoir un mécanisme
local d’identification d’extrémité de la connexion. Toutes les primitives émises au DLSAP considéré dans le cadre d’une
DLC seraient tenues d’utiliser ce mécanisme pour identifier la DLC. Cette identification implicite n’est pas décrite dans
la présente Recommandation I Norme internationale.
Modèle d’une connexion de liaison de données
92 0
La fonction de contrôle de flux, exercee entre les deux extremités d’une DLC, établit une relation entre le comportement
de l’utilisateur du DLS qui reçoit des données à une extrémité et l’aptitude de son homologue, a l’autre extrémité, à
expédier des donnees. Le modele de files d’attente d’une DLC, decrit dans les paragraphes suivants, est utilisé pour
spécifier les caractéristiques de ce contrôle de flux et ses relations avec les autres capacités fournies par le DLS en mode
connexion.
Ce modèle de files d’attente d’une DLC est développé à seule fin d’aider à la compréhension des caractéristiques du
service de bout en bout, telles qu’elles sont perçues par les utilisateurs du DLS. Ce modèle n’est pas destiné à se
substituer à une description formelle précise du DLS, ni a une spécification complète de tous les enchaînements autorisés
de primitives du DLS. (Les enchaînements autorises de primitives sont spécifies a l’article 11. Voir également la Note
ci-après.) En outre, ce modèle ne vise pas à décrire toutes les fonctions ou opérations des entités DL qui sont utilisées
pour fournir le DLS. Il n’implique aucune spécification de réalisation du DLS et n’impose pas de contraintes quant à
cette réalisation.
NOTE - Les m6canismes internes qui interviennent dans le fonctionnement du DLS ne sont pas visibles à l’utilisateur de ce
service. En plus des interactions entre primitives de service decrites dans ce modele (par exemple, Mmission d’une primitive de
demande DL-RESET en un DLSAP peut empêcher la réception par l’utilisateur homologue du DLS d’une primitive d’indication
DL-DATA correspondant a une demande de donnees de DL précédente), il peut y avoir également:
des contraintes susceptibles de limiter, au niveau local, la capacité d’appeler les primitives;
a>
b) des procédures de service imposant des contraintes d’enchaînement particulieres à certaines primitives.
9.2.1 Principes du modèle de files d’attente
Le modèle de files d’attente représente de façon abstraite le fonctionnement d’une DLC par deux files d’attente reliant les
deux DLSAP. Une file d’attente est associée à chaque sens de transfert d’information (voir la Figure 1).
utilisateur A de DLS utilisateur B de DLS
DLSAP DLSAP
A A
file d’attente de A vers B
file d’attente de B vws A
fournisseur du service de liaison de donn6es
I
TO721770-95/dO2
Figure 1 - Modèle de files d’attente d’une connexion de liaison de données
Chaque file d’attente représente une fonction de contrôle de flux qui s’exerce dans un sens de transfert. La possibilité qu’a
un utilisateur du DLS d’ajouter des objets dans une file d’attente est déterminée par le comportement de l’autre utilisateur
qui retire des objets de la même file d’attente et par l’état de cette file d’attente. L’introduction d’objets dans une file
d’attente et l’extraction d’objets de celle-ci résultent des interactions au niveau des deux DLSAP.
On considère qu’une paire de files d’attente est disponible pour chaque DLC potentielle.
Les objets pouvant être placés dans une file d’attente par un utilisateur du DLS (voir les articles 12 à 14) sont:
un objet relatif à la connexion, représentant une primitive de demande ou de réponse DL-CONNECT et
a>
ses paramètres;
b) un objet relatif aux données, représentant une primitive de demande DL-DATA et ses paramètres;
Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
c) un objet relatif a la réinitialisation, représentant une primitive de demande ou de réponse DL-RESET et
ses paramètres;
d) un objet relatif à la déconnexion, représentant une primitive de demande DL-DISCONNECT et ses
paramètres.
Les objets qui peuvent être placés dans une file d’attente par le fournisseur du DLS (voir les articles 12 à 14) sont:
1) un objet relatif à la reinitialisation;
un repère de synchronisation (voir 9.2.4);
2)
3) un objet relatif à la déconnexion.
Par définition, les files d’attente ont les propriétes générales suivantes:
une file d’attente est vide jusqu’à ce qu’un objet relatif à la connexion y soit introduit; elle peut être remise
dans cet état, avec perte de son contenu, par le fournisseur du DLS;
ii) les objets sont introduits dans une file d’attente l’utilisateur du DLS source, sous le contrôle du
Par
introduits par le
fournisseur du DLS; des objets peuvent également être fournisseur du DLS;
iii) les objets sont retirés de la file d’attente sous le contrôle de l’utilisateur du DLS destinataire;
les objets sont normalement retirés dans l’ordre ou ils ont été introduits (voir toutefois 9.2.3);
iv)
une file d’attente a une capacité limitée, mais cette capacité n’est pas nécessairement fixée ni determinable.
9.2.2 Etablissement de connexion de liaison de données
Une paire de files d’attente est associée à une DLC entre deux DLSAP, lorsque le fournisseur du DLS reçoit une
primitive de demande DL-CONNECT au niveau de l’un des DLSAP et qu’un objet relatif à la connexion est introduit
dans l’une des files d’attente. Pour les utilisateurs de la DLC, ces files d’attente demeurent associées à cette DLC jusqu’à
ce qu’un objet relatif à la déconnexion (représentant une primitive de demande ou d’indication DL-DISCONNECT) soit
introduit ou retiré de la file d’attente.
Si un «utilisateur du DLS A» engage l’Établissement d’une DLC en introduisant un objet relatif à la connexion
(représentant une primitive de demande DL-CONNECT) dans la file d’attente de l’utilisateur A vers l’utilisateur B, alors
l’utilisateur A n’est autorisé à introduire dans la file d’attente aucun autre objet relatif à la déconnexion, tant que l’objet
relatif à la connexion (représentant la primitive de confirmation DL-CONNECT) n’a pas été retire de la file d’attente de
l’utilisateur B vers l’utilisateur A. Dans cette file d’attente, des objets ne peuvent être introduits qu’après que
l’utilisateur B a introduit un objet relatif à la connexion, représentant une primitive de réponse DL-CONNECT.
Les proprietes des files d’attente pendant l’existence de la DLC correspondent à l’accord établi entre les utilisateurs et le
fournisseur du service DLS au cours de la procédure d’établissement de cette connexion en ce qui concerne la qualité de
service.
9.2.3 Transfert de données
Le contrôle de flux exerce sur la DLC est représenté dans ce modele de files d’attente par la gestion de la capacité de la
file d’attente: cette gestion de la capacité autorise l’addition d’objets aux files d’attente. L’addition d’un certain objet est
susceptible d’empêcher l’addition d’un autre objet.
Des paires d’objets adjacents se trouvant en file d’attente peuvent être manipulées par le fournisseur du DLS, à des fins
de suppression. Un objet peut être supprimé si et seulement si l’objet suivant est défini comme étant destructif à l’égard
de celui qui le précède. Le dernier objet de la file d’attente est supprimé, si nécessaire, pour permettre l’introduction d’un
objet destructif - un objet destructif peut donc toujours être ajouté à la file d’attente. Les objets relatifs à la déconnexion
sont par définition destructifs à l’égard de tous les autres objets. Par définition, les objets relatifs à la réinitialisation sont
destructifs à l’égard de tous les autres objets, sauf ceux relatifs à la connexion et à la déconnexion.
Les relations entre objets déterminant les possibilités de manipulations de type ci-dessus sont récapitulées dans le
Tableau 1.
Le comportement des utilisateurs de la DLC et la QS adoptée pour celle-ci déterminent si le fournisseur du DLS effectue
ou non des actions se traduisant par des suppressions. En général, si des objets n’ont pas été retires de la file d’attente par
un utilisateur du service DLS, le fournisseur du service effectue, après un certain délai non spécifié, toutes les
suppressions autorisées.
6 Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
Tableau 1 - Relations entre objets de modèle de files d’attente
relation entre
l’objet y
relatif a la relatif a la repère de relatif à la
donnees
connexion
reinitialisation synchronisation deconnexion
et l’objet x
précédent
relatif à la connexion NIA NIA
DES
NIA
donnees DES NIA DES
relatif à la reinitialisation NIA DES DES
rep&e de synchronisation NIA DES NIA DES
relatif a la déconnexion NIA NIA 1 NIA NIA DES
I I I I 1 I
NIA x ne peut précéder y dans un État valide d’une file d’attente
l’objet n’est ni destructif a l’égard de l’autre objet, ni capable de le dépasser
DES destructif à l’égard de l’objet précédent
9.2.4 Réinitialisation
Pour modéliser avec précision le service de réinitialisation, il faut disposer d’un objet «repère de synchronisation». Cet
objet a les propriétés suivantes:
a) il ne peut pas être retire d’une file d’attente par un utilisateur du DLS;
b) une file d’attente est considérée comme vide par un utilisateur quand l’objet suivant dans cette file
d’attente est un objet «repère de synchronisation»;
un objet «repère de synchronisation» peut être détruit par un objet relatif a la déconnexion (voir le
C)
Tableau 1);
d) quand un objet relatif à la réinitialisation est précédé immediatement par un objet «repère de
synchronisation», les deux objets sont supprimés de la file d’attente.
Le déclenchement d’une procédure de réinitialisation est représenté dans les deux files d’attente comme suit:
i) le déclenchement d’une procédure de réinitialisation par le fournisseur du DLS est représenté par
l’introduction dans chacune des files d’attente d’un objet relatif à la réinitialisation, suivi d’un objet «repère
de synchronisation»;
ii) le déclenchement d’une procédure de réinitialisation par un utilisateur du DLS est représenté par
l’addition, par le fournisseur du DLS, d’un objet relatif à la réinitialisation dans la file d’attente allant de
celui qui a déclenché la réinitialisation vers l’utilisateur homologue du DLS, et par l’insertion dans l’autre
file d’attente d’un objet relatif à la réinitialisation suivi d’un objet «repère de synchronisation».
A moins qu’il ne soit détruit par un objet relatif à la déconnexion, un objet “repère de synchronisation» demeure dans la
file d’attente jusqu’à ce que l’objet qui le suit soit un objet relatif à la réinitialisation. Cet objet relatif à la réinitialisation
et l’objet «repère de synchronisation» sont alors tous deux supprimés par le fournisseur du DLS.
NOTE - Des restrictions concernant l’émission de certains types de primitives sont associées au déclenchement d’une
procédure de réinitialisation. Elles se traduisent par des limitations portant sur l’introduction de certains types d’objets dans la file
d’attente tant que la procédure de reinitialisation n’est pas terminée (voir 14.2.3).
9.2.5 Libération de connexion de liaison de données
L’introduction dans une file d’attente d’un objet relatif à la déconnexion, qui peut avoir lieu à tout moment, représente
l’engagement d’une procédure de libération de connexion de DLC. Cette procédure peut être destructive à l’égard des
objets se trouvant déjà dans les deux files d’attente et entraîner éventuellement le vidage des files d’attente et leur
dissociation de la DLC.
L’insertion d’un objet relatif à la déconnexion peut également représenter le refus ou l’échec d’une tentative
d’établissement de DLC. Dans ces cas, si un objet relatif a la connexion représentant une primitive de demande
DL-CONNECT est supprimé par un objet relatif à la déconnexion, ce dernier est également supprimé. L’objet relatif à la
déconnexion n’est pas supprimé quand il supprime tout autre objet, y compris dans le cas où il supprime un objet relatif à
la connexion représentant une primitive de réponse DL-CONNECT.
Rec. UIT-T X.212 (1995 F)
ISO/CEI 8886 : 1996 (F)
10 Qualité du service de liaison de données en mode connexion
L’expression «qualité de service» (QS) se rapporte à certaines caracteristiques d’une DLC, telles qu’elles sont observées
entre ses extrémités. Les caracteristiques d’une DLC décrites par la QS relèvent de la seule responsabilité du fournisseur
du DLS.
Quand une DLC est établie, les utilisateurs du DLS aux deux extrémités ont les mêmes connaissances et interprétations
de la QS offerte sur la DLC.
10.1 Détermination de la QS pour le service avec-connexion
La QS est déterminée en termes de paramètres de QS. Ces paramètres permettent aux utilisateurs du DLS de disposer
d’une méthode pour specifïer leurs exigences, et au fournisseur du DLS de disposer d’une base pour le choix du
protocole.
Les paramètres de QS du DLS se répartissent en deux types, selon la façon dont leurs valeurs sont déterminées:
a) ceux qui peuvent être choisis pour chaque connexion au cours de la phase d’établissement d’une DLC;
b) ceux qui ne sont pas choisis au cours de l’Établissement de la DLC mais dont les valeurs sont connues par
d’autres méthodes.
Trois paramètres de QS du service de liaison de données, le «débit», la «protection» et la «priorité» (tels que définis
respectivement aux 10.2.1, 10.2.5 et 10.2.6) sont du type de ceux qui peuvent être choisis lors de l’établissement de
la DLC. Les procédures de choix de ces paramètres sont décrites en détail au 12.2.5. Quand la DLC est établie, et
pendant toute sa durée de vie, les valeurs des paramètres QS adoptées ne peuvent être «rechoisies» à aucun moment, et il
n’est pas garanti que les valeurs d’origine soient conservées. L’utilisateur du DLS doit également être averti que les
modifications de QS d’une DLC ne sont pas signalées explicitement par le fournisseur du DLS.
Les autres caractéristiques de la QS qui correspondent à des paramètres, mais qui ne donnent pas lieu à un choix au
cours de l’établissement de DLC, sont le temps de transit, le taux d’erreur résiduel et la robustesse (comme cela est défini
dans les paragraphes 10.2.2 à 10.2.4). Les valeurs de ces paramètres pour une DLC donnée sont déterminées par d’autres
méthodes.
Si le choix est permis, certaines mesures de la QS sont demandées par l’utilisateur d’origine du DLS lorsque l’action
primitive de demande DL-CONNECT est engagée sur la DLC. Les mesures (ou valeurs de paramètres et options)
demandees sont fondées sur la connaissance a priori, par l’utilisateur du DLS, du ou des services mis à sa disposition par
le fournisseur du DLS. La connaissance des caracteristiques et le type de service fourni (les paramètres, formats et
options qui ont une influence sur le transfert des données) sont mis à la disposition d’un utilisateur du DLS par le moyen
d’une interaction de gestion de couche préalablement à (tout) appel du service de liaison de données en mode connexion.
De cette manière, l’utilisateur obtient une connaissance explicite des caractéristiques du service qu’il peut s’attendre à
recevoir pour chaque appel du service.
Le fournisseur du service de liaison de donnees peut aussi donner des informations sur la qualité du service actuelle, que
l’utilisateur accede a ce service ou pas. Cet aspect apparemment dynamique de la détermination de la QS n’est pas une
négociation; il s’agit de la fourniture de renseignements sur les caractéristiques du service, indépendamment de toute
instance d’appel du service.
Définition des paramètres de QS en mode connexion
10.2
Les paramètres de QS peuvent être classés de la manière suivante:
a) les paramètres qui expriment des performances du DLS, indiqués dans le Tableau 2;
b) les param&res qui expriment d’autres caractéristiques du DLS, indiqués dans le Tableau 3.
NOTE - Certains paramètres de QS sont definis en termes d’émission des primitives du DLS. La spécification d’une
primitive du DLS se rapporte h l’exkcution complète de cette primitive au DLSAP correspondant.
Tableau 2 - Classification des paramètres de QS relatifs aux performances du service
critère de performance
rapidité
prkision/fiabilité
debit taux d’erreur residuel (altération, duplication ou perte de donnees)
temps de transit probabilité de rupture de connexion
8 Rec. UIT-T X.212 (1995 F)
ISOKEI 8886 : 1996 (F)
Tableau 3 - Paramètres de QS non relatifs à la performance du service
protection
priorité
L
10.2.1 Débit
Le débit est défini par le nombre total de bits de DLSDU transferes avec SUC&S par un enchaînement de primitives de
demande DL-DATA/d’indication DL-DATA, divisé par le temps entréekortie correspondant à cet enchaînement.
Par définition, un transfert de bits dans une DLSDU transmise est réussi si les bits sont remis à l’utilisateur du DLS
destinataire prévu, sans erreur, en bon ordre et avant la libération de la DLC par cet utilisateur de DLS destinataire.
Pour un enchaînement de primitives de demande DL-DATA/d’indication DL-DATA, le temps entreekortie est le plus
grand des deux temps suivants:
le temps qui s’écoule entre la première et la dernière demande DL-DATA de l’enchaînement;
b) le temps qui s’écoule entre la première et la dernière indication DL-DATA de l’enchaînement.
Le débit n’a un sens que pour une suite de DLSDU complètes.
Le débit est spécifie indépendamment pour chaque sens de transfert. En général, chaque spécification de débit définit la
valeur «cible» et la valeur minimale acceptable (ou plus faible QS acceptable) désirées pour une DLC. Chaque
spécification représente un taux moyen, basé sur une taille moyenne de DLSDU indiquée préalablement.
susceptibles d’introduire des retards excessifs dans l’entrée ou la sortie d’une suite de
Les utilis
...