Trailing-Edge
-
PDP-10 Archives
-
BB-H348C-RM_1982
-
swskit-v21/documentation/false-node-init.mem
There are no other files named false-node-init.mem in the archive.
ADDENDUM TO
TOPS-20 NETWORKS
PROJECT PLAN FOR
DECNET-20 VERSIONS 1.0 AND 2.0
Addendum to TOPS-20 Networks Project Plan for DECnet-20 Page 2
1.0 EXECUTIVE SUMMARY
The RSX-11M prototype Phase III routing node can currently
communicate point-to-point with Phase II products which do not
implement intercept. This communication employs simple
compatibility code in the routing node. The DRG approved
version of the Transport Specification documents the technique.
This technique permits the evolution of non-intercept Phase II
nodes to Phase III nodes by conversion one at a time. At no
time in this process does any communication capability get
lost.
Unfortunately, no such technique has been devised for
communication between DECnet-20 and Phase III routing nodes
where a DN20 intercept node is used. As this communication
capability is as much a goal of the DECnet Program as any other
Phase II to Phase III capability, it is essential that
DECnet-20 communicate successfully to Phase III nodes.
After reviewing the several alternative solutions to the
problem of intercept nodes communicating with Phase III nodes,
the selected algorithm is one termed "False Node Init".
Briefly, this algorithm causes the DN20 DECnet front end to
appear to all nodes but the 2040/50/60 to which it is coupled
as the 2040/50/60 node. This means that it will no longer be
an intercept node to the network. It will still appear to be
an intercept node to the 2040/50/60 and continue to behave
exactly the same as previously for the host system. Further
detail of this algorithm is supplied later in this document.
This addendum to the final networks plan defines the new plan
required for DECnet-20 Task-to-Task to be compatible with Phase
III routing nodes by implementing the "False Node Init"
algorithm. This plan is designed to have minimal impact to the
Release 4 Program.
Functionally, the user will see no change in the product from
the DECnet-20 Version 1.0 product in the same configuration.
It is important to note, however, that this new algorithm WILL
change the topological considerations from those initially
anticipated for the Version 2.0 product. We are fortunate that
a multiple line product has not been released, as this would
have created several problems.
2.0 GOALS
The goals of this Project revision are:
1. Continued compatibility with all Phase II DECnet
products.
Addendum to TOPS-20 Networks Project Plan for DECnet-20 Page 3
2. Phase II type compatibility with the DECnet Transport
Specification.
3. Extensive system test to minimize the risks associated
with implementing critical code so late in the
program.
4. No, or at least minimal, impact on the TOPS-20 Release
4 Program schedule.
The non-goals of this project revision are:
1. Guaranteed Phase III routing node compatibility.
It is the Phase III products that must be (and prove)
compatibility with this implementation, as with any
other Phase II implementation.
2. Specifically excluding the use of the intercept
functions available within the DN20 to any system
attempting to use it.
3. Specifically including the use of the intercept
functions available within the DN20 to any system
attempting to use it.
3.0 TEST PLAN
3.1 Unit Test
The tests, procedures, and timing of this phase are the
responsibility of the developers and must fit into the
framework of the overall implementation plan. This means that
a system using "False Node Init", which is felt by the
developers can successfully connect, send data, and disconnect
to a DECnet-11M system, should be available no later than
January 22, 1979.
The following is the Unit Test Plan devised by the developers
responsible:
"The purpose of unit testing the DN20 False Node
Init is to assure the implementors that:
1. "the code implements the algorithm outlined in
section 5 of the Addendum to the TOPS-20
Project Plan for DECnet-20; and,
2. "the algorithm exhibits the external
characteristics identified in section 2 of the
addendum.
Addendum to TOPS-20 Networks Project Plan for DECnet-20 Page 4
"To this end, unit test consists of two phases. In
the first phase, we verify that the code
modifications produce the desired microscopic
effects. Testing at this level is accomplished
using artificial stimulus and inspections of the
system data structures. Specific tests verify that
the DN20 can:
1. "discriminate the DTE line from other lines
during the line enable and startup sequence
2. "initially start the DTE line and not any
others
3. "send the 20xx its native node init message
4. "save the node init parameters from the 20xx
system and not save parameters from remote
systems
5. "allow lines other than the DTE to start once
the 20xx system completes node initialization
6. "correctly build node init messages which it
sends to remote nodes from the saved parameters
provided by the 20xx system
7. "discriminate the DTE line from other lines
when messages are received without route
headers
8. "detect control messages other than start-up
control messages
9. "build route headers for control messages which
have the node name of the 20xx system as the
destination node and the name of the node
adjacent on the receive line as the source
node.
"In the second phase, we verify that the
combination of microscopic changes produce the
desired system performance. This is demonstrated
by the following events.
1. "The DN20 and the 20xx system complete the node
init operation.
2. "The 20xx system and the DN20 communicate using
any program that uses the logical link
interface.
Addendum to TOPS-20 Networks Project Plan for DECnet-20 Page 5
3. "The DN20 will not node init with any other
(not 20xx) system until the 20xx completes node
initialization.
4. "The DN20 will node init with another system
once the 20xx system completes node
initialization.
5. "The remote system believes that the name of
the adjacent node is the name of the 20xx
system.
6. "The 20xx system and a Phase 2 remote system
communicate using any program that used the
logical link interface.
7. "The 20xx system and a remote system which does
not build route headers communicate using any
program that uses the link interface."
3.2 System Test
Once a system which has been unit tested is available, system
test will start. This will be January 22, 1979. System test
will consist of DECnet Certification Comprehensive tests as
specified in the DECnet-20 Version 2.0 Certification Plan.
These tests will be run originally to the DECnet-11M system
on SYS880. It is expected that to successfully complete this
first phase of system test will require three weeks of
testing ending February 9, 1979. These tests will be done
using the DN20 on 2102 stand-alone at least two hours per
day. Inability to obtain the use of the DN20 for these time
periods will cause one-for-one slippage to this part of the
project.
After system test with DECnet-11M, system test will be
conducted with a 2020. This 2020 is currently planned to be
system 4097. This phase of system test is expected to move
significantly faster, and require no more than two weeks, and
most likely one week. Planned completion is February 16,
1979. As above, 2102 DN20 stand-alone time for at least two
hours a day will be required.
Once the above certifications have been completed in a DN20
stand-alone environment, the system will be put into the
standard timesharing load test environment.
Addendum to TOPS-20 Networks Project Plan for DECnet-20 Page 6
3.3 Load Test
Timesharing Load Test is the next phase of the test plan
commencing February 19, 1979. The new DN20 code will be put
onto 2102 as the standard timesharing system. During the
load test period, various certification tests will be
completed to other 2040/50/60 systems, and to various PDP-11
based DECnet systems as specified in the DECnet-20
Certification Plan.
The other, related aspects of network load test, including
ATS and RJE, will continue according to original plans and
schedules. This addendum should have no major impact on
testing or functionality of these other projects.
3.4 Field Test
To enter Field Test, the "False Node Init" system must have
passed formal certification with DECnet-11M Version 2.0;
DECnet-2020 Version 1.0; and whatever DECnet system
DECnet-20 Version 2.0 will Field Test with, if not either of
the former.
Field Test will proceed as originally planned with the new
"False Node Init" system.
4.0 DETAILS OF "FALSE NODE INIT" ALGORITHM
The "False Node Init" algorithm has as its major goal making
the 2040/50/60 host and DN20 front end appear to the other
nodes of the network as one non-intercept node, that node
being the host node. The DN20 does not exist in the
knowledge of the network, except to the host 2040/50/60.
That is:
1. The 2040/50/60 will perceive the network to be, as
presently, front ended by the DN20 intercept node.
2. The DN20 will special case certain of its intercept
functions as described later in this section.
3. All network nodes connected point-to-point with DECnet-20
will perceive one non-intercept end node with the node
name and number of the 2040/50/60. They will have no
knowledge of the existence of an intervening node (the
DN20).
This will be accomplished in the following manner:
Addendum to TOPS-20 Networks Project Plan for DECnet-20 Page 7
1. There are no changes to the TOPS-20 system.
2. When the DN20 is first started, it will do an NSP NODE
INIT with the DTE-20 line only. This will be done as
presently implemented.
3. The DN20 will use the NODE INIT message received from the
host TOPS-20, use the minimal values of BLKSIZ and
SEGSIZE, and start the Node Init process with all other
started lines. Note that this Node Init process is what
causes end nodes to see only a non-intercept 2040/50/60
system.
4. When the DN20 system is originally built, the host and
DN20 passwords must be set equivalent. The DN20 front
end will continue to do all node verification.
5. Outgoing CONNECT INITIATEs (from the host 2040/50/60 to
any other network node) will be processed as presently
implemented.
6. Incoming CONNECT INITIATEs (to the host 2040/50/60 from
any other network node) will be processed as follows:
a.) If a RTHDR (Routing header) exists, it will be
processed as presently implemented.
b.) If a RTHDR does not exist, and the message is not
from the DTE line, the DN20 must generate a correct
RTHDR, setting the destination node to the host
2040/50/60, and the source node to the node known to
exist on the incoming line.
c.) If a RTHDR does not exist, and the message is from
the DTE, the message is for the DN20.
7. Data Messages on established logical links will work as
currently implemented, using the LNKADR (Link address) to
do the proper intercept functions.
8. All other NSP Control Messages (not Connect or
initialization messages) will be handled as specified for
incoming CONNECT INITIATEs.
Topologically, this algorithm makes DECnet-20 consistent with
all other DECnet Phase II products. It is an end node to end
node, point-to-point system.
[End of Addendum to Networks Project Plan]