As per Relevance of the word different, we have this rfc below:
Network Working Group R.
Request for Comments: 1683 M.
Category: Informational K.
Georgia Institute of
August 1994
Multiprotocol Interoperability In
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
This document was submitted to the IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list
1. Executive
The two most commonly cited issues motivating the introduction
IPng are address depletion and routing table growth in IPv4.
motivation is the fact that the Internet is witnessing an
diversity in the protocols and services found in the network.
evaluating alternatives for IPng, we should consider how well
alternative addresses the problems arising from this diversity.
this document, we identify several features that affect a protocol'
ability to operate in a multiprotocol environment and propose
incorporation of these features into IPng
Our thesis, succinctly stated, is: The next generation
Protocol should have features that support its use with a variety
protocol architectures
2.
The Internet is not a single protocol network [4]. While TCP/
remains the primary protocol suite, other protocols (e.g., IPX
AppleTalk, OSI) exist either natively or encapsulated as data
IP. As new protocols continue to be developed, we are likely to
that a significant portion of the traffic in future networks is
from single-protocol communications. It is important to
that multiprotocol networking is not just a transition issue.
instance, we will continue to see tunneling used to carry IPX
Clark, Ammar & Calvert [Page 1]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
over the Internet between two Novell networks. Furthermore,
introduction of IPng is not going to result in a near
elimination of IPv4. Even when IPng becomes the primary
used in the Internet, there will still be IPv4 systems in use.
should consider such multiprotocol uses of the network as we
future protocols that can efficiently handle mixed protocol traffic
We have identified several issues related to the way in
protocols operate in a multiprotocol environment. Many of
issues have traditionally been deemed "less important" by
designers since their goal was to optimize for the case where
systems supported the same protocol. With the increasing
of network protocols, this approach is no longer practical.
addressing the issues outlined in this paper, we can simplify
introduction of IPng to the Internet and reduce the risk for
managers faced with the prospect of supporting a new protocol.
will result in a faster, wider acceptance of IPng and
interoperability between Internet hosts. In addition, by
IPng to address these issues, we will make the introduction of
protocols (IPng2) even easier
The outline for this document is as follows. In Section 3
motivate the issues of multiprotocol networking with a discussion
an example system. In Section 4 we describe three main
for dealing with multiple protocols. This is followed in Section 5
by a description of the various protocol features that are
for implementing these three techniques. We conclude in Section 6
with a summary of the issues raised
3. Multiprotocol
Consider the multiprotocol architecture depicted in Figure 1.
system supporting this architecture provides a generic file-
service using either the Internet or OSI protocol stacks.
generic service presents the user with a consistent interface
regardless of the actual protocols used. The user can transfer
between this host and hosts supporting either of the single
stacks presented in Figures 2a and 2b. To carry out this
transfer, the user is not required to decide which protocols to
or to adjust between different application interfaces
Clark, Ammar & Calvert [Page 2]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
+-----------------------------------+
| File Transfer Service |
+-----------+-----------------------+
| | FTAM |
| +-----------------------+
| FTP | ISO 8823 |
| +-----------------------+
| | ISO 8327 |
| +-----------+-----------+
| |TP0/RFC1006| TP4 |
+-----------+-----------+ |
| TCP | |
+-----------+-----------+-----------+
| IP | CLNP |
+-----------+-----------------------+
Figure 1: Multiprotocol architecture providing file-transfer
+-----------+ +-----------+ +-----------+ +-----------+
| FTP | | FTAM | | FTAM | | FTP |
+-----------+ +-----------+ +-----------+ +-----------+
| TCP | | ISO 8823 | | ISO 8823 | | TCP |
+-----------+ +-----------+ +-----------+ +-----------+
| IP | | ISO 8327 | | ISO 8327 | | CLNP |
+-----------+ +-----------+ +-----------+ +-----------+
| TP4 | |TP0/RFC1006|
+-----------+ +-----------+
| CLNP | | TCP |
+-----------+ +-----------+
| IP |
+-----------+
a) TCP/IP b) OSI c) RFC 1006 d)
Figure 2: Protocol stacks providing file-transfer service
Figure 2c depicts a mixed stack architecture that provides the
layer OSI services using the Internet protocols. This is an
of a "transition architecture" for providing OSI applications
requiring a full OSI implementation. Figure 2d depicts a mixed
architecture that provides the upper layer Internet
using the OSI network protocol. In addition to communicating
the two previous simple protocol stacks, the multiprotocol system
Figure 1 includes all the protocols necessary to communicate
these two new, mixed protocol stacks
Clark, Ammar & Calvert [Page 3]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
It is likely that many future network systems will be configured
support multiple protocols including IPng. As the IPng protocol
deployed, it is unreasonable to expect that users will be willing
give up any aspect of their current connectivity for the promise of
better future. In reality, most IPng installations will be made "
addition to" the current protocols. The resulting systems
resemble Figure 1 in that they will be able to communicate
systems supporting several different protocols
Unfortunately, in most current examples, the architecture of Figure 1
is implemented as independent protocol stacks. This means that
though both TCP and CLNP exist on the system, there is no way to
TCP and CLNP in the same communication. The problem with
implementations of architectures like Figure 1 is that they
designed as co-existence architectures and are not
interoperability systems. We believe future systems should
mechanisms to overcome this traditional limitation. By
the components of multiple protocol stacks in a systematic way,
can interoperate with hosts supporting any of the individual
as well as those supporting various combinations of the stacks
In order to effectively use multiple protocols, a system
identify which of the available protocols to use for a
communication task. We call this the Protocol Determination [2]
task. In performing this task, a system determines the
of protocols necessary to provide the needed service. For
interoperability, protocols are selected from the intersection
those supported on the systems that must communicate
4. Multiprotocol
In this section we identify three main techniques to dealing
multiprotocol networks that are in use today and will continue to
used in the Internet. The first two techniques, tunneling
conversion, are categorized as intermediate-system techniques in
they are designed to achieve multiprotocol support without
the end-systems. The third technique explicitly calls for
support of multiple protocols in end-systems. By describing
techniques here, we can motivate the need for the specific
features described in Section 5.
4.1 Encapsulation/
Encapsulation or tunneling is commonly used when two networks
support a common protocol must be connected using a
intermediate network running a different protocol. Protocol
from the two end networks are carried as data within the protocol
the intermediate network. This technique is only appropriate
Clark, Ammar & Calvert [Page 4]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
both end-systems support the same protocol stack. It does
provide interoperability between these end systems and systems
only support the protocol stack in the intermediate network.
examples of this technique are: a mechanism for providing the
transport services on top of the Internet protocols [13],
encapsulating IEEE 802.2 frames in IPX network packets [5],
IPX [10] and AppleTalk traffic over the Internet backbone. We
IPng to be used for tunneling other network protocols over IPng
to be encapsulated
4.2 Translation/
Despite their known limitations [8], translation or
gateways are another technique for handling multiple protocols [11,
12]. These gateways perform direct conversion of network
from one protocol to another. The most common examples of
gateways are the many electronic mail gateways now in use in
Internet. In certain cases it may also be feasible to
conversion of lower layer protocols such as the network layer.
technique has been suggested as part of the transition plan for
of the current IPng proposals [3, 15].
4.3 Multiprotocol End-
We expect that IPng will be introduced as an additional protocol
many network systems. This means that IPng should be able to
with other protocols on both end- and intermediate-systems
Specifically, IPng should be designed to support the
Determination task described in Section 3.
One technique that we consider for solving the Protocol
problem is to employ a directory service in distributing
protocol configuration information. We have developed
implemented mechanism for using the Internet Domain Name System (DNS
[6, 7] to distribute this protocol information [2]. Using
mechanism, a multiprotocol host can determine the
configuration of a desired host when it retrieves the network
for that host. Then the multiprotocol host can match
configuration of the desired host to its own configuration
determine which protocols should be used to carry out the
communication service
Another alternative to determining protocol information about
host is Protocol Discovery. Using this approach, a host
which protocols to use by trial-and-error with the
currently available. The initiating host monitors
attempts to communicate and uses the information gained from
monitoring to build a knowledge base of the possible protocols of
Clark, Ammar & Calvert [Page 5]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
remote system
This knowledge is used to determine whether or not a
link can be established and if it can, which protocol should be used
An important aspect of the Protocol Discovery approach is that
requires an error and control feedback system similar to ICMP [9],
but with additional functionality (See Section 5).
5. Protocol
In this section we identify features that affect a protocol's
to support the multiprotocol techniques described in the
section. These features indicate specific areas that should
considered when comparing proposed protocols. We present
different types of protocol features: those that should be
as part of the IPng protocol standard, and those that should
considered as part of the implementation and deployment
for IPng
5.1 Protocol Standard
o
A significant problem in dealing with multiprotocol networks
that most of the popular network protocols use
addressing mechanisms. The problem is not just with
lengths but also with different semantics (e.g., hierarchical vs
flat addresses). In order to accommodate these multiple formats
IPng should have the flexibility to incorporate many
formats within its addressing mechanism
A specific example might be for IPng to have the ability
include an IPv4 or IPX address as a subfield of the IPng address
This would reduce the complexity of performing address
by limiting the number of external mechanisms (e.g.,
tables) needed to convert an address. This reduction
complexity would facilitate both tunneling and conversion.
would also simplify the task of using IPng with
applications which rely on a particular address format
o Header Option
In any widely used protocol, it is advantageous to define
mechanisms for including header information that is not
in all packets or is not yet defined. This is especially true
multiprotocol networks where there is wide variation in
requirements of protocol users. IPng should provide efficient
Clark, Ammar & Calvert [Page 6]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
flexible support for future header options. This will
accommodate the different user needs and will
conversion between IPng and other protocols with
standard features
As part of the support for protocol options, IPng should include
mechanism for specifying how a system should handle
options. If a network system adds an option header, it should
able to specify whether another system that does not support
option should drop the packet, drop the packet and return
error, forward it as is, or forward it without the option header
The ability to request the "forward as is" option is
when conversion is used. When two protocols have
features, a converter may introduce an option header that is
understood by an intermediate node but may be required
interpretation of the packet at the ultimate destination. On
other hand, consider the case where a source is using IPng with
critical option like encryption. In this situation the user
not want a conversion to be performed where the option was
understood by the converter. The "drop the packet" or "drop
return error" options would likely be used in this scenario
o
The future Internet protocol should support the ability
distinguish between multiple users of the network. This
the ability to handle traditional "transport layer" protocols
TCP and UDP, as well as other payload types such as
AppleTalk packets or future real-time protocols. This kind
protocol multiplexing can be supported with an explicit
field as in IPv4 or by reserving part of the address format as
done with OSI NSEL's
In a multiprotocol network there will likely be a large number
different protocols running atop IPng. It should not be
to use a transport layer protocol for the sole purpose
providing multiplexing for the various network users. The cost
this additional multiplexing is prohibitive for future high-
networks [14]. In order to avoid the need for an additional
of multiplexing, the IPng should either use a payload
larger than the 8-bits used in IPv4 or provide an option
including additional payload type information within the header
o Status/Control
With multiple protocols, the correct transmission of a
might include encapsulation in another protocol and/or
conversions to different protocols before the packet
Clark, Ammar & Calvert [Page 7]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
reaches its destination. This means that there are many
places the transmission can fail and determining what went
will be a challenge
In order to handle this situation, a critical protocol feature
multiprotocol networks is a powerful error reporting mechanism
In addition to reporting traditional network level errors, such
those reported by ICMP [9], the IPng error mechanism
include feedback on tunneling and conversion failures. Also
since it is impossible to know exactly which part of a packet
an encapsulated header, it is important that the
mechanism include as much of the failed packet as possible in
returned error message
In addition to providing new types of feedback, this
should support variable resolution such that a transmitting
can request limited feedback or complete information about
communication process. This level of control would
facilitate the Protocol Discovery process described in
4.3. For example, a multiprotocol system could request
feedback when it sends packets to a destination it has
communicated with for some time. After the first few packets
this "new" destination, the system would revert back to
feedback, freeing up the resources used by the network
mechanisms
Finally, it is important that the information provided by
feedback mechanism be available outside the IPng implementation
In multiprotocol networks it is often the case that the
to a communication problem requires an adjustment in one of
protocols outside the network layer. In order for this to happen
the other protocols must be able to access and interpret
feedback messages
o MTU Discovery or
A form of multiprotocol support that has long been a part
networking is the use of diverse data link and physical layers
One aspect of this support that affects the network layer is
different Maximum Transmission Units (MTU) used by various
formats. For efficiency, many protocols will attempt to
fragmentation at intermediate nodes by using the largest
size possible, without exceeding the minimum MTU along the route
To achieve this, a network protocol performs MTU discovery to
the smallest MTU on a path
Clark, Ammar & Calvert [Page 8]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
The choice of mechanism for dealing with differing MTUs is
important when doing conversion or tunneling with
protocols. When tunneling is performed by an intermediate node
the resulting packets may be too large to meet the
requirements. Similarly, if conversion at an intermediate
results in a larger protocol header, the new packets may also
too large. In both cases, it may be desirable to have the
host reduce the transmission size used in order to prevent
need for additional fragmentation. This information could be
to the source host as part of the previously described
mechanism or as an additional MTU discovery message
5.2 Implementation/Deployment
o
We define switching in a protocol as the capability
simultaneously use more than one different underlying
[1]. In network layer protocols, this implies using
datalink layers. For example, it may be necessary to
between the 802.3 LLC and traditional Ethernet interfaces
connecting a host to an "ethernet" network. Additionally, in
systems IPng will not be used directly over a datalink layer
will be encapsulated within another network protocol before
transmitted. It is important that IPng be designed to
different underlying datalink services and that it
mechanisms allowing IPng users to specify which of the
services should be used
o Directory Service
While not specifically a part of the IPng protocol, it is
that the future Internet will include a directory service
obtaining address information for IPng. In light of this,
are some features of the directory service that should
considered vis-a-vis their support for multiple protocols
First, the directory service should be able to distribute
formats for several different protocol families, not just IPng
IPv4. This is necessary for the use of tunneling, conversion,
the support of multiprotocol systems. Second, the
service should include support for distributing
configuration information in addition to addressing
for the network hosts. This feature will support the
determination task to be carried out by multiprotocol systems [2].
Clark, Ammar & Calvert [Page 9]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
6.
Future networks will incorporate multiple protocols to meet
user requirements. Because of this, we are likely to find that
significant portion of the traffic in the Internet will not be
single-protocol communications (e.g., TCPng/IPng). This will
just be true of near term, transitional networks but will remain as
reality for most of the Internet. As we pursue the selection
IPng, we should consider the special needs of multiprotocol networks
In particular, IPng should include mechanisms to handle
protocol traffic that includes tunneling, conversion,
multiprotocol end-systems
7.
The authors would like to acknowledge the support for this work by
grant from the National Science Foundation (NCR-9305115) and
TRANSOPEN project of the Army Research Lab (formerly AIRMICS)
contract number DAKF11-91-D-0004.
8.
[1] Clark, R., Ammar, M., and K. Calvert, "Multi-
architectures as a paradigm for achieving inter-operability",
Proceedings of IEEE INFOCOM, April 1993.
[2] Clark, R., Calvert, K. and M. Ammar, "On the use of
services to support multiprotocol interoperability", To appear
proceedings of IEEE INFOCOM, 1994. Technical Report GIT-CC-93/56,
College of Computing, Georgia Institute of Technology, ATLANTA
GA 30332-0280, August 1993.
[3] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: the
Interoperability and Transition Mechanism, Work in Progress
November 1993.
[4] Leiner, B., and Y. Rekhter, "The Multiprotocol Internet",
1560, USRA, IBM, December 1993.
[5] McLaughlin, L., "Standard for the Transmission of 802.2
over IPX Networks", RFC 1132, The Wollongong Group,
1989.
[6] Mockapetris, P., "Domain Names - Concepts and Facilities",
13, RFC 1034, USC/Information Sciences Institute, November 1987.
Clark, Ammar & Calvert [Page 10]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
[7] Mockapetris, P., "Domain Names - Implementation
Specification. STD 13, RFC 1035, USC/Information
Institute, November 1987.
[8] Padlipsky, M., Gateways, Architectures, and Heffalumps", RFC 875,
MITRE, September 1982.
[9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792,
USC/Information Sciences Institute, September 1981.
[10] Provan, D., "Tunneling IPX Traffic Through IP Networks",
1234, Novell, Inc., June 1991.
[11] Rose, M., "The Open Book", Prentice-Hall, Englewood Cliffs,
Jersey, 1990.
[12] Rose, M., "The ISO Development Environment User's Manual -
Version 7.0.", Performance Systems International, July 1991.
[13] Rose, M., and D. Cass, "ISO Transport Services on top of
TCP", STD 35, RFC 1006, Northrop Research and Technology Center
May 1987.
[14] Tennenhouse, D., "Layered multiplexing considered harmful",
IFIP Workshop on Protocols for High-Speed Networks. Elsevier,
1989.
[15] Ullmann, R., "CATNIP: Common architecture technology for next
generation internet protocol", Work in Progress, October 1993.
9. Security
Security issues are not discussed in this memo
Clark, Ammar & Calvert [Page 11]
RFC 1683 Multiprotocol Interoperability In IPng August 1994
10. Authors'
Russell J.
College of Computing Georgia Institute of
Atlanta, GA 30332-0280
EMail: rjc@cc.gatech.
Mostafa H.
College of Computing Georgia Institute of
Atlanta, GA 30332-0280
EMail: ammar@cc.gatech.
Kenneth L.
College of Computing Georgia Institute of
Atlanta, GA 30332-0280
EMail: calvert@cc.gatech.
Clark, Ammar & Calvert [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
