DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: T U

⟦ace274101⟧ TextFile

    Length: 6258 (0x1872)
    Types: TextFile
    Notes: Uncompressed file

Derivation

└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
    └─⟦362729382⟧ »EurOpenD3/network/modems/telebit/ppp.doc.Z« 
        └─⟦this⟧ 

TextFile

========================================================================
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