Internet Architecture Board                        Barry Leiner
INTERNET DRAFT                                     USRA
<draft-iab-multiprotocol-00.txt>		   Yakov Rekhter
						   IBM
Expiration Date: April 1994                        October 1993


The MultiProtocol Internet


Status of this Memo

This document was prepared by the authors on behalf of the IAB. It
is offered by the IAB to stimulate discussion.

This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its
Areas, and its Working Groups. Note that other groups may also
distribute working documents as Internet Drafts.

Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress". Please check the
1id-abstracts.txt listing contained in the internet-drafts Shadow
Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net,
ftp.nisc.sri.com, or munnari.oz.au to learn the current status of
any Internet Draft.

Abstract

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.

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]        D. Clark, L. Chapin, V. Cerf, R. Braden, and R. Hobby,
Towards the Future Internet Architecture. RFC No. 1287.
1991.