As per Relevance of the word provider, we have this rfc below:
Network Working Group M.
Request for Comments: 1085
December 1988
ISO Presentation
on top of TCP/IP-based
Status of this
This memo proposes a standard for the Internet community
Distribution of this memo is unlimited
1.
[RFC1006] describes a mechanism for providing the ISO
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-
internets, by simply implementing OSI session, presentation,
application services on top of the transport service access
which is provided on top of the TCP. Although straight-forward
there are some environments in which the richness provided by the
application layer is desired, but it is nonetheless impractical
implement the underlying OSI infrastructure (i.e., the presentation
session, and transport services on top of the TCP). This
describes an approach for providing "stream-lined" support of
application services on top of TCP/IP-based internets for
constrained environments
2.
In as much as this memo is concerned primarily with concepts
in the framework of Open Systems Interconnection (OSI) as
by the International Organization for Standardization (ISO),
terminology used herein is intended to be entirely consistent
that domain of discourse. This perspective is being taken
the expressed intent of implementing the mechanism proposed by
memo in the Internet and other TCP/IP-based internets. For
more familiar with the terminology used in this latter domain,
author is apologetic but unyielding
Although no substitute for the "correct" definitions given in
appropriate ISO documents, here is a short summary of the terms
herein
Rose [Page 1]
RFC 1085 ISO Presentation Services December 1988
Application Context
The collection of application service elements
cooperatively interact within an application-entity
Application Service Element
A standardized mechanism, defined by both a service and
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
entities [ISO8650].
Object Identifier
An ordered set of integers, used for
identification
Presentation Service
A set of facilities used to manage a connection between
application-entities. The fundamental responsibility of
presentation service is to maintain transfer syntaxes
are used to serialize application protocol data units
transmission on the network and subsequent de-
for reception
Protocol Data Unit (PDU):
A data object exchanged between service providers
Serialization
The process of applying an abstract transfer notation to
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
pertaining to the reference model [ISO7498], to the
conventions in the model [ISO8509], and to
connection-oriented presentation service [ISO8822].
3.
The mechanism proposed by this memo is targeted for a
class of OSI applications, namely those entities whose
context contains only an Association Control Service Element (ACSE
and a Remote Operations Service Element (ROSE). In addition,
Rose [Page 2]
RFC 1085 ISO Presentation Services December 1988
Directory Services Element (DSE) is assumed for use by
application-entity, but only in a very limited sense.
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
whose application context is more extensive (e.g., contains
Reliable Transfer Service Element). The mechanism proposed by
memo could be modified to support additional elements. However,
extensions would, at this time, merely serve to defeat the purpose
providing the minimal software infrastructure required to run
majority of OSI applications
The motivation for this memo was initially derived from a
to run the ISO Common Management Information Protocol (CMIP)
TCP/IP-based internets. In its current definition, CMIP
precisely the application service elements provided for herein.
may be desirable to offer CMIP users a quality of service
than the one offered by a connection with a high-quality level
reliability. This would permit a reduced utilization of connection
related resources. This memo proposes a mechanism to implement
less robust -- and less costly -- quality of service
4.
The approach proposed by this memo relies on the
architectural nuances
Rose [Page 3]
RFC 1085 ISO Presentation Services December 1988
- the TCP is a stream-oriented transport
- ASN.1 objects, when represented as a stream of octets
self-
- The ISO presentation service permits the exchange of ASN.1
- The ACSE and ROSE require the following
facilities
The Connection Establishment
The Connection Termination
The Information Transfer Facility (P-
service only
- The majority of the parameters used by the services
provide these facilities can be "hard-wired" to
In principle, these nuances suggest that a "cheap" emulation of
ISO presentation services could be implemented by simply
ASN.1 objects over a TCP connection. This approach is precisely
is proposed by this memo
Given this perspective, this memo details how the essential
of the ISO presentation service may be maintained while using
protocol entirely different from the one given in [ISO8823].
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] |
| |
Rose [Page 4]
RFC 1085 ISO Presentation Services December 1988
In greater detail, the "client" and "server" boxes implement
protocol described in this memo. Each box contains three modules
- a dispatch module, which provides the presentation
interface
- a serialization module, containing a serializer, which
an ASN.1 object and applies the encoding rules of [ISO8825]
to produce a stream of octets, and a de-serializer,
performs the inverse operation,
- a network module, which manages a TCP connection
The software architecture used to model a network entity using
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
negotiation of transfer syntaxes in addition to the transformation
and from transfer syntax. However, using the mechanism proposed
this memo, no negotiation component will be employed. This
specifies the fixed contexts which exist over each
connection offered. This memo further specifies other
which are used in order to eliminate the need for presentation
negotiation
5. Fundamental
There are certain parameters which are used by the
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
Rose [Page 5]
RFC 1085 ISO Presentation Services December 1988
ordered-tuple containing
- one or more network
- a transport
- a session
- a presentation
Each selector is an uninterpreted octet string of possibly
length. The mechanism proposed in this memo completely
the values of these selectors. Note however that the value of
presentation selector is preserved by the provider
A network address is interpreted as containing three components
- a 32-bit IP
- a set indicating which transport services are
at the IP address (currently only two members are defined
TCP and UDP; as experience is gained, other
services may be added); as a local matter, if a member
present it may have an "intensity" associated with it
either "possibly present" or "definitely present
- a 16-bit port
As a consequence of these interpretations, any application-
residing in the network can be identified by its network address
2. Presentation context
A list of one or more presentation contexts. Each
context has three components
- a presentation context identifier (PCI), an
- an abstract syntax name, an object
- an abstract transfer name, an object
The range of values these components may take is
restricted by this memo. In particular, exactly two contexts
defined: one for association control and the other for
specific application service element which is being carried as
APDUs (see the section on connection establishment for the
values).
In addition, if the presentation context list appears in
"result" list (e.g., the Presentation context result
Rose [Page 6]
RFC 1085 ISO Presentation Services December 1988
parameter for the P-CONNECT service), a fourth component
present
- an acceptance
which indicates if the context was accepted by both the
provider and the remote peer. If the context was not accept,
brief reason, such as "abstract syntax not supported" is given
For the novice reader, one might think of the abstract
notation as defining the vocabulary of some language, that is,
lists the words which can be spoken. In contrast, the
transfer notation defines the pronunciation of the language
3. User
User data passes through the presentation service interface
ASN.1 objects (in a locally defined form). Associated with
object is a presentation context identifier. The
distinguishes the context for which the data is intended.
range of values the PCI may take is severely restricted by
memo. Exactly one of two contexts must always be used: either
value for the ACSE presentation context or the value for the ROSE
4. Quality of
Quality of service is a collection of "elements". Each
denotes some characteristics of the communication, e.g.,
throughput, and some value in an arbitrary unit of measure.
our purposes, only one quality of service element is interpreted
"transport-mapping". Currently, the "transport-mapping"
takes on one of two values: "tcp-based" or "udp-based".
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
would correspond directly to the new transport services which
listed in the network address
5. Version of Session
Some application service elements (e.g., the ACSE)
different procedures based on the (negotiated) version of
session service available. Implementations of this memo
indicate that session service version 2 has been negotiated
Rose [Page 7]
RFC 1085 ISO Presentation Services December 1988
6. Choice of Transport
Discussion thus far has centered along the use of the TCP as
underlying transport protocol. However, it has also been noted
it may be desirable to permit a quality of service with
reliability in order to take advantage of some other
of the transport service
The introduction of this service has several profound impacts on
model, and it is beyond the scope of this memo to enumerate
impacts. However, this memo does propose a mechanism by which such
facility is implemented
To begin, we use the quality of service parameter for the P-
service to select an underlying transport service. Only one
is currently interpreted, "transport-mapping" which takes the
"tcp-based" or "udp-based". If the value is "tcp-based", then
presentation provider will use TCP as the underlying
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
udp-based service. Very few transport-level facilities are placed
top of the UDP service, i.e., it is not the intent of this memo
"re-invent" the facilities in the TCP. Hence, It is critical
understand
low-quality means LOW-QUALITY
Because the UDP is a packet-oriented protocol, it is necessary
slightly redefine the role of the serialization module. For
serializer, we say that each top-level ASN.1 object placed on
input queue will form a single UDP datagram on the output queue
is given to the network. Similarly, for the de-serializer, we
that each UDP datagram placed on the input queue from the
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
data units being exchanged by the presentation providers
It should be noted that in its current incarnation, this memo
the choice of two different transport protocols, e.g., the TCP or
UDP. However, as experience is gained and as other
protocols are deployed (e.g., the VMTP), then future incarnations
this memo will permit these transport protocols to be used. This
a three step process: first, the set of transport services
for the network address is updated; second, a corresponding value
added to the range of the quality of service element "transport
mapping"; and, third, the following sections of this memo
Rose [Page 8]
RFC 1085 ISO Presentation Services December 1988
modified accordingly
7. Connection
The Connection Establishment facility consists of one service,
P-CONNECT service
7.1. The P-CONNECT
This service is used to bring two identified application-
into communication. Its successful use results in a
connection, with an initial defined context set, being
between then. This connection is available for their
communication. This is a confirmed service whose effects
sequenced and non-destructive
If the udp-based service is selected, then a presentation
is formed which should be used infrequently and will have
reliability characteristics
For our purposes, the P-CONNECT service
- requests TCP or UDP resources
- builds a fixed defined context set,
- exchanges initial user data
Following are the interpretation of and the defaults assigned to
parameters of the P-CONNECT service
1. Calling Presentation
This is a presentation address. Although the ISO
service states that this parameter is mandatory, in practice,
local implementation rule may be used to determine
"ephemeral" address to use
2. Called Presentation
This is a presentation address. Note that when issuing the P
CONNECT.REQUEST primitive, this parameter may contain more
one network address. In the P-CONNECT.INDICATION
however, only one network address, the one actually used
establish the presentation connection, is present. (Appendix
describes a strategy which might be used to determine the
network address).
Rose [Page 9]
RFC 1085 ISO Presentation Services December 1988
3. Responding Presentation
This parameter is identical to the value of the
Presentation Address parameter of the P-CONNECT.
primitive
4. Multiple defined
Always TRUE. Note that this parameter is present only in
DIS version of the presentation service
5. Presentation context definition
Two contexts are defined
PCI Abstract Syntax Name Abstract Transfer
--- -------------------- ----------------------
1 specific to the application "iso asn.1
transfer
1.0.8825
3 "acse pci version 1" "iso asn.1
transfer
2.2.1.0.0 1.0.8825
The abstract syntax and transfer names for the ACSE PCI are
use with the DIS version of association control. If the
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
Identical to the Presentation context definition list with
addition that the acceptance indicator for both contexts
"accepted".
7. Default Context
None
8. Default Context
Not applicable
Rose [Page 10]
RFC 1085 ISO Presentation Services December 1988
9. Quality of
The element "transport-mapping" takes the value "tcp-based"
"udp-based". In the future the range of values may be extended
10. Presentation
None (the kernel functional unit is always used).
11. Session
Full duplex
12. Initial synchronization point serial
None
13. Initial Assignment of
None
14. Session connection
Unlike the "real" presentation service, depending on the
of service selected, this parameter may have great
to presentation provider. Hence, the following format of
session connection identifier is mandated by this memo
user data: a local string encoded as a T.61
using ASN.1, e.g., given string "gonzo":
14 05 67 6f 6e 7a 6
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
the first two octets of each data component for transmission
the network as when the session connection identifier
represented with ASN.1, the tag and length octets will be
anyway
Rose [Page 11]
RFC 1085 ISO Presentation Services December 1988
15. User
A single ASN.1 object is present, the appropriate A-
PDU, carried in presentation context 3.
16.
One of the following values: acceptance, user-rejection
provider-rejection (transient), or provider-
(permanent).
8. Connection
The Connection Termination facility consists of three services,
P-RELEASE, P-U-ABORT, and P-P-ABORT services
8.1. The P-RELEASE
This service provides the service user with access to a
release facility. This service has effects which are sequenced
non-destructive. Either presentation user is permitted to
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
discarded
For our purposes, the P-RELEASE service
- waits for the serialization module to drain
- sends release user data,
- releases TCP or UDP
Following are the interpretation of and the defaults assigned to
parameters of the P-RELEASE service
1.
Release accepted
2. User
A single ASN.1 object is present, the appropriate A-RELEASE PDU
Rose [Page 12]
RFC 1085 ISO Presentation Services December 1988
8.2. The P-U-ABORT
This service can be used by either presentation user to force
release of a presentation connection at any time and have
correspondent presentation user informed of this termination.
service has effects which are not sequenced with respect to
service invocations and may be destructive. It does not require
agreement of both service users
For our purposes, the P-U-ABORT service
- flushes the serialization module
- sends abort user data,
- releases TCP or UDP
Following are the interpretation of and the defaults assigned to
parameters of the P-U-ABORT service
1. Presentation context identifier
Contained in the ASN.1 objects, if any, that are delivered
user data
2. User
A single ASN.1 object is present, an A-ABORT PDU, carried
presentation context 3.
8.3. The P-P-ABORT
This service is the means by which the service provider may
the termination of the presentation connection for reasons
to the service provider. This service has effects which are
sequenced with respect to preceding service invocations.
execution of this service disrupts any other concurrently
service and may thus be destructive
For our purposes, the P-P-ABORT service
- flushes the serialization module,
- releases TCP or UDP
Following are the interpretation of and the defaults assigned to
parameters of the P-P-ABORT service
Rose [Page 13]
RFC 1085 ISO Presentation Services December 1988
1. Provider
An integer code detailing why the connection was aborted.
include, but are not limited to: invalid PPDU parameter
unexpected PPDU, unrecognized PPDU, and specified reason
2. Abort
None
9. Information
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
This services provides the service user with a data
capability. This service has effects which are sequenced and non
destructive
If the udp-based service is selected, then there is an upper-bound
the size of the serialized ASN.1 objects which may be transmitted
This limit, imposed by the UDP, is 65536 octets. As a
matter, it is probably a good idea to keep datagrams less than
equal to 536 octets in size
For our purposes, the P-DATA service
- sends user
Following are the interpretation of and the defaults assigned to
parameters of the P-DATA service
1. User
A single ASN.1 object is present, a remote operations APDU
carried in presentation context 1.
10. Elements of
The service provider is in one of the following states
IDLE, WAIT1, WAIT2, DATA, WAIT3, or WAIT
The possible events are
PS-user P-CONNECT.
Rose [Page 14]
RFC 1085 ISO Presentation Services December 1988
P-CONNECT.
P-RELEASE.
P-RELEASE.
P-DATA.
P-U-ABORT.
network TCP closed or errored(*)
receive ConnectRequest
receive ConnectResponse
receive ReleaseRequest
receive ReleaseResponse
receive UserData(*) or CL-UserData(**)
receive user-initiated Abort
receive provider-initiated Abort
timer expires(**)
The possible actions are
PS-user P-CONNECT.
P-CONNECT.
P-RELEASE.
P-RELEASE.
P-DATA.
P-U-ABORT.
P-P-ABORT.
network open TCP(*)
close TCP(*)
send ConnectRequest
send ConnectResponse
send ReleaseRequest
send ReleaseResponse
send UserData(*) or CL-UserData(**)
send user-initiated Abort
send provider-initiated Abort
set timer(**)
(*) tcp-based service
(**) udp-based service
10.1. Elements of Procedure specific to the tcp-based
The provider maintains the following information for
presentation connection
- a local designator for the PS-
Rose [Page 15]
RFC 1085 ISO Presentation Services December 1988
- a local designator for a TCP
- the state of the connection (e.g., IDLE, WAIT1, and so on
Upon receiving an event from the network, the provider finds
associated presentation connection. Matching is done by
comparing local designators for the TCP connection. Whenever
connection remains in or returns to the IDLE state, any
resources, such as an attachment to a local TCP port, are released
In the procedures which follow, outgoing PDUs are "placed on
input queue for the serializer". This has a different
depending on the type of PDU being enqueued. If the PDU is not
abort PDU (user-initiated or provider-initiated), then the PDU
simply appended to the input queue regardless of the number of
present. If however, the PDU is an abort PDU, then the
checks the size of the input queue. If the input queue is non-
or if the serializer is busy transmitting to the network, then
abort PDU is discarded, and the serializer is flushed, aborting
output to the network in progress. However, if the input queue
empty, then the Abort PDU is appended to the queue, and a small
started. If the timer expires before the PDU has been serialized
transmitted, then the serializer is flushed, aborting any output
the network in progress
Further, in general, whenever the TCP connection is closed (
locally by the provider, or remotely by the network) or has errored
the serializer is flushed. The one exception to this is if
ReleaseResponse PDU is being serialized and transmitted to
network. In this case, the provider will not close the
connection until after the serializer has finished
10.2. Elements of Procedure specific to the udp-based
The provider maintains the following information for
presentation connection
- a local designator for the PS-
- the 32-bit IP address and 16-bit UDP port number of
initiating
- the 32-bit IP address and 16-bit UDP port number of
responding
- the session connection identifier used to establish
presentation
Rose [Page 16]
RFC 1085 ISO Presentation Services December 1988
- a local designator for an UDP
- the state of the connection (e.g., IDLE, WAIT1, and so on
- a retransmission
Upon receiving an event from the network, the provider finds
associated presentation connection. Matching is done on the basis
addresses, ports, and the session connection identifier (i.e.,
different presentation connections may differ only in their
connection identifier). If no presentation connection can be found
then for the purposes of discussion, it may be assumed that
"vanilla" presentation connection is created and initialized to
IDLE state. Further, whenever a connection remains in or returns
the IDLE state, any associated resources, such as an attachment to
local UDP port, are released
In the procedures which follow, outgoing PDUs are "placed on
input queue for the serializer". This means that the ASN.1 object
serialized and the resulting sequence of octets is sent as a
UDP datagram
10.3. State
Following are the rules for transitioning states. If an
associated with a user-generated primitive is omitted, then it is
interface error for the user to issue that primitive in the
state. Each state considers all possible incoming PDUs
We assume that for the tcp-based service, that some entity starts
passive TCP open. When the passive open completes, the entity,
some local rule, locates a PS-user to be associated with the
presentation connection. This presentation connection is then
in the IDLE state. The entity then continues listening for
passive opens to complete. The mechanisms associated with
entity are entirely a local matter, the concept of this listener
introduced solely as a modeling artifact
Finally, if the udp-based service is selected, then CL-UserData
are exchanged by the provider instead of UserData PDUs
IDLE
Event: P-CONNECT.REQUEST primitive
Based on the quality of service parameter and the list of
addresses in the called presentation address parameter, the
Rose [Page 17]
RFC 1085 ISO Presentation Services December 1988
selects an address for the use of the presentation connection.
method for making this determination is a local matter. (Appendix
discusses a strategy which might be used.) For the discussion
follows, we assume that a network address supporting the
quality of service has been determined
Based on the network address chosen from the called
address parameter, the provider selects a compatible network
from the calling presentation address parameter. The
attaches itself to the port associated with this network address
(By local determination, this address need not be used, and
"ephemeral" port may be chosen by the provider.)
For the tcp-based service, the provider attempts to establish a
connection to the network address listed in the called
address. If the connection can not be established, the P
CONNECT.CONFIRMATION(-) primitive is issued with a reason
provider-rejection, and the provider remains in the IDLE state
Regardless, the user data parameter is placed in a
PDU, which is put on the input queue for the serializer
For the udp-based service, the provider sets the
counter to a small value (e.g., 2), and now starts a small timer
Regardless, the provider enters the WAIT1 state
Event: ConnectRequest PDU
The provider issues the P-CONNECT.INDICATION primitive and enters
WAIT2 state
Event: any other PDU
If the PDU is not an Abort PDU, the provider constructs a provider
initiated Abort PDU, which is put on the input queue for
serializer. Regardless, the provider remains in the IDLE state
WAIT1
Event: P-U-ABORT.REQUEST primitive
The user data parameter is placed in an Abort PDU, which is put
the input queue for the serializer. The provider enters the
state
Rose [Page 18]
RFC 1085 ISO Presentation Services December 1988
Event: ConnectResponse PDU
For the udp-based service, the timer is cancelled. If the
indicates rejection, the P-CONNECT.CONFIRMATION(-) primitive
issued and the provider enters the IDLE state. Otherwise, the P
CONNECT.CONFIRMATION(+) primitive is issued and the provider
the DATA state
Event: user-initiated Abort PDU
The provider issues the P-U-ABORT.INDICATION primitive and enters
IDLE state
Event: any other PDU
If the PDU not an Abort PDU, the provider constructs a provider
initiated Abort PDU, which is put on the input queue for
serializer. Regardless, The provider issues the P-P-ABORT.
primitive and enters the the IDLE state
Event: timer
The provider decrements the retransmission counter. If the
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
serializer, the small timer is started again, and the
remains in the WAIT1 state
WAIT2
Event: P-CONNECT.RESPONSE primitive
The user data parameter is placed in a ConnectResponse PDU, which
put on the input queue for the serializer. If the result
had the value user-rejection, the provider enters the IDLE state
Otherwise if the parameter had the value acceptance, the
enters the DATA state
Rose [Page 19]
RFC 1085 ISO Presentation Services December 1988
Event: P-U-ABORT.REQUEST primitive
The user data parameter is placed in an Abort PDU, which is put
the input queue for the serializer. The provider enters the
state
Event: user-initiated Abort PDU
The provider issues the P-U-ABORT.INDICATION primitive and enters
IDLE state
Event: any other PDU
If the PDU is not an Abort PDU, the provider constructs a provider
initiated Abort PDU, which is put on the input queue for
serializer. Regardless, The provider issues the P-P-ABORT.
primitive and enters the the IDLE state
DATA
Event: P-DATA.REQUEST primitive
The user data parameter is placed in a UserData PDU, which is put
the input queue for the serializer. The provider remains in the
state
Event: P-RELEASE.REQUEST primitive
The user data parameter is placed in a ReleaseRequest PDU, which
put on the input queue for the serializer
For the udp-based service, the provider sets the
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
The user data parameter is placed in an Abort PDU, which is put
the input queue for the serializer. The provider enters the
state
Rose [Page 20]
RFC 1085 ISO Presentation Services December 1988
Event: UserData PDU
The provider issues the P-DATA.INDICATION primitive and remains
the DATA state
Event: ReleaseRequest PDU
The provider issues the P-RELEASE.INDICATION primitive, and
the WAIT4 state
Event: user-initiated Abort PDU
The provider issues the P-U-ABORT.INDICATION primitive and
the IDLE state
Event: any other PDU
If the PDU is not an Abort PDU, the provider constructs a provider
initiated Abort PDU, which is put on the input queue for
serializer. Regardless, the provider issues the P-P-ABORT.
primitive and enters the the IDLE state
WAIT3
Event: P-U-ABORT.REQUEST primitive
The user data parameter is placed in an Abort PDU, which is put
the input queue for the serializer. The provider enters the
state
Event: ReleaseResponse PDU
For the udp-based service, the timer is cancelled. The
issues the P-RELEASE.CONFIRMATION primitive and enters the
state
Event: user-initiated Abort PDU
The provider issues the P-U-ABORT.INDICATION primitive and enters
IDLE state
Rose [Page 21]
RFC 1085 ISO Presentation Services December 1988
Event: any other PDU
If the PDU is not an Abort PDU, the provider constructs a provider
initiated Abort PDU, which is put on the input queue for
serializer. Regardless, the provider issues the P-P-ABORT.
primitive and enters the the IDLE state
Event: timer
The provider decrements the retransmission counter. If the
value is less than or equal to zero, the provider constructs
provider-initiated Abort PDU, which is put on the input queue for
serializer. It then issues the P-P-ABORT.INDICATION primitive
enters the IDLE state. Otherwise, a ReleaseRequest PDU is put on
input queue for the serializer, the small timer is started again,
the provider remains in the WAIT3 state
WAIT4
Event: P-RELEASE.RESPONSE primitive
The user data parameter is placed in a ReleaseResponse PDU, which
put on the input queue for the serializer. The provider now
the IDLE state
Event: P-U-ABORT.REQUEST primitive
The user data parameter is placed in an Abort PDU, which is put
the input queue for the serializer. The provider now enters the
state
Event: user-initiated Abort PDU
The provider issues the P-U-ABORT.INDICATION primitive and enters
IDLE state
Event: any other PDU
If the PDU is not an Abort PDU, the provider constructs a provider
initiated Abort PDU, which is put on the input queue for
serializer. Regardless, the provider issues the P-P-ABORT.
primitive and enters the the IDLE state
Rose [Page 22]
RFC 1085 ISO Presentation Services December 1988
11. Directory
Although not properly part of the presentation service, this
assumes and specifies a minimal Directory service capability for
by the application-entity
The function of the Directory Service Element is to provide
mappings: first, a service name is mapped into an application
title, which is a global handle on the service; and, second,
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
upon at the present time. Since objects of this type are
interpreted by the presentation service, this memo does not
their structure. If the DIS version of association control is
used, then use of an OBJECT IDENTIFIER will suffice. If the
version is being employed, then application-entity titles consist
two parts: an application-process title and an application-
qualifier. It is suggested that the AP-Title use an
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
mechanisms proposed by this memo is
"-"
where is a string denoting either domain name or
32-bit IP address, and is a string denoting the
of application-entity desired, e.g.,
"gonzo.twg.com-mgmtinfobase
2. Any locally defined mapping rules may be used to map
service designation into an application-entity title
3. The application-entity title is then mapped into
presentation address, with uninterpreted transport, session,
presentation selectors, and one or more network addresses,
containing
-the 32-bit IP address resolved from the
of the service name
- a set indicating which transport services are
Rose [Page 23]
RFC 1085 ISO Presentation Services December 1988
at the IP address
- the 16-bit port number resolved from the
portion of the service name (using the Assigned
document),
- optionally, a presentation selector, which is
uninterpreted sequence of octets
The method by which the mappings are obtained are straight-forward
The directory services element employs the Domain Name System
with a local table which may be used to resolve the address
local rules
In the simplest of implementations, the DNS is used to map
to an IP address, and to fill-in the set of
services available at the IP address. The port number is found in
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
provide a presentation selector. This would be useful, e.g.,
"proxy" connections. The network address would resolve to the
agent for the non-IP device, and the presentation selector
indicate to the proxy agent the particular non-IP device desired
This implies, of course, that the local table and the proxy
bilaterally agree as to the interpretation of each
selector
12.
To begin, if one really wanted to implement ISO applications in
TCP/IP-based network, then the method proposed by [RFC1006] is
preferred method for achieving this. However, in a
environment, where it is necessary to host an application
entity with a minimal amount of underlying OSI infrastructure,
memo proposes an alternative mechanism. It should be noted that
OSI application realized using this approach can be moved directly
an [RFC1006]-based environment with no modifications
A key motivation therefore is to minimize the size of the
underling infrastructure specified by this memo. As more and
presentation services functionality is added, the method
herein would begin to approximate the ISO presentation protocol
Since this in contrary to the key motivation, featurism must
avoided at all costs
Rose [Page 24]
RFC 1085 ISO Presentation Services December 1988
13.
Several individuals contributed to the technical quality of
memo
Karl Auerbach, Epilogue
Joseph Bannister,
Amatzia Ben-Artzi,
Stephen Dunford,
Lee Labarre,
Keith McCloghrie, The Wollongong
Jim Robertson, Bridge
Glenn Trewitt, Stanford
14.
[ISO7498] Information Processing Systems - Open
Interconnection, "Basic Reference Model", October, 1984.
[ISO8509] Information Processing Systems - Open
Interconnection, " Service Conventions".
[ISO8650] Information Processing Systems - Open
Interconnection, " Protocol Specification for
Association Control Service Element (Final
of DIS 8650)", January, 1988.
[ISO8822] Information Processing Systems - Open
Interconnection, " Connection Oriented
Service Definition (Final Text of DIS 8822)",
April, 1988.
[ISO8823] Information Processing Systems - Open
Interconnection, " Connection Oriented
Protocol Specification (Final Text of DIS 8822)",
April, 1988.
[ISO8824] Information Processing Systems - Open
Interconnection, " Specification of Abstract
Notation One (ASN.1)", December, 1987.
[ISO8825] Information Processing Systems - Open
Interconnection, "Specification of basic encoding
for Abstract Syntax Notation One (ASN.1)",
December, 1987.
[ISO9072/2] Information Processing Systems - Text
MOTIS, " Remote Operations Part 2:
Rose [Page 25]
RFC 1085 ISO Presentation Services December 1988
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
Protocol Specification", RFC 791, USC/ISI
September 1981.
[RFC793] Postel, J., "Transmission Control Protocol -
Internet Program Protocol Specification", RFC 793,
USC/ISI, September 1981.
[RFC1006] Rose, M., and D. Cass, "ISO Transport 1 on Top of
TCP Version: 3", Northrop Research and
Center, May 1987.
Appendix A
Abstract Syntax
RFC1085-PS DEFINITIONS ::=
PDUs ::=
CHOICE {
ConnectRequest-PDU
ConnectResponse-PDU
ReleaseRequest-PDU
ReleaseResponse-PDU
Abort-PDU
UserData-PDU
cL-
CL-UserData-
Rose [Page 26]
RFC 1085 ISO Presentation Services December 1988
}
-- connect request
ConnectRequest-PDU ::=
[0]
IMPLICIT SEQUENCE {
version[0] -- version-1 corresponds to to
IMPLICIT INTEGER { version-1(0) },
SessionConnectionIdentifier
OPTIONAL
called[2]
IMPLICIT
OPTIONAL
asn[3] -- the ASN for PCI #1
IMPLICIT OBJECT IDENTIFIER
user-
UserData-
}
SessionConnectionIdentifier ::=
[0]
SEQUENCE {
T61String
UTCTime
additionalReferenceInformation[0]
IMPLICIT T61
}
PresentationSelector ::=
[1]
IMPLICIT OCTET
Rose [Page 27]
RFC 1085 ISO Presentation Services December 1988
-- connect response
ConnectResponse-PDU ::=
[1]
IMPLICIT SEQUENCE {
reference -- present only in the udp-
--
OPTIONAL
OPTIONAL
reason[2] -- present only if the
-- was
IMPLICIT Rejection-
OPTIONAL
user-data -- present only if reason is
-- OR has
-- value rejected-by-
UserData-
}
Rejection-reason ::=
INTEGER {
rejected-by-responder(0)
called-presentation-address-unknown(1),
local-limit-exceeded(3),
protocol-version-not-supported(4),
}
-- release request
ReleaseRequest-PDU ::=
[2]
IMPLICIT SEQUENCE {
reference -- present only in the udp-
--
OPTIONAL
user-
UserData-
}
Rose [Page 28]
RFC 1085 ISO Presentation Services December 1988
-- release response
ReleaseResponse-PDU ::=
[3]
IMPLICIT SEQUENCE {
reference -- present only in the udp-
--
OPTIONAL
user-
UserData-
}
-- abort
Abort-PDU ::=
[4]
SEQUENCE {
reference -- present only in the udp-
--
OPTIONAL
user-data -- MAY BE present on user-initiated
UserData-
OPTIONAL
reason[1] -- ALWAYS present on provider-initiated
IMPLICIT Abort-
}
Abort-reason ::=
INTEGER {
unspecified(0),
unrecognized-ppdu(1),
unexpected-ppdu(2),
unrecognized-ppdu-parameter(4),
invalid-ppdu-parameter(5),
reference-mismatch(9)
}
-- data
UserData-PDU ::=
[5] -- this is the ASN.1
Rose [Page 29]
RFC 1085 ISO Presentation Services December 1988
ANY -- if it is a top-level PDU,
-- is in PCI #1, otherwise PCI #3
-- data PDU for the udp-based
CL-UserData-PDU ::=
[6]
IMPLICIT SEQUENCE {
SessionConnectionIdentifier
user-data[0] -- this is the ASN.1
ANY -- it is always in PCI #1
}
Appendix B
Example of
Consider the following call to ROSE
RO-INVOKE (operation number = 5
operation class =
argument =
invocation identifier = 1
linked invocation id. =
priority = 0)
.
Ultimately, ROSE will use the P-DATA service
P-DATA (user data = {
1, -- this is the
{ -- this is the ASN.1
invokeID 1,
operation-value 5,
argument {}
}
})
.
The presentation provider will construct a UserData PDU and send
via the transport connection
Rose [Page 30]
RFC 1085 ISO Presentation Services December 1988
[5] {
{
1,
5,
{}
}
}
Applying the basic encoding rules for ASN.1, we have an stream of 12
octets
a5 0a [5]
tag
a0 08 [0]
tag
02 01 01 invokeID 1
tag len
02 01 05 operation-value 5
tag len
30 00 argument
tag
Of course, in actual use, the argument would not be NONE and
could be expected to dominate the size of the UserData PDU. However
it is worth nothing that the overhead of the encoding mechanism
is on the order of 10 octets, hardly a staggering amount
Appendix C
Determination of Network Called
As described in Section 10, when the P-CONNECT.REQUEST primitive
issued the presentation provider must determine which of the
addresses present in the called presentation address parameter to
for the presentation connection. The first step in
determination is to examine the quality of service parameter
consider only those network addresses which support the
transport service. In practice, it is likely that each
address will support exactly the same transport services, so
quality of service as a discriminant will either permit all or
or the network addresses present to be selected. This
describes a local policy which might be employed when deciding
network address to use
The policy distinguishes between "underlying failures"
Rose [Page 31]
RFC 1085 ISO Presentation Services December 1988
"connection establishment failures". An "underlying failure"
when, using the desired transport service, the
presentation provider is unable to contact the
presentation provider. For the tcp-based service, this means that
TCP connection could not be established for some reason. For
udp-based service, it means that a response was not received
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
presentation provider or the correspondent presentation user
The policy is simple: starting with the first network
present, attempt the connection procedure. If the procedure
due to an "underlying failure", then the next network address in
list is tried. This process is repeated until either an
connection is established or all network addresses are exhausted
If, however, a "connection establishment failure" occurs, then
presentation provider immediately indicates this failure to
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
on the "intensity" associated with the members present in the set
transport services for each network address
Author's Address
Marshall
The Wollongong
1129 San Antonio
Palo Alto, CA 94303
Phone: (415) 962-7100
EMail: mrose@TWG.
Rose [Page 32]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
