top - download
⟦fc17c1c5e⟧ Wang Wps File
Length: 8651 (0x21cb)
Types: Wang Wps File
Notes: Spelunked
Names: »~ORPHAN54.00«
Derivation
└─⟦740f46985⟧ Bits:30006253 8" Wang WCS floppy, CR 0097K
└─ ⟦this⟧ »~ORPHAN54.00«
WangText
5…08…5…09…5…00…4…08…4…0a…4…0b…4 3…09…3…0c…3…0f…3…02…3
3…06…3…07…2…0d…2…07…1…0f…1…01…1…05…0…0d…0
/…0a…/…0d……86…1
…02… …02…
…02… …02…
CHAPTER
6
Page
#
DOCUMENT
III
TECHNICAL
PROPOSAL
Apr.
29, 1982
6.5 N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The ACON software is built using layered concepts.
The NSS constitutes the lowest three environments:
CUE, DTrE and DLE. Each "horizontal" layer consist
of software schedulable tasks which provide similar
services. The packaging of these tasks is done by "vertical"
partitioning such that a group of tasks providing the
total NSS capability can be included in in functional
CR80-processes.
In the fllowing description, we concentrate on the
functions of the NSS without regard to its packaging.
Figure 6.5-1 illustrates this environment.
6.5.1 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲U̲s̲e̲r̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲ ̲(̲C̲U̲E̲)̲
This environment is primarily concerned with providing
an ordrly data exchange between two entities in the
higher level software. This orderly exchange is provided
by establishing session-conversations.
This environment is not concerned with the idiosynchrocies
of the individual user. The Network InterfaceEnvironment
handles these by providing emulator functions or with
implementation of virtual terminals.
The session-conversations are built on the services
provided by the Data Transmission Environment.
Figure III 6.5-1 …01…Communication Environment
6.5.1.1 S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
6.5.1.1.1. S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲E̲s̲t̲a̲b̲l̲i̲s̲h̲m̲e̲n̲t̲
The purpose of the session-conversation establishment
phase is to tie two Session ServiceUsers (SSU) into
a cooperative relationship. To do this the CUE includes
the means to:
- request a session-conversation to another SSU
- receive a request for session-conversation from
another SSU, which it can accept, reject or negotiate
- b notified of the session-conversation establishment
or the rejection of the request
- enable the two SSUs cooperatively to determine
the values of the session-conversation parameters.
These parameters determine:
- type of service (stream or atagram)
- grade of service (reliability, priority etc.)
- throughput (blocksize, degree of flow control)
6.5.1.1.2 S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
This phase of the interaction serves for a controlled
exchange of data during the lifetimeof the conversation.
Local flow control is provided by CUE so as not to
overload the transport network. This is done by limiting
the size of the outbound queue for each conversation.
When CUE detects that the queue length for a particular
converstion exceeds a predetermined number, it indicates
this to the Session Service User. The latter is expected
to limit the generated output if the ordely exchange
is to be maintained.
Other services for recovering from a possible failures
are providd on request.…86…1 …02… …02… …02… …02…
6.5.1.1.3 S̲e̲s̲s̲i̲o̲n̲-̲C̲o̲n̲v̲e̲r̲s̲a̲t̲i̲o̲n̲ ̲T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲
This allows the SSU to terminate the conversation without
loss of data. Either SSU may at any time request the
forced termination of th conversation, in which case
data may be lost.
The CUE, optionally, gatheres charging data which is
forwarded to the NSE on termination of a conversation.
6.5.2 D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲E̲n̲v̲i̲r̲o̲n̲m̲e̲n̲t̲ ̲
This environment provides standard interfaces andservices
which form the basic transport facilities in the ACDN.
The Transport Service Users (TSU) get access to this
facilities by acquiring a Transport Access Port (TAP).
The request for a TAP is processed by the Network Services
Environment. One a TSU has acquired a TAP, it can communicate
with other TSUs and vice versa.
Chapter 6.5.2.2.1 expands on the addressing aspects.
Notice that TSUs may be identified either e̲x̲p̲l̲i̲c̲i̲t̲l̲y̲
or i̲m̲p̲l̲i̲c̲i̲t̲l̲y̲ in the addressing structure. When a C-PORT-NO
i used the TSU is identified implicitly via the TAP
corresponding to the C-PORT-NO. When the generic name
of the TSU is used, the NSE at the destination is requested
to identify the TSU. If the explicitly named TSU is
known to the destination system(confirmed by directory-lookup),
then it, or an incarnation of it, is activated and
informed of the incoming information. The activated
TSU will then respond to the incoming indication of
a session-conversation by contacting the CUE.
6.5.2.1 D̲T̲r̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲
The underlining mechanism by which DTrE communicates
is based on datagram technology.
The higher level software is provided with basically
two types of services. T̲h̲e̲ ̲D̲a̲t̲a̲g̲r̲a̲m̲ ̲S̲e̲r̲v̲i̲c̲e̲ (DGS) is
based directly on the underlining datagramtechnology.
This provides a vechicle to base higher level transaction
oriented services.…86…1 …02… …02… …02… …02…
The V̲i̲r̲t̲u̲a̲l̲ ̲T̲r̲a̲n̲s̲p̲o̲r̲t̲ ̲C̲o̲n̲n̲e̲c̲t̲i̲o̲n̲ ̲(̲V̲T̲C̲)̲ service provides
enhanced stream oriented services again based on the
underlining datagram technology. This provides a means
for trasportingbulk data.
Figure III 6.5.2.1-1 illustrates this.
Figure III 6.5.2.1-1…01…DTrE Structure
6.5.2.2 D̲a̲t̲a̲g̲r̲a̲m̲ ̲S̲e̲r̲v̲i̲c̲e̲s̲ ̲(̲D̲G̲S̲)̲
This service provides a one-to-one mapping on the underlining
datagram implementation of the DTrE.
The information entities exchanged within thenetwork
are d̲a̲t̲a̲g̲r̲a̲m̲s̲. A datagram is a data structure of a
defined maximum size consisting of a Datagram Header
(DH) and Datagram Text (DT). The datagram header contains
the source and destination addresses of the datagram.
The datagram text is theactual data to be transported
through the network. This textual data is transparent
to the datagram service.
The DGS only accepts data in the form of Datagram Texts.
Because of the limited size of the datagrams, the service
user is expected to spit longer data structures into
a number of DTs. For ACDN a maximum size of 512 bytes
for a DT is suggested. This maximum size will enable
the ACDN to transport the majority of its transactions
in a single datagram.
The DGS provides a fast but notcompletely reliable
service. If for some reason the datagram cannot be
delivered the transport network will destroy them.
An option is provided whereby the user may request
the delivery confirmation of the datagram. In this
case, the destination DTE will automatically "echo"
the datagram back to the user - the Datagram Text of
the echo-datagram is shorten to the first ten bytes
of the original datagram. It is expected that the source-user
will have enough information within the echo-datagramtext
to recognize the returned echo-datagram as being the
delivery confirmation on a particular datagram sent
previously.
DGS will provide eight priority levels. The designated
priority is noted in the packet header to ensure that
all transit nods will respect the priority level of
the datagram. The priority assigned to a datagram affects
the order in which it is transmitted and also the order
in which it is processed in the individual nodes. However,
the algorithms employed ensure that th low priorty
traffic does not get completely blocked.
DGS provides a test mode services. When in this mode,
all datagarams are marked with a user provided mode-indicator.
The interpretation and special processing is in the
users domain.…86…1 …02… …02… …02… …02…
6.5.2.2.1 A̲d̲d̲r̲e̲s̲s̲i̲n̲g̲ ̲S̲t̲r̲u̲c̲t̲u̲r̲e̲
The transport network of CRNET provides a number of
Transport Access Ports (TAP) through which the network
users can communicate with one another. he addressing
form reflects the heirarchical structure of the topology.
Figure III 6.5.2.2.1-1 illustrate the various address
formats used.
1) C̲C̲-̲f̲o̲r̲m̲a̲t̲: This format is the normal address format
used to identify another C-NET user who is knownto
be attached to a specific TAP.
2) C̲N̲-̲f̲o̲r̲m̲a̲t̲: This is an optional address format used
by a C-NET user to identify another C-NET user, who
is known by a generic name but his specific address
(TAP) is unknown to the source user. The format does
nt limit the size of this generic name - however, it
is not expected to be greater than 8 bytes.
3) X̲-̲f̲o̲r̲m̲a̲t̲: This is the normal format used by a C-NET
user to identify a X-NET user. This format is similar
to the CC-format, but has less addressing
