The NetWare^® Link/PPP^TM software subsystem is based on the Point-to-Point Protocol (PPP), a protocol standardized by the Internet Engineering Task Force (IETF). When configured with a synchronous or asynchronous serial interface on a NetWare 3.12 or NetWare 4.x standalone router or file server, NetWare Link/PPP enables point-to-point transmissions of routed data across transmission facilities between interconnected LANs.

Data transfer rates of up to 2.048 Mbps are possible, depending on the serial interface used. The only requirements are a full-duplex WAN link and modem status signals. You can use any physical interface, including RS-232, RS-422, RS-423, V.35, or X.21. Additionally, you can use copper, fiber-optic, microwave, Integrated Services Digital Network (ISDN), or satellite leased lines.

NetWare Link/PPP contains mechanisms for link configuration negotiation, call authentication, link error detection and correction, protocol multiplexing, and link header compression and data compression.

PPP Background

Prior to the emergence of PPP, many vendors of routing and bridging products implemented proprietary serial transmission protocols suitable for WAN connections. Often, these implementations were in the form of variants of the Serial Line Internet Protocol (SLIP) or High-level Data-Link Control (HDLC) protocol.

These proprietary implementations became inadequate as the need for WAN interconnectivity of LANs became greater. These different implementations by different manufacturers meant that hardware routers or bridges could not be selected purely on the basis of need. Instead, whatever type of routing or bridging hardware was placed at one end of a serial link dictated what had to be placed at the other end.

The need for multivendor interoperability between routing hardware was the driving force behind the need to support multiple protocols across a single high-speed link. Proprietary serial transmission protocols tend to support a single protocol, such as IP in the case of SLIP implementations.

In 1988, a work group of the IETF began to define PPP as a replacement for SLIP. PPP was fully defined and accepted as a standard in 1991 and was described in RFCs 1171 and 1172. These initial RFCs have since been replaced with the following RFCs:

RFC	Title	Supported
1220	Point-to-Point Protocol Extensions for Bridging	No
1332	The PPP Internet Protocol Control Protocol (IPCP)	Yes
1333	PPP Link Quality Monitoring	No
1334	PPP Authentication Protocols	Yes
1376	The PPP DECnet Phase IV Control Protocol (DNCP)	No
1377	The PPP OSI Network Layer Control Protocol (OSINLCP)	No
1378	PPP AppleTalk Control Protocol (ATCP)	No
1471	The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol	Yes
1472	The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol	No
1473	The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol	No
1474	The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol	No
1547	Requirements for an Internet Standard Point-to-Point Protocol	Yes
1552	The PPP Internetworking Packet Exchange Control Protocol (IPXCP)	Yes, for remote clients
1553	Compressing IPX Headers Over WAN Media (CIPX)	Yes
1570	PPP LCP Extensions	No
1598	PPP in X.25	No
1618	PPP over ISDN	Yes
1619	PPP over SONET/SDH	No
1634	Novell IPX Over Various WAN Media (IPXWAN II)	Yes
1638	PPP Bridging Control Protocol (BCP)	No
1661	The Point-to-Point Protocol (PPP)	Yes
1662	PPP in HDLC-like Framing	No
1663	PPP Reliable Transmission	Yes
1962	The PPP Compression Control Protocol (CCP)	Yes
1674	PPP Stac LZS Compression Protocol	Yes
1978	PPP Predictor Compression Protocol	Yes
1990	The PPP Multilink Protocol (MP)	Yes
1994	PPP Challenge Handshake Authentication Protocol (CHAP)	Yes

Further enhancements and protocol clarifications are in progress for PPP in the form of the following RFC drafts:

• The Arbitrary Handshake Authentication (AHA) Protocol
• The Generic Authentication Protocol (GAP)
• PPP BSD Compression Protocol
• The PPP Compression Control Protocol (CCP)
• The PPP DES Encryption Protocol (DESE)
• The PPP Encryption Control Protocol (ECP)
• PPP Extensible Authentication Protocol (EAP)
• PPP Gandalf FZA Compression Protocol
• PPP Hewlett-Packard* Packet-by-Packet Compression (HP PPC) Protocol
• PPP in Frame Relay
• PPP Kerberos Authentication Protocol (KAP)
• PPP LCP Option for Data Encapsulation Selection
• PPP Magnalink Variable Resource Compression
• The PPP NetBIOS Frames Control Protocol (NBFCP)
• PPP Predictor Compression Protocol
• PPP Stacker LZs Compression Protocol

NetWare Link/PPP

NetWare Link/PPP corresponds to the Data-Link layer of the Open Systems Interconnection (OSI) model, with additional services provided on behalf of the Network layer. It defines the automatic establishment and configuration of serial links, or connections, within router- and bridge-based network topologies.

NetWare Link/PPP comprises three main components:

