GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1560

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:
  1. maintain its focus on the TCP/IP protocol suite,
  1. work to select a single next-generation internet protocol and

develop mechanisms to aid in transition from the current IPv4,

      and
  1. 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:
  1. It is desirable to have a single protocol stack. The community

should try to avoid unconstrained proliferation of various

      protocol stacks.
  1. 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.
  1. ————– ————–

! ! ! !

          !             !             ! 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:
  1. 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
  1. 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:
  1. Communities of end users can select their desired applications,

independent of the technologies used to support the intermediate

      networks.
  1. 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:
  1. maintain its focus on the TCP/IP protocol suite,
  1. 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

  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1560.txt · Last modified: 1993/12/22 21:15 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki