As per Relevance of the word encapsulation, we have this rfc below:
Network Working Group A.
Request for Comments: 1356 BBN
Obsoletes: RFC 877 D.
Computervision Systems
R.
Process Software
August 1992
Multiprotocol
on X.25 and ISDN in the Packet
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This document specifies the encapsulation of IP and other
layer protocols over X.25 networks, in accordance and alignment
ISO/IEC and CCITT standards. It is a replacement for RFC 877, "
Standard for the Transmission of IP Datagrams Over Public
Networks" [1].
It was written to correct several ambiguities in the
Standard for IP/X.25 (RFC 877), to align it with ISO/IEC
that have been written following RFC 877, to allow
multiprotocol operation between routers and bridges over X.25, and
add some additional remarks based upon practical experience with
specification over the 8 years since that RFC
The substantive change to the IP encapsulation is an increase in
allowed IP datagram Maximum Transmission Unit from 576 to 1600,
reflect existing practice
This document also specifies the Internet encapsulation
protocols, including IP, on the packet mode of the ISDN. It
to the use of Internet protocols on the ISDN in the circuit mode
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
RFC 877 was written by J. T. Korb of Purdue University, and
document follows that RFC's format and builds upon its text
appropriate. This document was produced under the auspices of the
over Large Public Data Networks Working Group of the IETF
1.
The following language conventions are used in the items
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
required for interoperability
o SHOULD -- the item should be followed for all but
circumstances
o MAY or optional -- the item is truly optional and may be
or ignored according to the needs of the implementor
The words "should" and "may" are also used, in lower case, in
more ordinary senses
2.
RFC 877 was written to document the method CSNET and the VAN
had adopted to transmit IP datagrams over X.25 networks. Its
is evident in its current wide use and the inclusion of its
protocol identifier in ISO/IEC TR 9577, "Protocol Identification
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
it can carry, several inadequacies have become evident in the RFC
especially in the areas of IP datagram Maximum Transmission
(MTU) size, X.25 maximum data packet size, virtual
management, and the interoperable encapsulation, over X.25,
protocols other than IP between multiprotocol routers and bridges
As with RFC 877, one or more X.25 virtual circuits are opened
demand when datagrams arrive at the network interface
transmission. A virtual circuit is closed after some period
inactivity (the length of the period depends on the cost
with an open virtual circuit). A virtual circuit may also be
if the interface runs out of virtual circuits
Malis, Robinson, & Ullmann [Page 2]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
3.
3.1 Protocol Data Units (PDUs) are sent as X.25 "complete
sequences". That is, PDUs begin on X.25 data packet boundaries
the M bit ("more data") is used to fragment PDUs that are
than one X.25 data packet in length
In the IP encapsulation the PDU is the IP datagram
3.2 The first octet in the Call User Data (CUD) Field (the first
octet in the Call Request packet) is used for
demultiplexing, in accordance with the Subsequent
Identifier (SPI) in ISO/IEC TR 9577. This field contains a one
octet Network Layer Protocol Identifier (NLPID), which
the network layer protocol encapsulated over the X.25
circuit. The CUD field MAY contain more than one octet
information, and receivers MUST ignore all extraneous octets in
field
In the following discussion, the most significant digit of
binary numbers is left-most
For the Internet community, the NLPID has four relevant values
The value hex CC (binary 11001100, decimal 204) is IP [6].
Conformance with this specification requires that IP be supported
See section 5.1 for a diagram of the packet formats
The value hex 81 (binary 10000001, decimal 129) identifies ISO/
8473 (CLNP) [4]. ISO/IEC TR 9577 specifically allows other ISO/
connectionless-protocol packets, such as ES-IS and IS-IS, to also
carried on the same virtual circuit as CLNP. Conformance with
specification does not require that CLNP be supported. See
5.2 for a diagram of the packet formats
The value hex 82 (binary 10000010, decimal 130) is used
for ISO/IEC 9542 (ES-IS) [5]. If there is already a circuit open
carry CLNP, then it is not necessary to open a second circuit
carry ES-IS. Conformance with this specification does not
that ES-IS be supported
The value hex 80 (binary 10000000, decimal 128) identifies the
of IEEE Subnetwork Access Protocol (SNAP) [3] to further
and identify a single network-layer protocol. The SNAP-
protocol is identified by including a five-octet SNAP header in
Call Request CUD field immediately following the hex 80 octet.
headers are not included in the subsequent X.25 data packets.
one SNAP-encapsulated protocol may be carried over a virtual
Malis, Robinson, & Ullmann [Page 3]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
opened using this encoding. The receiver SHOULD accept the
call only if it can support the particular SNAP-identified protocol
Conformance with this specification does not require that this
encoding be supported. See section 5.3 for a diagram of the
formats
The value hex 00 (binary 00000000, decimal 0) identifies the
encapsulation, used to multiplex multiple network layer
over the same circuit. This encoding is further discussed
section 3.3 below
The "Assigned Numbers" RFC [7] contains one other non-CCITT
non-ISO/IEC value that has been in active use for Internet X.25
encapsulation identification, namely hex C5 (binary 11000101,
decimal 197) for Blacker X.25. This value MAY continue to be used
but only by prior preconfiguration of the sending and receiving X.25
interfaces to support this value. The value hex CD (
11001101, decimal 205), listed in "Assigned Numbers" for "ISO-IP",
is also used by Blacker and also can only be used by
preconfiguration of the sending and receiving X.25 interfaces
Each system MUST only accept calls for protocols it can process
every Internet system MUST be able to accept the CC
for IP datagrams. A system MUST NOT accept calls, and
immediately clear them. Accepting the call indicates to the
system that the protocol encapsulation is supported; on
networks, a call accepted and cleared is charged, while a
cleared in the request state is not charged
Systems that support NLPIDs other than hex CC (for IP) SHOULD
their use to be configured on a per-peer address basis. The use
hex CC (for IP) MUST always be allowed between peers and cannot
configured
3.3 The NLPID encodings discussed in section 3.2 only allow a
network layer protocol to be sent over a circuit. The
encapsulation, identified by a NLPID encoding of hex 00, is used
order to multiplex multiple network layer protocols over
circuit
When the Null encapsulation is used, each X.25 complete
sequence sent on the circuit begins with a one-octet NLPID,
identifies the network layer protocol data unit contained only
that particular complete packet sequence. Further, if the
NLPID (hex 80) is used, then the NLPID octet is immediately
by the five-octet SNAP header, which is then immediately followed
the encapsulated PDU. The encapsulated network layer protocol
differ from one complete packet sequence to the next over the
Malis, Robinson, & Ullmann [Page 4]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
circuit
When a receiver is presented with an Incoming Call identifying
Null encapsulation, the receiver MUST accept the call if it
the Null encapsulation for any network layer protocol. The
MAY then silently discard a multiplexed PDU if it cannot
that particular encapsulated protocol. See section 5.4 for
diagram of the packet formats
Use of the single network layer protocol circuits described
section 3.2 is more efficient in terms of bandwidth if only
limited number of protocols are supported by a system. It
allows each system to determine exactly which protocols
supported by its communicating partner. Other advantages
being able to use X.25 accounting to detail each protocol
different quality of service or flow control windows for
protocols
The Null encapsulation, for multiplexing, is useful when a system
for any reason (such as implementation restrictions or network
considerations), may only open a limited number of virtual
simultaneously. This is the method most likely to be used by
multiprotocol router, to avoid using an unreasonable number
virtual circuits
If performing IEEE 802.1d bridging across X.25 is desired, then
Null encapsulation MUST be used. See section 4.2 for a
discussion
Conformance with this specification does not require that the
encapsulation be supported
Systems that support the Null encapsulation SHOULD allow its use
be configured on a per-peer address basis
3.4 For compatibility with existing practice, and RFC 877 systems,
datagrams MUST, by default, be encapsulated on a virtual
opened with the CC CUD
Implementations MAY also support up to three other
encapsulations of IP
o IP may be contained in multiplexed data packets on a circuit
the Null (multiplexed) encapsulation. Such data packets
identified by a NLPID of hex CC
o IP may be encapsulated within the SNAP encapsulation on a circuit
This encapsulation is identified by containing, in the 5-octet
Malis, Robinson, & Ullmann [Page 5]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
header, an Organizationally Unique Identifier (OUI) of hex 00-00-00
and Protocol Identifier (PID) of hex 08-00.
o On a circuit using the Null encapsulation, IP may be
within the SNAP encapsulation of IP in multiplexed data packets
If an implementation supports the SNAP, multiplexed, and/
multiplexed SNAP encapsulations, then it MUST accept the encoding
IP within the supported encapsulation(s), MAY send IP using
encapsulation(s), and MUST allow the IP encapsulation to send to
configured on a per-peer address basis
3.5 The negotiable facilities of X.25 MAY be used (e.g., packet
window size negotiation). Since PDUs are sent as complete
sequences, any maximum X.25 data packet size MAY be configured
negotiated between systems and their network service providers.
section 4.5 for a discussion of maximum X.25 data packet size
network performance
There is no implied relationship between PDU size and X.25
size (i.e., the method of setting IP MTU based on X.25 packet
in RFC 877 is not used).
3.6 Every system MUST be able to receive and transmit PDUs up to
least 1600 octets in length
For compatibility with existing practice, as well
interoperability with RFC 877 systems, the default transmit MTU
IP datagrams SHOULD default to 1500, and MUST be configurable in
least the range 576 to 1600.
This is done with a view toward a standard default IP MTU of 1500,
used on both local and wide area networks with no fragmentation
routers. Actually redefining the IP default MTU is, of course
outside the scope of this specification
The PDU size (e.g., IP MTU) MUST be configurable, on at least
per-interface basis. The maximum transmitted PDU length SHOULD
configurable on a per-peer basis, and MAY be configurable on a per
encapsulation basis as well. Note that the ability to configure
send IP datagrams with an MTU of 576 octets and to receive
datagrams of 1600 octets is essential to interoperate with
implementations of RFC 877 and implementations of
specification
Note that on circuits using the Null (multiplexed) encapsulation
when IP packets are encapsulated using the NLPID of hex CC, then
default IP MTU of 1500 implies a PDU size of 1501; a PDU size
Malis, Robinson, & Ullmann [Page 6]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
1600 implies an IP MTU of 1599. When IP packets are
using the NLPID of hex 80 followed by the SNAP header for IP,
the default IP MTU of 1500 implies a PDU size of 1506; a PDU size
1600 implies an IP MTU of 1594.
Of course, an implementation MAY support a maximum PDU size
than 1600 octets. In particular, there is no limit to the size
may be used when explicitly configured by communicating peers
3.7 Each ISO/IEC TR 9577 encapsulation (e.g., IP, CLNP, and SNAP
requires a separate virtual circuit between systems. In addition
multiple virtual circuits for a single encapsulation MAY be
between systems, to, for example, increase throughput (see notes
section 4.5).
Receivers SHOULD accept multiple incoming calls with the
encapsulation from a single system. Having done so, receivers
then accept incoming PDUs on the additional circuit(s), and
transmit on the additional circuits
Shedding load by refusing additional calls for the
encapsulation with a X.25 diagnostic of 0 (DTE clearing) is
practice, as is shortening inactivity timers to try to
circuits
Receivers MUST NOT accept the incoming call, only to close
circuit or ignore PDUs from the circuit
Because opening multiple virtual circuits specifying the
encapsulation is specifically allowed, algorithms to prevent
circuit call collision, such as the one found in section 8.4.3.5
ISO/IEC 8473 [4], MUST NOT be implemented
While allowing multiple virtual circuits for a single protocol
specifically desired and allowed, implementations MAY choose (
configuration) to permit only a single circuit for some protocols
some destinations. Only in such a case, if a colliding
call is received while a call request is pending, the incoming
shall be rejected. Note that this may result in a failure
establish a connection. In such a case, each system shall wait
least a configurable collision retry time before retrying. Adding
random increment, with exponential backoff if necessary,
recommended
3.8 Either system MAY close a virtual circuit. If the virtual
is closed or reset while a datagram is being transmitted,
datagram is lost. Systems SHOULD be able to configure a
holding time for circuits to remain open as long as the
Malis, Robinson, & Ullmann [Page 7]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
are up. (Note that holding time, the time the circuit has been open
differs from idle time.)
3.9 Each system MUST use an inactivity timer to clear virtual
that are idle for some period of time. Some X.25 networks
including the ISDN under present tariffs in most areas, charge
virtual circuit holding time. Even where they do not, the
SHOULD be released when idle. The timer SHOULD be configurable;
timer value of "infinite" is acceptable when explicitly configured
The default SHOULD be a small number of minutes. For IP,
reasonable default is 90 seconds
3.10 Systems SHOULD allow calls from unconfigured calling
(presumably not collect calls, however); this SHOULD be
configuration option. A system accepting such a call will,
course, not transmit on that virtual circuit if it cannot
the protocol (e.g., IP) address of the caller. As an example,
the DDN this is not a restriction because IP addresses can
determined algorithmically based upon the caller's X.121
[7,9].
Allowing such calls helps work around various "helpful"
translations done by the network(s), as well as
experimentation with various address resolution protocols
3.11 Systems SHOULD use a configurable hold-down timer to prevent
to failed destinations from being immediately retried
3.12 X.25 implementations MUST minimally support the following
in order to conform with this specification: call setup
clearing and complete packet sequences. For better
and/or interoperability, X.25 implementations SHOULD also support
extended frame and/or packet sequence numbering, flow
parameter negotiation, and reverse charging
3.13 The following X.25 features MUST NOT be used: interrupt packets
the Q bit (indicating qualified data). Other X.25 features
explicitly discussed in this document, such as fast select and
D bit (indicating end-to-end significance) SHOULD NOT be used
Use of the D bit will interfere with use of the M bit (more
sequences) required for identification of PDUs. In particular,
subscription to the D bit modification facility (X.25-1988,
3.3) will prevent proper operation, this user facility MUST NOT
subscribed
3.14 ISO/IEC 8208 [11] defines the clearing diagnostic code 249
signify that a requested protocol is not supported. Systems
Malis, Robinson, & Ullmann [Page 8]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
use this diagnostic code when clearing an incoming call because
identified protocol is not supported. Non-8208 systems
typically use a diagnostic code of 0 for this function.
a diagnostic code is not mandatory, but when it is supplied
this reason, it MUST be either of these two values
4. General
The following remarks are not specifications or requirements
implementations, but provide developers and users with guidelines
the results of operational experience with RFC 877.
4.1 Protocols above the network layer, such as TCP or TP4, do
affect this standard. In particular, no attempt is made to
X.25 virtual circuits corresponding to TCP or TP4 connections
4.2 Both the circuit and multiplexed encapsulations of SNAP may be
to contain any SNAP encapsulated protocol. In particular,
includes using an OUI of 00-00-00 and the two octets of
containing an Ethertype [7], or using IEEE 802.1's OUI of hex 00-
80-C2 with the bridging PIDs listed in RFC 1294, "
Interconnect over Frame Relay" [8]. Note that IEEE 802.1d
can only be performed over a circuit using the Null (multiplexed
encapsulation of SNAP, because of the necessity of preserving
order of PDUs (including 802.1d Bridged PDUs) using different
headers
4.3 Experience has shown that there are X.25 implementations that
assign calls with CC CUD to the X.29 PAD (remote login)
when the IP layer is not installed, not configured properly, or
operating (indeed, they assume that ALL calls for unconfigured
unbound X.25 protocol IDs are for X.29 PAD sessions).
originators can detect that this has occurred at the receiver if
originator receives any X.25 data packets with the Q bit set
especially if the first octet of these packets is hex 02, 04, or 06
(X.29 PAD parameter commands). In this case, the originator
clear the call, and log the occurrence so that the
X.25 address can be corrected. It may be useful to also use
hold-down timer (see section 3.11) to prevent further attempts
some period of time
4.4 It is often assumed that a larger X.25 data packet size will
in increased performance. This is not necessarily true: in
X.25 networks it will actually decrease performance
Many, if not most, X.25 networks completely store X.25 data
in each switch before forwarding them. If the X.25 network
a path through a number of switches, and low-speed trunks are used
Malis, Robinson, & Ullmann [Page 9]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
then negotiating and using large X.25 data packets could result
large transit delays through the X.25 network as a result of
time required to clock the data packets over each low-speed trunk
If a small end-to-end window size is also used, this may
adversely affect the end-to-end throughput of the X.25 circuit.
this reason, segmenting large IP datagrams in the X.25 layer
complete packet sequences of smaller X.25 data packets allows
greater amount of pipelining through the X.25 switches,
subsequent improvements in end-to-end throughput
Large X.25 data packet size combined with slow (e.g., 9.6Kbps
physical circuits will also increase individual packet latency
other virtual circuits on the same path; this may cause
effects on, for example, X.29 connections
This discussion is further complicated by the fact that X.25
networks are free to internally combine or split X.25 data
as long as the complete packet sequence is preserved
The optimum X.25 data packet size is, therefore, dependent on
network, and is not necessarily the largest size offered by
network
4.5 Another method of increasing performance is to open multiple
circuits to the same destination, specifying the same CUD.
packet size, this is not always the best method
When the throughput limitation is due to X.25 window size,
multiple circuits effectively multiplies the window, and
increase performance
However, opening multiple circuits also competes more
for the physical path, by taking more shares of the
bandwidth. While this may be desirable to the user of
encapsulation, it may be somewhat less desirable to the other
of the path
Opening multiple circuits may also cause datagram sequencing
reordering problems in end systems with limited buffering (e.g.,
the TCP level, receiving segments out of order, when a
circuit would have delivered them in order). This will only
performance, not correctness of operation
Opening multiple circuits may also increase the cost of
datagrams across a public data network
Malis, Robinson, & Ullmann [Page 10]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
4.6 This document does not specify any method of dynamic IP to X.25 (
X.121) address resolution. The problem is left for further study
Typical present-day implementations use static tables of
kinds, or an algorithmic transformation between IP and X.121
addresses [7,9]. There are proposals for other methods.
particular, RFC 1183 [10] describes Domain Name System (DNS
resource records that may be useful either for automatic
or for maintenance of static tables. Use of these method(s)
entirely experimental at this time
5. Packet
For each protocol encoding, the diagrams outline the call request
the data packet format. The data packet shown is the first of
complete packet (M bit) sequence
5.1 IP
Call Request
+----------------+-----------+------------+----+
| GFI, LCN, type | addresses | facilities | CC |
+----------------+-----------+------------+----+
X.25 data packets
+----------------+------------------------+
| GFI, LCN, I | IP datagram |
+----------------+------------------------+
5.2 CLNP, ES-IS, IS-IS
Call Request
+----------------+-----------+------------+----+
| GFI, LCN, type | addresses | facilities | 81 |
+----------------+-----------+------------+----+
X.25 data packets
+----------------+--------------------------------+
| GFI, LCN, I | CLNP, ES-IS, or IS-IS datagram |
+----------------+--------------------------------+
(Note that these datagrams are self-identifying in
first octet).
Malis, Robinson, & Ullmann [Page 11]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
5.3 SNAP
Call Request
+----------------+-----------+------------+----+-----------------+
| GFI, LCN, type | addresses | facilities | 80 | SNAP (5 octets) |
+----------------+-----------+------------+----+-----------------+
X.25 data packets
+----------------+-------------------------------------+
| GFI, LCN, I | Protocol Data Unit (no SNAP header) |
+----------------+-------------------------------------+
5.4 Null (Multiplexed)
Call Request
+----------------+-----------+------------+----+
| GFI, LCN, type | addresses | facilities | 00 |
+----------------+-----------+------------+----+
X.25 data packets
+----------------+-----------------+---------------------+
| GFI, LCN, I | NLPID (1 octet) | Protocol Data Unit |
+----------------+-----------------+---------------------+
Examples of data packets
Multiplexed IP datagram
+----------------+----+-----------------------+
| GFI, LCN, I | CC | IP datagram |
+----------------+----+-----------------------+
Multiplexed CLNP datagram
+----------------+----+-------------------------+
| GFI, LCN, I | 81 | CLNP datagram |
+----------------+----+-------------------------+
Multiplexed SNAP PDU
+----------------+----+-----------------+--------------------+
| GFI, LCN, I | 80 | SNAP (5 octets) | Protocol Data Unit |
+----------------+----+-----------------+--------------------+
Malis, Robinson, & Ullmann [Page 12]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
6. Security
Security issues are not discussed in this memo
7.
[1] Korb, J., "A Standard for the Transmission of IP Datagrams
Public Data Networks", RFC 877, Purdue University,
1983.
[2] ISO/IEC TR 9577, Information technology - Telecommunications
Information exchange between systems - Protocol
in the network layer, 1990 (E) 1990-10-15.
[3] IEEE, "IEEE Standard for Local and Metropolitan Area Networks
Overview and Architecture", IEEE Standards 802-1990.
[4] ISO/IEC 8473, Information processing systems -
communications - Protocol for providing the connectionless-
network service, 1988.
[5] ISO/IEC 9542, Information processing systems -
Telecommunications and information exchange between systems -
End system to intermediate system routeing protocol for use
conjunction with the protocol for providing the connectionless
mode network service (ISO/IEC 8473), 1988.
[6] Postel, J., Editor., "Internet Protocol - DARPA Internet
Protocol Specification", RFC 791, USC/Information
Institute, September 1981.
[7] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1340,
USC/Information Sciences Institute, July 1992.
[8] Bradley, T., Brown, C., and A. Malis, "
Interconnect over Frame Relay", RFC 1294,
Communications and BBN Communications, January 1992.
[9] "Defense Data Network X.25 Host Interface Specification",
contained in "DDN Protocol Handbook", Volume 1, DDN
Information Center 50004, December 1985.
[10] Everhart, C., Mamakos, L., Ullmann, R, and P. Mockapetris
Editors, "New DNS RR Definitions", RFC 1183, Transarc
University of Maryland, Prime Computer, USC/Information
Institute, October 1990.
[11] ISO/IEC 8208, Information processing systems -
Malis, Robinson, & Ullmann [Page 13]
RFC 1356 Multiprotocol Interconnect on X.25 August 1992
communications - X.25 Packet Level Protocol for Data
Equipment, 1987.
8. Authors'
Andrew G.
BBN
150 CambridgePark
Cambridge, MA 02140
Phone: +1 617 873 3419
Email: malis@bbn.
David
Computervision Systems
201 Burlington
Bedford, MA 01730
Phone: +1 617 275 1800 x2774
Email: drb@relay.prime.
Robert L.
Process Software
959 Concord
Framingham, MA 01701
Phone: +1 508 879 6994
Email: ariel@process.
Malis, Robinson, & Ullmann [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