• A method for encapsulating datagrams over serial links
• A Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection
• A group of Network Control Protocols (NCPs) for establishing and configuring logical connections on behalf of various Network-layer protocols

NetWare Link/PPP defines encapsulation methods supporting bit-synchronous and character-asynchronous serial communication links. NetWare Link/PPP supports the use of both types of links and operates across many standard models of modems and data terminal equipment/data circuit-terminating equipment (DTE/DCE) interfaces (for example, EIA RS-232, EIA RS-422, EIA RS-423, X.21, and International Telecommunication Union [ITU] V.35). The links must be full-duplex and can be either dedicated or switched.

NetWare Link/PPP uses a variant of HDLC that provides basic data-link delivery services over point-to-point serial connections. Typically, PPP uses HDLC unnumbered information frames providing low overhead and high throughput exchange of control and data packets. In this case, error detection is based on the CRC-16 frame check sequence (FCS). Data delivery is considered best effort, with error recovery left to higher-level Network- and Transport-layer protocols.

When NetWare Link/PPP data compression is enabled, HDLC sequenced information frames provide reliable delivery of control and data packets. In this case, both error detection and retransmission error recovery is provided by the data link.

A mechanism allows control data to be transmitted transparently, and removes spurious control data that can be injected into the link by intervening hardware and software. Recovery is left to higher-layer protocols.

PPP is a point-to-point service, but is capable of supporting multiple Network-layer protocols simultaneously over the same link. Because PPP provides for multiplexing of multiple Network-layer protocols (such as the Internetwork Packet Exchange^TM [IPX^TM] protocol, IP, AppleTalk, and source route bridging) simultaneously over one link, NetWare Link/PPP provides a means of easy connection at the Data-Link layer for a variety of hosts, bridges, and routers.

Communications Medium

NetWare Link/PPP can use any synchronous full-duplex point-to-point leased lines at speeds up to 2.048 Mbps. It also supports the use of switched-circuit lines (such as switched/56 service) and asynchronous communications over Public Switched Telephone Network (PSTN) lines, as well as synchronous communication over ISDN lines. Switched services and PSTNs provide additional flexibility by allowing on-demand and permanent connections. On-demand connections are established by the router when data must be passed to a remote system, and are terminated when idle. On-demand connection management minimizes the costs associated with serial line connectivity.

Character asynchronous and bit synchronous HDLC framing is supported by PSTNs. Device management allowing connection (circuit) establishment and termination over the PSTN is also supported using various modem command sets. Because PSTN access is unrestricted, authentication of the calling party during inbound connection attempts is provided. Because bandwidth available over most PSTNs is less than that of dedicated circuits, both PPP header compression and payload data compression is provided; however, only one compression method can be used per circuit, not both.

Within the United States, Australia, and Japan, T1 is a digital two-way telecommunications medium that operates at a clock rate of 1.544 Mbps. In Europe, E1 is the telecommunications medium and operates at a clock rate of 2.048 Mbps. The T1 data rate of 1.544 Mbps is "digital signal level one," otherwise known as DS-1. The term T1 actually refers to the hardware (usually a system of copper wire cables and amplifiers or generators) used to transport data at the DS-1 rate; however, in common use, T1 has come to mean a transmission line or connection running at 1.544 Mbps.

Traditionally, telephone companies have used these high-speed backbone trunk lines to carry long distance and local voice traffic between their central offices. In addition to voice, T1/E1 is used to transmit facsimile, graphics, and other digital data. In recent years, T1/E1 lines have been used increasingly to implement WAN connectivity.

To access T1/E1 links, the router PC or file server that is running NetWare Link/PPP must be connected to a digital service unit/channel service unit (DSU/CSU) that encodes data for transmission over the WAN link. A DSU converts a serial bit stream into a DS-1 signal; a CSU provides an interface between T1 signaling and the local loop, provided by the local telephone company (telco). The WAN board that you install in the router or file server connects to the DSU/CSU multiplexer or modem.

NetWare Link/PPP Features

PPP is recognized throughout the routing industry as a standardized serial line data-link protocol providing an efficient multivendor interoperable means of establishing WAN connections in internetwork topologies. NetWare Link/PPP includes the following advantages:

• Routing of multiple protocols simultaneously across a single WAN link. Sites can use the Novell^® Internet Access Server 4.1 routing software (at both ends of each link) and gain the ability to simultaneously route IPX, IP, and AppleTalk protocols, and to route protocols routable through source route bridge, as well as nonroutable protocols.
• Removing single-vendor routing system requirements. Internetwork communities wanting to extend connectivity to new sites can configure a NetWare file server or router/bridge PC with the NetWare Link/PPP software and route IPX, TCP/IP, and AppleTalk packets across a WAN link to a non-NetWare router that also employs PPP as its data-link protocol. (The IPX over NetWare Link/PPP uses the IPXWAN^TM II protocol specification, which has been published as RFC 1634 to allow other vendors to conform to the Novell NetWare Link/PPP-IPX implementation.)
• Providing a basis for supporting WAN routing of additional network protocols implemented in the future because of the extensible nature of PPP. Such enhancements, as well as enhancements to the PPP data link itself, are achieved through software upgrades; no hardware upgrade is required.
• Providing an easier and more consistent method of configuring NetWare Link/PPP, along with other Novell Internet Access Server 4.1 modules, using NIASCFG. The boards used by NetWare Link/PPP, the protocols it multiplexes across WAN links, and the parameters of the various Network-layer calls made across the WAN links are all configured through NIASCFG. You do not need to enter commands at the server console prompt manually.
• Support of source route bridging of token ring packets over PPP.

All compliant PPP implementations are not alike. Because of the wide range of point-to-point connectivity requirements, the PPP specification, by design, specifies more capabilities and services than any single implementation might provide. However, differences in PPP implementation capabilities are reconciled at link establishment time when the two PPP peer nodes negotiate a common set of supported services.

Novell has chosen the following options:

• Any given implementation of PPP can include either asynchronous or synchronous framing, or both. NetWare Link/PPP supports both framing types. Bit synchronous framing is required for high-speed leased lines and switched circuits, whereas asynchronous framing supports the use of low-speed modems with PSTNs.

• Any given implementation can support one or more Network-layer protocols. There is no specific prescribed set of protocols that must be supported. Currently, Novell supports AppleTalk, TCP/IP, IPX, and source route bridging.

• PPP does not require modem control signals (such as RTS, CTS, DCD, and DTR), even though such signals do allow greater functionality. However, NetWare Link/PPP uses these modem control signals to provide switched-circuit device management.

• Scripted logins are provided for users who use asynchronous PPP connections to log in to online services. With minimum modification, these standard scripts enable many common logins. It is also possible to develop customized login scripts tailored to meet the needs of a specific site.

• Backup call associations ensure that new connections are made successfully and that permanent connections are maintained, even if a primary WAN call destination goes down. When a backup call association is configured, two previously configured WAN call destinations are specified to have an association with one another. One destination is defined as the primary call destination; the other, as its backup. In the event that the primary destination becomes unavailable, NetWare Link/PPP switches automatically to the backup destination.

• The NetWare Link/PPP Link Control Protocol (LCP) implementation includes the following options:
  • Maximum Receive Unit (MRU)---Allows the sender to inform the peer that it can receive larger frames than the default, or to request that the peer send smaller frames. Even if smaller frames are sent, the ability to receive 1,500-octet LCP frames is required in case link synchronization is lost.

    NetWare Link/PPP supports MRU values with the range of 128 to 4,500 bytes.

  • Magic Number---Provides a way to detect failure of a remote peer node, as well as loopback links and other Data-Link layer anomalies.

  • LCP Echo Request---Provides a positive method of verifying the presence of a remote PPP peer or detecting a loopback line. Echo requests, generated on a periodic basis, serve to elicit keep-alive echo responses from the remote peer.

  • PAP and CHAP Call Authentication---Limits dial-in access to authorized remote systems only. PAP (Password Authentication Protocol) and CHAP (Challenge Handshake Authentication Protocol) are authentication protocols that protect against unauthorized access. This option is an integral part of the NetWare Link/PPP on-demand routing implementation, providing identification of each remote system.

  • Asynchronous Control Character Map (ACCM)---Allows user-configured hardware control character mapping on behalf of a variety of manufacturers' modems.

  • Address and Control Field Compression---Provides a 2-byte per packet performance optimization by eliminating the fixed HDLC address and control fields from each PPP header.

  • Protocol Field Compression---Provides a 1-byte per packet performance optimization by eliminating one of the two PPP protocol ID bytes.

• Data Compression---Provides a major performance optimization by encoding Network-layer payload data into more compact character sequences based on recurring patterns.
• Compression Control Protocol (CCP)---Supports CCP for the negotiation and selection of a common data compression protocol between systems.

  In addition, Novell Internet Access Server 4.1 maintains backward compatibility with NetWare MultiProtocol Router^TM 3.1 software, NetWare MultiProtocol Router 3.0, and NetWare MultiProtocol Router 2.11 PPP data compression.

• Bandwidth Allocation Control Protocol and Multilink Protocol---Greatly increase your total available bandwidth. Bandwidth Allocation Control Protocol and Multilink Protocol enable you to use multiple physical ports on one or more WAN boards to represent a single logical link to one location. When the bandwidth threshold of one port is reached, the bandwidth of the next port becomes available. More ports are added to the connection if bandwidth requirements continue to increase beyond the threshold of the ports currently in use.