S. XUTO 200-TE-E.DOC CCITTREC.DOT 22.11.91
52
S. XUTO 200-TE-E.DOC CCITTREC.DOT 22.11.91
51
52 Fascicle VIII.4 - Rec. X.200
Fascicle VIII.4 - Rec. X.200 51
SECTION 1
MODEL AND NOTATION
Recommendation X.200
Fascicle VIII.4 – Rec. X.200
REFERENCE MODEL OF OPEN SYSTEMS INTERCONNECTION
FOR CCITT APPLICATIONS1)
The CCITT,
considering
(a) that Administrations in many countries are planning to
establish telecommunication services which exploit the networks now
existing or due to be available in the near future;
(b) that those services may be carried on different types of
networks;
(c) that users of these services need to communicate with
each other irrespective of the diversity of interconnected
networks;
(d) that methodical representation of network services will
further promote the effective and efficient use of networks;
(e) that accommodation of conflicting service requirements
and network constraints can be effected through the analysis of
service and network functions. This analysis should lead to a
universally applicable logical structure which may be used in the
development of compatible service, interface and procedure
definitions;
(f) that this structure should as far as possible
accommodate existing Recommendations to allow the steady evolution
of networks providing the new services;
(g) that close collaboration and liaison with other bodies
studying reference models is desirable to ensure the widest
possible applicability of resulting Recommendations,
unanimously recommends
that for CCITT applications:
(1) the methodical representation of new services be
undertaken in accordance with the principles and architecture of
this Recommendation;
(2) the structure of this reference model contained within
this Recommendation be employed in the specification of new
interface and procedural definitions;
(3) the user and Administration requirements for both
services and management of services can be satisfied by application
of the principles of this Recommendation.
CONTENTS
0 Introduction
1 Scope and field of application
2 Definitions
3 Notation
4 Introduction to Open Systems Interconnection (OSI)
4.1 Definitions
4.2 Open Systems Interconnection environment
4.3 Modelling the OSI environment
5 Concepts of a layered architecture
5.1 Introduction
5.2 Principles of layering
5.3 Communication between peer entities
5.4 Identifiers
5.5 Properties of service-access points
5.6 Data-units
5.7 Elements of layer operation
5.8 Routing
5.9 Management aspects of OSI
6 Introduction to the specific OSI layers
6.1 Specific layers
6.2 The principles used to determine the seven layers of the
Reference Model
6.3 Layer descriptions
7Detailed description of the resulting OSI architecture
7.1 Application layer
7.2 Presentation layer
7.3 Session layer
7.4 Transport layer
7.5 Network layer
7.6 Data link layer
7.7 Physical layer
Annex A - Brief explanation of how the layers were chosen
Annex B - Alphabetical index to definitions
0 Introduction
0.1 About this Recommendation
This Recommendation presents the purpose, framework and
function of a reference model structure (hereinafter called “the
Reference Model”) for the logical process in a communications
system. Instances of communication system elements that have been
defined using this Reference Model may be found in other
Recommendations.
Communications systems which employ the standardized
communication procedures and methods derived from the Reference
Model are referred to as “open systems”, and such interconnection
is referred to as “VOpen Systems Interconnection” (OSI). This
Reference Model is consistent with the principles established by
ISO for Open Systems Interconnection.
This Recommendation allows standardized procedures to be
defined enabling the interconnection and subsequent effective
exchange of information between users. Such users are systems;
i.e., a set of one or more computers, associated software,
peripherals, terminals, human operators, physical processes,
information transfer means, etc., that form an autonomous whole
capable of performing information processing and/or information
transfer. The Reference Model, in particular, will permit
interworking between different networks, of the same or different
types, to be defined such that communication may be achieved as
easily over a combination of networks as over a single network.
The term “user” implies nothing in respect to the contractual
customer-Administration relationship; a user may be either outside
the Administration or part of the Administration.
Conformance with the Reference Model does not imply any
particular implementation or technology, but rather refers to the
support of standardized information exchange procedures derived
according to its provisions as specified in this Recommendation.
The Recommendation provides neither details nor definitions or
interconnection protocols.
The Reference Model serves as a framework for the definition
of services and protocols which fit within the boundaries
established by the Reference Model. In those few cases where a
feature is explicitly marked as “optional” in the Reference Model,
it should remain optional in the corresponding service or protocol
(even if at a given instant the two cases of the option are not yet
documented).
1 Scope and field of application
1.1 The scope of the Reference Model
a)to specify a universally applicable logical structure
encompassing the requirements of CCITT applications;
b)to act as a reference during the development of new
communications services, including potential CCITT
recommended services, and the definition of the
corresponding procedures;
c)to enable different users to communicate with each other by
encouraging the compatible implementation of communication
features;
d)to enable the steady evolution of CCITT applications by
allowing sufficient flexibility so that advancements in
technology and expanding requirements of users can be
accommodated;
e)to allow comparison of a proposed new user requirement with
the services for existing user requirements, thus allowing
the new requirements to be satisfied in a manner compatible
with existing CCITT recommended services.
1.2 The application of the Reference Model
This model will be employed in the development of
interconnection protocols for communicating services, including
potential CCITT recommended services, as follows:
a)A new user requirement is first expressed in user oriented
terms. The requirement is then analyzed to determine the
underlying patterns which would allow it to be grouped into
functional subsets;
b)While the specification of a requirement will contain much
narrative text for clarification, there may also be a
requirement formally stated using a formal description
technique (FDT);
c)A set of service definitions and protocol specifications is
being written for each layer. Extensions and new uses of
OSI will be progressively incorporated as new CCITT X-
series Recommendations;
d)New functions that are identified will be incorporated into
the Reference Model to enhance its future applicability;
e)For new uses and applications of OSI where no appropriate
protocol is contained in the Recommendations, new
protocols, particularly for the application layer, will be
needed.
2 Definitions
Definitions of terms are included at the beginning of
individual divisions and sub-divisions. An index of these terms is
provided in an Annex B for easy reference.
3 Notation
Layers are introduced in division 5. An (N)-, (N + 1)-, and (N
- 1)-notation is used to identify and relate adjacent layers:
(N)-Layer: any specific layer;
(N + 1)-Layer: the next higher layer;
(N – 1)-Layer: the next lower layer.
This notation is also used for other concepts in the model
which are related to these layers, e.g. (N)-protocol, (N + 1)-
service.
Division 6 introduces names for individual layers. When
referring to these layers by name, the (N)-, (N + 1)- and (N – 1)-
prefixes are replaced by the names of the layers, e.g. transport-
protocol, session-entity and network-service.
4 Introduction to Open Systems Interconnection (OSI)
Note – The general principles described in divisions 4 and 5
hold for all layers of the Reference Model, unless layer specific
statements to the contrary are made in divisions 6 and 7.
4.1 Definitions
4.1.1real system
A set of one or more computers, the associated software,
peripherals, terminals, human operators, physical processes,
information transfer means, etc., that forms an autonomous whole
capable of performing information processing and/or information
transfer.
4.1.2real open system
A real system which complies with the requirements of OSI
Recommendations in its communication with other real systems.
4.1.3open system
The representation within the Reference Model of those aspects
of a real open system that are pertinent to OSI.
4.1.4application-process
An element within a real open system which performs the
information processing for a particular application.
4.2 Open Systems Interconnection environment
In the concept of OSI, a real system is a set of one or more
computers, associated software, peripherals, terminals, human
operators, physical processes, information transfer means, etc.,
that forms an autonomous whole capable of performing information
processing and/or information transfer.
An application-process is an element within an open system
which performs the information processing for a particular
application.
Application-processes can represent manual processes,
computerized processes or physical processes. Some examples of
application-processes that are applicable to this open system
definition are the following:
a)a person operating a banking terminal is a manual
application-process;
b)a FORTRAN program executing in a computer centre and
accessing a remote database is a computerized application-
process; the remote database management systems server is
also an application-process; and
c)a process control program executing in a dedicated computer
attached to some industrial equipment and linked into a
plant control system is a physical application-process.
OSI is concerned with the exchange of information between open
systems (and not the internal functioning of each individual real
open system).
As shown in Figure 1/X.200, the physical media for open
systems interconnection provides the means for the transfer of
information between open systems.
Note – At this point, only telecommunications media have been
considered. The use of other interconnection media is for further
study.
FIGURE 1/X.200
OSI is concerned only with interconnection of systems. All
other aspects of systems which are not related to interconnection
are outside the scope of OSI.
OSI is concerned not only with the transfer of information
between systems, i.e. transmission, but also with their capability
to interwork to achieve a common (distributed) task. In other
words, OSI is concerned with the interconnection aspects of
cooperation (see Note) between systems, which is implied by the
expression “systems interconnection”.
The objective of OSI is to define a set of Recommendations to
enable open systems to cooperate. A system which complies with the
requirements of applicable OSI Recommendations in its cooperation
with other systems is termed a real open system.
Note – Cooperation among open systems involves a broad range
of activities of which the following have been identified:
a)interprocess communication, which concerns the exchange of
information and the synchronization of activity between OSI
application-processes;
b)data representation, which concerns all aspects of the
creation and maintenance of data descriptions and data
transformations for reformatting data exchanged between
open systems;
c)data storage, which concerns storage media, and file and
database systems for managing and providing access to data
stored on the media;
d)process and resource management, which concerns the means
by which OSI application-processes are declared, initiated
and controlled, and the means by which they acquire OSI
resources;
e)integrity and security, which concerns information
processing constraints that must be preserved or assured
during the operation of the open systems; and
f)program support, which concerns the definition,
compilation, linking, testing, storage, transfer and access
to the programs executed by OSI application-processes.
Some of these activities may imply exchange of information
between the interconnected open systems and their interconnection
aspects may, therefore, be of concern to OSI.
This Recommendation covers the elements of OSI aspects of
these activities which are essential for early development of OSI
Recommendations.
4.3 Modelling the OSI environment
The development of OSI Recommendations, i.e., Recommendations
for the interconnection of real open systems, is assisted by the
use of abstract models. To specify the external behaviour of
interconnected real open systems, each real open system is replaced
by a functionally equivalent abstract model of a real open system
called an open system. Only the interconnection aspects of these
open systems would strictly need to be described. However, to
accomplish this, it is necessary to describe both the internal and
external behaviour of these open systems. Only the external
behaviour of open systems is retained as the standard of behaviour
of real open systems. The description of the internal behaviour of
open systems is provided in the Reference Model only to support the
definition of the interconnection aspects. Any real system which
behaves externally as an open system can be considered to be a real
open system.
This abstract modelling is used in two steps.
First, basic elements of open systems and some key decisions
concerning their organization and functioning, are developed. This
constitutes the Reference Model of Open Systems Interconnection
described in this Recommendation.
Then, the detailed and precise description of the functioning
of the open system is developed in the framework formed by the
Reference Model. This constitutes the services and protocols for
Open Systems Interconnection which are the subject of other
Recommendations.
It should be emphasized that the Reference Model does not, by
itself, specify the detailed and precise functioning of the open
system and, therefore, it does not specify the external behaviour
of real open systems and does not imply the structure of the
implementation of a real open system.
The reader not familiar with the technique of abstract
modelling is cautioned that those concepts introduced in the
description of open systems constitute an abstraction despite a
similar appearance to concepts commonly found in real systems.
Therefore real open systems need not be implemented as described by
the Model.
Throughout the remainder of this Recommendation, only the
aspects of real systems and application-processes which lie within
the OSI environment are considered. Their interconnection is
illustrated throughout this Recommendation as depicted in Figure
2/X.200.
FIGURE 2/X.200
5 Concepts of a layered architecture
5.1 Introduction
Division 5 sets forth the architectural concepts that are
applied in the development of the Reference Model of Open Systems
Interconnection. Firstly, the concept of a layered architecture
(with layers, entities, service-access-points, protocols,
connections, etc.) is described. Secondly, identifiers are
introduced for entities, service-access-points, and connections.
Thirdly, service-access-points and data-units are described.
Fourthly, elements of layer operation are described including
connections, transmission of data, and error functions. Then,
routing aspects are introduced and finally, management aspects are
discussed.
The concepts described in division 5 are those required to
describe the Reference Model of Open Systems Interconnection.
However, not all of the concepts described are employed in each
layer of the Reference Model.
Four elements are basic to the Reference Model (see Figure
2/X.200):
a)open systems;
b)the application-entities which exist within the Open
Systems Interconnection environment;
c)the connections (see § 5.3) which join the application-
entities and permit them to exchange information (see Note
1); and
d)the physical media for Open Systems Interconnection.
Note 1 – This Basic Reference Model of Open Systems
Interconnection is based on the assumption that a connection is
required for the transfer of data. An addendum to this
Recommendation is currently being developed to extend the
description to cover the connectionless forms of data transmission
which may be found in a wide variety of data communications
techniques (e.g. local area networks, digital radio, etc.) and
applications (e.g. remote sensing and banking).
Note 2 – Security aspects which are also general architectural
elements of protocols are not discussed in this Recommendation.
5.2 Principles of layering
5.2.1Definitions
5.2.1.1 (N)-subsystem
An element in a hierarchical division of an open system which
interacts directly only with elements in the next higher division
or the next lower division of that open system.
5.2.1.2 (N)-layer
A sub-division of the OSI architecture, constituted by
subsystems of the same rank (N).
5.2.1.3 (N)-entity
An active element within an (N)-subsystem.
5.2.1.4 peer-entities
Entities within the same layer.
5.2.1.5 sublayer
A sub-division of a layer.
5.2.1.6 (N)-service
A capability of the (N)-layer and the layers beneath it, which
is provided to (N + 1)-entities at the boundary between the (N)-
layer and the (N + 1)-layer.
5.2.1.7 (N)-facility
A part of an (N)-service.
5.2.1.8 (N)-function
A part of the activity of (N)-entities.
5.2.1.9 (N)-service-access-point
The point at which (N)-services are provided by an (N)-entity
to an (N + 1)-entity.
5.2.1.10 (N)-protocol
A set of rules and formats (semantic and syntactic) which
determines the communication behaviour of (N)-entities in the
performance of (N)-functions.
5.2.2Description
The basic structuring technique in the Reference Model of Open
Systems Interconnection is layering. According to this technique,
each open system is viewed as logically composed of an ordered set
of subsystems, represented for convenience in the vertical sequence
shown in Figure 3/X.200. Adjacent subsystems communicate through
their common boundary. Subsystems of the same rank (N) collectively
for the (N)-layer of the Reference Model of Open Systems
Interconnection. An (N)-subsystem consists of one or several (N)-
entities. Entities exist in each layer. Entities in the same layer
are termed peer-entities. Note that the highest layer does not have
an (N + 1)-layer above it and the lowest layer does not have an (N
- 1)-layer below it.
FIGURE 3/X.200
Not all peer (N)-entities need or even can communicate. There
may be conditions which prevent this communication (e.g. they are
not in interconnected open systems, or they do not support the same
protocol subsets).
Note 1 – Type and Instance.
The distinction between the type of some object and an
instance of that object is a distinction of significance for OSI. A
type is a description of a class of objects. An instance of this
type is any object that conforms to this description. The instances
of the same type constitute a class. A type, and any instance of
this type can be referred to by an individual name. Each nameable
instance and the type to which this instance belongs carry
distinguishable names.
For example, given that a programmer has written a computer
program, that programmer has generated a type of something, where
instances of that type are created every time that particular
program is invoked into execution by a computer. Thus, a FORTRAN
compiler is a type and each occasion where a copy of that program
is invoked in a data processing machine displays an instance of
that program.
Consider now an (N)-entity in the OSI context. It, too, has
two aspects, a type and a collection of instances. The type of an
(N)-entity is defined by the specific set of (N)-layer functions it
is able to perform. An instance of that type of (N)-entity is a
specific invocation of whatever it is within the relevant open
system that provides the (N)-layer functions called for by its type
for a particular occasion of communication. It follows from these
observations that (N)-entity types refer only to the properties of
an association between peer (N)-entities, while an (N)-entity
instance refers to the specific, dynamic occasions of actual
information exchange.
It is important to note that actual communication occurs only
between (N)-entity instances at all layers. It is only at
connection establishment time (or its logical equivalent during a
recovery process) that (N)-entity types are explicitly relevant.
Actual connections are always made to specific (N)-entity
instances, although a request for a connection may well be made for
arbitrary (N)-entity instances of a specified type. Nothing in
Recommendation X.200, however, precludes the request for a
connection with a specific (named) instance of a peer (N)-entity.
If an (N)-entity instance is aware of the name of its peer (N)-
entity instance, it is able to request another connection to that
(N)-entity instance.
Note 2 – It may be necessary to further divide a layer into
small substructures called sublayers and to extend the technique of
layering to cover other dimensions of Open Systems Interconnection.
A sublayer is described as a grouping of functions in a layer which
may be bypassed. The bypassing of all the sublayers of a layer is
not allowed. A sublayer uses the entities and connections of its
layer. The detailed definition or additional characteristics of a
sublayer are for further study.
Except for the highest layer, each (N)-layer provides (N + 1)-
entities in the (N + 1)-layer with (N)-services. The highest layer
is assumed to represent all possible uses of the services which are
provided by the lower layers.
Note 1 – Not all open systems provide the initial source or
final destination of data, such open systems need not contain the
higher layers of the architecture (see Figures 6/X.200 and
13/X.200).
Note 2 – Classes of service may be defined within the (N)-
services. The precise definition of the term “classes of service”
is for further study.
Each service provided by an (N)-layer may be tailored by the
selection of one or more (N)-facilities which determine the
attributes of that service. When a single (N)-entity cannot by
itself fully support a service requested by an (N + 1)-entity it
calls upon the cooperation of other (N)-entities to help complete
the service request. In order to cooperate, (N)--entities in any
layer, other than those in the lowest layer, communicate by means
of the set of services provided by the (N – 1)-layer (see Figure
4/X.200). The entities in the lowest layer are assumed to
communicate directly via the physical media which connect them.
FIGURE 4/X.200
The services of an (N)-layer are provided to the (N + 1)-
layer, using the (N)-functions performed within the (N)-layer and
as necessary the services available from the (N - 1)-layer.
An (N)-entity may provide services to one or more (N + 1)-
entities and use the services of one or more (N - 1)-entities. An
(N)-service-access-point is the point at which a pair of entities
in adjacent layers use or provide services (see Figure 7/X.200).
Cooperation between (N)-entities is governed by one or more
(N)-protocols. The entities and protocols within a layer are
illustrated in Figure 5/X.200.
FIGURE 5/X.200
5.3 Communication between peer entities
5.3.1Definitions
5.3.1.1 (N)-connection
An association established by the (N)-layer between two or
more (N + 1)-entities for the transfer of data.
5.3.1.2 (N)-connection-endpoint
A terminator at one end of an (N)-connection within an (N)-
service-access-point.
5.3.1.3 multi-endpoint-connection
A connection with more than two connection-endpoints.
5.3.1.4 correspondent (N)-entities
(N)-entities with an (N - 1)-connection between them.
5.3.1.5 (N)-relay
An (N)-function by means of which an (N)-entity forwards data
received from one correspondent (N)-entity to another correspondent
(N)-entity.
5.3.1.6 (N)-data-source2)
An (N)-entity that sends (N - 1)-service-data-units (see §
5.6.1.7) on an (N - 1)-connection.
5.3.1.7 (N)-data-sink3)
An (N)-entity that receives (N - 1)-service-data-units on an
(N - 1)-connection.
5.3.1.8 (N)-data-transmission
An (N)-facility which conveys (N)-service-data-units from one
(N + 1)-entity to one or more (N + 1)-entities.
5.3.1.9 (N)-duplex-transmission
(N)-data transmission in both directions at the same time.
5.3.1.10 (N)-half-duplex-transmission
(N)-data transmission in either direction one direction at a
time; the choice of direction is controlled by an (N + 1)-entity.
5.3.1.11 (N)-simplex-transmission
(N)-data-transmission in one pre-assigned direction.
5.3.1.12 (N)-data-communication
An (N)-function which transfers (N)-protocol-data-units (see §
5.6.1.3) according to an (N)-protocol over one or more (N - 1)-
connections.
5.3.1.13 (N)-two-way-simultaneous-communication
(N)-data-communication in both directions at the same time.
5.3.1.14 (N)-two-way alternate communication
(N)-data communication in both directions, one direction at a
time.
5.3.1.15 (N)-one-way communication
(N)-data communication in one pre-assigned direction.
5.3.2Description
For information to be exchanged between two or more (N + 1)-
entities, an association is established between them in the (N)-
layer using an (N)-protocol.
Note – Classes of protocols may be defined within the (N)-
protocols. The precise definition of the term “classes of
protocols” is for further study.
This association is called an (N)-connection. (N)-connections
are provided by the (N)-layer between two or more (N)-service-
access-points. The terminator of an (N)-connection at an (N)-
service-access-point is called an (N)-connection-endpoint. A
connection with more than two connection-endpoints is termed a
multi-endpoint-connection. (N)-entities with a connection between
them are termed correspondent (N)-entities.
(N + 1)-entities can communicate only by using the services of
the (N)-layer. There are instances where services provided by the
(N)-layer do not permit direct access between all of the (N + 1)-
entities which have to communicate. If this is the case,
communication can still occur if some other (N + 1)-entity can act
as a relay between them (see Figure 6/X.200).
The fact that communication is relayed by a chain of (N + 1)-
entities is known neither by the (N)-layer nor by the (N + 2)-
layer.
FIGURE 6/X.200
5.4 Identifiers
5.4.1Definitions
5.4.1.1 title
A permanent identifier for an entity.
5.4.1.2 title-domain
A subset of the title space of the OSI environment.
5.4.1.3 title-domain-name
An identifier which uniquely identifies a title-domain with
the OSI environment.
Note – Title-domains of primary importance are the layers. In
this specific case, the title-domain-name identifies the (N)-layer.
5.4.1.4 local-title
A title which is unique within a title-domain.
5.4.1.5 global-title
A title which is unique within the OSI environment and
comprises two parts, a title-domain-name and a local-title.
5.4.1.6 (N)-address; (N)-service-access-point-address
An identifier which tells where an (N)-service-access-point
may be found.
5.4.1.7 (N)-directory
An (N)-function by which the global title of an (N)-entity is
translated into the (N - 1)-address of an (N - 1)-service-access-
point to which the (N)-entity is attached.
5.4.1.8 (N)-address-mapping
An (N)-function which provides the mapping between the (N)-
addresses and the (N - 1)-addresses associated with an (N)-entity.
5.4.1.9 routing
A function within a layer which translates the title of an
entity or the service-access-point-address to which the entity is
attached into a path by which the entity can be reached.
5.4.1.10 (N)-connection-endpoint-identifier
An identifier of an (N)-connection-endpoint which can be used
to identify the corresponding (N)-connection at an (N)-service-
access-point.
5.4.1.11 (N)-connection-endpoint-suffix
A part of an (N)-connection-endpoint-identifier which is
unique within the scope of an (N)-service-access-point.
5.4.1.12 multi-connection-endpoint-identifier
An identifier which specifies the connection-endpoint of a
multi-endpoint-connection which should accept the data that is
being transferred.
5.4.1.13 (N)-service-connection-identifier
An identifier which uniquely specifies an (N)-connection
within the environment of the correspondent (N + 1)-entities.
5.4.1.14 (N)-protocol-connection-identifier
An identifier which uniquely specifies an individual (N)-
connection within the environment of the multiplexed (N - 1)-
connection.
5.4.1.15 (N)-suffix
A part of an (N)-address which is unique within the (N)-
service-access-point.
5.4.2Description
An (N)-service-access-point-address, or (N)-address for short,
identifies a particular (N)-service-access-point to which an
(N + 1)-entity is attached (see Figure 7/X.200). When the (N + 1)-
entity is detached from the (N)-service-access-point, the (N)-
address no longer provides access to the (N + 1)-entity. If the (N)-
service-access-point is reattached to a different (N + 1)-entity,
then the (N)-address identifies the new (N + 1)-entity and not the
old one.
FIGURE 7/X.200
The use of an (N)-address to identify an (N + 1)-entity is the
most efficient mechanism if the permanence of the attachment
between the (N + 1)-entity and the (N)-service-access-point can be
assured. If there is a requirement to identify an (N + 1)-entity
regardless of its current location, then the global-title assures
correct identification.
An (N)-directory is an (N)-function which translates global-
titles of peer (N)-entities into the (N - 1)-addresses through
which they cooperate.
Interpretation of the correspondence between the (N)-addresses
served by an (N)-entity and the (N - 1)-addresses used for
accessing (N - 1)-services is performed by an (N)-address-mapping
function.
Two particular kinds of (N)-address-mapping functions may
exist within a layer:
a)hierarchical (N)-address-mapping; and
b)(N)-address-mapping by tables.
If an (N)-address is always mapped into only one (N - 1)-
address then hierarchical construction of addresses can be used
(see Figure 8/X.200). The (N)-address-mapping function need only
recognize the hierarchical structure of an (N)-address and extract
the (N - 1)-address it contains.
FIGURE 8/X.200
In this case, an (N)-address consists of two parts:
a)an (N - 1)-address of the (N)-entity which is supporting
the current (N)-service-access-point of the (N + 1)-entity;
b)an (N)-suffix which makes the (N)-service-access-point
uniquely identifiable within the scope of the (N - 1)-
address.
Within a given layer, a hierarchical structure of addresses
simplifies (N)-address-mapping functions because of the permanent
nature of the mapping it presupposes. It is not imposed by the
model in all layers in order to allow more flexibility in (N)-
address-mappings and to cover the case where an (N)-entity attached
to more than one (N - 1)-service-access-point supports only one (N)-
service-access-point.
If the previous condition is not true, i.e. either an (N)-
address can be mapped into several (N - 1)-addresses, or an (N)-
address is not permanently mapped into the same (N - 1)-address,
then hierarchical construction of an address is not possible and
the (N)-address-mapping function may use tables to translate (N)-
addresses into (N - 1)-addresses.
The structure of an (N)-address is known by the (N)-entity
which is attached to the identified (N)-service-access-point.
However, the (N + 1)-entity does not know this structure.
If an (N + 1)-entity has two or more (N)-service-access-points
with either the same (N)-entity or different (N)-entities, the (N)-
entities have no knowledge of this fact. Each (N)-service-access-
point is considered to identify a different (N + 1)-entity from the
perspective of the (N)-entities.
A routing function translates the (N)-address of an (N + 1)-
entity into a path or route by which the (N + 1)-entity may be
reached.
An (N + 1)-entity may establish an (N)-connection with another
(N + 1)-entity by using an (N)-service. When an (N + )-entity
establishes an (N)-connection with another (N + 1)-entity, each
(N + 1)-entity is given an (N)-connection-endpoint-identifier by
its supporting (N)-entity. The (N + 1)-entity can then distinguish
the new connection from all other (N)-connections accessible at the
(N)-service-access-point it is using. This (N)-connection-endpoint-
identifier is required to be unique within the scope of the (N + 1)-
entity which will use the (N)-connection.
The (N)-connection-endpoint-identifier consists of two parts:
a)the (N)-address of the (N)-service-access-point which will
be used in conjunction with the (N)-connection; and
b)an (N)-connection-endpoint-suffix which is unique within
the scope of the (N)-service-access-point.
A multi-endpoint-connection requires multi-connection-endpoint-
identifiers. Each such identifier is used to specify which
connection-endpoint should accept the data which is being
transferred. A multi-connection-endpoint-identifier must be unique
within the scope of the connection within which it is used.
The (N)-layer may provide to the (N + 1)-entities an (N)-
service-connection-identifier which uniquely specifies the (N)-
connection within the environment of the correspondent (N + 1)-
entities.
5.5 Properties of service-access-points
An (N + 1)-entity requests (N)-services via an (N)-service-
access-point which permits the (N + 1)-entity to interact with an
(N)-entity.
Both the (N)- and (N + 1)-entities attached to an (N)-service-
access-point are in the same system.
An (N + 1)-entity may concurrently be attached to one or more
(N)-service-access-points attached to the same or different (N)-
entities.
An (N)-entity may concurrently be attached to one or more (N +
1)-entities through (N)-service-access-points.
An (N)-service-access-point is attached to only one (N)-entity
and to only one (N + 1)-entity at a time.
An (N)-service-access-point may be detached from an (N + 1)-
entity and reattached to the same or another (N + 1)-entity.
An (N)-service-access-point may be detached from an (N)-entity
and reattached to the same or another (N)-entity.
An (N)-service-access-point is located by means of its (N)-
address. An (N)-address is used by an (N + 1)-entity to request an
(N)-connection.
5.6 Data Units
5.6.1Definitions
5.6.1.1 (N)-protocol-control-information
Information exchanged between (N)-entities, using an (N - 1)-
connection, to coordinate their joint operation.
5.6.1.2 (N)-user-data
The data transferred between (N)-entities on behalf of the (N
+ 1)-entities for whom the (N)-entities are providing services.
5.6.1.3 (N)-protocol-data-unit
A unit of data specified in an (N)-protocol and consisting of
(N)-protocol-control-information and possibly (N)-user-data.
5.6.1.4 (N)-interface-control-information
Information transferred between an (N + 1)-entity and an (N)-
entity to coordinate their joint operation.
5.6.1.5 (N)-interface-data
Information transferred from an (N + 1)-entity to an (N)-
entity for transmission to a correspondent (N + 1)-entity over an
(N)-connection, or conversely, information transferred from an (N)-
entity to an (N + 1)-entity after being received over an (N)-
connection from a correspondent (N + 1)-entity.
5.6.1.6 (N)-interface-data-unit
The unit of information transferred across the (N)-service-
access-point between an (N + 1)-entity and an (N)-entity in a
single interaction. Each (N)-interface-data-unit contains (N)-
interface-control-information and may also contain the whole or
part of an (N)-service-data-unit.
5.6.1.7 (N)-service-data-unit
An amount of (N)-interface-data whose identity is preserved
from one end of an (N)-connection to the other.
5.6.1.8 expedited (N)-service-data-unit, (N)-expedited-data-
unit
A small (N)-service-data-unit whose transfer is expedited. The
(N)-layer ensures that an expedited-data-unit will not be delivered
after any subsequent service-data-unit or expedited unit sent on
that connection.
5.6.2Description
Information is transferred in various types of data units
between peer-entities and between entities attached to a specific
service-access-point. The data-units are defined in sub-division
5.6.1 and the relationships among them are illustrated in Figures
9/X.200 and 10/X.200.
FIGURE 9/X.200
FIGURE 10/X.200
Except for the relationships defined in Figures 9/X.200 and
10/X.200, there is no overall architectural limit to the size of
data units. There may be other size limitations at specific layers.
The size of (N)-interface-data-units is not necessarily the
same at each end of the connection.
Data may be held within a connection until a complete service-
data-unit is put into the connection.
5.7 Elements of layer operation
5.7.1Definitions
5.7.1.1 (N)-protocol-identifier
An identifier used between correspondent (N)-entities to
select a specific (N)-protocol to be used on a particular (N - 1)-
connection.
5.7.1.2 centralized multi-endpoint-connection
A multi-endpoint-connection where data sent by the entity
associated with the central connection-endpoint is received by all
other entities, while data sent by one of the other entities is
only received by the central entity.
5.7.1.3 decentralized multi-endpoint-connection
A multi-endpoint-connection such that data sent by an entity
associated with a connection-endpoint is received by all other
entities.
5.7.1.4 multiplexing
A function within the (N)-layer by which one (N - 1)-
connection is used to support more than one (N)-connection.
Note – The term multiplexing is also used in a more restricted
sense to refer to the function performed by the sending (N)-entity
while the term demultiplexing is used to refer to the function
performed by the receiving (N)-entity.
5.7.1.5 demultiplexing
The function performed by an (N)-entity which identifies (N)-
protocol-data-units for more than one (N)-connection within (N - 1)-
service-data-units received on a single (N - 1)-connection. It is
the reverse function of the multiplexing function performed by the
(N)-entity sending the (N - 1)-service-data-units.
5.7.1.6 splitting
A function within the (N)-layer by which more than one (N - 1)-
connection is used to support one (N)-connection.
Note – The term splitting is also used in a more restrictive
sense to refer to the function performed by the sending (N)-entity
while the term recombining is used to refer to the function
performed by the receiving (N)-entity.
5.7.1.7 recombining
The function performed by an (N)-entity which identifies (N)-
protocol-data-units for a single (N)-connection in (N - 1)-service-
data-units received on more than one (N - 1)-connection. It is the
reverse function of the splitting function performed by the (N)-
entity sending the (N - 1)-service-data-units.
5.7.1.8 flow control
A function which controls the flow of data within a layer or
between adjacent layers.
5.7.1.9 segmenting
A function performed by an (N)-entity to map one (N)-service-
data-unit into multiple (N)-protocol-data-units.
5.7.1.10 reassembling
A function performed by an (N)-entity to map multiple (N)-
protocol-data-units into one (N)-service-data-unit. It is the
reverse function of segmenting.
5.7.1.11 blocking
A function performed by an (N)-entity to map multiple (N)-
service-data-units into one (N)-protocol-data-unit.
5.7.1.12 deblocking
A function performed by an (N)-entity to identify multiple (N)-
service-data-units which are contained in one (N)-protocol-data-
unit. It is the reverse function of blocking.
5.7.1.13 concatenation
A function performed by an (N)-entity to map multiple (N)-
protocol-data-units into one (N - 1)-service-data-unit.
5.7.1.14 separation
A function performed by an (N)-entity to identify multiple (N)-
protocol-data-units which are contained in one (N - 1)-service-data-
unit. It is the reverse function of concatenation.
5.7.1.15 sequencing
A function performed by the (N)-layer to preserve the order of
(N)-service-data-units that were submitted to the (N)-layer.
5.7.1.16 acknowledgement
A function of the (N)-layer which allows a receiving (N)-
entity to inform a sending (N)-entity of the receipt of an (N)-
protocol-data-unit.
5.7.1.17 reset
A function which sets the correspondent (N)-entities to a
predefined state with a possible loss or duplication of data.
Note – Blocking and concatenation, though close to each other
(they both permit grouping of data-units) are different (see
definitions §§ 5.7.1.11 and 5.7.1.13). These two functions may
serve different purposes. For instance, concatenation permits the
(N)-layer to group one or several acknowledgement (N)-PDUs with one
(or several) (N)-PDUs containing user data, and this would not be
possible with the blocking function only. Note also that the two
functions may be combined so that the (N)-layer performs blocking
and concatenation.
5.7.2Protocol selection
One or more (N)-protocols may be defined for the (N)-layer. An
(N)-entity may employ one or more (N)-protocols.
Meaningful communication between (N)-entities over an (N - 1)-
connection requires the agreed selection of one (N)-protocol. (N)-
protocol-identifiers name the specific protocols defined.
5.7.3Properties of connections
An (N)-connection is an association established for
communication between two or more (N + 1)-entities, identified by
their (N)-addresses. An (N)-connection is offered as a service by
the (N)-layer, so that information may be exchanged between the
(N + 1)-entities.
An (N + 1)-entity may have, simultaneously, one or more (N)-
connections with other (N + 1)-entities, with any given (N + 1)-
entity, and with itself.
An (N)-connection is established by referencing, either
explicitly or implicitly, an (N)-address for the source (N + 1)-
entity and an (N)-address for each of one or more destination
(N + 1)-entities.
The source (N)-address and one or more of the destination (N)-
addresses may be the same. One or more of the destination (N)-
addresses may be the same while the source (N)-address is
different. All may be different.
One (N)-connection-endpoint is constructed for each (N)-
address referenced explicitly or implicitly when an (N)-connection
is established.
An (N + 1)-entity accesses an (N)-connection via an (N)-
service-access-point.
An (N)-connection has two or more (N)-connection-endpoints.
An (N)-connection-endpoint is not shared by (N + 1)-entities
or (N)-connections.
An (N)-connection-endpoint relates three elements:
a)an (N + 1)-entity;
b)an (N)-entity; and
c)an (N)-connection.
The (N)-entity and the (N + 1)-entity related by an (N)-
connection-endpoint are those implied by the (N)-address referenced
when the (N)-connection is established.
An (N)-connection-endpoint has an identifier, called an (N)-
connection-endpoint-identifier, which is unique within the scope of
the (N + 1)-entity which is bound to the (N)-connection-endpoint.
An (N)-connection-endpoint-identifier is not the same as an
(N)-address.
An (N + 1)-entity references an (N)-connection using its (N)-
connection-endpoint-identifier.
Multi-endpoint-connections are connections which have three or
more connection-endpoints. Two types of multi-endpoint-connection
are defined.
a)centralized; and
b)decentralized.
A centralized multi-endpoint-connection has a central
connection-endpoint. Data sent by the entity associated with the
central connection-endpoint is received by the entities associated
with all other connection-endpoints. The data sent by an entity
associated with any other connection-endpoint is received only by
the entity associated with the central connection-endpoint.
On a decentralized multi-endpoint-connection, data sent by an
entity associated with any connection-endpoint is received by the
entities associated with all of the other connection-endpoints.
5.7.4Connection establishment and release
The establishment of an (N)-connection by peer-entities of an
(N)-layer requires the following:
a)the availability of an (N - 1)-connection between the
supporting (N)-entities; and
b)both (N)-entities be in a state in which they can execute
the connection establishment protocol exchange.
If it is not already available, an (N - 1)-connection has to
be established by peer-entities of the (N - 1)-layer. This
requires, for the (N - 1)-layer, the same conditions as described
above for the (N)-layer.
The same consideration applies downwards until either an
available connection or the physical medium for Open Systems
Interconnection is encountered.
Depending upon the characteristics of the (N - 1)-service and
of the establishment protocol exchange, the establishment of an (N)-
connection may or may not be done in conjunction with the
establishment of the (N - 1)-connection.
The characteristics of the (N)-service with regard to the
establishment of the (N)-connection vary depending upon whether or
not (N)-user-data can be transferred by the connection
establishment protocol exchange for each direction of the (N)-
connection.
Where (N)-user-data is transferred by the (N)-connection
establishment protocol exchange, the (N + 1)-protocol may take
advantage of this to allow an (N + 1)-connection to be established
in conjunction with the establishment of the (N)-connection.
The release of an (N)-connection is normally initiated by one
of the (N + 1)-entities associated in it.
The release of an (N)-connection may also be initiated by one
of the (N)-entities supporting it as a result of an exception
condition occurring in the (N)-layer or the layers below.
Depending upon the conditions, release of an (N)-connection
may result in the discarding of (N)-user-data.
The orderly release of an (N)-connection requires either the
availability of an (N - 1)-connection, or a common reference to
time (e.g. time of failure of the (N - 1)-connection and common
time-out). In addition, it requires that both (N)-entities are in a
state in which they can execute the connection release protocol
exchange. It is important to note, however, that the release of an
(N - 1)-connection does not necessarily cause the release of the
(N)-connection(s) which were using it; the (N - 1)-connection can
be re-established, or another (N - 1)-connection substituted.
The characteristics of the (N)-service with regard to the
release of an (N)-connection can be of two kinds:
a)(N)-connections are either released immediately when the
release protocol exchange is initiated ((N)-user-data not
yet delivered may be discarded); or
b)release is delayed until all (N)-user-data sent previous to
the initiation of the release protocol exchange has been
delivered (i.e., delivery confirmation has been received.)
(N)-user-data may be transferred by the connection release
protocol exchange.
Some (N)-protocols may provide for the combining of connection
establishment and connection release protocol exchanges.
5.7.5Multiplexing and splitting
Within the (N)-layer, (N)-connections are mapped onto (N - 1)-
connections. The mapping may be one of three kinds:
a)one-to-one;
b)many (N)-connections to one (N - 1)-connection
(multiplexing); and
c)one (N)-connection to many (N - 1)-connections (splitting).
Multiplexing may be needed in order to:
a)make more efficient or more economic use of the (N - 1)-
service; and
b)provide several (N)-connections in an environment where
only a single (N - 1)-connection exists.
Splitting may be needed in order to:
a)improve reliability where more than one (N - 1)-connection
is available;
b)provide the required grade of performance, through the
utilization of multiple (N - 1)-connections; and
c)obtain cost benefits by the utilization of multiple low
cost (N - 1)-connections each with less than the required
grade of performance.
Multiplexing and splitting each involve a number of associated
functions which may not be needed for one-to-one connection
mapping.
The functions associated with multiplexing are:
a)identification of the (N)-connection for each (N)-protocol-
data-unit transferred over the (N - 1)-connection, in order
to ensure that (N)-user-data from the various multiplexed
(N)-connections are not mixed. This identification is
distinct from that of the (N)-connection-endpoint-
identifiers and is called an (N)-protocol-connection-
identifier;
b)flow control on each (N)-connection in order to share the
capacity of the (N - 1)-connection (see § 5.7.6.4); and
c)scheduling the next (N)-connection to be serviced over the
(N - 1)-connection when more than one (N)-connection is
prepared to send data.
The functions associated with splitting are:
a)scheduling the utilization of multiple (N - 1)-connections
used in splitting a single (N)-connection; and
b)resequencing of (N)-protocol-data-units associated with an
(N)-connection since they may arrive out of sequence even
when each (N - 1)-connection guarantees sequence of
delivery (see § 5.7.6.6).
5.7.6Transfer of data
5.7.6.1 Normal Data transfer
Control information and user data are transferred between (N)-
entities in (N)-protocol-data-units. An (N)-protocol-data-unit is a
unit of data specified in an (N)-protocol and contains (N)-protocol-
control-information and possibly (N)-user-data.
(N)-protocol-control-information is transferred between (N)-
entities using the (N - 1)-connection. (N)-protocol-control-
information is any information that supports the joint operation of
(N)-entities. (N)-user-data is passed transparently between (N)-
entities over an (N - 1)-connection.
An (N)-protocol-data-unit has an arbitrary, but finite, size.
(N)-protocol-data-units are mapped into (N - 1)-service-data-units.
The interpretation of an (N)-protocol-data-unit is defined by the
(N)-protocol in effect for the (N - 1)-connection.
An (N)-service-data-unit is transferred between an (N + 1)-
entity and an (N)-entity, through an (N)-service-access-point, in
the form of one or more (N)-interface-data-units. The (N)-service-
data-unit is transferred as (N)-user-data in one or more (N)-
protocol-data-units.
The exchange of data under the rules of an (N)-protocol can
only occur if an (N - 1)-connection exists. If an (N - 1)-
connection does not exist, it must be established before an
exchange of data can occur (see § 5.7.4).
5.7.6.2 Data transfer during connection establishment and
release
(N)-user-data may be transferred in the (N)-connection
establishment protocol exchange and in the (N)-connection release
protocol exchange.
The connection release protocol exchange may be combined with
the connection establishment protocol exchange (see § 5.7.4) to
provide means for the delivery of a single unit of (N)-user-data
between correspondent (N + 1)-entities with a confirmation of
receipt.
5.7.6.3 Expedited transfer of data
An expedited-data-unit is a service-data-unit which is
transferred and/or processed with priority over normal service-data-
units. An expedited data transfer service may be used for
signalling and interrupt purposes.
Expedited data flow is independent of the states and operation
of the normal data flow, although the data sent on the two flows
may be logically related. Conceptually, a connection that supports
expedited flow can be viewed as having two subchannels, one for
normal data, the other for expedited data. Data sent on the
expedited channel is assumed to be given priority over normal data.
The transfer guarantees that an expedited-data-unit will not
be delivered after any subsequent normal service-data-unit or
expedited-data-unit sent on the connection.
Because the expedited flow is assumed to be used to transfer
small amounts of data infrequently, simplified flow control
mechanisms may be used on this data flow.
An expedited (N)-service-data-unit is intended to be processed
by the receiving (N + 1)-entity with priority over normal (N)-
service-data-units.
5.7.6.4 Flow control
If flow control functions are provided, they can operate only
on protocol-data-units and interface-data-units.
Two types of flow control are identified:
a)peer flow control which regulates the rate at which (N)-
protocol-data-units are sent to the peer (N)-entity on the
(N)-connection. Peer flow control requires protocol
definitions and is based on protocol-data-unit size; and
b)(N)-interface flow control which regulates the rate at
which (N)-interface-data are passed between an (N + 1)-
entity and an (N)-entity. (N)-interface flow control is
based on the (N)-interface-data-unit size.
Multiplexing in a layer may require a peer flow control
function for individual flows (see § 5.7.5).
Peer flow control functions require that flow control
information be included in the (N)-protocol-control-information of
an (N)-protocol-data-unit.
If the size of service-data-units exceeds the maximum size of
the (N)-user-data portion of an (N)-protocol-data-unit, then first
segmentation must be performed on the (N)-service-data-unit to make
it fit within the (N)-protocol-data-units. Peer flow control can
then be applied on the (N)-protocol-data-units.
5.7.6.5 Segmenting, blocking and concatenation
Data units in the various layers are not necessarily of
compatible size. It may be necessary to perform segmenting, i.e.,
to map an (N)-service-data-unit into more than one (N)-protocol-
data-unit. Similarly, segmenting may occur when (N)-protocol-data-
units are mapped into (N - 1)-interface-data-units. Since it is
necessary to preserve the identity of (N)-service-data-units on an
(N)-connection, functions shall be available to identify the
segments of an (N)-service-data-unit, and to allow the
correspondent (N)-entities to reassemble the (N)-service-data-unit.
Segmenting may require that information be included in the (N)-
protocol-control-information of an (N)-protocol-data-unit. Within a
layer, (N)-protocol-control-information is added to an (N)-service-
data-unit to form an (N)-protocol-data-unit when no segmenting or
blocking is performed (see Figure 11a/X.200). If segmenting is
performed, an (N)-service-data-unit is mapped into several (N)-
protocol-data-units with added (N)-protocol-control-information
(see Figure 11b/X.200).
Conversely, it may be necessary to perform blocking whereby
several (N)-service-data-units with added (N)-protocol-control-
information form an (N)-protocol-data-unit (see Figure 11c/X.200).
The Reference Model also permits concatenation whereby several
(N)-protocol-data-units are concatenated into a single (N - 1)-
service-data-unit (see Figure 11d/X.200).
5.7.6.6 Sequencing
The (N - 1)-services provided by the (N - 1)-layer of the OSI
architecture may not guarantee delivery of (N - 1)-service-data-
units in the same order as it was submitted by the (N)-layer. If
the (N)-layer needs to preserve the order of (N - 1)-service-data-
units transferred through the (N - 1)-layer, sequencing mechanisms
must be present in the (N)-layer. Sequencing may require additional
(N)-protocol-control-information.
5.7.7Error functions
5.7.7.1 Acknowledgement
An acknowledgement function may be used by peer (N)-entities
using an (N)-protocol to obtain a higher probability of detecting
protocol-data-unit loss than is provided by the (N - 1)-layer. Each
(N)-protocol-data-unit transferred between correspondent (N)-
entities is made uniquely identifiable, so that the receiver can
inform the sender of the receipt of the (N)-protocol-data-unit. An
acknowledgement function is also able to infer the non-receipt of
(N)-protocol-data-units and take appropriate remedial action.
FIGURE 11/X.200
An acknowledgement function may require that information be
included in the (N)-protocol-controlinformation of (N)-protocol-
data-units.
The scheme for uniquely identifying (N)-protocol-data-units
may also be used to support other functions such as detection of
duplicate data-units, segmenting and sequencing.
Note – Other forms of acknowledgement such as confirmation of
delivery and confirmation of performance of an action are for
further study.
5.7.7.2 Error detection and notification
Error detection and notification functions may be used by an
(N)-protocol to provide a higher probability of both protocol-data-
unit error detection and data corruption detection than is provided
by the (N - 1)-service.
Error detection and notification may require that additional
information be included in the (N)-protocol-control-information of
the (N)-protocol-data-unit.
5.7.7.3 Reset
Some services require a reset function to recover from a loss
of synchronization between correspondent (N)-entities. A reset
function sets the correspondent (N)-entities to a predefined state
with a possible loss or duplication of data.
Note – Additional functions may be required to determine at
what point reliable data transfer was interrupted.
A quantity of (N)-user-data may be conveyed in association
with the (N)-reset function.
The reset function may require that information be included in
the (N)-protocol-control-information of the (N)-protocol-data-unit.
5.8 Routing
A routing function within the (N)-layer enables communication
to be relayed by a chain of (N)-entities. The fact that
communication is being routed by intermediate (N)-entities is known
by neither the lower layers nor by the higher layers. An (N)-entity
which participates in a routing function may have a routing table.
5.9 Management aspects of OSI
5.9.1Definitions
5.9.1.1 application-management
Functions in the Application Layer (see § 6.1) related to the
management of OSI application-processes.
5.9.1.2 application-management-application-entity
An application-entity which executes application-management
functions.
5.9.1.3 OSI resources
Data processing and data communication resources which are of
concern to OSI.
5.9.1.4 systems-management
Functions in the Application Layer related to the management
of various OSI resources and their status across all layers of the
OSI architecture.
5.9.1.5 systems-management-application-entity
An application-entity which executes systems-management
functions.
5.9.1.6 layer-management
Functions related to the management of the (N)-layer partly
performed in the (N)-layer itself according to the (N)-protocol of
the layer (activities such as activation and error control) and
partly performed as a subset of systems-management.
5.9.2Introduction
Within the OSI architecture there is a need to recognize the
special problems of initiating, terminating, and monitoring
activities and assisting in their harmonious operations, as well as
handling abnormal conditions. These have been collectively
considered as the management aspects of the OSI architecture. These
concepts are essential to the operation of the interconnected open
systems and therefore are included in the comprehensive description
of the Reference Model described in subsequent divisions of this
Recommendation.
The management activities which are of concern are those which
imply actual exchanges of information between open systems. Only
the protocols needed to conduct such exchanges are candidates for
standardization within the OSI architecture.
This sub-division describes key concepts relevant to the
management aspects, including the different categories of
management activities and the positioning of such activities within
the OSI architecture.
5.9.3Categories of management activities
Only those management activities which imply actual exchanges
of information between remote management entities are pertinent to
the OSI architecture. Other management activities local to
particular open systems are outside its scope.
Similarly, not all resources are pertinent to OSI. This
Recommendation considers only OSI resources, i.e., those data
processing and data communication resources which are of concern to
OSI.
The following categories of management activities are
identified:
a)application-management;
b)systems-management; and
c)layer-management.
5.9.3.1 Application-management
Application-management relates to the management of OSI
application-processes. The following list is typical of activities
which fall into this category but it is not exhaustive:
a)initialization of parameters representing application-
processes;
b)initiation, maintenance and termination of application-
processes;
c)allocation and de-allocation of OSI resources to
application-processes;
d)detection and prevention of OSI resource interference and
deadlock;
e)integrity and commitment control;
f)security control; and
g)checkpointing and recovery control.
The protocols for application-management reside within the
Application Layer, and are handled by application-management-
application-entities.
5.9.3.2 Systems-management
Systems-management relates to the management of OSI resources
and their status across all layers of the OSI architecture. The
following list is typical of activities which fall into this
category but it is not exhaustive:
a)activation/deactivation management which includes:
1)activation, maintenance and termination of OSI resources
distributed in open systems, including physical media
for OSI;
2)some program loading functions;
3)establishment/maintenance/release of connections between
management entities; and
4)open systems parameter initialization/modification;
b)monitoring which includes:
1)reporting status or status changes; and
2)reporting statistics; and
c)error control which includes:
1)error detection and some of the diagnostic functions;
and
2)reconfiguration and restart.
The protocols for systems-management reside in the Application
Layer, and are handled by systems-management-application-entities.
5.9.3.3 Layer-management
There are two aspects of layer-management. One of these is
concerned with layer activities such as activation and error
control. This aspect is implemented by the layer protocol to which
it applies.
The other aspect of layer-management is a subset of systems-
management. The protocols for these activities reside within the
Application Layer and are handled by system-management-application-
entities.
5.9.4Principles for positioning management functions
Several principles are important in positioning management
functions in the Reference Model of Open Systems Interconnection.
They include the following:
a)both centralization and decentralization of management
functions are allowed. Thus, the OSI architecture does not
dictate any particular fashion or degree of centralization
of such functions. This principle calls for a structure in
which each open system is allowed to include any (subset
of) systems-management functions and each subsystem is
allowed to include any (subset of) layer-management
functions; and
b)if it is necessary, connections between management entities
are established when an open system which has been
operating in isolation from other open systems, becomes
part of the OSI environment.
Note – Other principles are for further study.
6 Introduction
6.1 Specific layers
The general structure of the OSI architecture described in
division 5 provides architectural concepts from which the Reference
Model of Open Systems Interconnection has been derived, making
specific choices for the layers and their contents.
The Reference Model contains seven layers:
a)the Application Layer (layer 7);
b)the Presentation Layer (layer 6);
c)the Session Layer (layer 5);
d)the Transport Layer (layer 4);
e)the Network Layer (layer 3);
f)the Data Link Layer (layer 2); and
g)the Physical Layer (layer 1).
These layers are illustrated in Figure 12/X.200. The highest
layer is the Application Layer and it consists of the application-
entities that cooperate in the OSI environment. The lower layers
provide the services through which the application-entities
cooperate.
Layers 1-6, together with the physical media for OSI provide a
step-by-step enhancement of communication services. The boundary
between two layers identifies a stage in this enhancement of
services at which an OSI service Recommendation is defined, while
the functioning of the layers is governed by OSI protocol
Recommendations.
Not all open systems provide the initial source or final
destination of data. When the physical media for OSI do not link
all open systems directly, some open systems act only as relay open
systems, passing data to other open systems. The functions and
protocols which support the forwarding of data are then provided in
the lower layers. This is illustrated in Figure 13/X.200.
FIGURE 12/X.200
FIGURE 13/X.200
6.2 The principles used to determine the seven layers in the
Reference Model
The following principles have been used to determine the seven
layers in the Reference Model and are felt to be useful for guiding
further decisions in the development of OSI Recommendations.
Note – It may be difficult to prove that any particular
layering selected is the best possible solution. However, there are
general principles which can be applied to the question of where a
boundary should be placed and how many boundaries should be placed.
P1: do not create so many layers as to make the system
engineering task of describing and integrating the
layers more difficult than necessary;
P2: create a boundary at a point where the description of
services can be small and the number of interactions
across the boundary are minimized;
P3: create separate layers to handle functions that are
manifestly different in the process performed or the
involved technology;
P4: collect similar functions into the same layer;
P5: select boundaries at a point which past experience has
demonstrated to be successful;
P6: create a layer of easily localized functions so that
the layer could be totally redesigned and its protocols
changed in a major way to take advantage of new advances
in architectural, hardware or software technology
without changing the services expected from and provided
to the adjacent layers;
P7: create a boundary where it may be useful at some point
in time to have the corresponding interface
standardized;
Note 1 – Advantages and drawbacks of standardizing
internal interfaces within open systems are not
considered in this Recommendation. In particular,
mention of, or reference to principle P7, should not be
taken to imply usefulness of standards for such internal
interfaces.
Note 2 – It is important to note that OSI per se does
not require interfaces within open systems to be
standardized. Moreover, whenever standards for such
interfaces are defined, adherence to such internal
interface standards can in no way be considered as a
condition of openness.
P8: create a layer where there is a need for a different
level of abstraction in the handling of data, e.g.,
morphology, syntax, semantics;
P9: allow changes of functions or protocols to be made
within a layer without affecting other layers;
and
P10: create for each layer, boundaries with its upper and
lower layer only.
Similar principles have been applied to sublayering:
P11: create further subgrouping and organization of
functions to form sublayers within a layer in cases
where distinct communications services need it;
P12: create, where needed, two or more sublayers with a
common, and therefore minimal functionality
to allow interface operation with adjacent layers; and
P13: allow by-passing of sublayers.
6.3 Layer descriptions
For each of the seven layers identified above, division 7
provides:
a)an outline of the purpose of the layer;
b)a description of the services offered by the layer to the
layer above; and
c)a description of the functions provided in the layer and
the use made of the services provided by the layer below.
The descriptions, by themselves, do not provide a complete
definition of the services and protocols for each layer. These are
the subject of separate Recommendations.
7 Detailed description of the resulting OSI architecture
7.1 Application layer
7.1.1Definitions
7.1.1.1 application-entity
The aspects of an application-process pertinent to OSI.
7.1.1.2 application-service-element
A part of an application-entity which provides an OSI
environment capability, using underlying services where
appropriate.
7.1.1.3 user-element
The representation of that part of the application-process
which uses those application-service-elements needed to accomplish
the communications objectives of that application-process.
7.1.2Purpose
As the highest layer in the Reference Model of Open Systems
Interconnection, the application layer provides a means for the
application-processes to access the OSI environment. Hence the
application layer does not interface with a higher layer. The
application layer is the sole means for the application-processes
to access the OSI environment.
The purpose of the application layer is to serve as the window
between correspondent application-processes which are using the OSI
to exchange meaningful information.
Each application-process is represented to its peer by the
application-entity.
All specifiable application-process parameters of each OSI
environment communications instance are made known to the OSI
environment (and, thus, to the mechanisms implementing the OSI
environment) via the application layer.
7.1.3Services provided to applications-processes
Application-processes exchange information by means of
application-entities, application-protocols, and presentation
services.
As the only layer in the Reference Model that directly
provides services to the application-processes, the application
layer necessarily provides all OSI services directly usable by
application-processes.
The application-entity contains one user-element and a set of
application-service-elements. The user-element represents that part
of the application-process which uses those application-service-
elements needed to accomplish the communications objectives of that
application-process. Application-service-elements may call upon
each other and/or upon presentation services to perform their
function.
The only means by which user-elements in different systems may
communicate is through the exchange of application-protocol-data-
units. These application-protocol-data-units are generated by
application-service- elements.
Note – The application services differ from services provided
by other layers in neither being provided to an upper layer nor
being associated with a service-access-point.
In addition to information transfer, such services may
include, but are not limited to the following:
Note – Some of the services listed below are provided by OSI
management.
a)identification of intended communications partners (e.g.,
by name, by address, by definite description, by generic
description);
b)determination of the current availability of the intended
communication partners;
c)establishment of the authority to communicate;
d)agreement on privacy mechanisms;
e)authentication of intended communication partners;
f)determination of cost allocation methodology;
g)determination of the adequacy of resources;
h)determination of the acceptable quality of service (e.g.,
response time, tolerable error rate, cost vis-a-vis the
previous considerations);
i)synchronization of cooperating applications;
j)selection of the dialogue discipline including the
initiation and release procedures;
k)agreement on the responsibility for error recovery;
l)agreement on procedures for control of data integrity; and
m)identification of constraints on data syntax (character
sets, data structure).
7.1.4Functions within the application layer
The application layer contains all functions which imply
communication between open-systems and are not already performed by
the lower layers. These include functions performed by programs as
well as functions performed by human beings.
When a specific instance of an application-process wishes to
communicate with an instance of an application-process in some
other open-system, it must invoke an instance of an application-
entity in the application layer of its own open-system. It then
becomes the responsibility of this instance of the application
entity to establish an association with an instance of an
appropriate application-entity in the destination open-system. This
process occurs by invocation of instances of entities in the lower
layers. When the association between the two application-entities
has been established, the application-processes can communicate.
7.1.4.1 Grouping of functions in the application layer
An application-entity can be structured internally into groups
of functions. The technique used to express this structure is not
constrained by this Recommendation. Use of one grouping of
functions may depend on use of some other functions, and the active
functions may vary during the lifetime of an association.
The structuring of application-entities into application-
service-elements and the user-element provides an organization of
functions in application-entities. Furthermore, any given subset of
application-service-elements, along with the user-element,
constitutes an application-entity type. Each application-entity
type, and each instance thereof, are unambiguously identifiable.
An application-process may determine the grouping of functions
comprising the application-entity.
Two categories of application-service-elements are recognized:
common-application-service-elements and specific-application-
service-elements. Common-application-service-elements provide
capabilities that are generally useful to a variety of
applications. Specific-application-service-elements provide
capabilities required to satisfy the particular needs of specific
applications (for example, file-transfer, data base access, job
transfer, banking, order-entry). Application entities may contain
application-service-elements from both categories, as illustrated
in Figure 14/X.200.
The partitioning of application-service-elements into these
two categories does not imply the existence of two independent
protocols.
FIGURE 14/X.200
7.1.4.2 Systems-management and application-management
Systems-management functions and application-management
functions are located in the application layer. For details see sub-
division 5.9.
7.1.4.3 Application layer management
In addition to systems- and application-management, there are
other activities specifically related to application layer
management (such as activation and error control). See sub-division
5.9 for the relationship with other management aspects.
7.2 Presentation layer
7.2.1Definitions
7.2.1.1 concrete syntax
Those aspects of the rules used in the formal specification of
data which embody a specific representation of that data.
7.2.1.2 transfer syntax
That concrete syntax used in the transfer of data between open
systems.
7.2.2Purpose
The presentation layer provides for the representation of
information that application-entities either communicate or refer
to in their communication.
The presentation layer covers two complementary aspects of
this representation of information:
a)the representation of data to be transferred between
application-entities; and
b)the representation of the data structure which application-
entities refer to in their communication, along with the
representations of the set of actions which may be
performed on this data structure.
The complementary aspects of the representation of information
outlined above refer to the general concept of transfer syntax.
The presentation layer is concerned only with the syntax,
(i.e., the representation of the data) and not with its semantics,
(i.e., their meaning to the application layer), which is known only
by the application-entities.
The presentation layer provides for a common representation to
be used between application-entities. This relieves application-
entities of any concern with the problem of “common” representation
of information, i.e., it provides them with syntax independence.
This syntax independence can be described in two ways:
a)the presentation layer provides common syntactical elements
which are used by application-entities; and
b)the application-entities can use any syntax and the
presentation layer provides the transformation between
these syntaxes and the common syntax needed for
communication between applicationentities. This
transformation is performed inside the open systems. It is
not seen by other open systems and therefore has no impact
on the standardization of presentation-protocols.
In this Recommendation the approach outlined in b) is used.
7.2.3Services provided to the application layer
The presentation layer provides session-services (see § 7.3)
and the following facilities:
a)transformation of syntax; and
b)selection of syntax.
Tranformation of syntax is concerned with code and character
set conversions, with the modification of the layout of the data
and the adaptation of actions on the data structures. Selection of
syntax provides the means of initially selecting a syntax and
subsequently modifying the selection.
Session-services are provided to application entities in the
form of presentation-services.
7.2.4Functions within the presentation layer
The presentation layer peforms the following functions to help
accomplish the presentation-services:
a)session establishment request;
b)data transfer;
c)negotiation and renegotiation of syntax;
d)transformation of syntax including data transformation,
formatting and special purpose transformations
(e.g., compression); and
e)session termination request.
7.2.4.1 Transformation of syntax
The fact that there is or is not actual transformation of
syntax has no impact on the presentation protocol.
There are three syntactic versions of the data: the syntax
used by the originating application-entity, the syntax used by the
receiving application-entity and the syntax used between
presentation-entities (the transfer syntax). It is clearly possible
that any two or all three of these syntaxes may be identical. The
presentation layer contains the functions necessary to transform
between the transfer syntax and each of the other syntaxes as
required.
There is not a single predetermined transfer syntax for all
OSI. The transfer syntax to be used on a presentation-connection is
negotiated between the correspondent presentation-entities. Thus, a
presentation-entity must know the syntax of its application-entity
and the agreed transfer syntax. Only the transfer syntax needs to
be referred to in the presentation layer protocols.
To meet the service requirements specified by the application-
entities during the intitiation phase, the presentation layer may
utilize any transfer syntax available to it. To accomplish other
service objectives (e.g., data volume reduction to reduce data
transfer cost), syntax transformation may be performed either as a
specific syntax-matching service provided to the application-
entities, or as a function internal to the presentation layer.
7.2.4.2 Negotiation of syntax
Negotiation of syntax is carried out by communication between
presentation-entities on behalf of the application-entities to
determine the form that data will have while in the OSI
environment. The negotiations will determine what transformations
are needed (if any) and where they will be performed. Negotiations
may be limited to the initiation phase or they may occur any time
during a session.
In OSI, the syntaxes used by application-entities that wish to
communicate may be very similar or quite dissimilar. When they are
similar, the transformation functions may not be needed at all;
however, when they are dissimilar, the presentation layer services
provide the means to converse and decide where needed
transformations will take place.
7.2.4.3 Addressing and multiplexing
There is a one-to-one correspondence between presentation-
address and session-address. There is no multiplexing or splitting
in the presentation layer.
7.2.4.4 Presentation layer management
The presentation layer protocols deal with some management
activities of the layer (such as activation and error control). See
sub-division 5.9 for relationship with other management aspects.
7.3 Session layer
7.3.1Definitions
7.3.1.1 quarantine service
A facility of the session-service by which an integral number
of session-service-data-units sent on a session-connection are not
made available to the receiving presentation-entity until
explicitly released by the sending presentation-entity.
7.3.1.2 interaction management
A facility of the session-service which allows correspondent
presentation-entities to control explicitly whose turn it is to
exercise certain control functions.
7.3.1.3 two-way-simultaneous interaction
A mode of interaction where both presentation-entities may
concurrently send and receive.
7.3.1.4 two-way-alternate interaction
A mode of interaction where the presentation-entity with the
turn may send and its correspondent is permitted only to receive.
7.3.1.5 one-way interaction
A form of operation of two-way-alternate interaction in which
the turn can never be exchanged.
7.3.1.6 session-connection synchronization
A facility of the session-service which allows presentation-
entities to define and identify synchronization points and to reset
a session-connection to a predefined state and to agree on a
resynchronization point.
7.3.2Purpose
The purpose of the session layer is to provide the means
necessary for cooperating presentation-entities to organize and
synchronize their dialogue and to manage their data exchange. To do
this, the session layer provides services to establish a session-
connection between two presentation-entities, and to support
orderly data exchange interactions.
To implement the transfer of data between the presentation-
entities, the session-connection is mapped onto and uses a
transport-connection (see § 7.3.4.1).
A session-connection is created when requested by a
presentation-entity at a session-service-access-point. During the
lifetime of the session-connection, session services are used by
the presentation-entities to regulate their dialogue, and to ensure
an orderly message exchange on the session-connection. The session-
connection exists until it is released by either the presentation-
entities or the session-entities. While the session-connection
exists, session services maintain the state of the dialogue even
over data loss by the transport layer.
A presentation-entity can access another presentation-entity
only by initiating or accepting a session-connection. A
presentation-entity may be associated with several session-
connections simultaneously. Both concurrent and consecutive session-
connections are possible between two presentation-entities.
The initiating presentation-entity designates the destination
presentation-entity by a session-address. In many systems, a
transport-address may be used as the session-address, i.e., there
is a one-to-one correspondence between the session-address and the
transport-address. In general, however, there is a many-to-one
correspondence between session-addresses and transport-address.
This does not imply multiplexing of session-connections onto
transport-connections, but does imply that at session-connection
establishment time, more than one presentation-entity is a
potential target of a session-connection establishment request
arriving on a given transport-connection.
7.3.3Services provided to the presentation layer
The following services provided by the session layer are
described below:
a)session-connection establishment;
b)session-connection release;
c)normal data exchange;
d)quarantine service;
e)expedited data exchange;
f)interaction management;
g)session-connection synchronization; and
h)exception reporting.
7.3.3.1 Session-connection establishment
The session-connection establishment service enables two
presentation-entities to establish a session-connection between
themselves. The presentation-entities are identified by session-
addresses used to request the establishment of the session-
connection.
The session-connection establishment service allows the
presentation-entities cooperatively to determine the unique values
of session-connection parameters at the time the session-connection
is established.
Note – The provision for change of session parameters after
session-connection establishment is a candidate for further
extension.
Simultaneous session-connection establishment requests
typically result in a corresponding number of session-connections,
but a session-entity can always reject an incoming request.
The session-connection establishment service provides to the
presentation-entities a session-service-connection identifier which
uniquely specifies the session-connection within the environment of
the correspondent presentation-entities, with a lifetime which may
be greater than the lifetime of the session-connection. This
identifier may be used by the presentation- entities, to refer to
the session-connection during the lifetime of the session-
connection, and may also be used by management-entities for
administrative purposes such as accounting.
7.3.3.2 Session-connection release
The session-connection release service allows presentation-
entities to release a session-connection in an orderly way without
loss of data. It also allows either presentation-entity to request
at any time that a session-connection be aborted; in this case,
data may be lost.
The release of a session-connection may also be initiated by
one of the session-entities supporting it.
7.3.3.3 Normal data exchange
The normal data exchange service allows a sending presentation-
entity to transfer a session-service-data-unit to a receiving
presentation-entity. This service allows the receiving presentation-
entity to ensure that it is not overloaded with data.
7.3.3.4 Quarantine service
The quarantine service allows the sending presentation-entity
to request that an integral number of session-service-data-units
(one or more) sent on a session-connection should not be made
available to the receiving presentation-entity until explicitly
released by the sending presentation-entity. The sending
presentation-entity may request that all data currently quarantined
be discarded. The receiving presentation-entity receives no
information that data being received has been quarantined or that
some data was discarded.
7.3.3.5 Expedited data exchange
The expedited data exchange service provides expedited
handling for the transfer of expedited session-service-data-units.
A specific size restriction is placed on expedited session-service-
data-units. This service may be used by either presentation-entity
at any time that a session-connection exists.
7.3.3.6 Interaction management
The interaction management service allows the presentation-
entities to control explicitly whose turn it is to exercise certain
control functions.
The service provides for voluntary exchange of the turn where
the presentation-entity which has the turn relinquishes it
voluntarily. This service also provides for forced exchange of the
turn where, upon request from the presentation-entity which does
not have the turn, the session-service may force the presentation-
entity with the turn to relinquish it. In the case of forced
exchange of the turn, data may be lost.
The following types of session-service-data-unit exchange
interaction are defined:
a)two-way-simultaneous (TWS);
b)two-way-alternate (TWA); and
c)one-way interaction.
7.3.3.7 Session-connection synchronization
The session-connection synchronization service allows
presentation-entities to:
a)define and identify synchronization points; and
b)reset the session-connection to a defined state and agree
on a resynchronization point.
The session layer is not responsible for any associated
checkpointing or commitment action associated with synchronization.
7.3.3.8 Exception reporting
The exception reporting service permits the presentation-
entities to be notified of exceptional situations not covered by
other services, such as unrecoverable session malfunctions.
Note – The following services are candidates for future
extensions:
a)session-service-data-unit sequence numbering;
b)brackets;
c)stop-go; and
d)security.
7.3.4Functions within the session layer
The functions within the session layer are those which are
performed by session-entities in order to provide the session
services.
Most of the functions required are readily implied by the
services provided. Additional description is given below for the
following functions:
a)session-connection to transport-connection mapping;
b)session-connection flow control;
c)expedited data transfer;
d)session-connection recovery;
e)session-connection release; and
f)session layer management.
7.3.4.1 Session-connection to transport-connection mapping
There is a one-to-one mapping between a session-connection and
a transport-connection at any given instant. However, the lifetime
of a transport-connection and that of a related session-connection
can be distinguished so that the following cases are defined:
a)a transport-connection supports several consecutive session-
connections (see Figure 15/X.200); and
b)several consecutive transport-connections support a session-
connection (see Figure 16/X.200).
Note 1 – It is also possible to consider cases in which one
transport-connection is used to support several session-connections
(i.e., n-to-1 mapping). In this case peer flow control would be
required in the session layer. This case is for future development
if needed.
Note 2 – To implement the mapping of a session-connection onto
a transport-connection, the session layer maps session-service-data-
units into session-protocol-data-units, and session-protocol-data-
units into transport-service-data-units. These mappings may require
the session-entities to perform functions such as segmenting. These
functions are visible only in the session-protocols, therefore they
are transparent to the presentation and transport layers.
FIGURE 15/X.200
FIGURE 16/X.200
7.3.4.2 Session-connection flow control
There is no peer flow control in the session layer. To prevent
the receiving presentation-entity from being overloaded with data,
the receiving session-entity applies back pressure across the
transport-connection using the transport flow control.
7.3.4.3 Expedited data transfer
The transfer of expedited session-service-data-units is
generally accomplished by use of the expedited transport service.
7.3.4.4 Session-connection recovery
In the event of reported failure of an underlying transport-
connection, the session layer may contain the functions necessary
to re-establish a transport connection to support the session-
connection, which continues to exist. The session-entities involved
notify the presentation-entities via the exception reporting
service that service is interrupted and restore the service only as
directed by the presentation-entities. This permits the
presentationentities to resynchronize and continue from an agreed
state.
7.3.4.5 Session-connection release
The session layer contains the functions necessary to release
the session-connection in an orderly way, without loss of data,
upon request by the presentation-entities. The session layer also
contains the necessary functions to abort the session-connection
with the possible loss of data.
7.3.4.6 Session layer management
The session layer protocols deal with some management
activities of the layer (such as activation and error control). See
sub-division 5.9 for the relationship with other management
aspects.
7.4 The transport layer
7.4.1Definitions
No transport layer specific terms are identified.
7.4.2Purpose
The transport-service provides transparent transfer of data
between session-entities and relieves them from any concern with
the detailed way in which reliable and cost effective transfer of
data is achieved.
The transport layer optimizes the use of the available network-
service to provide the performance required by each session-entity
at minimum cost. This optimization is achieved within the
constraints imposed by the overall demands of all concurrent
session-entities and the overall quality and capacity of the
network-service available to the transport layer.
All protocols defined in the transport layer have end-to-end
significance, where the ends are defined as correspondent transport-
entities. Therefore the transport layer is OSI end open system
oriented and transport-protocols operate only between OSI end open
systems.
The transport layer is relieved of any concern with routing,
and relaying since the network-service provides network-connections
from any transport-entity to any other, including the case of
tandem subnetworks (see § 7.5.1).
The transport functions invoked in the transport layer to
provide a requested service quality depend on the quality of the
network-service. The quality of the network-service depends on the
way the network-service is achieved (see § 7.5.3).
7.4.3Services provided to the session layer
The transport layer uniquely identifies each session-entity by
its transport-address. The transport-service provides the means to
establish, maintain and release transport-connections. Transport-
connections provide duplex transmission between a pair of transport-
addresses.
More than one transport-connection can be established between
the same pair of transport-addresses. A session-entity uses
transport-connection-endpoint-identifiers provided by the transport
layer to distinguish between transport-connection-endpoints.
The operation of one transport-connection is independent of
the operation of all others except for the limitations imposed by
the finite resources available to the transport layer.
The quality of service provided on a transport-connection
depends on the service class requested by the session-entities when
establishing the transport-connection. The selected quality of
service is maintained throughout the lifetime of the transport-
connection. The session-entity is notified of any failure to
maintain the selected quality of service on a given transport-
connection.
The following services provided by the transport layer are
described below:
a)transport-connection establishment;
b)data transfer; and
c)transport-connection release.
7.4.3.1 Transport-connection establishment
Transport-connections are established between session-entities
identified by transport-addresses. The quality of service of the
transport-connection is negotiated between the session-entities and
the transport-service.
At the time of establishment of a transport-connection the
class of transport service to be provided can be selected from a
defined set of available classes of service.
These service classes are characterized by combinations of
selected values of parameters such as throughput, transit delay,
and connection set-up delay and by guaranteed values of parameters
such as residual error rate and service availability.
These classes of service represent globally predefined
combinations of parameters controlling quality of service. These
classes of service are intended to cover the transport-service
requirements of the various types of traffic generated by the
session-entities.
7.4.3.2 Data transfer
This service provides data transfer in accordance with the
agreed quality of service. When the quality of service cannot be
maintained and all possible recovery attempts have failed, the
transport-connection is terminated and the session-entities are
notified.
a)The transport-service-data-unit transfer-service provides
the means by which transport-service-data-units of
arbitrary length are delimited and transparently
transferred in sequence from one sending transport-service-
access-point to the receiving transport-service-access-
point over a transport-connection. This service is subject
to flow control.
b)The expedited transport-service-data-unit transfer service
provides an additional means of information exchange on a
transport-connection. The expedited transport-data-units
are subject to their own set of transport-service and flow
control characteristics. The maximum size of expedited
transport-service data-units is limited.
7.4.3.3 Transport-connection release
This service provides the means by which either session-entity
can release a transport-connection and have the correspondent
session-entity informed of the release.
7.4.4Functions within the transport layer
The transport layer functions may include:
a)mapping transport-address onto network-address;
b)multiplexing (end-to-end) transport-connections onto
network-connections;
c)establishment and release of transport-connections;
d)end-to-end sequence control on individual connections;
e)end-to-end error detection and any necessary monitoring of
the quality of service;
f)end-to-end error recovery;
g)end-to-end segmenting, blocking and concatenation;
h)end-to-end flow control on individual connections;
i)supervisory functions; and
j)expedited transport-service-data-unit transfer.
7.4.4.1 Addressing
When a session-entity requests the transport layer to
establish a transport-connection with another session-entity
identified by its transport-address, the transport layer determines
the network-address identifying the transport-entity which serves
the correspondent session-entity.
Because transport-entities support services on an end-to-end
basis no intermediate transport-entity is involved as a relay
between the end transport-entities. Therefore the transport layer
maps transport-addresses to the network-addresses which identify
the end transport-entities (see Figure 17/X.200).
FIGURE 17/X.200
One transport-entity may serve more than one session-entity.
Several transport-addresses may be associated with one network-
address within the scope of the same transport-entity.
Corresponding mapping functions are perfomed within the transport-
entities to provide these facilities (see Figure 18/X.200).
FIGURE 18/X.200
7.4.4.2 Connection multiplexing and splitting
In order to optimize the use of network-connections, the
mapping of transport-connections onto network-connections need not
be on a one-to-one basis. Both splitting and multiplexing may be
performed, namely for optimizing cost of usage of the network-
service.
7.4.4.3 Phases of operation
The phases of operation within the transport layer are:
a)establishment phase;
b)data transfer phase; and
c)release phase.
The transfer from one phase of operation to another will be
specified in detail within the protocol for the transport layer.
7.4.4.4 Establishment phase
During the establishment phase, the transport layer
establishes a transport-connection between two session-entities.
The functions of the transport layer during this phase match the
requested class of services with the services provided by the
network layer. The following functions may be performed during this
phase:
a)obtain a network-connection which best matches the
requirements of the session-entity taking into account ost
and quality of service;
b)decide whether multiplexing or splitting is needed to
optimize the use of network connections;
c)establish the optimum transport-protocol-data-unit size;
d)select the functions that will be operational upon entering
the data transfer phase;
e)map transport-addresses onto network-addresses;
f)provide identification of different transport-connections
between the same pair of transport-service-access-points
(connection identification function); and
g)transfer of data.
7.4.4.5 Data transfer phase
The purpose of the data transfer phase is to transfer
transport-service-data-units between the two session-entities
connected by the transport-connection. This is achieved by the
transmission of transport-protocol-data-units and by the following
functions, each of which is used or not used according to the class
of service selected in the establishment phase:
a)sequencing;
b)blocking;
c)concatenation;
d)segmenting;
e)multiplexing or splitting;
f)flow control;
g)error detection;
h)error recovery;
i)expedited data transfer;
j)transport-service-data-unit delimiting; and
k)transport-connection identification.
7.4.4.6 Release phase
The purpose of the release phase is to release the transport-
connection. It may include the following functions:
a)notification of reason for release;
b)identification of the transport-connection released; and
c)transfer of data.
7.4.4.7 Transport layer management
The transport layer protocols deal with some management
activities of the layer (such as activation and error control). See
sub-division 5.9 for the relationship with other management
aspects.
7.5 Network layer
7.5.1Definitions
7.5.1.1 subnetwork
A set of one or more intermediate open systems which provide
relaying and through which end systems may establish network-
connections.
Note – A subnetwork is a representation within the OSI
Reference Model of a real network such as a carrier network, a
private network or a local area network.
7.5.1.2 subnetwork-connection
A communication path through a subnetwork which is used by
entities in the network layer in providing a network-connection.
7.5.2Purpose
The network layer provides the means to establish, maintain
and terminate network-connections between open systems containing
communicating application-entities and the functional and
procedural means to exchange network-service-data-units between
transport-entities over network connections.
It provides to the transport-entities independence from
routing and relay considerations associated with the establishment
and operation of a given network-connection. This includes the case
where several subnetworks are used in tandem (see § 7.5.4.2) or in
parallel. It makes invisible to transport-entities how underlying
resources such as data-link-connections are used to provide network-
connections.
Any relay functions and hop-by-hop service enhancement
protocols used to support the network-service between the OSI end
open systems are operating below the transport layer, i.e., within
the network layer or below.
7.5.3Services provided to the transport layer
The basic service of the network layer is to provide the
transparent transfer of data between transport-entities. This
service allows the structure and detailed content of submitted data
to be determined exclusively by layers above the network layer.
All services are provided to the transport layer at a known
cost.
The network layer contains functions necessary to provide the
transport layer with a firm network/transport layer boundary which
is independent of the underlying communications media in all things
other than quality of service. Thus the network layer contains
functions necessary to mask the differences in the characteristics
of different transmission and subnetwork technologies into a
consistent network service.
The service provided at each end of a network-connection is
the same even when a network-connection spans several subnetworks,
each offering dissimilar services (see § 7.5.4.2).
Note – It is important to distinguish the specialized use of
the term “service” within the OSI Reference Model from its common
use by suppliers of private networks and carriers.
The quality of service is negotiated between the transport-
entities and the network-service at the time of establishment of a
network-connection. While this quality of service may vary from one
network-connection to another it will be agreed for a given network-
connection and be the same at both network-connection-endpoints.
The following services or elements of services provided by the
network layer are described below:
a)network-addresses;
b)network-connections;
c)network-connection-endpoint-identifiers;
d)network-service-data-unit transfer;
e)quality of service parameters;
f)error notification;
g)sequencing;
h)flow control;
i)expedited network-service-data-unit transfer;
j)reset;
k)release; and
l)receipt of confirmation.
Some of the services described below are optional. This means
that:
a)the user has to request the service; and
b)the network-service provider may honour the request or
indicate that the service is not available.
7.5.3.1 Network-addresses
Transport-entities are known to the network layer by means of
network-addresses. Network-addresses are provided by the network
layer and can be used by transport-entities to identify uniquely
other transport-entities, i.e., network addresses are necessary for
transport-entities to communicate using the network-service. The
network layer uniquely identifies each of the end open systems
(represented by transport-entities) by their network-addresses.
This may be independent of the addressing needed by the underlying
layers.
7.5.3.2 Network-connections
A network-connection provides the means of transferring data
between transport-entities identified by network-addresses. The
network layer provides the means to establish, maintain and release
network-connections.
A network-connection is point-to-point.
More than one network-connection may exist between the same
pair of network-addresses.
7.5.3.3 Network-connection-endpoint-identifiers
The network layer provides to the transport-entity a network-
connection-endpoint-identifier which identifies the network-
connection-end-point uniquely with the associated network-address.
7.5.3.4 Network-service-data-unit transfer
On a network-connection, the network layer provides for the
transmission of network-service-data-units. These units have a
distinct beginning and end and integrity of the unit's content is
maintained by the network layer.
No limit is imposed on the maximum size of network-service-
data-units.
The network-service-data-units are transferred transparently
between transport-entities.
7.5.3.5 Quality of service parameters
The network layer establishes and maintains a selected quality
of service for the duration of the network-connection.
The quality of service parameters include residual error rate,
service availability, reliability, throughput, transit delay
(including variations), and delay for network-connection
establishment.
7.5.3.6 Error notification
Unrecoverable errors detected by the network layer are
reported to the transport-entities.
Error notification may or may not lead to the release of the
network-connection, according to the specification of a particular
network-service.
7.5.3.7 Sequencing
The network layer may provide sequenced delivery of network-
service-data-units over a given network-connection when requested
by the transport-entities.
7.5.3.8 Flow control
A transport-entity which is receiving at one end of a network-
connection can cause the network-service to stop transferring
network-service-data-units across the service-access-point. This
flow control condition may or may not be propagated to the other
end of the network-connection and thus be reflected to the
transmitting transport-entity, according to the specification of a
particular network-service.
7.5.3.9 Expedited network-service-data-unit transfer (optional)
The expedited network-service-data-unit transfer is optional
and provides an additional means of information exchange on a
network-connection. The transfer of expedited network-service-data-
units is subject to a different set of network-service
characteristics and to separate flow control.
The maximum size of expedited network-service-data-units is
limited.
7.5.3.10 Reset (optional)
The reset service is optional and when invoked causes the
network layer to discard all network-service-data-units in transit
on the network-connection and to notify the transport-entity at the
other end of the network-connection that a reset has occurred.
7.5.3.11 Release
A transport-entity may request release of a network-
connection. The network-service does not guarantee the delivery of
data preceding the release request and still in transit. The
network-connection is released regardless of the action taken by
the correspondent transport-entity.
7.5.3.12 Receipt of confirmation (optional)
A transport-entity may confirm receipt of data over a network-
connection. The use of receipt confirmation service is agreed by
the two users of the network-connection during connection
establishment.
This service is an optional service that may not always be
available.
Note – This service is included in the network service only to
support existing features of CCITT Recommendation X.25.
7.5.4Functions within the network layer
Network layer functions provide for the wide variety of
configurations supporting network-connections ranging from network-
connections supported by point-to-point configurations, to network-
connections supported by complex combinations of subnetworks with
different characteristics.
Note – In order to cope with this wide variety of cases,
network functions should be structured into sublayers. The
subdivision of the network layer into sublayers need only be done
when this is useful. In particular, sublayering need not be used
when the access protocol of the subnetwork supports the complete
functionality of the OSI network service.
The following are functions performed by the network layer:
a)routing and relaying;
b)network-connections;
c)network-connection multiplexing;
d)segmenting and blocking;
e)error detection;
f)error recovery;
g)sequencing;
h)flow control;
i)expedited data transfer;
j)reset;
k)service selection; and
l)network layer management.
7.5.4.1 Routing and relaying
Network-connections are provided by network-entities in end
open systems but may involve intermediate open systems which
provide relaying. These intermediate open systems may interconnect
subnetwork-connections, data-link-connections, and data-circuits
(see § 7.7). Routing functions determine an appropriate route
between network-addresses. In order to set up the resulting
communication, it may be necessary for the network layer to use the
services of the data link layer to control the interconnection of
data-circuits (see §§ 7.6.4.10 and 7.7.3.1).
The control of interconnection of data-circuits (which are in
the physical layer) from the network layer requires interaction
between a network-entity and a physical entity in the same open
system. Since the Reference Model permits direct interaction only
between adjacent layers, the network-entity cannot interact
directly with the physical-entity. This interaction is thus
described as through the data link layer which intervenes
“transparently” to convey the interaction between the network layer
and the physical layer.
This representation is an abstract representation of something
happening inside an open system and which does not model the
functioning of real open systems and as such has no impact on the
standardization of OSI protocols.
Note – When network layer functions are performed by
combinations of several individual subnetworks, the specification
of routing and relaying functions could be facilitated by using
sublayers, isolating individual subnetworks routing and relaying
functions from internetwork routing and relaying functions.
However, when subnetworks have access protocols supporting the
complete functionality of the OSI network service, there need be no
sublayering in the network layer.
7.5.4.2 Network-connections
This function provides network-connections between transport-
entities, making use of data-link-connections provided by the data
link layer.
A network-connection may also be provided as subnetwork-
connections in tandem, i.e., using several individual subnetworks
in series. The interconnected individual subnetworks may have the
same or different service capabilities. Each end of a subnetwork-
connection may operate with a different subnetwork protocol.
The interconnection of a pair of subnetworks of differing
qualities may be achieved in two ways. To illustrate these,
consider a pair of subnetworks, one of high quality and the other
of low quality:
a)The two subnetworks are interconnected as they stand. The
quality of the resulting network-connection is not higher
than that of the lower quality subnetwork (see Figure
19/X.200).
FIGURE 19/X.200
b)The lower quality subnetwork is enhanced equal to the
higher quality subnetwork and the subnetworks are then
interconnected. The quality of the resulting network-
connection is aproximately that of the higher quality
subnetwork (see Figure 20/X.200).
FIGURE 20/X.300
The choice between these two alternatives depends on the
degree of difference in quality, the cost of enhancement, and other
economic factors.
7.5.4.3 Network-connection multiplexing
This function may be used to multiplex network-connections
onto data-link-connections in order to optimize their use.
In the case of subnetwork-connections in tandem, multiplexing
onto individual subnetwork-connections may also be performed in
order to optimize their use.
7.5.4.4 Segmenting and blocking
The network layer may segment and/or block network-service-
data-units for the purpose of facilitating the transfer. However,
the network-service-data-unit delimiters are preserved over the
network-connection.
7.5.4.5 Error detection
Error detection functions are used to check that the quality
of service provided over a network-connection is maintained. Error
detection in the network layer uses error notification from the
data link layer. Additional error detection capabilities may be
necessary to provide the required quality of service.
7.5.4.6 Error recovery
This function provides for recovering from detected errors.
This function may vary depending on the quality of the network
service provided.
7.5.4.7 Sequencing
This function provides for the sequenced delivery of network-
service-data-units over a given network-connection when requested
by transport-entities.
7.5.4.8 Flow control
If flow control service is required (see § 7.5.3.8), this
function may need to be performed.
7.5.4.9 Expedited data transfer
This function provides for the expedited data transfer
service.
7.5.4.10 Reset
This function provides for the reset service.
7.5.4.11 Service selection
This function allows service selection to be carried out to
ensure that the service provided at each end of a network-
connection is the same when a network-connection spans several
subnetworks of dissimilar quality.
7.5.4.12 Network layer management
The network layer protocols deal with some management
activities of the layer (such as activation and error control). See
sub-division 5.9 for the relationship with other management
aspects.
7.6 Data link layer
7.6.1Definitions
No data link layer specific terms are identified.
7.6.2Purpose
The data link layer provides functional and procedural means
to establish, maintain and release data-link-connections among
network-entities and to transfer data-link-service-data-units. A
data-link-connection is built upon one or several physical-
connections.
The data link layer detects and possibly corrects errors which
may occur in the physical layer.
In addition, the data link layer enables the network layer to
control the interconnection of data-circuits within the physical
layer.
7.6.3Services provided to the network layer
The following services or elements of services provided by the
data link layer are described below:
a)data-link-connection;
b)data-link-service-data-units;
c)data-link-connection-endpoint-identifiers;
d)sequencing;
e)error notification;
f)flow control; and
g)quality of service parameters.
7.6.3.1 Data-link-connection
The data link layer provides one or more data-link-connections
between two network-entities. A data-link-connection is always
established and released dynamically.
7.6.3.2 Data-link-service-data-units
The data link layer allows exchange of data-link-service-data-
units over a data-link-connection.
The size of the data-link-service-data-units may be limited by
the relationship between the physical-connection error rate and the
data link layer error detection capability.
7.6.3.3 Data-link-connection-endpoint-identifiers
If needed, the data link layer provides data-link-connection-
endpoint-identifiers that can be used by a network-entity to
identify a correspondent network-entity.
7.6.3.4 Sequencing
When required, the sequence integrity of data-link-service-
data-units is maintained.
7.6.3.5 Error notification
Notification is provided to the network-entity when any
unrecoverable error is detected by the data link layer.
7.6.3.6 Flow control
Each network-entity can dynamically control (up to the agreed
maximum) the rate at which it receives data-link-service-data-units
from a data-link-connection. This control may be reflected in the
rate at which the data link layer accepts data-link-service-data-
units at the correspondent data-link-connection-endpoint.
7.6.3.7 Quality of service parameters
Quality of service parameters may be optionally selectable.
The data link layer establishes and maintains a selected quality of
service for the duration of the data-link-connection. The quality
of service parameters include mean time between detected but
unrecoverable errors, residual error rate (where errors may arise
from alteration, loss, duplication, disordering, misdelivery of
data-link-service-data-unit, and other causes), service
availability, transit delay and throughput.
7.6.4Functions within the data link layer
The following functions performed by the data link layer are
described below:
a)data-link-connection establishment and release;
b)data-link-service-data-unit mapping;
c)data-link-connection splitting;
d)delimiting and synchronization;
e)sequence control;
f)error detection;
g)error recovery;
h)flow control;
i)identification and parameter exchange;
j)control of data-circuit interconnection; and
k)data link layer management.
7.6.4.1 Data-link-connection establishment and release
This function establishes and releases data-link-connections
on activated physical-connections. When a physical-connection has
multiple endpoints (e.g., multipoint connection), a specific
function is needed within the data link layer to identify the data-
link-connections using such a physical-connection.
7.6.4.2 Data-link-service-data-unit mapping
This function maps data-link-service-data-units into data-link-
protocol-data-units on a one-to-one basis.
Note – More general mappings are for further study.
7.6.4.3 Data-link-connection splitting
This function performs splitting of one data-link-connection
onto several physical-connections.
7.6.4.4 Delimiting and synchronization
These functions provide recognition of a sequence of physical-
service-data-units (i.e., bits, see § 7.7.3.2) transmitted over the
physical-connection, as a data-link-protocol-data-unit.
Note – These functions are sometimes referred to as framing.
7.6.4.5 Sequence control
This function maintains the sequential order of data-link-
service-data-units across a data-link-connection.
7.6.4.6 Error detection
This function detects transmission, format and operational
errors occurring either on the physicalconnection, or as a result
of a malfunction of the correspondent data-link-entity.
7.6.4.7 Error recovery
This function attempts to recover from detected transmission,
format and operational errors and notifies the network-entities of
errors which are unrecoverable.
7.6.4.8 Flow control
This function provides the flow control service as indicated
in § 7.6.3.6.
7.6.4.9 Identification and parameter exchange
This function performs data-link-entity identification and
parameter exchange.
7.6.4.10 Control of data-circuit interconnection
This function conveys to network-entities the capability of
controlling the interconnection of data-circuits within the
physical layer.
7.6.4.11 Data link layer management
The data link layer protocols deal with some management
activities of the layer (such as activation and error control). See
§ 5.9 for the relationship with other management aspects.
7.7 Physical layer
7.7.1Definitions
7.7.1.1 data-circuit
A communication path in the physical media for OSI between two
physical-entities, together with the facilities necessary in the
physical layer for the transmission of bits on it.
7.7.2Purpose
The physical layer provides mechanical, electrical, functional
and procedural means to activate, maintain and deactivate physical-
connections for bit transmission between data-link-entities. A
physical-connection may involve intermediate open systems, each
relaying bit transmission within the physical layer. Physical layer
entities are interconnected by means of a physical medium.
7.7.3Services provided to the data link layer
The following services or elements of services provided by the
physical layer are described below:
a)physical-connections;
b)physical-service-data-units;
c)physical-connection-endpoints;
d)data-circuit identification;
e)sequencing;
f)fault condition notification; and
g)quality of service parameters.
7.7.3.1 Physical-connections
The physical layer provide for the transparent transmission of
bit streams between data-link-entities across physical-connections.
A data-circuit is a communication path in the physical media
for OSI between two physical-entities, together with the facilities
necessary in the physical layer for the transmission of bits on it.
A physical-connection may be provided by the interconnection
of data-circuits using relaying functions in the physical layer.
The provision of a physical-connection by such an assembly of data-
circuits is illustrated in Figure 21/X.200.
The control of the interconnection of data-circuits is offered
as a service to data-link-entities.
FIGURE 21/X.200
7.7.3.2 Physical-service-data-units
A physical-service-data-unit consists of one bit in serial
transmission and of “n” bits in parallel transmission.
A physical-connection may allow duplex or half-duplex
transmission of bit streams.
7.7.3.3 Physical-connection-endpoints
The physical layer provides physical-connection-endpoint-
identifiers which may be used by a data-link-entity to identify
physical-connection-endpoints.
A physical-connection will have two (point-to-point) or more
(multi-endpoint) physical-connection-endpoints (see Figure
22/X.200).
7.7.3.4 Data-circuit identification
The physical layer provides identifiers which uniquely specify
the data-circuits between two adjacent open systems.
Note – This identifier is used by network-entities in adjacent
open systems to refer to data-circuits in their dialogue.
FIGURE CCITT 85010
FIGURE 22/X.200
7.7.3.5 Sequencing
The physical layer delivers bits in the same order in which
they were submitted.
7.7.3.6 Fault condition notification
Data-link-entities are notified or fault conditions detected
within the physical layer.
7.7.3.7 Quality of service parameters
The quality of service of a physical-connection is derived
from the data-circuits forming it. The quality of service can be
characterized by:
a)error rate, where errors may arise from alteration, loss,
creation, and other causes;
b)service availability;
c)transmission rate; and
d)transit delay.
7.7.4Functions within the physical layer
The following functions performed by the physical layer are
described below:
a)physical-connection activation and deactivation;
b)physical-service-data-unit transmission; and
c)physical layer management.
7.7.4.1 Physical-connection activation and deactivation
These functions provide for the activation and deactivation of
physical-connections between two data-link-entities upon request
from the data link layer. These include a relay function which
provides for interconnection of data-circuits.
7.7.4.2 Physical-service-data-unit transmission
The transmission of physical-service-data-units (i.e., bits)
may be synchronous or asynchronous.
7.7.4.3 Physical layer management
The physical layer protocols deal with some management
activities of the layer (such as activation and error control). See
sub-division 5.9 for the relationship with other management
aspects.
Note – Relationship of the physical layer with the real
environment
The above text deals with interconnection between open systems
as illustrated in Figure 12/X.200. For open-systems to communicate
in the real environment, real physical connections should be made,
for example as in Figure 23a/X.200. Their logical representation is
as shown in Figure 23b/X.200 and is called the physical media
connection.
FIGURE 23/X.200
The mechanical, electromagnetic and other media dependant
characteristics of physical media connections are defined at the
boundary between the physical layer and the physical media.
Definitions of such characteristics may be found in other
Recommendations.
ANNEX A
(to Recommendation X.200)
Brief explanation of how the layers were chosen
This Annex provides elements giving additional information to
this Recommendation, which are not an integral part of it.
The following is a brief explanation of how the layers were
chosen:
a)It is essential that the architecture permit usage of a
realistic variety of physical media for interconnection
with different control procedures (e.g., V.24, V.25, etc.).
Application of principles P3, P5 and P8 leads to
identification of a Physical Layer as the lowest layer in
the architecture.
b)Some physical communication media (e.g. telephone line)
require specific techniques to be used in order to transmit
data between systems despite a relatively high error rate
(i.e., an error rate not acceptable for the great majority
of applications). These specific techniques are used in
data-link control procedures which have been studied and
standardized for a number of years. It must also be
recognized that new physical communication media (e.g.,
fibre optics) will require different data link control
procedures. Application of principles P3, P5 and P8 leads
to identification of a Data Link Layer on top of the
Physical Layer in the architecture.
c)In the open system architecture, some open systems will act
as the final destination of data, see division 4. Some open
systems may act only as intermediate nodes (forwarding data
to other open systems), see Figure 13/X.200. Application of
principles P3, P5 and P7 leads to identification of a
Network Layer on top of the Data Link Layer. Network
oriented protocols such as routing, for example, will be
grouped in this layer. Thus, the Network Layer will provide
a connection path (network-connection) between a pair of
transport-entities, including the case where intermediate
nodes are involved, see Figure 13/X.200 (see also §
7.5.4.1).
d)Control data transportation from source end open system to
destination end open system (which is not performed in
intermediate nodes) is the last function to be performed in
order to provide the totality of the transport-service.
Thus, the upper layer in the transport-service part of the
architecture is the Transport Layer, on top of the Network
Layer. This Transport Layer relieves higher layer entities
from any concern with the transportation of data between
them.
e)There is a need to organize and synchronize dialogue, and
to manage the exchange of data. Application of principles
P3 and P4 leads to the identification of a Session Layer on
top of the Transport Layer.
f)The remaining set of general interest functions are those
related to representation and manipulation of structured
data for the benefit of application programs. Application
of principles P3 and P4 leads to identification of a
Presentation Layer on top of the Session Layer.
g)Finally, there are applications consisting of application
processes which perform information processing. An aspect
of these application processes and the protocols by which
they communicate comprise the Application Layer as the
highest layer of the architecture.
The resulting architecture with seven layers, illustrated in
Figure 12/X.200 obeys principles P1 and P2.
A more detailed definition of each of the seven layers
identified above is given in division 7 of this Recommendation,
starting from the top with the Application Layer described in § 7.1
down to the Physical Layer described in § 7.7.
ANNEX B
(to Recommendation X.200)
Alphabetical index to definitions
Section
acknowledgement
5.7.1.16
(N)-address
5.4.1.6
(N)-address-mapping
5.4.1.8
application-entity
7.1.1.1
application-management
5.9.1.1
application-management-application-entity
5.9.1.2
application-process
4.1.4
application-service-element
7.1.1.2
blocking
5.7.1.11
centralized multi-endpoint-connection
5.7.1.2
concatenation
5.7.1.13
concrete syntax
7.2.1.1
(N)-connection
5.3.1.1
(N)-connection-endpoint
5.3.1.2
(N)-connection-endpoint-identifier
5.4.1.10
(N)-connection-endpoint-suffix
5.4.1.11
correspondent (N)-entities
5.3.1.4
data-circuit
7.7.1.1
(N)-data communication
5.3.1.12
(N)-data sink
5.3.1.7
(N)-data source
5.3.1.6
(N)-data transmission
5.3.1.8
deblocking
5.7.1.12
decentralized multi-endpoint-connection
5.7.1.3
demultiplexing
5.7.1.5
(N)-directory
5.4.1.7
(N)-duplex transmission
5.3.1.9
(N)-entity
5.2.1.3
expedited (N)-service-data-unit
5.6.1.8
(N)-expedited-data-unit
5.6.1.8
(N)-facility
5.2.1.7
flow control
5.7.1.8
(N)-function
5.2.1.8
global-title
5.4.1.5
(N)-half-duplex transmission
5.3.1.10
interaction-management
7.3.1.2
(N)-interface-control-information
5.6.1.4
(N)-interface-data
5.6.1.5
(N)-interface-data-unit
5.6.1.6
(N)-layer
5.2.1.2
layer-management
5.9.1.6
local-title
5.4.1.4
multi-connection-endpoint-identifier
5.4.1.12
multi-endpoint-connection
5.3.1.3
multiplexing
5.7.1.4
(N)-one-way communication
5.3.1.15
one-way-interaction
7.3.1.5
open system
4.1.3
OSI resources
5.9.1.3
peer-entities
5.2.1.4
(N)-protocol
5.2.1.10
(N)-protocol-connection-identifier
5.4.1.14
(N)-protocol-control-information
5.6.1.1
(N)-protocol-data-unit
5.6.1.3
(N)-protocol-identifier
5.7.1.1
quarantine service
7.3.1.1
real system
4.1.1
real open system
4.1.2
reassembling
5.7.1.10
recombining
5.7.1.7
(N)-relay
5.3.1.5
reset
5.7.1.17
routing
5.4.1.9
segmenting
5.7.1.9
separation
5.7.1.14
sequencing
5.7.1.15
(N)-service
5.2.1.6
(N)-service-access-point
5.2.1.9
(N)-service-access-point-address
5.4.1.6
(N)-service-connection-identifier
5.4.1.13
(N)-service-data-unit
5.6.1.7
session-connection synchronization
7.3.1.6
(N)-simplex transmission
5.3.1.11
splitting
5.7.1.6
sublayer
5.2.1.5
subnetwork
7.5.1.1
subnetwork-connection
7.5.1.2
(N)-subsystem
5.2.1.1
(N)-suffix
5.4.1.15
systems-management
5.9.1.4
systems-management-application-entity
5.9.1.5
title
5.4.1.1
title-domain
5.4.1.2
title-domain-name
5.4.1.3
transfer-syntax
7.2.1.2
(N)-two-way-alternate communication
5.3.1.14
two-way-alternate interaction
7.3.1.4
(N)-two-way-simultaneous communication
5.7.1.13
two-way-simultaneous interaction
7.3.1.3
(N)-user-data
5.6.1.2
user-element
7.1.1.3
_______________________________
1) Recommendation X.200 and ISO 7498 [Information Processing
Systems - Open Systems Interconnection - Basic Reference Model]
were developed in close collaboration and are technically
aligned.
2) Other types of multi-endpoint-connections are for further
study.
3) This definitions are not for use in this Recommendation but
are for use in future OSI Recommendations.