GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1683

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 big-internet@munnari.oz.au 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] RFC 1683 Multiprotocol Interoperability In IPng August 1994

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

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

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

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

    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.

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

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

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

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

8. References

 [1] Clark, R., Ammar, M., and K. Calvert, "Multi-protocol
     architectures as a paradigm for achieving inter-operability", In
     Proceedings of IEEE INFOCOM, April 1993.
 [2] Clark, R., Calvert, K. and M. 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] Gilligan, R., Nordmark, E., and B. Hinden, "IPAE: the SIPP
     Interoperability and Transition Mechanism, Work in Progress,
     November 1993.
 [4] Leiner, B., and Y. Rekhter, "The Multiprotocol Internet", RFC
     1560, USRA, IBM, December 1993.
 [5] McLaughlin, L., "Standard for the Transmission of 802.2 Packets
     over IPX Networks", RFC 1132, The Wollongong Group, November
     1989.
 [6] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
     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 and
     Specification.  STD 13, RFC 1035, USC/Information Sciences
     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", RFC
     1234, Novell, Inc., June 1991.
[11] Rose, M., "The Open Book", Prentice-Hall, Englewood Cliffs, New
     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 the
     TCP", STD 35, RFC 1006, Northrop Research and Technology Center,
     May 1987.
[14] Tennenhouse, D., "Layered multiplexing considered harmful", In
     IFIP Workshop on Protocols for High-Speed Networks. Elsevier, May
     1989.
[15] Ullmann, R., "CATNIP: Common architecture technology for next-
     generation internet protocol", Work in Progress, October 1993.

9. Security Considerations

 Security issues are not discussed in this memo.

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

10. Authors' Addresses

 Russell J. Clark
 College of Computing Georgia Institute of Technology
 Atlanta, GA 30332-0280
 EMail: rjc@cc.gatech.edu
 Mostafa H. Ammar
 College of Computing Georgia Institute of Technology
 Atlanta, GA 30332-0280
 EMail: ammar@cc.gatech.edu
 Kenneth L. Calvert
 College of Computing Georgia Institute of Technology
 Atlanta, GA 30332-0280
 EMail: calvert@cc.gatech.edu

Clark, Ammar & Calvert [Page 12]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1683.txt · Last modified: 1994/08/08 23:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki