RFC 1560

The MultiProtocol Internet 🎀

okay bestie, title block tea ☕ RFC 1560 is called The MultiProtocol Internet, and it's from the Network Working Group. The authors are B. Leiner (USRA) and Y. Rekhter (IBM). It's Informational 📚 and dated December 1993. The title block doesn't list anything it obsoletes or updates 💅

Status of this Memo 🫶

This memo gives information to the Internet community 💖 It does not specify an Internet standard of any kind, so don't go treating it as one 🙈 Distribution of this memo is unlimited ✨

Abstract 🌸

This document was written by the authors on behalf of the Internet Architecture Board (IAB) 🧚 The IAB is offering it up to get people talking 💬

There has been a lot of buzz lately about two topics: MultiProtocol approaches in the Internet and picking a next generation Internet Protocol 👀 This doc throws out a strawman (a starting point, not a final answer) for goals and approaches for the IETF/IESG/IAB in these areas. The authors think these two topics are connected, and they suggest directions the IETF/IESG/IAB could pursue 🦋

The big recommendation is that the IETF/IESG/IAB should keep being a force for consensus on a single protocol suite and internet layer protocol 🔥 So 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 big purpose of the Internet is to enable ubiquitous communication services between endpoints ✨ Honestly, the Internet IS inter-enterprise networking 😭 So multiprotocol Internet isn't just about having multiple network layers. It's about having multiple comparable services built over different protocols 💅

The multiprotocol Internet issue has a lot of dimensions, and it should be looked at through two principles happening at the same time 🌈

• 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. Multiple network layers are just one result of this, because even inside a single protocol stack, the forces of that stack evolving 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 🧚

At an IAB architectural retreat held in 1991 [Cla91], people described a dynamic view of how multiprotocol integration and accommodation works 🫶 Here's the figure they drew:

            ---------------             --------------
            !             !             !            !
            !             !             ! 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 looks at things from the view of a community working on one primary protocol suite, like the IETF/IESG/IAB working on TCP/IP 🌸 (Note: you have to keep in mind the whole time that even though this paper comes from the IETF/IESG/IAB and TCP/IP side, every community focused on one of the other protocol suites has its own complementary view 👀) There are other protocol suites, like IPX, OSI, and SNA 🍓 Even though the main focus is building one system on one set of protocols (a protocol suite), those other suites mean the community has to deal with two parts of multiprotocolism. The first is interoperability between the primary protocol suite and the other ones. The second is resource sharing between them. Both interoperability and sharing can happen at multiple levels in the protocol suites 💅

Achieving interoperability and resource sharing is hard, and unexpected interactions happen a lot 😩 Interoperability can be tough because of things like a lack of common semantics. Resource sharing can run into trouble because of a lack of common operational paradigms. For example, sharing bandwidth on a link may not work well if one protocol suite backs off on its demands and the other one doesn't 🙃 Interoperability and resource sharing both need cooperation between the developers and users of the different protocol suites. So the challenge is to develop mechanisms for interoperability and resource sharing that have minimal negative affect on the primary protocol suite 🛡️

Trying to get interoperability and resource sharing therefore leads to an attempt to bring the multiple protocol suites into some level of harmonization, even if it's just to make the interoperability and sharing problems simpler ✨ On top of that, the communication between the communities also leads to a level of harmonization 🫧 These processes, together with normal evolution, lead to changes in the primary protocol suite, as well as the other suites 🦋

So 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 🌈

Even though this discussion was about the relationship between multiple protocol suites, it can also be applied somewhat to evolution inside the primary protocol suite 🧚 For example, as new technologies develop, multiple approaches for using those technologies will also develop. The process then hopefully leads to harmonization of those different approaches 💖

2.2. The Basis of the Internet 🌈

The Internet grew fast for a few reasons 🚀 Some were "practical," like TCP/IP being bundled with Berkeley Unix and the early decision to base NSFNet on TCP/IP 🍓 But the authors believe there's a more fundamental reason too. The Internet (and the TCP/IP protocol suite) was targeted at Inter-Enterprise Networking 👑 Even though TCP/IP being available on workstations, and the wish for one environment to serve both intra- and inter-enterprise networking, led people to use TCP/IP inside organizations, the big contribution of the Internet and TCP/IP was giving user communities a way to communicate with other organizations and communities in a straightforward manner, using a set of common and basic services 🫶

