rfc1560.txt

RFC 的详细文档！

   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: [phone]
   Fax: [phone]
   EMail: [e-mail]


   Yakov Rekhter
   T.J. Watson Research Center, IBM Corp.
   P.O. Box 218,
   Yorktown Heights, NY 10598

   Phone: [phone]
   EMail: [e-mail]


















Internet Architecture Board                                     [Page 7]