Updates for new RFC.

Author: larsbrinkhoff

doc/rfc-new.txt

@@ -9,6 +9,13 @@ Obsoletes: 165, 636, 6529                                      J. Postel
 
 Abstract
 
+ | The Internet community is challenged by ever changing protocols of
+ | increasing complexity.  The authors suggest the community might be
+ | better served by switching to a protocol that is simple and
+ | unlikely to ever change again.  Thus we present what is believed to
+ | be the last and final edition of the ARPA Network Host/Host
+ | Protocol.
+
    This document reproduces the Host/Host Protocol developed by the ARPA
    Network Working Group during 1969, 1970, and 1971.  It describes a
    protocol used to manage communication between processes residing on
@@ -140,6 +147,8 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    curious gap in the historical record.  It is to fill that gap that
    this RFC is offered.
 
+ | Maybe add more here.
+
    In 1972, most ARPA Network documents, RFCs and others, were prepared
    and distributed in hard copy.  The Host/Host Protocol document was
    typed on a typewriter (probably an IBM Selectric), which had
@@ -304,6 +313,16 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    In addition to the above, several minor editorial changes have been
    made.
 
+ | This document supersedes RFC 6529 of the same title.  Principal
+ | differences between the documents include:
+ |
+ |    - clarifies non-control messages also have the header,
+ |    - a brief description of the Initial Connection Protocol
+ |      from RFC 165,
+ |    - addition of the RAR, RAS, RAP, NXR, and NXS opcodes from
+ |      RFC 636,
+ |    - assigned link numbers from RFC 1060.
+
    Although there are many individuals associated with the network who
    are knowledgeable about protocol issues, individuals with questions
    pertaining to Network protocols should initially contact one of the
@@ -404,7 +423,7 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    through wideband communications lines supplied by the telephone
    company.  Each IMP is programmed to store and forward messages to the
    neighboring IMPs in the network.  During a typical operation, a Host
-   passes a message to its local IMP; the first 32 bits of this message
+ | passes a message to its local IMP; the first 32 or 96 bits of this message
    include the "network address" of a destination Host.  The message is
    passed from IMP to IMP through the Network until it finally arrives
    at the destination IMP, which in turn passes it along to the
@@ -451,6 +470,8 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    1) An _Initial_Connection_Protocol_ (ICP) which provides a convenient
       standard method for several processes to gain simultaneous access
       to some specific process (such as the "logger") at another Host.
+ |    This protocol has since been adopted as the method to initiate
+ |    a communication path for all application protocols.
 
    2) A _Telecommunication_Network_ (TELNET) protocol which provides for
       the "mapping" of an arbitrary keyboard-printer terminal into a
@@ -478,7 +499,9 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
       over Hosts which provide batch processing facilities.
 
    The remainder of this document describes and specifies the Host/Host,
-   or second level, protocol as formulated by the Network Working Group.
+   or second level, protocol as formulated by the Network Working Group,
+ | as well as the Initial Connection Protocol that is now integral to the
+ | Host/Host protocol.
 
 
 
@@ -622,7 +645,8 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    that byte size, then the outer layer of protocol will not be
    implementable on that Host.
 
-   The IMP sub-network requires that the first 32 bits of each message
+ | The original protocol on the IMP sub-network requires that the first
+   32 bits of each message
    (called the leader) contain addressing information, including
    destination Host address and link number.  The second level protocol
    extends the required information at the beginning of each message to
@@ -631,9 +655,15 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    conveniently with 8-bit units of data or have word lengths of 18 or
    36 bits; 72 is the least common multiple of these lengths.  Thus, the
    length chosen for the message header should reduce bit-shifting
-   problems for many Hosts.  In addition to the leader, the message
+   problems for many Hosts.
+ | In 1976, the leader was extended to 96 bits, and the host was
+ | allowed to specify some number of 16-bit padding words between the
+ | leader and the message data portion.
+   In addition to the leader, the message
    header includes a field giving the byte size used in the message, a
    field giving the number of bytes in the message, and "filler" fields.
+ | Note that the message header applies to both control messages and
+ | regular messages containing data.
    The format of the message header is fully described in Section IV.
 
    Another major concern of the second level protocol is a method for
@@ -804,6 +834,68 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    _queueing_facility._  This is not, however, an absolute requirement
    of the protocol.
 
+ | _Initial Connection Protocol_
+ |
+ | RFC 165 specifies a procol that allows a server to listen to some
+ | particular well-known socket number, and then establish two
+ | connections for full-duplex communication between the server and
+ | user processes.  To do this, first a temporary simplex connection
+ | is opened for the server to transfer a new socket number to the
+ | user.  Then this socket is the basis for opening two new
+ | connections between the two processes, and the first connection is
+ | closed.
+ |
+ | Below, the well-known socket is called L.  The temporary connection
+ | is initiated by the user from socket U.  The new socket number is
+ | S, and the full-duplex connections are between S and U+3, and S+1
+ | and U+2.
+
+   Server                          User
+
+   S1: listening on socket L.      U1: RTS (U, L, _l1_)
+
+   S2: Wait for match.             U2: Wait for match.
+
+   S3: STR (L, U, _s1_)
+
+   S4: Wait for allocation.        U3: All (_l1_, _m1_, _b1_)
+
+   S5: Send data S in_s1_ bit      U4: Receive data S in s1 bit bytes.
+       bytes as allowed by             _s1_ bit bytes.
+       allocation m1_, _b1_).
+
+   S6: CLS (L, U)                  U5: CLS (U, L)
+
+   S7: RTS (S, U+3, _l2_)          U6: STR (U+3, S, _s2_)
+
+   S8: STR (S+1, U+2, _s3_)        U7: RTS (U+2, S+1, _l3_)
+
+   The labels here imply no ordering except that ordering required by
+   the Host-Host Protocol.  Note that steps S7 and S8 can be reversed as
+   can U6 and U7.  Also, notice that at any time after S2 the server
+   could initiate steps S7 and S8 in parallel with steps S3 through S6,
+   and that at any time after U4 the user could initiate steps U6 and U7
+   in parallel with step U5.
+
+   Following the above, exchanges ALL commands would be exchanged and
+   data transfers could begin.
+
+   At this level the parameters of the above ICP family are L, _m1_,
+   _b1_, _s1_, _s2_, _s3_, _l1_, _l2_, _l3_.
+
+   L is a well known socket number and will be specified for each type
+   of service.
+
+   m1 and b1 are allocation quantities for the transfer of a socket
+   number.
+
+      _m1_ is specified to be 1.
+      _b1_ is specified to be 32.
+      _s1_, _s2_, and _s3_ are byte sizes.  Only _s1_ is to be specified
+         as _s2_ and _s3_ are to be left to the process involved.
+      _s1_ is specified to be 32.
+
+      _l1_, _l2_, and _l3_ are links and are not specified.
 
    Connection Termination
    ======================
@@ -1357,12 +1449,38 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
 
       2-71           Available for connections
 
-      1, 72-190      Reserved - not for current use
+      1, 72-149      Reserved - not for current use
+
+ |    150            Xerox NS IDP
+ |
+ |    151            Unassigned
+ |
+ |    152            PARC Universal Protocol
+ |
+ |    153            TIP Status Reporting
+ |
+ |    154            TIP Accounting
+ |
+ |    155            Internet Protocol [regular]
+ |
+ |    156-158        Internet Protocol [experimental]
+ |
+ |    159            Figleaf Link
+ |
+ |    160            Blacker Local Network Protocol  
+ |
+ |    161-190        Unassigned
 
       191            To be used only for measurement work under the
                      direction of the Network Measurement Center at UCLA
 
-      192-255        Available for private experimental use.
+ |    192-194        Unassigned
+ |
+ |    195            ISO-IP       
+
+      196-247        Available for private experimental use.
+
+ |    248-255        Network Maintenance
 
 
    Control Messages
