|
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