Fases de la operación

En la siguiente figura se muestran las fases por las que pasa una línea cuando es activada, usada y desactivada, a través del protocolo PPP. Esta secuencia se aplica tanto a las conexiones por módem como a las conexiones router a router.

Fase de enlace muerto (capa física no lista)

El enlace comienza y termina necesariamente en esta fase. Cuando un evento externo (como una detección de portadora) indica que la capa física está lista para ser usada, PPP procederá con la fase de establecimiento del enlace.

Típicamente, si se utiliza un módem, el enlace volverá a esta fase automáticamente después de la desconexión del mismo. En el caso de un enlace hard-wired esta fase puede ser extremadamente corta, tan solo hasta detectar la presencia del dispositivo.

 Fase de establecimiento del enlace

El protocolo de control de enlace (LCP) es usado para establecer la conexión a través de un intercambio de paquetes de configuración. Este intercambio está completo y se ingresa en el estado abierto de LCP una vez que un paquete de "reconocimiento de configuración" ha sido enviado y recibido por ambos.

Todas las opciones de configuración son asumidas con sus valores por defecto a menos que sean alteradas por un intercambio de paquetes de configuración.

Es importante notar que solo las opciones de configuración que son independientes de cada protocolo particular de capa de red son manejadas por el LCP. La configuración de los protocolos de capa de red individuales es manejada por separado por los protocolos de control de red (NCPs) durante la fase de red.

Cualquier paquete que no sea LCP recibido durante esta fase debe ser descartado.

 Fase de validación

En algunos enlaces puede ser deseable solicitar al "par" que se autentifique a sí mismo antes de permitir el intercambio de paquetes del protocolo de capa de red.

Por defecto, la validación o autenticación no es obligatoria. Si una implementación desea que el "par" se autentifique con algún protocolo de validación específico, entonces ésta debe solicitar el uso del protocolo de autenticación durante la fase de establecimiento del enlace.

La autenticación debe tomar lugar tan pronto como sea posible después del establecimiento del enlace.

El progreso de la fase de autenticación a la fase de red no debe ocurrir hasta que la autenticación haya sido completada. Si ésta falla, el que realiza la autenticación debe proceder a la fase de terminación del enlace.

Durante esta fase, sólo son permitidos paquetes del protocolo de control de enlace, el protocolo de autenticación y el monitoreo de calidad de enlace. Cualquier otro paquete recibido debe ser descartado.

La autenticación debe proporcionar algún método de retransmisión, y se procederá a la fase de terminación del enlace sólo luego de que se ha excedido cierta cantidad de intentos de autenticación.

 Fase de red

Cada NCP debe ser abierto y cerrado de a uno por vez.

Fase abierta

Una vez que un NCP ha alcanzado el estado abierto, PPP transportará los correspondientes paquetes del protocolo de capa de red. Cualquier paquete recibido mientras su NCP no esté en el estado abierto debe ser descartado.

Durante esta fase el tráfico del enlace consiste en cualquier combinación posible de paquetes LCP, NCP, y de protocolo de capa de red.

 Fase de terminación del enlace

PPP puede terminar el enlace en cualquier momento. Esto puede ocurrir por la pérdida de la señal portadora, una falla de autenticación, una falla de la calidad del enlace, la expiración de un timer, o un cierre administrativo del enlace.

LCP es usado para cerrar el enlace a través de un intercambio de paquetes de "terminación". Cuando el enlace ha sido cerrado, PPP informa a los protocolos de capa de red así ellos pueden tomar la acción apropiada.

Después del intercambio de paquetes de "terminación", la implementación debe avisar a la capa física que desconecte la línea para forzar la terminación del enlace, particularmente en el caso de una falla de autenticación. El que envía una "solicitud de terminación" debe desconectarse después de recibir un "reconocimiento de terminación", o después de que expire el timer correspondiente. El receptor de una "solicitud de terminación" debe esperar al "par" para desconectarse, y no lo debe hacer hasta que al menos haya pasado cierto tiempo de reiniciado después de enviar el "reconocimiento de terminación". PPP procederá entonces con la fase de enlace muerto.

Cualquier paquete recibido durante esta fase que no sea LCP debe ser descartado.

La clausura del enlace por LCP es suficiente. No es necesario que cada NCP envíe paquetes de terminación. A la inversa, el hecho de que un NCP sea cerrado no es razón suficiente para causar la terminación del enlace PPP, aún si ese NCP era el único actualmente en el estado abierto.

 Estados

