|
|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: T U
Length: 6258 (0x1872)
Types: TextFile
Notes: Uncompressed file
└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
└─⟦362729382⟧ »EurOpenD3/network/modems/telebit/ppp.doc.Z«
└─⟦this⟧
========================================================================
Telebit Corporation Revision 1.02 01 APRIL 1990
========================================================================
POINT-TO-POINT PROTOCOL
[RFC 1134]
By Russ Hobby, rdhobby@ucdavis.edu
INTRODUCTION
Point-to-point circuits in the form of asynchronous and synchronous
lines have long been the mainstay of data communications. Even with
the growing popularity of local area networks, wide area
connections are still made using various point-to-point circuits.
Over time the data link levels used have settled to a few standards.
However, the method use of the data link by upper level protocols,
such as IP, has been largely implementation dependent. This
resulted in requiring a single vendor's equipment for both ends of a
point-to-point circuit.
The Point-to-Point Protocol (PPP) seeks to remedy this problem by
proposing a standard method of encapsulating IP datagrams, as well
as other network layer protocol information, over point-to-point
links. PPP also specifies the means for line and protocol operation
and maintenance by providing the means for testing and configuring
the line and each of the upper level protocols. PPP is designed to be
easily extensible for adding new protocols and features.
PHYSICAL LAYER
PPP is capable of operating across virtually any DTE/DCE interface.
The most common examples of interfaces are RS-232-C, EIA RS-423
and CCITT V.35. The only absolute requirement for PPP is that a
duplex circuit be provided. While control signals are not required
for the use of PPP, it should be recognized that they do add
functionality and it is recommended that they be fully utilized when
they are available from the interface.
DATA LINK LAYER
PPP specifies for synchronous and asynchronous circuits ISO that
3309-1979 as modified by ISO 3309:1984/PDAD1 be used. The
framing specified by this document is more commonly known as
HDLC and the 1984 addendum defines HDLC for asynchronous
circuits. PPP describes the values to be used in the standard HDLC
fields and adds a protocol field to indicate for which protocol the
data is destined. There are three major types of protocols, link
control, upper level protocol control, and upper level protocol data.
BRINGING UP A LINE
Before al link is considered to be ready for use by upper level
protocols, a specific sequence of events must happen. These are:
Phase 1: Link Configuration Exchange
In this phase, Link Control Packets are exchanged and link
configuration options are negotiated.
Phase 2: Authentication
In this phase, each end of the link authenticates itself with the
remote end using authentication methods agreed upon in the Link
Configuration Exchange phase. If no authentication is required, this
phase is skipped. PPP currently defines a simple user/password
authentication protocol. Development of other protocols is
encouraged.
Phase 3: Link Quality Determination
If desired, the link may be tested at this point to determine if the
quality of the link is sufficient for operation. PPP does not specify
the policy for determining link quality but does provide low level
tools, such as echo request and reply, for testing the line. If no
testing is required, this phase may be skipped.
Phase 4: Link Ready
Upper level protocols may be seperately configured, and may be
brought up and taken down at any time. If the Link Control Protocol
takes the link down, it informs the upper level protocols so that
they may take the appropriate action.
LINK CONTROL PROTOCOL
The Link Control Protocol (LCP) provides a method of establishing,
configuring, maintaining, and terminating the point-to-point
connection. LCP handles configuration of the link itself, it does not
handle configuration of individual network layer protocols. In
particular, all configuration parameters which are independent of
particular network layer protocols are configured by LCP.
LCP has packet types to provide link option negotiation, link
up/down control, and link testing. Options that can be negotiated
cover areas such as Maximum Receive Unit, asynchronous control-
character mapping, authentication methods, keep-alive paramters.
All configuration options are assumed to be at default values until
configuration exchange is completed.
LCP provides the ability to do keep-alives and determine packet loss
on the link, while the link is operating. Policy on when to take the
link down, or re-establish it, is implementation dependent.
Before any other protocol packets may be exchanged, LCP must first
open the connection through an exchange of configuration packets.
This exchange is completed once a configuration acknowledgment
packet has been both sent an received. Any non-LCP packets
received before this exchange is complete, are silently discarded.
IP CONTROL PROTOCOL
The IP Control Protocol (IPCP) is responsible for configuring,
enabling, and disabling the IP protocol modules on both ends of the
point-to-point link. The IPCP sequence is the same as the LCP
sequence, allowing for the possible recycling of code. Options,
currently defined for negotiation by IPCP, include IP addresses and
the type of IP-header compression to be used.
DOD INTERNET PROTOCOL (IP)
Exactly on Internet Protocol packet is encapsulated in the
information field of PPP data link layer frames, where the protocol
field indicates DOD Internet Protocol.
FUTURE WORK
There are many areas fo future work on PPP. Currently, only the use
of the IP protocol has been defined in PPP. To make use of PPP for
other protocols the control protocol and rules for data encapsulation
need to be defined. The simple authentication method, currently
defined, is weak. A stronger authentication method needs to be
defined. Also, while there is a means to negotiate encryption
methods, no encryption methods have been defined.
Michael Ballard/Cerafin E. Castillo
Telebit Corporation
1315 Chesapeake Terrace
Sunnyvale, CA 94089
1-800-TELEBIT
UUCP: {ames, uunet, sun, pyramid, decwrl}!telebit!modems
INTERNET: modems@telebit.com