Como SLIP, PPP es un protocolo usado para mandar datagramas a trav�s de una conexi�n serie; sin embargo, resuelve varias de las deficiencias de SLIP. Primero, puede transportar un alto n�mero de protocolos y no est� limitado al protocolo IP. Proporciona detecci�n de errores en el mismo enlace, mientras que SLIP acepta y reenv�a datagramas corruptos mientras que la corrupci�n no se produzca en la cabecera. Igualmente importante, permite a los extremos comunicantes negociar opciones, como la direcci�n IP y el tama�o m�ximo del datagrama, y provee autentificaci�n del cliente. Esta negociaci�n interna, permite una automatizaci�n fiable del establecimiento de la conexi�n. Mientras la autentificaci�n elimina la necesidad de cuentas de usuario que requiere SLIP. Para cada una de estas capacidades, PPP tiene un protocolo espec�fico. En este cap�tulo cubrimos brevemente estos elementos b�sicos que forman PPP. Esta discusi�n de PPP est� lejos de ser completa; si quiere aprender m�s sobre PPP, le instamos a que lea el RFC de su especificaci�n y la alrededor de docena de RFCs que lo complementan.[1] Adem�s hay un extenso libro de O'Reilly sobre el tema Using & Managing PPP, por Andrew Sun.
En la parte m�s baja de PPP est� el protocolo de Control de Conexi�n de Datos de Alto-Nivel (HDLC), que define los l�mites de las tramas PPP individuales, y proporciona un control de errores de 16 bit.[2] Al contrario de lo que ocurr�a con SLIP, una trama PPP es capaz de llevar paquetes de otros protocolos distintos al IP, como IPX de Novell o Appletalk. PPP consigue esto a�adiendo a la trama b�sica HDLC un campo de control que identifica el tipo de paquete contenido en la misma.
El Protocolo de Control de Enlace, es utilizado en la parte m�s alta del HDLC para negociar las opciones concernientes a la conexi�n de datos, tales como la Unidad M�xima de Recepci�n (MRU), que establece el tama�o m�ximo del datagrama que cada extremo de comunicaci�n acepta recibir.
Un paso importante en la configuraci�n del enlace PPP corresponde a la autentificaci�n del cliente. Aunque no es obligatorio, es casi un deber para las l�neas telef�nicas y as� mantener fuera a los intrusos. Normalmente la m�quina llamada (el servidor) pide al cliente que se identifique probando que se sabe alguna clave secreta. Si el llamante se equivoca con la clave, la conexi�n termina. Con PPP, las autorizaciones se producen en los dos sentidos; es decir, el que llama tambi�n puede pedir al servidor que se autentifique. Estos procedimientos de autentificaci�n son totalmente independientes entre s�. Hay dos protocolos distintos, seg�n el tipo de autentificaci�n, los cuales discutiremos m�s adelante en este cap�tulo: el Protocolo de Autentificaci�n por Contrase�a (PAP) y el Protocolo de Autentificaci�n por Reto (CHAP).
Cada protocolo de red que es encaminado a trav�s de la conexi�n de datos, como el IP, el Appletalk, etc; se configura din�micamente usando el correspondiente Protocolo de Control de Red (NCP). Por ejemplo, para enviar datagramas IP a trav�s del enlace, los dos nodos tienen que negociar en primer lugar qu� direcciones IP van a utilizar. El protocolo de control utilizado para esto es el Protocolo de Control del IP (IPCP).
Aparte de enviar datagramas IP est�ndar a trav�s del enlace, el PPP tambi�n permite la compresi�n Van Jacobson de las cabeceras en los datagramas IP. Es una t�cnica para reducir las cabeceras de los paquetes TCP a un espacio de tan s�lo tres bytes. Tambi�n se utiliza en el CSLIP, y es conocida coloquialmente como compresi�n de cabeceras VJ. La utilizaci�n de la compresi�n puede negociarse tambi�n al comienzo de la conexi�n gracias al IPCP.
[1] | Los RFCs m�s relevantes est�n indicados en la bibliografia al final del libro. |
[2] | En realidad, HDLC es un protocolo mucho m�s general publicado por la Organizaci�n Internacional de Est�ndares (ISO). |