This module implements the OSI Connection-Oriented Transport
Protocol specification (International Standard ISO 8073); and
the Connectionless-Mode Transport Service Protocol (International
Standard ISO 8602) for Tru64 UNIX. For OpenVMS, this module also
implements RFC1006 and RFC1006 Extension. These protocols implement
the OSI Reference Model Transport Layer 4. These protocols, as
well as the NSP protocol, implement the transport protocols in
the Digital Network Architecture.
The OSI Transport Protocol permits communication between
DECnet-Plus systems and other vendors' systems that also implement
the OSI Transport Protocol. You can set up OSI Transport
connections:
o Between two systems on the same ISO 8802-3 LAN.
o Between two systems that are connected, either directly
or via an X.25 connection.
o Between two systems that are connected directly by an X.25
point-to-point link.
o Between two systems on different subnetworks, where the
linking subnetworks might mix technologies.
o Between two systems that are connected via TCP/IP.
Refer to CONNECTION_PHASES below for a description of the three
phases of an OSI Transport connection.
The OSI Transport Protocol conforms to the ISO 8072 Service
Definition and the ISO 8073 Protocol Standard. They define
OSI Transport Protocol classes 0, 2 and 4 (TP 0, TP 2, and TP 4).
This protocol can use two types of ISO Network service:
o Connection-Oriented Network Service (CONS)
o Connectionless-Mode Network Service (CLNS)
The Routing module provides a connectionless network service
(CLNS). The X.25 Access module, if configured into the system,
provides a reliable connection-oriented network service (CONS).
For Tru64 UNIX, any attributes that are specific to CONS will only
be accessible if X.25/CONS has been installed and configured into
the system. See X.25/CONS Configuration for more information. The
Connectionless Transport Service, known as CLTS or CLTP, allows
for the transfer of data between correspondent Transport Service
users on a connectionless basis. The service provides for single-
access data transfer for corresponding Transport Service users,
without the overhead of establishing a connection. This protocol
benefits those applications that require a one-time, one-way
transfer of data toward one Transport Service user. CLTS runs
over CLNS.
The OSI transport conforms to the RFC1006 Standard and to the
RFC1859 Standard. They define how to implement ISO 8073 Transport
Class 0 on top of TCP (RFC1006) and how to implement ISO 8073
Transport Class 2 Non-use of Explicit Flow Control on top of TCP
(RFC1859, once known as 1006 Extension). The network service used
is provided by TCP. These OSI over TCP/IP and DECnet over TCP/IP
features require an installed TCP/IP product that supports the PWIP
interface.
Refer to NETWORK_SERVICES below for a table which shows the
relationship between the transport protocols and the network
services.
Refer to PROTOCOL_CLASSES for a table describing the protocol
classes, their functions, and which network service can be used.
1 – Protocol Classes
The following table describes the protocol classes, their functions,
and which Network service can be used.
Protocol Functions Network Service
Class
---------------------------------------------------------------------
TP 0 Provides a basic Transport Service. CONS and RFC1006
TP 2 Provides Provides all functions of CONS and RFC1006 Ext
TP 0. Provides multiplexing of more
than one transport connection over a
Network Connection or TCP connection.
Provides flow control over CONS.
TP 4 Provides all functions of TP 2. CONS and CLNS
Provides error detection and recovery.
Some other differences are that:
o TP 0 relies on the upper layers to do its error correction.
This class is disconnected if the underlying Network layer is
disconnected.
o TP 2 and 4 use disconnect requests.
o TP 4 reassigns the OSI Transport connection to another Network
layer connection if the existing one fails.
When a Transport user sets up a Transport connection, a preferred
protocol class for the connection is specified in the connection
request. The responding Transport user must either agree to this
protocol class, or suggest an alternative protocol class that is
acceptable to the initiating user. If no such agreement is possible,
the Transport connection cannot be set up.
2 – Connection Phases
An OSI Transport connection is an end-to-end connection. It is a
reliable two-way, data-transfer path between two OSI Transport
users. An OSI Transport connection has three phases:
o Setting up the connection -- an OSI Transport user (the
initiating user) on one end system (the initiating host) sends a
connection request TPDU to another OSI Transport user (the
responding user) on a second end system (the responding host).
When a successful connection is made, data transfer can take
place in either direction.
o Using the connection to transfer data through -- OSI Transport
connections support two kinds of data transfer:
- Normal data transfer --- for usual message exchange or
- Expedited data transfer --- bypasses any blockage
due to the flow control applied to normal data; only for
sending small amounts of data; has its own type of TPDU
and transmission rules.
o Releasing the connection -- either transport user can release the
OSI transport connection by sending a disconnect TPDU.
3 – Network Services
The following table shows the relationship between the transport
protocols and the network services.
Table 1-1 Transport Protocols and Network Services
_______________________________________________________________________
Class 4 Class 4 Class 2 Class 0 CLTS RFC RFC
(COTS) (COTS) (COTS) (COTS) over 1006 1859
Port over over over over CLNS
Att- CLNS CONS CONS CONS (Tru64
ributes UNIX)
_______________________________________________________________________
Acknow- * *
ledgement
delay time
Checksums * *
Client * * * * * *
CONS * * *
template
CR timeout * * * *
Direction * * * * * *
ER timeout * * * *
Expedited * * * *
data
Extended * * *
format
Inactivity * *
time
Initial * *
retransmit
time
Keepalive * *
time
Local DTE
address * * *
Local * *
RFC1006 IP
address
Local nsap * * * * *
Local * * * * * *
Reference
Local * * * * * * *
transport
selector
Maximum nsdu * * * * *
size
Name * * * * * * *
Negotiable * * * *
classes (Tru64 UNIX)
Negotiated * * * * * *
tpdu size
Network port* * * *
Network * * * * * * *
service
Protocol * * * * * *
class
Remote DTE * * *
address
Remote * * * *
identifier
Remote nsap * * * *
Remote
RFC1006 * *
port
number
Remote * *
RFC1006
IP address
Remote * * * * * *
reference
Remote * * * * * *
transport
selector
Request ac- * *
knowledgment
Retransmit * *
threshold
Roundtrip * *
delay
estimate
Type * * * * * * *
UID * * * * * * *
Use clns *
error
reports
Template Attributes
Acknow- * *
ledgment
delay time
Checksums * *
Classes * * * *
CONS * * *
template
CR timeout * * * *
ER timeout * * * *
Expedited * * *
data
Inbound * * * * * * *
Initial * *
retransmit
time
Keepalive * *
time
Local nsap * * * * *
Maximum nsdu * * *
size
Name * * * * *
Network * * * * *
service
Retransmit * *
threshold
RFC1006 * *
port number
Security * * * *
Use clns *
error
reports
4 – Subentities
The entity hierarchy for the OSI Transport module is:
_Application (OpenVMS)
|
Node___OSI_Transport___|_Local_NSAP______________Remote_NSAP
|
|_Port
|
|_Template
The OSI TRANSPORT entity is the top-level entity in the hierarchy
of entities belonging to the OSI Transport module.
An OSI TRANSPORT APPLICATION entity stores information about an
end user that is activated for receipt of an incoming connection
request when the request contains that end user's name in its
Destination Name field. The application-name refers to the
application managed by this command.
An OSI TRANSPORT LOCAL NSAP entity is automatically created for
each NSAP address used by the osi transport entity. Local NSAPs
are used primarily to group together remote NSAPs (see the OSI
transport local NSAP remote NSAP entity). The nsap-address refers
to the local NSAP managed by this command.
An OSI TRANSPORT LOCAL NSAP REMOTE NSAP entity maintains
the transport counters and generates events resulting from
interactions between its superior local NSAP and a remote
transport service. The nsap-address refers to the remote NSAP
managed by this command.
An OSI TRANSPORT PORT entity represents one end of a transport
connection and maintains status information about that
connection. Although the connectionless transport protocol
does not create transport connections, ports are still used to
maintain status information.
On Tru64 UNIX, a port can also represent a listener, which is
a passive endpoint awaiting connect requests from the remote
transport service provider. Normally, ports exist only when
OSI transport is enabled. However, the port that represents the
session control listener (local transport selector 'DEC'0'H) is
a special case. This port can exist even when OSI transport is
disabled.
The port attributes type, and for Tru64 UNIX direction, can be
used to distinguish the various uses of ports. The port-name
refers to the name of the port managed by this command.
An OSI TRANSPORT TEMPLATE entity provides a collection of
characteristics that supply default values for certain parameters
that influence the operation of a port on a transport connection.
One template, with the reserved identifier default, is
automatically created when the osi transport entity is created.
This template is used by default when a user does not specify
a template identifier in a call to establish a connection.
The default template is automatically deleted when the osi
transport entity is deleted. Similarly, the initial values of
the attributes in a template are the same as the current values
in the default template. The template-name refers to the template
managed by this command.
For Tru64 UNIX, the only attributes that apply to CLTS are
checksum, network service, and local nsap.