RFC 1560 (rfc1560) - Page 3 of 7

The MultiProtocol Internet

RFC 1560               The MultiProtocol Internet          December 1993


   The figure describes the process from the perspective of a community
   working on a single primary protocol suite (such as the IETF/IESG/IAB
   working on the TCP/IP protocol suite.) (Note: It must be kept in mind
   throughout this paper that, while the discussion is oriented from the
   perspective of the IETF/IESG/IAB and the TCP/IP protocol suite, there
   is a complementary viewpoint from the perspective of each of the
   communities whose primary focus is on one of the other protocol
   suites.) There are other protocol suites (for example, IPX, OSI,
   SNA).  Although the primary emphasis of the community is developing a
   system based on a single set of protocols (protocol suite), the
   existence of other protocol suites demands that the community deal
   with two aspects of multiprotocolism. The first is interoperability
   between the primary protocol suite and other protocol suites. The
   second is resource sharing between the primary protocol suite and
   other protocol suites.  Both interoperability and sharing may happen
   at multiple levels in the protocol suites.

   Achieving interoperability and resource sharing is difficult, and
   often unanticipated interactions occur. Interoperability can be
   difficult for reasons such as lack of common semantics. Resource
   sharing can run into problems due to lack of common operational
   paradigms. For example, sharing bandwidth on a link may not work
   effectively if one protocol suite backs off in its demands and the
   other does not. Interoperability and resource sharing both require
   cooperation between the developers/users of the different protocol
   suites. The challenge in this area, then, is to develop mechanisms
   for interoperability and resource sharing that have minimal negative
   affect on the primary protocol suite.

   The very attempts to achieve interoperability and resource sharing
   therefore lead to an attempt to bring the multiple protocol suites
   into some level of harmonization, even if it is just to simplify the
   problems of interoperability and sharing. Furthermore, the
   communications between the communities also leads to a level of
   harmonization. These processes, together with the normal process of
   evolution, lead to changes in the primary protocol suite, as well as
   the other suites.

   Thus, the need for new technologies and the need to accommodate
   multiple protocols leads to a natural process of diversion. The
   process of harmonization leads to conversion.

   While this discussion was oriented around the relation between
   multiple protocol suites, it can also be applied somewhat to the
   process of evolution within the primary protocol suite. So, for
   example, as new technologies develop, multiple approaches for
   exploiting those technologies will also develop. The process then
   hopefully leads to a process of harmonization of those different



Internet Architecture Board