IEN # 2 Comments on Internet Protocol and TCP IEN # 2 Jon Postel Supercedes: None ISI Replaces: None 15 August 1977 2.3.3.2 Comments on Internet Protocol and TCP Introduction This memo suggests an approach to protocols used in internetwork systems somewhat different from the main thrust of the work on the Transmission Control Protocol (TCP) [1]. The position taken here is that internetwork communication should be view as having two components: the hop by hop relaying of a message, and the end to end control of the conversation. This leads to a proposal for a hop by hop oriented internet protocol, an end to end oriented host level protocol, and the interface between them. Discussion We are screwing up in our design of internet protocols by violating the principle of layering. Specifically we are trying to use TCP to do two things: serve as a host level end to end protocol, and to serve as an internet packaging and routing protocol. These two things should be provided in a layered and modular way. I suggest that a new distinct internetwork protocol is needed, and that TCP be used strictly as a host level end to end protocol. I also believe that if TCP is used only in this cleaner way it can be simplified somewhat. A third item must be specified as well -- the interface between the internet host to host protocol and the internet hop by hop protocol. An analogy may be drawn between the internet situation and the ARPANET. The endpoints of message transmissions are hosts in both cases, and they exchange messages conforming to a host to host protocol. In the ARPA subnet there is a IMP to IMP protocol that is primarily a hop by hop protocol, to parallel this the internet system should have a hop by hop internet protocol. In the ARPANET a host and an IMP interact through an inteface, commonly called 1822, which specifies the format of messages crossing the boundary, an equivalent interface in needed in the internet system. In the rest of this memo i outline first a possible internet host - hop interface, second an internet hop by hop protocol, and third some modifications to TCP so that it can serve as an internet host level protocol. Internet Host - Hop Interface Section 2.3.3.2 [page 1] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Internet Host - Hop Interface It is difficult to present a protocol and an interface separately. In this section i present the fields and functions used in the internet host - hop interface. The discussion will however explain some of the operation of the internet hop by hop protocol as well. I suggest an internet hop by hop protocol that provides only those functions needed to address and route messages in an arbitrarily structured network, to allow for fragmentation and reassembly of fragments, to provide various types of service, and a moderate level of error control. The internet host - hop interface is described by discussing the use made of each of the fields in the interface message header. Version As time goes by the internetwork system may evolve to a point where the interface format (or the protocol) must be changed. This field provides the handle for simultaneously supporting two (or more) versions of the protocol. Data Identifier and Acknowledgement Identifier When a message is sent from a host to a hop module, or between hop modules, or from a hop module to a host, it must be acknowledged. To allow several messages to be in transit simultaneously an identifier is used to associate data messages and acknowledgements. Type of Service Because different applications may call for different aspects of communication performance to be emphasised a type of service field is necessary. For example one application may call for reliable delivery and be willing to suffer longer delays or lower throughput for it. Another application may not be able to tolerate the slightest delay but be unconcerned about reliability. The type of service field has the following assigned values: 0 - reliable delivery requested This means that at each hop the message (or fragment) is retransmitted to the next hop until an acknowledgement is received. 1 - no retransmission Section 2.3.3.2 [page 2] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Internet Host - Hop Interface This means that at each hop the message (or fragment) is transmitted exactly once to the next hop, if it is afflicted with errors, too bad. Addresses Addresses are variable length strings of 4 bit chunks prefixed by a length. As address chunks are processed they are removed from their position at the head of the address chunk string and placed at the end of the string. This chunk by chunk circular shifting of the address allows each node in the hop by hop processing of a message to examine the part of the address it consumes with out knowing how much address preceeds or follows that part. Fragmentation Fragmentation is an internet protocol problem rather than a host level problem. Fragmentation is necessary because of the differing sizes of maximum message allowed by the various networks making up the internetwork system. The possibility of a large message being routed or delivered in a network with a smaller maximum message size requires that the internet protocols provide for fragmentation. Any where along the transmission path an internet protocol node may fragment a message (which already may be a fragment). Only at a point where all fragments must pass can reassembly of the fragments be done. Usually the only point that meets this constraint is the destination host. To understand a little about the fragmentation information carried in the internet protocol header we examine the information needed to reassemble fragments and the possible ways to provide that information. What does the reassembler need to know? What message is this a fragment of? - Message Identifier Where in the message does this fragment go? - Fragment Number and Size Are all the fragments of this message here? - Number of Fragments or Last Fragment Flag What can the fragmenter (original or intermeadiate) provide? Section 2.3.3.2 [page 3] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Internet Host - Hop Interface It may be easier to say what it can not do: It can't keep a count of total fragments carried in each fragment because some fragments may get split while others do not in a alternate routing environment. It can't know what fragment identifiers have already been used. It can do these things: It can pass on a last fragment flag. It can pass on fragment numbers that are hierarchial or based of data length such as data sequence numbers. It can pass on a message identifier. It can pass on a data length. The difficult issue is how best to identify where this fragment fits with respect to other fragments when trying to reassemble a message. Two schemes seem workable: a hierachial fragment naming scheme, and a sequence number scheme. The hierachial scheme would call for a fragment name to be composed of a variable number of chunks. Each time a fragment was split each new fragment would get a copy of the old fragment name with an added chunk specifing the order between the just created fragments. These fragment names would then be equivalent to the names of the leaves of a tree. At the destination the reassembly would proceed by combining sibling leaves and replacing the mother node by the combined fragment. This scheme would require a last fragment flag for each set of siblings unless the degree of branching were fixed. The variable length fragment names are a complexity it would be nice to avoid. The sequence number scheme would call for each fragment to carry a fragment sequence number and a data length. Each original message could start with the fragment sequence number zero. When it was necessary to fragment a message the first fragment would carry the original fragment sequence number, while the second fragment would carry a fragment sequence number equal to the fragment sequence number of the first fragment plus the data length of the first fragment, and so on. The last fragment Section 2.3.3.2 [page 4] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Internet Host - Hop Interface would have to carry a last fragment flag. At the reassembly point adjacent fragments could be combined until the message was complete. Two messages are adjacent when the fragment sequence number of the second is equal to the fragment sequence number of the first plus the data length of the first. Message Identifier Each message to be fragmented must have an identifier unique to this end to end address pair, so that the fragments of one message may be distinguished from the fragments of another message. There is no need to coordinate the choice of this identifier between the source and destination. The source should choose the identifiers on messages it sends so as to avoid having two distinct messages to the same destination concurrently in circulation with the same identifier. The choice of message identifier could be clock based or a simple sequence and the same sequence could be spread across all outgoing messages or separate sequences could be used for each destination address. Data Ah the data, at last a space for the reason we are going through all this nonsense. There is a data length field, and then that much data. Error Control Only hop to hop error control should be attempted in the internet protocol. Specific host level protocols such as TCP can provide for end to end error control. The same checksum field is used to protect the communication between the source host and the first hop, and between the last hop and the destination host, as is used between hops. Section 2.3.3.2 [page 5] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Internet Host - Hop Interface Message Format The internet protocol message format has the following fields: Version Flags Data Identifier Acknowledgement Identifier Type of Service Destination Address Fragment Information Message Identifier Fragment Sequence Number Last Fragment Flag Data Length Data Checksum The Version field is a 4 bit field which indicates the version of the internet protocol the remainder of the message conforms to. This proposal describes version 0. The Type of Service field is a 4 bit field specifing which handling type is desired. The Flags are a set of bits which specify the presence or absence of values in certain fields, in particular there is a data flag which indicates the data identifier field is meaningful (and that the data length is nonzero), and a acknowledgement flag which indicates the acknowledgement identifier field is meaningful. The Data Identifier is a 16 bit field that distinguishes this message from other active messages on this host to hop, hop to hop, or hop to host, link. The Acknowledgement Identifier is a 16 bit field that specifies which message among the active messages on this host to hop, hop to hop, or hop to host, link this acknowledgement pertains to. The Destination Address field is a variable length extensible address composed of 4 bit chunks. The first chunk is the length of the address in chunks, except that the value 0 indicates that the next two chunks as a 8 bit number indicate the length. This address extension scheme actually goes on indefinitely: we Section 2.3.3.2 [page 6] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Internet Host - Hop Interface start with the length of the length equal to one, ll=1, if the value of the length is zero, l=0, then the next two chunks, ll_ll+1, are taken to be the length, if that length value is zero, l=0, then the next ll_ll+1 chunks are taken to be the length, and so on. The Fragmentation Information consists of three things: the message identifier which is a 16 bit field, the fragment sequence number which is a 16 bit field, and the last fragment flag which requires one bit. The Data Length is a 16 bit field whose value is the number of octets in the Data field. The Data field is as many octets of arbitrary data as specified in the data length field. The Checksum is a 16 bit field whose value is a hop by hop computed checksum that covers the entire message. Internet Hop Protocol The internet hop by hop protocol has nearly been described, at least by implication, in the preceeding section. In this section i will try to add a few details about the use of the fields in the hop by hop protocol. The Type of Service field specifies the handling type is desired. The intent here is for the hop module to tailor its treatment of this messages according to the value of this field. As previously indicated one kind of tailoring is a trade off between delay and reliability. I expect substantially more thought will be needed before a reasonable set of cases can be established for type of service. The Flags are bits which specify the presence or absence of values in certain fields: data flag - indicates the data identifier is meaningful acknowledgement flag - indicates the acknowledgement identifier is meaningful. The Data Identifier field distinguishes this message from other active messages on this host to hop, hop to hop, or hop to host, link. Section 2.3.3.2 [page 7] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Internet Hop Protocol The intention is that for each hop module to select its own data identifier to put on a messages for transmission to the next hop module. That each hop modules should choose identifiers to avoid having two active messages on this link with the same identifier should be obvious. The Acknowledgement Identifier specifies which message among the active messages on this host to hop, hop to hop, or hop to host, link this acknowledgement pertains to. The hop module copies the data identifier of a message, lets call it A, it receives into the acknowledgement identifier field and sets the acknowledgement identifier flag in a message, lets call it B, traveling to the sender of message A to acknowledge correct receipt and take responsibility for message A. The Destination Address field is processed by the hop module and the portion of the address consumed by the hop module is (chunk by chunk) circular shifted to the end of the address, bring the part of the address to be processed by the next hop to the beginning of the address string. Fragmentation is performed if nesessary. Reassembly is left for the destination host. Fragment Handling Procedures Necessary Fragment Information Fields Message Identifier Data Length Fragment Sequence Number (initially zero in each new message) Last Fragment Flag (initially set in each new message) Fragmentation Procedure Split the data. Copy the internet header from original message (or fragment) to each fragment. Replace the data length field of each fragment by the new data length. Section 2.3.3.2 [page 8] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Internet Hop Protocol Replace the fragment sequence number in each fragment by the correct value. The correct value of the fragment sequence number for fragment N+1 is the fragment sequence number of fragment N plus the data length of fragment N. Reset the last fragment flag in all but the last fragment. Reassembly Procedure If two fragments are of the same message and adjacent assemble them. If a fragment has fragment sequence number zero and the last fragment flag set then it is a whole message. Where assemble means form one fragment with fragment sequence number set to the fragment sequence number of the first fragment the data length set to the data length of the first fragment plus the data length of the second fragment last fragment flag set to the last fragment flag of the second fragment Where adjacent means the fragment sequence number plus the data length of the first fragment equals the fragment sequence number of the second fragment. The Data Length is only modified if fragmentation is done. The Data field is not examined at all. The Checksum must be checked as the first step in processing each message. If the checksum is not correct the message is discarded. When a message is forwarded to the next hop the checksum is recomputed if any change has been made. Since almost always the destination address is changed the checksum must be recomputed. And, of course, if a message has been fragmented a new checksum is necessary for each fragment. Section 2.3.3.2 [page 9] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Internet Hop Protocol To review, the internet hop by hop protocol message format has the following fields: FIELD BITS Version 4 Flags Data Identifier 1 Acknowledgement Identifier 1 Data Identifier 16 Acknowledgement Identifier 16 Type of Service 4 Destination Address variable Fragment Information Message Identifier 16 Fragment Sequence Number 16 Last Fragment Flag 1 Data Length 16 Data variable Checksum 16 Internet Host Protocol The internet host protocol is a slightly simplified TCP. The principal simplifications are that TCP no longer concerns itself with fragmentation, and that the addresses are of the same form as used in the internet hop protocol. The TCP should use the extensible addresses used in the hop by hop protocol. This means that the TCP need not carry a distinct copy of the destination address since it can be reconstructed from the internet host - hop message format. However since the TCP needs both the source and destination addresses in each message it may be useful to carry both in the host level header (which is treated as part of the data by the internet hop by hop protocol). Since TCP is no longer concerned about fragmentation the End of Letter flag is not necessary to any part of the TCPs internal workings. It may be a desirable feature for purposes of the TCP - user interface though. Model of Communication To pull all this together perhaps it would be helpful to have a scenario of a message transversing this system. Section 2.3.3.2 [page 10] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP Discussion Model of Communication First a source process turns some data over to a source host protocol module. The host protocol module packages the data up in the host level protocol. Then that package is wrapped up in the internet interface format and forwarded to an intenet hop module. The internet hop module then forwards the message according to the address processing rules. At any hop along the way the message may be fragmented, and the fragments separately forwarded toward the destination. When the message arrives at the destination it is first verified according to the internet hop by hop protocol (i.e. is the checksum correct?). Next the address is checked to be sure this really is the destination. Once this initial checking is done, the next step is to reassemble the fragments if that is necessary. Once the whole message is assembled it can be turned over to the host protocol module for processing. The host protocol module unpackages the data and passes it to the destination process. Summary A model of internetwork commuication has been presented that is based on components that separate and modularize the distinct functions of the host to host interaction controls and the hop by hop addressing and routing functions. An interface between these functional modules has been specified. It is argued that this approach is more appropriate than the attempts to make a single protocol cover both functions. Section 2.3.3.2 [page 11] 15 Aug 77 IEN # 2 Comments on Internet Protocol and TCP References References [1] Cerf, V. "Specification of TCP version 2," March 1977. Section 2.3.3.2 [page 12]