Trailing-Edge
-
PDP-10 Archives
-
QT020_T20_4.1_6.1_SWSKIT_851021
-
swskit-documentation/tcpip.mem
There are no other files named tcpip.mem in the archive.
MEMOS IN THIS FILE:
o Overview (R6-ARPANET.TXT)
o Functional Specification (TCPIP-SPEC.DOC)
o NI-based TCP/IP project (TCPNI-PROJECT-DESCRIPTION.TXT)
o NI-based TCP/IP driver specification (IPNIDV.TXT)
-------------------
"ARPANET Overview"
----------------
Release 6 of TOPS-20AN supports a new set of network software for the
ARPANET environment. All the protocols below the user level have been
completely changed. Protocols at and above the user level have been
modified to use TCP instead of NCP. The new protocols are based upon
the Internet Protocol (IP) and the Transmission Control Protocol
(TCP). The family of protocols making up the "new" ARPANET are
collectively called TCP/IP.
The new family of protocols was developed by the Department of
Defense (DOD) to facilitate the interconnection of various homogenous
and heterogenous packet switching networks. TCP/IP is the current
standard (and required) protocol to be used on all DOD packet
switching networks. The TCP/IP implementation used in release 6 is
based on the TCP/IP software developed by Bolt, Beranek, and Newman
(BBN) under contract the the Defense Advanced Research Projects
Agency (DARPA).
The ARPANET uses the Interface Message Processor (IMP) as the primary
backbone processors of the network. The IMP is responsble for
delivering messages sent from a source host on the network to the
specified destination host. At this time the IMPs provide an orderly,
reliable, and flow controlled communications path on the ARPANET.
The DECSYSTEM20 interfaces to the IMP via the AN20 (AKA AN10)
hardware interface. The AN20 provides the requried control signals
and a bit serial data stream. The AN20 is capable of passing data to
and from the IMP at speeds in excess of 100Kb.
TOPS20AN interfaces to the IMP at the software level (as do all hosts
at this time) by using the 1822 Host/IMP interface protocol. The 1822
protocol provides for a simple flow control, status, and error
reporting mechanism. Datagrams from the IMP are received by the 1822
procotol modules and passed to the IP protocol modules.
Datagrams received by the IP modules are first checked for errors in
the IP header. IP options are processed and fragmented datagrams are
reassembled. The IP datagram is now passed to the TCP protocol
modules (or some other protocol above IP).
Datagrams received by the TCP modules from IP are first checksumed to
check for data errors. TCP options are also processed. If everything
is correct the data in the TCP message is acknowledged and the data
is passed to the user.
User data is sent via TCP/IP in much the same way as it is received,
except that the protocol transisitions are reversed. Data is passed
from the user the the TCP modules. The TCP modules checksum the data
and encapsulate it with TCP headers. The message is then passed to
the IP modules where the messsage may be fragmented into several
datagrams to faciltate transmission through he various nettwork
interfces. The message is encapsulated within the IP header (which
includes various IP options). The message is then passed to the 1822
protocol layers for transmission to the IMP and the rest of the
ARPANET.
"TCP/IP Implementation Notes"
The TCP/IP software is implemented is much the same manner as the
older NCP (Network Control Protocol) ARPANET software. NCP was used
up until release 6 of TOPS-20AN.
Very little of the TCP/IP software runs at interrupt level. The only
code running at interrupt level (currently PI channel six) is the
device driver for the AN20. The AN20 is capable of both input and
output at the same time independently of eachother. The AN20 uses two
device codes. ANI is the input side of the AN20 and is device code
520. ANO is the output side of the AN20 and is device code 524.
The TCP/IP was developed to be able to interface to more than one
network interface. At this time we support one and only one interface
and the interface we support is to the ARPANET via an AN20. The
interrupt instructions for the AN20 are find in the NCT for the AN20
interface. Since we only support one NCT the AN20 has the only NCT.
The AN20 NCT begins at the symbol ".NCT0". The definintions for the
offsets in the NCT are found in the ANAUNV module.
Most of the TCP/IP activity occurs in an asynchrous monitor context
fork called the internet fork. INTFRK contains the FORKX of the
internet fork. The INTFRK uses UPDL for its stack space. The INTFRK
is made up of several "processes". The INTFRK "processes" are not
separate forks but instead resemble coroutines. The current
"processes" are as follows:
Name Handle Description
---------------------------------------------------------------------
Background BG The background process is used to perform
various background tasks such as the creation
of buffers, interface state checks, and
gateway pinging.
Delayed Action DY The delayed action process is used to perform
various random tasks that are not gauranteed
to be performed in other places. Tasks
include the scanning for dead (and currently
unused connection blocks.
Input Processor IP The input processor is used to process
incoming IP datagrams destined for TCP. The
IP performs TCP message processing.
Packetizer PZ The packetizer is used to output TCP
messages. The TCP messages are transformed
into IP datagrams and queued for output to
the IMP via the 1822 software. The packetizer
is also responsible for the acking of TCP
messages from the host at the other end of
the TCP connection. The packetizer is also
responsible for sending flow control (window
information) to the host at the other end of
a connection.
Reasembler RA The reasembler is used to reasemble
fragmented IP datagrams into complete
datagrams before being processed by TCP.
Retransmitter RX The retransmitter is used to retransmit TCP
messages which may have gotten lost or
dropped in the network. TCP will
automatically retransmit message until the
are acking.
"ARPANET 1822 Host to Imp Message with TCP/IP Message Header Formats"
-------------------------------------------------------------------
0|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|2|3
0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1
-------------------------------------------------------------------------
1822 | MBZ |Format | Dest. Net. MBZ| MBZ |T|Flags| Message Type | 0
-----------------------------------------------------------------
H to I | Handling Type | Dest. Host | Destination IMP | 1
-----------------------------------------------------------------
Leader | Message ID. |Subtype| Message Length | 2
===========================================================================
|Version|Hdr Len|Type of Service| Total Length of Datagram | 0
-----------------------------------------------------------------
Inter- | |M|D|M| |
net | Datagram Identifier |B|F|F| Fragment Offset | 1
| |Z| | | |
Data- -----------------------------------------------------------------
gram | Time to Live | Protocol | Header Checksum | 2
-----------------------------------------------------------------
Header | Source Host Address | 3
-----------------------------------------------------------------
Format | Destination Host Address | 4
-----------------------------------------------------------------
| Protocol Options | Padding | 5
=============================================================================
| Source Port | Destination Port | 0
Trans- -----------------------------------------------------------------
Mission | Sequence Number | 1
-----------------------------------------------------------------
Control | Acknowledgment Number | 2
-----------------------------------------------------------------
Proto- | Data | |U|A|P|R|S|F| |
col |Offset | Reserved |R|C|S|S|Y|I| Flow Control Window | 3
| | |G|K|H|T|N|N| |
Header -----------------------------------------------------------------
| Checksum | Urgent Pointer | 4
Format -----------------------------------------------------------------
| Transmission Control Protocol Options | Padding | 5
=============================================================================
| data | 0
-----------------------------------------------------------------
| data | 1
Message -----------------------------------------------------------------
| data | .
Data -----------------------------------------------------------------
| data | .
-----------------------------------------------------------------
| data | n
=============================================================================
0|0|0|0|0|0|0|0|0|0|1|1|1|1|1|1|1|1|1|1|2|2|2|2|2|2|2|2|2|2|2|3
0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1
"ARPANET TCP/IP Protocol Layerings"
---------------------------------
_________________________
| User Level Protocols |
| eg. TELNET, FTP, SMTP |
----------\||/-----------
||
______/||\________ ___________________ __________________
| Transmission | | Internet | | Gateway to |
| Control | | Control Message | | Gateway |
| Protocol (TCP) | | Protocol (ICMP) | | Protocol (GGP) |
------\||/-------- --\||/------------- ------\||/--------
|| || __________________||
|| || |__________________|
|| || ||
__/||\___________/||\__/||\_
| Internet Protocol (IP) |
----------\||/--------------
||
_______/||\_________
| IMP Interface |
| (1822 Protocol) |
--------------------
"ARPANET Protocol Specification Documents"
----------------------------------------
ARPANET protocol specifications are available from the ARPANET
Network Information Center (NIC) at the following mail address. The
protocols are also available online on the NIC's system (SRI-NIC
10.0.0.73) in the <NETINFO> directory. Most ARPANET protocols
documents are refered to as "Request for Comments" (RFC).
Network Information Center
SRI International
Menlo Park, CA 94025
ARPANET mail address: NIC@NIC
The following documents specify ARPANET the most common TCP/IP
Protocols:
Specifications for the Interconnection of a Host and an Imp (1822).
BBN Report No. 1822. This document specifies the electrical
and software requirements for interfacing a host to an IMP.
Internet Protocol (IP).
RFC-791. This document specifies the DOD Standard Internet
Protocol. IP provides an internetwork datagram transmission
facility. IP is the backbone protocol of the Internet. IP
is layered above the physical data link level. In the case
of ARPANET the physical data link level protocol (and
electrical specification) is 1822.
Internet Control Message Protocol (ICMP).
RFC-792. This document specifies the DOD Standard Internet
Control Message Protocol. ICMP is used by destination hosts
and gateways to notify other hosts of anomalies in IP
datagram processing. ICMP is layered above the IP protocol.
User Datagram Protocol (UDP).
RFC-768. This document specifies the DOD Standard User
Datagram Protocol. UDP is used to implement a service
whereby users can send and receive datagrams for an
apllications which does not require the gauranteed orderly
delivery of messages that the TCP provides. UDP is layered
above the IP protocol.
Transmission Control Protocol (TCP).
RFC-793. This document describes the DOD Standard
Tranmission Control Protocol. TCP provides a very high
reliability host to host level protocol for the Internet
environment. TCP provides for data verification
(checksumming), flow control, and ordered delivery of user
data. TCP is layered above the IP protocol.
Telnet Protocol Specification (TELNET).
RFC-764. This document describes the DOD Standard Telnet
protocol. The TELNET protocol is used to provide a general,
eight bit byte, bidirectional communications facility. The
primary use of the TELNET protocol is to provide a standard
method of interfacing Internet systems for remote terminal
service. The TELNET protocol is layered above the TCP
protocol.
File Transfer Protocol (FTP).
RFC-765. This document describes the DOD Standard File
Transfer Protocol. The objective of FTP is to provide a
facility for sharing programs and data in a file format
between the various Internet hosts. The File transfer
protocol is layered above the TCP protocol.
Simple Mail Transfer Protocol (SMTP).
RFC-788. This document describes the DOD standard Simple
Mail Transfer Protocol. The objective of the SMTP protocol
is provide for the reliable and efficient transfer of
electronic computer mail between hosts on the Internet. The
SMTP protocol is layered above the TCP protocol.
+---------------+
! d i g i t a l ! I N T E R O F F I C E M E M O R A N D U M
+---------------+
DATE: 26-Sept-1983
TO: TOPS20 Group
FROM: Kevin W. Paetzold
DEPT: LCG S.E.
DTN: 231-7420
LOC: MRO1-2/L10
FILE: TCPIP-SPEC.MEM
SUBJ: Functional Specification - Release 6 TCP/IP Support
1.0 Introduction
The following describes the Release 6.0 TOPS-20AN support for
the ARPANET Transmission Control Protocol (TCP) and the ARPANET
Internet Protocol (IP). It is assumed the reader is familiar with the
following documents:
2.0 References
The following documents specify the DOD Standard TCP/IP
protocols. The documents are available in the directory
GIDNEY::RANDOM:<SPECS.ARPA>.
1. "Internet Protocol", RFC791.
2. "Internet Control Message Protocol", RFC792.
3. "Transmission Control Protocol", RFC793.
4. "Telnet Protocol", RFC764.
5. "Assigned Numbers", RFC820.
6. "Service Mappings", RFC795.
7. "Address Mappings", RFC796.
8. "Specification for the Interconnection of a Host and
an IMP - BBN Report No. 1822".
Release 6.0 ARPANET TCP/IP Functional Specification - Page 2
3.0 Protocol Overview
The 1822 protocol is used for communication between the TOPS-20
Monitor and the ARPANET Internet Message Processor (IMP). The 1822
protocol used for communicating with the IMP has not changed
significantly for support of TCP/IP (versus NCP).
The Internet Protocol (IP) is a new protocol used to provide
internetwork datagram service in heterogenous packet switching
network environment. The IP supports many protocol fields and options
to control datagram lifetime, datagram routing, and multiple higher
level protocol support.
The Internet Control Message Protocol (ICMP) is used to provide
host gateway control communication, simple host gateway flow control,
and IP level error reporting. The ICMP is also layered above the IP
layer.
The Transmission Control Protocol (TCP) is a new protocol used
in the ARPANET environment to provide a reliable host to host virtual
circuit tranmission facility. The TCP is layered above the IP layer.
The TCP provides data verification, flow control, and sequencing
facilities.
The TELNET protocol is used to provide remote terminal service
and has not changed. The NCP versions of TOPS20AN supported two
TELNET protocols (the "old" and the "new" TELNET protocols). The old
telnet protocol has been removed. The Telnet protocol is layered
above the TCP protocol.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 3
The following diagram shows the relationship and layering of the
ARPANET protocols:
.-----------------.
| Telnet Protocol |
`\||/-------------'
|| .--------------.
|| | Customer |
|| | Defined |
|| | Applications |
|| `------\||/----'
|| ||
./||\--------/||\.
| Transmission |
| Control |
| Protocol (TCP) |
`-----\||/-------'
||
./||\--------------------------------------.
| Internet Protocol (IP) |
|------------------------------------------|
| Internet Control Message Protocol (ICMP)|
`\||/--------------------------------------'
||
.-----/||\---------.
| IMP Interface |
| Via KL AN20 |
| (1822 Protocol) |
`------------------'
Release 6.0 ARPANET TCP/IP Functional Specification - Page 4
4.0 Removal of NCP Support
The current ARPANET software (release 5.1) in the TOPS-20AN
monitor supports the old Network Control Protocol (NCP). There is no
longer any need for the support of NCP in an ARPANET environment and
its support in the monitor has been removed. This means that the
"NET:" device will not be supported in release 6.0 and will be
removed. Also the GTNCP%, CVSKT%, CVHST%, and FLHST JSYS' will be
removed. The GTHST% JSYS will be the only NCP era ARPANET JSYS which
will remain in monitors after release 6.0.
The only remaining ARPANET related GETAB% table will be the
NETRDY table. The following GETAB% tables were required for support
of the NCP software and have been removed: GNTFSK, HOSTN, HSTSTS,
HSTNAM, IMPHRT, IMPLT1, IMPLT2, IMPLT3, IMPLT4, NETAWD, NETBAL,
NETBTC, NETBUF, NETLSK, NETSTS.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 5
5.0 Required SYSTEM: files
The SYSTEM:HSTNAM.TXT files and the SYSTEM:HSTNAM.MULTINET files
are no longer required to be in the SYSTEM: area. These files
supported the NIC host table format from the NCP "era".
The following files are required to be in SYSTEM:. The
SYSTEM:HOSTS.TXT file contains information about the names of the
defined INTERNET hosts. The SYSTEM:INTERNET.GATEWAYS file contains
information about the various networks (and their gateways) connected
to the INTERNET. The SYSTEM:SITE-ADDRESS.TXT file contains
information about the INTERNET address and interface of the customers
system. The SYSTEM:SITE-ADDRESS.TXT file replaces the "HOST" keyword
in the X-CONFIG.CMD file read by SYSDPY. The SYSTEM:SITE-ADDRESS.TXT
file must be updated for the address of the customers HOST.
The SYSTEM:INTNERNET.GATEWAYS and SYSTEM:HOSTS.TXT files are
available from the ARPANET Network Information Center (NIC). Sites
installing ARPANET with TCP/IP support should be sure to obtain the
most recent versions of these files from the NIC.
The following is an example SYSTEM:SITE-ADDRESS.TXT file. Each
site should change the address (following the "AN20#0," to correspond
to the Internet address for the site. The address of DEC-TOPS20 is
10.0.0.79.
;;; SITE-ADDRESS file for host DEC-TOPS20
AN20#0, 10 0 0 79,NCP,PACKET-SIZE:1004,LOGICAL-HOST-MASK:0 0 255 0
Release 6.0 ARPANET TCP/IP Functional Specification - Page 6
The following is an example of the SYSTEM:INTERNET.GATEWAYS file.
; Created by DYER on 25 February 1983 18:58-PST
; Derived from HOSTS3 format file:
; DSK:<DYER>HOSTS.TXT version 261
; Compiled by DYER at 830225-185538
; Canonical version [SRI-NIC]<NETINFO>INTERNET.GATEWAYS
; Send additions or corrections to DYER@SRI-NIC
CREATED 25 FEB 1983 1858-PST
; GW/PRIME Internet Gateways. These speak full GGP.
PRIME 1 0 0 11, 3 0 0 62
PRIME 10 0 0 38, 9 0 0 11
PRIME 10 0 0 94, 192 5 2 6
PRIME 10 1 0 20, 21 0 0 2
PRIME 10 1 0 20, 4 0 0 24
PRIME 10 1 0 49, 128 11 0 1
PRIME 10 3 0 72, 3 3 0 8
PRIME 10 3 0 80, 47 0 0 11
PRIME 11 1 0 0, 128 16 0 0
PRIME 4 0 0 60, 32 3 0 42
PRIME 4 0 0 60, 35 7 0 0
; GW/DUMB gateways do not speak GGP, but are OK to use
DUMB 10 0 0 77, 18 8 0 4
DUMB 10 5 0 49, 4 0 0 30
DUMB 21 0 0 3, 28 10 0 0
; GW/ALWAYS-UP gateways. Basically dumb, but will not respond to a ping.
ALWAYS-UP 10 1 3 51, 28 11 0 0
ALWAYS-UP 10 3 0 29, 192 5 21 5
; Host IP/GW gateways. Use only as a last resort.
HOST 10 1 0 54, 192 5 7 2
HOST 10 3 0 49, 3 3 0 49
Release 6.0 ARPANET TCP/IP Functional Specification - Page 7
6.0 JFN JSYS Interface
The major goal of the TCP interface is to be consistant with the
other TOPS-20 network interfaces. The existing TCP interface as
developed by Bolt Beranek and Newman (BBN) is not consistant with the
"TOPS-20 way of doing things".
The new TCP interface will use the standard TOPS-20 JSYS' for
most functions. Any TCP specific functions will be accessable through
a new JSYS (TCOPR%) specifically designed for TCP.
The programmer using the TCP interface must provide information
to the operating system about the virtual connection information as
well as various parameters dealing with the type and quality of
service required. Connections are established using the GTJFN% and
OPENF% JSYS'. Input and Output is performed with the BIN%, BOUT%,
SIN%, SOUT%, SINR%, SOUTR%, and TCOPR% JSYSi. Status information is
obtained from the TCOPR%, SOBE%, SOBF%, and GDSTS% JSYS.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 8
6.1 GTJFN% JSYS
The GTJFN% JSYS is used to obtain an indexable file handle on a
TCP connection. The format of the GTJFN% JSYS call for TCP is the
same as for any other GTJFN% call (see the TOPS-20 JSYS reference
manual). The file name string for a TCP GTJFN% specifies data about
the desired connection. This format is similiar to the formats used
in GTJFN% calls for DECNET and the ARPANET NCP.
The format for the GTJFN% file specification is as follows:
TCP:[LOCAL_HOST-][LOCAL_PORT[#]] (continued...)
.[FOREIGN_HOST-][FOREIGN_PORT][;A1..][;A2..]
Bracket pairs indicate optional parameters. This does not
indicate the parameters are always optional. It does indicate that
not all parameters must be supplied at all times.
"TCP:" indicates that this JFN will be associated with TCP (not
unlike "NET" for ARPANET NCP and "DCN:/SRV:" for DNA).
"LOCAL_HOST-" specifies the local host address for this
connection. This is usefull for hosts which have multiple local
addresses (multihoming). This field will default to the ARPANET
address of the local host. This field may be specified using the
alphanumeric host name (eg. DEC-MARLBORO) or the octal host number
(eg. 1200200117, NOT decimal and NOT the aaa.bbb.ccc.ddd format). The
"-" after the host name is required to delimit between the host
name/number and the port number. The "-" is required even if the port
number is omited.
"LOCAL_PORT" specifies the local port number to be used for this
connection. The port number specified is in decimal (not octal). This
field is optional. Port numbers are in the range 1:65535. Ports in
the range 1:255 are special ports which require special priviledges
in order to be assigned. The "#" (in reality a "^V#") must be
appended to a port in the range of 1:255 and in the range of
32768:65535 to prevent accidental assignment. Ports in the range
256:32767 are reserved for users. Ports in the range 32768:65535 are
assigned on an as need basis as default port numbers. If no local
port is specified a number in the range 32768:65535 will be assigned.
A local port in the range 1:255 will require SC%WHL, SC%OPR, SC%NAS,
or SC%NWZ priviledges.
The "." is a delimitor separating the local host connection
values from the foreign host connection values.
"FOREIGN_HOST-" is used to specify the specific foreign host
that this connection is destined for. It is an optional field. If the
FOREIGN_HOST is not specified any host using any port is allowed to
connect to this connection. This is most usefull for system servers.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 9
"FOREIGN_PORT" is used to specify the foreign port that this
connection is destined for. If this field is omited any foreign port
will be allowed to connect to this connection.
";A1.." and ";A2.." are used to specify various attributes that
this connection will use. The valid attributes are detailed below.
A GTJFN% for any valid host name/port pair is allowed. Checking
for conflicts with other connections does not occur until the OPENF%
is performed. A GTJFN% for the same local parameters with wild
foreign parameters is legal.
6.1.1 GTJFN File Specification Attributes
;CONNECTION:ACTIVE
;CONNECTION:PASSIVE
This attribute is used to indicate if the operating system
should actively connect to the foreign system. The default is
ACTIVE.
;PERSIST:n ;PERSIST:(n,m)
With an argument of 0, attempt to open the connection and
keep trying until successful. If n is given, try for n seconds,
at which time an error return is given if no connection has been
established. An attempt is made every m seconds, where m is an
estimate of the round trip delay between systems or provided by
the user. If no persistence is given, 30 seconds will be used.
The default for "n" is 30 seconds and the default for "m: is 5
seconds.
;TIMEOUT:n
The amount of time allowed to pass while waiting for a
message from the foreign system before an error is given to the
user. If not given, a default 30 seconds will be used. If the
value of n is 0, no timeout will occur. N may be in the range of
0 to 2^18-1.
;TYPE-OF-SERVICE:n
The type of service required by the user indicates what
tradeoffs are to be made in providing data transmission. N may
be in the range of 0 to (2^18-1). The TCP implementation will
only use the low order 8 bits. This attribute is not used by TCP
but is used by the IP layer underneath. Values other than zero
require SC%NWZ, SC%WHL, or SC%OPR priveledges. The default value
is zero.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 10
;SECURITY:n
The security field of the connection is a sixteen (16) bit
number. The values are described in the Internet Protocol (IP)
specification. If this value is omitted the system default level
will be used. The system default level is set via the .TCSDSL
function of the TCOPR% JSYS. The system default security level
is normally zero. This attribute is not used by TCP but is used
by the IP layer underneath.
;COMPARTMENTS:n
The COMPARTMENTALIZATION of the connection is a sixteen
(16) bit number. If not specified a value of zero is used. The
meaning of this field is described in the Internet Protocol
specification. This attribute is not used by TCP but is used by
the IP layer underneath.
;HANDLING-RESTRICTIONS:n
The HANDLING RESTRICTIONS option of the connection is a
sixteen (16) bit number. The meaning of this field is described
in the Internet Protocol specification. This attribute is not
used by TCP but is used by the IP layer underneath.
;TRANSMISSION-CONTROL:n
The TRANSMISSION CONTROL option of the connection is a
twenty-four (24) bit number. The meaning of this field is
described in the Internet Protocol specification. This attribute
is not used by TCP but is used by the IP layer underneath.
;LOCAL-HOST:a.b.c.d
The LOCAL-HOST attribute is an alternate way to specify the
thirty-two (32) bit local host number. "a", "b", "c", and "d"
are decimal octets forming the host number. The "." is a
required delimitor. A field of zero must be represented as zero.
;FOREIGN-HOST:a.b.c.d
The FOREIGN-HOST:a.b.c.d attribute is an alternative way to
specify the thirty-two (32) bit foreign host address.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 11
6.1.2 GTJFN File Specification Examples
The following are valid examples of GTJFN% strings for the
"TCP:" device.
"TCP:1200200117-12345.1200000117-54321" specifies a connection
from DEC-MARLBORO port 12345 to DEC-2136 port 54321.
"TCP:4500000121-23456.1200000117-65432" specifies a connection
from the DECNET side of DEC-MARLBORO port 23456 to DEC-2136 port
65432.
"TCP:DEC-2136-32145.DEC-MARLBORO-21211" is the same as
"TCP:32145.DEC-MARLBORO-21211" is the same as
"TCP:32145.1200200117-21211" (assuming the local host is DEC-2136).
"TCP:27#" specifies a connection "listening" for a connection on
port 27 (decimal 23). This connection will allow any foreign host
with any port to connect.
"TCP:27#.DEC-2136-" specifies a connection "listening" for a
connection from DEC-2136 on any port.
"TCP:27#.2345" specifies a connection "listening" for a
connection on port 2345 from any host.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 12
6.2 OPENF% JSYS
The OPENF% JSYS is used to force the TOPS-20 monitor to initiate
the connection. The OPENF% JSYS call is issued after a GTJFN% call.
Many parameters pertaining to this connection may also be set via the
TCOPR% JSYS. Some parameters (eg. Security levels) must be set before
the OPENF% JSYS is issued. The format of the OPENF% JSYS call for TCP
is the same as for other devices.
The only byte sizes (AC2 B0:B5) currently supported at eight (8)
and thirty two (32) bit bytes. All TCP data transfers are made with
eight bit bytes. Thirty two (32) bit mode is only provided as an easy
way to lower byte instructions required for data transfer. TCP
connections are full duplex. OF%RD and OF%WR are ignored.
6.2.1 OPENF JSYS IO Modes
Several data modes are supported (AC2 B6:9). The modes supported
correspond to the modes used in the OPENF% JSYS call for the ARPANET
NCP interface.
Mode Description
---------------------------------------------------------------------
.TCMWI (1) Interactive mode. Wait for connection to be fully
open before returning from the OPENF% JSYS. Wait for
the connection to be fully closed before returning
from the CLOSF% JSYS. Send all bytes as soon as
possible (ie. Send data after each SOUT% or BOUT).
This mode attempts to give the most "interactive"
response possible by sending many small messages.
.TCMWH (2) High throughput mode. Same action as mode zero for
OPENF% and CLOSF%. Hold data in local buffers until
accumulated bytes are sufficient for efficient
transmission, or until transmission is requested with
the TCOPR% or SOUTR% JSYS. The mode attempts to give
high throughput at low overhead by sending large
messages.
.TCMII (3) Immediate return mode. Return to user program
immediately without waiting on a OPENF% or CLOSF%
JSYS. Send all bytes as soon as possible (interactive
mode).
.TCMIH (4) Buffered Immediate return mode. Same as mode 1 except
that OPENF% and CLOSF% return immediately.
6.2.2 OPENF JSYS Connection Rules
In TCP a connection is identified by both the foreign port and
the local port. Two connection from system A to system B are allowed
to have the same local ports or the same foreign ports but not the
same local and foreign ports. A connection using a default local port
will always be different from any other connection using a default
local port (because of the way default local port numbers are
assigned). Wild connections (ie. a connections which will allow any
foreign host and/or foreign port) may be duplicated in multiple JFNs
(in this job or other jobs).
Release 6.0 ARPANET TCP/IP Functional Specification - Page 13
6.3 BIN, BOUT, SIN, SOUT, SINR%, SOUTR% JSYS'
The BIN% and BOUT% JSYSi have the same functionality and calling
sequences for the TCP device as for other devices. BIN% will read a
single byte and BOUT% will send a single byte.
The SIN% and SOUT% JSYSi have the same functionality and calling
sequences used with other devices. SIN% will read a stream of bytes
and SOUT% will send a stream of bytes.
The SOUTR% JSYS has the same functionality as the SOUT% JSYS
with one addition. The SOUTR% JSYS will set the TCP PUSH flag for the
last message generated by this call. This will also force all data
currently held in local buffers to be sent immediately.
The SINR% JSYS has the same functionality as the SIN% JSYS with
one addition. The SINR% JSYS will return when a TCP message with the
PUSH flag is received. The SINR% will also return when the byte count
is exhausted.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 14
6.4 SOBE and SOBF JSYS'
The SOBE% and SOBF% JSYSi have the same functionality and
calling sequence for the TCP device as with other devices. The SOBE%
and SOBF% JSYSi are documented in the TOPS-20 JSYS Reference Manual.
6.5 GDSTS JSYS
The GDSTS% JSYS is used to obtain the status of a given
connection. The TCOPR% JSYS may also be used for this purpose. The
GDSTS% JSYS is implemented for completeness. GDSTS% accepts the JFN
of the connection in AC1. The current status of the specified
connection is returned in AC2. The send side status is returned in
the left half and the receive side status is returned in the right
half. The states are documented in the .TCTCS word of the .TCRCS
function of the TCOPR% JSYS. The foreign host number is returned in
AC3. The foreign port number is returned in AC4.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 15
6.6 GTHST% JSYS Additions
The GTHST% JSYS has two additional functions. Documentation of the
new functions follows:
Code Symbol Function
-----------------------------------------------------------------------
6 .GTHLN Returns hostnumber of this host on an Internet network.
AC2: Network number, or host number on a network.
Returns+1 if host has no address on specified network.
Returns+2 if host has address on specified network.
AC2: Host number on specified network.
7 .GTHNT Get status of an Internet Network.
AC2: Network number, or host number on a network.
AC3: Address of location to store data.
AC4: -Number of words,,Offset of first word of data
Returns+1 if no such network or invalid offset.
Returns+2 if valid network and arguments.
Offset Description
-----------------------------------------------------------------------
0 Interface status. 0 means down, >0 means going down, and <0
means up.
1 Desired Interface status. 0 means off, <0 means on, >0 means
cycle.
2 Network has an unreported state change if >0.
3 Network has output enabled if -1.
4 Time and Date last time network was cycled.
5 Time and Date last time network went off.
6 Time and Data last time network came on.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 16
6.7 TCOPR% JSYS
TCOPR% JSYS - Transmission Control Protocol Operations
The following are the TCOPR functions related to the TCP: device.
These functions are like the MTOPR JSYS, but are only used with the
TCP device.
ACCEPTS AC1: JFN of connection
AC2: function code (see below)
AC3: function argument or address of argument block.
See each function for details.
RETURNS +1 always
Symbol Meaning
.TCSUD Send urgent data. AC3 points to a block of
the form
0 Pointer to data
1 Count of bytes or 0
2 Byte to terminate output on
(note that these are the same as AC2 - AC4 of
the SOUT and SOUTR JSYS's)
.TCPSH Cause all local buffered data to be sent
immediately. Also set the TCP PUSH flag
for the last message of the data being
sent.
.TCSPA Set passive/active flag. TC%APF is set in
AC3 to indicate an active connection, and
cleared to indicate a passive connection.
.TCSPP Set persistence parameters. AC3 is the time
to wait for connections.
If AC3 is 0, do not timeout the connection.
If AC3 contains 0,,n an attempt to connect
will be made for n seconds with
retransmission time estimated by the system
If AC3 contains m,,n an attempt to connect
will be made for n seconds with
retransmission every m seconds. M must be
less than n.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 17
.TCSTP Set timeout parameters. AC3 contains the
time to wait before a timeout. The value
given must be in the range of 0 to 2^18-1.
If AC3 contains a 0, no timeout will occur.
.TCSTS Set Type-of-service. AC3 contains the type
of service desired. The value must be in the
range of 0 to 2^18-1. TCP will only use the
low order eight bits. The values are described
in the Internet Protocol specification.
.TCSSC Set security and compartment levels. AC3
contains the security level and the
compartment levels in the form
(security),,(compartment)
Security and compartment are sixteen bit numbers
described in the Internet Protocol specification.
.TCSPC Set PSI channels. AC3 contains four 6 bit
fields as follows
TC%TPU 1st byte, Urgent data channel
TC%TER 2th byte, Error channel
TC%TSC 3th byte, State change
TC%TXX 4th byte, unused, must be 77 (octal)
To indicate that no interrupt is desired for
a given function, specify the value 77
(octal) for the channel.
.TCRTW Read a single entry from the TCB. AC3
contains the word of the TCB that is desired.
On return, AC3 will contain the value of the
word in question.
For a list of the words that may be returned,
see the function .TCRCS.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 18
7.0 I/O Interelationships
This section describes the relations of various monitor calls
which relate to performing I/O for a TCP device.
First, the user may execute a TCOPR JSYS to set various fields
within the transmission control block (TCB). Some of these functions
are allowed only before the OPENF.
If the user has enabled for PSI interrupts on state changes, an
interrupt will be given the user every time the state of the
connection changes.
If the user has enabled interrupts for URGENT data, an interrupt
will be given to the user each time the urgent data pointer is
increased, that is, we have been notified of more urgent data than we
previously knew about. If the user has not read all of the previous
urgent data, the interrupt will still be sent.
If the user has enabled interrupts for errors, a PSI interrupt
will be given under the following conditions:
1. A timeout has occured (either in communications,
or in opening the channel).
2. An ABORT or RST (reset) message was received.
At any time, a SIBE will return the number of unread bytes
available to the user, i.e. those bytes which have been acknowledged.
This is not the receive window size. To determine the size of the
receive window, the program must use a TCOPR JSYS.
If the user executes a JSYS which will cause output or input to
occur the user will block until the connection is established and the
data specified by the JSYS is moved into the monitor, or an event
which will cause the user to be notified of an error occurs.
A SOBE or SOBF will return the number of bytes which are in the
output buffer, i.e. the number of bytes which are have not been
acknowledged by the foreign host.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 19
8.0 Message Retranmission
This section describes the data retransmission parameters, Alpha
and Beta.
The functions used provide an "elongation factor" or delay
variance, Alpha, as well as an exponential smoothing function with
weighting of Beta. Assume the following:
RTT is the delay between the sending of an octet and the ACK for
that octet.
SRTT is the exponentially weighted round trip delay.
UBND is the upper bound for data retransmission.
LBND is the lower bound for data retransmission.
RTO is the retransmission timeout for this data set.
SRTT may be calculated from the following.
SRTT = ( Beta * SRTT ) + ( ( 1 - Beta ) * RTT )
RTT and SRTT are initially set to an estimated delay time. The
retransmission time out, RTO, may be calculated as follows:
RTO = max ( LBND, min ( UBND, Alpha * SRTT ))
By default, the lower bound, LBND, will be set to 1 second and
the upper bound, UBND will be set to 250 seconds. These values may be
changed with the .TCSLB and .TCSUB functions of the TCOPR% JSYS. Beta
must be in the range of 0.0 to 1.0. It will initially be set to 0.9.
Alpha must be in the range of 0.0 to 250.0. The default value for
Alpha is 1.5. Although numbers less than 1.0 and larger than 10.0 are
fairly useless, they are allowed.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 20
9.0 Internet Protocol JSYS Interface Introduction
The Internet Jsyses provide a facility for user programs to send
and receive Internet packets. SC%NWZ capability is required for use
of the Internet Message Queues. The Internet Message Queues provide a
service not unlike the IMP special queue facility. The Internet
Message queue facility allows the user to interface at the IP level
instead of the 1822 level.
9.1 Internet Protocol JSYS Interface Description
In order to use the Internet calls a program must first assign
an Internet Queue using ASNIQ%. The arguments for this JSYS are a set
of mask and value words that determine what messages may be sent and
which of the incoming messages will be delivered to the owning job. A
successful ASNIQ% returns with a handle (a small number, short-hand
for the queue), in T1 which is then given to SNDIN%, RCVIN%, and
RELIQ%. In addition ASNIQ% returns the maximum buffer size acceptable
to SNDIN% in T2 if the assignment is successful.
The arguments for SNDIN% are an Internet Queue Handle and a
pointer to a buffer of data in the caller's space. Word-0 of this
buffer is the size (in words) of the buffer, including this count
word. Words 1 through 5 must have a Version 4 Internet Header (see
last page). Various fields of the header are checked for legality,
the source host word is filled in, and the Internet header checksum
inserted. A network interface is then selected and a local leader for
that network is constructed in the packet. The packet is then queued
for output on that interface and SNDIN returns.
RCVIN% takes the same arguments, an Internet Queue Handle and a
buffer pointer (the right half of word-0 is the maximum length of the
buffer including the count word). Normally, if no messages are
already waiting on the queue, RCVIN% waits. This wait can be defeated
by turning on the "don't wait" control bit (RIQ%NW) which forces an
error return (error code -1) if no messages are waiting. When a
message is available, it is placed into the user supplied buffer. The
number of words filled is set into the left half of word-0 (the count
word) of the buffer. Ordinarily this can be ignored, but if the
message was too big for the buffer, this tells how much space would
have been required.
When finished, the queue handle can be released by using RELIQ%.
All handles owned by the job may be released by supplying -1 as the
argument.
All Internet Jsys calls use only the LEFT 32 bits of each word.
This is true of both the ASNIQ% argument block and of data buffers.
Messages left waiting on an input queue for a long time
(currently 30 seconds) will be deleted. Also, the number of messages
which will be placed into a queue is limited (currently 8). Flooding
the input queue of a slow receiver will result in dropped messages.
(Note that these monitor assembly parameters may vary from site to
site.)
Release 6.0 ARPANET TCP/IP Functional Specification - Page 21
Messages addressed to the sending host will ordinarily be
delivered without sending over any network at all and are reasonably
fast.
User programs have no control over which network a given message
will be sent out over. This decision will be made by the host gateway
module on the basis of routing information supplied to it by other
Internet gateways. This means that all networks to which a host is
connected must go down before Internet communications will be
completely stifled, and even then, processes within a host will be
able to communicate due to the local delivery mechanism.
Programs using Internet messages must be aware that messages are
not necessarily delivered in the order in which they were sent, some
messages may be dropped and others duplicated. Some may traverse a
broadcast network and be clobbered by other packets, lightning, flaky
intermediate gateways, etc. Thus, some higher level protocol is
needed in most cases. TCP is one example, but there are others (the
"Datagram Protocol", XNET, etc.).
If a particular protocol is implemented in the monitor (e.g.
ICMP, TCP) and that protocol module is turned on, no messages of that
protocol type will be passed to users via Internet queues. Assigning
a queue will still be possible, but no traffic will reach the user
unless that protocol module is disabled.
Not all Internet protocols have ports. If you are implementing
one which does not, be sure that .IQPTM in the ASNIQ block contains a
zero. If the protocol uses both local and foreign ports, they are
expected to be in the first two 16-bit bytes following the Internet
header, source port in leftmost 16 bits and destination port in the
next 16 bits. The location of this word is found by adding the
contents of the Internet data offset field to the address of the
zeroth word of the Internet header.
Provision has been made for protocols such as XNET which have
only a local port. Turning on the AQ%SPT control flag for ASNIQ
selects single port mode. The first 16-bit byte following the
Internet header is expected to contain the port. This port is used
both for demultiplexing incoming packets and for checking access when
packets are being sent.
Note that for a given set of addresses and protocol numbers,
etc., a single-port protocol queue will not be assigned if a
dual-port version already exists, and vice versa. This rule permits
an incoming packet to specify a unique queue. Without the rule either
the first or second 16-bit field following the Internet header would
have to be used for demultiplexing, but we could not know which
unless there was something else to tell which queue was being
addressed.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 22
The host may receive ICMP error messages relating to datagrams
for an Internet User queue. Normally these messages are discarded.
The user may, however, request that these datagrams be placed into
the input queue so that they may be read using RCVIN. To enable this
option, the AQ%ICM bit must be sepcified when the queue is assigned.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 23
9.2 ASNIQ% JSYS
ASNIQ% (JSYS 756) - Assign Internet Queue
1/ Flags,,Pointer to queue descriptor block
2/ (Unused, must be 0)
3/ (Unused, must be 0)
Ret+1: Failed. Error code in T1. Confliciting job number in T2.
Ret+2: Success. Internet queue handle in T1. Max. SNDIN count in T2.
Flags:
AQ%SPT Single-port protocol.
AQ%ICM Deliver ICMP error datagrams to this queue.
Queue Descriptor Block Format:
Offset Usage
.IQPRV Internet protocol number in bit 24-31. Others should be 0.
.IQFHV Internet foreign host value word in bits 0-31.
.IQSHV Internet source host value word in bits 0-31. Used for
logical host selection.
.IQPTV Internet port value word. Local port value in bits 0-15,
foreign port in 16-31. Foreign port bits ignored if AQ%SPT
("single-port" control flag) is set.
.IQPRM Mask word corresponding to .IQPRV.
.IQFHM Mask word corresponding to .IQFHV
.IQSHM Mask word corresponding to .IQSHV
.IQPTM Mask word corresponding to .IQPTV (Use 0 for portless
protocols.)
The mask words specify those bit positions where an exact match
is required. Thus, one can make .IQFHM contain 0 in order to talk to
all Internet hosts. Or by making say the low 3 bits of the local port
mask word be 0, one owns eight ports. Note that an error will result
unless the current queue descriptor block differs in the masked in
bits from all other Internet queues which are assigned at the instant
the ASNIQ is issued.
Possible errors:
NTWZX1 NET WIZARD capability required
ASNSX1 All Internet queues in use (or IP not initialized)
ASNSX2 Conflict with some other job (# in T2)
Release 6.0 ARPANET TCP/IP Functional Specification - Page 24
9.3 RELIQ% JSYS
RELIQ% (JSYS 757)
1/ An Internet Queue Handle or -1 for all or job process handle
2/ (Not used. Must be 0)
3/ (Not used. Must be 0)
Ret+1: Failed. Error code in T1.
Ret+2: Success.
RELIQ releases ownership of an Internet queue so that other jobs
can assign it. See the TOPS-20 Monitor Calls Reference Manual for a
description of the various process handles.
Possible errors:
SQX1 Internet queue handle out of range
SQX2 Internet queue not assigned
Release 6.0 ARPANET TCP/IP Functional Specification - Page 25
9.4 SNDIN% JSYS
SNDIN% (JSYS 754)
1/ Internet Queue Handle
2/ Pointer to buffer containing message
3/ (Not used. Must be 0.)
Ret+1: Failed. Error code in T1.
Ret+2: Success.
The buffer must contain a word count (including this word) in
the right-most 18 bits of word-0, a valid Internet header in the
left-most 32 bits of words 1 through 5, and possibly some data in the
left-most 32 bits of words 6 and following. If port filtering is
being used (.IQPTM was non-zero for ASNIQ), the port(s) must be
located in the word following the Internet header. The address of
this word is found by adding the address of word-1 in the buffer to
the number in the Internet data offset field.
The monitor fills in the source host field in the packet and
also the Internet header checksum. The rest of the header is supplied
by the user.
Possible errors:
SQX1 Internet queue handle out of range
SQX2 Internet queue not assigned
SNDIX1 Invalid message size
SNDIX2 Insufficient resources (No buffers available)
SNDIX4 Invalid header value for this queue
(Includes Internet Packet Length too big, Data
offset too small, filtering on ports but packet
length says packet does not contain a port word,
and header does not fit the ASNIQ arguments).
Release 6.0 ARPANET TCP/IP Functional Specification - Page 26
9.5 RCVIN% JSYS
RCVIN% (JSYS 755)
1/ Flags,,Internet Queue Handle
2/ Pointer to buffer where message will be put
3/ (Not used. Must be 0.)
Ret+1: Failed. Error code in T1.
Ret+2: Success.
Flags:
RIQ%NW On to cause fail return instead of waiting.
Each RCVIN gets one message from the named queue. These messages
match the values in the queue descriptor block when masked by the
mask words in the block. The maximum size of the buffer (including
the count word) is expected in the right-most 18 bits of word-0 of
the buffer when the RCVIN is executed. The number of words filled
plus one (counting the count word) is placed in the left-most 18 bits
of word-0 of the buffer. If the message was too big as determined by
the Internet data length field, as much as will fit in the buffer is
transferred and an error return given. No retry for the same message
is possible.
Possible errors:
SQX1 Internet queue handle out of range
SQX2 Internet queue not assigned
SNDIX1 Invalid message size
777777 means that RIQ%NW was on and no messages were waiting
Release 6.0 ARPANET TCP/IP Functional Specification - Page 27
9.6 IP Message Format
The following DEFSTRs show the format of the header words for an
IP buffer. The header words in a buffer sent or received via RCVIN%
or SNDIN% are supplied or must be supplied.
Word offsets:
.IPKVR==0 ; Word with version, type of service, etc
.IPKSG==1 ; Word with segmentation info
.IPKPR==2 ; Word with time to live, checksum, protocol
.IPKSH==3 ; Word with source host
.IPKDH==4 ; Word with destination host
DEFSTR(PIVER,PKTELI+.IPKVR,3,4) ; PACKET.IP.VERSION
DEFSTR(PIDO,PKTELI+.IPKVR,7,4) ; PACKET.IP.DATA-OFFSET
DEFSTR(PITOS,PKTELI+.IPKVR,15,8) ; PACKET.IP.TYPE-OF-SERVICE
DEFSTR(PIPRC,PKTELI+.IPKVR,10,3) ; PACKET.IP.PRECEDENCE
DEFSTR(PILDY,PKTELI+.IPKVR,11,1) ; PACKET.IP.LOW-DELAY
DEFSTR(PIHTR,PKTELI+.IPKVR,12,1) ; PACKET.IP.HIGH-THROUGHPUT
DEFSTR(PIHRL,PKTELI+.IPKVR,13,1) ; PACKET.IP.HIGH-RELIABILITY
DEFSTR(PIPL,PKTELI+.IPKVR,31,16) ; PACKET.IP.PACKET-LENGTH
DEFSTR(PISID,PKTELI+.IPKSG,15,16) ; PACKET.IP.SEGMENT-ID
DEFSTR(PIFLG,PKTELI+.IPKSG,18,3) ; PACKET.IP.FLAGS
DEFSTR(PIDF,PKTELI+.IPKSG,17,1) ; PACKET.IP.DONT-FRAGMENT
DEFSTR(PIMF,PKTELI+.IPKSG,18,1) ; PACKET.IP.MORE-FRAGMENTS
DEFSTR(PIFO,PKTELI+.IPKSG,31,13) ; PACKET.IP.FRAGMENT-OFFSET
DEFSTR(PITTL,PKTELI+.IPKPR,7,8) ; PACKET.IP.TIME-TO-LIVE
DEFSTR(PIPRO,PKTELI+.IPKPR,15,8) ; PACKET.IP.PROTOCOL
DEFSTR(PICKS,PKTELI+.IPKPR,31,16) ; PACKET.IP.HEADER-CHECKSUM
DEFSTR(PISH,PKTELI+.IPKSH,31,32) ; PACKET.IP.SOURCE-HOST
DEFSTR(PIDH,PKTELI+.IPKDH,31,32) ; PACKET.IP.DESTINATION-HOST
Release 6.0 ARPANET TCP/IP Functional Specification - Page 28
9.7 IPOPR% JSYS
IPOPR% (JSYS 760)
ACCEPTS AC1/ Function Code
AC2/ Function Dependent Argument
AC3/ Function Dependent Argument
RETURNS +1 Always. Error code in T1 if failure.
Function Description
----------------------------------------------------------------------
.IPSNT Change network state. AC2 contains the ARPANET
network number (ARPANET is number 10.). AC3 contains
the desired network state (nonzero for enable and
and zero for disable).
.IPRNT Determine network state. AC2 contains the ARPANET
network number (ARPANET is number 10.). Network
state is returned in AC3 (zero for disabled and
non zero for enabled).
.IPINI Reload ARPANET host table.
.IPGWY Reload ARPANET gateway table.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 29
10.0 Dependancies
The TCP/IP has very few requirements from the rest of the
monitor. The biggest requirement of the TCP/IP monitors is address
space. The TCP/IP code also assumes that the code in the monitor for
dealings with JFNs in the general case works. The TCP code uses all
(or most) of the JSYS' for dealing with JFNs. The TCP/IP code uses
its own free space management. The TCP/IP software calls several
general utility subroutines found throughout the monitor (eg. UPSHR,
DWNSHR, PSIRQ, etc...).
Acceptable performance of the TCP/IP code currently relies on
the improved performance of one word global byte pointers. If the
performance of OWGBPs is not improved the performance of the TCP
software will not be considered acceptable.
Release 6.0 ARPANET TCP/IP Functional Specification - Page 30
Appendix A.
The following is an example of the SYSTEM:HOSTS.TXT file.
; DoD Internet Host Table
; 27-May-83
;
; Changes, corrections, comments or questions to (NIC@SRI-NIC)
;
; The format of this file is documented in RFC 810, "DoD Internet
; Host Table Specification", which is available on-line at SRI-NIC
; as the file
; [SRI-NIC]<NETINFO>RFC810.TXT
; It may be retrieved via FTP using username ANONYMOUS with
; any password.
;
; NOTE CAREFULLY: RFC 810 has been slightly revised since the original
; version was written. In particular, the version printed in the
; "Internet Protocol Transition Notebook" does not document the
; added "machine type" field (between the host-name and system-name
; fields).
;
; The format for entries is:
;
; NET : NET-ADDR : NETNAME :
; GATEWAY : ADDR, ADDR : NAME : CPUTYPE : OPSYS : PROTOCOLS :
; HOST : ADDR, ALTERNATE-ADDR (if any): HOSTNAME,NICKNAME : CPUTYPE :
; OPSYS : PROTOCOLS :
;
; Where:
;; ADDR = internet address in decimal, e.g., 10.0.0.73
;; CPUTYPE = machine type (PDP-11/70, VAX-11/780, FOONLY-F3, C/30, etc.)
;; OPSYS = operating system (UNIX, TOPS-20, TENEX, ITS, etc.)
;; PROTOCOLS = transport/service (NCP/FTP,TCP/TELNET,TCP/FTP, etc.)
;; : (colon) = field delimiter
;; :: (2 colons) = null field
NET : 10.0.0.0 : ARPANET :
HOST : 10.0.0.1 : UCLA-CS,UCLA-CECS : VAX-11/750 : LOCUS : TCP/TELNET,TCP/FTP,TCP/SMTP :
HOST : 10.0.0.2 : SRI-NSC11,NSC11,DNSRI : PDP-11/40 : UNIX : NCP :
HOST : 10.0.0.3 : NOSC-CC,NOSC : VAX-11/750 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP :
HOST : 10.0.0.4, 192.5.12.21 : UTAH-CS : VAX-11/750 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP :
.
.
.
.
HOST : 10.1.1.51 : SRI-STA6 ::::
HOST : 10.2.1.58 : RU-GREEN : DEC-2060 : TOPS20 : TCP/SMTP :
HOST : 10.3.1.51 : SRI-STA2 ::::
HOST : 10.2.2.58 : RU-BLUE : DEC-2060 : TOPS20 : TCP/SMTP :
HOST : 10.3.2.51 : SRI-PRMH : PDP-11/44 : UNIX : TCP :
HOST : 10.1.4.51 : SRIJOYCE,JOYCE : VAX-11/750 : UNIX : TCP/FTP,TCP/TELNET,TCP/SMTP,UDP :
+---------------------------+
! ! ! ! ! ! ! ! i n t e r o f f i c e
! d ! i ! g ! i ! t ! a ! l !
! ! ! ! ! ! ! ! m e m o r a n d u m
+---------------------------+
Date: 29-Feb-84
From: Kevin W. Paetzold
Dept: TOPS-20 Monitor Group
DTN: 231-7430
LOC/MAIL STOP: MRO1-2/L10
Revision Level: 1.3
Subject: Early NI Support Project for the DOD TCP/IP Networking Protocols
1.0 Description of Document
----------------------------
This document is intended to clarify the current plans for the support
of the Department of Defense (DOD) Tranmission Control Protocol (TCP)
and Internet Protocol (IP) on the Network Interconnect (NI) for a
release 5.1 based TOPS-20 monitor. The NI is also known as the
Ethernet. This monitor will also support the existing 1822 (IMP)
ARPANET interface.
1.1 Related and Required Documents
-----------------------------------
The following documents specify the DOD Standard TCP/IP protocols.
DOD Standard Internet Protocol (IP) - RFC791
DOD Standard Internet Control Mesage Protocol (ICMP) - RFC792
DOD Standard Transmission Control Protocol (TCP) - RFC793
DOD Standard Exterior Gateway Protocol (EGP) RFC827
NISRV Functional Specification - GIDNEY::R61SPC:?.?
NIDLL Functional Specification - GIDNEY::R61SPC:NIDLL.DOC
IPNIDV Design Specification - R61SPC:IPNIDV.TXT
The following document specifies the ethernet environment as
agreed upon by DEC, Xerox, and Intel. "The Ethernet, A Local Area
Network, Data Link Layer and Physical Layer Specifications".
2.0 Relationship to Other Monitors
-----------------------------------
2.1 TOPS20 Release 5.3 Description (Existing Product)
------------------------------------------------------
Currently ARPANET customers are running release 5.3 of TOPS20 in an
"Alpha test" mode. Release 5.3 is based on Release 5.1 of TOPS20
with changes to support the TCP/IP protocols.
2.2 TOPS20 Release 5.3 Relationship to the TCP/IP NI Monitor
-------------------------------------------------------------
The TCP/IP NI Monitor will be known as release 5.4 of TOPS-20.
Release 5.4 will be the same as release 5.3 with the addition of
NI support. Release 5.4 will replace release 5.3 at customer
sites. Customers currently running release 5.3 will be moved to
5.4 as soon as possible after the 5.4 monitor has stabilized.
Release 5.4 will also be available in an "Alpha test" mode just
like release 5.3 was.
3.0 NI Support Description and Relationship to DECNET
------------------------------------------------------
Release 5.4 will support a minimum of the NI software required for the
transmission of Internet Protocol datagrams over the Ethernet. Release
5.4 will not support the tranmission of any form of Digital Network
Architecture (DNA or DECNET) messages. Release 5.4 DECNET software will
NOT be modified to support the NI. Release 5.4 DECNET support will
remain at the DECNET Phase III levels.
4.0 Project Goals
------------------
The primary goal of this project is to provide a base level of support
for the transmission of IP datagrams over the NI on or about April 1,
1984. This project will support the NI using the current NI device
driver (NISRV) being developed for Release 6.1 of TOPS20. NISRV will be
transported to a release 5.1 based monitor. NISRV is currently made up
of the modules NISRV and PHYKNI.
It is a goal of this monitor to support both the AN20 and the NI for
the tranmission of IP datagrams. A machine with only the NI hardware
(no AN20) will still require support for an AN20 in the monitor. It is
not possible to remove the AN20 software support in the time period
this project allows.
A minimum of the Low Level Operation Maintainance Protocol (LLMOP) will
be supported in order to meet Ethernet Blue Book (Xerox, Intel, and
Digital Ethernet Agreement) Requirements for the Ethernet Configuration
Testing Protocol. The LLMOP JSYS interface will not be supported.
The JSYS Interface to NISRV allowing direct user mode access to the
Ethernet will not be supported. The Timesharing diagnostic DFNIB which
requires the NISRV JSYS interface will not be supported. It is also not
clear that DFNIB will be available in time. The timesharing and stand
alone diagnostic DFNIA requires no additional support from the monitor
and will be supported.
It is a goal of this project that Digital Field Service will be able to
support the NI as a standard piece of Digital hardware. Diagnostics
will be made available to Field Service on the KLAD pack.
An important goal of this project is to cause a mimimum impact on the
TOPS20 Release 6.0 and 6.1 schedules via either human resources or
machine resources.
It is a goal that TOPS20 Release 5.4 will able to communicate with the
DEC Ultrix Operating system using the TCP/IP protocols over the
Ethernet. It is also a goal that release 5.4 will be able to
communicate with any other system running a compatable IP Ethernet
Transport Protocol.
5.0 Project Non Goals
----------------------
It is not a goal of this project to support DECNET Phase IV in any form
or to allow any DECNET messages to be transmitted over the NI.
It is not a goal of this project to support the Local Area Terminal
(LAT) protocols.
It is not a goal of this project to support direct access to the
Ethernet via JSYS calls to NISRV.
It is not a goal of this project to support any functionality not
required for the transmission of IP datagrams except for functionality
required by the Ethernet Blue Book agreement.
6.0 TCP/IP Protocol Impact
---------------------------
The TCP/IP Protocol Suite is a layered protocol strategy. IP provides a
non gauranteed internetwork datagram tranmission service. TCP is
layered within the IP protocol datagram and provides a reliable, flow
controlled, and sequenced message service.
The IP protocol was designed to allow tranmission over various packet
switching network mediums. This project will allow TOPS-20 to transmit
and receive IP datagrams on the Ethernet.
The TCP protocol is layered within the IP protocol. The tranmission of
TCP messages within IP datagrams over the Ethernet is transparent to
the TCP protocol module. The tranmission of TCP messages within IP over
the Ethernet will have no impact on the TCP JSYS interface or the user
level software used in this environment (ie. TELNET, MS, MM, FTP).
The current TOPS20 (5.3) TCP/IP support was designed with the ability
to interface multiple network interfaces to IP. The interface code is
known as Multinet. Interfacing TCP/IP to the NI requires interfacing
the NI driver (NISRV) to the Multinet code (MNETDV). The module to
interface NISRV to MNETDV will be known as IPNIDV.
7.0 New TCP/IP Functionality
-----------------------------
Supporting TCP/IP on the NI will allow much new functionality to exist
in TOPS20 with little development cost. TOPS20 systems on the NI will
be able to communicate with other TOPS20 and Ultrix systems using
TCP/IP on the NI regardless of the presence of an AN20 hardware
interface on the TOPS20 system. A TOPS-20 system will be able to
communicate over the Ethernet using TCP/IP with any other system
running a compatable IP Ethernet Transport Protocol.
A TOPS20 release 5.4 system with both an AN20 (interfacing to an IMP)
and an NI will act as a internet gateway between the local Ethernet and
any other interconnected network. TOPS20 will act as an Internet
Exterior Gateway (EGP Protocol).
An exterior gateway is the sole connection between two networks. A
multiple gateway network interconnection is not allowed at this time by
the Internet Network Control Center (ie. administratively prohibited).
8.0 Development Strategy
-------------------------
The development strategy for the TCP/IP NI monitor is divided into four
parts or major milestones.
8.1 IP Ethernet Transport Protocol Definition
----------------------------------------------
The first milestone is the definition of the IP Ethernet Transport
Protocol. This protocol will specify the format of IP datagrams on
the Ethernet.
The Defense Communications Agency (DCA) has control over the
establishment of standard protocol descriptions for the Internet
Protocol Suite. DCA has not at this point issued a specification
for the tranmission of IP datagrams over the Ethernet.
Many organizations (eg. ISI, SRI, and Stanford) are currently
transmitting IP datagrams over the Ethernet. The IP transport
protocols used by various organizations are disimiliar due to the
lack of a standard from the DCA.
Our goal is to implement an IP Ethernet Transport protocol which
will be compatable with the Berkeley Unix IP Ethernet Transport
Protocol. The DEC Ultrix operating system is based on Berkeley
Unix and uses the same protocols.
8.2 TOPS-20 Release 6.1 TCP/IP Support
---------------------------------------
The second milestone of this project is to build and test a
release 6.1 TCP/IP monitor without the TCP/NI support.
TOPS-20 Release 6.1 has contained the code for supporting TCP/IP
for some time. However the release 6.1 ARPANET code has not been
tested. Release 6.1 currently has major address space restrictions
which restrict the size and types of monitors available.
8.3 TOPS-20 Release 6.1 TCP/IP NI Support
------------------------------------------
The third milestone of this project is the implementation of the
software required for the tranmission of IP datagrams over the
Ethernet in release 6.1 of TOPS-20. Release 6.1 currently supports
the NI device driver.
8.4 TOPS-20 Release 5.4 NI support
-----------------------------------
The fourth and final milestone of this project is the 5.4 monitor
itself.
This part entails transporting the release 6.1 Ethernet software
to the 5.1 based TCP/IP monitor. The code to be transported falls
into two parts. The NI driver itself (NISRV) and the TCP/IP
Ethernet Protocol module (IPNIDV).
9.0 Required Resources
-----------------------
This project requires standalone resources on multiple (2) KLs with NI
hardware. One of the KLs must also have an AN20 with a connection to
the IMP in the software Lab. This requirement is easily met by adding
an NI to CHIP and connecting CHIP to RONCO or ETHER over the NI.
Standalone requirements are difficult to accurately predict at this
time. An estimate is that we will require two hours a day of standalone
on Chip and Ronco (or Ether) for one week. We will require additional
standalone on both Chip and Ronco for final debuging and tuning. This
should amount to about one hour a day on both Chip and Ronco and one
additional hour a day on Chip.
This project also requires some consulting effort from the release 6.1
group on the NI device driver (NISRV) for general information purposes
and bug fixes in NISRV.
10.0 Dependancies and Risks
----------------------------
Some risks and dependancies exist. The resources mentioned in 9.0 is a
requirement. Without the above resources this project is not possible.
This project assumes that the NI device driver (NISRV) works well
enough to support the tranmission of IP datagrams at this time. Having
to debug NISRV will cause a slip in this project. It is assumed that
the 6.1 group will supply some resources for the debuging of problems
in NISRV.
11.0 Support and Distribution to Customers
-------------------------------------------
Through an extension of the current release 5.3 alpha test license
customers will be able to run this software on an alpha test basis.
This monitor will be supported by software engineering as a pre field
test monitor. This is the same method that release 5.3 was supported.
Maintenance releases corresponding to release 5.1 autopatch tapes will
be supplied. Monitors will be built by Software Engineering. Monitors
will be supported on a best effort basis by Software Engineering. The
monitors will be initially distributed via the ARPANET (same as 5.3
was). We will make a tape which will be available for copying on a
special case basis for those customers who can not access the software
via the ARPANET.
12.0 Testing
-------------
This monitor will be tested at selected customer sites before release
to the general TOPS-20 customer base. A few (about two) sites will be
chosen for testing. The customer sites should have multiple
DECSYSTEM20s and possible Berkeley Unix or Ultrix systems. Software
Engineering will provide on site expertise during the initial
installation and testing of the monitor.
13.0 Relationship to SPEAR
---------------------------
The only data available to SPEAR from the NI support is the BUGINFs,
BUGCHKs, and BUGHLTs generated from NISRV, IPNIDV, and the TCP/IP
software modules.
Appendix A - TCP/IP Protocol Relationships
------------------------------------------
.-----------------.
| Telnet Protocol |
`\||/-------------'
|| .--------------.
|| | Customer |
|| | Defined |
|| | Applications |
|| `------\||/----'
|| ||
|| ||
./||\--------/||\. .-----------------.
| Transmission | | Internet |
| Control | | Control Message |
| Protocol (TCP) | | Protocol |
`-----\||/-------' `-------\||/------'
|| ||
.-/||\-----------------------------/||\-----.
| Internet Protocol (IP) |
`-\||/--------------------------------------'
||
||
.-/||\------------------------------------------------.
| Multinet Software |
`-\||/--------------------\||/-----------------\||/---'
|| || ||
|| || ||
|| || ||
.-----/||\---------. .-----/||\-----. .----/||\----.
| IMP Interface | | Ethernet | | Customer |
| Via KL AN20 | | Interface | | Defined |
| (1822 Protocol) | | (IPNIDV) | | Interfaces |
`------------------' `-----\||/-----' `------------'
||
||
.-----/||\-----.
| Ethernet |
| Driver |
| (NISRV) |
`--------------'
Appendix B - TCP/IP, Ethernet, and 1822 Message Bit Maps
--------------------------------------------------------
+---------------+
! d i g i t a l ! I N T E R O F F I C E M E M O R A N D U M
+---------------+
DATE: Mar 1, 1984
TO: TOPS-20 Software Engineering
FROM: Mark Pratt
DEPT: LCG S.E.
DTN: 231-6455
LOC: MRO1-2/L10
FILE: GIDNEY::R61SPC:IPNIDV-DESIGN-SPECIFICATION.TXT
SUBJ: TCP/IP PACKET TRANSMISSION OVER ETHERNET
This document describes the proposed implementation for
transmitting the DoD standard Internet Protocol messages over
Ethernet networks. The main goals of this implementation are:
o To provide a base level of support for the
transmission of IP datagrams over the NI hardware
o To be able to communicate with other TOPS-20
systems running the same TCP/IP/NI implementation
o To be able to communicate with Vax systems which
are running Digital's Ultrix operating system.
OVERVIEW
Even though the standard TOPS-20 TCP/IP uses an AN20 to
connect the 20 to the Internet, BBN designed a module called
Multinet which allows TCP/IP to be transmitted over any number
of different hardware devices. The basic concept is that each
hardware device is the interface into a different physically
seperate network.
To allow IP datagrams to be sent over the Ethernet we will
create a new module called IPNIDV. IPNIDV will be the interface
between Multinet (MNETDV) and the NI software (NISRV). It's main
function will be to service the requests of Multinet, requests
such as network startup, network shutdown, start I/O, status
checking, etc. IPNIDV will also provide some adminstrative
gateway control for routing IP messages between Internet and
hosts on the Ethernet.
The new organization of the monitor modules will look like this:
TCP / IP Multinet 1822 / AN20 driver
|---------------------| |---------| |---------------------|
.-------. .-------. .-------. .-------. .-------.
| | | | | | | | | |
|TCPTCP |<--->|IPIPIP |<--->|MNETDV |<--->|IMPDV |<--->|IMPANX |
| | | | | | | | | |
|_______| |_______| |_______| |_______| |_______|
^
|
v
.-------. .-------------------.
| | | |
|IPNIDV |<--->| NISRV + PHYKNI |
| | | |
|_______| |___________________|
|---------| |---------|---------|
Interface Data Link NI hardware
to the NI Layer driver
software
THE PROBLEMS OF PUTTING TCP/IP ON ETHERNET
There were a number of problems which were studied before
deciding that this implementation would succeed.
o NO STANDARDS EXIST
A "Request for Comment" (RFC) has been the
official forum for setting the standards within the
Internet environment. Even though no RFC has been
issued which proposes a standard for transmitting IP
datagrams over Ethernet networks, several draft RFC's
have been proposed.
We have used these drafts as the basis for
deciding what our implementation will use. The
following issues were discussed in great detail in
these draft RFCs.
o TRAILER ENCAPSULATION
There are current Unix implementations of TCP/IP
over Ethernet which are designed to make use of paging
virtual memory systems to obtain higher throughput for
IP datagrams. The method they use is called trailer
encapsulation.
Trailers consist of an Ethernet header followed by
the data portion of an IP or TCP packet, followed by
the original IP and/or TCP header information. This
allows the data to be page aligned and can be mapped
between kernal and user address space with doing
memory to memory transfers.
The current implementations of trailers allows a
host to turn off the use of trailers. Therefore given
the timeframe in which we have to implement the IPNI
project, we will not be doing trailer encapsulation.
THE PROBLEMS OF PUTTING TCP/IP ON ETHERNET (continued)
o ADDRESS RESOLUTION
A method of obtaining the Ethernet host address
given an Internet host address needs to be developed.
This problem has been addressed by RFC826 but has
not been adopted as a standard. This RFC defines the
Address Resolution Protocol (ARP). ARP is based on
Ethernet broadcast mechanism. It allows us to send an
ARP message to every Ethernet host. In the ARP message
is the Internet host number which we want to
communicate with. Each host can look at this message
and decide if the message is for it. The remote host
can then respond to us, filling in it's Ethernet
address.
Even though ARP is used in certain
implementations, it does not have to be used. In fact
there are provisions for hosts which do not use it.
Therefore given the timeframe in which we have to
implement the IPNI project, we will not be doing ARP.
In place of ARP, the monitor will maintain a table
that will contain the Internet host number, the
Ethernet host number, and some host related flags.
This table will be used to obtain the Ethernet or
Internet host number given the other type of host
number.
THE PROBLEMS OF PUTTING TCP/IP ON ETHERNET (continued)
o IP PROTOCOL TYPE FOR ETHERNET
The protocol type has been more or less defined by
the draft RFCs. The protocol type is also defined by
the use of trailer encapsulations or not.
If a host is not using trailers, the protocol type
is defined as hex 008.
If a host is using trailers, the protocol type is
based on the number of 512 byte pages within the
Ethernet message. The protocol types range in value
from 1001 (1000(?)) and 1016, and 4096.
Since we are not implementing trailers, we will
only enable the receiving of type 0008.
ETHERNET TCP/IP PACKET FORMAT
This diagram is shows what a possible TCP IP packet will
look like when transmitted over the NI. The Ethernet header
information is generated by NISRV and is not available to
IPNIDV.
0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
E .---------------------------------------------------------------.
t H |Dst adr Byte 1 |Dst adr byte 2 |Dst adr byte 3 |Dst adr byte 4 |
h e |---------------------------------------------------------------|
e a |Dst adr byte 5 |Dst adr byte 6 |Src adr byte 1 |Src adr byte 2 |
r d |---------------------------------------------------------------|
n e |Src adr Byte 3 |Src adr byte 4 |Src adr byte 5 |Src adr byte 6 |
e r |-------------------------------.-------------------------------'
t | Protocol Type |
======= |==============================='-------------------------------.
|Version|Hdr Len|Type of Service| Total Length of Datagram | 0
|---------------------------------------------------------------|
I P | |M|D|M| |
n r H | Datagram Identifier |B|F|F| Fragment Offset | 1
t o e | |Z| | | |
e t a |---------------------------------------------------------------|
r o d | Time to Live | Protocol | Header Checksum | 2
n c e |---------------------------------------------------------------|
e o r | Source Host Address | 3
t l |---------------------------------------------------------------|
| Destination Host Address | 4
|---------------------------------------------------------------|
| Protocol Options | Padding | 5
======= |===============================================================|
T P | Source Port | Destination Port | 0
r r |---------------------------------------------------------------|
a C o | Sequence Number | 1
n o t |---------------------------------------------------------------|
s n | Acknowledgment Number | 2
m t H |---------------------------------------------------------------|
i r e | Data | |U|A|P|R|S|F| |
s o a |Offset | Reserved |R|C|S|S|Y|I| Flow Control Window | 3
s l d | | |G|K|H|T|N|N| |
i e |---------------------------------------------------------------|
o r | Checksum | Urgent Pointer | 4
n |---------------------------------------------------------------|
| Transmission Control Protocol Options | Padding | 5
======= |===============================================================|
| data | 0
|---------------------------------------------------------------|
| data | .
|---------------------------------------------------------------|
| data | .
|---------------------------------------------------------------|
| data | n
|_______________________________________________________________|
MONITOR CHANGES
The following is a list which outlines the changes that will
be made to the 6.1 monitor.
SYSFLG.MAC code for IPNI
Changes to STG
IPNIDV storage
LOADMODULE for IPNIDV
Changes to ANAUNV, add nct for IPNI device
Changes to MNETDV to add IPNI device to INTNAM table
Add IPOPR% jsys function to load IPNI host # lookup tables
Changes to IPFREE to get contiguous physical memory
Create IPNIDV, major routines are:
Miscellaneous routines:
read and verify host # lookup tables
internet host to ethernet host number lookup
ipni to multinet loopback
services privilege check by host # (gateway control)
Multinet callable routines:
network startup
network reset
network shutdown
status check
start output
Calls to NISRV:
post a receive buffer
nisrv callback dispatch routine
open ni channel and enable protocol type
send datagram
NISRV callable routines:
receive datagram callback
ni state change callback
datagram sent callback
address change callback
MNETDV CHANGES
MNETDV.MAC contains the code which is generally called
Multinet. It is a number of subroutines which allow Internet to
support a number of different networks, any of which can have
it's own or shared hardware interface.
The defintions which follow are in ANAUNV. They are used to
call the routines within a network interface. In our case, the
routines within IPNIDV. P1 contains the Network Control Table
(NCT) address for Ethernet. FOO is the NCT offset for whatever
function needs to be performed.
DEFINE MNTCALL(FOO)<CALL @FOO(P1)> ;Call a routine
DEFINE MNTJRST(FOO)<JRST @FOO(P1)> ;Jump to a routine
DEFINE MNTXCT(FOO)<XCT FOO(P1)> ;Execute an instruction
The Multinet code contains a table of known devices (such as
the AN20) which can transmit IP datagrams. We will need to add
an entry to specify the existence of Ethernet:
o Change the table INTNAM to include IPNI. This entry is
used for parsing the SYSTEM:SITE-ADDRESS.TXT file.
NETWORK CONTROL TABLE (NCT)
The NCT is a device dispatch table for specific hardware
devices which can send Internet messages. Each entry contains a
device specific instruction or a dispatch address to a routine.
NOP ; NTCNSZ - CONSZ Input
NOP ; NTCNSO - CONSO Input
NOP ; NTCONO - CONO Input
NOP ; NTCONI - CONI Input
NOP ; NTDATO - DATAO Input
NOP ; NTDATI - DATAI Input
IFIW!NIPINI ; NTINI - Initialization instruction
IFIW!NIPKIL ; NTKILL - Shutdown instruction
IFIW!NIPRST ; NTRSRT - Restart instruction
IFIW!NIPSTI ; NTISRT - Start input instruction
IFIW!NIPSTO ; NTOSRT - Start output instruction
IFIW!R ; NTIDUN - Input done dispatch
IFIW!R ; NTODUN - Output done dispatch
IFIW!R ; NTLLDR - Make header instruction
IFIW!RSKP ; NTOTOK - CLear packet for output
IFIW!R ; NTMAIN - Maintainance
IFIW!NIPSTS ; NTSCHK - Status check instruction
BLOCK NTOCNO-NTIB ; NTIB through NTOTYP
NOP ; NTOCNO - CONO Output
NOP ; NTOCNI - CONI Output
NOP ; NTOCSO - CONSO Output
NOP ; NTOCSZ - CONSZ Output
NOP ; NTODTO - DATAO Output
NOP ; NTODTI - DATAI Output
XPCW .+1 ; NTIINT - Interrupt instruction
BLOCK 2 ; NTIPCW - Inturrupt PC storage
EXP 0 ; NTINPC - New flags (Input)
XWD MSEC1,.+1 ; New PC (Input save)
MAKSAV (IMPPDP,NTIDSP) ; NTIISV - 6 words of AC save routine
MAKRES (NTIPCW) ; NTIIRS - 3 words of AC restore routine
XPCW .+1 ; NTOINT - Interrupt instruction
BLOCK 2 ; NTOPCW - PC storage
EXP 0 ; NTONPC - New flags
XWD MSEC1,.+1 ; New PC (Output Save)
MAKSAV (IMPPDP,NTODSP) ; NTIOSV _ 6 words of AC Save
MAKRES (NTOPCW) ; NTIORS 3 words of AC restore
BLOCK 20 ; NTSVAC - AC storage
STG - STORAGE
A new symbol is needed to specify Ethernet IP. This is called
IPNIN. It should be set to 1.
Multinet requires a defintion for the # of networks.
Normally this is set to the # of AN20 devices. This should be
increased by 1.
;
;add this line around the: %NETS==:ANXN ;TOTAL # OF IP INTERFACES
;
IFN IPNIN,<%NETS==:%NETS+IPNIN> ;PLUS 1 IF ETHERNET IP
The IPNIDV module must be loaded when LINK is run.
;
;add the following line
;
IFN IPNIN,<LOADMODULE IPNIDV>
Another feature test switch called FTIPNI will be used in
SYSFLG which can be used for IPNI conditional assembly in the IP
modules.
IPNIDV reads a gateway host table which contains the
Internet and Ethernet host addresses, and some gateway control
flags. The maximum number of entries which we will allow
internally is set by this defintion.
NIMAXH::^D32*NIHMDL ;reasonable maximum number of hosts
;we want to talk with on the ni
STG - STORAGE (continued)
The PC section storage required by IPNIDV will be kept to a
minimum. Most of the storage required will come from the
Internet storage section.
These are the locations which I believe will need to be
defined in STG:
Name Description
---- -----------------
NILPBK Set to -1 if for local loopback testing of
messages. This will only apply to messages
which are sent to the local host using the
local hosts IP/ENET host number. All other
messages will be dumped as if the remote
host were not up.
NIPNCT Holds NCT address for IPNI multinet data base.
IUNBLK Holds the address of the UN block
GHTPNT Holds the address of the gateway host table.
GHTLEN Holds the length of the GHT
NNIPIB is the value of the number buffers to keep queued
NIPNIB is the location where NNIPIB is stored
NIPNFI is the number of free input buffers we currently have
[More to be defined]
IPNI ROUTINES
NIHINI - IPNI host table initialization.
NIHINI is called at system startup, or by the IPOPR% jsys.
It will read the Internet-Ethernet host number translation table
file. This file contains the information which allows us to
handle address resolution. It also contains the gateway control
info which allows us to act like an ACJ to control what TCP
services (Telnet, Mail, FTP, etc) each Ethernet host can use
when communicating between us or the outside world (Internet).
NIHINI builds the gateway host table (GHT) from a binary
file produced by the IPHOST program. The name of this file is:
SYSTEM:INTERNET-ETHERNET-MAPPINGS.BIN
Format of this host table file is:
.---------------------------------------------.
| CHECKSUM |
|---------------------------------------------|
| GTAD FORMAT DATE AND TIME OF FILE |
|---------------------------------------------|
| MONITOR VERSION # |
|---------------------------------------------|
| IPHOST VERSION # |
|---------------------------------------------|
| NUMBER OF WORDS THAT FOLLOW |
|=============================================| -.
| STANDARD 32 BIT INTERNET ADDRESS | |
|---------------------------------------------| |
| BYTE 1 | BYTE 2 | BYTE 3 | BYTE 4 | MBZ | 1 group per host
|---------------------------------------------| |
| BYTE 5 | BYTE 6 | MBZ | |
|---------------------------------------------| |
| GATEWAY CONTROL FLAGS | |
|=============================================| -'
/ . /
/ . /
/ . /
`============================================='
The definitions for words in the GHT are in ANAUNV.MAC
as follows:
.NICHK==:0 ;Computed checksum of file
.NIGTD==:1 ;GTAD format for date/time of
;when the file was created
.NIMVR==:2 ;Monitor version # when created
.NIMIR==:3 ;IPHOST version # when created
.NILEN==:4 ;Number of words which follow
.NIINT==:0 ;the internet host number
.NIEN1==:1 ;ethernet addr word 1
.NIEN2==:2 ;ethernet addr word 2
.NIGCF==:3 ;gateway control flags
NIHMDL==:4 ;max length of per host data
The checksum word in this file is generated by adding all
words in the file together except the checksum word itself. If
the checksum computed by the monitor does not agree with the
file checksum, the table will not be accepted. Until there is a
GHT, no IP datagrams can be transmitted over the NI.
Changes can be made to the GHT by successive calls to NIHINI
with a modified file. The previous GHT will be used until the
file has been successfully read and checked.
NIHINI Returns + 1 on error
+ 2 on success
NIHINI will perform the following steps:
o set up some temporary TRVAR storage
o open the file
o read the header words and begin to compute checksum
o check file length, if too long generate an error
o get resident storage for gateway host table
o save pointer to stoarge
Loop:
o read 1 block of host data
o check Internet host # for ascending order
o compute a checksum on this block's data
o store data in the free space
o decrement the "words following" count
o check for end of data
o if more, go back to loop
o test the computed checksum against the file checksum
o get pointer to storage
o exchange this new pointer with the old pointer
o if old pointer was non-zero, release the old storage
o close the file
CNVADR - CONVERT ADDRESSES (HOST NUMBERS)
Called from the start output code, this routine converts the
destination Internet host number into Ethernet host number and
places it into the UN block host address words.
Call with:
T1/ Destination Internet host number
T2/ UN block address
Returns + 1 on error
+ 2 on success
o get the GHT adr of the destination Internet host number
o retrieve the Ethernet host number, save in UN block
INTSRC - SEARCH FOR GHT ENTRY OF INTERNET HOST NUMBER
Called from CNVADR and the received datagram callback
routines to find an entry in the GHT that matches the Internet
host number. It then returns the address of the entry to the
caller.
Call with:
T1/ Internet host number
Returns + 1 if host number not found
+ 2 on success with T1/ adr of GHT entry that matched
o perform a binary search of the host number
o if not found, ret
o if found, return skip with address of entry
NIPINI - INITIALIZATION
Called from MNTINI when initializing all of the networks
known to Multinet.
Returns + 1 always
o saves away the NCT address for the NI callbacks
o makes sure that the GHT has been initialized
o clears the "host going down" flag
o set "we want the netowrk up" flag
o do a reset of the driver code by calling restart code
NIPRST - RESTART
Called from MNETDV and NIPINI to restart the driver and
start sending output.
Returns + 1 always
o check the "we want the network up" flag
o if not on, return
o clear output hung timer
o call the NIOPEN routine, lose if error
o call NIPSTS to check the status, lose if error
o get a receive buffer
o enable the protocol type
o post the receive buffer
o set network on flags
o set "time when interface came up" word
o set "allow output" flag
o call INTUP to say interface is up
o start output if possible
o flag job 0 to say network state has changed
NIPSTS - STATUS CHECK
This routine is called from MNETDV and from the IPNI code
itself. It checks the status of the NI. It skip returns if all
is okay.
Returns + 1 when hardware/software has a problem,
sets NTERRF and NTTOUT
+ 2 on success
o clear out "error flag" word
o if in local loopback mode, always "win" (RETSKP)
o call NI status routine
o if channel is running then RETSKP
o on errors, set "error flag" and set net hung timer word
NIPKIL - SHUTDOWN
Called from MNETDV code to shutdown the network.
Returns + 1 always
o check and the set the netowrk ready words
o clear the output hung timer
o if already down, just RET
o say NI, NET, and OUTPUT off
o flag "just changed state"
o flag job 0 to notice network state has changed
o if in local loopback mode, RET
o perform an NI close function
o release unused buffers from IPNI free pool
NIPSTO - START OUTPUT
Called from Multinet or from itself, NIPSTO tries to start
output by passing the IP packet to NISRV. If local loopback is
turned on, the message, if destined for this host, is sent to
the NI packet input routine.
Call with:
NTIOBO(P1)/ address of the internet buffer
Returns + 1 always
o If no output or IPNI driver error is on, do nothing
o Mark output as being in progress
o Get the output buffer off the output queue
o If loop back mode is on, goto loopback code
When sending output to the NI:
o Form an 8 bit OWGBP to the output buffer
o Get remote Internet address
o Convert the address to Ethernet addresses
o If host not found in GHT
o Increment an error counter
o Release the buffer and ret
o Check IP length to see if padding is needed
o Pick up the IP packet size and save in UN
o Lock the buffer
o Give the packet to NISRV
o If NISRV gives an error:
o Unlock the buffer
o Place the buffer in the free queue
o Generate an error, return
o Clear output hung timer
o Try to start more output
When in loopback mode:
o Check the packet destination, if not for us:
o Place the buffer on the free queue
o Try to start more output
o Place on Internet input queue
NIOPEN - OPEN NI CHANNEL
NIOPEN is called from the restart code. It sets up the UN
block and calls NISRV to open a portal.
Returns +1 on error, error code in T1
+2 on success
o reserve some IP free space for a UN block
o lock the UN block
o set up the callback vector
o set up the user id as "TCPIP"
o set the scan for a channel bit
o set up the protocol type in the UN block
o call NISRV to open the channel
o if error,
o unlock the un block
o generate error and return
GTIBFR - GET INPUT BUFFER
Called from the restart code and from the datagram received
callback to obtain resident free space for input buffers. At
this time, the NI hardware requires the boundaries of any given
input buffer lie on physically contiguous pages of memory.
Buffers are obtained from the IPNI buffer free queue which
is maintained by the Internet fork.
Returns + 1 on error
+ 2 on success, T1/ address of buffer
o call GETNIB to get a buffer
o lock the buffer
IPCALL - CALLBACK DISPATCH
Routine that NISRV calls so that we can do a callback
dispatch.
Call with:
T1/ Callback function code
T2/ Address of the UN block
Returns + 1 always to NISRV from the individual routines
o Check to see if callback vector is in range
o Dispatch into dispatch table
Callback vectors are: Routine called:
Illegal function call back IPCBIL
Datagram received IPCBDR
Datagram sent IPCBDS
Line state changed IPCBLS
Read counters complete IPCBRC
Read channel info complete IPCBRS
Close done IPCBCD
Address change IPCBAC
IPCBDS - DATAGRAM SENT CALLBACK
Uses the request ID in the UN block which is the address of
the sent buffer and places it on the free buffer list. Errors in
the message transmission are ignored, TCP will take care of
retransmission.
Call with:
T1/ NU.XMT
T2/ UN block address
Returns + 1 always
o Save P1 for NISRV and pick up the NCT address
o Get the request id (buffer address)
o Unlock the buffer
o Place the buffer on the free queue
o If there are any errors from NISRV, possibly
generate a BUGxxx message
IPCBDR - DATAGRAM RECEIVED CALLBACK
Called by NISRV when we have received a datagram from the
Ethernet. The address of the buffer is in the request id word of
the UN block.
Call with:
T1/ NU.RCV
T2/ UN block address
Returns + 1 always
o get a new receive buffer from IPNI free queue
o lock the buffer
o post the new receive buffer
o check status of the channel
o if error,
o if channel shutting down,
o release the buffer and return
o if size error,
o generate an ICMP error
o release the buffer and return
o else
o generate an error
o release the buffer and return
o get the buffer address from UNRID
o place on Internet input queue
IPCBLS - LINE STATE CHANGE
This routine is called from NISRV as a callback whenever our
channel is changing states from off to on, on to off, or when
the NI is being reloaded.
Call with:
T1/ NU.xxx
T2/ xxxxxx
Returns + 1 always
o get the status
o if transistioning from on to off or being reloaded,
o declare NI down
o call the NIPKIL routine
o return
o else
o declare NI up
o call NIPRST
[End of TCPIP.MEM]