Bienvenido! - Willkommen! - Welcome!

Bitácora Técnica de Tux&Cía., Santa Cruz de la Sierra, BO
Bitácora Central: Tux&Cía.
Bitácora de Información Avanzada: Tux&Cía.-Información
May the source be with you!

Friday, June 10, 2011

PPP Link Control Protocol (LCP)

Key Concept: The PPP Link Control Protocol (LCP) is the most important protocol in the PPP suite. It is responsible for configuring, maintaining and terminating the overall PPP link. The two devices using PPP employ a set of LCP frames to conduct LCP operations.
------------
Previous 
Page
Pages in 
Current Topic/Section
1
23
Next Page
Of all the different PPP suite protocols, the single most important protocol is the PPP Link Control Protocol (LCP). LCP is the “boss” of PPP; it is responsible for its overall successful operation, and for “supervising” (in a way) the actions of other protocols.
PPP is about links, and LCP is about controlling those links. As I discussed in the PPP fundamentals section, the operation of a PPP link can be thought of as proceeding through various “life stages” just as a biological organism does. There are three main stages of “link life” and LCP plays a key role in each one:
  • Link Configuration: The process of setting up and negotiating the parameters of a link.
  • Link Maintenance: The process of managing an opened link.
  • Link Termination: The process of closing an existing link when it is no longer needed (or when the underlying physical layer connection closes).
Each of these functions corresponds to one of the “life phases” of a PPP link. Link configuration is performed during the initial Link Establishment phase of a link; link maintenance occurs while the link is open, and of course, link termination happens in the Link Termination phase. Figure 26 represents a summary of the LCP link, showing the different message exchanges performed by LCP during these different life phases of a PPP connection.

Figure 26: PPP Link Control Protocol (LCP) Message Exchanges
This diagram provides an overview of many of the message exchanges performed by LCP during different phases of a PPP connection. Link Configuration is here shown as a simple exchange of a Configure-Request and Configure-Ack. After subsequent exchanges using other PPP protocols to authenticate and configure one or more NCPs, the link enters the Link Open phase. In this example, an Echo-Request and Echo-Reply message are first used to test the link, followed by the sending and receiving of data by both devices. One Data message is shown being rejected due to an invalid Code field. Finally, the link is terminated using Terminate-Request and Terminate-Ack messages.

LCP Frames
Devices use LCP to control the PPP link by sending special LCP messages across the physical link between them. These messages are called both LCP packets and LCP frames; while the standard uses "packet", the term "frame" is preferred because layer two messages are normally called frames. There are eleven different LCP frame types defined in the main PPP document, which are divided into three groups that correspond to the three link “life stages” above. Four LCP frame types are used for link configuration, five for maintenance and two for termination. The frame formats themselves are described in the topic on LCP frames. Below I will discuss each of the three major functions of LCP and how the frames are used in each.
PPP is the protocol used for establishing internet links over dial-up modems, DSL connections, and many other types of point-to-point links. The pppd daemon works together with the kernel PPP driver to establish and maintain a PPP link with another system (called the peer) and to negotiate Internet Protocol (IP) addresses for each end of the link. Pppd can also authenticate the peer and/or supply authentication information to the peer. PPP can be used with other network protocols besides IP, but such use is becoming increasingly rare

We already encountered LCP, the Link Control Protocol, which is used to negotiate link characteristics and test the link.
The two most important options negotiated by LCP are the Maximum Receive Unit, and the Asynchronous Control Character Map. There are a number of other LCP configuration options, but they are far too specialized to discuss here.
The Asynchronous Control Character Map, colloquially called the async map, is used on asynchronous links such as telephone lines to identify control characters that must be escaped (replaced by a specific two-character sequence). For instance, you may want to avoid the XON and XOFF characters used for software handshake because some misconfigured modem might choke upon receipt of an XOFF. Other candidates include Ctrl-] (the telnet escape character). PPP allows you to escape any of the characters with ASCII codes 0 through 31 by specifying them in the async map.
The async map is a bitmap 32 bits wide, with the least significant bit corresponding to the ASCII NUL character, and the most significant bit corrsponding to ASCII 31. If a bit is set, it signals that the corresponding character must be escaped before sending it across the link. Initially, the async map is set to 0xffffffff, that is, all control characters will be esaped.
To tell your peer that it doesn't have to escape all control characters but only a few of them, you can specify a new async map to pppd using the asyncmap option. For instance, if only ^S and ^Q (ASCII 17 and 19, commonly used for XON and XOFF) must be escaped, use the following option:
asyncmap 0x000A0000
The Maximum Receive Unit, or MRU, signals to the peer the maximum size of HDLC frames we want to receive. Although this may remind you of the MTU value (Maximum Transfer Unit), these two have little in common. The MTU is a parameter of the kernel networking device and describes the maximum frame size the interface is able to handle. The MRU is more of an advice to the remote end not to generate any frames larger than the MRU; the interface must nevertheless be able to receive frames of up to 1500 bytes.
Choosing an MRU is therefore not so much a question of what the link is capable of transferring, but of what gives you the best throughput. If you intend to run interactive applications over the link, setting the MRU to values as low as 296 is a good idea, so that an occasional larger packet (say, from an FTP session) doesn't make your cursor ``jump.'' To tell pppd to request an MRU of 296, you would give it the option mru 296. Small MRUs, however, only make sense if you don't have VJ header compression disabled (it is enabled by default).
pppd also understands a couple of LCP options that configure the overall behavior of the negotiation process, such as the maximum number of configuration requests that may be exchanged before the link is terminated. Unless you know exactly what you are doing, you should leave these alone.
Finally, there are two options that apply to LCP echo messages. PPP defines two messages, Echo Request and Echo Response. pppd uses this feature to check if a link is still operating. You can enable this by using the lcp-echo-interval option together with a time in seconds. If no frames are received from the remote host within this interval, pppd generates an Echo Request and expects the peer to return an Echo Response. If the peer does not produce a response, the link is terminated after a certain number of requests are sent. This number can be set using the lcp-echo-failure option. By default, this feature is disabled altogether. 

No comments: