doc: Add RFC documents

1 files changed, 444 insertions, 0 deletions

diff --git a/doc/rfc/rfc1618.txt b/doc/rfc/rfc1618.txt
new file mode 100644
index 0000000..ddac4d7
--- /dev/null
+++ b/doc/rfc/rfc1618.txt
@@ -0,0 +1,444 @@
+
+
+
+
+
+
+Network Working Group                                         W. Simpson
+Request for Comments: 1618                                    Daydreamer
+Category: Standards Track                                       May 1994
+
+
+                             PPP over ISDN
+
+
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+
+Abstract
+
+   The Point-to-Point Protocol (PPP) [1] provides a standard method for
+   transporting multi-protocol datagrams over point-to-point links.
+   This document describes the use of PPP over Integrated Services
+   Digital Network (ISDN) switched circuits.
+
+   This document is the product of the Point-to-Point Protocol Working
+   Group of the Internet Engineering Task Force (IETF).  Comments should
+   be submitted to the ietf-ppp@merit.edu mailing list.
+
+
+Applicability
+
+   This specification is intended for those implementations which desire
+   to use the PPP encapsulation over ISDN point-to-point links.  PPP is
+   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 few
+   common implementations, chosen from the current wide variety of
+   alternatives, in an effort to promote interoperability.
+
+
+
+
+
+
+
+
+
+
+
+Simpson                                                         [Page i]
+RFC 1618                     PPP over ISDN                      May 1994
+
+
+                           Table of Contents
+
+
+     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.  Introduction
+
+   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 is
+   easily deployed in these environments as well.
+
+   This specification is primarily concerned with the use of the PPP
+   encapsulation over ISDN links.  Since the ISDN B-channel is by
+   definition a point-to-point circuit, PPP is well suited to use over
+   these links.
+
+   The ISDN Primary Rate Interface (PRI) may support many concurrent B-
+   channel links.  The PPP LCP and NCP mechanisms are particularly
+   useful in this situation in reducing or eliminating hand
+   configuration, and facilitating ease of communication between diverse
+   implementations.
+
+   The ISDN D-channel can also be used for sending PPP packets when
+   suitably framed, but is limited in bandwidth and often restricts
+   communication links to a local switch.
+
+   The terminology of ISDN can be confusing.  Here is a simple graphical
+   representation of the points used in subsequent descriptions:
+
+                   +-------+     +-------+     +-------+
+               R   |       |  S  |       |  T  |       |   U
+               +---+  TA   +--+--+  NT2  +--+--+  NT1  +---+
+                   |       |     |       |     |       |
+                   +-------+     +-------+     +-------+
+
+   These elements are frequently combined into a single device.
+
+
+
+2.  Physical Layer Requirements
+
+   PPP treats ISDN channels as bit or octet oriented synchronous links.
+   These links MUST be full-duplex, but MAY be either dedicated or
+   circuit-switched.
+
+   Interface Format
+
+      PPP presents an octet interface to the physical layer.  There is
+      no provision for sub-octets to be supplied or accepted.  The octet
+      stream is applied primarily at the R or T reference points.
+
+
+
+
+Simpson                                                         [Page 1]
+RFC 1618                     PPP over ISDN                      May 1994
+
+
+   Transmission Rate
+
+      PPP does not impose any restrictions regarding transmission rate,
+      other than that of the particular ISDN channel interface.
+
+   Control Signals
+
+      PPP does not require the use of control signals.  When available,
+      using such signals can allow greater functionality and
+      performance.  Implications are discussed in [2].
+
+      Control signals MAY be required by some of the framing techniques
+      described, and is outside the scope of this specification.
+
+   Encoding
+
+      The definition of various encodings and scrambling is the
+      responsibility of the DTE/DCE equipment in use, and is outside the
+      scope of this specification.
+
+      While PPP will operate without regard to the underlying
+      representation of the bit stream, lack of standards for
+      transmission will hinder interoperability as surely as lack of
+      data link standards.  The D-channel LAPD interface requires NRZ
+      encoding at the T reference point.  Therefore, as a default, it is
+      recommended that NRZ be used over the B-channel interface at the T
+      reference point.  This will allow frames to be easily exchanged
+      between the B and D channels.
+
+      When configuration of the encoding is allowed, NRZI is recommended
+      as an alternative in order to ensure a minimum ones density where
+      required over the clear B-channel, with caveats regarding FCS [2].
+
+      Historically, some implementations have used Inverted NRZ (merely
+      switching the sense of mark and space), in order to ensure a
+      minimum ones density with bit-synchronous HDLC.  The use of
+      Inverted NRZ is deprecated.
+
+      Automatic Detection
+
+         Implementations which desire to interoperate with multiple
+         encodings MAY choose to detect those encodings automatically.
+         Automatic encoding detection is particularly important for
+         Primary Rate Interfaces, to avoid extensive pre-configuration.
+         Only simple encodings are currently distinguished.
+
+         The only reliable method of detection available is to switch
+         modes between the supported encodings.  Transmission of the LCP
+
+
+
+Simpson                                                         [Page 2]
+RFC 1618                     PPP over ISDN                      May 1994
+
+
+         Configure-Request SHOULD be tried twice for each mode before
+         switching in rotation.  This ensures that sufficient time is
+         available for a response to arrive from the peer.
+
+         Max-Configure MUST be set such that the cumulative attempts
+         result in no more than 59 seconds of time before disconnect.
+         It is preferable that the usual limit of 30 seconds be
+         observed.
+
+      Prior Configuration
+
+         By prior configuration, PPP MAY also be used with other
+         encodings.  Because of difficulty distinguishing them, it is
+         not recommended that these encodings be automatically detected.
+
+         Terminal adapters conforming to V.120 [4] can be used as a
+         simple interface to workstations.  Asynchronous HDLC framing
+         [2] is accepted at the R reference point.  The terminal adapter
+         provides async-sync conversion.  Multiple B-channels can be
+         used in parallel.  Unfortunately, V.120 has a framing mode of
+         its own for rate adaptation, which is difficult to distinguish
+         from Frame Relay, and which can confuse in-band frame
+         detection.  V.120 is not interoperable with bit-synchronous
+         links, since V.120 does not provide octet-stuffing to bit-
+         stuffing conversion.  Therefore, V.120 is deprecated in favor
+         of more modern standards, such as "PPP in Frame Relay".
+
+         The "Bandwidth On Demand Interoperability Group" has defined a
+         proposal called BONDING.  Multiple B-channels can be used in
+         parallel.  BONDING has an initialization period of its own,
+         which might conflict with the simple detection technique
+         described above, and requires extensive individual
+         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.  Framing
+
+   For B-channels, in the absence of prior configuration, the
+   implementation MUST first use bit-synchronous HDLC [2], as opposed to
+   other framings, for initial link establishment.  This assumes that
+   circuit-switched communications are generally [host | router] to
+   [host | router].
+
+   By prior configuration, octet-synchronous HDLC [2] is recommended
+   where the network termination equipment interfaces directly to the T
+
+
+
+Simpson                                                         [Page 3]
+RFC 1618                     PPP over ISDN                    May 1994
+
+
+   reference point, and octet boundaries are available at the time of
+   framing.  Such equipment is likely to be highly integrated, and the
+   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 prior
+   configuration, "PPP in X.25" or "PPP in Frame Relay" framing MAY be
+   used.
+
+   Despite the fact that HDLC, LAPB, LAPD, and LAPF are nominally
+   distinguishable, multiple methods of framing SHOULD NOT be used
+   concurrently on the same ISDN channel.  There is no requirement that
+   PPP recognize alternative framing techniques, or switch between
+   framing techniques without specific configuration.
+
+
+
+4.  Out-of-Band signaling
+
+   Experience has shown that the LLC Information Element is not reliably
+   transmitted end to end.  The deployment of compatible switches is too
+   limited, and the subscription policies of the providers are too
+   diverse.  Therefore, transmission of the LLC-IE SHOULD NOT be relied
+   upon for framing or encoding determination.
+
+   No LLC-IE values which pertain to PPP have been assigned.  Any other
+   values which are received are not valid for PPP links, and can be
+   ignored for PPP service.
+
+   As an alternative administrative measure, multiple directory numbers
+   can point to the same physical access facility, by binding particular
+   services to each directory number.  The called party identifier has
+   proven to be reliably provided by the local switch.
+
+   When a called party identifier is used, or when a future LLC-IE value
+   is assigned to PPP and the PPP value is received, if the LCP has not
+   had the administrative Open event, the call MUST be rejected.
+   Receivers MUST NOT accept an incoming call, only to close the circuit
+   or ignore packets from the circuit.
+
+
+
+
+
+
+
+
+
+
+
+Simpson                                                         [Page 4]
+RFC 1618                     PPP over ISDN                      May 1994
+
+
+5.  Configuration Details
+
+   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 of
+   either 1500, or 2048 or greater.  To avoid fragmentation, the
+   Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
+   exceed 1500, unless a peer MRU of 2048 or greater is specifically
+   negotiated.
+
+   Instead of a constant value for the Restart timer, the exponential
+   backoff method is recommended.  The Restart Timer SHOULD be 250
+   milliseconds for the initial value, and 3 seconds for the final
+   value.
+
+   Implementations that include persistent dialing features, such as
+   "demand dialing" or "redialing", SHOULD use mechanisms to limit their
+   persistence.  Examples of such mechanisms include exponential
+   backoff, and discarding packet queues after failure to complete link
+   establishment.  In some implementations, discarding the transmit
+   queue can temporarily remove the stimulus to retry the connection.
+
+
+
+Security Considerations
+
+   Security issues are not discussed in this memo.
+
+
+
+References
+
+   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
+         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 Equipment
+         Communications over the Telephone Network with Provision for
+         Statistical Multiplexing", CCITT Blue Book, Volume VIII,
+         Fascicle VIII.1, 1988.
+
+
+
+
+Simpson                                                         [Page 5]
+RFC 1618                     PPP over ISDN                      May 1994
+
+
+Acknowledgments
+
+   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, Dory
+   Leifer (University of Michigan) for technical details and called
+   party signalling, and Vernon Schryver (Silicon Graphics) regarding
+   handling of link misconfiguration and timeouts.
+
+   Special thanks to Morning Star Technologies for providing computing
+   resources and network access support for writing this specification.
+
+
+
+Chair's Address
+
+   The working group can be contacted via the current chair:
+
+      Fred Baker
+      Advanced Computer Communications
+      315 Bollay Drive
+      Santa Barbara, California  93117
+
+      EMail: fbaker@acc.com
+
+
+Author's Address
+
+   Questions about this memo can also be directed to:
+
+      William Allen Simpson
+      Daydreamer
+      Computer Systems Consulting Services
+      1384 Fontaine
+      Madison Heights, Michigan  48071
+
+      EMail: Bill.Simpson@um.cc.umich.edu
+             bsimpson@MorningStar.com
+
+
+
+
+
+
+
+
+
+
+
+
+Simpson                                                         [Page 6]
+
+