rfc1683.txt

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


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: [e-mail]


   Mostafa H. Ammar
   College of Computing Georgia Institute of Technology
   Atlanta, GA 30332-0280

   EMail: [e-mail]


   Kenneth L. Calvert
   College of Computing Georgia Institute of Technology
   Atlanta, GA 30332-0280

   EMail: [e-mail]






























Clark, Ammar & Calvert                                         [Page 12]