As per Relevance of the word discussion, we have this rfc below:
Network Working Group J.
Request for Comments: 1613 G.
Category: Informational G.
cisco Systems, Inc
R.
May 1994
cisco Systems X.25 over TCP (XOT
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Table of
1. Introduction....................................................1
2. Conventions.....................................................2
3. Relationship Between XOT and X.25...............................2
4. Overall Packet Format...........................................3
4.1 XOT Header....................................................4
5. TCP Connection, Port Number, and Logical Channel Numbers (LCNs).4
6. XOT Packets.....................................................5
6.1 Virtual Circuit Setup and Clearing............................5
6.2 Data and Flow Control.........................................6
6.3 Interrupt, and Reset Packets..................................8
6.4 Restart, DTE Reject, Diagnostics, and Registration............8
6.5 PVC Setup.....................................................8
7. Acknowledgments................................................12
8. Security Considerations........................................12
9. References.....................................................12
10. Authors' Addresses.............................................13
1.
It is sometimes desirable to transport X.25 over IP internets.
X.25 Packet Level requires a reliable link level below it
normally uses LAPB. This memo documents a method of sending X.25
packets over IP internets by encapsulating the X.25 Packet Level
TCP packets
TCP provides a reliable byte stream. X.25 requires that the
below it provide message semantics, in particular the
between packets. To provide this, a small (4-byte) XOT header
used between TCP and X.25. The primary content of this header is
Forster, Satz, Glick & Day [Page 1]
RFC 1613 X.25 Over TCP (XOT) May 1994
length field, which is used to separate the X.25 packets within
TCP stream
In general, the normal X.25 protocol packet formats and
transition rules apply to the X.25 layer in XOT. Exceptions to
are noted
2.
The following language conventions are used in the items
specification in this document
o MUST, SHALL, or MANDATORY -- This item is an
requirement of the specification
o SHOULD or RECOMMEND -- This item should generally be
for all but exceptional circumstances
o MAY or OPTIONAL -- This item is truly optional and may
followed or ignored according to the needs of the implementor
In some places in this document, there is parenthetical
labeled "DISCUSSION". This material is intended to
clarification and explanation of the preceding text
3. Relationship Between XOT and X.25
When a networking device (a host, router, etc.) has an X.25
(i.e., protocol implementation), that engine may be connected
interface(s) running LAPB, and/or to logical interface(s) running
or XOT/TCP/IP. In general, the XOT layer itself is not at
sensitive to what kind of packets the X.25 engine passes to it
However, to improve interoperability between
implementations, this document in some cases does specify behavior
the X.25 engine
While this document primarily discusses XOT from the perspective
switching X.25 traffic (i.e., connecting an X.25 Virtual
between the local X.25 interfaces of two networking devices),
should not prevent a host from offering X.25 connectivity using XOT
The various X.25 standards may call a given packet type by
different name according to the assigned DTE/DCE role of
interface that originated the packet. XOT is intended to
insensitive to the DTE/DCE role of the local interfaces at either
of an XOT TCP connection, so, for this document, the following
are interchangeable unless stated otherwise
Forster, Satz, Glick & Day [Page 2]
RFC 1613 X.25 Over TCP (XOT) May 1994
o Call, Call Request and Incoming
o Call Confirm, Call Accepted and Call
o Clear, Clear Request and Clear
o Clear Confirm, DTE Clear Confirmation and DCE Clear
o Data, DTE Data and DCE
o Interrupt, DTE Interrupt and DCE
o Interrupt Confirm, DTE Interrupt Confirmation
DCE Interrupt
o RR, DTE RR and DCE
o RNR, DTE RNR and DCE
o REJ, Reject and DTE
o Reset, Reset Request and Reset
o Reset Confirm, DTE Reset Confirmation and DCE Reset
o Restart, Restart Request and Restart
o Restart Confirm, DTE Restart Confirmation
DCE Restart
4. Overall Packet
The entire encapsulated packet has the following format
---------------------------------
| |
| IP Header |
| |
---------------------------------
| |
| TCP Header |
| |
---------------------------------
| |
| XOT Header |
| |
---------------------------------
| |
| X.25 Packet |
| |
---------------------------------
RFC convention is that a packet format is represented
with the data sent first above the data sent later. This
is followed in this document, and therefore, while we refer to X.25
being transported over TCP, we draw the packet format with the X.25
portion of the packet lower on the page than the TCP portion
Forster, Satz, Glick & Day [Page 3]
RFC 1613 X.25 Over TCP (XOT) May 1994
4.1 XOT
The XOT header has the format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Version (2 octets
The version number of the XOT protocol is encoded in the
two octets. The version number MUST be 0. Other values
this field are reserved for future use. If a value other
0 is received, then the TCP connection MUST be closed
Length (2 octets
The length of the X.25 packet is encoded in the second
octets. Values must be legal X.25 packet lengths. If
Length field has an illegal value, then the TCP connection
be closed
5. TCP Connection, Port Number, and Logical Channel Numbers (LCNs
A separate TCP connection MUST be used for each X.25 virtual circuit
All connections MUST be made to TCP port number 1998. This
number is an IANA Registered Port Number registered by cisco Systems
cisco has designated it for use by XOT
The TCP connection MUST be created before the virtual circuit can
established. The TCP connection MAY be maintained after the
circuit has been cleared. Data MUST NOT be passed along with the
SYN packet
The Logical Channel Number (LCN) field in the X.25 header has
significance and has arbitrary values. A corollary of this is
there is no assignment of one side of the connection to be DTE
another to be DCE
Consider three devices A, B and C, where A and B both conduct
sessions to C. It's possible that C could receive two calls
the same LCN and, unless the X.25 engine could tell that they
received on different logical (XOT) interfaces, here would
danger of call collision (indeed a valid LCN on one interface
Forster, Satz, Glick & Day [Page 4]
RFC 1613 X.25 Over TCP (XOT) May 1994
not even be valid on a different interface). It is
necessary for C's X.25 engine to distinguish between the
streams, but the LCN field is not sufficient to do this. The
protocol design decision was to expect the XOT layer
communicate the stream identification to the X.25 layer
6. XOT
For each X.25 packet received from the TCP connection to be sent
a local interface, an XOT implementation MUST set the packet'
logical channel number to that used on the outgoing interface.
the purposes of this RFC, a logical channel number is the 12
field confusingly defined by the X.25 Recommendations as the high
order 4 bit "logical channel group number" and low-order 8
"logical channel number", where the latter phrase is used to refer
both the aggregated 12 bits and the low-order 8 bits
An XOT implementation SHOULD NOT modify the X.25 packet
information received on a local interface to be transmitted over
TCP connection
An XOT implementation MUST modify the X.25 packet header
as required for proper X.25 protocol operation for packets
on a TCP connection to be transmitted over a local interface
An XOT implementation MAY support connection between interfaces
use different flow control modulos. If this feature is supported
XOT MUST modify the packet General Format Identifier on all
received over the TCP connection to set the proper
identifier
6.1 Virtual Circuit Setup and
Once a TCP connection has been established, the X.25 Call packet
sent by the XOT that initiated the TCP connection. Eventually a
Confirm or Clear packet is received, or the X.25 T11/T21
occurs or the XOT TCP connection is closed. The usual X.25
transitions are followed
Any legal X.25 facilities from the family of X.25
(including but not limited to the 1980, 1984 and 1988 CCITT X.25
Recommendations) MAY be included in the Call, Call Confirm and
packets. Receipt of an unknown or unsupported X.25 facility
from the TCP connection SHOULD be ignored (i.e., not presented in
packet sent out the local interface) or treated as an error
defined by the X.25 standard implemented
Forster, Satz, Glick & Day [Page 5]
RFC 1613 X.25 Over TCP (XOT) May 1994
To simplify end-to-end flow control, the packet size and window
are always sent explicitly as facilities in the Call packet.
Call packet MUST contain both Packet Size and Window Size facilities
The Call Confirm packet MAY contain these facilities. The
of a Call received over a TCP connection that does not encode one
both of the flow control facilities is a local matter--if the
accepts such a Call, it MUST encode the missing flow control
values that apply to the connection in the returned Call
packet
X.25 interfaces normally have a concept of network default
for packet size and window size. It was thought that
connecting diverse sites over a TCP/IP network this concept
be difficult to achieve in practice. If there is no
default, then each call must state the packet size and
size. This is the reason for requiring the packet size and
size facilities. It is expected that this can be achieved
by the XOT layer itself, or by configuring the X.25 engine
that there no network default on this interface
After sending a Clear the TCP connection MAY be closed
without waiting for the Clear Confirm. A Clear Confirm received
the TCP connection MAY be silently discarded
A packet with an invalid X.25 Packet Type Identifier (PTI)
over the TCP connection before a Call has been received (i.e.,
in the P1 state) MUST be silently discarded
6.2 Data and Flow
The implementation of X.25 flow control is a local matter,
different implementation choices affect XOT behavior
An XOT implementation may implement either end-to-end
control, where DATA, RR and RNR packets are sent over the
connection as received over the local interface, or local
control, where flow control packets (RR, RNR and, if supported
REJ) are sent on a VC according to local criteria, a
packet sequence of DATA packets may be fragmented or combined,
data packet numbering normally has only local DTE-
significance
Existing implementations of XOT perform end-to-end flow control
Data and flow control packets are simply transferred between
Forster, Satz, Glick & Day [Page 6]
RFC 1613 X.25 Over TCP (XOT) May 1994
two local interfaces via the TCP connection, adjusting the X.25
header data as necessary for mixed modulo operation. This
not preclude an XOT implementation that performs local
control, but interoperability requires that a local flow
implementation conduct the XOT session such that a
end-to-end flow control implementation receives Data packets
the proper size and flow control fields with appropriate P(S)
P(R) values
An X.25 implementation that performs local flow control
may set up a Call between two local interfaces where each
channel has its own packet and window sizes and Data packets
be fragmented or collected between the interfaces and
interface manages distinct packet sequence numbers; XOT
is simply an extension to this operation as a VC is
between the local interface and an XOT/TCP virtual interface,
of which have distinct window and packet sizes
An XOT that implements local flow control MUST send data
acknowledgements across the TCP connection for the DATA packets
receives from the TCP connection, using the received packet numbers
and MUST observe the maximum packet sizes agreed to across the
connection
An XOT implementation MUST NOT assume that an RNR sent across the
connection will stop the flow of DATA packets in the other direction
An RNR packet received from the TCP connection MAY cause an
packet to be sent across the local interface; end-to-end flow
implementations MAY communicate the P(R) in an RNR packet
from the TCP connection by sending an RR packet on the
interface
An XOT implementation that allows mixed-modulo connections
implements end-to-end flow control MUST intervene in the window
negotiation process when a modulo 128 Call Request proposes a
size of 8 or larger to an XOT connection that serves a modulo 8
interface. The intervention MUST either refuse the connection
lower the too-large window size(s) to a value valid for the
and indicate the final result of the window size negotiation
in the Call Confirm packet returned over the TCP connection
For any type of flow control implementation that supports
modulo connections, both cooperating XOTs MUST interpret the the P(S
and P(R) values received from the TCP connection and perform any
control operation appropriate for correct X.25 operation of the
interface. End-to-end flow control implementations MUST
between the two modulos and construct the analogous X.25 header P(S
and P(R) fields for DATA, RR and RNR packets
Forster, Satz, Glick & Day [Page 7]
RFC 1613 X.25 Over TCP (XOT) May 1994
An XOT implementation MAY support connecting two XOT TCP sessions
each other. If this feature is supported, XOT MUST simply
the two TCP sessions without modifying the data passed
6.3 Interrupt, and Reset
Interrupt, Interrupt Confirm, Reset and Reset Confirm packets
sent over the TCP connection using the normal X.25 packet formats
state transitions. The end-to-end nature of both the Interrupt
Reset services MUST be maintained for correct X.25 operation
6.4 Restart, DTE Reject, Diagnostics, and
X.25 packets that have only a local DTE/DCE interface
(Restart, Restart Confirm, DTE Reject, Diagnostic,
Request and Registration Confirmation) MUST NOT be sent over the
connection. If one of these packets is received, then it MUST
silently discarded
6.5 PVC
An XOT implementation MAY support connecting a PVC via XOT
X.25 PVCs are Virtual Circuits that are presumed to be
when the X.25 service is available (i.e., in the R1 state).
Connecting a PVC via XOT is complicated because no Call,
Confirm, Clear or Clear Confirm packets are transferred (
allowed) across the X.25 interface--PVCs are simply
because they have been provisioned by the network provider
contracted for by the network users
Supporting a PVC using XOT requires a data exchange between
XOT entities that is outside the scope of the X.25 standards,
must provide for a number of error conditions
The setup of a PVC between two XOT entities is performed
exchanging a non-standard X.25 packet type (encapsulated in an
Header); the PVC setup exchange takes place immediately after a
TCP XOT connection has been established. The XOT implementation
initiated the TCP connection is the initiator; the other XOT is
responder
Forster, Satz, Glick & Day [Page 8]
RFC 1613 X.25 Over TCP (XOT) May 1994
The PVC Setup packet includes the X.25 General Format Identifier,
and Packet Type Identifier fields followed by additional data.
non-standard packet type takes the form
+--+--+--+--+--+--+--+--+--+
| X.25 GFI | X.25 LCN |
+--+--+--+--+ +
| |
+--+--+--+--+--+--+--+--+--+
| X.25 PTI | PVC setup PTI (= 0xF5)
+--+--+--+--+--+--+--+--+--+
| | version (= 0x81)
+--+--+--+--+--+--+--+--+--+
| |
+--+--+--+--+--+--+--+--+--+
| | initiator interface name length (N
+--+--+--+--+--+--+--+--+--+
| | initiator LCN (high octet
+--+--+--+--+--+--+--+--+--+
| | initiator LCN (low octet
+--+--+--+--+--+--+--+--+--+
| | responder interface name length (M
+--+--+--+--+--+--+--+--+--+
| | responder LCN (high octet
+--+--+--+--+--+--+--+--+--+
| | responder LCN (low octet
+--+--+--+--+--+--+--+--+--+
| | sender incoming
+--+--+--+--+--+--+--+--+--+
| | sender outgoing
+--+--+--+--+--+--+--+--+--+
| | sender incoming max. packet
+--+--+--+--+--+--+--+--+--+
| | sender outgoing max. packet
+--+--+--+--+--+--+--+--+--+
| | initiator interface name (N octets
| |
+--+--+--+--+--+--+--+--+--+
| | responder interface name (M octets
| |
+--+--+--+--+--+--+--+--+--+
The PVC setup packet was designed so that the responder
simply modify a few fields of the received packet and send it
to the initiator
Forster, Satz, Glick & Day [Page 9]
RFC 1613 X.25 Over TCP (XOT) May 1994
The Packet Type Identifier was chosen from the unused X.25
values so it is distinct from the standard X.25 Packet
Identifiers
The PVC setup version value was chosen to prevent connections
prior experimental implementations
The PVC status field has the following values defined
Status
------ --------------------------------------
0x00 Waiting to
0x08 Destination
0x09 PVC/TCP connection
0x0A PVC/TCP routing
0x0B PVC/TCP connect timed
0x10 Trying to connect via
0x11 Awaiting PVC-SETUP
0x12
0x13 No such destination
0x14 Destination interface is not
0x15 Non-X.25 destination
0x16 No such destination
0x17 Destination PVC configuration
0x18 Mismatched flow control
0x19 Can't support flow control
0x1A PVC setup protocol
Not all of the PVC status values are appropriate for a PVC
packet; these values represent a particular implementation
chose to assign values in three groups that correspond to a
timer for a connect attempt (0x00 through 0x07), a long timer
a connect attempt (0x08 through 0x0F) and no attempt to
(greater than 0x0F). The values that are appropriate for a
setup packet are 0x00 and those values greater than 0x12.
Most of the PVC status error values that may be found in a
message are self-explanatory, with a few exceptions. The
0x17, "Destination PVC configuration mismatch" may returned in
case that the targeted PVC already has an XOT PVC
active. The value 0x19, "Can't support flow control values",
be returned when the flow control values match but, for instance
a modulo 8 interface is requested to set up a PVC with a
size greater than 7 or an interface is requested to set up a
Forster, Satz, Glick & Day [Page 10]
RFC 1613 X.25 Over TCP (XOT) May 1994
with a maximum packet size that is too large for its data
layer to transfer
An XOT MAY retry a failed PVC setup; if implemented the XOT
wait between attempts (5 minutes is suggested).
Each XOT PVC is configured with the identity of the other XOT (i.e.,
IP address), the name of the interface to connect to, the
Channel Number on that interface and the flow control values to use
These data are present in the PVC setup packets and the
XOT verifies the configurations are compatible
The interface name fields are the ASCII names of the two
involved. These names SHOULD be case-insensitive. There MUST NOT
any padding or trailing zero octets between or after the
names
The flow control values are the values from the perspective of
local interface of the XOT implementation that sent the PVC
packet. The maximum packet size values are encoded as they are
the packet size facility, (i.e., the base-2 log of the size
octets, so 7 represents a maximum packet size of 128 octets). If
responding XOT implements end-to-end flow control, it will
that the configured flow control values be complimentary, so
returned status of 0x18 will indicate the values required by
responding XOT (note that the incoming value of one local
corresponds to the outgoing value of the connecting local interface
and vice-versa).
After establishing the TCP connection the initiator sends a PVC
packet, the status value MUST be 0x00; the responder will reply
its own PVC setup packet or by closing the TCP connection. An
PVC setup is successful if the responder returns a status of 0x00.
Once the XOT PVC connection is successfully established, each
MUST complete a Reset procedure on the local interface, so if
local interface LCI is in state D1, a Reset packet would be
both to the local interface and the XOT TCP connection
An XOT PVC connection is broken by simply closing the TCP connection
X.25 packets that are not legal for PVCs MUST NOT be
across an XOT PVC connection. When a local interface undergoes
Restart procedure, the XOT PVC connections MUST be either perform
Reset (which is appropriate if the interface remains in state R1)
close the XOT PVC connection
Forster, Satz, Glick & Day [Page 11]
RFC 1613 X.25 Over TCP (XOT) May 1994
An XOT implementation SHOULD also consider how a PVC
collision will be handled. Receipt of an XOT PVC setup for a
that is itself attempting to setup an XOT connection could
accept a (valid) setup attempt and, if two TCP XOT
result, simply use one connection to send XOT data (XOT MUST
send traffic over both) and accept XOT data on either, or it
close the incoming attempt and, if no connections result,
the connection after waiting for a random interval. If
connections are allowed for a PVC, closure of one SHOULD result
the closure of the other
7.
Greg Satz is the original designer and implementor of X.25 over TCP
Aviva Garrett of cisco Systems reviewed the specification and
many editorial corrections
8. Security
Security issues are not discussed in this memo
9.
[1] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1340,
USC/Information Sciences Institute, July 1992.
[2] CCITT, Blue Book Volume VIII--Fascicle VIII.2, "
Communication Networks: Services and Facilities, Interfaces";
Recommendation X.25, "Interface Between Data Circuit-
Equipment (DCE) for Terminals Operating in the Packet Mode
Connected to Public Data Networks by Dedicated Circuit", 1989,
Geneva
Forster, Satz, Glick & Day [Page 12]
RFC 1613 X.25 Over TCP (XOT) May 1994
10. Authors'
James R.
Engineering Dept
cisco
1525 O'Brien Dr
Menlo Park. CA. 94025
Phone: 1.415.688.8245
Fax: 1.415.688.8282
EMail: forster@cisco.
Greg
Engineering Dept
cisco
1525 O'Brien Dr
Menlo Park. CA. 94025
Phone: 1.415.688.8245
Fax: 1.415.688.8282
EMail: satz@cisco.
Gilbert
Engineering Dept
cisco
1525 O'Brien Dr
Menlo Park. CA. 94025
Phone: 1.415.688.8245
Fax: 1.415.688.8282
EMail: gglick@cisco.
Bob
Joint Network
c/o Rutherford Appleton
Oxfordshire OX11 0
United
Phone: 44.235.44.5163
Fax: 44.235.44.6251
EMail: R.Day@jnt.ac.
Forster, Satz, Glick & Day [Page 13]
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
