rfc891.txt

RFC 相关的技术文档


DCN Local-Network Protocols                                        Page 21
D.L. Mills


    4.  For precise timekeeping, the offset can be considered valid only if
        the length of the last HELLO packet transmitted is equal to
        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.