Solstice PPP 3.0.1 Administration Guide

Running IP Applications over Solstice PPP

Once configured and started on a host machine, Solstice PPP encapsulates standard IP packets and routes them across serial point-to-point links. This process occurs in three phases, as shown in Figure 1-1.

  1. A physical connection is established between two endpoints.

  2. A PPP link is established over the physical connection.

  3. IP is established over the PPP link.

Figure 1-1 Establishing IP over PPP Links

Graphic

Establishing the Physical Connection

Solstice PPP transmits data over full-duplex, bit-serial connections. It supports any of the common serial communications protocols, including EIA-232-E (formerly, RS-232-C), EIA-422, EIA-423, EIA-530, and CCITT V.24 and V.35. The physical connection for Solstice PPP may be either synchronous or asynchronous.

Synchronous Connections

Synchronous connections use independent clocking signals to synchronize the data transmission. They provide a permanent connection between two endpoints, and are typically established over dedicated leased-lines.

You pay for the synchronous connection for the duration of the lease and the cost is independent of the quantity of data transmitted. For these reasons, synchronous connections are best suited to continuous data traffic and are used typically for LAN-to-LAN interconnectivity and bulk transfers of information as shown in Figure 1-2.

Figure 1-2 Synchronous Connection between LANs.

Graphic

The synchronous connection is established through a synchronous serial interface installed in the host machine. The synchronous connection is established when Solstice PPP is started; therefore, there is no independent connection phase when a PPP link is established over a synchronous connection. Refer to the Solstice PPP 3.0.1 Installation Guide and Release Notes for a list of the synchronous serial interfaces with which Solstice PPP has been tested.

Asynchronous Connections

Asynchronous connections either use information carried in the data itself (software flow control), or handshake signals generated by the serial interface (hardware flow control), to control the data transmission. They provide temporary connections between two endpoints, and are typically established over private and public telephone networks or null modem links.

The cost of the connection is related to the duration of the call and the distance between endpoints. For this reason, asynchronous connections are best suited to transient network traffic, and are used typically for mobile communication, teleworking, and temporary access to Internet servers as shown in Figure 1-3.

Figure 1-3 Asynchronous Connection between Client and Server

Graphic

The asynchronous connection is established through an asynchronous serial interface installed in the host machine, and a modem which represents the interface between the host machine and the analog telephone network. During the connection phase, the modems at each endpoint communicate to set up the call.

Refer to the Solstice PPP 3.0.1 Installation Guide and Release Notes for a list of the asynchronous serial interfaces and modems with which Solstice PPP has been tested. Configuration information for these modems is contained in the modem database file /etc/opt/SUNWconn/ppp/modems.

You can modify the modems database file to add configuration information for additional modems, provided they support standard Hayes AT commands. Refer to the manufacturers' documentation for details of the commands used to configure your modem.

Establishing PPP over the Physical Connection

Once the physical connection is established, the two endpoints negotiate to define a common configuration for the PPP layer. For synchronous connections, the PPP layer is established each time you start Solstice PPP on your machine. For asynchronous connections, the PPP layer is established each time you initiate a call to a remote host.

During the PPP negotiation phase, the endpoints exchange Link Control Protocol (LCP) frames that contain information regarding the desired configuration and the supported protocol options. Negotiated parameters include the use of compression algorithms to improve performance over slow connections, and the use of authentication protocols to protect against unauthorized access. The policy is to converge the negotiation, if at all possible; however, if the two endpoints fail to agree on a common configuration, the link is closed automatically.

Establishing IP over PPP

Once the PPP link is established, the two endpoints negotiate to define a common configuration for the IP layer. During the IP negotiation phase, the two endpoints exchange Network Control Protocol (NCP) frames that contain information about the desired configuration. The negotiated parameters can include the IP address. This feature forms the basis of dynamic IP address allocation.

To route IP datagrams across synchronous or asynchronous PPP links, you must define the logical IP interfaces that represent the boundary between Solstice PPP and the IP layer of the Solaris operating system. These interfaces are initialized with the negotiated configuration information.

Solstice PPP supports two types of IP interface:

Point-to-Point IP Interfaces (ipdptpn)

The point-to-point IP interface for Solstice PPP is /dev/ipdptp. This interface is used to create a direct connection for IP between exactly two hosts, as shown in Figure 1-4.

Figure 1-4 IP Point-to-Point Configuration

Graphic

A point-to-point IP interface is defined by specifying a source address (or point of attachment) and a unique destination address. There is a single possible destination for the next hop, once the IP datagram has been passed to a given point-to-point interface. Therefore, the same source address can be used for multiple point-to-point connections on the same host. Multiple point-to-point connections can be used to connect to several remote hosts simultaneously.

IP point-to-point connections are supported by both synchronous and asynchronous Solstice PPP links.

Point-to-Multipoint IP Interfaces (ipdn)

The point-to-multipoint IP interface for Solstice PPP is /dev/ipd. A single interface is used to create IP connections between one host and several others, as shown in Figure 1-5. The effect of using point-to-multipoint interfaces is to create a virtual subnetwork, which is usually assigned its own subnetwork number.

Figure 1-5 IP Point-to-Multipoint Configuration

Graphic

A point-to-multipoint interface is defined by specifying a source address only. There are multiple possible destinations for the next hop, once an IP datagram has been passed to a point-to-multipoint interface. Therefore, each point-to-multipoint interface must be assigned a unique source address.

IP point-to-multipoint connections are only supported by asynchronous Solstice PPP links.

Load-Sharing for Synchronous PPP Links

Load-sharing is a Sun-specific enhancement to the standard implementation of PPP. It increases the available bandwidth by sharing the network traffic from one IP interface equally between two or more synchronous links, as shown in Figure 1-6.

Figure 1-6 Load-Sharing over Synchronous Links

Graphic


Note -

For optimum performance, all of the synchronous devices used for load-sharing must be operating at the same line speed. Both ends of the link must be running Solstice PPP in order to implement load-sharing.


See "Load-Sharing over Synchronous Links" for a detailed example that shows how to enable load-sharing using Solstice PPP.

Dynamic IP Address Allocation

Solstice PPP provides a mechanism for dynamic IP address allocation over asynchronous PPP links. This mechanism is used by clients to request IP addresses from a server at the time the PPP link is established.

Dynamic IP address allocation is enabled on the client side. When the client initiates a PPP link to the server, it requests an IP address for the connection. The server responds with its own IP address and the IP address it has allocated for the client's local interface, and the client uses these addresses to establish a point-to-point IP connection over the existing PPP link.

To support dynamic IP address allocation on the server, you must define a pool of point-to-point IP interfaces. The server allocates an interface from this pool when it receives a request for IP addresses from a client, and the interface is returned to the pool when the PPP link is terminated.

The number of IP interfaces in the pool should be equal to the number of modems connected to the server; however, the number of clients supported by the server may be much larger. IP addresses are allocated on demand for as long as there are modems available to accept the connections.

See Chapter 4, Editing the Configuration Filesfor instructions on how to set up servers and clients to use dynamic IP address allocation.

Static and Dynamic IP Interfaces

Point-to-point IP interfaces may be static or dynamic:

See "Generic Internet Server Configuration" for a detailed example of an Internet server configuration that uses dynamic IP address allocation with dynamic IP interfaces.