RFC 1560 (rfc1560) - Page 3 of 7
The MultiProtocol Internet
Alternative Format: Original Text Document
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