As per Relevance of the word document, we have this rfc below:
Network Working Group W.
Request for Comments: 1598
Category: Standards Track March 1994
PPP in X.25
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links
This document describes the use of X.25 for framing PPP
packets
This document is the product of the Point-to-Point Protocol
Group of the Internet Engineering Task Force (IETF). Comments
be submitted to the ietf-ppp@merit.edu mailing list
This specification is intended for those implementations which
to use facilities which are defined for PPP, such as the Link
Protocol, Network-layer Control Protocols, authentication,
compression. These capabilities require a point-to-
relationship between peers, and are not designed for multi-point
multi-access environments
Simpson [Page i
RFC 1598 PPP in X.25 March 1994
Table of
1. Introduction .......................................... 1
2. Physical Layer Requirements ........................... 2
3. The Data Link Layer ................................... 2
3.1 Frame Format .................................... 3
3.2 Modification of the Basic Frame ................. 3
4. Call Setup ............................................ 4
5. Configuration Details ................................. 5
SECURITY CONSIDERATIONS ...................................... 6
REFERENCES ................................................... 6
ACKNOWLEDGEMENTS ............................................. 6
CHAIR'S ADDRESS .............................................. 7
AUTHOR'S ADDRESS ............................................. 7
1.
CCITT recommendation X.25 [2] describes a network layer
providing error-free, sequenced, flow controlled, virtual circuits
X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335
and 6256.
PPP also uses ISO 3309 HDLC as a basis for its framing [3].
When X.25 is configured as a point-to-point circuit, PPP can use X.25
as a framing mechanism, ignoring its other features. This
equivalent to the technique used to carry SNAP headers over X.25 [4].
At one time, it had been hoped that PPP HDLC frames and X.25
would co-exist on the same links. Equipment could gradually
converted to PPP. Subsequently, it has been learned that
switches actually remove the X.25 header, transport packets
another switch using a different protocol such as Frame Relay,
reconstruct the X.25 header at the final hop. Co-existance
gradual migration are precluded
Simpson [Page 1]
RFC 1598 PPP in X.25 March 1994
2. Physical Layer
PPP treats X.25 framing as a bit synchronous link. The link MUST
full-duplex, but MAY be either dedicated (permanent) or switched
Interface
PPP presents an octet interface to the physical layer. There
no provision for sub-octets to be supplied or accepted
Transmission
PPP does not impose any restrictions regarding transmission rate
other than that of the particular X.25 interface
Control
Implementation of X.25 requires the provision of control signals
which indicate when the link has become connected or disconnected
These in turn provide the Up and Down events to the LCP
machine
Because PPP does not normally require the use of control signals
the failure of such signals MUST NOT affect correct operation
PPP. Implications are discussed in [2].
The definition of various encodings is the responsibility of
DTE/DCE equipment in use, and is outside the scope of
specification
While PPP will operate without regard to the
representation of the bit stream, X.25 requires NRZ encoding
3. The Data Link
This specification uses the principles, terminology, and
structure described in "Multiprotocol Interconnect on X.25 and
in the Packet Mode" [4].
The purpose of this specification is not to document what is
standardized in [4]. Instead, this document attempts to give
concise summary and point out specific options and features used
PPP
Simpson [Page 2]
RFC 1598 PPP in X.25 March 1994
3.1. Frame
Since both "PPP in HDLC Framing" [3] and X.25 use ISO 3309 as a
for framing, the X.25 header is easily substituted for the
HDLC header. The fields are transmitted from left to right
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
+-+-+-+-+-+-+-+-+
| Flag (0x7e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address | Control |D|Q| SVC# (hi) | SVC# (lo) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|p(r) |M|p(s) |0| PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PPP Protocol field and the following Information and
fields are described in the Point-to-Point Protocol
[1].
3.2. Modification of the Basic
The Link Control Protocol can negotiate modifications to the
frame structure. However, modified frames will always be
distinguishable from standard frames
Address-and-Control-Field-
Because the Address and Control field values are not constant,
are modified as the frame is transported by the network
fabric, Address-and-Control-Field-Compression MUST NOT
negotiated
Protocol-Field-
Note that unlike the HDLC framing, the X.25 framing does not
the Information field on a 32-bit boundary. Alignment to a 16-
boundary occurs when the Protocol field is compressed to a
octet. When this improves throughput, Protocol-Field-
SHOULD be negotiated
Simpson [Page 3]
RFC 1598 PPP in X.25 March 1994
4. Call
When the link is configured as a Permanent Virtual Circuit (PVC),
support for Switched Virtual Circuit (SVC) call setup and clearing
not required. Calls are Established and Terminated using PPP
packets
When the link is configured as a Switched Virtual Circuit (SVC),
first octet in the Call User Data (CUD) Field (the first data
in the Call Request packet) is used for protocol demultiplexing,
accordance with the Subsequent Protocol Identifier (SPI) in ISO/
TR 9577 [5]. This field contains a one octet Network Layer
Identifier (NLPID), which identifies the encapsulation in use
the X.25 virtual circuit. The CUD field MAY contain more than
octet of information
The PPP encapsulation MUST be indicated by the PPP NLPID value (
hex). Any subsequent octet in this CUD is extraneous and MUST
ignored
Multipoint networks (or multicast groups) MUST refuse calls
indicate the PPP NLPID in the CUD
The accidental connection of a link to feed a multipoint network (
multicast group) SHOULD result in a misconfiguration indication
This can be detected by multiple responses to the LCP Configure
Request with the same Identifier, coming from different
addresses. Some implementations might be physically unable to
log or report such information
Conformance with this specification requires that the PPP NLPID (CF
be supported. In addition, conformance with [4] requires that the
NLPID (CC) be supported, and does not require that other NLPID
be supported, such as Zero (00), SNAP (80), CLNP (81) or ES-IS (82).
When IP address negotiation and/or VJ header compression are desired
the PPP call setup SHOULD be attempted first. If the PPP call
fails, the normal IP call setup MUST be used
The PPP NLPID value SHOULD NOT be used to demultiplex circuits
use the Zero NLPID in call setup, as described in [4]. When such
circuit exists concurrently with PPP encapsulated circuits,
network layer traffic which has not been negotiated by the
NCP is sent over the Zero NLPID circuit
Rationale
Using call setup to determine if PPP is supported should
Simpson [Page 4]
RFC 1598 PPP in X.25 March 1994
inexpensive, when users aren't charged for failed calls
Using the Zero NLPID call together with PPP could be expensive
when users are charged per packet or for connect time, due to
probing of PPP configuration packets at each call
PPP configuration provides a direct indication of the
of service, and on that basis is preferred over the Zero
technique, which can result in "black-holes".
5. Configuration
The following Configuration Options are recommended
Magic
Protocol Field
The standard LCP configuration defaults apply to X.25 links,
MRU
To ensure interoperability with existing X.25 implementations,
initial Maximum-Receive-Unit (MRU) is 1600 octets [4]. This
affects the minimum required buffer space available for
packets, not the size of packets sent
The typical network feeding the link is likely to have a MRU
either 1500, or 2048 or greater. To avoid fragmentation,
Maximum-Transmission-Unit (MTU) at the network layer SHOULD
exceed 1500, unless a peer MRU of 2048 or greater is
negotiated
The X.25 packet size is not directly related to the MRU. Instead
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 larger
one X.25 data packet in length
Simpson [Page 5]
RFC 1598 PPP in X.25 March 1994
Security
Implementations MUST NOT consider PPP authentication on call
for one circuit between two systems to apply to concurrent call
for other circuits between those same two systems. This results
possible security lapses due to over-reliance on the integrity
security of switching systems and administrations. An
attack might be undetected. An attacker which is able to spoof
same calling identity might be able to avoid link authentication
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
1548, December 1993.
[2] CCITT Recommendation X.25, "Interface Between Data
Equipment (DTE) and Data Circuit Terminating Equipment (DCE
for Terminals Operating in the Packet Mode on Public
Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25.
[3] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549,
1993.
[4] Malis, A., Robinson, D., and R. Ullmann, "Multiprotocol
Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356,
August 1992.
[5] ISO/IEC TR 9577, "Information technology -
and Information exchange between systems -
Identification in the network layer", 1990 (E) 1990-10-15.
This design was inspired by the paper "Parameter Negotiation for
Multiprotocol Interconnect", Keith Sklower and Clifford Frost
University of California, Berkeley, 1992, unpublished
Simpson [Page 6]
RFC 1598 PPP in X.25 March 1994
Chair's
The working group can be contacted via the current chair
Fred
Advanced Computer
315 Bollay
Santa Barbara, California 93117
EMail: fbaker@acc.
Author's
Questions about this memo can also be directed to
William Allen
Computer Systems Consulting
1384
Madison Heights, Michigan 48071
EMail: Bill.Simpson@um.cc.umich.
bsimpson@MorningStar.
Simpson [Page 7]
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