The key to all of this was that the Internet was built on a single, common, virtual network service (IP) with a supporting administrative infrastructure 💜 That let a ubiquitous underlying communication infrastructure grow up to serve the global community, and a set of services could be offered on top of it for user communities. It also let a big market grow up for application services built on the underlying communications 💅

An important side effect of having one common virtual network service available to the end user (an open network service) is that choosing applications becomes the job of the end-user community rather than the intermediate network provider 🙌 Because there's this common underlying infrastructure, user communities can pick the application services they want or need based on their own unique needs, knowing the intermediate networking service will support their communication requirements ✨ The authors think this has mattered a lot to the Internet's success 🔥

On top of providing network layer services for the TCP/IP transport layer and applications, IP may also be used to provide network layer services for non-TCP/IP transport layers and applications 🦋 That's clearly beneficial, because it keeps all the benefits of a single, common, virtual network service (IP) while also widening the set of applications available to end users 🌸

3. Directions for Multiprotocolism 👑

Over the past few years, as the Internet's scope has grown, there's been a growing need to develop mechanisms for accommodating other protocol suites 😤 Most techniques have fallen into one of two camps: interoperability (techniques that allow communication between users of different protocol suites) or resource sharing (letting common resources like links or switches jointly serve communities using different protocol suites) 🧚 It has to be noted that these techniques have been pretty limited, with interoperability happening mostly at application layers and resource sharing happening to a limited extent 🫠

This need to deal with multiple protocol suites has started discussion in the community about the role of the IETF/IESG/IAB regarding TCP/IP versus other protocol suites 💭 People are asking whether TCP/IP is the sole domain of interest for the IETF/IESG/IAB, or whether the community also needs to deal with other protocol suites, and if so, how, given those other suites have their own communities pursuing their development and evolution 🌈

The answer depends on understanding the role of the IETF/IESG/IAB in the process described above (Figure 1) 💖 The continued success of the Internet relies on a continued strong force for convergence, making sure the primary protocol suite (TCP/IP) succeeds through an evolutionary process that accommodates both changing user requirements and emerging technologies 🎀

Since this process requires ongoing effort to accommodate other protocol suites within the overall Internet, efforts at interoperability and sharing must continue 🌸 So the directions for the IETF/IESG/IAB can be summed up in two parts 💅

• 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 ✨

Okay bestie, everything we just said about multiprotocolism totally applies to the next generation internet protocol too 🔮 Right now there are several IPng candidates, and that raises the question of how to deal with multiple protocols at that level 💅 We note that even if just one gets picked, there's still an issue involved in transitioning from IPv4 to IPng 😭

Picking a single Internet protocol isn't the only way to handle this, though 🦋 Even if a layer of ubiquity is required (like what IP gives us right now), we could maybe provide ubiquity at a different layer. For example, we could imagine a common transport protocol running over multiple internet protocols. We could also imagine getting interoperability through common application services (like directory services) running over diverse communication services, both at the transport and network layers 🧚

These alternatives don't give you the considerable benefits of a single internet protocol, so they would be undesirable 🙈 Having one single internet protocol gives you a common communication infrastructure across the various networks, and that gets you 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. Installing these applications doesn't require end users to select a corresponding network protocol (although some advanced applications may require enhancements, such as high-bandwidth approaches).

So the community (IETF/IESG/IAB) should keep acting as a force for convergence by selecting a single next generation Internet protocol and developing methods to ease the transition from IPv4 to IPng 👑 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 the same way. Not that layer, periodt 💅

5. Conclusion 🌈

Historically, the IETF/IESG/IAB has been a strong force for the development of the Internet, acting as a force for convergence on and evolution of a single primary protocol suite. This has served the community well, so this approach should keep going into 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] 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 💀

Dramatic pause 😭 Security issues are not discussed in this memo. That's the whole tea, bestie, and I'm not adding anything to it 🫶

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