Internet DRAFT - draft-clark-multipro-interop
draft-clark-multipro-interop
Internet Engineering Task Force Russell J Clark
INTERNET-DRAFT Mostafa H Ammar
Kenneth L Calvert
Georgia Institute of Technology
January, 1994
Multiprotocol Interoperability In IPng
<draft-clark-ipng-multipro-interop-00.txt>
1 Status of this Memo
This document was submitted to the IETF IPng area in response to RFC
1550 Publication of this document does not imply acceptance by the
IPng area of any ideas expressed within. Comments should be submitted
to the big-internet@munnari.oz.au mailing list.
Distribution of this memo is unlimited.
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six months.
Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts
as reference material or to cite them other than as a ``working
draft'' or ``work in progress.''
Please check the 1id-abstracts.txt listing contained in the
internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current
status of any Internet Draft.
2 Executive Summary
The two most commonly cited issues motivating the introduction of IPng
are address depletion and routing table growth in IPv4. Further
motivation is the fact that the Internet is witnessing an increasing
diversity in the protocols and services found in the network. When
evaluating alternatives for IPng, we should consider how well each
alternative addresses the problems arising from this diversity. In
this document, we identify several features that affect a protocol's
ability to operate in a multiprotocol environment and propose the
incorporation of these features into IPng.
Our thesis, succinctly stated, is: The next generation Internet
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
Protocol should have features that support its use with a variety of
protocol architectures.
3 Introduction
The Internet is not a single protocol network [4]. While TCP/IP
remains the primary protocol suite, other protocols (e.g., IPX,
AppleTalk, OSI) exist either natively or encapsulated as data within
IP. As new protocols continue to be developed, we are likely to find
that a significant portion of the traffic in future networks is not
from single-protocol communications. It is important to recognize
that multiprotocol networking is not just a transition issue. For
instance, we will continue to see tunneling used to carry IPX traffic
over the Internet between two Novell networks. Furthermore, the
introduction of IPng is not going to result in a near term elimination
of IPv4. Even when IPng becomes the primary protocol used in the
Internet, there will still be IPv4 systems in use. We should consider
such multiprotocol uses of the network as we design future protocols
that can efficiently handle mixed protocol traffic.
We have identified several issues related to the way in which
protocols operate in a multiprotocol environment. Many of these
issues have traditionally been deemed ``less important'' by protocol
designers since their goal was to optimize for the case where all
systems supported the same protocol. With the increasing diversity of
network protocols, this approach is no longer practical. By
addressing the issues outlined in this paper, we can simplify the
introduction of IPng to the Internet and reduce the risk for network
managers faced with the prospect of supporting a new protocol. This
will result in a faster, wider acceptance of IPng and increased
interoperability between Internet hosts. In addition, by designing
IPng to address these issues, we will make the introduction of future
protocols (IPng2) even easier.
The outline for this document is as follows. In Section 4 we motivate
the issues of multiprotocol networking with a discussion of an example
system. In Section 5 we describe three main techniques for dealing
with multiple protocols. This is followed in Section 6 by a
description of the various protocol features that are important for
implementing these three techniques. We conclude in Section 7 with a
summary of the issues raised.
4 Multiprotocol Systems
Consider the multiprotocol architecture depicted in Figure 1. A
system supporting this architecture provides a generic file-transfer
service using either the Internet or OSI protocol stacks. The generic
service presents the user with a consistent interface, regardless of
the actual protocols used. The user can transfer files between this
Clark, Ammar, and Calvert [Page 2]
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
host and hosts supporting either of the single protocol stacks
presented in Figures 2a and 2b. To carry out this file transfer, the
user is not required to decide which protocols to use or to adjust
between different application interfaces.
+-----------------------------------+
| File Transfer Service |
+-----------+-----------------------+
| | FTAM |
| +-----------------------+
| FTP | ISO 8823 |
| +-----------------------+
| | ISO 8327 |
| +-----------+-----------+
| |TP0/RFC1006| TP4 |
+-----------+-----------+ |
| TCP | |
+-----------+-----------+-----------+
| IP | CLNP |
+-----------+-----------------------+
Figure 1: Multiprotocol architecture providing file-transfer service
+-----------+ +-----------+ +-----------+ +-----------+
| 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) TUBA
Figure 2: Protocol stacks providing file-transfer service.
Figure 2c depicts a mixed stack architecture that provides the upper
layer OSI services using the Internet protocols. This is an example
of a ``transition architecture'' for providing OSI applications
without requiring a full OSI implementation. Figure 2d depicts a
mixed stack architecture that provides the upper layer Internet
applications using the OSI network protocol. In addition to
communicating with the two previous simple protocol stacks, the
Clark, Ammar, and Calvert [Page 3]
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
multiprotocol system of Figure 1 includes all the protocols necessary
to communicate with these two new, mixed protocol stacks.
It is likely that many future network systems will be configured to
support multiple protocols including IPng. As the IPng protocol is
deployed, it is unreasonable to expect that users will be willing to
give up any aspect of their current connectivity for the promise of a
better future. In reality, most IPng installations will be made ``in
addition to'' the current protocols. The resulting systems will
resemble Figure 1 in that they will be able to communicate with
systems supporting several different protocols.
Unfortunately, in most current examples, the architecture of Figure 1
is implemented as independent protocol stacks. This means that even
though both TCP and CLNP exist on the system, there is no way to use
TCP and CLNP in the same communication. The problem with current
implementations of architectures like Figure 1 is that they are
designed as co-existence architectures and are not integrated
interoperability systems. We believe future systems should include
mechanisms to overcome this traditional limitation. By integrating
the components of multiple protocol stacks in a systematic way, we can
interoperate with hosts supporting any of the individual stacks as
well as those supporting various combinations of the stacks.
In order to effectively use multiple protocols, a system must identify
which of the available protocols to use for a given communication
task. We call this the Protocol Determination [2] task. In
performing this task, a system determines the combination of protocols
necessary to provide the needed service. For achieving
interoperability, protocols are selected from the intersection of
those supported on the systems that must communicate.
5 Multiprotocol Techniques
In this section we identify three main techniques to dealing with
multiprotocol networks that are in use today and will continue to be
used in the Internet. The first two techniques, tunneling and
conversion, are categorized as intermediate-system techniques in that
they are designed to achieve multiprotocol support without changing
the end-systems. The third technique explicitly calls for the support
of multiple protocols in end-systems. By describing these techniques
here, we can motivate the need for the specific protocol features
described in Section 6.
5.1 Encapsulation/Tunneling
Encapsulation or tunneling is commonly used when two networks that
support a common protocol must be connected using a third intermediate
network running a different protocol. Protocol packets from the two
Clark, Ammar, and Calvert [Page 4]
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
end networks are carried as data within the protocol of the
intermediate network. This technique is only appropriate when both
end-systems support the same protocol stack. It does not provide
interoperability between these end systems and systems that only
support the protocol stack in the intermediate network. Some examples
of this technique are: a mechanism for providing the OSI transport
services on top of the Internet protocols [13], encapsulating
IEEE 802.2 frames in IPX network packets [5], tunneling IPX [10] and
AppleTalk traffic over the Internet backbone. We expect IPng to be
used for tunneling other network protocols over IPng and to be
encapsulated.
5.2 Translation/Conversion
Despite their known limitations [8], translation or conversion
gateways are another technique for handling multiple
protocols [11, 12]. These gateways perform direct conversion of
network traffic from one protocol to another. The most common
examples of conversion gateways are the many electronic mail gateways
now in use in the Internet. In certain cases it may also be feasible
to perform conversion of lower layer protocols such as the network
layer. This technique has been suggested as part of the transition
plan for some of the current IPng proposals [3, 15].
5.3 Multiprotocol End-Systems
We expect that IPng will be introduced as an additional protocol in
many network systems. This means that IPng should be able to coexist
with other protocols on both end- and intermediate-systems.
Specifically, IPng should be designed to support the Protocol
Determination task described in Section 4.
One technique that we consider for solving the Protocol Determination
problem is to employ a directory service in distributing system
protocol configuration information. We have developed and implemented
mechanism for using the Internet Domain Name System (DNS) [6, 7] to
distribute this protocol information [2]. Using this mechanism, a
multiprotocol host can determine the protocol configuration of a
desired host when it retrieves the network address for that host.
Then the multiprotocol host can match the configuration of the desired
host to its own configuration and determine which protocols should be
used to carry out the requested communication service.
Another alternative to determining protocol information about another
host is Protocol Discovery. Using this approach, a host determines
which protocols to use by trial-and-error with the protocols currently
available. The initiating host monitors successive attempts to
communicate and uses the information gained from that monitoring to
build a knowledge base of the possible protocols of the remote system.
Clark, Ammar, and Calvert [Page 5]
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
This knowledge is used to determine whether or not a communication
link can be established and if it can, which protocol should be used.
An important aspect of the Protocol Discovery approach is that it
requires an error and control feedback system similar to ICMP [9], but
with additional functionality (See Section 6).
6 Protocol Features
In this section we identify features that affect a protocol's ability
to support the multiprotocol techniques described in the previous
section. These features indicate specific areas that should be
considered when comparing proposed protocols. We present two
different types of protocol features: those that should be included
as part of the IPng protocol standard, and those that should be
considered as part of the implementation and deployment requirements
for IPng.
6.1 Protocol Standard Features
o Addressing
A significant problem in dealing with multiprotocol networks is
that most of the popular network protocols use different
addressing mechanisms. The problem is not just with different
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 address
formats within its addressing mechanism.
A specific example might be for IPng to have the ability to
include an IPv4 or IPX address as a subfield of the IPng address.
This would reduce the complexity of performing address conversion
by limiting the number of external mechanisms (e.g., lookup
tables) needed to convert an address. This reduction in
complexity would facilitate both tunneling and conversion. It
would also simplify the task of using IPng with legacy
applications which rely on a particular address format.
o Header Option Handling
In any widely used protocol, it is advantageous to define option
mechanisms for including header information that is not required
in all packets or is not yet defined. This is especially true in
multiprotocol networks where there is wide variation in the
requirements of protocol users. IPng should provide efficient,
flexible support for future header options. This will better
accommodate the different user needs and will facilitate
conversion between IPng and other protocols with different
Clark, Ammar, and Calvert [Page 6]
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
standard features.
As part of the support for protocol options, IPng should include a
mechanism for specifying how a system should handle unsupported
options. If a network system adds an option header, it should be
able to specify whether another system that does not support the
option should drop the packet, drop the packet and return an
error, forward it as is, or forward it without the option header.
The ability to request the ``forward as is'' option is important
when conversion is used. When two protocols have different
features, a converter may introduce an option header that is not
understood by an intermediate node but may be required for
interpretation of the packet at the ultimate destination. On the
other hand, consider the case where a source is using IPng with a
critical option like encryption. In this situation the user would
not want a conversion to be performed where the option was not
understood by the converter. The ``drop the packet'' or ``drop
and return error'' options would likely be used in this scenario.
o Multiplexing
The future Internet protocol should support the ability to
distinguish between multiple users of the network. This includes
the ability to handle traditional ``transport layer'' protocols
like TCP and UDP, as well as other payload types such as
encapsulated AppleTalk packets or future real-time protocols.
This kind of protocol multiplexing can be supported with an
explicit header field as in IPv4 or by reserving part of the
address format as is done with OSI NSEL's.
In a multiprotocol network there will likely be a large number of
different protocols running atop IPng. It should not be necessary
to use a transport layer protocol for the sole purpose of
providing multiplexing for the various network users. The cost of
this additional multiplexing is prohibitive for future high-speed
networks [14]. In order to avoid the need for an additional level
of multiplexing, the IPng should either use a payload selector
larger than the 8-bits used in IPv4 or provide an option for
including additional payload type information within the header.
o Status/Control Feedback
With multiple protocols, the correct transmission of a packet
might include encapsulation in another protocol and/or multiple
conversions to different protocols before the packet finally
reaches its destination. This means that there are many different
places the transmission can fail and determining what went wrong
will be a challenge.
In order to handle this situation, a critical protocol feature in
multiprotocol networks is a powerful error reporting mechanism.
Clark, Ammar, and Calvert [Page 7]
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
In addition to reporting traditional network level errors, such as
those reported by ICMP [9], the IPng error mechanism should
include feedback on tunneling and conversion failures. Also,
since it is impossible to know exactly which part of a packet is
an encapsulated header, it is important that the feedback
mechanism include as much of the failed packet as possible in the
returned error message.
In addition to providing new types of feedback, this mechanism
should support variable resolution such that a transmitting system
can request limited feedback or complete information about the
communication process. This level of control would greatly
facilitate the Protocol Discovery process described in
Section 5.3. For example, a multiprotocol system could request
maximal feedback when it sends packets to a destination it has not
communicated with for some time. After the first few packets to
this ``new'' destination, the system would revert back to limited
feedback, freeing up the resources used by the network feedback
mechanisms.
Finally, it is important that the information provided by the
feedback mechanism be available outside the IPng implementation.
In multiprotocol networks it is often the case that the solution
to a communication problem requires an adjustment in one of the
protocols outside the network layer. In order for this to happen,
the other protocols must be able to access and interpret these
feedback messages.
o MTU Discovery or Fragmentation
A form of multiprotocol support that has long been a part of
networking is the use of diverse data link and physical layers.
One aspect of this support that affects the network layer is the
different Maximum Transmission Units (MTU) used by various media
formats. For efficiency, many protocols will attempt to avoid
fragmentation at intermediate nodes by using the largest packet
size possible, without exceeding the minimum MTU along the route.
To achieve this, a network protocol performs MTU discovery to find
the smallest MTU on a path.
The choice of mechanism for dealing with differing MTUs is also
important when doing conversion or tunneling with multiple
protocols. When tunneling is performed by an intermediate node,
the resulting packets may be too large to meet the MTU
requirements. Similarly, if conversion at an intermediate node
results in a larger protocol header, the new packets may also be
too large. In both cases, it may be desirable to have the source
host reduce the transmission size used in order to prevent the
need for additional fragmentation. This information could be sent
to the source host as part of the previously described feedback
mechanism or as an additional MTU discovery message.
Clark, Ammar, and Calvert [Page 8]
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
6.2 Implementation/Deployment Features
o Switching
We define switching in a protocol as the capability to
simultaneously use more than one different underlying
protocol [1]. In network layer protocols, this implies using
different datalink layers. For example, it may be necessary to
select between the 802.3 LLC and traditional Ethernet interfaces
when connecting a host to an "ethernet" network. Additionally, in
some systems IPng will not be used directly over a datalink layer
but will be encapsulated within another network protocol before
being transmitted. It is important that IPng be designed to
support different underlying datalink services and that it provide
mechanisms allowing IPng users to specify which of the available
services should be used.
o Directory Service Requirements
While not specifically a part of the IPng protocol, it is clear
that the future Internet will include a directory service for
obtaining address information for IPng. In light of this, there
are some features of the directory service that should be
considered vis-a-vis their support for multiple protocols.
First, the directory service should be able to distribute address
formats for several different protocol families, not just IPng and
IPv4. This is necessary for the use of tunneling, conversion, and
the support of multiprotocol systems. Second, the directory
service should include support for distributing protocol
configuration information in addition to addressing information
for the network hosts. This feature will support the protocol
determination task to be carried out by multiprotocol systems [2].
7 Conclusion
Future networks will incorporate multiple protocols to meet diverse
user requirements. Because of this, we are likely to find that a
significant portion of the traffic in the Internet will not be from
single-protocol communications (e.g. TCPng/IPng). This will not just
be true of near term, transitional networks but will remain as a
reality for most of the Internet. As we pursue the selection of IPng,
we should consider the special needs of multiprotocol networks. In
particular, IPng should include mechanisms to handle mixed protocol
traffic that includes tunneling, conversion, and multiprotocol
end-systems.
Clark, Ammar, and Calvert [Page 9]
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
8 Acknowledgments
The authors would like to acknowledge the support for this work by a
grant from the National Science Foundation (NCR-9305115) and the
TRANSOPEN project of the Army Research Lab (formerly AIRMICS) under
contract number DAKF11-91-D-0004.
9 References
[1] R. J. Clark, M. H. Ammar, and K. L. Calvert. Multi-protocol
architectures as a paradigm for achieving inter-operability. In
Proceedings of IEEE INFOCOM, April 1993.
[2] R. J. Clark, K. L. Calvert, and M. H. Ammar. On the use of
directory services to support multiprotocol interoperability.
To appear in 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] R. Gilligan, E. Nordmark, and B. Hinden. IPAE: the SIPP
interoperability and transition mechanism. Internet Draft,
November 1993.
[4] B. Leiner and Y. Rekhter. The multiprotocol internet. RFC 1560,
December 1993.
[5] L. McLaughlin. Standard for the transmission of 802.2 packets
over IPX networks. RFC 1132, November 1989.
[6] P. Mockapetris. Domain names - concepts and facilities. RFC
1034, November 1987.
[7] P. Mockapetris. Domain names - implementation and specification.
RFC 1035, November 1987.
[8] M. A. Padlipsky. Gateways, architectures, and heffalumps. RFC
875, September 1982.
[9] J. B. Postel. Internet control message protocol. RFC 792,
September 1981.
[10] D. Provan. Tunneling IPX traffic through IP networks. RFC 1234,
June 1991.
[11] M. T. Rose. The Open Book. Prentice-Hall, Englewood Cliffs, New
Jersey, 1990.
[12] M. T. Rose. The ISO Development Environment User's Manual -
Version 7.0. Performance Systems International, July 1991.
Clark, Ammar, and Calvert [Page 10]
INTERNET-DRAFT Multiprotocol Interoperability In IPng January, 1994
[13] M. T. Rose and D. E. Cass. ISO Transport Services on top of the
TCP. RFC 1006, May 1987.
[14] D. L. Tennenhouse. Layered multiplexing considered harmful. In
IFIP Workshop on Protocols for High-Speed Networks. Elsevier, May
1989.
[15] R. Ullmann. CATNIP: Common architecture technology for
next-generation internet protocol. Internet Draft, October 1993.
10 Authors' Address
Russell J Clark - rjc@cc.gatech.edu
Mostafa H Ammar - ammar@cc.gatech.edu
Kenneth L Calvert - calvert@cc.gatech.edu
College of Computing Georgia Institute of Technology
Atlanta, GA 30332-0280
Clark, Ammar, and Calvert [Page 11]
----<END OF DOCUMENT>----
--
Russ Clark
College of Computing, Georgia Tech, Atlanta, GA 30332-0280
rjc@cc.gatech.edu
