the length of the last one received. Thus, if HLO.LENGTH
equal to PKT.LENGTH, set OFFSET -> HOST-TABLE.OFFSET;
otherwise, leave this field alone. Finally, if HID is equal to
CLOCK-HID and bit 15 (the DATE-VALID bit)
of DATE is zero, set PKT.DATESTAMP -> DATE and call the SET-CLOCK
procedure of the CLOCK process with argument HLO.TIMESTAMP.
OUTPUT-PACKET Event
This event is evoked once every HELLO-INTERVAL seconds. It determines if
a HELLO message is to be transmitted, transmits it and updates state
variables.
1. If HLO.KEEP-ALIVE is nonzero decrement its value.
2. If HLO.POLL is zero and HLO.KEEP-ALIVE is zero, do not send a HELLO
message. If either is nonzero initialize the packet fields as
follows: LOCAL-ADDRESS -> PKT.SOURCE,
HLO.NEIGHBOR-ADDRESS -> PKT.DESTINATION and DATE -> PKT.DATESTAMP.
Note: PKT.DESTINATION is set to zero if this is a broadcast link
(HLO.BROADCAST set to one). Also, note that bit 15 of DATE is the
DATE-VALID bit. If this bit is one the receiver will not update its
master clock from the information in the transmitted packet.
This is significant only if the sending host is on the
least-delay path to the master clock. Set PKT.TIMESTAMP to
the value returned from the READ-CLOCK procedure. If
HLO.KEEP-ALIVE is zero or HOLD is nonzero, set PKT.TSP to
zero; otherwise, set PKT.TIMESTAMP + HLO.TSP -> PKT.TSP.
3. Determine if the neighbor is on the same net or subnet. If the
neighbor is on a different net set PKT.NHOSTS to zero and
proceed with the next step. Otherwise, set NHOSTS ->
PKT.NHOSTS and for each value of HID from zero to PKT.HOSTS-1
copy the HOST-TABLE.DELAY and HOST-TABLE.OFFSET fields of the
corresponding HOST-TABLE entry in order into the packet. For
each entry copied test if the HOST-TABLE.PID field matches the
HLO.PID of the HELLO process. If so, a potential routing loop
is possible. In this case use MAXDELAY for the delay field in
the packet instead.
4. Finally, set HLO.LENGTH to the number of octets in the packet
and send the packet.
3.4. HOST Process (HOS)
This process maintains the routing tables. It is activated once per
second to scan HOST-TABLE and decrement the HOST-TABLE.TTL field of each
entry. It also performs housekeeping functions.
DCN Local-Network Protocols Page 22
D.L. Mills
3.4.1. Local variables
HOS.PID
This is an eight-bit integer used to identify the HOST process. It is
initialized by the kernel when the process is created and remains
unchanged thereafter.
HOS.HID
This is an eight-bit temporary variable.
3.4.2. Events and Procedures
SCAN Event
This event is evoked once each second to scan the HOST-TABLE and perform
housekeeping functions.
1. For each value of a temporary variable F from zero to NHOSTS-1 do the
following: Set LOCAL-ADDRESS -> ADDRESS and call the ROUTE
procedure, which will return the host ID HID. If F is equal
to HID, then set both DELAY and OFFSET to zero, HOS.PID -> PID
and call the UPDATE procedure. This will cause all packets
received with the local address to be routed to this process.
If HOST-TABLE.TTL is zero skip this step. Otherwise, decrement
HOST-TABLE.TTL by one. If the result is nonzero skip the
remainder of this step. Otherwise, If HOST-TABLE.DELAY <MAXDELAY set
HOLDOFF-INTERVAL -> HOST-TABLE.TTL and MAXDELAY -> HOST-TABLE.DELAY.
The effect of this step is to declare a hold-down cycle when a host
goes down.
4. References
1. Mills, D.L. Final Report on Internet Research, ARPA Packet Switching
Program. Technical Report TSLAB 82-7, COMSAT Laboratories,
December 1982.
DCN Local-Network Protocols Page 23
D.L. Mills
Appendix A. Link-Level Packet Formats
A.1. Serial Links Using Program-Interrupt Interfaces
Following is a description of the frame format used on
asynchronous and synchronous serial links with program-interrupt
interfaces such as the DEC DLV11 and DPV11. This format provides
transparency coding for all messages, including HELLO messages, but
does not provide error detection or retransmission functions. It is
designed to be easily implemented and compatible as far as possible
with standard industry protocols.
The protocol is serial-by-bit, with the same interpretation on
the order of transmission as standard asynchronous and synchronous
interface devices; that is, the low-order bit of each octet is
transmitted first. The data portion of the frame consists of one
Internet datagram encoded according to a "character-stuffing"
transparency convention:
1. The frame begins with the two-octet sequence DLE-STX, in the case of
asynchronous links, or the four-octet sequence SYN-SYN-DLE-STX, in the
case of synchronous links. The data portion is transmitted next,
encoded as described below, followed by the two-octet sequence
DLE-ETX. No checksum is transmitted or expected. If it is
necessary for any reason to transmit time-fill other than in the
data portion, the DEL (all ones) is used.
2. Within the data portion of the frame the transmit buffer is
scanned for a DLE. Each DLE found causes the sequence DLE-DLE to
be transmitted. If it is necessary for some reason for the
transmitter to insert time-fill within the data portion, the
sequence DLE-DEL is used.
3. While scanning the data stream within the data portion of the
frame the sequence DLE-DLE is found, a single DLE is inserted in
the receive buffer. If the sequence DLE-ETX is found, the buffer
is passed on for processing. The sequence DLE-DEL is discarded.
Any other two-octet sequence beginning with DLE and ending with
other than DLE, ETX or DEL is considered a protocol error
(see note below).
Note: In the case of synchronous links using program-interrupt
interfaces such as the DPV11, for example, a slightly modified
protocol is suggested when both ends of the link concur. These
interfaces typically provide a parameter register which can be loaded
with a code used both to detect the receiver synchronizing pattern and
for time-fill when the transmit buffer register cannot be serviced in
time for the next character.
The parameter register must be loaded with the SYN code for this
protocol to work properly. However, should it be necessary to
transmit time-fill, a single SYN will be transmitted, rather than the
DLE-DEL sequence specified. Disruptions due to these events can be
minimized by use of the following rules:
DCN Local-Network Protocols Page 24
D.L. Mills
1. If the transmitter senses a time-fill condition (usually by a
control bit assigned for this purpose) between frames or
immediately following transmission of a DLE, the condition is ignored.
2. If the transmitter senses a time-fill condition at other times it sends
the sequence DLE-CAN.
3. If the receiver finds a SYN either between frames or immediately
following DLE, the SYN is discarded without affecting sequence
decoding.
4. If the receiver finds the sequence DLE-CAN in the data portion, it
discards the sequence and the immediately preceding octet.
These rules will work in cases where a single SYN has been
inserted by the transmitter and even when a SYN has been inserted in
the DLE-CAN sequence. If an overrun (lost data) condition is sensed
at the receiver, the appropriate action is to return to the
initial-synchronization state. This should also be the action if any
code other than STX is found following the initial DLE. or if any
code other than DLE, ETX, DEL or CAN is found following a DLE in the
data portion.
A.2. Serial Links Using DDCMP Devices
Following is a description of the frame format used on DEC DDCMP links
with DMA interfaces such as the DEC DMV11 and DMR11. These interfaces
implement the DEC DDCMP protocol, which includes error detection and
retransmission capabilities. The DDCMP frame format is as follows:
+-------------+-----+-----+-----+-----+-----+------+------+------+
| SYN SYN SOH |Count|Flag |Resp | Seq | Adr | CRC1 | Data | CRC2 |
+-------------+-----+-----+-----+-----+-----+------+------+------+
bits 24 14 2 8 8 8 16 ... 16
With respect to this diagram, each octet is transmitted starting from the
leftmost octet, with the bits of each octet transmitted low-order bit first.
The contents of all fields except the "Data" field are managed by the
interface. The Internet datagram is placed in this field as-is, with no
character or bit stuffing (the extent of this field is indicated by the
interface in the "Count" field.
A.3. Serial Links Using HDLC Devices
Following is a description of the frame format used on HDLC links with
program-interrupt interfaces such as the DEC DPV11.
+--------+--------+--------+--------+--------+--------+
| Flag | Addr | Ctrl | Data | CRC | Flag |
+--------+--------+--------+--------+--------+--------+
coding 01111110 00000000 00000000 xxxxxxxx cccccccc 01111110
DCN Local-Network Protocols Page 25
D.L. Mills
With respect to this diagram, each octet is transmitted starting from
the leftmost octet, with the bits of each octet transmitted low-order
bit first. The code xxxxxxxx represents the data portion and cccccccc
represents the checksum. The bits between the "Flag" fields are
encoded with a bit-stuffing convention in which a zero bit is stuffed
following a string of five one bits. The "Addr" and "Ctrl" fields are
not used and the checksum is ignored. The Internet datagram is placed
in the "Data" field, which must be a multiple of eight bits in length.
A.4. ARPANET 1822 Links Using Local or Distant Host Interfaces
Following is a description of the frame format used with ARPANET
1822 Local or Distant Host interfaces. These interfaces can be used
to connect a DCN host to an ARPANET IMP, Gateway or Port Expander or
to connect two DCN hosts together. When used to connect a DCN host to
an ARPANET IMP, Gateway or Port Expander, a 96-bit 1822 leader is
prepended ahead of the Internet datagram. The coding of this leader
is as described in BBN Report 1822. When used to connect two DCN
hosts together, no leader is used and the frame contains only the
Internet datagram.
A.5. ARPANET 1822 Links Using HDH Interfaces
Following is a description of the frame format used with ARPANET
1822 HDH interfaces. These interfaces can be used to connect a DCN
host to an ARPANET IMP or Gateway or to connect two DCN hosts
together. In either case, the frame format is as described in
Appendix J of BBN Report 1822.
A.6. X.25 LAPB Links Using RSRE Interfaces
Following is a description of the frame format used on X.25 LAPB
links with the Royal Signals and Radar Establishment interfaces.
These interfaces implement the X.25 Link Access Protocol - Balanced
(LAPB), also known as the frame-level protocol, using a frame format
similar to that described under A.3 above. Internet datagrams are
placed in the data portion of I frames and encoded with the
bit-stuffing procedure described in A.3. There is no packet-level
format used with these interfaces.
A.7. Ethernet Links
Following is a description of the frame format used on Ethernet links.
+-----------+-----------+------+------+-----+
| Dest Addr | Srce Addr | Type | Data | CRC |
+-----------+-----------+------+------+-----+
bits 48 48 16 ... 32
With respect to this diagram, each field is transmitted starting from
the leftmost field, with the bits of each field transmitted low-order
bit first. The "Dest Addr" and "Srce Addr" contain 48-bit Ethernet
addresses, while the "Type" field contains the assigned value for IP
datagrams (0800 hex) or for
DCN Local-Network Protocols Page 26
D.L. Mills
ARP datagrams (0806 hex). The Internet datagram is placed in the
"Data" field and followed by the 32-bit checksum. The Address
Resolution Protocol (ARP) is used to establish the mapping between
Ethernet address and Internet addresses.