• Aucun résultat trouvé

Abstract This document was prepared by the authors on behalf of the Internet Architecture Board (IAB)


Academic year: 2022

Partager "Abstract This document was prepared by the authors on behalf of the Internet Architecture Board (IAB)"


Texte intégral


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.


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


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


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



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


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


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.


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


- 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


Documents relatifs

We think that once a network is congested, packets will be dropped (regardless of whether these packets carry BGP or any other information), unless special measures outside

This specification is intended for those implementations which desire to use the PPP encapsulation over ISDN point-to-point links.. PPP is not designed for multi-point

If reliable transmission over the HDLC link is desired, the implementation MUST specify the Numbered-Mode Configuration Option during Link Establishment phase.. Generally,

At the time of this writing BGP-4 is used as an inter-autonomous system routing protocol between ALL significant autonomous systems, including, but by all means not limited

Ideally the routing system should allow to shift the overhead associated with a particular routing requirement towards the entity that instigates the requirement (for

For all purposes relevant to the Internet Standards development process, membership in the IETF and its Working Groups is defined to be established solely and entirely

(according to the IPP model document order) being the first octet in the encoding Every integer in this encoding MUST be encoded as a signed integer using two’s-complement

This memo is published by the RFC Editor in accordance with Section 2.1 of &#34;The Internet Standards Process -- Revision 3&#34;, RFC 2026, which specifies the rules

The reason a hash of the channel bindings and not the actual channel bindings are used to compute rbcva_chan_mic is that some channel bindings, such as those

Adverse impacts are very likely if the base protocol contains an extension mechanism and the proposed extension does not fit into the model used to create and

Revisable format: the format that will provide the information for conversion into a Publication format; it is used or created by the RFC Editor (see Section 2.3 for

For example, &#34;instance discovery&#34; messages are sent to an anycast destination address, and a reply is subsequently sent from the unique unicast source address of

In addition, the IETF Administrative Oversight Committee (IAOC), a body responsible for IETF administrative and financial matters [BCP101], maintains an SLA with the

The Internet Architecture Board (IAB) through its IP Stack Evolution program, the Internet Society, and the Swiss Federal Institute of Technology (ETH) Zurich hosted the

This document briefly describes the role of the Chair of the Internet Research Task Force (IRTF), discusses its duties, and outlines the skill set a candidate for the role

IETF Stream: &#34;This document is a product of the Internet Engineering Task Force (IETF).&#34;. If there has been an IETF consensus call per IETF process, this

Note that the &#34;name&#34; attribute does not need to be unique for &lt;artwork&gt; elements in a document.. If multiple &lt;artwork&gt; elements have the same

Text artwork is rendered inside an HTML &lt;pre&gt; element, which is contained by a &lt;div&gt; element for consistency with SVG artwork..

Some differences from the HTML rendition would include different typeface and size (chosen for printing), page numbers in the table of contents and index, and the

The Internet Architecture Board (IAB) and the Internet Society (ISOC) hosted a day-long Coordinating Attack Response at Internet Scale (CARIS) workshop on 18 June 2015

A review of the case studies described in Appendix A suggests that a good transition plan include at least the following components: an understanding of what is already

- Device users, owners, and customers like these may want to know what devices are installed over a longer period of time, what software/firmware version is the

Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.. Status of