The MultiProtocol Internet
The Internet Architecture Board's strawman position on protocol coexistence and on the next version of IP.
Leiner, B. and Y. Rekhter, "The MultiProtocol Internet", RFC 1560, DOI 10.17487/RFC1560, December 1993, <https://www.rfc-editor.org/info/rfc1560>.
@misc{rfc1560,
series = {Request for Comments},
number = 1560,
howpublished = {RFC 1560},
publisher = {RFC Editor},
doi = {10.17487/RFC1560},
url = {https://www.rfc-editor.org/info/rfc1560},
author = {B. Leiner and Y. Rekhter},
title = {{The MultiProtocol Internet}},
pagetotal = 7,
year = 1993,
month = dec,
} RFC text
Contents
Network Working Group B. Leiner
Request for Comments: 1560 USRA
Category: Informational Y. Rekhter
IBM
December 1993
The MultiProtocol Internet
Status of this Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
This document was prepared by the authors on behalf of the Internet
Architecture Board (IAB). It is offered by the IAB to stimulate
discussion.
There has recently been considerable discussion on two topics:
MultiProtocol approaches in the Internet and the selection of a next
generation Internet Protocol. This document suggests a strawman
position for goals and approaches for the IETF/IESG/IAB in these
areas. It takes the view that these two topics are related, and
proposes directions for the IETF/IESG/IAB to pursue.
In particular, it recommends that the IETF/IESG/IAB should continue
to be a force for consensus on a single protocol suite and internet
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 and
develop mechanisms to aid in transition from the current IPv4,
and
- continue to explore mechanisms to interoperate and share
resources with other protocol suites within the Internet.
1. Introduction
The major purpose of the Internet is to enable ubiquitous
communication services between endpoints. In a very real way, the
Internet IS inter-enterprise networking. Therefore, the issue of
multiprotocol Internet is not just the issue of multiple network
layers, but the issue of multiple comparable services implemented
over different protocols.
The issue of multiprotocol Internet is multidimensional and should be
analyzed with respect to two simultaneous principles:
- It is desirable to have a single protocol stack. The community
should try to avoid unconstrained proliferation of various
protocol stacks.
- In reality there will always be more than one protocol stack.
Presence of multiple network layers is just one of the
corollaries of this observation, as even within a single
protocol stack, forces of evolution of that stack will lead
to periods of multiple protocols. We need to develop
mechanisms that maximize the services that can be provided
across all the protocol stacks (multiprotocol Internet).
2. Background and Context
2.1. The MultiProtocol Evolutionary Process
In an IAB architectural retreat held in 1991 [Cla91], a dynamic view
of the process of multiprotocol integration and accommodation was
described, based on the figure below.
--------------- --------------
! ! ! !
! ! ! Interop- !
! Primary ! >>>>>>>>>>> ! erability !>>>>>
! Protocol ! ! ! v
! Suite ! -------------- v
! ! v
! ! v
! ! -------------- v
! ! ! ! v
! ! >>>>>>>>>>> ! Resource ! v
! ! ! Sharing !>>>>v
! ! ! ! v
--------------- -------------- v
^ v
^ -------------- v
^ ! ! v
<<<<<<<! Harmonize !<<<<<<<<<<<<<<<<<<<<
! !
! !
--------------
Figure 1: MultiProtocol Evolution Process
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
approaches.
2.2. The Basis of the Internet
The rapid growth of the Internet has resulted from several forces.
Some of them are "practical", such as the bundling of TCP/IP with
Berkeley Unix and the early decision to base NSFNet on TCP/IP.
However, we believe that there is a more fundamental reason for this
growth. The Internet (and the TCP/IP protocol suite) were targeted at
Inter-Enterprise Networking. Although the availability of TCP/IP on
workstations and the desire to have a single environment serve both
intra- and inter-enterprise networking led to the use of TCP/IP
within organizations, the major contribution of the Internet and
TCP/IP was to provide to user communities the ability to communicate
with other organizations/communities in a straightforward manner
using a set of common and basic services.
Fundamental to this ability was the fact that the Internet was based
on a single, common, virtual network service (IP) with a supporting
administrative infrastructure. This allowed a ubiquitous underlying
communication infrastructure to develop serving the global community,
upon which a set of services could be provided to the user
communities. This also allowed for a large market to develop for
application services that were built upon the underlying
communications.
An important corollary to having a single common virtual network
service available to the end user (open network service) is that the
selection of applications becomes the province of the end-user
community rather than the intermediate network provider. By having
this common underlying infrastructure, user communities are able to
select their desired/required application services based on their
unique needs, with assurance that the intermediate networking service
will support their communication requirements. We believe that this
has been of considerable importance in the success of the Internet.
In addition to providing network layer services for TCP/IP transport
layer and applications, IP may be used to provide network layer
services for non-TCP/IP transport layer and applications. Such use is
clearly beneficial, since it allows preservation of all the benefits
of a single, common, virtual network service (IP), while at the same
time widening the set of applications available to the end users.
3. Directions for Multiprotocolism
Over the past few years, with the increasing scope of the Internet,
has come an increasing need to develop mechanisms for accommodating
other protocol suites. Most techniques have fallen into the regime of
either interoperability (techniques that allow for communications
between users of different protocol suites) or resource sharing
(allowing common resources such as links or switches to jointly
service communities using different protocol suites.) It must be
noted that such techniques have been quite limited, with
interoperability happening primarily at application layers and
resource sharing happening to limited extent.
This need to deal with multiple protocol suites has led to discussion
within the community concerning the role of the IETF/IESG/IAB
regarding the TCP/IP protocol suite versus other protocol suites.
Questions are asked as to whether the TCP/IP protocol suite is the
sole domain of interest of the IETF/IESG/IAB or if the community
needs also to deal with other protocol suites, and if so, in what
manner, given these other protocol suites have their own communities
of interest pursuing their development and evolution.
The answer to this question lies in understanding the role of the
IETF/IESG/IAB with respect to the process described above (Figure 1).
The continued success of the Internet relies on a continued strong
force for convergence, making sure that the primary protocol suite
(TCP/IP) is successful through an evolutionary process in
accommodating both the changing user requirements and emerging
technologies.
Since this process requires a continued effort to accommodate other
protocol suites within the overall Internet, efforts at
interoperability and sharing must continue. Thus, we can summarize
the directions for the IETF/IESG/IAB as two-fold:
- Have as a primary focus the evolution of the primary protocol
suite (TCP/IP), acting as a force for convergence at all times
towards a single set of protocols, and
- Make provision for other protocol suites within the global
Internet through mechanisms for interoperability and resource
sharing.
4. Next Generation Internet Protocol
The principles described above for multiprotocolism can also be
applied to the discussions regarding the next generation internet
protocol. Currently, there are several candidates for IPng, which
raises the question of how to deal with multiple protocols at that
level. We note that even if just one is selected, there is an issue
involved in transitioning from IPv4 to IPng.
Selection of a single Internet protocol is not the only way of
dealing with this issue. Even if a layer of ubiquity is required
(such as that provided currently by IP), we might consider providing
ubiquity at a different layer. For example, we could imagine having a
common transport protocol running over multiple internet protocols.
We also could imagine achieving interoperability by use of common
application services (such as directory services) running over
diverse communication services (both transport and network layers).
These alternatives do not provide the considerable benefits of a
single internet protocol, and therefore would be undesirable. Having
a single internet protocol provides a common communication
infrastructure across the various networks, thereby achieving the
following:
- Communities of end users can select their desired applications,
independent of the technologies used to support the intermediate
networks.
- The common underlying infrastructure provides a common
marketplace upon which application developers can create new and
exciting applications. Installation of these applications does
not require end users to select a corresponding network protocol
(although some advanced applications may require enhancements,
such as high-bandwidth approaches).
Thus, the community (IETF/IESG/IAB) should continue to act as a force
for convergence by selecting a single next generation Internet
protocol and developing methods to ease the transition from IPv4 to
IPng. Specifically, at the applications layer, it is desirable to
promote different approaches and "let the marketplace decide."
However, it is unacceptable to treat the internet protocol layer in
the same way.
5. Conclusion
Historically, the IETF/IESG/IAB has acted as a strong force for the
development of the Internet by acting as a force for convergence on
and evolution of a single primary protocol suite. This has served
the community well, and this approach should be continued for the
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 and
develop mechanisms to aid in transition from the current IPv4,
and
- continue to explore mechanisms to interoperate and share
resources with other protocol suites within the Internet.
6. References
[Cla91] Clark, D., Chapin, L., Cerf, V., Braden, R., and
R. Hobby, "Towards the Future Internet Architecture",
RFC 1287, MIT, BBN, CNRI, ISI, UC Davis, December 1991.
Security Considerations
Security issues are not discussed in this memo.
Authors' Addresses
Dr. Barry M. Leiner
Senior Scientist
Universities Space Research Association
625 Ellis Street, Suite 205
Mountain View, CA 94043
Phone: (415) 390-0317
Fax: (415) 390-0318
EMail: leiner@nsipo.nasa.gov
Yakov Rekhter
T.J. Watson Research Center, IBM Corp.
P.O. Box 218,
Yorktown Heights, NY 10598
Phone: (914) 945-3896
EMail: yakov@watson.ibm.com
ISO Plain Language
On this page
§1The Question the Memo Asks
The memo was prepared by its authors on behalf of the Internet Architecture Board and is offered by the IAB to stimulate discussion. It takes up two topics that had recently seen considerable discussion: multiprotocol approaches in the Internet, and the selection of a next generation Internet Protocol. It suggests a strawman position for the goals and approaches of the IETF, the IESG and the IAB, and takes the view that the two topics are related, proposing directions for the three bodies to pursue.
The three directions are stated up front: maintain the focus on the TCP/IP protocol suite; work to select a single next-generation internet protocol and develop mechanisms to aid the transition from the current IPv4; and continue to explore mechanisms to interoperate and share resources with other protocol suites within the Internet.
The memo then sets out why the question is bigger than it looks. The major purpose of the Internet is to enable ubiquitous communication services between endpoints, and in a very real way the Internet is inter-enterprise networking. The issue of a multiprotocol Internet is therefore not just the issue of multiple network layers, but the issue of multiple comparable services implemented over different protocols.
It analyses the problem against two principles that hold at the same time. It is desirable to have a single protocol stack, and the community should try to avoid unconstrained proliferation of various stacks. But in reality there will always be more than one stack. The presence of multiple network layers is just one corollary of that, because even within a single stack the forces of evolution lead to periods of multiple protocols. What is needed, then, are mechanisms that maximise the services that can be provided across all the stacks.
The IAB is saying that a multiprotocol Internet is not really about supporting several network layers. It is about offering the same kinds of service to people who use different protocols, and about not pretending that one stack will ever be the only one.
§2.1The MultiProtocol Evolutionary Process
The picture the memo works from comes from an IAB architectural retreat held in 1991, and it describes the process of multiprotocol integration and accommodation from the point of view of a community working on a single primary protocol suite, such as the IETF, IESG and IAB working on TCP/IP. The memo notes that there is a complementary viewpoint from each of the communities whose primary focus is one of the other suites, and names IPX, OSI and SNA among them.
The existence of other protocol suites forces the community to deal with two aspects of multiprotocolism: interoperability between the primary suite and the others, and resource sharing between them. Both may happen at several levels in the protocol suites.
Achieving either is difficult, and often unanticipated interactions occur. Interoperability can be hard for reasons such as a lack of common semantics. Resource sharing can run into problems from a lack of common operational paradigms: sharing bandwidth on a link, for instance, may not work effectively if one protocol suite backs off in its demands and the other does not. Both interoperability and resource sharing require cooperation between the developers and users of the different suites. The challenge, then, is to develop mechanisms for them that have minimal negative effect on the primary protocol suite.
The memo then draws the consequence that makes the figure work. The very attempts to achieve interoperability and resource sharing lead to an attempt to bring the multiple suites into some level of harmonisation, even if only to simplify the problems of sharing and interoperability, and the communication between the communities also produces a degree of harmonisation. These processes, together with the normal process of evolution, lead to changes in the primary suite as well as the others. The need for new technologies and the need to accommodate multiple protocols therefore lead to a natural process of diversion, and the process of harmonisation leads to conversion. The same description can also be applied within the primary suite, where new technologies lead to several competing approaches, which are hoped to harmonise.
Making two different protocol families talk to each other, or share the same cable, forces the two communities to compromise. That compromise is what keeps the number of stacks from growing without limit, and it is also what turns one stack into a slightly different one over time.
- INTEROPERABILITYCommunication between users of different suites, which can be hard for a lack of common semantics.
- RESOURCE SHARINGCommon resources such as links or switches jointly serving communities using different suites.
- HARMONIZATIONThe attempts at interoperability and sharing lead to harmonisation, and harmonisation leads to conversion.
- HARMONIZATIONHarmonisation feeds changes back into the primary suite, so evolution changes it too.
§2.2The Basis of the Internet
The memo asks why the Internet grew as it did. Some of the forces were practical, such as the bundling of TCP/IP with Berkeley Unix and the early decision to base NSFNet on TCP/IP. But the authors believe there is a more fundamental reason: the Internet, and the TCP/IP protocol suite, were targeted at inter-enterprise networking. The availability of TCP/IP on workstations, and the desire to have a single environment serve both intra- and inter-enterprise networking, led to TCP/IP being used inside organisations, but the major contribution of the Internet and TCP/IP was to give user communities the ability to communicate with other organisations and communities in a straightforward manner, using a set of common and basic services.
Fundamental to that ability was the fact that the Internet was based on a single, common, virtual network service, IP, with a supporting administrative infrastructure. That allowed a ubiquitous underlying communication infrastructure to develop, serving the global community, upon which a set of services could be provided to the user communities. It also allowed a large market to develop for application services built on the underlying communications.
An important corollary of having a single common virtual network service available to the end user is that the selection of applications becomes the province of the end-user community rather than the intermediate network provider. With a common underlying infrastructure, user communities are able to select the application services they need based on their own requirements, with the assurance that the intermediate networking service will support their communication requirements. The authors believe this has been of considerable importance in the success of the Internet.
The memo adds that IP may be used to provide network layer services for non-TCP/IP transport layers and applications. Such use is clearly beneficial, because it preserves all the benefits of a single common virtual network service while at the same time widening the set of applications available to end users.
The reason the Internet worked, the memo argues, is that it offered one network service to everybody. Because the network underneath was the same everywhere, people could pick whatever application they liked and be sure it would work across it.
- One network serviceThe Internet was based on a single, common, virtual network service, IP, with a supporting administrative infrastructure.
- One infrastructureThat allowed a ubiquitous underlying communication infrastructure to develop, serving the global community, with a set of services on top of it.
- One marketplaceIt also allowed a large market to develop for application services built on the underlying communications.
- Users choose the applicationBecause the network underneath was the same everywhere, the choice of application became the end user's rather than the network provider's.
§3Directions for Multiprotocolism
As the scope of the Internet has grown, there has been an increasing need for mechanisms to accommodate other protocol suites. Most techniques fall into one of two categories. Interoperability techniques allow communications between users of different protocol suites. Resource sharing techniques allow common resources, such as links or switches, to jointly service communities using different protocol suites. The memo notes that such techniques have been quite limited so far, with interoperability happening primarily at the application layer and resource sharing to a limited extent.
This has led to discussion within the community about the role of the IETF, IESG and IAB with respect to the TCP/IP suite versus the other suites. Questions are asked as to whether TCP/IP is the sole domain of interest of those bodies, or whether the community needs to deal with other suites, and if so in what manner, given that those suites have their own communities of interest pursuing their own development and evolution.
The memo's answer is that the question has to be understood in the light of the process described by the figure. The continued success of the Internet relies on a continued strong force for convergence, making sure that the primary protocol suite, TCP/IP, is successful through an evolutionary process that accommodates both changing user requirements and emerging technologies. Since that process requires a continued effort to accommodate other suites within the overall Internet, efforts at interoperability and sharing must continue. The directions are therefore two-fold: have as a primary focus the evolution of the primary protocol suite, acting as a force for convergence at all times towards a single set of protocols, and make provision for other protocol suites within the global Internet through mechanisms for interoperability and resource sharing.
The answer to the squabble is a division of labour. The IETF keeps TCP/IP the one suite it pushes forward, and spends the rest of its effort on making it possible for other suites to share the Internet without making TCP/IP worse.
| Technique | What it means | Where it has happened |
|---|---|---|
| Interoperability | Techniques that allow communications between users of different protocol suites | Primarily at the application layer |
| Resource sharing | Allowing common resources such as links or switches to jointly service communities using different protocol suites | To a limited extent |
§4Selecting the Next Generation Internet Protocol
The same principles apply to the debate about the next generation internet protocol. There were several candidates for IPng, which raises the question of how to deal with multiple protocols at that level, and the memo notes that even if only one is selected there is an issue involved in transitioning from IPv4 to IPng.
Selecting a single Internet protocol is not the only way of dealing with the issue, the memo observes. Even if a layer of ubiquity is required, such as the one IP currently provides, ubiquity might be provided at a different layer. It might be possible to have a common transport protocol running over multiple internet protocols, or to achieve interoperability through common application services, such as directory services, running over diverse communication services at both the transport and the network layer.
These alternatives do not provide the considerable benefits of a single internet protocol and would therefore be undesirable. A single internet protocol provides a common communication infrastructure across the various networks, and that buys two things. Communities of end users can select their desired applications independently of the technologies used to support the intermediate networks. And the common underlying infrastructure provides a common marketplace upon which application developers can create new and exciting applications, whose installation does not require end users to select a corresponding network protocol, although some advanced applications may require enhancements such as high-bandwidth approaches.
So the community should continue to act as a force for convergence by selecting a single next generation Internet protocol and developing methods to ease the transition from IPv4 to IPng. Specifically, at the applications layer it is desirable to promote different approaches and let the marketplace decide. However, it is unacceptable to treat the internet protocol layer in the same way.
Applications can safely compete with one another, because a user only has to pick the application. The network layer cannot, because two network layers cannot sit on the same wire. That is why the IAB wants one new IP and wants it chosen soon.
§5Conclusion
The memo ends by stating that historically the IETF, IESG and IAB have acted as a strong force for the development of the Internet by acting as a force for convergence on and evolution of a single primary protocol suite, and that this has served the community well and should be continued. The three recommendations are then repeated in full: maintain the focus on the TCP/IP protocol suite; work to select a single next-generation internet protocol and develop mechanisms to aid the transition from the current IPv4; and continue to explore mechanisms to interoperate and share resources with other protocol suites within the Internet.
The Security Considerations section is one sentence: security issues are not discussed in this memo.
The three recommendations come round to the same thing. Keep pushing one suite, replace IPv4 with one successor rather than several, and keep working on how other suites can share the Internet with it.