rfc1705.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,438 行 · 第 1/5 页

   The Internet community has a large installed base of IP users.  The
   resources required to operate this network,  both people and machine,
   is enormous.  These resources will need to be preserved.  The last
   time a change like this took place, moving from NCP to TCP, there
   were a few 100 nodes to deal with [Postel, 1981c].  A small close
   knit group of engineers managed the network and mandated a one year
   migration strategy.  Today there are millions of nodes and thousands
   of administrators.  It will be impossible to convert any portion of
   the Internet to a new protocol without effecting the rest of the
   community.

   In the worst case, users will lose communications with their peers as
   some systems upgrade and others do not.  In the current global
   environment, this will not be tolerated.  Any attempt to simply
   replace the current IPv4 protocol with a new IPng protocol that does
   not address compatibility issues is doomed to failure.  This
   reasoning has recently been realized by Ullmann (CATNIP) and he
   attempts to use translators to convert from one protocol to another
   (i.e., CATNIP to IPv4).  The problem is what to do when incompatible
   parameters are encountered.  Also CATNIP would need to be replaced
   every time a new network layer protocol was developed.

   This proposal attempts to solve these problems by decoupling the
   transport and network protocols.  By allowing TCP to operate over
   different network layer protocols, we will create a more stable
   environment.  New network layer protocols could be developed and
   implemented without requiring changes that are visible to the user
   community.  As TCP packets flow from host-to-host they may use
   several different network layers, allowing users to communicate
   without having to worry about how the data is moved across the



Carlson & Ficarella                                            [Page 16]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


   underlying network.

4.5.1  Backward Compatibility

   It may be said that the maturity of a software package can be
   determined by how much code is required to maintain compatibility
   with previous versions.  With the current growth of the Internet,
   backward compatibility issues can not be dismissed or added in as an
   after thought.  This version of TCP was designed with backward
   compatibility in mind. When the TCP communicates with an unmodified
   IPv4 TCP/IP, it takes steps to insure compatibility.  First off it
   sets a bit in the header indicating that the TCP parameters (ack,
   seq, port numbers, and window size) use the TCPv6 values.  When
   communicating directly with an unmodified host the existing TCP/IP
   header is used.  Only existing TCP options may be sent as well.

   The advantage of this approach is that TCP transporter nodes will not
   have to make decisions about how to modify packets just passing
   through.  It is up to the source node to build a header that is
   compatible before sending it.  This approach will allow any new TCP
   to contact and communicate with any unmodified IPv4 host.  The source
   host may have an IPv4 address, or it may send data to a transporter
   for delivery.  The decision will be made based on the source and
   destination addresses.  During connection setup, the location of the
   destination node is determined and the proper network layer is used
   to send data.

   An existing IPv4 host will be capable of opening a connection to any
   new TCPng host that is directly connected to the network with an IPv4
   protocol stack.  If the TCPng host only has an IPng stack, the
   connection attempt will fail.  Some existing batch style services
   (i.e., Simple Mail Transfer Protocol - SMTP) will continue to work
   with the help of transporters.  Interactive sessions (i.e., Telnet)
   will fail.  Thus, our new TCP is backward compatible, but the
   existing IPv4 hosts are not forward compatible.

4.6  Level 4 Gateways

   The ability to allow hosts with differing network layer protocols to
   communicate will be accomplished by using a transport layer gateway
   (called transporter in this paper).  The transporter works just like
   an IP router, receiving TCP packets from one network layer and
   transporting them over to another.  This switching is done by
   examining the packets source and destination TA's.  If a TCP packet
   arrives with a destination TA that differs from this hosts TA, and
   the transporter functionality is enabled, the packet should be
   transported to another network layer.  In some cases, the receiving
   node is a host and not a transporter (i.e., transporter functionality



Carlson & Ficarella                                            [Page 17]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


   disabled).  In this case the host will discard the packet and return
   a TCMP (see below) error message.

   A transporter is not responsible for reading or formatting the TCP
   header of packets it receives.  The header is simply examined to
   determine where to deliver the packet.  When forwarding, the packet
   is sent to any of the network layers the transporter supports.  The
   exception is that the packet may not be presented back to the network
   it was received from. It is the responsibility of the network layer
   to destroy undeliverable packets.  If a transporter is unable to
   determine which network the packet should be forwarded to, the packet
   is discarded and a TCMP message is generated and returned to the
   original source host.  Several examples of how transporting works are
   presented in appendix D.

