|
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 |