rfc1683.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 676 行 · 第 1/2 页

Network Working Group                                           R. Clark
Request for Comments: 1683                                      M. Ammar
Category: Informational                                       K. Calvert
                                         Georgia Institute of Technology
                                                             August 1994


                 Multiprotocol Interoperability In IPng

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 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 [e-mail] mailing list.

1.  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
   Protocol should have features that support its use with a variety of
   protocol architectures.

2.  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



Clark, Ammar & Calvert                                          [Page 1]

RFC 1683         Multiprotocol Interoperability In IPng      August 1994


   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 3 we
   motivate the issues of multiprotocol networking with a discussion of
   an example system.  In Section 4 we describe three main techniques
   for dealing with multiple protocols.  This is followed in Section 5
   by a description of the various protocol features that are important
   for implementing these three techniques.  We conclude in Section 6
   with a summary of the issues raised.

3.  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 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.











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 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 multiprotocol system of
   Figure 1 includes all the protocols necessary to communicate with
   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 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.

4.  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 5.

4.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 end networks are carried as data within the protocol of
   the intermediate network.  This technique is only appropriate when



Clark, Ammar & Calvert                                          [Page 4]

RFC 1683         Multiprotocol Interoperability In IPng      August 1994


   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.

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

4.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 3.

   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



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 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 5).

5.  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.

5.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,



Clark, Ammar & Calvert                                          [Page 6]