summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1560.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1560.txt')
-rw-r--r--doc/rfc/rfc1560.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc1560.txt b/doc/rfc/rfc1560.txt
new file mode 100644
index 0000000..569c681
--- /dev/null
+++ b/doc/rfc/rfc1560.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+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
+
+
+
+Internet Architecture Board [Page 1]
+
+RFC 1560 The MultiProtocol Internet December 1993
+
+
+ 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
+
+
+
+Internet Architecture Board [Page 2]
+
+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 [Page 3]
+
+RFC 1560 The MultiProtocol Internet December 1993
+
+
+ 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
+
+
+
+Internet Architecture Board [Page 4]
+
+RFC 1560 The MultiProtocol Internet December 1993
+
+
+ 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.
+
+
+
+
+
+Internet Architecture Board [Page 5]
+
+RFC 1560 The MultiProtocol Internet December 1993
+
+
+ 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
+
+
+
+
+Internet Architecture Board [Page 6]
+
+RFC 1560 The MultiProtocol Internet December 1993
+
+
+ - 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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Internet Architecture Board [Page 7]
+ \ No newline at end of file