As per Relevance of the word interoperability, we have this rfc below:
Network Working Group B.
Request for Comments: 1560
Category: Informational Y.
December 1993
The MultiProtocol
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was prepared by the authors on behalf of the
Architecture Board (IAB). It is offered by the IAB to
discussion
There has recently been considerable discussion on two topics
MultiProtocol approaches in the Internet and the selection of a
generation Internet Protocol. This document suggests a
position for goals and approaches for the IETF/IESG/IAB in
areas. It takes the view that these two topics are related,
proposes directions for the IETF/IESG/IAB to pursue
In particular, it recommends that the IETF/IESG/IAB should
to be a force for consensus on a single protocol suite and
layer protocol. The IETF/IESG/IAB should
- maintain its focus on the TCP/IP protocol suite
- work to select a single next-generation internet protocol
develop mechanisms to aid in transition from the current IPv4,
- continue to explore mechanisms to interoperate and
resources with other protocol suites within the Internet
1.
The major purpose of the Internet is to enable
communication services between endpoints. In a very real way,
Internet IS inter-enterprise networking. Therefore, the issue
multiprotocol Internet is not just the issue of multiple
layers, but the issue of multiple comparable services
Internet Architecture Board [Page 1]
RFC 1560 The MultiProtocol Internet December 1993
over different protocols
The issue of multiprotocol Internet is multidimensional and should
analyzed with respect to two simultaneous principles
- It is desirable to have a single protocol stack. The
should try to avoid unconstrained proliferation of
protocol stacks
- In reality there will always be more than one protocol stack
Presence of multiple network layers is just one of
corollaries of this observation, as even within a
protocol stack, forces of evolution of that stack will
to periods of multiple protocols. We need to
mechanisms that maximize the services that can be
across all the protocol stacks (multiprotocol Internet).
2. Background and
2.1. The MultiProtocol Evolutionary
In an IAB architectural retreat held in 1991 [Cla91], a dynamic
of the process of multiprotocol integration and accommodation
described, based on the figure below
--------------- --------------
! ! ! !
! ! ! Interop- !
! Primary ! >>>>>>>>>>> ! erability !>>>>>
! Protocol ! ! !
! Suite ! --------------
! !
! !
! ! --------------
! ! ! !
! ! >>>>>>>>>>> ! Resource !
! ! ! Sharing !>>>>
! ! ! !
--------------- --------------
^
^ --------------
^ ! !
<<<<<<
! !
! !
--------------
Figure 1: MultiProtocol Evolution
Internet Architecture Board [Page 2]
RFC 1560 The MultiProtocol Internet December 1993
The figure describes the process from the perspective of a
working on a single primary protocol suite (such as the IETF/IESG/
working on the TCP/IP protocol suite.) (Note: It must be kept in
throughout this paper that, while the discussion is oriented from
perspective of the IETF/IESG/IAB and the TCP/IP protocol suite,
is a complementary viewpoint from the perspective of each of
communities whose primary focus is on one of the other
suites.) There are other protocol suites (for example, IPX, OSI
SNA). Although the primary emphasis of the community is developing
system based on a single set of protocols (protocol suite),
existence of other protocol suites demands that the community
with two aspects of multiprotocolism. The first is
between the primary protocol suite and other protocol suites.
second is resource sharing between the primary protocol suite
other protocol suites. Both interoperability and sharing may
at multiple levels in the protocol suites
Achieving interoperability and resource sharing is difficult,
often unanticipated interactions occur. Interoperability can
difficult for reasons such as lack of common semantics.
sharing can run into problems due to lack of common
paradigms. For example, sharing bandwidth on a link may not
effectively if one protocol suite backs off in its demands and
other does not. Interoperability and resource sharing both
cooperation between the developers/users of the different
suites. The challenge in this area, then, is to develop
for interoperability and resource sharing that have minimal
affect on the primary protocol suite
The very attempts to achieve interoperability and resource
therefore lead to an attempt to bring the multiple protocol
into some level of harmonization, even if it is just to simplify
problems of interoperability and sharing. Furthermore,
communications between the communities also leads to a level
harmonization. These processes, together with the normal process
evolution, lead to changes in the primary protocol suite, as well
the other suites
Thus, the need for new technologies and the need to
multiple protocols leads to a natural process of diversion.
process of harmonization leads to conversion
While this discussion was oriented around the relation
multiple protocol suites, it can also be applied somewhat to
process of evolution within the primary protocol suite. So,
example, as new technologies develop, multiple approaches
exploiting those technologies will also develop. The process
hopefully leads to a process of harmonization of those
Internet Architecture Board [Page 3]
RFC 1560 The MultiProtocol Internet December 1993
approaches
2.2. The Basis of the
The rapid growth of the Internet has resulted from several forces
Some of them are "practical", such as the bundling of TCP/IP
Berkeley Unix and the early decision to base NSFNet on TCP/IP
However, we believe that there is a more fundamental reason for
growth. The Internet (and the TCP/IP protocol suite) were targeted
Inter-Enterprise Networking. Although the availability of TCP/IP
workstations and the desire to have a single environment serve
intra- and inter-enterprise networking led to the use of TCP/
within organizations, the major contribution of the Internet
TCP/IP was to provide to user communities the ability to
with other organizations/communities in a straightforward
using a set of common and basic services
Fundamental to this ability was the fact that the Internet was
on a single, common, virtual network service (IP) with a
administrative infrastructure. This allowed a ubiquitous
communication infrastructure to develop serving the global community
upon which a set of services could be provided to the
communities. This also allowed for a large market to develop
application services that were built upon the
communications
An important corollary to having a single common virtual
service available to the end user (open network service) is that
selection of applications becomes the province of the end-
community rather than the intermediate network provider. By
this common underlying infrastructure, user communities are able
select their desired/required application services based on
unique needs, with assurance that the intermediate networking
will support their communication requirements. We believe that
has been of considerable importance in the success of the Internet
In addition to providing network layer services for TCP/IP
layer and applications, IP may be used to provide network
services for non-TCP/IP transport layer and applications. Such use
clearly beneficial, since it allows preservation of all the
of a single, common, virtual network service (IP), while at the
time widening the set of applications available to the end users
3. Directions for
Over the past few years, with the increasing scope of the Internet
has come an increasing need to develop mechanisms for
other protocol suites. Most techniques have fallen into the regime
Internet Architecture Board [Page 4]
RFC 1560 The MultiProtocol Internet December 1993
either interoperability (techniques that allow for
between users of different protocol suites) or resource
(allowing common resources such as links or switches to
service communities using different protocol suites.) It must
noted that such techniques have been quite limited,
interoperability happening primarily at application layers
resource sharing happening to limited extent
This need to deal with multiple protocol suites has led to
within the community concerning the role of the IETF/IESG/
regarding the TCP/IP protocol suite versus other protocol suites
Questions are asked as to whether the TCP/IP protocol suite is
sole domain of interest of the IETF/IESG/IAB or if the
needs also to deal with other protocol suites, and if so, in
manner, given these other protocol suites have their own
of interest pursuing their development and evolution
The answer to this question lies in understanding the role of
IETF/IESG/IAB with respect to the process described above (Figure 1).
The continued success of the Internet relies on a continued
force for convergence, making sure that the primary protocol
(TCP/IP) is successful through an evolutionary process
accommodating both the changing user requirements and
technologies
Since this process requires a continued effort to accommodate
protocol suites within the overall Internet, efforts
interoperability and sharing must continue. Thus, we can
the directions for the IETF/IESG/IAB as two-fold
- Have as a primary focus the evolution of the primary
suite (TCP/IP), acting as a force for convergence at all
towards a single set of protocols,
- Make provision for other protocol suites within the
Internet through mechanisms for interoperability and
sharing
4. Next Generation Internet
The principles described above for multiprotocolism can also
applied to the discussions regarding the next generation
protocol. Currently, there are several candidates for IPng,
raises the question of how to deal with multiple protocols at
level. We note that even if just one is selected, there is an
involved in transitioning from IPv4 to IPng
Internet Architecture Board [Page 5]
RFC 1560 The MultiProtocol Internet December 1993
Selection of a single Internet protocol is not the only way
dealing with this issue. Even if a layer of ubiquity is
(such as that provided currently by IP), we might consider
ubiquity at a different layer. For example, we could imagine having
common transport protocol running over multiple internet protocols
We also could imagine achieving interoperability by use of
application services (such as directory services) running
diverse communication services (both transport and network layers).
These alternatives do not provide the considerable benefits of
single internet protocol, and therefore would be undesirable.
a single internet protocol provides a common
infrastructure across the various networks, thereby achieving
following
- Communities of end users can select their desired applications
independent of the technologies used to support the
networks
- The common underlying infrastructure provides a
marketplace upon which application developers can create new
exciting applications. Installation of these applications
not require end users to select a corresponding network
(although some advanced applications may require enhancements
such as high-bandwidth approaches).
Thus, the community (IETF/IESG/IAB) should continue to act as a
for convergence by selecting a single next generation
protocol and developing methods to ease the transition from IPv4
IPng. Specifically, at the applications layer, it is desirable
promote different approaches and "let the marketplace decide."
However, it is unacceptable to treat the internet protocol layer
the same way
5.
Historically, the IETF/IESG/IAB has acted as a strong force for
development of the Internet by acting as a force for convergence
and evolution of a single primary protocol suite. This has
the community well, and this approach should be continued for
future. In particular, the IETF/IESG/IAB should
- maintain its focus on the TCP/IP protocol suite
- work to select a single next-generation internet protocol
develop mechanisms to aid in transition from the current IPv4,
Internet Architecture Board [Page 6]
RFC 1560 The MultiProtocol Internet December 1993
- continue to explore mechanisms to interoperate and
resources with other protocol suites within the Internet
6.
[Cla91] Clark, D., Chapin, L., Cerf, V., Braden, R.,
R. Hobby, "Towards the Future Internet Architecture",
RFC 1287, MIT, BBN, CNRI, ISI, UC Davis, December 1991.
Security
Security issues are not discussed in this memo
Authors'
Dr. Barry M.
Senior
Universities Space Research
625 Ellis Street, Suite 205
Mountain View, CA 94043
Phone: (415) 390-0317
Fax: (415) 390-0318
EMail: leiner@nsipo.nasa.
Yakov
T.J. Watson Research Center, IBM Corp
P.O. Box 218,
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: yakov@watson.ibm.
Internet Architecture Board [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