4.7  Error Conditions

   It is recognized that from time to time certain error conditions will
   occur at some intermediate transporter that will need to be
   communicated back to the source host.  To accomplish this a Transport
   Control Message Protocol (TCMP) service facility will need to be
   developed.  This protocol will model itself after the Internet
   Control Message Protocol (ICMP).  The operational details are
   discussed in a separate TCMP document.

5.  Advantages and Disadvantages of this approach

   This proposal offers the Internet community several advantages.
   First, TCPng will operate over multiple network layer protocol
   stacks.  Users will be able to select the stack(s) that meets their
   needs.  The problem of IPv4 address exhaustion will be postponed as
   sites move from IPv4 to IPng protocol stacks. Future IP3g protocol
   stacks may be designed and deployed without major service
   disruptions.  The increased size of the sequence, acknowledge, and
   window fields will allow applications to run effectively over high
   bandwidth-delay network links.  Lastly, TCPng will allow applications
   to specify certain Quality of Service (QoS) parameters which may be
   used by some network layer protocols (i.e., Asynchronous Transfer
   Mode - ATM).

   This protocol is not without it's share of design compromises.  Among
   these are a large packet header increased in size from 5 to 12 long
   words.  The addition of a TA means that network administrators must
   deal with yet another network number that must be globally
   maintained.  Multiple network protocols may add to the complexity of
   a site's network.  Lastly, is the TA address space large enough so we
   will not have to rebuild TCP.




Carlson & Ficarella                                            [Page 18]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


6.  Conclusions

   In this paper, we have reviewed the current status of the Internet
   society s IPng initiative.  We were struck by the enormity of the
   changes required by those proposals.  We felt that a different
   approach was needed to allow change to occur in a controlled manner.
   This approach calls for replacing the current TCP protocol with one
   that does not require a specific IP layer protocol.  Once this is in
   place, various IPng protocols may be developed and deployed as sites
   require them.  Communications between IPv4 and IPng hosts will be
   maintained throughout the transition period.  Modified hosts will be
   able to remove their IPv4 protocol stacks, while maintaining
   communications with unmodified hosts by using a TCP transporter.

   The title of this paper "Six Virtual Inches to the Left" comes from a
   talk the author once heard.  In this talk an engineer from Control
   Data Corporation (CDC) told a story of CDC's attempt to build a
   cryogenically cooled super computer.  The idea being that the power
   consumption of such a computer would be far lower then that of a
   conventional super computer.  As the story goes, everyone thought
   this was a great idea until someone pointed out what the power
   requirements of the cryo system were.  The result was that all the
   assumed power savings were consumed by the cryo system.  The
   implication being that all the power requirements were not saved but
   simply moved 6 feet from the CPU to the support equipment.  The moral
   being that the entire system should be analyzed instead of just one
   small piece.

References

   [Postel, 1981a] Postel, J., "Transmission Control Protocol - DARPA
   Internet Program Protocol Specification", STD 7, RFC 793, DARPA,
   September 1981.

   [Halsal, 1992] Data Communications, Computer Networks, and Open
   Systems.

   [Meyer, Zobrist, 1990] TCP/IP versus OSI, The Battle of the
   Network Standards, IEEE Potentials.

   [Braden, et al, 1991] Clark, D., Chapin, L., Cer, V., Braden, R., and
   R. Hobby, "Towards the Future Internet Architecture", RFC 1287,
   MIT, BBN, CNRI, ISI, UCDavis, December 1991.

   [Dixon, 1993] Dixon, T., "Comparison of Proposals for Next Version of
   IP", RFC 1454, RARE, May 1993.