@@ -1543,6 +1661,60 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
    allocations in response to a GVB command.  This command may be sent
    only while the connection is established.
 
+ | RAR - Reset allocation by receiver
+ | ==================================
+ |
+ |         8      8
+ |      +------------+
+ |      | RAR | link |
+ |      +------------+
+ |
+ | Sent in reply to RAS to acknowledge allocations have been reset.
+ | The RAR command is sent from the Host receiving on "link" to the
+ | Host sending on "link" in response to an RAS.  It marks the
+ | completion of the connection resynchronization.  When the RAR is
+ | returned the connection is in the known state of having no messages
+ | in transit in either direction and the allocations are zero.  The
+ | receiving Host may then start afresh with a new allocation and
+ | normal message transmission can proceed.  Since the RAR may be sent
+ | ONLY in response to an RAS, there are no races in the
+ | resynchronization.  All of the initiative lies with the sending
+ | Host.
+ |
+ | RAS - Reset allocation by sender
+ | ================================
+ |
+ |         8      8
+ |      +------------+
+ |      | RAS | link |
+ |      +------------+
+ |
+ | Tells the receiver to clear allocations for the specified link.
+ | The RAS command is sent from the Host sending on "link" to the Host
+ | receiving on "link".  This command may be sent whenever the sending
+ | Host desires to resynch the status information associated with the
+ | connection (and doesn't have a message in transit through the
+ | network).
+ |
+ | RAP - Reset allocation please
+ | =============================
+ |
+ |         8      8
+ |      +------------+
+ |      | RAP | link |
+ |      +------------+
+ |
+ | Sent from receiver to sender to ask it to send an RAS.  If the
+ | receiving Host detects an anomalous situation, the RAP command is
+ | provided.  It constitutes a "suggestion" on the part of the
+ | receiving Host that the sending Host resynchronize; the sending
+ | Host is free to honor it or not as it sees fit.  Since there is no
+ | obligatory response to a RAP, the receiving Host may send them as
+ | frequently as it chooses and no harm can occur.  For example, if a
+ | message in excess of the allocate arrives, the receiving Host might
+ | send RAPs every few seconds until the sending Host replies with no
+ | fears of races if one or more RAPs pass a RAS in the network.
+
    INR - Interrupt by receiver
    ===========================
 
@@ -1690,6 +1862,28 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
            field are the message header followed by the first eight bits
            of text (if any) or zeros.
 
+ | NXR - Non-existent receive link
+ | ===============================
+ |
+ |         8      8
+ |      +------------+
+ |      | NXR | link |
+ |      +------------+
+ |
+ | Tells sender the link it used is non-existant.  On receipt of an
+ | NXR, the sender should close the connection.
+ |
+ | NXS - Non-existent send link
+ | ============================
+ |
+ |         8      8
+ |      +------------+
+ |      | NXS | link |
+ |      +------------+
+ |
+ | Tells receiver the link it used is non-existant.  On receipt of an
+ | NXS, the receiver should close the connection.
+
    Opcode Assignment
    =================
 
@@ -1710,6 +1904,11 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
       ERR = 11
       RST = 12
       RRP = 13
+      RAR = 14
+      RAS = 15
+      RAP = 16
+      NXR = 17
+      NXS = 18
 
 
    Control Command Summary
@@ -1803,6 +2002,30 @@ RFC XXXX         Host-Host Protocol for the ARPA Network      April 2012
         | RRP |
         +-----+
 
+ |         8      8
+ |      +------------+
+ |      | RAR | link |
+ |      +------------+
+ |
+ |         8      8
+ |      +------------+
+ |      | RAS | link |
+ |      +------------+
+ |
+ |         8      8
+ |      +------------+
+ |      | RAP | link |
+ |      +------------+
+ |
+ |         8      8
+ |      +------------+
+ |      | NXR | link |
+ |      +------------+
+ |
+ |         8      8
+ |      +------------+
+ |      | NXS | link |
+ |      +------------+