Network Working S.E. Hardcastle-Kille
Group University College London
INTERNET-DRAFT March 1992
The Simple OSI Stack
Status of this Memo
This document specifies a mapping of protocols defined by the Abstract
Service Description Conventions onto Connection Oriented Transport
Service, Connectionless Transport Service, TCP, and UDP [MHS88b].
This mapping will support all ROS (Remote Operation Service) based
protocols, such as directory, both with and without use of RTS
(Reliable Transfer Service), and all of the X.400 services
[ISO88, CCI88, MHS88a].
Four example applications of the Simple OSI Stack (SOS) are given in
appendices. These are all ``real'' examples, which will are quite
likely to evolve into formal specifications. They are intended to
show that specification of SOS applications is very straightforward
and useful. These examples will be dropped from future versions of
this document, and perhaps be replaced by artificial examples.
This draft document will be submitted to the RFC editor as a protocol
standard. Distribution of this memo is unlimited. Please send
comments to the author or to the discussion group
<osi-ds@CS.UCL.AC.UK>.
INTERNET--DRAFT Simple OSI Stack March 1992
Contents
1 Introduction 4
2 Goals 5
3 Model 6
4 Deployment in Conjunction with Full Stack OSI 6
5 Comparison with Previous Work 7
6 PDUs 7
6.1 Application Entity Titles . . . . . . 9
7 Operational Procedures 10
7.1 Terminology . . . . . . . . . . 10
7.2 User Data . . . . . . . . . . 10
7.3 Binding . . . . . . . . . . . 11
7.4 Unbinding . . . . . . . . . . 12
7.5 Operation . . . . . . . . . . 13
7.6 Reject . . . . . . . . . . . 13
8 Mapping onto Used Services 13
8.1 Connectionless Mappings . . . . . . . 13
8.1.1 Connectionless Transport Service . . . 14
8.1.2 UDP . . . . . . . . . . 14
8.2 Connnection Oriented Mappings . . . . . 14
8.3 Connection Oriented Transport Service . . . 15
8.3.1 TCP . . . . . . . . . . 15
9 Streaming 15
10 Checkpointing and Resumption 16
Hardcastle-Kille Page 1
INTERNET--DRAFT Simple OSI Stack March 1992
11 Application Level Relaying 18
12 Encoding 19
13 Addressing 19
13.1 Application Context . . . . . . . . 19
13.2 COTS and CLTS Mappings . . . . . . . 19
13.3 TCP and UDP Mappings . . . . . . . . 19
14 Security Considerations 20
15 Author's Address 21
A Nameserver Protocol 1 21
A.1 Options . . . . . . . . . . . 23
A.2 Mapping . . . . . . . . . . . 23
A.3 Encoding . . . . . . . . . . . 23
A.4 Port Assignment . . . . . . . . . 23
B Nameserver Protocol 2 23
B.1 Options . . . . . . . . . . . 25
B.2 Mapping . . . . . . . . . . . 25
B.3 Encoding . . . . . . . . . . . 26
B.4 Port Assignment . . . . . . . . . 26
C MTA Transfer 26
C.1 Options . . . . . . . . . . . 26
C.2 Mapping . . . . . . . . . . . 26
C.3 Encoding . . . . . . . . . . . 26
C.4 Port Assignment . . . . . . . . . 27
D Directory Access Protocol 27
D.1 Options . . . . . . . . . . . 28
D.2 Mapping . . . . . . . . . . . 28
Hardcastle-Kille Page 2
INTERNET--DRAFT Simple OSI Stack March 1992
D.3 Encoding . . . . . . . . . . . 29
D.4 Port Assignment . . . . . . . . . 29
Hardcastle-Kille Page 3
INTERNET--DRAFT Simple OSI Stack March 1992
1 Introduction
The majority of OSI Applications fall into two classes:
1. ROS based services without RTS.
2. ROS based services with RTS.
A third category is closely related: RTS based services which do not
use ROS. There is only one well known protocol in this category (X.400
P1), but it is an important protocol.
This family of protocols uses the session and presentation layer
service. Most of the services provided by these layer protocols are
not used by this family of applications. These protocols use three
Application Service Elements (ASEs): Association Control; Reliable
Transfer; and Remote Operations. Much of the complexity of the
protocols used to provide the ASE services upwards relate to the way
in which the session and presentation services are used.
A much simpler mapping onto the transport service is possible for this
family of protocols. This specification defines such a mapping.
There are a number of reasons why this work is needed:
o The potential for higher performance, and increasing the domain of
applicability of ASDC based applications. In particular, it will
make it much easier to achieve performance comparable to
conventional RPC approaches.
o It reduces complexity, which is inherently desirable.
o It reduces the number of documents which an implementor needs to
read.
o It enables a number of problems which have been exposed with
ROS-based implementations to be fixed. These are discussed in the
next section.
Hardcastle-Kille Page 4
INTERNET--DRAFT Simple OSI Stack March 1992
2 Goals
The following goals are defined for this specification. The first is
the initial motivation, described above. The remaining goals are
additional features, which are not available in the current mappings,
but are seen to be desirable.
o To provide a mapping from the ASDC onto COTS, which is a strict
replacement for the mapping onto ACSE, RTS, and ROS.
o To provide a mapping onto CLTS, which will be useful for some
applications specified in ROS.
o To provide mappings onto TCP and UDP, the equivalent TCP/IP
services.
o With ROS mapped onto RTS, there is a strict ``layering''. This
makes the mapping awkward to implement in a manner such that
transfer resumption can be used effectively, and also forces use
of RTS for all ROS PDUs, some of which may be small. SOS allows
checkpointing/resumption to be selected for some PDUs only, and
does not require two way alternate.
o Rebinding may be done without breaking the transport connection.
An example of the utility of this is for an application where an
agent has bound with one authentication, and wishes to rebind with
different authentication.
o A means for the responder of the association to request clean
association release. An example of where this might be useful is
when a DUA connects to a DSA, and holds the connection open. It
is desirable that the DSA can request the DUA to cleanly close the
association.
o A means for the responder of the association to reject a request
to unbind is provided. This may be useful if the SOS-initiator
requests the unbind at the same time as the SOS-responder invokes
an operation.
o Provide an unambiguous means for an RTS user to permanently reject
a user PDU (e.g., for protocol violation).
Hardcastle-Kille Page 5
INTERNET--DRAFT Simple OSI Stack March 1992
o Give support for ``streaming''. ROS-based specifications often
define large PDUs (e.g., messages). If the protocol is being used
interactively, it is desirable that the PDU is displayed as it is
being transferred across the net. For example, when listing in
the directory, it would be useful to request a very large number
of entries, and then let them ``flow'' over the net. This would
be a much cleaner way to provide the paged results mechanisms of
X.500(92). This could in principle be implemented without change
of protocol, but requires a very awkward interaction between the
network, the application protocol, and the application. SOS
defines an approach to allow the ROS PDUs to be broken on
boundaries which have meaning to the application. This will make
streaming straightforward to implement, whilst retaining the
cleanliness of the existing ROS specification.
o Provide support for application level relaying. This is
beneficial when direct connectivity is not possible at the network
level either for physical or policy reasons. In the former case,
this approach is much cleaner than transport bridging. In the
latter, it provides a clean management model for control of
external access.
3 Model
This specification essentially follows the OSI model. The services of
the session and presentation layer required by these applications are
conceptually provided by SOS. SOS follows the OSI approach to
services, but performs layer compression to radically simplify the
protocols.
4 Deployment in Conjunction with Full Stack OSI
For deployment to be effective, and not simply to add in another
boundary it is important that server implementations support both SOS
and full stack OSI, in order to provide for application relaying and
overall uniform service.
Hardcastle-Kille Page 6
INTERNET--DRAFT Simple OSI Stack March 1992
5 Comparison with Previous Work
A similar piece of work was attempted earlier in the Lightweight
Presentation Protocol (LPP) [Ros88]. Whilst this has been implemented
and deployed, it has not achieved widespread success. Whilst there
are some similarities to SOS, there are quite a few differences, some
of which I believe to be critical:
o LPP cut at presentation level, which removed some potential for
simplification within the application layer.
o LPP maps onto TCP only. SOS also maps onto COTS, and so can be
used with OSI lower layers.
o LPP gives only a connection-oriented mapping. SOS also gives a
connectionless mapping, which will be critical for some
applications (e.g., Directory).
o LPP does not support ROS with RTS.
o LPP cannot support X.400. This is a critical problem.
o The LPP implementation in ISODE is a compile time choice, which
prevents building relays to full-stack OSI. Whilst this might seem
to be a detail, I believe that LPP would have definite local uses
today if this had been available.
6 PDUs
This section defines the basic SOS PDUs. At the top level, SOS PDUs
are broken into four types. The KernelPDU is described here, as this
covers the basic approach of SOS. Other parts of SOS are defined
later. A protocol using SOS will often only need a small selection of
the PDUs. This is defined implicitly by the ASDC description.
SOSPDU ::= CHOICE -
KernelPDU,
ResumptionPDU,
StreamingPDU,
RelayPDU "
Hardcastle-Kille Page 7
INTERNET--DRAFT Simple OSI Stack March 1992
KernelPDU ::= CHOICE -
bind-argument [0] BindArgument,
bind-result [1] BindArgument,
bind-error [2] OptionalUserData,
unbind-argument [3] UnbindArgument,
unbind-result [4] OptionalUserData,
unbind-error [5] OptionalUserData,
operation-argument [6] Argument,
operation-result [7] Result,
operation-error [8] Error,
reject [9] Reject
UserData ::= ANY -- defined by application --
OptionalUserData ::= SEQUENCE -UserData OPTIONAL"
BindArgument ::= SEQUENCE -
version-number [0] INTEGER,
application-entity-title [1] DirectoryName OPTIONAL,
application-context [2] OBJECT IDENTIFIER OPTIONAL,
association-identifier [3] AssociationIdentifer OPTIONAL,
resumption-information [4] ResumptionInformation OPTIONAL,
use-streaming [5] BOOLEAN DEFAULT FALSE,
user-data [6] UserData OPTIONAL "
DirectoryName ::= CHOICE -
DistinguishedName,
IA5String "
AssociationIdentifier ::= PrintableString
UnbindArgument ::= SEQUENCE -
type ENUMERATED -
normal(1),
retain-transport-connection(2),
responder-request(3) "
UserData "
Argument ::= SEQUENCE -
invoke-id InvokeID,
linked-id [0] InvokeID,
Hardcastle-Kille Page 8
INTERNET--DRAFT Simple OSI Stack March 1992
operation INTEGER,
Userdata OPTIONAL "
InvokeID ::= INTEGER
Result ::= SEQUENCE -
InvokeID,
Userdata OPTIONAL "
Error ::= SEQUENCE -
InvokeID,
ErrorID,
UserData "
ErrorID ::= INTEGER
Reject ::= SEQUENCE -
reason ENUMERATED -
temporary-provider-reject(0),
temporary-user-reject(1),
-- permanent errors
provider-protocol-error(2)
user-protocol-error(3),
user-permanent-reject(4),
version-not-supported(5),
duplicate-invokation(6),
unrecognised-operation(7),
unrecognised-linked-id(8),
linked-response-unexpected(9),
unrecognised-invokation(10),
result-response-unexpected(11),
unrecognised-invokation(12),
error-response-unexpected(13),
unrecognised-error(14),
unexpected-error(15) "
supplementary-information PrintableString OPTIONAL "
6.1 Application Entity Titles
An Application Entity Title (AET) is a directory distinguished name.
SOS allows two different encodings of AET. An application using SOS
Hardcastle-Kille Page 9
INTERNET--DRAFT Simple OSI Stack March 1992
will usually specify which form should be used. The forms are:
1. The encoding of Distinguished Name, as specified in the OSI
Directory.
2. A string representation of Distinguished Name, as specified in
[HK92a]. This is available, as the encoding of Distinguished Name
is complex, and for many applications, it will be preferable to
use this simple form.
7 Operational Procedures
7.1 Terminology
SOS-entity A SOS provider entity.
SOS-user The entity which is using the services provided by a
SOS-entity.
SOS-use-definition The protocol specification which is mapping onto
SOS.
SOS-initiator The SOS-entity which initiates the SOS Association.
SOS-reponder The SOS-entity which responds to the SOS association.
SOS-operation-invoker The SOS-entity which invokes an operation.
SOS-operation-responder The SOS-entity which responds to an invoked
operation.
7.2 User Data
Many of the PDUs have an Element UserData. This will always refer to
a type definition from the ASDC description. For example, in the
Operation PDU, the type is defined in the OPERATION MACRO of ROS in
the SOS-use-definition.
Hardcastle-Kille Page 10
INTERNET--DRAFT Simple OSI Stack March 1992
7.3 Binding
If a BIND definition is present in the SOS-use-definition ASDC
specification, then the procedure for binding must be followed. If
this definition is not present, the procedure may still be followed.
The protocol mapping onto SOS should specify if this mandatory,
optional, or absent.
When binding procedures are followed, a bind-argument is sent by the
SOS-initiator, and either a bind-result or bind-error is returned by
the SOS-responder. The parameters for bind-argument are as follows.
version This is set to 1.
application-entity-title The setting of this parameter, and the form
used is defined by the SOS-use-definition.
association-identifier This is a unique identifier of the association
between the pair of application entities. It will always be set
if resumption-information is present, and may be set in other
cases for logging purposes.
resumption-information This will be present if resumption is
requested.
use-streaming This may be present if explicitly permitted by the
SOS-use-definition.
user-data This is a value of the type defined in the BIND ARGUMENT.
If the SOS-responder rejects the bind, then a bind-error is sent, with
the UserData omitted.
If the user of the SOS-responder rejects the bind, then a bind-error
is sent, with the UserData type defined by the ERROR parameter.
If the user of the SOS-responder accepts the bind, then a bind-result
is sent, with the following parameters:
version This is set to the highest version supported, which is less
than or equal to that proposed. If a mutually convenient version
cannot be reached, a reject is sent.
application-entity-title The setting of this parameter, and the form
Hardcastle-Kille Page 11
INTERNET--DRAFT Simple OSI Stack March 1992
used is defined by the SOS-use-definition.
association-identifier This is omitted.
resumption-information This will be present if resumption is
requested and has been accepted.
use-streaming This may be present if explicitly permitted by the
SOS-use-definition, and this service was requested.
user-data This is a value of the type defined in the BIND RESULT.
7.4 Unbinding
Unbinding is a handshake initiated by the SOS-initiator, which will
send an unbind-argument. The SOS-responder will send back either a
unbind-result or unbind-error. This procedure is always followed if
the SOS-use-definition ASDC contains an UNBIND.
When the SOS-initiator sends a unbind-argument, the UserData is
defined by the UNBIND ARGUMENT. The type may have two values:
normal This is the usual case, and indicates that no more data will
be given to the transport provider.
retain-transport-connection This indicates that a bind will follow
the unbind.
If the user of the SOS-responder wishes to accept the unbind, it will
send an unbind-result, with the optional UserData type defined by the
UNBIND RESULT.
If the SOS-responder wishes to reject the unbind it will send an
unbind-error, with no UserData.
If the user of the SOS-responder wishes to reject the unbind it will
send an unbind-error, with the UserData type defined by the UNBIND
ERROR.
If the SOS-responder wishes to end the association, it should send an
unbind-error, with the verb_type_ set to responder-request. The
SOS-initiator shall then initiate an unbind in the usual way, unless
it has good reason not to (e.g., it has just started another
operation).
Hardcastle-Kille Page 12
INTERNET--DRAFT Simple OSI Stack March 1992
7.5 Operation
Whether the SOS-initiator, the SOS-responder, or both may invoke
operations is specified in the SOS-use-definition.
When a SOS-user issues an invoke, an operation-argument PDU is sent.
The operation from the SOS-use-definition is identified by the
operation parameter. All SOS operations must be identified by
integers, not object identifiers. This does not to lose generality,
as the operations only need to be unique in the context of a given
application context. The UserData defined by the OPERATION ARGUMENT
of the operation in question. The InvokeID is an integer, which
uniquely identifies the operation. The value of this starts at 1, and
monotonically increases of the life of the association.
The operation-argument is received by the SOS-operation-responder, and
is passed to the associated SOS-user. The SOS-use-definition
indicates the procedure for the SOS-user to follow. This may result,
in a result, an error, or no response.
If a result is sent, the SOS-operation-responder sends a
operation-result. The InvokeID matches the invoke, and the UserData
type is defined by the OPERATION RESULT of the operation in question.
If an error is sent, the SOS-operation-responder sends a
operation-error. The InvokeID matches the invoke, and the error-id
identifies the error from the SOS-use-definition ASDC. The UserData
type is defined by the PARAMETER of the ERROR.
7.6 Reject
A general purpose reject is provided, which can deal with user and
provider errors in operations, bind, and unbind.
8 Mapping onto Used Services
8.1 Connectionless Mappings
The SOS PDUs are self delimiting. A sequence of SOS PDUs is mapped
onto a connectionless PDU by simple concatenation, and no further
encapsulation or parameters.
The SOS-initiator sends a PDU containing at least one SOS PDU. This
will be:
Hardcastle-Kille Page 13
INTERNET--DRAFT Simple OSI Stack March 1992
o A bind-argument. In addition to what has been described above,
parameters are set as follows:
association-identifier This is a unique handle to identify the
request.
resumption-information Always absent.
use-streaming Always false.
o Zero or more operation-arguments.
o An optional unbind-argument.
In all cases, the SOS-responder will send back a response. This will
be sent to the called address of the SOS-initiator.
o A response to the bind.
o Responses to each operation that needs a response.
o A response to the unbind, if present in the request.
If no response is received, the SOS-Initiator may retransmit the
request.
8.1.1 Connectionless Transport Service
The PDU containing the SOS PDUs is mapped onto A-UNIT-DATA.
8.1.2 UDP
The PDU containing the SOS PDUs is mapped onto a UDP Datagram.
8.2 Connnection Oriented Mappings
A connection is first established. If the bind procedure used, this
handshake should take place before the SOS-initiator invokes any
operations. Then operations may be invoked in either direction.
Hardcastle-Kille Page 14
INTERNET--DRAFT Simple OSI Stack March 1992
Where operations may be invoked by the SOS-responder, the unbind
procedure must always be used. This will allow the SOS-responder to
reject the unbind where operations are outstanding.
If an unbind is not accepted, the association is considered to be
open, and the SOS-initiator should retry the unbind.
8.3 Connection Oriented Transport Service
Each PDU is mapped onto T-DATA.
The unbind procedure must always be used. When the unbind ends the
transport connection, the SOS-initiator shall close the transport
connection when it receives the unbind-result. When the SOS-responder
has sent the unbind-result, it should wait for 10 seconds before
closing the transport connection. This timer is to prevent the
unbind-result from being flushed as the connection is closed.
8.3.1 TCP
Each PDU, which is self delimiting, is sent onto the TCP byte stream.
The TCP connection should always be closed cleanly.
9 Streaming
*** repeat text from intro ***
Use of streaming is a facility which must be requested by both
SOS-entities. An SOS-use-definition may make use of streaming
mandatory, optional, or absent. The facility is negotiated at bind
time.
A SOS-use-definition defines which arguments, results and errors that
streaming can be applied to, and the list of permitted breakpoints.
Streaming is selected by omitting the UserData to be streamed from the
PDU which would have contained it. This data is then sent in a
sequence of streamed PDUs. There shall be a maximum of one streamed
PDU being transmitted in each direction at any one time. This does
not prohibit other (non-streamed) PDUs from being transferred. In
particular, an abandon may be sent, to terminate the operation in
mid-flow. The StreamingPDU is defined as follows:
Hardcastle-Kille Page 15
INTERNET--DRAFT Simple OSI Stack March 1992
StreamingPDU ::= CHOICE -
first-or-intermediate [10] UserData,
last [11] UserData "
The data is sent as a sequence of StreamingPDUs, which can be
reconstructed into the original PDU. The individual PDUs should break
at natural points, and thus be straightforward for the application to
handle. The application will also need to define the ordering rules
for sending such PDUs. In many cases, the first PDU can be the
existing PDU, and then subsequent PDUs transfer bulky or repetitive
information. Usually these PDUs will be a small component of the
existing PDU.
If the operation is abandoned (perhaps at the request of the invoker)
before all of the data is transferred, a Reject PDU should be sent,
with reason temporary-user-reject.
10 Checkpointing and Resumption
ResumptionInformation ::= SEQUENCE -
transfer-direction ENUMERATED -
monologue-push(1),
monologue-pull(2),
two-way-simultaneous(3) ",
window-size INTEGER,
checkpoint-size INTEGER,
association-identifier [1] AssociationID OPTIONAL,
forward [2] ResumptionPoint OPTIONAL,
reverse [3] ResumptionPoint OPTIONAL "
ResumptionPoint ::= INTEGER
ResumptionPDU ::= CHOICE -
block [12] BlockNumber,
block-ack [13] INTEGER "
Block ::= SEQUENCE -
block-number BlockNumber,
last-block BOOLEAN,
data OCTET STRING "
Hardcastle-Kille Page 16
INTERNET--DRAFT Simple OSI Stack March 1992
BlockNumber ::= INTEGER
When resumption is going to be used, ResumptionInformation is
exchanged at bind time. The initiator proposes parameter settings,
and then the responder replies. The values specified by the responder
defines the agreement. The responder may refuse resumption by
omitting the entire parameter. Consider first the case when no
transfer is being resumed. The parameters are as follows:
transfer-direction Three choices are offered: monologue in either
direction, and two-way-simultaneous. The latter provides for
simultaneous transfer in both directions. In monologue cases,
there may be only one resumable transfer. In two way
simultaneous, there may be up to one resumable transfer in each
direction. Two way alternate may be provided by rebinding the
association with the opposite monologue direction selected. The
responder must accept the proposed setting, with the exception
that two way simultaneous may be negotiated down to monologue in
either direction.
window-size This defines the number of blocks which may be
outstanding without an acknowledgement received. The responder
may accept or decrease this value.
checkpoint-size This defines the block size, in units of 1024 bytes.
With the exception of the last block, blocks must be exactly this
size. This size is the user data, prior to wrapping in the
OCTET STRING encoding. The responder may accept or decrease this
value.
When initiating a new association, the remaining parameters are
absent. When resuming a transfer, the first parameters must be
exactly as negotiated in the transfer being resumed (i.e., the
SOS-initiator must propose these parameters, and the SOS-responder
accept them unchanged. The SOS-initiator must be the original
SOS-initiator. The association is identified by the
association-identifier. A transfer may be resumed in either direction
or both. If the resumption point is not present, the transfer should
be discarded, and started from scratch. The SOS-initiator proposes
resumption points for each transfer. The SOS-responder may reduce
Hardcastle-Kille Page 17
INTERNET--DRAFT Simple OSI Stack March 1992
these to a lower value. If the SOS-initiator is unable to resume at
this point, it should rebind, and discard the transfers.
Note: The combined use of streaming and resumption is not currently
allowed. It may be desirable to do this. This would mean
allowing blocking on boundaries used for streaming. This may be
desirable for some applications anyway.
An alternate approach might be to provide resumption for primitive
components transmitted within a PDU (e.g., an OCTET STRING
carrying a document within a directory access).
11 Application Level Relaying
RelayPDU ::= [14] CHOICE -
directory-name [1] DirectoryName,
presentation-address [2] PresentationAddress
ip-address [3] IPAddress "
IPAddress ::= PrintableString -- dot notation
It is often not possible for applications to connect directly.
Reasons for this include:
o The application services are mapped onto lower layer stacks which
do not interwork.
o There are organisational policy reasons, which wish to exert
application level controls at an organisational boundary.
Transport level bridging does not provide a solution to the second
problem, and has a number of practical difficulties with the first.
A mechanism to provide straightforward application level relaying is
provided. One or more relay PDUs may be sent at the start of the
connection. These define a source route. The first RelayPDU
indicates the next hop. The point may be defined by either its
Directory Name, or presentation address.
Hardcastle-Kille Page 18
INTERNET--DRAFT Simple OSI Stack March 1992
12 Encoding
No encoding rules are defined in this protocol. The encoding rules to
be used should be defined by the protocol which uses SOS. A protocol
using SOS is considered to have a single abstract syntax, which
includes the abstract syntax for SOS. The application then defines the
transfer syntax to be used. An application may support multiple
transfer syntaxes by defining an application context for each transfer
syntax. This is done, so that new transfer syntaxes (standard or
non-standard) may be introduced cleanly.
13 Addressing
13.1 Application Context
An application entity is identified by its directory name. When this
is looked up in the directory, it will identify a set of supported
application contexts.
13.2 COTS and CLTS Mappings
The location of an OSI Application Entity is defined by its
presentation address. For SOS mappings, presentation and session
selectors are not used. For mappings onto COTS or CLTS, the
application context must be present in the bind-argument, except where
the application entity only supports a single possible application
context.
13.3 TCP and UDP Mappings
The location of a SOS-entity is defined by a new attributes:
IPApplicationEntity OBJECT CLASS
SUBCLASS OF ApplicationEntity
MUST CONTAIN IPAddress
::= oc-ip-application-entity
IPAddress ATTRIBUTE
WITH SYNTAX IPAddress
Hardcastle-Kille Page 19
INTERNET--DRAFT Simple OSI Stack March 1992
::= ac-ip-address
The application context is implied by the selector, and so the
application context is always omitted from the bind-argument and
bind-result.
14 Security Considerations
Security is intentionally omitted from this version of SOS, although
it is likely to be added in later versions. Some key protocols have
applications specific security, and many useful things can be done
without these additions. It is seen as desirable to progress these
extensions separately.
The following security issues should be considered:
o Peer authentication at bind time.
o Proxy authentication, so that an entity indirectly using the
association can be authenticated (e.g., to provide a shared DUA).
o Per-operation authentication (e.g., as done by directory).
o Data confidentiality.
References
[CCI88] The Directory --- overview of concepts, models and services,
December 1988. CCITT X.500 Series Recommendations.
[HK92a] S.E. Hardcastle-Kille. A string representation of
distinguished name. Request for Comments in preparation,
Department of Computer Science, University College London,
January 1992.
[HK92b] S.E. Hardcastle-Kille. Using the OSI directory to achieve
user friendly naming. Request for Comments in preparation,
Department of Computer Science, University College London,
January 1992.
Hardcastle-Kille Page 20
INTERNET--DRAFT Simple OSI Stack March 1992
[ISO88] Remote operations: Model, notation and service definition,
December 1988. ISO/CCITT.
[MHS88a] CCITT recommendations X.400 / ISO 10021, April 1988. CCITT
SG 5/VII / ISO/IEC JTC1, Message Handling: System and
Service Overview.
[MHS88b] CCITT recommendations X.407/ ISO 10021, April 1988.
CCITT SG 5/VII / ISO/IEC JTC1, Message Handling: Abstract
Service Definition Conventions.
[Ros88] M.T. Rose. ISO Presentation Services on top of TCP/IP-based
internets. Request for Comments 1085, The Wollongong Group,
December 1988.
15 Author's Address
Steve Hardcastle-Kille
Department of Computer Science
University College London
Gower Street
WC1E 6BT
England
Phone: +44-71-380-7294
EMail: S.Kille@CS.UCL.AC.UK
DN: CN=Steve Hardcastle-Kille, OU=Computer Science,
O=University College London, C=GB
UFN: S. Hardcastle-Kille, Computer Science
University College London, GB
A Nameserver Protocol 1
This appendix gives an example nameservice protocol, which is a strict
subset of X.500 Directory Access Protocol mapped onto SOS.
Hardcastle-Kille Page 21
INTERNET--DRAFT Simple OSI Stack March 1992
DAPNS DEFINITIONS ::=
BEGIN
IMPORTS SimpleCredentials, Name, EntryInformationSelection,
CommonArguments, EntryInformation, CommonResults
FROM X.511
IMPORTS attributeError, nameError, serviceError, securityError ;
FROM X.519
DAPNSBind ::= BIND
ARGUMENT DAPNSBindArgument
RESULT DAPNSBindResult
ERROR DAPNSBindError
DAPNSBindResult ::= DAPNSBindArgument
DAPNSBindArgument ::= SET -
[0] Credentials OPTIONAL "
Credentials ::= SimpleCredentials
read OPERATION
ARGUMENT DAPNSReadArgument
RESULT DAPNSReadResult
ERROR -attributeError, nameError,
serviceError, securityError "
::= 1
DAPNSReadArgument ::= SET -
[0] Name,
[1] EntryInformationSelection DEFAULT -",
COMPONENTS OF CommonArguments "
DAPNSResult ::= SET -
[0] EntryInformation,
COMPONENTS OF CommonResults "
END
Hardcastle-Kille Page 22
INTERNET--DRAFT Simple OSI Stack March 1992
A.1 Options
Application Entity Titles should be omitted from the bind-argument, as
the same information is carried at the application level.
Resumption and streaming are not used.
A.2 Mapping
Connectionlness and connection oriented mappings are provided. The
following application contexts are defined:
ac-dap-ns-cots ::=
ac-dap-ns-clts ::=
ac-dap-ns-tcp ::=
ac-dap-ns-udp ::=
A.3 Encoding
The protocol is encoded using ASN.1 Basic Encoding Rules (BER).
A.4 Port Assignment
TCP PORT nnn is assigned UDP PORT nnn is assigned
B Nameserver Protocol 2
This appendix gives an example nameservice protocol which uses the
X.500 data model, but provides an entirely new access protocol.
SimpleNameServerProtocol DEFINITIONS ::=
BEGIN
NSRead OPERATION
ARGUMENT NSReadArgument
RESULT NSReadResult
ERRORS -NameError, UFNError, ServiceError"
::= op-ns-read
Hardcastle-Kille Page 23
INTERNET--DRAFT Simple OSI Stack March 1992
NSReadArgument ::= SEQUENCE -
name IA5String,
ufn BOOLEAN,
types SET OF AttributeType "
NSReadResult ::= SEQUENCE -
distinguished-name IA5String,
aliases-dereferenced INTEGER,
SET OF ATTRIBUTE "
Attribute ::= SEQUENCE -
AttributeType,
SET OF AttributeValue "
AttributeType ::= OBJECT IDENTIFIER
AttributeValue ::= ANY -- defined by AttributeType
NameError ::= SEQUENCE -
name-matched IA5String,
components-matched INTEGER,
aliases-dereferenced INTEGER
ufn-choices SET OF IA5String "
ServiceError ::= ENUMERATED -
unwilling-to-perform(0),
security-error(1),
busy(2),
dsa-unavailable(3) "
END
This protocol is for DUA to DSA access. It is used to look up
selected information associated with an object.
The argument to NSRead has the following options:
name The string form of the name being looked up.
ufn If this is false, the name is a string encoded distinguished name
[HK92a]. If this is true, the name is a user Friendly Name (UFN)
[HK92b], which should be resolved by the DSA.
Hardcastle-Kille Page 24
INTERNET--DRAFT Simple OSI Stack March 1992
types This is a list of attributes to be returned.
If the distinguished name is matched, or the UFN is resolved
unambiguously, the attributes matched are returned. This may be zero
or more attributes.
The operation may fail for a number of reasons. A service error gives
some of those. If an entry is not located unambiguously, a name error
is given. This has the following options:
name-matched This is the distinguished name of the longest portion
matched.
components-matched This is a count of the number of components in the
original name which led to this match.
aliases-dereferenced The number of aliases dereferenced to reach the
point matched.
name-choices If UFN is selected, this may be used to give a set of
ambiguous choices at the next level to be resolved.
B.1 Options
Bind should always be used, although no application level parameters
are specified. Application Entity Title should always be present,
primarily for logging purposes. The string form of encoding should be
used.
Resumption and streaming are not used.
B.2 Mapping
Only a connectionlness mapping is provided. The following application
contexts are defined:
ac-simple-ns-clts ::=
ac-simple-ns-udp ::=
Hardcastle-Kille Page 25
INTERNET--DRAFT Simple OSI Stack March 1992
B.3 Encoding
The protocol is encoded using ASN.1 Basic Encoding Rules (BER).
B.4 Port Assignment
UDP PORT nnn is assigned
C MTA Transfer
This appendix defines a mapping of X.400 MTA Transfer (P1) onto SOS.
A PDU of format MTS-APDU, as defined in X.419 should be carried as the
argument of an invoke only. There are no results or errors. The BIND
arguments are defined in X.411 (MTA Abstract Service). There is no
unbind.
C.1 Options
Application Entity Title should always be present in the bind, and the
ASN.1 form should be used.
Resumption may be used, and streaming is not used.
C.2 Mapping
Only a connection oriented mapping is provided. The following
application contexts are defined:
ac-sos-mts-transfer-cots ::=
ac-sos-mts-transfer-tcp ::=
C.3 Encoding
The protocol is encoded using ASN.1 Basic Encoding Rules (BER).
Hardcastle-Kille Page 26
INTERNET--DRAFT Simple OSI Stack March 1992
C.4 Port Assignment
TCP PORT nnn is assigned
D Directory Access Protocol
This appendix defines a mapping of X.500 Directory Access Protocol
(DAP) onto SOS, which illustrates how a mapping which utilises
streaming should be defined.
The standard DAP is used, with streaming allowed for the following:
o Breaking up search and list results so that (groups of) entries
may be returned separately.
o Breaking up read result, so that attributes may be returned
separately. Small attributes might be returned first, with large
attributes such as photos held back.
o Very large attribute values may be broken up, so the the protocol
can be used to retrieve things such as documents.
Streaming may not be used in conjunction with per-operation
authentication or with uncorrelated results. The three following PDUs
are allowed. Each define the PDUs allowed in the streamed result.
ListResult SOSDAPListResult ::= CHOICE -
wrapper [0] ListResult,
subordinates [1] SET OF SEQUENCE -
RelativeDistinguishedName,
aliasEntry [0] BOOLEAN DEFAULT FALSE,
fromEntry [1] BOOLEAN DEFAULT TRUE
"
"
The element wrapper is sent first, and this uses the standard DAP
PDU to send common information. Subsequent PDUs are sent as
subordinates, which give additional results from the list. The
ASN.1 of this PDU is the same as that used within ListResult.
SearchResult SOSDAPSearchResult ::= CHOICE -
Hardcastle-Kille Page 27
INTERNET--DRAFT Simple OSI Stack March 1992
wrapper [0] SearchResult,
hits [1] SET OF EntryInformation,
poq [2] PartialOutcomeQualifier
"
The element wrapper is sent first, and this uses the standard DAP
PDU to send common information. Subsequent PDUs are sent as hits,
which give additional results from the search. The PDU poq is
used to indicate areas of the DIT which have not been searched.
This can be repeated, and mixed with hits.
ReadResult SOSDAPReadResult ::= CHOICE -
wrapper [0] ReadResult,
attributes [1] SET OF Attribute,
attribute-fragment [2] Attribute
"
The element wrapper is sent first, and this uses the standard DAP
PDU to send common information. Subsequent PDUs are sent as
attributes, which give additional attributes from the entry. A
single attribute may be fragmented, and this must be the last
attribute sent (multiple attributes could be supported by addition
of another PDU). Only attributes with a primitive syntax can be
fragmented. The resulting attribute values from the
attribute-fragment are concatenated to make the single large
value.
D.1 Options
Application Entity Titles should be omitted from the bind-argument, as
the same information is carried at the application level.
Resumption is not used, and streaming may be used.
D.2 Mapping
Only a connection oriented mapping is provided. The following
application contexts are defined:
ac-dap-streamed-cots ::=
ac-dap-streamed-tcp ::=
Hardcastle-Kille Page 28
INTERNET--DRAFT Simple OSI Stack March 1992
D.3 Encoding
The protocol is encoded using ASN.1 Packed Encoding Rules (PER).
D.4 Port Assignment
TCP PORT nnn is assigned
Hardcastle-Kille Page 29