ISO Presentation on TCP: ISO presentation services on top of TCP/IP based internets
A pared-down way to run OSI applications on TCP/IP without building the whole OSI stack.
Rose, M.T., "ISO presentation services on top of TCP/IP based internets", RFC 1085, DOI 10.17487/RFC1085, December 1988, <https://www.rfc-editor.org/info/rfc1085>.
@misc{rfc1085,
series = {Request for Comments},
number = 1085,
howpublished = {RFC 1085},
publisher = {RFC Editor},
doi = {10.17487/RFC1085},
url = {https://www.rfc-editor.org/info/rfc1085},
author = {M.T. Rose},
title = {{ISO presentation services on top of TCP/IP based internets}},
pagetotal = 32,
year = 1988,
month = dec,
} RFC text
Contents
Network Working Group M. Rose
Request for Comments: 1085 TWG
December 1988
ISO Presentation Services
on top of TCP/IP-based internets
Status of this Memo
This memo proposes a standard for the Internet community.
Distribution of this memo is unlimited.
1. Introduction
[RFC1006] describes a mechanism for providing the ISO transport
service on top of the Transmission Control Protocol (TCP) [RFC793]
and Internet Protocol (IP) [RFC791]. Once this method is applied,
one may implement "real" ISO applications on top of TCP/IP-based
internets, by simply implementing OSI session, presentation, and
application services on top of the transport service access point
which is provided on top of the TCP. Although straight-forward,
there are some environments in which the richness provided by the OSI
application layer is desired, but it is nonetheless impractical to
implement the underlying OSI infrastructure (i.e., the presentation,
session, and transport services on top of the TCP). This memo
describes an approach for providing "stream-lined" support of OSI
application services on top of TCP/IP-based internets for such
constrained environments.
2. Terminology
In as much as this memo is concerned primarily with concepts defined
in the framework of Open Systems Interconnection (OSI) as promulgated
by the International Organization for Standardization (ISO), the
terminology used herein is intended to be entirely consistent within
that domain of discourse. This perspective is being taken despite
the expressed intent of implementing the mechanism proposed by this
memo in the Internet and other TCP/IP-based internets. For those
more familiar with the terminology used in this latter domain, the
author is apologetic but unyielding.
Although no substitute for the "correct" definitions given in the
appropriate ISO documents, here is a short summary of the terms used
herein.
Application Context:
The collection of application service elements which
cooperatively interact within an application-entity.
Application Service Element:
A standardized mechanism, defined by both a service and a
protocol, which provides a well-defined capability, e.g.,
ROSE - the Remote Operations Service Element,
which orchestrates the invocation of "total"
operations between application-entities [ISO9066/2].
ACSE - the Association Control Service Element,
which manages associations between application
entities [ISO8650].
Object Identifier:
An ordered set of integers, used for authoritative
identification.
Presentation Service:
A set of facilities used to manage a connection between two
application-entities. The fundamental responsibility of the
presentation service is to maintain transfer syntaxes which
are used to serialize application protocol data units for
transmission on the network and subsequent de-serialization
for reception.
Protocol Data Unit (PDU):
A data object exchanged between service providers.
Serialization:
The process of applying an abstract transfer notation to an
object described using abstract syntax notation one (ASN.1)
[ISO8824] in order to produce a stream of octets.
De-serialization is the inverse process.
It is assumed that the reader is familiar with terminology
pertaining to the reference model [ISO7498], to the service
conventions in the model [ISO8509], and to the
connection-oriented presentation service [ISO8822].
3. Scope
The mechanism proposed by this memo is targeted for a particular
class of OSI applications, namely those entities whose application
context contains only an Association Control Service Element (ACSE)
and a Remote Operations Service Element (ROSE). In addition, a
Directory Services Element (DSE) is assumed for use by the
application-entity, but only in a very limited sense. The
organization of such an entity is as follows:
+------------------------------------------------------------+
| |
| Application-Entity |
| |
| +------+ +------+ +------+ |
| | ACSE | | ROSE | | DSE | |
| +------+ +------+ +------+ |
| |
+------------------------------------------------------------+
| |
| Presentation Services |
| |
| P-CONNECT P-RELEASE P-DATA |
| P-U-ABORT |
| P-P-ABORT |
| |
+------------------------------------------------------------+
The mechanism proposed by this memo is not applicable to entities
whose application context is more extensive (e.g., contains a
Reliable Transfer Service Element). The mechanism proposed by this
memo could be modified to support additional elements. However, such
extensions would, at this time, merely serve to defeat the purpose of
providing the minimal software infrastructure required to run the
majority of OSI applications.
The motivation for this memo was initially derived from a requirement
to run the ISO Common Management Information Protocol (CMIP) in
TCP/IP-based internets. In its current definition, CMIP uses
precisely the application service elements provided for herein. It
may be desirable to offer CMIP users a quality of service different
than the one offered by a connection with a high-quality level of
reliability. This would permit a reduced utilization of connection-
related resources. This memo proposes a mechanism to implement this
less robust -- and less costly -- quality of service.
4. Approach
The approach proposed by this memo relies on the following
architectural nuances:
- the TCP is a stream-oriented transport protocol
- ASN.1 objects, when represented as a stream of octets are
self-delimiting
- The ISO presentation service permits the exchange of ASN.1
objects
- The ACSE and ROSE require the following presentation
facilities:
The Connection Establishment Facility
The Connection Termination Facility
The Information Transfer Facility (P-DATA
service only)
- The majority of the parameters used by the services which
provide these facilities can be "hard-wired" to avoid
negotiation
In principle, these nuances suggest that a "cheap" emulation of the
ISO presentation services could be implemented by simply serializing
ASN.1 objects over a TCP connection. This approach is precisely what
is proposed by this memo.
Given this perspective, this memo details how the essential features
of the ISO presentation service may be maintained while using a
protocol entirely different from the one given in [ISO8823]. The
overall composition proposed by this memo is as follows:
+-----------+ +-----------+
| PS-user | | PS-user |
+-----------+ +-----------+
| |
| PS interface PS interface |
| [ISO8822] |
| |
+----------+ ISO Presentation Services on the TCP +----------+
| client |-----------------------------------------| server |
+----------+ (this memo) +----------+
| |
| TCP interface TCP interface |
| [RFC793] |
| |
In greater detail, the "client" and "server" boxes implement the
protocol described in this memo. Each box contains three modules:
- a dispatch module, which provides the presentation services
interface,
- a serialization module, containing a serializer, which takes
an ASN.1 object and applies the encoding rules of [ISO8825]
to produce a stream of octets, and a de-serializer, which
performs the inverse operation, and
- a network module, which manages a TCP connection.
The software architecture used to model a network entity using this
approach is as follows:
+---------+ +----------+ +-----+
| | | | output +---------------+ input | n |
| | | |<--------| de-serializer |<--------| e |
| | | | queue +---------------+ queue | t |
| PS-user |----| dispatch | | w |
| | | | input +---------------+ output | o |
| | | |-------->| serializer |-------->| r |
| | | | queue +---------------+ queue | k |
+---------+ +----------+ +-----+
|---- serialization module ----|
The ISO presentation layer is concerned primarily with the
negotiation of transfer syntaxes in addition to the transformation to
and from transfer syntax. However, using the mechanism proposed by
this memo, no negotiation component will be employed. This memo
specifies the fixed contexts which exist over each presentation
connection offered. This memo further specifies other constants
which are used in order to eliminate the need for presentation layer
negotiation.
5. Fundamental Parameters
There are certain parameters which are used by the presentation
service and are defined here.
1. Presentation address:
The structure of a presentation address is presented in Addendum 3
to [ISO7498]. This memo interprets a presentation address as an
ordered-tuple containing:
- one or more network addresses
- a transport selector
- a session selector
- a presentation selector
Each selector is an uninterpreted octet string of possibly zero
length. The mechanism proposed in this memo completely ignores
the values of these selectors. Note however that the value of the
presentation selector is preserved by the provider.
A network address is interpreted as containing three components:
- a 32-bit IP address
- a set indicating which transport services are available
at the IP address (currently only two members are defined:
TCP and UDP; as experience is gained, other transport
services may be added); as a local matter, if a member is
present it may have an "intensity" associated with it:
either "possibly present" or "definitely present"
- a 16-bit port number
As a consequence of these interpretations, any application-entity
residing in the network can be identified by its network address.
2. Presentation context list
A list of one or more presentation contexts. Each presentation
context has three components:
- a presentation context identifier (PCI), an integer
- an abstract syntax name, an object identifier
- an abstract transfer name, an object identifier
The range of values these components may take is severely
restricted by this memo. In particular, exactly two contexts are
defined: one for association control and the other for the
specific application service element which is being carried as ROS
APDUs (see the section on connection establishment for the precise
values).
In addition, if the presentation context list appears in a
"result" list (e.g., the Presentation context result list
parameter for the P-CONNECT service), a fourth component is
present:
- an acceptance indicator
which indicates if the context was accepted by both the service
provider and the remote peer. If the context was not accept, a
brief reason, such as "abstract syntax not supported" is given.
For the novice reader, one might think of the abstract syntax
notation as defining the vocabulary of some language, that is, it
lists the words which can be spoken. In contrast, the abstract
transfer notation defines the pronunciation of the language.
3. User data
User data passes through the presentation service interface as
ASN.1 objects (in a locally defined form). Associated with each
object is a presentation context identifier. The PCI
distinguishes the context for which the data is intended. The
range of values the PCI may take is severely restricted by this
memo. Exactly one of two contexts must always be used: either the
value for the ACSE presentation context or the value for the ROSE.
4. Quality of Service
Quality of service is a collection of "elements". Each element
denotes some characteristics of the communication, e.g., desired
throughput, and some value in an arbitrary unit of measure. For
our purposes, only one quality of service element is interpreted,
"transport-mapping". Currently, the "transport-mapping" element
takes on one of two values: "tcp-based" or "udp-based". At
present, the two values may also be referred to as "high-quality"
or "low-quality", respectively.
As experience is gained, other values may be added. These values
would correspond directly to the new transport services which are
listed in the network address.
5. Version of Session Service
Some application service elements (e.g., the ACSE) invoke
different procedures based on the (negotiated) version of the
session service available. Implementations of this memo always
indicate that session service version 2 has been negotiated.
6. Choice of Transport Service
Discussion thus far has centered along the use of the TCP as the
underlying transport protocol. However, it has also been noted that
it may be desirable to permit a quality of service with less
reliability in order to take advantage of some other characteristic
of the transport service.
The introduction of this service has several profound impacts on the
model, and it is beyond the scope of this memo to enumerate these
impacts. However, this memo does propose a mechanism by which such a
facility is implemented.
To begin, we use the quality of service parameter for the P-CONNECT
service to select an underlying transport service. Only one element
is currently interpreted, "transport-mapping" which takes the value
"tcp-based" or "udp-based". If the value is "tcp-based", then the
presentation provider will use TCP as the underlying transport
service. If, however, the value of "transport-mapping" is "udp-
based", then the presentation provider will use the UDP instead.
The User Datagram Protocol (UDP) [RFC768] is used to implement the
udp-based service. Very few transport-level facilities are placed on
top of the UDP service, i.e., it is not the intent of this memo to
"re-invent" the facilities in the TCP. Hence, It is critical to
understand that
low-quality means LOW-QUALITY!
Because the UDP is a packet-oriented protocol, it is necessary to
slightly redefine the role of the serialization module. For the
serializer, we say that each top-level ASN.1 object placed on the
input queue will form a single UDP datagram on the output queue which
is given to the network. Similarly, for the de-serializer, we say
that each UDP datagram placed on the input queue from the network
will form a single top-level ASN.1 object placed on the output queue.
The term "top-level ASN.1 object" refers, of course, to the protocol
data units being exchanged by the presentation providers.
It should be noted that in its current incarnation, this memo permits
the choice of two different transport protocols, e.g., the TCP or the
UDP. However, as experience is gained and as other transport
protocols are deployed (e.g., the VMTP), then future incarnations of
this memo will permit these transport protocols to be used. This is
a three step process: first, the set of transport services defined
for the network address is updated; second, a corresponding value is
added to the range of the quality of service element "transport-
mapping"; and, third, the following sections of this memo are
modified accordingly.
7. Connection Establishment
The Connection Establishment facility consists of one service, the
P-CONNECT service.
7.1. The P-CONNECT Service
This service is used to bring two identified application-entities
into communication. Its successful use results in a presentation
connection, with an initial defined context set, being established
between then. This connection is available for their subsequent
communication. This is a confirmed service whose effects are
sequenced and non-destructive.
If the udp-based service is selected, then a presentation connection
is formed which should be used infrequently and will have minimal
reliability characteristics.
For our purposes, the P-CONNECT service:
- requests TCP or UDP resources,
- builds a fixed defined context set, and
- exchanges initial user data.
Following are the interpretation of and the defaults assigned to the
parameters of the P-CONNECT service:
1. Calling Presentation Address
This is a presentation address. Although the ISO presentation
service states that this parameter is mandatory, in practice, a
local implementation rule may be used to determine an
"ephemeral" address to use.
2. Called Presentation Address
This is a presentation address. Note that when issuing the P-
CONNECT.REQUEST primitive, this parameter may contain more than
one network address. In the P-CONNECT.INDICATION primitive
however, only one network address, the one actually used to
establish the presentation connection, is present. (Appendix C
describes a strategy which might be used to determine the actual
network address).
3. Responding Presentation Address
This parameter is identical to the value of the Called
Presentation Address parameter of the P-CONNECT.INDICATION
primitive.
4. Multiple defined Contexts
Always TRUE. Note that this parameter is present only in the
DIS version of the presentation service.
5. Presentation context definition list
Two contexts are defined:
PCI Abstract Syntax Name Abstract Transfer Name
--- -------------------- ----------------------
1 specific to the application "iso asn.1 abstract
transfer"
1.0.8825
3 "acse pci version 1" "iso asn.1 abstract
transfer"
2.2.1.0.0 1.0.8825
The abstract syntax and transfer names for the ACSE PCI are for
use with the DIS version of association control. If the IS
version is being used, then this PCI is used instead:
3 "acse pci version 1" "asn.1 basic encoding"
2.2.1.0.1 2.1.1
6. Presentation context result list
Identical to the Presentation context definition list with the
addition that the acceptance indicator for both contexts is
"accepted".
7. Default Context Name
None.
8. Default Context Result
Not applicable.
9. Quality of Service
The element "transport-mapping" takes the value "tcp-based" or
"udp-based". In the future the range of values may be extended.
10. Presentation Requirements
None (the kernel functional unit is always used).
11. Session Requirements
Full duplex.
12. Initial synchronization point serial number
None.
13. Initial Assignment of tokens
None.
14. Session connection identifier
Unlike the "real" presentation service, depending on the quality
of service selected, this parameter may have great significance
to presentation provider. Hence, the following format of the
session connection identifier is mandated by this memo.
user data: a local string encoded as a T.61 string
using ASN.1, e.g., given string "gonzo":
14 05 67 6f 6e 7a 6f
tag length "g" "o" "n" "z" "o"
common data: a universal time encoding using ASN.1, e.g.,
given time "880109170845":
17 0c 38 38 30 31 30 ...
tag length "8" "8" "0" "1" "0" ...
additional data: any string encoded as a T.61 string using ASN.1
(optional)
As a local convention, the presentation provider may disregard
the first two octets of each data component for transmission on
the network as when the session connection identifier is
represented with ASN.1, the tag and length octets will be added
anyway.
15. User Data
A single ASN.1 object is present, the appropriate A-ASSOCIATE
PDU, carried in presentation context 3.
16. Result
One of the following values: acceptance, user-rejection,
provider-rejection (transient), or provider-rejection
(permanent).
8. Connection Termination
The Connection Termination facility consists of three services, the
P-RELEASE, P-U-ABORT, and P-P-ABORT services.
8.1. The P-RELEASE Service
This service provides the service user with access to a negotiated
release facility. This service has effects which are sequenced and
non-destructive. Either presentation user is permitted to request
this service. However, in the event of collision, a provider-
initiated abort procedure will be invoked.
If the udp-based service is selected, then any data in transit may be
discarded.
For our purposes, the P-RELEASE service:
- waits for the serialization module to drain,
- sends release user data, and
- releases TCP or UDP resources
Following are the interpretation of and the defaults assigned to the
parameters of the P-RELEASE service:
1. Result
Release accepted.
2. User data
A single ASN.1 object is present, the appropriate A-RELEASE PDU,
8.2. The P-U-ABORT Service
This service can be used by either presentation user to force the
release of a presentation connection at any time and have the
correspondent presentation user informed of this termination. This
service has effects which are not sequenced with respect to preceding
service invocations and may be destructive. It does not require the
agreement of both service users.
For our purposes, the P-U-ABORT service:
- flushes the serialization module,
- sends abort user data, and
- releases TCP or UDP resources
Following are the interpretation of and the defaults assigned to the
parameters of the P-U-ABORT service:
1. Presentation context identifier list
Contained in the ASN.1 objects, if any, that are delivered as
user data.
2. User data
A single ASN.1 object is present, an A-ABORT PDU, carried in
presentation context 3.
8.3. The P-P-ABORT Service
This service is the means by which the service provider may indicate
the termination of the presentation connection for reasons internal
to the service provider. This service has effects which are not
sequenced with respect to preceding service invocations. The
execution of this service disrupts any other concurrently active
service and may thus be destructive.
For our purposes, the P-P-ABORT service:
- flushes the serialization module, and
- releases TCP or UDP resources
Following are the interpretation of and the defaults assigned to the
parameters of the P-P-ABORT service.
1. Provider reason
An integer code detailing why the connection was aborted. Codes
include, but are not limited to: invalid PPDU parameter,
unexpected PPDU, unrecognized PPDU, and specified reason.
2. Abort data
None.
9. Information Transfer
Although the Information Transfer facility consists of many services,
only one, the P-DATA service, is provided by this memo.
9.1. The P-DATA Service
This services provides the service user with a data transfer
capability. This service has effects which are sequenced and non-
destructive.
If the udp-based service is selected, then there is an upper-bound on
the size of the serialized ASN.1 objects which may be transmitted.
This limit, imposed by the UDP, is 65536 octets. As a practical
matter, it is probably a good idea to keep datagrams less than or
equal to 536 octets in size.
For our purposes, the P-DATA service:
- sends user data
Following are the interpretation of and the defaults assigned to the
parameters of the P-DATA service:
1. User data
A single ASN.1 object is present, a remote operations APDU,
carried in presentation context 1.
10. Elements of Procedure
The service provider is in one of the following states:
IDLE, WAIT1, WAIT2, DATA, WAIT3, or WAIT4
The possible events are:
PS-user P-CONNECT.REQUEST
P-CONNECT.RESPONSE
P-RELEASE.REQUEST
P-RELEASE.RESPONSE
P-DATA.REQUEST
P-U-ABORT.REQUEST
network TCP closed or errored(*)
receive ConnectRequest PDU
receive ConnectResponse PDU
receive ReleaseRequest PDU
receive ReleaseResponse PDU
receive UserData(*) or CL-UserData(**) PDU
receive user-initiated Abort PDU
receive provider-initiated Abort PDU
timer expires(**)
The possible actions are:
PS-user P-CONNECT.INDICATION
P-CONNECT.CONFIRMATION
P-RELEASE.INDICATION
P-RELEASE.CONFIRMATION
P-DATA.INDICATION
P-U-ABORT.INDICATION
P-P-ABORT.INDICATION
network open TCP(*)
close TCP(*)
send ConnectRequest PDU
send ConnectResponse PDU
send ReleaseRequest PDU
send ReleaseResponse PDU
send UserData(*) or CL-UserData(**) PDU
send user-initiated Abort PDU
send provider-initiated Abort PDU
set timer(**)
(*) tcp-based service only
(**) udp-based service only
10.1. Elements of Procedure specific to the tcp-based service
The provider maintains the following information for each
presentation connection:
- a local designator for the PS-user
- a local designator for a TCP connection
- the state of the connection (e.g., IDLE, WAIT1, and so on)
Upon receiving an event from the network, the provider finds the
associated presentation connection. Matching is done by simply
comparing local designators for the TCP connection. Whenever a
connection remains in or returns to the IDLE state, any associated
resources, such as an attachment to a local TCP port, are released.
In the procedures which follow, outgoing PDUs are "placed on the
input queue for the serializer". This has a different meaning
depending on the type of PDU being enqueued. If the PDU is not an
abort PDU (user-initiated or provider-initiated), then the PDU is
simply appended to the input queue regardless of the number of PDUs
present. If however, the PDU is an abort PDU, then the provider
checks the size of the input queue. If the input queue is non-empty
or if the serializer is busy transmitting to the network, then the
abort PDU is discarded, and the serializer is flushed, aborting any
output to the network in progress. However, if the input queue is
empty, then the Abort PDU is appended to the queue, and a small timer
started. If the timer expires before the PDU has been serialized and
transmitted, then the serializer is flushed, aborting any output to
the network in progress.
Further, in general, whenever the TCP connection is closed (either
locally by the provider, or remotely by the network) or has errored,
the serializer is flushed. The one exception to this is if a
ReleaseResponse PDU is being serialized and transmitted to the
network. In this case, the provider will not close the TCP
connection until after the serializer has finished.
10.2. Elements of Procedure specific to the udp-based service
The provider maintains the following information for each
presentation connection:
- a local designator for the PS-user
- the 32-bit IP address and 16-bit UDP port number of the
initiating host
- the 32-bit IP address and 16-bit UDP port number of the
responding host
- the session connection identifier used to establish the
presentation connection
- a local designator for an UDP endpoint
- the state of the connection (e.g., IDLE, WAIT1, and so on)
- a retransmission counter
Upon receiving an event from the network, the provider finds the
associated presentation connection. Matching is done on the basis of
addresses, ports, and the session connection identifier (i.e., two
different presentation connections may differ only in their session
connection identifier). If no presentation connection can be found,
then for the purposes of discussion, it may be assumed that a
"vanilla" presentation connection is created and initialized to the
IDLE state. Further, whenever a connection remains in or returns to
the IDLE state, any associated resources, such as an attachment to a
local UDP port, are released.
In the procedures which follow, outgoing PDUs are "placed on the
input queue for the serializer". This means that the ASN.1 object is
serialized and the resulting sequence of octets is sent as a single
UDP datagram.
10.3. State Transitions
Following are the rules for transitioning states. If an event
associated with a user-generated primitive is omitted, then it is an
interface error for the user to issue that primitive in the given
state. Each state considers all possible incoming PDUs.
We assume that for the tcp-based service, that some entity starts a
passive TCP open. When the passive open completes, the entity, using
some local rule, locates a PS-user to be associated with the incoming
presentation connection. This presentation connection is then placed
in the IDLE state. The entity then continues listening for other
passive opens to complete. The mechanisms associated with this
entity are entirely a local matter, the concept of this listener is
introduced solely as a modeling artifact.
Finally, if the udp-based service is selected, then CL-UserData PDUs
are exchanged by the provider instead of UserData PDUs.
IDLE state
Event: P-CONNECT.REQUEST primitive issued
Based on the quality of service parameter and the list of network
addresses in the called presentation address parameter, the provider
selects an address for the use of the presentation connection. The
method for making this determination is a local matter. (Appendix C
discusses a strategy which might be used.) For the discussion that
follows, we assume that a network address supporting the desired
quality of service has been determined.
Based on the network address chosen from the called presentation
address parameter, the provider selects a compatible network address
from the calling presentation address parameter. The provider
attaches itself to the port associated with this network address.
(By local determination, this address need not be used, and an
"ephemeral" port may be chosen by the provider.)
For the tcp-based service, the provider attempts to establish a TCP
connection to the network address listed in the called presentation
address. If the connection can not be established, the P-
CONNECT.CONFIRMATION(-) primitive is issued with a reason of
provider-rejection, and the provider remains in the IDLE state.
Regardless, the user data parameter is placed in a ConnectRequest
PDU, which is put on the input queue for the serializer.
For the udp-based service, the provider sets the retransmission
counter to a small value (e.g., 2), and now starts a small timer.
Regardless, the provider enters the WAIT1 state.
Event: ConnectRequest PDU received
The provider issues the P-CONNECT.INDICATION primitive and enters the
WAIT2 state.
Event: any other PDU received
If the PDU is not an Abort PDU, the provider constructs a provider-
initiated Abort PDU, which is put on the input queue for the
serializer. Regardless, the provider remains in the IDLE state.
WAIT1 state
Event: P-U-ABORT.REQUEST primitive issued
The user data parameter is placed in an Abort PDU, which is put on
the input queue for the serializer. The provider enters the IDLE
state.
Event: ConnectResponse PDU received
For the udp-based service, the timer is cancelled. If the PDU
indicates rejection, the P-CONNECT.CONFIRMATION(-) primitive is
issued and the provider enters the IDLE state. Otherwise, the P-
CONNECT.CONFIRMATION(+) primitive is issued and the provider enters
the DATA state.
Event: user-initiated Abort PDU received
The provider issues the P-U-ABORT.INDICATION primitive and enters the
IDLE state.
Event: any other PDU received
If the PDU not an Abort PDU, the provider constructs a provider-
initiated Abort PDU, which is put on the input queue for the
serializer. Regardless, The provider issues the P-P-ABORT.INDICATION
primitive and enters the the IDLE state.
Event: timer expires
The provider decrements the retransmission counter. If the resulting
value is less than or equal to zero, the provider issues the P-
CONNECT.CONFIRMATION(-) primitive and enters the IDLE state.
Otherwise, a ConnectRequest PDU is put on the input queue for the
serializer, the small timer is started again, and the provider
remains in the WAIT1 state.
WAIT2 state
Event: P-CONNECT.RESPONSE primitive issued
The user data parameter is placed in a ConnectResponse PDU, which is
put on the input queue for the serializer. If the result parameter
had the value user-rejection, the provider enters the IDLE state.
Otherwise if the parameter had the value acceptance, the provider
enters the DATA state.
Event: P-U-ABORT.REQUEST primitive issued
The user data parameter is placed in an Abort PDU, which is put on
the input queue for the serializer. The provider enters the IDLE
state.
Event: user-initiated Abort PDU received
The provider issues the P-U-ABORT.INDICATION primitive and enters the
IDLE state.
Event: any other PDU received
If the PDU is not an Abort PDU, the provider constructs a provider-
initiated Abort PDU, which is put on the input queue for the
serializer. Regardless, The provider issues the P-P-ABORT.INDICATION
primitive and enters the the IDLE state.
DATA state
Event: P-DATA.REQUEST primitive issued
The user data parameter is placed in a UserData PDU, which is put on
the input queue for the serializer. The provider remains in the DATA
state.
Event: P-RELEASE.REQUEST primitive issued
The user data parameter is placed in a ReleaseRequest PDU, which is
put on the input queue for the serializer.
For the udp-based service, the provider sets the retransmission
counter to a small value (e.g., 2), and now starts a small timer.
Regardless, the provider enters the WAIT3 state.
Event: P-U-ABORT.REQUEST primitive issued
The user data parameter is placed in an Abort PDU, which is put on
the input queue for the serializer. The provider enters the IDLE
state.
Event: UserData PDU received
The provider issues the P-DATA.INDICATION primitive and remains in
the DATA state.
Event: ReleaseRequest PDU received
The provider issues the P-RELEASE.INDICATION primitive, and enters
the WAIT4 state.
Event: user-initiated Abort PDU received
The provider issues the P-U-ABORT.INDICATION primitive and enters
the IDLE state.
Event: any other PDU received
If the PDU is not an Abort PDU, the provider constructs a provider-
initiated Abort PDU, which is put on the input queue for the
serializer. Regardless, the provider issues the P-P-ABORT.INDICATION
primitive and enters the the IDLE state.
WAIT3 state
Event: P-U-ABORT.REQUEST primitive issued
The user data parameter is placed in an Abort PDU, which is put on
the input queue for the serializer. The provider enters the IDLE
state.
Event: ReleaseResponse PDU received
For the udp-based service, the timer is cancelled. The provider
issues the P-RELEASE.CONFIRMATION primitive and enters the IDLE
state.
Event: user-initiated Abort PDU received
The provider issues the P-U-ABORT.INDICATION primitive and enters the
IDLE state.
Event: any other PDU received
If the PDU is not an Abort PDU, the provider constructs a provider-
initiated Abort PDU, which is put on the input queue for the
serializer. Regardless, the provider issues the P-P-ABORT.INDICATION
primitive and enters the the IDLE state.
Event: timer expires
The provider decrements the retransmission counter. If the resulting
value is less than or equal to zero, the provider constructs a
provider-initiated Abort PDU, which is put on the input queue for the
serializer. It then issues the P-P-ABORT.INDICATION primitive and
enters the IDLE state. Otherwise, a ReleaseRequest PDU is put on the
input queue for the serializer, the small timer is started again, and
the provider remains in the WAIT3 state.
WAIT4 state
Event: P-RELEASE.RESPONSE primitive issued
The user data parameter is placed in a ReleaseResponse PDU, which is
put on the input queue for the serializer. The provider now enters
the IDLE state.
Event: P-U-ABORT.REQUEST primitive issued
The user data parameter is placed in an Abort PDU, which is put on
the input queue for the serializer. The provider now enters the IDLE
state.
Event: user-initiated Abort PDU received
The provider issues the P-U-ABORT.INDICATION primitive and enters the
IDLE state.
Event: any other PDU received
If the PDU is not an Abort PDU, the provider constructs a provider-
initiated Abort PDU, which is put on the input queue for the
serializer. Regardless, the provider issues the P-P-ABORT.INDICATION
primitive and enters the the IDLE state.
11. Directory Services
Although not properly part of the presentation service, this memo
assumes and specifies a minimal Directory service capability for use
by the application-entity.
The function of the Directory Service Element is to provide two
mappings: first, a service name is mapped into an application entity
title, which is a global handle on the service; and, second, the
application-entity title is mapped onto a presentation address.
The structure of presentation addresses were defined in Section 5.
The structure of application-entity titles is less solidly agreed
upon at the present time. Since objects of this type are not
interpreted by the presentation service, this memo does not specify
their structure. If the DIS version of association control is being
used, then use of an OBJECT IDENTIFIER will suffice. If the IS
version is being employed, then application-entity titles consist of
two parts: an application-process title and an application-entity
qualifier. It is suggested that the AP-Title use an OBJECT
IDENTIFIER and that the AE-Qualifier use NULL.
This memo requires the following mapping rules:
1. The service name for an OSI application-entity using the
mechanisms proposed by this memo is:
<designator> "-" <qualifier>
where <designator> is a string denoting either domain name or a
32-bit IP address, and <qualifier> is a string denoting the type
of application-entity desired, e.g.,
"gonzo.twg.com-mgmtinfobase"
2. Any locally defined mapping rules may be used to map the
service designation into an application-entity title.
3. The application-entity title is then mapped into a
presentation address, with uninterpreted transport, session, and
presentation selectors, and one or more network addresses, each
containing:
-the 32-bit IP address resolved from the <designator> portion
of the service name,
- a set indicating which transport services are available
at the IP address,
- the 16-bit port number resolved from the <qualifier>
portion of the service name (using the Assigned Numbers
document), and
- optionally, a presentation selector, which is an
uninterpreted sequence of octets.
The method by which the mappings are obtained are straight-forward.
The directory services element employs the Domain Name System along
with a local table which may be used to resolve the address employing
local rules.
In the simplest of implementations, the DNS is used to map the
<designator> to an IP address, and to fill-in the set of transport
services available at the IP address. The port number is found in a
local table derived from the current Assigned Numbers document.
Finally, the presentation selector is empty.
A more ambitious implementation would use a local table to perhaps
provide a presentation selector. This would be useful, e.g., in
"proxy" connections. The network address would resolve to the proxy
agent for the non-IP device, and the presentation selector would
indicate to the proxy agent the particular non-IP device desired.
This implies, of course, that the local table and the proxy agent
bilaterally agree as to the interpretation of each presentation
selector.
12. Remarks
To begin, if one really wanted to implement ISO applications in a
TCP/IP-based network, then the method proposed by [RFC1006] is the
preferred method for achieving this. However, in a constrained
environment, where it is necessary to host an application layer
entity with a minimal amount of underlying OSI infrastructure, this
memo proposes an alternative mechanism. It should be noted that an
OSI application realized using this approach can be moved directly to
an [RFC1006]-based environment with no modifications.
A key motivation therefore is to minimize the size of the alternate
underling infrastructure specified by this memo. As more and more
presentation services functionality is added, the method proposed
herein would begin to approximate the ISO presentation protocol.
Since this in contrary to the key motivation, featurism must be
avoided at all costs.
13. Acknowledgements
Several individuals contributed to the technical quality of this
memo:
Karl Auerbach, Epilogue Technologies
Joseph Bannister, Unisys
Amatzia Ben-Artzi, Sytek
Stephen Dunford, Unisys
Lee Labarre, MITRE
Keith McCloghrie, The Wollongong Group
Jim Robertson, Bridge Communications
Glenn Trewitt, Stanford University
14. References
[ISO7498] Information Processing Systems - Open Systems
Interconnection, "Basic Reference Model", October, 1984.
[ISO8509] Information Processing Systems - Open Systems
Interconnection, " Service Conventions".
[ISO8650] Information Processing Systems - Open Systems
Interconnection, " Protocol Specification for the
Association Control Service Element (Final Text
of DIS 8650)", January, 1988.
[ISO8822] Information Processing Systems - Open Systems
Interconnection, " Connection Oriented Presentation
Service Definition (Final Text of DIS 8822)",
April, 1988.
[ISO8823] Information Processing Systems - Open Systems
Interconnection, " Connection Oriented Presentation
Protocol Specification (Final Text of DIS 8822)",
April, 1988.
[ISO8824] Information Processing Systems - Open Systems
Interconnection, " Specification of Abstract Syntax
Notation One (ASN.1)", December, 1987.
[ISO8825] Information Processing Systems - Open Systems
Interconnection, "Specification of basic encoding rules
for Abstract Syntax Notation One (ASN.1)",
December, 1987.
[ISO9072/2] Information Processing Systems - Text Communication
MOTIS, " Remote Operations Part 2: Protocol
Specification (Working Document for DIS 9072/2)",
November, 1987.
[RFC768] Postel, J., "User Datagram Protocol", RFC 768, USC/ISI,
28 August 1980.
[RFC791] Postel, J., "Internet Protocol - DARPA Internet Program
Protocol Specification", RFC 791, USC/ISI,
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol - DARPA
Internet Program Protocol Specification", RFC 793,
USC/ISI, September 1981.
[RFC1006] Rose, M., and D. Cass, "ISO Transport 1 on Top of the
TCP Version: 3", Northrop Research and Technology
Center, May 1987.
Appendix A:
Abstract Syntax Definitions
RFC1085-PS DEFINITIONS ::=
BEGIN
PDUs ::=
CHOICE {
connectRequest
ConnectRequest-PDU,
connectResponse
ConnectResponse-PDU,
releaseRequest
ReleaseRequest-PDU,
releaseResponse
ReleaseResponse-PDU,
abort
Abort-PDU,
userData
UserData-PDU,
cL-userData
CL-UserData-PDU
}
-- connect request PDU
ConnectRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
version[0] -- version-1 corresponds to to this
memo
IMPLICIT INTEGER { version-1(0) },
reference
SessionConnectionIdentifier,
calling
PresentationSelector
OPTIONAL,
called[2]
IMPLICIT PresentationSelector
OPTIONAL,
asn[3] -- the ASN for PCI #1
IMPLICIT OBJECT IDENTIFIER,
user-data
UserData-PDU
}
SessionConnectionIdentifier ::=
[0]
SEQUENCE {
callingSSUserReference
T61String,
commonReference
UTCTime,
additionalReferenceInformation[0]
IMPLICIT T61String
OPTIONAL
}
PresentationSelector ::=
[1]
IMPLICIT OCTET STRING
-- connect response PDU
ConnectResponse-PDU ::=
[1]
IMPLICIT SEQUENCE {
reference -- present only in the udp-based
-- service
SessionConnectionIdentifier
OPTIONAL,
responding
PresentationSelector
OPTIONAL,
reason[2] -- present only if the connection
-- was rejected
IMPLICIT Rejection-reason
OPTIONAL,
user-data -- present only if reason is absent
-- OR has the
-- value rejected-by-responder
UserData-PDU
OPTIONAL
}
Rejection-reason ::=
INTEGER {
rejected-by-responder(0)
called-presentation-address-unknown(1),
local-limit-exceeded(3),
protocol-version-not-supported(4),
}
-- release request PDU
ReleaseRequest-PDU ::=
[2]
IMPLICIT SEQUENCE {
reference -- present only in the udp-based
-- service
SessionConnectionIdentifier
OPTIONAL,
user-data
UserData-PDU
}
-- release response PDU
ReleaseResponse-PDU ::=
[3]
IMPLICIT SEQUENCE {
reference -- present only in the udp-based
-- service
SessionConnectionIdentifier
OPTIONAL,
user-data
UserData-PDU
}
-- abort PDU
Abort-PDU ::=
[4]
SEQUENCE {
reference -- present only in the udp-based
-- service
SessionConnectionIdentifier
OPTIONAL,
user-data -- MAY BE present on user-initiated abort
UserData-PDU
OPTIONAL,
reason[1] -- ALWAYS present on provider-initiated abort
IMPLICIT Abort-reason
OPTIONAL
}
Abort-reason ::=
INTEGER {
unspecified(0),
unrecognized-ppdu(1),
unexpected-ppdu(2),
unrecognized-ppdu-parameter(4),
invalid-ppdu-parameter(5),
reference-mismatch(9)
}
-- data PDU
UserData-PDU ::=
[5] -- this is the ASN.1 object
ANY -- if it is a top-level PDU, it
-- is in PCI #1, otherwise PCI #3
-- data PDU for the udp-based service
CL-UserData-PDU ::=
[6]
IMPLICIT SEQUENCE {
reference
SessionConnectionIdentifier,
user-data[0] -- this is the ASN.1 object
ANY -- it is always in PCI #1
}
END
Appendix B:
Example of Serialization
Consider the following call to ROSE:
RO-INVOKE (operation number = 5
operation class = synchronous
argument = NONE
invocation identifier = 1
linked invocation id. = NONE
priority = 0)
.REQUEST
Ultimately, ROSE will use the P-DATA service:
P-DATA (user data = {
1, -- this is the PCI
{ -- this is the ASN.1 object
invokeID 1,
operation-value 5,
argument {}
}
})
.REQUEST
The presentation provider will construct a UserData PDU and send this
via the transport connection:
[5] {
{
1,
5,
{}
}
}
Applying the basic encoding rules for ASN.1, we have an stream of 12
octets.
a5 0a [5]
tag len
a0 08 [0]
tag len
02 01 01 invokeID 1
tag len value
02 01 05 operation-value 5
tag len value
30 00 argument NULL
tag len
Of course, in actual use, the argument would not be NONE and this
could be expected to dominate the size of the UserData PDU. However,
it is worth nothing that the overhead of the encoding mechanism used
is on the order of 10 octets, hardly a staggering amount!
Appendix C:
Determination of Network Called Address
As described in Section 10, when the P-CONNECT.REQUEST primitive is
issued the presentation provider must determine which of the network
addresses present in the called presentation address parameter to use
for the presentation connection. The first step in this
determination is to examine the quality of service parameter and
consider only those network addresses which support the corresponding
transport service. In practice, it is likely that each network
address will support exactly the same transport services, so using
quality of service as a discriminant will either permit all or none
or the network addresses present to be selected. This appendix
describes a local policy which might be employed when deciding which
network address to use.
The policy distinguishes between "underlying failures" and
"connection establishment failures". An "underlying failure" occurs
when, using the desired transport service, the initiating
presentation provider is unable to contact the responding
presentation provider. For the tcp-based service, this means that a
TCP connection could not be established for some reason. For the
udp-based service, it means that a response was not received before
final time-out. In contrast, a "connection establishment failure"
occurs when the responding presentation provider can be contacted,
but the presentation connection is rejected by either the
presentation provider or the correspondent presentation user.
The policy is simple: starting with the first network address
present, attempt the connection procedure. If the procedure fails
due to an "underlying failure", then the next network address in the
list is tried. This process is repeated until either an underlying
connection is established or all network addresses are exhausted.
If, however, a "connection establishment failure" occurs, then the
presentation provider immediately indicates this failure to the
presentation user and no further network addresses are considered.
Note that this is only one conformant policy of many. For example,
the presentation provider may wish to order network addresses based
on the "intensity" associated with the members present in the set of
transport services for each network address.
Author's Address:
Marshall Rose
The Wollongong Group
1129 San Antonio Road
Palo Alto, CA 94303
Phone: (415) 962-7100
EMail: mrose@TWG.COM
ISO Plain Language
On this page
§1Why a Lighter Way to Run OSI Applications
RFC 1006 describes a mechanism for providing the ISO transport service on top of TCP and IP. Once that method is applied, real ISO applications can be implemented on TCP/IP-based internets by implementing the OSI session, presentation and application services on top of the transport service access point provided over TCP. Although straightforward, there are environments where the richness of the OSI application layer is desired but implementing the underlying OSI infrastructure, the presentation, session and transport services on top of TCP, is impractical. This memo describes an approach for providing streamlined support of OSI application services over TCP/IP-based internets for such constrained environments.
The mechanism is targeted at a particular class of OSI applications: those whose application context contains only an Association Control Service Element, which manages associations between application entities, and a Remote Operations Service Element, which orchestrates the invocation of total operations between application entities. A Directory Services Element is assumed to be used by the application entity, but only in a very limited sense. The mechanism is not applicable to entities whose application context is more extensive, for example one containing a Reliable Transfer Service Element, although it could be modified to support additional elements. Such extensions would, at this time, merely defeat the purpose of providing the minimal software infrastructure needed to run the majority of OSI applications.
The motivation came from a requirement to run the ISO Common Management Information Protocol in TCP/IP-based internets, since in its current definition CMIP uses precisely the application service elements provided for here. It may be desirable to offer CMIP users a quality of service different from the one offered by a connection with a high level of reliability, which would permit reduced use of connection-related resources, and this memo proposes a mechanism to implement that less robust and less costly quality of service.
The memo's own remarks note that if one really wanted to implement ISO applications in a TCP/IP-based network, the method of RFC 1006 is the preferred one, and that in a constrained environment this memo proposes an alternative. An OSI application realised this way can be moved directly to an RFC 1006 based environment with no modifications. As more presentation service functionality is added, the method proposed here would begin to approximate the ISO presentation protocol, which is contrary to the key motivation, so featurism must be avoided at all costs.
The full OSI stack is a lot of software to write when all an application really needs is a way to exchange structured objects with a remote program. This memo keeps only the part that the association and remote operation elements use, and leaves out everything else. The trade-off is stated plainly in the memo's remarks: an application written this way can be moved to the fuller approach later without changes.
§4The Approach: ASN.1 Objects Over TCP
The approach relies on a set of architectural nuances: the TCP is a stream-oriented transport protocol; ASN.1 objects, when represented as a stream of octets, are self-delimiting; the ISO presentation service permits the exchange of ASN.1 objects; the ACSE and ROSE require the connection establishment facility, the connection termination facility and the information transfer facility, the P-DATA service only; and the majority of the parameters used by the services that provide these facilities can be hard-wired to avoid negotiation.
Together these suggest that a cheap emulation of the ISO presentation services could be implemented by simply serialising ASN.1 objects over a TCP connection, and that is exactly what the memo proposes. The overall composition is a client and a server, each implementing the protocol described in the memo, each offering a presentation service interface to its user and a TCP interface below. The essential features of the ISO presentation service are maintained while using a protocol entirely different from the one given in ISO 8823.
Each box contains three modules. A dispatch module provides the presentation services interface. A serialisation module holds a serializer, which takes an ASN.1 object and applies the encoding rules of ISO 8825 to produce a stream of octets, and a de-serializer, which performs the inverse operation. A network module manages the TCP connection. The flow of data is that the user hands an object to the dispatch module, which passes it to the serializer through an input queue; the serializer's output goes through an output queue to the network. In the other direction the network's input queue feeds the de-serializer, whose output queue feeds the dispatch module.
The ISO presentation layer is concerned primarily with the negotiation of transfer syntaxes in addition to the transformation to and from transfer syntax. With this mechanism no negotiation component is employed. The memo specifies the fixed contexts that exist over each presentation connection offered, and further specifies other constants used in order to eliminate the need for presentation layer negotiation.
The whole mechanism is: turn each application data object into bytes and send them. The trick that makes it work is that ASN.1 objects say where they end, so the receiver can find the boundary of each one in the byte stream without any extra framing. Three modules do the work: one that hands objects between the application and the network, one that turns objects into bytes and back, and one that manages the connection.
- Application entityACSE, ROSE and the directory services element
- Presentation serviceP-CONNECT, P-RELEASE and P-DATA, emulated here
- TCP or UDPCarries the serialised ASN.1 objects
- IPDelivers the packets
§5The Fixed Parameters
A presentation address is interpreted as an ordered tuple containing one or more network addresses, a transport selector, a session selector and a presentation selector, each selector being an uninterpreted octet string of possibly zero length. The mechanism ignores the values of these selectors, except that the value of the presentation selector is preserved by the provider. A network address is interpreted as containing a 32-bit IP address, a set indicating which transport services are available at that IP address, currently only two members, TCP and UDP, each possibly carrying an intensity of possibly present or definitely present, and a 16-bit port number. As a consequence, any application entity residing in the network can be identified by its network address.
The presentation context list holds one or more presentation contexts, each with a presentation context identifier, an integer, an abstract syntax name, an object identifier, and an abstract transfer name, an object identifier. The range of values these components may take is severely restricted: exactly two contexts are defined, one for association control and the other for the specific application service element carried as remote operations APDUs. In a result list a fourth component appears, an acceptance indicator saying whether the context was accepted by both the service provider and the remote peer, with a brief reason such as abstract syntax not supported if it was not accepted. The memo offers an analogy for the novice reader: the abstract syntax notation defines the vocabulary of a language, listing the words that can be spoken, while the abstract transfer notation defines the pronunciation.
User data passes through the presentation service interface as ASN.1 objects in a locally defined form, each associated with a presentation context identifier that distinguishes the context the data is intended for. Exactly one of two contexts must always be used, either the value for the ACSE presentation context or the value for ROSE. Quality of service is a collection of elements, and only one is interpreted, transport-mapping, which takes one of two values, tcp-based or udp-based, also referred to as high-quality or low-quality. Implementations of this memo always indicate that session service version 2 has been negotiated.
The memo also assumes and specifies a minimal Directory service capability. The Directory Services Element provides two mappings: a service name is mapped into an application entity title, a global handle on the service, and the application entity title is mapped onto a presentation address. The service name for an OSI application entity using this mechanism is a designator and a qualifier separated by a hyphen, where the designator is a string denoting either a domain name or a 32-bit IP address and the qualifier denotes the type of application entity desired, for example gonzo.twg.com-mgmtinfobase. The presentation address then carries the 32-bit IP address resolved from the designator, the set of available transport services, the 16-bit port number resolved from the qualifier using the Assigned Numbers document, and optionally a presentation selector. The simplest implementation uses the Domain Name System to map the designator to an IP address and a local table derived from the Assigned Numbers document for the port number.
Because nothing is negotiated, every value has to be fixed in advance, and the memo does that explicitly. There are exactly two presentation contexts, one for setting up the association and one for the application's own messages. The transfer syntax is always the basic ASN.1 encoding rules. The transport is chosen in advance as either TCP or UDP. And a service is found by a name of the form host-service, which a directory lookup turns into an IP address and a port number.
§6Choosing TCP or UDP
The quality of service parameter of the P-CONNECT service selects the underlying transport service. If transport-mapping is tcp-based, the presentation provider uses TCP; if it is udp-based, the provider uses UDP instead. Very few transport-level facilities are placed on top of the UDP service, and it is not the intent of the memo to re-invent the facilities in TCP. The memo is emphatic that low-quality means low-quality.
Because UDP is a packet-oriented protocol, the role of the serialisation module is slightly redefined. For the serializer, each top-level ASN.1 object placed on the input queue forms a single UDP datagram on the output queue that is given to the network. For the de-serializer, each UDP datagram placed on the input queue from the network forms a single top-level ASN.1 object placed on the output queue. The term top-level ASN.1 object refers to the protocol data units being exchanged by the presentation providers.
The memo permits the choice of two transport protocols, TCP or UDP, and explains that as experience is gained and other transport protocols are deployed, such as VMTP, future incarnations would permit them. That is a three step process: the set of transport services defined for the network address is updated, a corresponding value is added to the range of the transport-mapping quality of service element, and the following sections of the memo are modified accordingly.
The two transports are not treated equally, and the memo says so. With TCP the objects are simply written into the byte stream. With UDP each object becomes one datagram, so a large object will not fit and the receiver gets nothing if the datagram is lost, since nothing is retransmitted. The choice is fixed in advance, in the quality of service parameter.
§7Opening, Closing and Carrying Data
The connection establishment facility consists of one service, P-CONNECT, used to bring two identified application entities into communication. Its successful use results in a presentation connection with an initial defined context set being established between them. It is a confirmed service whose effects are sequenced and non-destructive. If the udp-based service is selected, a presentation connection is formed which should be used infrequently and will have minimal reliability characteristics. For the purposes of this memo, P-CONNECT requests TCP or UDP resources, builds a fixed defined context set, and exchanges initial user data.
The parameters have fixed interpretations. The calling presentation address may, in practice, be replaced by a local rule that picks an ephemeral address. The called presentation address may carry more than one network address in the request, while the indication carries only the one actually used. The responding presentation address is identical to the called address of the indication. Multiple defined contexts is always TRUE. The presentation context definition list holds two contexts: presentation context identifier 1 with an abstract syntax specific to the application and the transfer name iso asn.1 abstract transfer 1.0.8825, and identifier 3 with the abstract syntax acse pci version 1, 2.2.1.0.0, and the same transfer name, for use with the DIS version of association control; if the IS version is used, identifier 3 carries acse pci version 1, 2.2.1.0.1, with the transfer name asn.1 basic encoding, 2.1.1. The context result list is identical with the acceptance indicator for both contexts set to accepted. The default context name is none and the default context result is not applicable. Presentation requirements are none, because the kernel functional unit is always used, and session requirements are full duplex. The session connection identifier has a format that the memo mandates, holding user data as a local string encoded as a T.61 string using ASN.1, common data as a universal time encoding using ASN.1, and optional additional data as a T.61 string. The user data is a single ASN.1 object, the appropriate A-ASSOCIATE PDU, carried in presentation context 3, and the result is one of acceptance, user-rejection, provider-rejection transient or provider-rejection permanent.
The connection termination facility consists of three services. P-RELEASE gives the service user access to a negotiated release facility, has effects that are sequenced and non-destructive, and either user may request it, though a collision invokes a provider-initiated abort. It waits for the serialisation module to drain, sends release user data and releases the TCP or UDP resources; if the udp-based service is selected, any data in transit may be discarded. P-U-ABORT lets either user force the release of the connection at any time and have the correspondent informed, without requiring the agreement of both users; it flushes the serialisation module, sends abort user data and releases the resources. P-P-ABORT is the provider's way of indicating termination for reasons internal to the provider, with an integer provider reason such as invalid PPDU parameter, unexpected PPDU, unrecognised PPDU or specified reason.
The information transfer facility consists of many services, but only one, P-DATA, is provided, giving the service user a data transfer capability with sequenced and non-destructive effects. Its user data is a single ASN.1 object, a remote operations APDU, carried in presentation context 1. If the udp-based service is selected there is an upper bound on the size of the serialised ASN.1 objects that may be transmitted, imposed by UDP at 65536 octets, and as a practical matter it is probably a good idea to keep datagrams at 536 octets or less.
Opening a connection sends one object, the association request, and fixes the two contexts for the life of the connection. Closing is done in one of three ways: a polite release, an abort by one side, or an abort by the provider when something has gone wrong. Carrying data is one service that sends one object at a time, and over UDP each object has to fit inside a datagram.
§10Elements of Procedure
The service provider is in one of the following states: IDLE, WAIT1, WAIT2, DATA, WAIT3 or WAIT4. The possible events come from the PS-user, such as P-CONNECT.REQUEST, P-CONNECT.RESPONSE, P-RELEASE.REQUEST, P-RELEASE.RESPONSE, P-DATA.REQUEST and P-U-ABORT.REQUEST, and from the network, such as the TCP closing or erroring, the arrival of ConnectRequest, ConnectResponse, ReleaseRequest or ReleaseResponse PDUs, the arrival of UserData or CL-UserData PDUs, the arrival of a user-initiated or provider-initiated Abort PDU, and a timer expiring. The possible actions are the corresponding indications and confirmations to the PS-user, and to the network, opening or closing the TCP connection, sending the PDUs, and setting the timer. Opening and closing the TCP and the CL-UserData PDU and the timer apply to one transport or the other: the TCP actions are for the tcp-based service only, and the CL-UserData PDU and the timer for the udp-based service only.
For the tcp-based service, the provider keeps a local designator for the PS-user, a local designator for a TCP connection, and the state of the connection. An event from the network is matched to a presentation connection by comparing local designators for the TCP connection, and whenever a connection remains in or returns to the IDLE state any associated resources, such as an attachment to a local TCP port, are released. Outgoing PDUs are placed on the input queue for the serializer. If the PDU is not an abort PDU it is simply appended regardless of how many PDUs are queued. If it is an abort PDU and the input queue is non-empty, or the serializer is busy transmitting, the abort PDU is discarded and the serializer is flushed, aborting output in progress. If the queue is empty the abort PDU is appended and a small timer started, and if the timer expires before the PDU has been serialised and transmitted, the serializer is flushed. Whenever the TCP connection is closed or has errored the serializer is flushed, with the single exception of a ReleaseResponse PDU being serialised and transmitted, in which case the connection is not closed until the serializer has finished.
For the udp-based service, the provider keeps the local designators and the state, plus the 32-bit IP address and 16-bit UDP port number of both the initiating and the responding host, the session connection identifier used to establish the connection, a local designator for a UDP endpoint, and a retransmission counter. Matching an incoming event to a connection is done on the basis of addresses, ports and the session connection identifier, so two different presentation connections may differ only in that identifier. If no connection can be found, a vanilla presentation connection may be assumed, initialised to the IDLE state. Outgoing PDUs are serialised and the resulting octets sent as a single UDP datagram.
The state transitions follow a fixed pattern. In the IDLE state, a P-CONNECT.REQUEST makes the provider select an address, attach itself to the port, try to establish a TCP connection if the tcp-based service is chosen, and put a ConnectRequest PDU on the serializer's input queue; for the udp-based service it sets the retransmission counter to a small value, for example 2, and starts a small timer. The provider enters WAIT1. A ConnectRequest PDU received in the IDLE state produces a P-CONNECT.INDICATION and the WAIT2 state, while any other PDU received produces a provider-initiated Abort PDU and leaves the provider in IDLE.
In WAIT1, a ConnectResponse PDU received cancels the timer for the udp-based service; if the PDU indicates rejection the provider issues a negative P-CONNECT.CONFIRMATION and enters IDLE, otherwise a positive confirmation and the DATA state. A user-initiated Abort PDU produces a P-U-ABORT.INDICATION and the IDLE state, and any other PDU produces a provider-initiated Abort PDU, a P-P-ABORT.INDICATION and the IDLE state. When the timer expires the retransmission counter is decremented; if the result is less than or equal to zero the provider issues a negative P-CONNECT.CONFIRMATION and enters IDLE, otherwise another ConnectRequest PDU is queued, the timer started again, and the provider stays in WAIT1.
In WAIT2, a P-CONNECT.RESPONSE puts a ConnectResponse PDU on the queue, and the result parameter decides whether the provider enters IDLE, on user-rejection, or the DATA state, on acceptance. In the DATA state, a P-DATA.REQUEST queues a UserData PDU and the provider stays in DATA; a P-RELEASE.REQUEST queues a ReleaseRequest PDU and the provider enters WAIT3; a UserData PDU received produces a P-DATA.INDICATION and stays in DATA; and a ReleaseRequest PDU received produces a P-RELEASE.INDICATION and the WAIT4 state. In WAIT3, a ReleaseResponse PDU received produces a P-RELEASE.CONFIRMATION and the IDLE state, and an expired timer decrements the retransmission counter, leading to a provider-initiated abort when it reaches zero. In WAIT4, a P-RELEASE.RESPONSE queues a ReleaseResponse PDU and the provider enters IDLE. If the udp-based service is selected, CL-UserData PDUs are exchanged by the provider instead of UserData PDUs.
The provider is a small state machine with six states. It waits for a connection request, waits for the answer, passes data, then waits for the release to be answered and for the answer to the release. Over TCP the connection itself does the resending; over UDP the provider keeps a retransmission counter and resends the request itself a couple of times before giving up.
- IDLE start
- WAIT1
- WAIT2
- DATA
- WAIT3
- WAIT4
| From | To | Event |
|---|---|---|
| IDLE | WAIT1 | P-CONNECT.REQUEST |
| IDLE | WAIT2 | ConnectRequest PDU received |
| WAIT1 | DATA | ConnectResponse PDU received |
| WAIT1 | IDLE | Abort or timer expiry |
| WAIT2 | DATA | P-CONNECT.RESPONSE accepted |
| WAIT2 | IDLE | P-CONNECT.RESPONSE rejected |
| DATA | DATA | P-DATA.REQUEST |
| DATA | WAIT3 | P-RELEASE.REQUEST |
| WAIT3 | IDLE | ReleaseResponse PDU received |
| WAIT4 | IDLE | P-RELEASE.RESPONSE |