RFC 1356 (rfc1356) - Page 2 of 14

Multiprotocol Interconnect on X

RFC 1356           Multiprotocol Interconnect on X.25        August 1992


Acknowledgements

   RFC 877 was written by J. T. Korb of Purdue University, and this
   document follows that RFC's format and builds upon its text as
   appropriate.  This document was produced under the auspices of the IP
   over Large Public Data Networks Working Group of the IETF.

1. Conventions

   The following language conventions are used in the items of
   specification in this document:

   o MUST -- the item is an absolute requirement of the specification.
     MUST is only used where it is actually required for interoperation,
     not to try to impose a particular method on implementors where not
     required for interoperability.

   o SHOULD -- the item should be followed for all but exceptional
     circumstances.

   o MAY or optional -- the item is truly optional and may be followed
     or ignored according to the needs of the implementor.

   The words "should" and "may" are also used, in lower case, in their
   more ordinary senses.

2. Introduction

   RFC 877 was written to document the method CSNET and the VAN Gateway
   had adopted to transmit IP datagrams over X.25 networks.  Its success
   is evident in its current wide use and the inclusion of its IP
   protocol identifier in ISO/IEC TR 9577, "Protocol Identification in
   the Network Layer" [2], which is administered by ISO/IEC and CCITT.

   However, due to changes in the scope of X.25 and the protocols that
   it can carry, several inadequacies have become evident in the RFC,
   especially in the areas of IP datagram Maximum Transmission Unit
   (MTU) size, X.25 maximum data packet size, virtual circuit
   management, and the interoperable encapsulation, over X.25, of
   protocols other than IP between multiprotocol routers and bridges.

   As with RFC 877, one or more X.25 virtual circuits are opened on
   demand when datagrams arrive at the network interface for
   transmission.  A virtual circuit is closed after some period of
   inactivity (the length of the period depends on the cost associated
   with an open virtual circuit).  A virtual circuit may also be closed
   if the interface runs out of virtual circuits.




Malis, Robinson, & Ullmann