Algunos posibles estados son: "inicial" (la capa más baja no está disponible y no ha ocurrido una apertura), "starting" (ha sido iniciada una apertura pero la capa más baja aún no está disponible), "closed" (el enlace está disponible pero no ha ocurrido una apertura), etc.

 Eventos

Las transiciones y las acciones en la negociación son causadas por eventos.

Algunos son: "up" (este evento ocurre cuando la capa más baja indica que está lista para transportar paquetes; típicamente es usado por los procesos de manejo y llamada de un módem, y también puede ser utilizado por el LCP para indicar a cada NCP que el enlace está entrando en la fase de red). Otro evento muy común es "down" (cuando la capa más baja indica que ya no está lista para transportar paquetes, este evento también es generalmente utilizado por un módem o por un LCP).

 Acciones

Son causadas por eventos y habitualmente indican la transmisión de paquetes y/o el comienzo o parada de timers.

Algunas acciones son: "evento ilegal" (esto indica acerca de un evento que no puede ocurrir en una negociación implementada correctamente), "capa hacia arriba" (esta acción indica a las capas superiores que la negociación está entrando en estado "abierto"; típicamente es utilizada por el LCP para indicar el evento "up" a un NCP, por un protocolo de autenticación, o de calidad de enlace).

 Prevención de ciclos

El PPP hace intenta evitar ciclos mientras se efectúa la negociación de opciones de configuración. De todas formas, el protocolo no garantiza que no ocurrirán ciclos. Como en cualquier negociación es posible configurar dos implementaciones PPP con políticas conflictivas que nunca converjan finalmente. También es posible configurar políticas que converjan, pero que se tomen un tiempo significativo para hacerlo.

   Protocolo de Control de Enlace (LCP)

El LCP es usado para acordar automáticamente las opciones del formato de encapsulación, los límites de manipulación de tamaño de paquete, detectar un enlace con ciclos, otros errores comunes por mala configuración, y terminar el enlace. Otras facilidades opcionales provistas son: autenticación de la identidad de los "pares" del enlace, y determinación de cuándo el enlace está funcionando apropiadamente y cuándo está fallando.

 Hay tres clases de paquetes LCP:

1. Paquetes de configuración de enlace: usados para establecer y configurar el enlace ("solicitud de configuración", "reconocimiento de configuración", "no reconocimiento de configuración" y "rechazo de configuración").

2. Paquetes de terminación de enlace: usados para terminar el enlace ("solicitud de terminación" y "reconocimiento de terminación").

3. Paquetes de mantenimiento del enlace: usados para manejar y depurar el enlace ("rechazo de código", "rechazo de protocolo", "solicitud de eco", "respuesta de eco", "solicitud de descarte").

Un paquete LCP es encapsulado en el campo de información PPP, donde el campo de protocolo PPP indica el tipo C021hex.

Básicamente, el formato de un paquete del protocolo de control de enlace es el siguiente:

 Campo código

Ocupa un byte y sirve para identificar el tipo de paquete LCP. Cuando se recibe un paquete con un campo de código desconocido, se transmite un paquete de "rechazo de código".

 Campo identificador

Es de un byte y ayuda en la comparación de las solicitudes y respuestas.

Campo longitud

Es de dos bytes e indica la longitud del paquete LCP, incluyendo los campos código, identificador, longitud y datos. La longitud no debe exceder la MRU del enlace. Los bytes fuera del rango del campo longitud son tratados como relleno e ignorados al ser recibidos.

 Campo datos

Pueden ser 0 o más bytes, indicados por el campo longitud. El formato de los datos es determinado por el campo código.

Solicitud de configuración

Debe transmitirse para abrir una conexión. En el campo de datos se incluirán las opciones de configuración que el transmisor desee negociar (0 o más). Todas estas opciones son negociadas simultáneamente.

 Reconocimiento de configuración

Si cada opción de configuración recibida en una "solicitud de configuración" es reconocible y sus valores son aceptables, la implementación receptora debe transmitir un paquete de "reconocimiento". Estas opciones reconocidas no deberán ser modificadas luego. Las opciones reconocidas son enviadas en el área de datos del paquete simultáneamente.

 No reconocimiento de configuración

Si cada opción de configuración es reconocible pero algunos valores no son aceptables, se debe transmitir un paquete de "no reconocimiento de configuración". El campo de datos es completado sólo con las opciones no aceptadas de la "solicitud de configuración".

Al recibir un paquete de "no reconocimiento", el campo de identificación debe ser comparado con el de la última "solicitud de configuración", y cuando se vuelva a enviar una "solicitud de configuración", las opciones de la mismas deberán ser modificadas.