As per Relevance of the word reference, we have this rfc below:
Network Working Group W.
Request for Comments: 1618
Category: Standards Track May 1994
PPP over
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 PPP over Integrated
Digital Network (ISDN) switched circuits
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 the PPP encapsulation over ISDN point-to-point links. PPP
not designed for multi-point or multi-access environments
"It is clear that there is never likely to be a single, monolithic
worldwide ISDN." [3] The goal of this document is to describe a
common implementations, chosen from the current wide variety
alternatives, in an effort to promote interoperability
Simpson [Page i
RFC 1618 PPP over ISDN May 1994
Table of
1. Introduction .......................................... 1
2. Physical Layer Requirements ........................... 1
3. Framing ............................................... 3
4. Out-of-Band signaling ................................. 4
5. Configuration Details ................................. 5
SECURITY CONSIDERATIONS ...................................... 5
REFERENCES ................................................... 5
ACKNOWLEDGEMENTS ............................................. 6
CHAIR'S ADDRESS .............................................. 6
AUTHOR'S ADDRESS ............................................. 6
Simpson [Page ii
RFC 1618 PPP over ISDN May 1994
1.
PPP was designed as a standard method of communicating over point
to-point links. Initial deployment has been over short local lines
leased lines, and plain-old-telephone-service (POTS) using modems
As new packet services and higher speed lines are introduced, PPP
easily deployed in these environments as well
This specification is primarily concerned with the use of the
encapsulation over ISDN links. Since the ISDN B-channel is
definition a point-to-point circuit, PPP is well suited to use
these links
The ISDN Primary Rate Interface (PRI) may support many concurrent B
channel links. The PPP LCP and NCP mechanisms are
useful in this situation in reducing or eliminating
configuration, and facilitating ease of communication between
implementations
The ISDN D-channel can also be used for sending PPP packets
suitably framed, but is limited in bandwidth and often
communication links to a local switch
The terminology of ISDN can be confusing. Here is a simple
representation of the points used in subsequent descriptions
+-------+ +-------+ +-------+
R | | S | | T | |
+---+ TA +--+--+ NT2 +--+--+ NT1 +---+
| | | | | |
+-------+ +-------+ +-------+
These elements are frequently combined into a single device
2. Physical Layer
PPP treats ISDN channels as bit or octet oriented synchronous links
These links MUST be full-duplex, but MAY be either dedicated
circuit-switched
Interface
PPP presents an octet interface to the physical layer. There
no provision for sub-octets to be supplied or accepted. The
stream is applied primarily at the R or T reference points
Simpson [Page 1]
RFC 1618 PPP over ISDN May 1994
Transmission
PPP does not impose any restrictions regarding transmission rate
other than that of the particular ISDN channel interface
Control
PPP does not require the use of control signals. When available
using such signals can allow greater functionality
performance. Implications are discussed in [2].
Control signals MAY be required by some of the framing
described, and is outside the scope of this specification
The definition of various encodings and scrambling is
responsibility of the DTE/DCE equipment in use, and is outside
scope of this specification
While PPP will operate without regard to the
representation of the bit stream, lack of standards
transmission will hinder interoperability as surely as lack
data link standards. The D-channel LAPD interface requires
encoding at the T reference point. Therefore, as a default, it
recommended that NRZ be used over the B-channel interface at the
reference point. This will allow frames to be easily
between the B and D channels
When configuration of the encoding is allowed, NRZI is
as an alternative in order to ensure a minimum ones density
required over the clear B-channel, with caveats regarding FCS [2].
Historically, some implementations have used Inverted NRZ (
switching the sense of mark and space), in order to ensure
minimum ones density with bit-synchronous HDLC. The use
Inverted NRZ is deprecated
Automatic
Implementations which desire to interoperate with
encodings MAY choose to detect those encodings automatically
Automatic encoding detection is particularly important
Primary Rate Interfaces, to avoid extensive pre-configuration
Only simple encodings are currently distinguished
The only reliable method of detection available is to
modes between the supported encodings. Transmission of the
Simpson [Page 2]
RFC 1618 PPP over ISDN May 1994
Configure-Request SHOULD be tried twice for each mode
switching in rotation. This ensures that sufficient time
available for a response to arrive from the peer
Max-Configure MUST be set such that the cumulative
result in no more than 59 seconds of time before disconnect
It is preferable that the usual limit of 30 seconds
observed
Prior
By prior configuration, PPP MAY also be used with
encodings. Because of difficulty distinguishing them, it
not recommended that these encodings be automatically detected
Terminal adapters conforming to V.120 [4] can be used as
simple interface to workstations. Asynchronous HDLC
[2] is accepted at the R reference point. The terminal
provides async-sync conversion. Multiple B-channels can
used in parallel. Unfortunately, V.120 has a framing mode
its own for rate adaptation, which is difficult to
from Frame Relay, and which can confuse in-band
detection. V.120 is not interoperable with bit-
links, since V.120 does not provide octet-stuffing to bit
stuffing conversion. Therefore, V.120 is deprecated in
of more modern standards, such as "PPP in Frame Relay".
The "Bandwidth On Demand Interoperability Group" has defined
proposal called BONDING. Multiple B-channels can be used
parallel. BONDING has an initialization period of its own
which might conflict with the simple detection
described above, and requires extensive
configuration in some current implementations when multiple B
channels are involved. It is recommended that the PPP Multi
Link Procedure be used instead of BONDING
3.
For B-channels, in the absence of prior configuration,
implementation MUST first use bit-synchronous HDLC [2], as opposed
other framings, for initial link establishment. This assumes
circuit-switched communications are generally [host | router]
[host | router].
By prior configuration, octet-synchronous HDLC [2] is
where the network termination equipment interfaces directly to the
Simpson [Page 3]
RFC 1618 PPP over ISDN May 1994
reference point, and octet boundaries are available at the time
framing. Such equipment is likely to be highly integrated, and
elimination of bit-synchronous hardware can reduce the part count
resulting in lower cost interfaces and simpler configuration
Octet-synchronous HDLC MUST be used with NRZ bit encoding
For D-channels, by default no data service is expected. By
configuration, "PPP in X.25" or "PPP in Frame Relay" framing MAY
used
Despite the fact that HDLC, LAPB, LAPD, and LAPF are
distinguishable, multiple methods of framing SHOULD NOT be
concurrently on the same ISDN channel. There is no requirement
PPP recognize alternative framing techniques, or switch
framing techniques without specific configuration
4. Out-of-Band
Experience has shown that the LLC Information Element is not
transmitted end to end. The deployment of compatible switches is
limited, and the subscription policies of the providers are
diverse. Therefore, transmission of the LLC-IE SHOULD NOT be
upon for framing or encoding determination
No LLC-IE values which pertain to PPP have been assigned. Any
values which are received are not valid for PPP links, and can
ignored for PPP service
As an alternative administrative measure, multiple directory
can point to the same physical access facility, by binding
services to each directory number. The called party identifier
proven to be reliably provided by the local switch
When a called party identifier is used, or when a future LLC-IE
is assigned to PPP and the PPP value is received, if the LCP has
had the administrative Open event, the call MUST be rejected
Receivers MUST NOT accept an incoming call, only to close the
or ignore packets from the circuit
Simpson [Page 4]
RFC 1618 PPP over ISDN May 1994
5. Configuration
The LCP recommended sync configuration options apply to ISDN links
The standard LCP sync configuration defaults apply to ISDN links
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
Instead of a constant value for the Restart timer, the
backoff method is recommended. The Restart Timer SHOULD be 250
milliseconds for the initial value, and 3 seconds for the
value
Implementations that include persistent dialing features, such
"demand dialing" or "redialing", SHOULD use mechanisms to limit
persistence. Examples of such mechanisms include
backoff, and discarding packet queues after failure to complete
establishment. In some implementations, discarding the
queue can temporarily remove the stimulus to retry the connection
Security
Security issues are not discussed in this memo
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
1548, Daydreamer, December 1993.
[2] Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549,
Daydreamer, December 1993.
[3] Stallings, W, "ISDN and Broadband ISDN - 2nd ed", Macmillan
1992.
[4] CCITT Recommendations I.465 and V.120, "Data Terminal
Communications over the Telephone Network with Provision
Statistical Multiplexing", CCITT Blue Book, Volume VIII
Fascicle VIII.1, 1988.
Simpson [Page 5]
RFC 1618 PPP over ISDN May 1994
This design was inspired by previous drafts of C. Frost, B. Gorsline
D. Leifer, K. Muramaki, S. Sheldon, K. Sklower, and T. Sugawara
Thanks to Oliver Korfmacher (NetCS) for European considerations,
Leifer (University of Michigan) for technical details and
party signalling, and Vernon Schryver (Silicon Graphics)
handling of link misconfiguration and timeouts
Special thanks to Morning Star Technologies for providing
resources and network access support for writing this specification
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 6]
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
