GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:ien:ien2

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]

/data/webs/external/dokuwiki/data/pages/rfc/ien/ien2.txt · Last modified: 2001/06/25 18:22 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki