The RFC Archive
 The RFC Archive   RFC 611   « Jump to any RFC number directly 
 RFC Home
Full RFC Index
Recent RFCs
RFC Standards
Best Current Practice
RFC Errata
1 April RFC



IETF RFC 611

Two changes to the IMP/Host Protocol to improve user/network communications

Last modified on Wednesday, March 8th, 2000

Permanent link to RFC 611
Search GitHub Wiki for RFC 611
Show other RFCs mentioning RFC 611







Network Working Group                                          D. Walden
RFC # 611                                                        BBN-NET
NIC # 21354                                            February 14, 1974

                  TWO CHANGES T0 THE IMP/HOST PROTOCOL
                TO IMPROVE USER/NETWORK COMMUNICATIONS*

1.  A Reminder

    When a host receives an IMP-Going Down message from its IMP (see
page 3-15 of BBN Report 1822, Specifications for the Interconnection of
a Host and an IMP), the Host should forward the information included in
the IMP-Going-Down message to its users from the network and its local
users of the network.  Further, we suggest that the Host keep this
information around after the IMP has gone down, in order to tell local
users who are attempting to use the network.

    In the next two sections of the RFC, we describe modifications to
the IMP/Host protocol which will allow the IMPs to distribute the same
sort of information about Hosts which are down.

2.  Expansion of the Host-Going-Down Message

    The type 2, Host-Going-Down, message described on page 3-1l of BBN
Report 1822 has not previously allowed for any provision by the Host for
additional information such as why, when, and for how long the Host is
going down. The following describes a modification to the Host-Going-
Down message which permits the Host to supply this additiona1
information.

    In a type 2, Host-Going-Down message, bits 17-28 give the time of
the Host's coming back up, bit-coded as follows:

bits 17-19:  the day of the week the Host is coming back up. Monday is
             day 0 and Sunday is day 6.

bits 20-24:  the hour of the day, from hour 0 to hour 23, that the Host
             is coming back up.

bits 25-28:  the five minute interval, from 0 to 11, in the hour that
             the Host is coning back up.

----------
*Please file this RFC with your copy of BBN Report 1822 until that
report is updated.






Walden                                                       PAGE 1 top


RFC 611 Changes to IMP/Host Protocol February 1974 All three of the above or to be specified in Universal time (i.e., G.M.T.). The Host may indicate that it will be coming back up more than a week away by setting bits 17-28 all to ones. Setting all bits 17-27 to one and bit 28 to zero means it is unknown when the host is coming back up. Bits 29-32 of the Host-Going-Down message should be used by the Host to specify the reason it is going down. These bits are coded as follows: Value Meaning ----- ------- 0-4 Reserved for IMP use (see Section 3 below) 5 Scheduled P.M. 6 Scheduled Hardware Work 7 Scheduled Software Work 8 Emergency Restart 9 Power Outage 10 Software Breakpoint 11 Hardware Failure l2-15 Currently Unused It is assumed that as the time for the Host to go down approaches, the Host itself will send warning messages to its network users. Just before going down, the Host should send the Host-Going-Down message to its IMP. The IMP will store this message and return it to the source Host along with Destination (Host) Dead messages. The IMP will try to preserve this message over IMP reloads where appropriate. The NCC will be able to update manually the stored copy of this message in response to a phone call from the Host site in the event the Host is going to be down longer than it said or if it didn't have time to say before going down. 3. Addition of the Dead Host Status Message The type 7, destination dead, message described on page 3-16 of BBN Report 1822, does not allow for providing the reason for the Destination Host's being "dead". An additional IMP to Host message is therefore being added which provides status information on the dead Host. This message is type 6, Dead Host Status, and will provide the additional information as follows: Bits 17-28 have the same meanings as bits 17-28 in the Host-Going- Down message described in Section 2 above. Walden PAGE 2 top

RFC 611 Changes to IMP/Host Protocol February 1974 Bits 29-32 have the following meanings: Value Meaning ----- ------- 0 The destination Host is not communicating with the network -- the destination IMP has no information about the cause. Note that this is the message most likely to occur if the destination IMP has gone down since the destination Host went down. 1 The destination Host is not communicating with the network -- it took its ready-line down without saying why. 2 The destination Host is not communicating with the network -- the Host was tardy in taking traffic from the network and the network had to declare the Host down. 3 The destination Host does not exist to the knowledge of the NCC. 4 Currently unused. 5 The destination Host is down for scheduled P.M. 6 The destination Host is down for scheduled hardware work. 7 The destination Host is down for scheduled software work. 8 The destination Host is down for emergency restart. 9 The destination Host is down because of power outage. 10 The destination host is stopped at a software breakpoint. 11 The destination Host is down because of a hardware failure. 12-15 Currently unused. When the value of this 4-bit field is 0,1,2, or 3, bits 17-28 will have the "unknown" indication. Bit 1 in this message will always be set to zero and Hosts receiving this message should discard without reporting an error type 6 messages with bit 1 set to 1. This will allow later addition of similar status information on dead destination IMPs. Walden PAGE 3 top

RFC 611 Changes to IMP/Host Protocol February 1974 The Dead Host Status message will be returned to the source Host shortly (immediately, if possible) after each Destination Host Dead message. The Destination Host Dead message applies to a specific message-id (link) although the information contained in the Destination Host Dead message should probably be reported to all users connected to the dead Host. The Dead Host Status message does not apply to a specific message-id (link) and all users connected to the dead Host should be notified of the information contained in the Dead Host Status message. The modifications mentioned in Section 2 and 3 above will be put into the network very soon, and we urge the Hosts to implement the code necessary to take advantage of these modifications as soon as possible. This modification is backward compatible with the exception (!) that Hosts which have not done the implementation can receive a type 6 message which they do not know how To handle and will presumably log as an error. [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alex McKenzie with ] [ support from GTE, formerly BBN Corp. 1/2000 ] Walden PAGE 4 top

Two changes to the IMP/Host Protocol to improve user/network communications RFC TOTAL SIZE: 7481 bytes PUBLICATION DATE: Wednesday, March 8th, 2000 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 611: The IETF Trust, Wednesday, March 8th, 2000
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement