The RFC Archive
 The RFC Archive   RFC 22   « 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 22

Host-host control message formats

Last modified on Friday, September 29th, 2006

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







Network Working Group                                          Vint Cerf
Request for Comments: 22                                            UCLA
                                                        October 17, 1969


                   Host-Host Control Message Formats

   NWG/RFC 11 has been modified at UCLA; and will be republished.  In
   the meantime, it seems important to report a new control message
   format which does not use 7-bit ASCII character mode of transmission.

   All Host-Host control messages consist of sequences of 8-bit bytes of
   the form:

   <control byte> <parameter byte l> ... <parameter byte n>

   It is reasonable to transmit more than one control message in any
   given packet, although this is not mandatory.

   Presently, 9 control messages have been defined by UCLA; these are
   given in the table below along with their parameters.  The
   interpretation is given from the point of view of the transmitting
   host. ("L" or "Li" mean Link#, and are binary values.)

   Control byte     Parameter      Interpretation

    <0>             <L>           Please establish primary connection;
                                  our output link # is L

    <1>             <L,> <L2>     Please establish auxiliary connection
                                  parallel to our primary output link L.
                                  The auxiliary output link is L2.

    <2>             <L1> <L2>     DK primary.  Your primary output link
                                  to us was L; our primary output link
                                  to you is L2.

    <3>             <L1> <L2>     OK auxiliary.  Your auxiliary output
                                  link is Li, our auxiliary output link
                                  is L2.

    <4>             <L>           Not OK primary.  We cannot establish a
                                  primary connection.  Your primary
                                  output link number was L.

    <5>             <Li> <L2>     Not OK auxiliary.  We cannot establish
                                  an auxiliary connection.  Your primary
                                  output link no was L2.



Cerf                                                         PAGE 1 top


RFC 22 Host-Host Control Message Formats October 1969 <6> <L> Please stop transmitting over link number L. This is called the CEASE directive. <7> <L> We are CLOSING our output link number L. You may get this message before the last message arrives over this link since control messages are higher priority than regular data messages. <8> <L> UNCEASE: that is, you may resume transmitting over output link number L. Each control message is embedded in the appropriate message structure e.g.: <-------------32 bits ---------------> | HEADER | |____________________________________| | | | | | | mark | l | <L1> | <L2> | |______|_______|___________|_________| | | | | checksum | Padding | |_________________|__________________| typical control message (please establish auxiliary link #L2 parallel to our primary link #l) The header for all HOST-HOST control messages is given below: 0 3 4 7 8 9 10 14 LINK# 24 31 _______________________________________________________________ | | | | | |////////////////| | FLAGS | TYPE | H | SITE | 00000001 |////////////////| |_______|______|_____|_______|_______________|________________| where FLAGS - 0000 TYPE - 0000 (regular message) H - host #(0-3) at SITE (usually 0 for single HOST sites) SITE - Site # LINK# - 00000001 (HOST-HOST control link) [ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Alison De La Cruz 12/00 ] Cerf PAGE 2 top

Host-host control message formats RFC TOTAL SIZE: 4607 bytes PUBLICATION DATE: Friday, September 29th, 2006 LEGAL RIGHTS: The IETF Trust (see BCP 78)


RFC-ARCHIVE.ORG

© RFC 22: The IETF Trust, Friday, September 29th, 2006
© the RFC Archive, 2024, RFC-Archive.org
Maintainer: J. Tunnissen

Privacy Statement