doc: Add RFC documents

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