Network Working Group A. Malis
Request for Comments: 1356 BBN Communications
Obsoletes: RFC 877 D. Robinson
Computervision Systems Integration
R. Ullmann
Process Software Corporation
August 1992
Multiprotocol Interconnect
on X.25 and ISDN in the Packet Mode
Status of this Memo
This RFC specifies an IAB standards track protocol for the Internet
community, and requests discussion and suggestions for improvements.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
Abstract
This document specifies the encapsulation of IP and other network
layer protocols over X.25 networks, in accordance and alignment with
ISO/IEC and CCITT standards. It is a replacement for RFC 877, "A
Standard for the Transmission of IP Datagrams Over Public Data
Networks" [1].
It was written to correct several ambiguities in the Internet
Standard for IP/X.25 (RFC 877), to align it with ISO/IEC standards
that have been written following RFC 877, to allow interoperable
multiprotocol operation between routers and bridges over X.25, and to
add some additional remarks based upon practical experience with the
specification over the 8 years since that RFC.
The substantive change to the IP encapsulation is an increase in the
allowed IP datagram Maximum Transmission Unit from 576 to 1600, to
reflect existing practice.
This document also specifies the Internet encapsulation for
protocols, including IP, on the packet mode of the ISDN. It applies
to the use of Internet protocols on the ISDN in the circuit mode only
when the circuit is established as an end-to-end X.25 connection.
Malis, Robinson, & Ullmann [Page 1]
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 [Page 2]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
3. Standards
3.1 Protocol Data Units (PDUs) are sent as X.25 "complete packet
sequences". That is, PDUs begin on X.25 data packet boundaries and
datatracker.ietf.org