Carlson & Ficarella                                            [Page 19]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


   [Fuller, et al, 1992] Fuller, V., Li, T., Yu, J., and K. Varadhan,
   "Supernetting: an Address Assignment and Aggregation Strategy",
   RFC 1338, BARRNet, cicso, Merit, OARnet, June 1992.

   [Almquist, Gross, 1992] Gross, P., and P. Almquist, "IESG
   Deliberations on Routing and Addressing", RFC 1380, IESG Chair,
   IESG Internet AD, November 1992.

   [Postel, 1981b] Postel, J., "Transmission Control Protocol - DARPA
   Internet Program Protocol Specification", STD 7, RFC 793, DARPA,
   September 1981.

   [Postel, 1980] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
   USC/Information Sciences Institute, August 1980.

   [Postel, 1981c] Postel, J., "NCP/TCP Transition Plan", RFC 801,
   USC/Information Sciences Institute, November 1981.

   [Leiner, Rekhter, 1993] Leiner, B., and Y. Rekhter, "The
   Multi-Protocol Internet" RFC 1560, USRA, IBM, December 1993.

   [Ullmann, 1993] Ullmann, R., "TP/IX: The Next Internet", RFC 1475,
   Process Software Corporation, June 1993.

Bibliography

   Gilligan, Nordmark, and Hinden, "The SIPP Interoperability and
   Transition Mechanism", IPAE, 1993.

   Jacobson, V., and R. Braden, "TCP Extensions for Long-Delay Paths",
   RFC 1072, LBL, USC/Information Sciences Institute, October 1988.

   Jacobson, V., Braden, R., and D. Borman, "TCP Extensions for High
   Performance", RFC 1323, LBL, USC/Information Sciences Institute, Cray
   Research, May 1992.

   Jacobson, V., Braden, R., and L. Zhang, "TCP Extension for High-Speed
   Paths", RFC 1185, LBL, USC/Information Sciences Institute, PARC,
   October 1990.

   Leiner, B., and Y. Rekhter, "The Multiprotocol Internet", RFC 1560,
   USRA, IBM, December 1993.

   O'Malley, S., and L. Peterson, "TCP Extensions Considered Harmful",
   RFC 1263, University of Arizona, October 1991.

   Westine, A., Smallberg, D., and J. Postel, "Summary of Smallberg
   Surveys", RFC 847, USC/Information Sciences Institute, February 1983.



Carlson & Ficarella                                            [Page 20]

RFC 1705     Six Virtual Inches to the Left: IPng Problems  October 1994


Appendix A

   The minimum size of an ethernet frame is 64 bytes.  With the existing
   TCP/IP protocol, a minimum size frame is 18 bytes (ethernet header &
   trailer) + 20 bytes (IP header) + 20 bytes (TCP header) for a total
   of 58 bytes.  The transmitting station must add 6 null pad characters
   to this frame to make it conform to the 64 byte minimum.  This new
   TCP will increase the size of the TCP header to 48 bytes.
   Subtracting 26 bytes (the old header and pad characters) we are left
   with 22 bytes or 176 bits.  The time it takes to transmit these
   additional bits is the impact of this new TCP.  The transmission time
   for several types of media currently used is shown in the table
   below.  You will note that the increased times are all under 20
   micro-seconds for anything over T1 speeds.  User traffic patterns
   vary of course but it is generally agreed that 80% of the traffic
   stays at the local site.  If this is true then the increased header
   size has a negligible impact on communications.


      Media       Speed (Mbps)      Rate  (nsec/bit)  time (usec)
      ------      ------------      ---------------   ----------
        T1            1.544            647.7            144.00
        T3           44.736             22.4              3.91
        Enet         10.00             100.0             17.60
        FDDI        100.00              10.0              1.76
        OC-1         51.84              19.3              3.40