top - download
⟦1adb8ad65⟧ Wang Wps File
Length: 92949 (0x16b15)
Types: Wang Wps File
Notes: IDCN - EL-BIT Vol. II
Names: »4305A «
Derivation
└─⟦414beabd1⟧ Bits:30006027 8" Wang WCS floppy, CR 0394A
└─ ⟦this⟧ »4305A «
WangText
…00……00……00…D…0a…D…0b……00……00…D…0c…D…06…C…02…B…09…B…0c…B…0d…B…05…A…0e…A…06…A…07…@…0f…@…06…?…0e…?…05…>…0d…>…02…=…09…=…02…<…0b…<
<…05…<…06…<…07…;…08…;…0f…:…08…:…0c…:…0d…:
9…09…9…0e…9
8…86…1 …02… …02… …02… …02…
IDCN - VOLUME II SYS/83-11-18
TECHNICAL PROPOSAL
Page
3 SYSTEMS DESCRIPTION ..........................
3.1 SYSTEM OVERVIEW ..........................
3.1.1 IDCN MEDE Functions ..................
3.1.2 Message Routing ......................
3.1.3 System Supervision, Control and
Maintenance ..........................
3.2 MESSAGE ENTRY AND DISTRIBUTION EQUIPMENT
(MEDE) ...................................
3.2.1 User Terminal Functions .............
3.2.2 Control Functions ....................
3.3 NETWORK ..................................
3.3.1 Network Elements .....................
3.3.2 Topology .............................
3.3.3 Nodal Message Switching ..............
3.3.4 Nodal Switch Subsystem ...............
3.3.4.1 Transmission Between Nodes .......
3.3.4.2 Multiaddressing ..................
3.3.4.3 Flow Control .....................
3.3.5 Error Control ........................
3.3.6 Statistics ...........................
3.3.7 Network Control ......................
3.4 SCC .....................................
3.4.1 General Characteristics .............
3.4.1.1 Modes of operation ..............
3.4.2 Active SCC ..........................
3.4.2.1 Network Control .................
3.4.2.1.1 Message Routing Control .....
3.4.2.1.2 Address Number tables .......
3.4.2.1.3 AIG Tables ..................
3.4.2.1.4 Security Profile Control ....
3.4.2.1.5 Threshold setting
(Parameter Control) ..........
3.4.2.2 Network Supervision .............
3.4.2.2.1 TV-Monitor ...................
3.4.2.2.2 Reports .....................
3.4.2.2.3 Node/Trunk Supervision ......
3.4.2.2.4 MEDE Supervision ............
3.4.2.3 Local Supervision/Control .......
3.4.2.3.2 Local SCC Hardware Supervision
3.4.2.4 Statistics collection and
generation ......................
3.4.2.4.1 Logging .....................
3.4.2.4.2 Statistics ..................
3.4.2.4.2.1 Network Statistics ......
3.4.2.4.2.2 MEDE Statistics .........
3.4.2.4.2.3 Security Statistics .....
3.4.2.4.2.4 Maintenance Statistics ..
3.4.2.5 Remote Maintenance Support ......
3.4.2.6 Standard Terminal Functions ......
3.4.3 Standby SCC .........................
3.4.4 Off-Line SCC ........................
3.5 SOFTWARE .................................
3.5.1 XAMOS Operating System ...............
3.5.2 Extensions ...........................
3.5.2.1 Memory Management ................
3.5.2.2 Message Transition Control .......
3.5.2.3 Queue Access Management ..........
3.5.2.4 Shared Memory Access .............
3.5.2.5 Switchover and Recovery ..........
3.5.3 On Line Diagnostic ...................
3.5.4 Node/Mede Application Software .......
3.5.5 SCC Software .........................
3.5.6 Off-Line Diagnostics Programs ........
3.6 EXPANDABILITY ..............................
3.7 SOFTWARE MODIFICATIONS .....................
3.7.1 Software Modifications Overview ........
3.7.2 Modifications to Operating System,
Device Drivers and Extensions ..........
3.7.3 Modifications to the Nodal Supervisory
Software ...............................
3.7.4 Modifications to Message Distribution
and Output Software ....................
3.7.5 Modifications to Storage and Retrieval
Software ...............................
3.7.6 Modifications to Message Journal and
Statistics Software ....................
3.7.7 Modifications to Message Service
Software ...............................
3.7.8 Modifications to System Control
Center Software ........................
3.7.9 Modifications to the Nodal Switch
Software ...............................
3.7.10 Concentrator Interface Software ......
3.7.11 End-to-End Control Monitor ..........
3̲ ̲ ̲S̲Y̲S̲T̲E̲M̲S̲ ̲D̲E̲S̲C̲R̲I̲P̲T̲I̲O̲N̲
The objective of Israeli Data Communication Network
(IDCN) is to provide a fully integrated message entry/distribution
System and Communications Network for the Army, the
Navy, and the Air Force of Israel. IDCN provides rapid
and reliable communication of adequate capacity, incorporating
a high degree of security and survivability. Additionally,
IDCN is expandable - in capacity and function - so
that new systems and future developments do not render
IDCN obsolete for many years to come.
3.1 S̲Y̲S̲T̲E̲M̲ ̲O̲V̲E̲R̲V̲I̲E̲W̲
The IDCN network consists of 4 nodal switching centers,
interconnected by internodal trunk lines, operated
at 9.6 Kbaud, plus 1 System Control Center (SCC) connected
to one of the switching Centers.
The nodal switching centres are configured with three
functional entities:
the NODE - providing access to IDCN for data terminals,
interfacing MEDEs, and performing network-oriented
functions
the MEDE - Message Entry and Distribution Equipment,
providing access to IDCN for communications
centers and performing terminal-oriented
functions related to message traffic.
the SCC - System Control Center, providing global
network supervision and control
These IDCN system elements may be co-located and physically
integrated.
Initially, IDCN is structured as an four Node grid
network whose topology, shown in figure 3-1, is described
in the sections to follow. The system can be expanded
to a network containing 32 Nodes plus 2 SCCs for global
network control.
M̲e̲s̲s̲a̲g̲e̲ ̲U̲s̲e̲r̲s̲
Message users are served through a number of terminals
and concentrators. Many message terminals - assigned
to the concentrators - are given access to IDCN through
dedicated circuits terminated in the NODE/MEDE processors.
Single message terminals are served through a dedicated
line directly connected to the NODE/MEDE processor.
it shall be noted that this proposal does not include
the necessary terminals, concentrators, cryptoes, modems,
and lines, but the system will provide the necessary
ports to support the requested configuration.
34 ports to concentrators (9.6 kbaud)
48 ports to teleprinters (max. 300 baud)
4 ports to supervisor terminals
Figure 3-1…01…IDCN NODAL NETWORK AND TERMINALS
N̲e̲t̲w̲o̲r̲k̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
The entire IDCN network is monitored and supervised
by one System Control Center, SCC. This control is
of global nature. Local control of the MEDE and associated
terminals is provided by each individual NODE/MEDE.
M̲e̲s̲s̲a̲g̲e̲ ̲C̲a̲t̲e̲g̲o̲r̲i̲e̲s̲,̲ ̲C̲o̲d̲e̲s̲ ̲a̲n̲d̲ ̲F̲o̲r̲m̲a̲t̲s̲
Two categories of traffic are handled:
o NARRATIVE MESSAGES with precedence and multiple
addressees in standard message format (SMF) with
the essential elements of the ACP-127 format.
o SERVICE MESSAGES using an abbreviated format.
For message traffic, IDCN will accept either 5-level
(Baudot/ITA-2) or 7-level (ASCII/ITA-5) codes; internally,
message processing and storage will be in ASCII code.
Narrative messages are modified before transmission
by addition of an envelope containing IDCN internodal
routing and local address information, and the original
messages are restored at the destination terminals.
Internal to the IDCN network all traffic is handled
as packets compatible with HDLC protocol.
3.1.1 I̲D̲C̲N̲ ̲M̲E̲D̲E̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
IDCN MEDE is a secure message processing system installed
at various sites providing assistance with the distribution
of incoming messages and the transmission of outgoing
messages. Outgoing messages may be user generated using
an interactive on-line capability, or prepared off-line.
Figure 3.1.1-1 shows an overview of the system.
IDCN MEDE automatically allocates appropriate distributions
within the site to incoming messages. IDCN enables
staff to draft, co-ordinate, and release outgoing messages
at IDCN terminals. It automatically routes these messages
to the network and provides for local distribution.
The staff of the MEDE are only involved in cases of
error or difficulty with a message.
The users of IDCN can retrieve messages from on-line
disk files. IDCN also provides facilities for external
network communication lines control, regular accounting
of all message traffic received or transmitted, the
maintenance of tables of addresses, routes, distribution
lists, and control of all of its own resources and
users.
The assistance provided by IDCN includes the generation
and syntax-validation of certain formatted texts of
outgoing messages.
Message preparation is interactive with prompts from
the MEDE; format errors is detected, addressees validated,
and errors annotated. Messages are prepared in simplified
message format and clear text. After validation, the
message will be available for further editing and coordination
before release to destination.
Released messages is analyzed for routing. Messages
is queued by precedence (Flash, Rush, Immediate, Priority,
Quick and Routine) for network routing and for distribution
to local addressees.
IDCN provides a number of security procedures that
help to insure that messages are only seen by appropriately
authorized staff, and that security violation attempts
are detected and reported.
Users, within a given IDCN site may also communicate
with each other by using a coordination facility.
Operation of the MEDE, including switchover and recovery,
is automatic requiring minimum operator intervention.
Data for operational status and off-line statistical
processing is periodically forwarded to the System
Control Center.
The MEDE will respond to operator and supervisory commands
necessary to control on-line functions. Commands are
simply formatted easily learned by recall of the associated
action.
In addition to the editing and retrieval commands,
supervisory functions relate to reports, status, control,
test, and special handling. Typical commands include
add/delete addressees, and special handling.
Special handling comprises three categories of SPECAT
messages and two high classifications. Software checks
ensure that only authorized viewers are allowed to
examine the message content.
The IDCN system incorporates facilities to insure its
continued operation in spite of all but the most serious
of errors. These facilities include redundant hardware
and controlling software, as well as hardware and software
for operator control, communications control, and system
monitoring and control.
The IDCN system functions encompass the IDCN interfaces
(physical and man-machine), message analysis and synthesis,
message distribution and related support functions.
1. A̲c̲c̲e̲s̲s̲ ̲c̲o̲n̲t̲r̲o̲l̲ - Access control functions govern
the sign-on and sign-off of users and supervisors
and the maintenance of user and terminal profiles.
These profiles are used to control access to data
and to control which functions are permitted to
a user.
2. M̲e̲s̲s̲a̲g̲e̲ ̲p̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ - These functions enable VDU/TP
users to create and address messages to be transmitted
via the networks, validate the message information
and report errors;
3. M̲e̲s̲s̲a̲g̲e̲ ̲c̲o̲o̲r̲d̲i̲n̲a̲t̲i̲o̲n̲ - This function gives the
user the option to distribute locally to other
users of the system a message he has prepared.
This option can be invoked before the system is
requested to transmit the message.
4. M̲e̲s̲s̲a̲g̲e̲ ̲r̲e̲l̲e̲a̲s̲e̲ - A user who is permitted to release
an outgoing message for transmission may refuse,
postpone, or permit the transmission of the message.
5. R̲e̲t̲r̲i̲e̲v̲a̲l̲ ̲a̲n̲d̲ ̲a̲s̲s̲o̲c̲i̲a̲t̲e̲d̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲ - The system
automatically locates messages for user retrieval
using a variety of retrieval parameters. Outgoing
and incoming messages are stored at the long term
storage at the MEDE. Special handling message are
deleted from temporary storage after delivery.
Message are retrieved by message identification,
SIC codes, and date/time identification.
Figure 3.1.1-1
IDCN System Overview
6. I̲n̲q̲u̲i̲r̲i̲e̲s̲ - In response to user inquiries, the
system provides various status reports, e.g. message
delivery status, message status and release status.
7. G̲e̲n̲e̲r̲a̲l̲ ̲t̲e̲r̲m̲i̲n̲a̲l̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲ - The system monitors
queues of messages, alarm/alerts, reports, etc.,
at a terminal and displays the number of items
in a caption area of the VDU screen. Users can
request the next item which is presented according
to the FIFO (first in first out) queue on the selected
precedence level. Users are provided with general
control facilities for manipulating data on the
screen, for printing, and for cancelling and suspending
transactions at the terminal.
8. S̲y̲s̲t̲e̲m̲ ̲c̲o̲n̲t̲r̲o̲l̲ - Various transaction options are
available to the supervisor to manipulate user
and terminal profiles, channel data, routing address
and distribution tables; and to open and close
channels, block and unblock terminals etc.
9. S̲y̲s̲t̲e̲m̲ ̲m̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ - Details of errors and warnings,
reports on significant system control actions,
transaction logs, and statistical reports are output
on printers.
10. M̲S̲O̲ - The Message Service Operators use a group
of VDU's that share incoming and outgoing queues.
Items, which the system is unable to handle automatically,
are placed into these queues. These items have
problems such as garbles and errors on incoming
information or routing and output difficulties
on outgoing information. The operators have facilities
for the editing, rerouting, etc. of such items.
11. M̲D̲C̲O̲ - The Message Distribution and Control operators
use a group of VDU's that share a queue. Messages
for which the system is unable to derive a distribution
list are placed into this queue. Items which the
system is unable to deliver are also placed into
this queue. The operators modify the distribution
lists or the addresses to enable delivery.
12. I̲n̲c̲o̲m̲i̲n̲g̲ ̲t̲r̲a̲f̲f̲i̲c̲ - Incoming traffic is analyzed
according to source. The analysis decides the type
of information and subsequent message processing.
13. O̲u̲t̲g̲o̲i̲n̲g̲ ̲t̲r̲a̲f̲f̲i̲c̲ - Outgoing messages are routed
via the network according to their addresses. Other
items are put into the appropriate format and output.
14. D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲ - The system distributes messages
for terminal delivery.
15. T̲i̲m̲e̲-̲o̲u̲t̲ - The system also provides functions for
automatic generation of time-out conditions. (e.g.
channel checks and queuing of Flash precedence
messages).
3.1.2 M̲e̲s̲s̲a̲g̲e̲ ̲R̲o̲u̲t̲i̲n̲g̲
Message traffic is relayed from the originating MEDEs
through intermediate IDCN Nodes to the destination
MEDEs. The associated message routing and data line
switching functions are allocated to the Node processors.
Messages received by the Node are routed to other Nodes
or delivered to the locally connected MEDE on the basis
of routing indicators and precedence contained in a
special header. Each Node is interconnected to adjacent
Nodes through at least 3 independent trunks. The optimum
trunk route to the final destination Node is based
upon shortest route (minimum hop) and network connectivity.
A routing algorithm is used which allows the Node to
be independent of SCC control. SCC will be informed
of all changes in the network and calculate routing
tables for optimization of the network traffic. The
SCC routing algorithm uses weighted delay factors for
the individual trunks. These weighting factors will
be derived from the traffic Q-reports and be used to
calculate message routing tables which are down-loaded
to the Nodes.
The routing tables contain three alternative routes
per destination and the Nodes select the proper routes
from the tables based on trunk queue lengths. If no
SCCs are inoperative, the Node/MEDE supervisors can
manually update the tables.
As back-up for leased trunks, each NODE can have access
to a dial-up switched PTT Data network. An abbreviated
2-digit dialing sequence will then be used to establish
a back-up connection.
3.1.3 S̲y̲s̲t̲e̲m̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲,̲ ̲C̲o̲n̲t̲r̲o̲l̲,̲ ̲a̲n̲d̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲
Centralized global supervision and control of the overall
IDCN network maintains network efficiency and regulates
or restores service in case of congestion, outages,
or failures. Continuous network status is monitored
and displayed at System Control Centers. One SCC is
provided in a nondualized configuration. Two SCCs can
be provided, where both SSCs may be on-line with one
exercising network control and the other on standby
monitoring the network; or, the second may be off-line
and dedicated to maintenance.
The SCC exercises control of the network by use of
a number of procedures, e.g.:
o threshold setting for trunk queue lengths
o threshold setting for message retransmission rate
o control of SCC switchover (when 2 SSCs are provided)
o change of tables
o request of diagnostic results from Node/MEDEs
o open/close trunks
o Setting of security profiles for MEDE supervisors.
Control messages from the Node/MEDEs concerning traffic
queues, trunk and Node status, retransmission rate
and, equipment availability, etc. are transmitted to
the SCCs; from this, statistics are gathered, alarm
conditions noted, and reports presented to allow timely
network decisions by supervisory personnel. A log of
control messages and SCC action provides an audit trail
to trace all network control actions.
Downline loading of routing, security and address tables
from the SCC to the network permits selective re-routing
of message traffic, change of routing plan, reconfiguration
of the network, and change of security tables.
The current operational status of the nodal network
is displayed on a color TV, dynamically updated by
reports and alarms from the network.
The open/closed status of each internodal trunk and
active PTT back-up channels as well as configuration
and availability of each Node/MEDE and SCC are displayed.
Statistics are gathered by the SCC from control messages,
periodic reports and traffic received from the network.
Message flow, trunk usage, queuing delays, outages,
equipment up-time, and other statistics is available
for off-line statistical analysis, reports and network
planning. A summary message traffic report is automatically
generated and distributed every 24 hours to the Node/MEDEs.
3.2 M̲E̲S̲S̲A̲G̲E̲ ̲E̲N̲T̲R̲Y̲ ̲A̲N̲D̲ ̲D̲I̲S̲T̲R̲I̲B̲U̲T̲I̲O̲N̲ ̲E̲Q̲U̲I̲P̲M̲E̲N̲T̲ ̲(̲M̲E̲D̲E̲)̲
At each of the network NODEs a Message Entry and Distribution
Equipment (MEDE) is located. It is logically (from
a software point of view) connected to the NODE but
is physically embedded within the same H/W which supports
the NODE.
The MEDE serves the message users who can get access
to the system via terminals either directly connected
to the MEDE or connected to a concentrator which is
connected to the MEDE. Additionally the MEDE will serve
up to four supervisor positions.
The MEDE is capable of supporting the following terminals:
VDU-ASCII
Teleprinters
Receive Only Printers (connected to VDU)
Paper Tape Reader/Punch
Concentrator - connected via an X25 protocol
Message traffic rates can vary from low speed 50, 100,
and 300 baud, to medium speed 600, 1200, and 2400 baud.
Concentrators can be connected on 9600 baud lines.
Each operator has a set of the procedures available
at his position. The operational procedures available
at a terminal is a function of the responsibilities
assigned to the position. The Supervisor has use of
all operational procedures. The Supervisor-Assistant
has use of all procedures except those associated with
highly classified messages, special category (SPECAT)
message handling, and security profile modification.
Terminal operators have use of only standard terminal
procedures and procedures for message handling.
3.2.1 U̲s̲e̲r̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
All operator positions associated with the MEDE have
use of the Log on/Log off procedures, the message handling
procedures, and the standard terminal procedures.
The Log on/Log off procedures must be used to connect
and disconnect terminals. Log on permits a terminal
to be set for receive and transmit or for receive only.
Log off disconnects the terminal from all service or
sets the terminal for receive only.
Basic Message Handling consists of a set of procedures
necessary to message generation. Message generation
consists of Preparation, Coordination, Copy, Release,
and Deletion procedures. Additional message procedures
are provided for Message Retrieval, Message Readdressing
and Message Distribution. The Message Status procedure
is used to obtain message status for a terminal.
Standard Terminal procedures are used during normal
terminal use. Queue related procedures are used to
display the queue index, to print the queue index or
to display the first entry in the queue.
Transactions can be cancelled via the Cancel transaction
procedure. The Print Screen procedure may be used to
print the contents of the display for that terminal.
Message Preparation assistance is provided to user
terminals. At a terminal, the user can generate a message
header while being prompted on a line by line prompting
basis.
The proposed message header is subjected to message
header analysis. Error and/or omissions in the message
header is noted to the user.
All VDUs and Teleprinters associated with the MEDE
have use of message Entry procedures, Message Distribution,
Message Retrieval, and standard terminal functions.
M̲e̲s̲s̲a̲g̲e̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The functions which are available from a message handling
terminal are described in the following sections.
- Message terminal functions are described in functional
descriptions and operational procedures.
- The operational procedures describe the Man-Machine
interface.
- The Computer to Terminal column describes the computer
output.
- The Terminal to Computer column describes the valid
operator response.
- The ERR column is marked with x whenever operator
response shall be verified immediately by the computer.
These cases of illegal input causes an error code
to the operator in the following line.
- The x marking in the error column covers all command
used as answer to prompts.
- Operator input, which cannot be verified immediately
will in error cases lead to notification as specified
in the procedure descriptions.
- The interactive terminals used are of two types,
VDU and Teleprinter.
- Message Handling Terminals may be of either type,
and logged on in TXRX mode or RX mode.
The non interactive terminal elements are:
- Associated printer
- Tape punch device
- Tape reader device
The associated printer must be associated to a logged
on device in order to be operative. The paper tape
reader shall be fixed allocated to one VDU, and work
as a slave to this, at the level of log on/log off.
The tape punch device is identified to the system by
a term id with associated ANOS (Address Numbers).
M̲e̲s̲s̲a̲g̲e̲ ̲E̲n̲t̲r̲y̲
Message Entry function supports message preparation
and relase. Messages entered at a terminal are identified
by IDCN by means of the terminal ID and a 3 digit sequence
number 001-999. When 999 is reached, the next prepared
message will have the sequence number 001. Messages
entered but not yet released or deleted are considered
as being in preparation. A message shall stay in preparation
until released or deleted. This applies whether the
terminal is logged on or off. A maximum of 10 messages
can be in preparation per terminal. The storage for
all 10 messages in preparation is limited to 10.000
bytes.
P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲
In the following the preparation procedure is described
in detail to show the customer an example of the procedures.
All other procedures are not described to that extent
at this point in time.
Message header generation is done by the MEDE computer
in prompting the terminal operator as described in
the preparation procedure. The computer analyses the
operator answers on a line-by-line basis. Error and/or
omissions are noted to the operator.
Each terminal has a nominal "FROM" address to be used
with the "FM" prompt. The "To" address may be an ANO
and/or an AIG (Address Indicator Group). The "INFO"
addres may be an ANO. The "TO" and "INFO" address may
be an ANO + plain text. The plain text can only cover
the remainder of the line and will overwrite the normal
text associated with the ANO.
The plain text is always transmitted along with the
message. Plain texts are never processed by IDCN but
are only printed on the receiving terminal in the same
format as it was entered.
The "TO and INFO" address may be an -ANO. This type
of addressee shall not receive the message by automatic
distribution, but the related plain address shall be
represented on the message print out.
In connection with the "TO AIG" addressee it is possible
to specify, by the "XMT" address, exclusions to the
ANOs in the AIG, which shall not receive the message.
The XMT ANOs input shall at the message print out be
represented as plain text adressee.
The Clear text input by the operator on prompt "INT
DIST" is printed on the message, but not processed
by IDCN.
Preparation of the text part of a message is done by
the operator as described in the message preparations
procedure. The computer stores the text.
The operator may use one text mask in the preparation
of a message. When a text mask is used it is displayed
on the VDU immediately following the preparation of
the message header.
Each text mask can max. occupy 300 characters on the
disk storage device and is formatted to be max. one
screen image. A pool of masks are available to all
terminals connected to the MEDE. The maximum pool size
cannot exceed 60000 bytes or disc storage. The text
mask will be displayed on a VDU immediately following
the preparation of the message header.
The text mask facility at the tele printer is supported
so that each line of the text mask is printed on the
teleprinter whereupon the operator will be able to
continue that line by adding one or more characters
at the end of the line or just accepting the line as
it is by giving a (CR). The MEDE computer will accept
the whole line as if it had been entered by the operator.
Text masks are handled at the VDUs in the page mode.
The text mask will be transmitted as a full screen
image just before entering page mode.
The SEND PAGE function is employed to transmit to the
computer the text mask plus the character strings entered
by the operator.
During text entry mode at teleprinters, line-by-line
mode is used. This means that the operator enters one
line at a time before acceptance by the computer.
In order to leave the text entry mode at teleprinters
the operator must enter CROSS ̲ N (CR) at start of a
line which flags end of text.
Text entry at VDU is performed in page mode. After
finishing message header preparation the computer will
put the VDU in page mode. In this mode the operator
can compose a whole screen image in free format. This
allows the operator to use the editing facilities of
the VDU.
In page mode the whole contents of the screen will
be transmitted to the MEDE computers for storage when
the operator activates the SEND PAGE function of the
VDU. In order to have a VDU look teletype compatible,
the screen data to be transmitted starts in the upper
left corner of the screen and ends transmission at
the position of the cursor. The transmission is completed
when the cursor returns to home position. The screen,
or part of the screen, can now be transmitted again,
by moving the cursor to wanted position, and activate
the SEND PAGE key.
In order to continue the preparation at a VDU, one
of the function keys, NEXT PAGE or END OF MESSAGE shall
be employed.
NEXT PAGE: Clear screen and ready for next page
END OF MESSAGE: Clear screen and terminate text input
Message test, at VDU can optionally be entered in its
entirety from a Paper Tape Reader (PTR) fixed allocated
to the VDU.
Input is accepted from the PTR after the operator has
entered a positive response to TAPE prompt. The prompt
for TAPE shall be issued only on VDUs with a PTR associated.
In the preparation procedure the INFO precedence is
used as action precedence when no action precedence
is given.
In the preparation procedure the slash answer to the
prompt "FM" means the nominal "FROM" address is inserted
and displayed on the input terminal and additionally
transmitted to the receiving terminal where it is printed
along with the message.
P̲r̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲d̲u̲r̲e̲s̲
This procedure is used when entering messages with
interactive communication except for the text part.
The preparation procedure is uniform for all terminal.
The text part is entered in free format or with assistance
of one of the text masks.
Preparation can be performed in 4 different modes:
- Preparation Israeli short Command: PRS
- Preparation English short Command: PES
- Preparation Israeli long Command: PRL
- Preparation English long Command: PEL
In the following S, L represents short, long respectively.
The difference in the English/Israeli procedures is
in CLASS code input, and plain language address output
only.
For addressing the verification of an ANO, AIG is limited
to the existence of this ANO and AIG.
If the prepared messages exceed the max. allowed size
of the message or the preparation storage area then
an error message is given on the terminal and the procedure
is terminated. The part of the message that was successfully
entered, is still kept.
Security check is performed, ie. check if entered classification
is less than current user class, if special category
is requested, if that SH password exists in current
user profile.
In case of security breach the terminal operator is
notified by an error message and is prompted again
for the related item.
The prompt lines "TO", "INFO", "XMT" are repeated until
the response is (CR).
PROCEDURE DESCRIPTION: Preparation example
PROCEDURE DESCRIPTION: Preparation
PROCEDURE DESCRIPTION: Preparation
L̲o̲c̲a̲l̲ ̲D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
Messages entered by the user are validated for message
format errors, invalid classification addresses and/or
improper message precedence. After having been validated,
composed messages are sent to other user stations for
coordination and remarks as required. After editing
and coordination, messages may be sent to a designated
station for release authorization. Released messages
are distributed to local users simultaneously with
the forwarding of the message over the network.
M̲e̲s̲s̲a̲g̲e̲ ̲S̲t̲o̲r̲a̲g̲e̲
IDCN network messages are stored for at least 72 hours.
These messages are stored in simplified message format
and are available for message retransmission. The messages
are also available for review by the supervisor, the
message originator or the message addressee.
Actions related to a particular message are noted in
the message journal for the message. After all actions
for a message have been completed, the journal remains
as a historical record of the message
Message and message journal storage provides the means
to recover not only the original message but also all
pertinent message handling information. Retrieval requests
make reference to the message by the Message Identification,
Date time Group with Subject Indicator Code SIC.
3.2.2 C̲o̲n̲t̲r̲o̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The control functions described in this section pertain
to local functions embedded within the Node/Mede. Global
network control functions are performed by the SCC
and are described in the SCC section.
S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲C̲o̲m̲m̲a̲n̲d̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The Supervisory Command Functions are available to
the MEDE Supervisor and the Supervisor Assistant.
The Supervisor is the master operator at the MEDE.
He shall be responsible for message flow through the
MEDE and he shall control the MEDE and associated COM
CENTERS and terminals. Only the supervisor is allowed
to change security tables.
The Supervisor Assistant has the dual responsibilities
of message terminal operator and Supervisor Assistant.
While acting as a Supervisor Assistant, he shall assist
the Supervisor with the management of message flow
and with the control of the MEDE terminals.
Message Control procedures are used for control of
messages entering and leaving the MEDE. This includes
control of queues for incoming and outgoing traffic
plus the capability to obtain queue status for user
queues and for incoming and outgoing traffic queues.
Distribution procedures provide control over messages
which cannot be automatically delivered. With these
commands, delivery instructions can be entered for
these messages.
The On line table handling procedures are used to modify
the on line tables except for the Security Profile
Table. These commands are used to change existing tables,
to delete existing tables or table entries and to generate
new tables or table entries.
Service Message Procedures are used to generate service
messages for exchange of information between IDCN Supervisors.
Statistics Procedures are used to request statistics.
These procedures request the data for delivery to a
specified queue. Presentation of the data is via a
standard terminal procedure.
The Alert/Alarm response procedures are used to react
to alerts/alarms associated with the MEDE by taking
appropriate corrective action.
The Computer Control procedures provide the capability
for system start/restart, computer switchover, disk
file handling and off-line diagnostic.
S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲B̲r̲e̲a̲k̲d̲o̲w̲n̲
This section contains the description for NODE/MEDE
supervisory functions. These functions are all related
to supervision and control inside a NODE/MEDE area.
The description is split into the following subjects:
- Message Service.
- Reports.
- Control.
- Status.
- On-line table handling.
- Security profile handling.
- Statistics.
All these subjects except security profile handling
are available from all supervisory terminals. The security
profile handling is available from the supervisor terminal
only.
Only one terminal at a time is able to operate on a
given data item.
The common queue information, in AL/DT queues, is displayed
on all terminals.
Figure 3.2.2-1
M̲e̲s̲s̲a̲g̲e̲ ̲S̲e̲r̲v̲i̲c̲e̲
The supervisory message service functions include normal
message terminal functions and some unique functions
described in the following sections.
D̲i̲s̲t̲r̲i̲b̲u̲t̲i̲o̲n̲
Distribution functions are used to handle undeliverable
messages in the DT queue.
The following types of messages are directed to the
DT queue together with reason for distribution:
1. Transit messages with orbit error.
2. Transit messages, where all neighbour trunks are
unavailable.
3. Messages which cannot be delivered to the terminal
associated with a local ANO due to the ANO is unknown,
or no valid term is associated with the ANO.
4. Special handling messages with illegal authentication.
5. Special handling messages in case of 10 min. timeout
on printout.
6a. Special handling messages directed to a terminal
on which the logged on user has no SH password.
6b. When the user answers 'No' to the password prompt.
7. Messages which cannot be delivered because the
logged on user has a low classification.
8. Messages with header errors in the data fields
used for automatic distribution.
9. Undeliverable messages due to print queue excess.
The commands are as follows:
- Enter distribution mode.
This command sets the terminal in mode for distribution.
A number of messages in the DT queue will be displayed
together with the cause for distribution for insertion
of distribution commands.
- Get message distribution.
The command displays the first message in the DT
queue together with the cause for distribution
for insertion of distribution command.
Along with the reasons 4, 5, 6, 7, and 9 the terminal
identification of the destination terminal is displayed
in the distribution procedures. In these cases there
is a queue entry in the DT-queue for each terminal
where the message is underliverable.
P̲r̲i̲n̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲J̲o̲u̲r̲n̲a̲l̲
The message journal is available for print out from
any of the supervisor terminals.
The message journal is queued for print out, inserted
into the LP queue of the requesting terminal, upon
operator request.
P̲r̲i̲n̲t̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲L̲o̲g̲
The message log (HDB index) is available for print
out from any of the supervisor terminals.
The message log is queued for printout, inserted into
the LP queue of the requesting terminal, upon operator
request.
R̲e̲p̲o̲r̲t̲s̲
A̲l̲a̲r̲m̲s̲ ̲a̲t̲ ̲t̲h̲e̲ ̲N̲/̲M̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲o̲r̲
An Alarm (audible alarm + entry in AL queue) is generated
when the following events occur:
A. Trunk failure.
B. Wrong password on Log on/Log off.
C. Wrong password on security interrogation.
D. SH Message Non-delivery.
E. Wrong password on security profile update.
F. The print queue threshold is exceeded.
G. Public Data Net Set-up failure.
H. Public Data Net Close down failure
I. Public Data Net Set-up established
J. Public Data Net close down established
K. Long line detected at term id (xxx)
L. Flash alarm.
M. Deletion of orbiting control message.
R̲e̲p̲o̲r̲t̲ ̲R̲e̲s̲p̲o̲n̲s̲e̲s̲
Reports are displayed on the supervisory terminals
as a result of executing the procedure Display Alarm
queue.
The Alarm text contains the following information when
applicable:
1. Alarm event identification.
2. Terminal Id.
3. Trunk Id.
4. User Id.
5. Print-queue Id.
6. Type and category of deleted control message.
7. Originator and destination of deleted control message.
8. DTG of deleted control message.
T̲e̲r̲m̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲
By the terminal control procedures, the following actions
may be taken:
1. Block Terminal.
The terminal is set in b̲l̲o̲c̲k̲e̲d̲ state. In blocked
state log on is not possible.
2. Unblock Terminal.
Terminal state is changed from b̲l̲o̲c̲k̲e̲d̲ to l̲o̲g̲g̲e̲d̲-̲o̲f̲f̲.̲
M̲e̲s̲s̲a̲g̲e̲ ̲Q̲u̲e̲u̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
Queue control is available for message terminal queues.
The following procedures are available:
1. Reorganize Queue.
This procedure moves a specified queue element
from its present position to the first or last
position within the queue specified.
2. Relocate Queue elements.
The queue elements starting with N in queue A,
to and including the last element in queue A
are appended to queue B.
3. Reroute Terminal Traffic
All messages to terminal A, i.e. present and further
contents of display and print queue, are appended
to the corresponding queues at terminal B.
4. Reestablish terminal traffic
This procedure redirects future terminal traffic
back to the original terminal, i.e. the procedure
cancels the "Reroute terminal traffic" function.
O̲p̲e̲n̲/̲C̲l̲o̲s̲e̲ ̲T̲r̲u̲n̲k̲
The N/M Supervisor has a procedure to Open/Close a
Trunk line without SCC intervention.
Q̲u̲e̲u̲e̲ ̲S̲t̲a̲t̲u̲s̲
It is possible to display, on any supervisory terminal,
the terminal queue status (the VDU top status display
lines) of any terminal at the same Node/MEDE.
This status is displayed as a result of the display
queue status procedure.
O̲n̲-̲l̲i̲n̲e̲ ̲t̲a̲b̲l̲e̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
Handling of on-line tables covers insertion, deletion,
correction and simple look up of table entries in the
following on-line table:
- Address tables:
ANO to terminal reference.
Only temporary local changes are allowed from the Node/Mede.
Permanent changes are only allowed from the SCC.
AIG tables are only updated from the SCC. ANO to Plain
Text Adress tables are only updated from the SCC.
The description is split into procedures and format
and contents descriptions.
The following procedures are avaible:
1 D̲i̲s̲p̲l̲a̲y̲ ̲s̲p̲e̲c̲i̲f̲i̲e̲d̲ ̲o̲n̲-̲l̲i̲n̲e̲ ̲t̲a̲b̲l̲e̲ ̲i̲n̲d̲e̲x̲
Index for the specified table is displayed, covering
necessary information for selection of an entry.
2 D̲i̲s̲p̲l̲a̲y̲ ̲s̲p̲e̲c̲i̲f̲i̲e̲d̲ ̲e̲n̲t̲r̲y̲ ̲i̲n̲ ̲s̲p̲e̲c̲i̲f̲i̲e̲d̲ ̲o̲n̲-̲l̲i̲n̲e̲ ̲
t̲a̲b̲l̲e̲ ̲f̲o̲r̲ ̲r̲e̲p̲l̲a̲c̲e̲m̲e̲n̲t̲
The specified entry in the table is displayed in
a form that enables the supervisor (-assistant)
to interrogate and replace as well as delete corrections
to the table.
L̲o̲c̲a̲l̲ ̲r̲o̲u̲t̲i̲n̲g̲ ̲t̲a̲b̲l̲e̲ ̲u̲p̲d̲a̲t̲e̲
The Supervisor has a procedure which make it possible
to make a specific locally change of the routing table.
The update of the routing is executed without any check
and syncronization with other Nodes or the SCC's.
S̲e̲c̲u̲r̲i̲t̲y̲ ̲p̲r̲o̲f̲i̲l̲e̲ ̲h̲a̲n̲d̲l̲i̲n̲g̲
Functions related to this subject are used to look
up, insert, delete and correct security profiles. Access
is allowed to user profiles including supervisor assistant
profiles, but not to the supervisor profiles. The procedure
accessing user profiles require a special authentication
before access is allowed.
In case an illegal password has been entered three
times, the terminal is blocked and an alarm sent to
the N/M.
The following procedures are used to interrogate and
insert corrections to the "security profile" tables
in the MEDE:
1) Enter "security profile" handling mode.
This procedure involves a special authentication
procedure. After authentication the supervisor
is allowed to use the other procedures in this
group.
2) Display profile index.
This procedure displays a list of all the profiles
that are stored. Displayed is: user id, which shall
be the key to the security profile table.
3) Display specified profile for correction.
This procedure displays a specified, by user id,
profile covering all information stored in the
profile. The information is formatted in a manner
that makes it easy and secure to introduce corrections.
The procedure is used also to create new profiles
to the system. The procedure is used also to delete
a profile.
S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲a̲t̲ ̲N̲o̲d̲e̲/̲M̲E̲D̲E̲
2̲4̲ ̲h̲o̲u̲r̲ ̲s̲t̲a̲t̲i̲s̲t̲i̲c̲
This statistic function in the Node/MEDE is a print
of the 24 hour N/M statistic generated at the SCC.
The statistical output will be delivered to the N/M
supervisor's AX queue as soon as it is generated at
the
SCC. The supervisor has a procedure to initiate a printout
of the received statistic. The statistic contains information
about the released and received messages for the actual
Node/MEDE.
M̲e̲s̲s̲a̲g̲e̲ ̲r̲e̲l̲e̲a̲s̲e̲d̲
Class/precedence/no of messages/no of ANO's/ no of
characters.
M̲e̲s̲s̲a̲g̲e̲s̲ ̲r̲e̲c̲e̲i̲v̲e̲d̲ (from the trunks)
Class/precedence/no of messages/no of characters.
S̲t̲a̲t̲i̲s̲t̲i̲c̲a̲l̲ ̲d̲a̲t̲a̲ ̲c̲o̲l̲l̲e̲c̲t̲i̲o̲n̲
The Node/MEDE automatically collects statistical data
and send these to the SCC once per hour.
L̲o̲g̲g̲i̲n̲g̲
The following types of logs are available:
- Message journal
- Transaction log
- Message log.
M̲e̲s̲s̲a̲g̲e̲ ̲j̲o̲u̲r̲n̲a̲l̲
A message journal is recorded on a disk area. The journal
transactions are stored sequentially and in chronological
order. The file update is cyclic i.a. if the allocated
file space is exhausted, updates restart at the beginning
af the space.
Message information is recorded at the following events:
1. When a message is released.
2. When a message is delivered either successfully
to the terminal print queues, or to the supervisor
terminal DT queue.
3. Retrieve request of a message on the HDB, for dis-
play.
4. Retrieve request of a message on the HDB, for print
out.
5. Retrieve request of a message on the HDB, for local
distribution. Both the retrieve event, and the
distribution event shall be logged.
6. Retrieve request of a message on the HDB, for read-
dressing.
7. When a SH messagge is delivered (identical to 2).
8. Message print out started.
Parameters logged are in cases applicable.
- time of event, DTG
- message identification, MSG ID
- type of event
- terminal ID.
T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲ ̲l̲o̲g̲
Transaction log entries are available as printout at
a supervisory terminal, specified at system start-up.
Log records for printout are entered into the LP queue
of the terminal.
The following transactions are logged:
1. Log on successful
2. Log on unsuccessful
3. Lof off successful
4. Lof off unsuccessful
5. Failed Security Interrogation.
Parameters logged are:
- transaction time, DTG.
- terminal identification, Term ID.
- user identification, USER ID.
- transaction type.
M̲e̲s̲s̲a̲g̲e̲ ̲l̲o̲g̲
A message log is available, which describes the contents
of the HDB. The message log is available as printout
at the supervisory terminal, on request.
The message log gives the information about the messages
available for retrieval.
The log information is presented in table form, and
following items are presented:
1. Retrieval time, DTG.
2. Message identification, MSG ID.
3. Subject indicator codes, SIC.
4. Classification, CLASS.
5. Precedence.
The very first page of the log contains a columm header
describing the table contents.
The message log is queued in the LP-queue for printout,
on request.
O̲n̲-̲l̲i̲n̲e̲ ̲f̲a̲u̲l̲t̲ ̲d̲e̲t̲e̲c̲t̲i̲o̲n̲
On-line diagnostic programs are executed in lowest
priority, and operate as part of the operational software
in both the active and the standby processor system.
The diagnostic results are available for automatic
transmission to the SCC, upon request from the SCC
Supervisor.
Each Node/MEDE processor perform on-line diagnostics
and generate its own status information. The result
of the on-line diagnostics, is posted to the watch-dog
within a predetermined time period, tied to a real
time clock.
The status posted to the watch-dog holds a one bit
counter, which is incremented, each time a successfully
online diagnostic test has been executed; this is used
to inform the watch-dog if the on-line diagnostic S/W
are running or not.
Each computer system passes status information to the
watch-dog at regular time intervals.
D̲u̲a̲l̲ ̲o̲p̲e̲r̲a̲t̲i̲o̲n̲ ̲M̲E̲D̲E̲
Each Node/MEDE has redundant computer systems. The
watch-dog is an independent microprocessor system interconnection
to the Node/MEDE processors through two interface channels
operated at max. 9600 BPS. It includes a teleprinter
console to input and printout system control messages
for both processors.
Each computer system has the capability to independently
perform Node/MEDE operations. During normal operations
one computer is in the "ACTIVE" mode while the other
computer is in the "STANDBY" mode.
W̲a̲t̲c̲h̲-̲d̲o̲g̲
Switchover is initiated by the "Watch-dog" computer.
This watch-dog has a KSR-directly connected. This teleprinter
serves as an operator interface to both CR80 systems
and as a device error log.
In the events of watch-dog computer failure, this teleprinter
can be directly connected to one of the Node/MEDE computers.
Switchover of processor and peripherals can be either
manually initiated from the system control panel or
automatically performed by the watch-dog.
The watch-dog receives status information from the
two computer systems at regular time intervals.
Based on the received status information, the watch-dog
decides whether switchover from active to standby shall
occur, and print an error message on the WD-teleprinter.
It is possible to override the watch-dog switchover
decision, by manual intervention.
If the standby system is non operational, no switchover
will take place.
The watch-dog is able to interchange the on-line/standby
assignment, switch both mass storage systems, and reassign
line termination units.
At each decision point the watch-dog computer will
print a message on the teleprinter to inform the operator
of the present situation and to make it possible for
him to override the decision of the watch-dog computer
if necessary.
The watch-dog contains its own self-test logic referenced
to a fix-wired timer.
The watch-dog automatically falls back to manual operator
control upon failure, which can be executed from the
system control panel.
3.3 N̲E̲T̲W̲O̲R̲K̲
IDCN will consist of a multinode network geographically
distributed throughout Israel. The proposed network
will initially consist of 4 nodes and 1 system control
center (SCC). The 4 nodes will be interconnected by
6 trunk lines. The SCC will be collocated with one
of the nodes.
The Figure below shows the network configuration.
IDCN Initial Network Configuration
3.3.1 N̲e̲t̲w̲o̲r̲k̲ ̲E̲l̲e̲m̲e̲n̲t̲s̲
The IDCN network consists of the following basic elements:
N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲i̲n̲g̲ ̲C̲e̲n̲t̲e̲r̲s̲ which consists of integrated
Node/MEDE CR80m computers. The network functions
are included in a software package called Nodal
Switching Subsystem (NSS).
The main functions of the NSS are message routing
and transmission of messages between nodes.
S̲y̲s̲t̲e̲m̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲C̲e̲n̲t̲e̲r̲ ̲(̲S̲C̲C̲)̲: The SCC is a dedicated
computer system which performs centralized control
and supervision of the network. A main function
is optimisation of the network performance by automatic
calculation and distribution of routing tables.
The network is designed for optionally two SCCs,
but only one SCC is proposed for the IDCN. A SCC
may be connected to any of the nodes. The connection
is by means of a V24 Interface, operated at 9600
Bps.
I̲n̲t̲e̲r̲n̲o̲d̲a̲l̲ ̲T̲r̲u̲n̲k̲ ̲L̲i̲n̲e̲s̲
The IDCN internodal trunk lines shall consist of
full duplex leased PTT circuits operating synchronously
at 9600 Bps. The interface between the CR80 line
interface units and the trunk lines shall be according
to CCITT V24/V28 recommendation. The link level
protocol uses HDLC frame formats and error detection
and correction. The link level protocol is implemented
by microprocessors in the CR80 line termination
units.
Trunk errors (no carrier, error not corrected by
retransmission, too many retransmissions) will
cause alarm to the Node/MEDE and to the SCC Supervisor.
A trunk line disconnection will automatically cause
alternative routing of message traffic. It is
possible to open and close trunk lines by supervisor
commands from the SCC and at the connecting nodes.
P̲u̲b̲l̲i̲c̲ ̲D̲a̲t̲a̲ ̲N̲e̲t̲w̲o̲r̲k̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲(̲X̲2̲1̲)̲-̲O̲p̲t̲i̲o̲n̲
As a backup for leased trunk line each node may
have access to a public circuit switched data network
through an X21 compatible interface. Call set-up
will use an abbreviated 2-digit address, and result
in the assignment of a 9600-baud channel by the
data network. The single connection to the node
will provide back-up for one trunk failure between
a pair of nodes.
Call set-up and call close-down is performed by
Node/MEDE supervisor procedures.
After a successful dial-up, the identification
of the replaced trunk is transmitted to the called
node and those events are reported to the N/M supervisors
and to the SCC.
In case of unsuccessful dial-up, this is reported
to the supervisors of the N/M as an alarm.
This facility is available in the system but not
included in this proposal.
C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲I̲n̲t̲e̲r̲m̲e̲d̲i̲a̲t̲e̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲(̲C̲C̲I̲E̲)̲
The communication channel intermediate equipment,
CCIE, consists of modems, cryptographic equipment,
patch panels, and main distribution frames. The
system shall include this equipment between the
line termination units and the voice frequency
or telegraph line facilities supplied by the PTT.
The equipment
3.3.2 T̲o̲p̲o̲l̲o̲g̲y̲
The IDCN is a meshed network configuration, providing
high flexibility and survivability by means of adaptive
routing. The maximum number of nodes is 32. Each
node may be connected to maximum five neighbor nodes.
The upper limit of trunk lines per node is 7. Connection
of two neighbour nodes may be by one or two 9600 Bps
trunk lines. Any node may be connected to a collocated
or remote SCC. One or two SCCs may be connected.
In case of two SCCs, one will be active while the other
will be stand-by and thereby constitute a geographically
remote backup. For IDCN one collocated SCC is proposed.
3.3.3 N̲o̲d̲a̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲ ̲S̲w̲i̲t̲c̲h̲i̲n̲g̲
The IDCN is a message switching network based on the
message store and forward principle. Entire messages
are transmitted from node to node and stored on disk
before being locally distributed or relayed to the
next node on the route.
Two types of messages exist:
1. N̲a̲r̲r̲a̲t̲i̲v̲e̲ ̲m̲e̲s̲s̲a̲g̲e̲s̲, which are text messages
generated
by
a
user
on
a
terminal
connected
to
the
message
entry
and
distribution
equipment
(MEDE).
The
header
of
such
messages
contain
destination
address
numbers
(ANOs)
which
identify
destination
nodes
and
destination
terminals.
When
such
messages
are
released
for
distribution
they
will
be
handed
over
to
the
Nodal
Switch
Subsystem
which
adds
a
binary
header
to
the
message
before
routing
and
transmission.
The
binary
header
contains
the
network
routing
information
which
controls
the
correct
routing
to
the
destination
nodes.
Narrative
messages
may
be
transmitted
with
different
priority
levels
controlled
by
the
originating
user.
2. C̲o̲n̲t̲r̲o̲l̲ ̲M̲e̲s̲s̲a̲g̲e̲s̲, which are generated by the
system either automatically or initiated by
a supervisor command. System generated control
messages are typically error messages and status
changes reporting such as trunk error and queue
overloads. Supervisor initiated control messages
are, among others, close trunk commands and
updates of address tables issued from the SCC.
Control messages are typically very short messages
transmitted with ultra high priority. Control
messages are routed by means of a binary header
similar to narrative messages.
Messages are routed through the network based
on an adaptive routing mechanism which minimizes
the network transmission delay. At each node
a routing table will contain 3 alternative routes
for each destination node: Primary, secondary,
and tertiary. Primary will give shortest delay
and therefore used unless the trunk line on
the primary route is disconnected or the primary
trunk message queue has exceeded a limit.
The routing tables are calculated by the SCC
based on the current connectivity in the network
and knowledge of the message load distribution.
The routing tables are distributed to the nodes
by means of control messages. New routing tables
are automatically generated upon network topology
changes such as node outage and trunk line disconnections.
New routing tables may also be generated by
SCC Supervisor command. In case of SCC outage
the network will continue operation based on
the local routing tables. If necessary these
tables may be updated by the local Node/MEDE
Supervisor.
3.3.4 N̲o̲d̲a̲l̲ ̲S̲w̲i̲t̲c̲h̲ ̲S̲u̲b̲s̲y̲s̲t̲e̲m̲
The main tasks of the Nodal Switch Subsystem (NSS)
are:
- the receipt of messages from the local MEDE
and a possible collocated SCC; these messages
are forwarded through the network.
- the receipt of message packets from the network;
the messages are sent to the local MEDE and
a possible SCC or they are relayed.
- routing of messages.
- assembly of inbound packets into messages before
routing and disassembly of outbound messages
into packets after routing.
- queueing by precedence of outbound messages.
- node-to-node message control.
- copying of multiaddress messages.
- oscillation and looping control.
- SCC- and MEDE-communication for error- and
statistical reporting and for the receipt of
network controlling information.
3.3.4.1 T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲B̲e̲t̲w̲e̲e̲n̲ ̲N̲o̲d̲e̲s̲
T̲h̲e̲ ̲E̲r̲r̲o̲r̲ ̲F̲r̲e̲e̲ ̲T̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲
During the error free transmission messages are transferred
between a pair of nodes via a transmission line in
both directions.
When a message is received it is acknowledged by returning
an ACK to the sending node. The purpose of this is
to maintain flow control i.e. to ensure that messages
are not forwarded faster than the receiver is always
able to accept the messages. For identification each
message is supplied with a unique number.
Before being transmitted a message is chopped into
packets. The purpose of this is to obtain easier handling,
because messages may be extremely long. Another purpose
is to give priority to the messages: if, during transmission
of a message, another message of higher priority must
be transmitted, the first message is temporarily aborted,
and transmission of the last message is initiated;
also this message may be temporarily aborted, if meanwhile,
a third message of even higher priority must be transmitted
and so on.
As an example short messages could be given a higher
priority than long messages reducing the average delay.
C̲l̲o̲s̲e̲ ̲T̲r̲u̲n̲k̲
When a trunk is closed it must not be used for message
traffic until it is reopened.
After a "close trunk" command the trunk state is set
ot closed.
All messages outbound on the trunk (and not yet acknowledged)
must be rerouted.
All messages inbound on the trunk and only partly received
must have their resources released. The messages will
be rerouted by the sender.
Probably there will now exist a mismatch between the
packet - as well as the message numbers of the two
nodes. Therefore they must be brought to agree, when
the trunk is opened.
O̲p̲e̲n̲ ̲T̲r̲u̲n̲k̲
In both neighbours, the inbound - as well as the outbound
packet numbers and message numbers are reset, because
there may exist a mismatch from the previous disconnection
or closing of the trunk.
The trunk state is set to open, so message traffic
is allowed to flow.
T̲r̲a̲n̲s̲i̲e̲n̲t̲ ̲T̲r̲u̲n̲k̲ ̲F̲a̲i̲l̲u̲r̲e̲
If noise or another transient trunk failure disturbs
the transmission of a packet, the failure will be detected
(with a very high degree of probability) at the receiving
node, and the erroneous packet will be discarded.
The packet will be retransmitted until it is received
without error.
For very long messages it is important that they are
chopped into packets which may be retransmitted. Otherwise
it may be very difficult to get them transferred.
The retransmission facility is implemented on the HDLC
- level of the TRUNK - connections.
On the TRANS-connection between an SCC and its collocated
node, however, no such retransmission facility is implemented.
Therefore packets may be disturbed and discarded.
The situation that one or more packets are missing
will be detected by the receiving Packet Handler.
All packets of the message(-s) in question will be
discarded, and the message(-s) will be retransmitted.
This is done by releasing resources occupied by packets
already received, by deletion of subsequent packets
and by returning a NACK to the sending neighbour.
It is seen that a NACK is a request for retransmission
of one or more entire message(-s) for repair of a transient
trunk failure.
P̲e̲r̲m̲a̲n̲e̲n̲t̲ ̲t̲r̲u̲n̲k̲ ̲F̲a̲i̲l̲u̲r̲e̲
If a transmission line is broken, or if the power is
switched off a modem, then the failure is so serious
that the trunk cannot be used for a shorter or longer
time; this error is reported to both nodes. The trunk
state is set to disconnected.
All messages outbound on that trunk (and not yet acknowledged)
must be rerouted.
All messages inbound on the trunk and only partly received
(i.e. the first but not the last packet is received)
must have their resources released. These messages
will be rerouted by the sender.
It is seen that there may now exist a mismatch between
the packet and the message numbers of the two nodes.
Therefore when the trunk has been repaired and being
re-opened the packet and the message counters of the
two neighbours must be brought to agree for that trunk.
N̲o̲d̲e̲ ̲F̲a̲i̲l̲u̲r̲e̲
To detect a failure in a neighbour node a special control
message of the very highest priority level is currently
forwarded to each neighbour connected with an open
trunk; having transmitted the message, a timer is started.
If the timer expires before the message is acknowledged,
it is retransmitted. If the timer expires after having
retransmitted once, the neighbour is assumed to have
failed.
Whether the node failure is transient or permanent,
transmission of message traffic will be avoided.
Therefore, messages outbound for the failed node will
be rerouted. Partly received messages inbound from
the node will be released - later, when the failed
node is restarted, they will be retransmitted.
The SCC is informed about the node failure if possible,
and new routing tables are generated.
When the former failed node is restarted, the former
open trunks are automatically reopened from that node.
As mentioned above, old outbound messages (i.e. messages
for which the failed node was responsible) are rerouted
and retransmitted.
If the former failed node is started from scratch,
the trunks must be opened by the supervisor.
If a "failure" is erroneously detected in a neighbour
actually running, possible messages from the "failed"
neighbour are acknowledged; otherwise the neighbour
will recognize the present node as failed. The situation
may be recovered simply by a CLOSE TRUNK followed by
an OPEN TRUNK command.
3.3.4.2 M̲u̲l̲t̲i̲a̲d̲d̲r̲e̲s̲s̲i̲n̲g̲
Messages for multiple (MEDE-) addressees (Figure 3.3.4.2-1)
are handled by the network as described below:
Referring to Figure 3.3.4.2-2 you will find that a
message is equipped with a routing mask placed in the
binary header. In the routing mask an indication is
set for each MEDE, SIP, or SCC which shall be delivered
one copy. (SIP, SCC Interface Process, used for control
messages to and from the SCC).
The names of the destinations are the letters: (applicable
for a 8 node network with 2 SCCs)
A: MEDE
B: MEDE
E: MEDE
F: MEDE
H: MEDE
K: MEDE
L: MEDE
N: MEDE
P: SCC, collocated N/M "E"
Q: SCC, collocated N/M "K"
S: SIP at N/M "E"
Z: SIP at N/M "K"
As late as possible a copy is made for each trunk,
which must transmit the message. Each copy is equipped
with an appropriate routing mask, which is a subset
of the routing mask received in the node. All copies
are handled according to a common action precedence
level.
One copy is given to each destination MEDE, or SCC
or SIP, independently of how many copies are made at
the communication centers.
Figure 3.3.4.2-1…01…The Network And Its Users…01…The Addresses Are MEDEs, SCCs,
And SPIs
Figure 3.3.4.2-2…01…Multiaddressing, Copying, And Routing…01…(The trunks HFl, HLl, and HNl are thought
to be disconnected)
3.3.4.3 F̲l̲o̲w̲ ̲C̲o̲n̲t̲r̲o̲l̲
R̲o̲u̲t̲i̲n̲g̲ ̲C̲o̲n̲t̲r̲o̲l̲
The network is a message switching network, so routing
is performed on message level; this means that (finally)
all packets of a message follow the same route.
The routing is non-predetermined, which means that
it is not determined in advance which route a message,
not yet put into the network, will follow. The decision
is taken from node-to-node. The advantage by doing
so is that the decision is made on the latest local
knowledge about the state of the nodes and the trunks.
The routing algorithm is run by the SCC.
The routing result of the algorithm contains three
alternate results per destination despite the fact
that it is run when the topology is changed and when
the delay is changed. The reason is that it must be
possible to perform routing also in the period of time
when the algorithm is executed, i.e. from some changes
occur until new Routing Tables are calculated and distributed.
A complete set of Routing Tables for a 8 node network
with 2 SCCs is shown in Figure 3.3.4.3-1.
Figure 3.3.4.3-1…01…The Routing Table Of Each Node
It must be pointed out that in a period of time where
the routing in the individual nodes is based on different
information about the network, oscillations and loopings
of messages may occur. The reasons may be:
- two nodes may disagree about the availability
of a trunk or a node.
- the information about topology and delay needs
some time to spread out through the network,
i.e. the routing tables arrive at different
times at different nodes.
The routing algorithm must ensure that when using the
same knowledge of the network, then two nodes agree
about the optimum route.
The amount of oscillations and looping of messages
in the network will be controlled by the "Orbit Counter"
of each message. The counter is a part of the binary
header. When entering the network it is a preset to
20; it is reduced by one, when passing a node; reaching
0 the message is transferred to the supervisor of the
Node/MEDE. In this way some small amount of oscillitions
and loopings is tolerated.
Narrative and control messages locked up in a node
(because all trunks are cut, or the destination is
not available) are transferred to the supervisor of
the Node/MEDE.
A message retransmitted from a node to its neighbour
node 3 times without success is transferred to the
supervisor of the Node/MEDE.
In a collocated node control messages for the SIP are
put into the SIP-queue, and narrative messages for
the SIP are put into the MDS-queue (see Figure 3.1.3.1-2).
T̲r̲a̲f̲f̲i̲c̲ ̲C̲o̲n̲t̲r̲o̲l̲
Traffic control means control of the amount of traffic
in the network; this is done in two ways:
- messages from the network to the local MEDE
are given a higher priority than relay messages.
Relay messages are given a higher priority
than new messages entering the network from
MEDE - to ensure that the network is not overloaded.
- if the length of the Trunk Queue exceeds the
threshold, this is reported to the SCC. This
is an indication of congestion in the neighbour
at the far end of the trunk.
Figure 3.3.4.3-2…01…Flow Of Messages For The SIP
C̲o̲n̲g̲e̲s̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
Congestion Control is performed by giving certain types
of messages higher priority than others. 6 + 1 precedence
levels are handled:
0. super flash S (for control messages:
ACK, NACK, MICK and MACK
only)
1. flash Z
2. rush Y
3. immediate O
4. priority P
5. quick M
6. routine R
3.3.5 E̲r̲r̲o̲r̲ ̲C̲o̲n̲t̲r̲o̲l̲
P̲h̲y̲s̲i̲c̲a̲l̲ ̲L̲e̲v̲e̲l̲
Trunk disconnection, soft trunk failures, and unsuccessful
NPDN call-up/close-down are detected and reported from
the LTUX-TRUNK and LTUX-NPDN.
L̲i̲n̲k̲ ̲L̲e̲v̲e̲l̲
Frame format errors are detected and corrected on the
Link Level. Crypto Garbling is detected and reported.
P̲a̲c̲k̲e̲t̲ ̲L̲e̲v̲e̲l̲
Errors detected and reported by the Packet Handler
are:
Packet Format Error and Missing Packet.
L̲E̲V̲E̲L̲ E̲R̲R̲O̲R̲S̲
5: Node-to-Node Neighbour Node Failure
4: Message Missing message
Phantom message
Hard Trunk Failure
Neighbour Node Failure
Message locked out from destination
Orbit message
Trunk Queue threshold exceeded
3: Packet Packet format error
Missing packet
2: Link Crypto garbling
Frame error
Too many retransmissions
1: Physical Trunk disconnected
Soft trunk failure
Unsuccessful NPDN call-up/close-down
Figure 3.3.5-1…01…Errors And Levels.
The errors are grouped according to the
level where they are first recognized
M̲e̲s̲s̲a̲g̲e̲ ̲L̲e̲v̲e̲l̲
Errors detected but not corrected on the packet level
are reported to the message level. These may be:
- Missing message
Too many retransmissions of messages to the next node
are reported to the supervisors (Hard Trunk Failure
or Neighbour Node Failure). Duplicated messages are
cancelled. Messages may be locked out from their destination;
such messages are transferred to the MEDE supervisor.
Trunk Queue Threshold Alarms and Orbiting Messages
are reported to the SCC.
N̲o̲d̲e̲-̲t̲o̲-̲N̲o̲d̲e̲ ̲L̲e̲v̲e̲l̲
A node failure is detected and reported from its neighbours.
E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲i̲n̲g̲
The following error reports are sent to the supervisor
of the MEDE:
report: Trunk failure, hard/soft
Node fialure
Unsuccessful NPDN call-up/close-down
The Message distribution Subsystem at the Node/Mede
receives narrative messages locked-out, orbiting or
being retransmitted too many times.
The error reports mentioned below are sent to the supervisor
of the SCC.
Local Network
Status Report:
- Trunk failure
- NPDN assignment
- Trunk Queue Threshold
- Node failure
- Change of Data User Route
- Crypto failure
- Orbiting narrative message
One hour reports are sent to the supervisor of the
SCC containing:
- No. of frames transmitted per
trunk
- No. of frames retransmitted per
trunk
- Trunk load
- DTG of oldest message per precedence per trunk
3.3.6 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The NSS forwards statistical information to the SCC
every hour:
- No. of frames retransmitted per trunk
- Trunk load: No. of text characters trasmitted
- trunk queue length: No. of messages per precedence
- DTG of oldest message per precedence per trunk
The information is transmitted by a control message.
3.3.7 N̲e̲t̲w̲o̲r̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲
Network control is performed from the SCC by distributing
control messages to the individual nodes. It may also
be performed locally by the MEDE supervisor.
Network control performed by the SCC covers:
- Routing Tables
- Open/Close Trunk
- Set alarm threshold of retransmission rate
- Set alarm threshold of Trunk Queue length
Local control performed by the MEDE supervisor covers:
- Local updating of Routing Table
- Open/Close trunk
- NPDN call-up/close-down
3.4 S̲C̲C̲ ̲
The function of the SCC is to perform centralized supervision
and control of the overall IDCN Network.
One SCC is proposed for the IDCN, with an option for
expansion to two SCC's.
3.4.1 G̲e̲n̲e̲r̲a̲l̲ ̲C̲h̲a̲r̲a̲c̲t̲e̲r̲i̲s̲t̲i̲c̲s̲ ̲
The SCC is connected to the collocated Node/MEDE via
a 9.6 KB LTUX connection. An active SCC performs the
following major functions:
- Network Control: Message routing control, centralized
maintenance of address tables and of Node/MEDE
supervisor security profiles.
- Network Supervision: The SCC receives via Control
Messages network status information, which is presented
to the SCC supervisor as alarms, alerts and notices.
The status of the network is displayed on a TV
monitor.
- Network Statistics: Collection of data for statistical
treatment.
3.4.1.1 M̲o̲d̲e̲s̲ ̲o̲f̲ ̲o̲p̲e̲r̲a̲t̲i̲o̲n̲
A. The SCC shall be in one of the following modes
of operation:
M̲o̲d̲e̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲D̲e̲f̲i̲n̲i̲t̲i̲o̲n̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
On-line, Active The SCC perform all Network monitoring
and Control. Only one SCC kan be
active at a time; if dual SCC option
is included,
it forwards keep-alive messages
to the standby SCC at regular intervals.
---------------------------------------------------------…86…1
…02… …02…
On-line, Standby The SCC is ready to take over as
Active. It performs in this mode
network supervision, and in case
of dual SCC, it forwards keep alive
messages to the active SCC at regular
time intervals.
--------------------------------------------------------
Off-line The SCC is logically disconnected
from the Network and can only be
used for operating off-line Software.
--------------------------------------------------------
B. Below figure shows the possible transitions between
the modes of operation:
Figure 3.4.1.1-1
The shown mode transitions shall be handled in
the following way:
a. A̲c̲t̲i̲v̲e̲ ̲t̲o̲ ̲S̲t̲a̲n̲d̲b̲y̲
By supervisor command.
In case of dual SCC:
The active SCC shall command the other SCC to enter
active mode. If the other SCC do not confirm a
completion of standby to active transition or the
other SCC is off-line, the commanding SCC will
not enter into standby mode.
b. S̲t̲a̲n̲d̲b̲y̲ ̲t̲o̲ ̲a̲c̲t̲i̲v̲e̲
The transition is forced by a supervisor command.
In case of dual SCC:
This command may be given when the active SCC direct
the standby to take over, or upon an active SCC
failure.
c. S̲t̲a̲n̲d̲b̲y̲ ̲t̲o̲ ̲o̲f̲f̲-̲l̲i̲n̲e̲
This transition will occur by use of a supervisor
initiated procedure, which performs a controlled
shut down of a standby SCC.
d. O̲f̲f̲-̲l̲i̲n̲e̲ ̲t̲o̲ ̲S̲t̲a̲n̲d̲b̲y̲
This transition is performed automatically and
is part of the start up procedure.
It can also be performed if a supervisor regrets
a Standby to Off-line transition, and issues a
Go-Standby command.
3.4.2 A̲c̲t̲i̲v̲e̲ ̲S̲C̲C̲
The Active SCC will be able to perform the following
functions:
a. Network Control
b. Network Supervision (including the remote stand-by
SCC, if dual SCC option)
c. Local Supervision and Control
d. Statistics collection and generation
e. Remote Maintenance Support
f. Standard terminal functions.
3.4.2.1 N̲e̲t̲w̲o̲r̲k̲ ̲C̲o̲n̲t̲r̲o̲l̲
A
The SCC Supervisor will exercise control over the
IDCN network by using commands, which result in
down line loading of Node/MEDE tables.
3.4.2.1.1 M̲e̲s̲s̲a̲g̲e̲ ̲R̲o̲u̲t̲i̲n̲g̲ ̲C̲o̲n̲t̲r̲o̲l̲
A
The SCC will have a procedure for calculating and
updating the Message Routing table.
B
Input to the calculation will be the network connectivity
(which is a function of queue lengths + allocated
bandwidth).
C
Output from the calculation will be an updated
Message Routing table for each active Node/MEDE.
D
The updated routing tables will be forwarded to
the Node/MEDEs by use of control messages. When
received at the N/Ms the local routing table will
be automatically updated.
E
The forwarding of routing table to the N/M will
be supervisor initiated i.e. by change of delay
factors, or automatically initiated i.e. by topology
change (trunk failure).
3.4.2.1.2 A̲d̲d̲r̲e̲s̲s̲ ̲N̲u̲m̲b̲e̲r̲ ̲t̲a̲b̲l̲e̲s̲
A
The SCC will maintain the address number table,
which is common to all Node/MEDEs and the SCC('s).
B
The content of the ANO-table will be
a. Address Number (One letter followed by 3 digits)
b. Addressee Name, Israel: (Max. 20 characters)
c. Addressee Name, English (Max. 20 characters)
d. Terminal Id. (3 letters)
C
The update procedure will be on-line from a VDU,
and functions will be the following
- Add (only when initial space allocated)
- Delete
- Change
where the Key to all changes is Address number.
All update functions will relate to one table entry.
D
Updates are forwarded to the N/Ms as control messages.
Upon reception by the N/Ms an automatic update
will occur of N/M tables.
E A table entry updated at the SCC cause a permanent
change of the SCC and N/M table.
F
It will only be possible to distribute an entire
ANO-table entry record.
G
The SCC will have facilities for on-line table
display and printout of table content.
3.4.2.1.3 A̲I̲G̲ ̲T̲a̲b̲l̲e̲s̲
A
The SCC will maintain an A̲ddress I̲ndicator G̲roup
(AIG) table which is common to all Node/Mede's
and the SCC('s).
B
The content of the table will be address number's
(ANO's).
C
The number of ANO's within a AIG entry can be up
to 275 ANO's.
D
The SCC will be the only one to update the AIG
table.
E
The update procedure will be on-line from a VDU,
and the functions will be the following:
- Add (only when initial space allocated)
- Delete
- Change
Where the key to all changes is an AIG.
Updates are forwarded to the N/M's as control messages.
Upon reception by the N/M's an automatic update
of the N/M tables will occur.
F
A table entry updated at the SCC cause a permanent
change of the SCC and N/M table.
G
It will only be possible to distribute an entire
AIG table entry record.
H
The SCC will have a facility for on-line table
display and printout of table of content.
3.4.2.1.4 S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
A
All N/M Supervisor Security Profiles will be stored
and maintained by the SCC.
B
The SCC supervisor will have a procedure for updating
and downline load of a given N/M supervisor's security
profile.
C
Only Active SCC will be able to update and distribute
new or changed Supervisor profiles to the N/M's.
D
Seen from the operator the update procedure will
be similar to the Node/MEDE user security profile
procedure.
E
Only completely new or changed supervisor security
profile records will be distributed to the Node/MEDES.
3.4.2.1.5 T̲h̲r̲e̲s̲h̲o̲l̲d̲ ̲s̲e̲t̲t̲i̲n̲g̲ (Parameter Control)
A
The active SCC will have facilities to change the
following threshold values at the Node/MEDEs:
1. Retransmission rate threshold on trunks
2. Trunk queue threshold:
- maximum queue length
- minimum queue length
Controlling alarm on/off respectively
B
Changes will automatically be distributed to the
Node/MEDEs, and threshold automatically set in
accordance with transmitted values.
3.4.2.2 N̲e̲t̲w̲o̲r̲k̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
A
The SCC(s) will perform network supervision by
means of control messages received from Node/MEDEs
containing reports and other status information
reflecting the network status.
B
The control messages contain reports, which will
be presented to the operators in the following
ways:
- Alarms: Alarms cause an audible alarm to sound
a few seconds and a blinking character
in the queue display area of the supervisory
VDUs.
- Alerts: Alerts cause a blinking character
in the queue display area of the supervisory
VDU's.
- Notices: These are reports generated purely
for information and require no supervisor
to take action. Notices are only printed
on the log-printer.
C
Log Printer: All reports except statistical reports
will be printed on the SCC-log printer.
D
Reports will contain the following information:
- Time of event
- Event description
- Identification of subjects involved
3.4.2.2.1 T̲V̲-̲M̲o̲n̲i̲t̲o̲r̲
The TV monitor at the on-line SCC will display a graph
of the IDCN network. Figure 3.4.2.2.1-1.
The graph will illustrate through a colour code the
status of each network element.
The network elements which will be displayed are:
- T̲h̲e̲ ̲S̲C̲C̲(̲'̲s̲)̲ ̲illustrated by a circle enclosing the
letter(s) identifying the SCC(s)
- T̲h̲e̲ ̲N̲o̲d̲e̲/̲M̲E̲D̲E̲s̲,̲ ̲illustrated by a circle enclosing
the letters identifying the Node/MEDE's.
- T̲h̲e̲ ̲t̲r̲u̲n̲k̲, illustrated by a line between the Node/MEDE's.
For each element the operational status is indicated
by a colour code:
Figure 3.4.2.2.1-1
IDCN NETWORK STATUS
T̲R̲U̲N̲K̲ ̲C̲O̲L̲O̲U̲R̲S̲:
RED : Disconnected or closed
WHITE : Transition state (ON OPERATOR REQ.)
YELLOW : NPDN connection, OPEN
GREEN : NORMAL Connection, OPEN
T̲R̲U̲N̲K̲;̲ ̲B̲E̲N̲D̲:̲
MAGENTA : NEIGHBOR NODE FAIL
BLUE : TRUNK THRESHOLD EXCEEDED
OTHER : SAME AS FOR TRUNK
S̲C̲C̲ ̲C̲O̲L̲O̲U̲R̲S̲:̲ (transition shown by changing SCC
ID to colour of new state)
MAGENTA : Offline
YELLOW : Standby (incl. transitions away
from stby)
GREEN : Active and Act. Standby trans.
N̲/̲M̲ ̲C̲O̲L̲O̲U̲R̲S̲:̲
GREEN : Dual operation
MAGENTA : Singular operation
RED : N/M Failed (Off)
BLACK : Offline
3.4.2.2.2 R̲e̲p̲o̲r̲t̲s̲
Point A, B, C below summarizes and group the reports
which will be received at the SCC.
A Alarms: The following event will cause an alarm
at the SCC;
A̲l̲a̲r̲m̲s̲
1. Dial up/close down NPDN
2. Trunk failure
3. Trunk queue threshold on/off
In case of dual SCC:
4. Active SCC switchover request
5. Active SCC failure
B. Alerts: The following event will cause an alert
at the SCC:
A̲l̲e̲r̲t̲s̲
1. N/M switchover
2. N/M out/in operation
3. N/M standby available/unavailable
4. Crypto failure
C. The following event will cause a notice at the
SCC:
N̲o̲t̲i̲c̲e̲s̲
1. N/M Diagnostic Result (as reply on SCC request)
2. N/M Disc unit status change (on/off)
3. Message orbiting
4. Trunk error rate exceeded
5. Security profile update at N/M's
3.4.2.2.3 N̲o̲d̲e̲/̲T̲r̲u̲n̲k̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
A N̲o̲d̲a̲l̲ ̲T̲r̲a̲f̲f̲i̲c̲
DTG of oldest message in each trunk queue per precedence
is reported to the SCC once per hour.
B R̲e̲t̲r̲a̲n̲s̲m̲i̲s̲s̲i̲o̲n̲ ̲R̲a̲t̲e̲s̲ ̲o̲n̲ ̲T̲r̲u̲n̲k̲s̲
The retransmission rate measured as retransmitted
frames in percent of the total number of transmitted
frames per hour is reported to SCC once per hour.
C T̲r̲u̲n̲k̲ ̲L̲o̲a̲d̲
The number of messages transmitted per precedence
per hour in each direction will be reported to
the SCC once per hour.
3.4.2.2.4 M̲E̲D̲E̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
A. The DTG for the oldest message in each message
output queue i.e. print queues, will be reported
hourly to the SCC.
3.4.2.3 L̲o̲c̲a̲l̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲/̲C̲o̲n̲t̲r̲o̲l̲ ̲
Local Supervision and Control will include Supervision
of the
- local SCC queues
- local SCC hardware
and control of the
- SCC modes
3.4.2.3.1 L̲o̲c̲a̲l̲ ̲S̲C̲C̲ ̲q̲u̲e̲u̲e̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
The following queues will be supervised at the SCC:
- AL: Alarm/Alert queues
- LP: Printer queues
The queue status will be displayed on the VDU's queue
status line.
3.4.2.3.2 L̲o̲c̲a̲l̲ ̲S̲C̲C̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲S̲u̲p̲e̲r̲v̲i̲s̲i̲o̲n̲
The SCC will be provided with on-line diagnostic program's,
for on-line fault detection, similar to that at the
Node/MEDEs.
Fault detection will be written on the KSR connected
to the SCM at the SCC.
3.4.2.3.3 S̲C̲C̲ ̲M̲o̲d̲e̲ ̲C̲o̲n̲t̲r̲o̲l̲
The SCC Supervisor will have procedures for control
of SCC modes. These procedures will include:
o Active to Standby Transition
o Manual restart
o Standby to Active Transition
o Standby to off-line Transition
o Offline to Standby Transition
In case of dual SCC:
o Switchover
3.4.2.4 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲ ̲c̲o̲l̲l̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲g̲e̲n̲e̲r̲a̲t̲i̲o̲n̲
3.4.2.4.1 L̲o̲g̲g̲i̲n̲g̲
A
A transaction log will exist; logging:
- All the reports received from the N/M
- All SCC generated commands
on a supervisory printer.
B
Each log event is printed according to the precedence
alarm, alert, notices, commands.
C
Information logged will be
S̲C̲C̲ ̲g̲e̲n̲e̲r̲a̲t̲e̲d̲ ̲c̲o̲m̲m̲a̲n̲d̲s̲
o Command
o Event description
R̲e̲p̲o̲r̲t̲
o Type
o Sender-id
o DTG
o Event description
o Identification of subjects (H/W) involved
3.4.2.4.2 S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
A
The SCC will have facilities to collect statistical
data, and to generate the MEDE 24 hour statistic.
B
The MEDE 24 hour statistics will be generated on-line.
C
Input for the statistics are collected on-line
from control messages received at the SCC once
per hour.
D
All control messages containing statistical data
will include the DTG of collection.
E
It will be possible to dump on-line the collected
statistical data, from mass storage to floppy disc.
3.4.2.4.2.1 N̲e̲t̲w̲o̲r̲k̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The following Network Statistic data will be collected
at the SCC:
a. Number of Retransmissions per trunk
b. Message load per trunk
c. Trunk queue length per precedence per MEDE
d. The DTG of the oldest message in transit per precedence
per MEDE.
3.4.2.4.2.2 M̲E̲D̲E̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
A. 24 hour Statistic
This statistic will be generated online, when the
supervisor activates the procedure.
The statistic will contain information about the
released and received messages for each Node/MEDE,
and will cover the traffic for the preceding day
(from 00.00 - 24.00).
The information will be:
M̲e̲s̲s̲a̲g̲e̲s̲ ̲r̲e̲l̲e̲a̲s̲e̲d̲:̲
Class/precedence/No. of messages/No. of ANO's (ACTION
& INFO)/total No. of characters.
M̲e̲s̲s̲a̲g̲e̲s̲ ̲r̲e̲c̲e̲i̲v̲e̲d̲ ̲(̲f̲r̲o̲m̲ ̲t̲h̲e̲ ̲t̲r̲u̲n̲k̲s̲)̲:̲
Class/precedence/No. of messages/total No. of characters.
E̲x̲a̲m̲p̲l̲e̲:̲
R̲E̲L̲E̲A̲S̲E̲D̲ R̲E̲C̲E̲I̲V̲E̲D̲
SECR/R/3/11/58 REST/R/4/82
SECR/P/2/8/34 UNCL/PO/2/21
CONF/P/4/12/126 UNCL/R/13/112
REST/R/1/8/31
The 24 hour statistic will after generation automatically
be distributed to the concerned Node/MEDE (AX queue).
B. S̲T̲O̲R̲A̲G̲E̲ ̲(̲H̲D̲B̲)̲ ̲s̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The DTG of the oldest message in the HDB per MEDE
(per hour) will be collected.
C. M̲e̲s̲s̲a̲g̲e̲ ̲F̲l̲o̲w̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The system will collect statistical data for the
following:
a. Queue-length of the message queues in the MEDE
categorized by precedence per MEDE.
b. Number of mutilated messages per MEDE
c. DTG of oldest message in print queue per precedence
per MEDE.
3.4.2.4.2.3 S̲e̲c̲u̲r̲i̲t̲y̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
These statistics will be based on reports sent to the
SCC from the Node/MEDEs, and will contain information
related to security events.
A C̲r̲y̲p̲t̲o̲ ̲E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲F̲a̲i̲l̲u̲r̲e̲s̲
This statistic contains count of the following
events per Crypto Unit per MEDE:
o Crypto failure (on/off)
B S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲a̲r̲a̲m̲e̲t̲e̲r̲ ̲C̲h̲a̲n̲g̲e̲s̲
These data will contain the following events:
a. Sec. Profile entry changed
b. Sec. Profile entry added
c. Sec. Profile entry deleted.
Each event will be marked with the supervisor user
identification.
3.4.2.4.2.4 M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲S̲t̲a̲t̲i̲s̲t̲i̲c̲s̲
The following events are collected:
a. Trunk circuit outage
b. Trunk circuit back in service
Each event will be marked with the DTG of the event.
3.4.2.5 R̲e̲m̲o̲t̲e̲ ̲M̲a̲i̲n̲t̲e̲n̲a̲n̲c̲e̲ ̲S̲u̲p̲p̲o̲r̲t̲ ̲
A
The SCC Supervisor will have a procedure for having
the diagnostic results from any Node/MEDE, automatically
sent for printout at the SCC:
B
The result from the diagnostic's are forwarded
to the SCC without N/M personnel intervention.
C
The diagnostics will be printed on the logprinter
in a defined format.
3.4.2.6 S̲t̲a̲n̲d̲a̲r̲d̲ ̲t̲e̲r̲m̲i̲n̲a̲l̲ ̲f̲u̲n̲c̲t̲i̲o̲n̲s̲
The operator can make use of the following control
functions:
a. Trunk control.
- Set retransmission rate
- Set trunk queue thresholds
- Trunk open/close
b. Data table/file display and update.
- Display/update delay table
- Display routing table
- Display ANO/AIG table index
- Update ANO/AIG table
- Supervisor security profile changes
c. SCC mode, SCC VDU mode control.
- Log-on
- Log-off
- SCC active to stand-by
- SCC off-line to stand-by
- SCC stand-by to active or off-line
In case of dual SCC:
- Cancel/reject SCC mode change
d. Monitoring.
- Request on-line diagnostics results.
3.4.3 S̲t̲a̲n̲d̲b̲y̲ ̲S̲C̲C̲
The Standby SCC will be able to perform the following
functions:
a. Network Supervision, please refer to 3.4.2.2
b. Local Supervision and Control, please refer to
3.4.2.3
c. Statistics collection, please refer to 3.4.2.4,
notice only collection performed.
d. Standard terminal functions, but only those concerning
SCC mode, SCC VDU mode control, please refer to
3.4.2.6.c.
The difference between a Standby SCC and an Active
SCC, is the Active SCC's possibility to control and
change the Network topology, and change of configuration
cables.
3.4.4 O̲f̲f̲-̲L̲i̲n̲e̲ ̲S̲C̲C̲
The Off-line SCC will be able to perform normal Software
development functions e.g.:
File manipulation:
- editing
- copying
- inspecting
- printing
- patching
- creating
- deleting
- renaming
- protecting
Program development:
- SWELL compiler
- PASCAL compiler
- Assembler
- Linker
- Debugger
- System Generator
- Boot module Generator
