Make your own free website on Tripod.com

PROTOCOLO PPP

ENTRAMADO

La encapsulación PPP provee multiplexamiento de diferentes protocolos de la capa de red sobre el mismo enlace. Ha sido diseñada cuidadosamente para mantener compatibilidad con el hardware mayormente usado.

Sólo son necesarios 8bytes adicionales para formar la encapsulación cuando se usa dentro del entramado por defecto. En ambientes con escaso ancho de banda, la encapsulación y entramado pueden requerir menos bytes.

El formato de la trama completa es:

Indicador (1byte)

Dirección (1byte)

Control (1byte)

Protocolo (1 ó 2bytes)

Información (Variable)

Suma (2 ó 4bytes)

Indicador (1byte)

Todas las tramas comienzan con el byte indicador “01111110”. Luego viene el campo dirección, al que siempre se asigna el valor “11111111”. La dirección va seguida por el campo de control, cuyo valor predeterminado es “00000011”. Este valor indica un marco sin número ya que PPP no proporciona por omisión transmisión confiable (usando números de secuencia y acuses) pero en ambientes ruidosos se puede usar un modo numerado para transmisión confiable. El anteúltimo campo es el de suma de comprobación, que normalmente es de 2bytes, pero puede negociarse una suma de 4bytes. La trama finaliza con otro byte indicador “01111110”.

Debido a que los campos indicadores son utilizados para encapsular la información fundamental del protocolo, desde ahora nos concentraremos en el siguiente esquema:

Protocolo (1 ó 2bytes)

Información (y relleno) (Variable)

Campo Protocolo.

Este campo es de 1 ó 2 bytes y su valor identifica el contenido del datagrama en el campo de información del paquete (Cuando hablamos de “paquete” nos estamos refiriendo al marco de la capa de enlace, que es la que opera el PPP; no debe confundirse con los de la capa de red, manejados por IP). El bit menos significativo del byte menos significativo debe ser 1 y el bit menos significativo del byte mas significativo debe ser 0.Los marcos recibidos que no cumplan con estas reglas deben ser tratados como irreconocibles.

Los valores en el campo de protocolo dentro del rango de 0hex a 3hex identifican el protocolo de la capa de red de los paquetes específicos, y valores en el campo de 8hex a Bhex identifican paquetes pertenecientes al protocolo de control de red asociado (NCPs).Los valores en el campo de protocolo dentro del rango de 4hex a 7hex son usados para protocolos con bajo volumen de trafico, los cuales no tienen asociados NCP. Valores en el rango de Chex a Fhex identifican paquetes de los protocolos de control de la capa de enlace (Como LCP).

Campo información.

Puede tener 0 ó mas bytes. Contiene el datagrama para el protocolo especificado en el campo protocolo. La máxima longitud para este campo, incluyendo el relleno pero no incluyendo el campo de protocolo, es determinada por la unidad máxima de recepción (MRU), la cual es de 1500 bytes por defecto. Mediante negociaciones, PPP puede usar otros valores para la MRU.

A la información se le puede agregar un relleno, con un número arbitrario de bytes, hasta llegar a la MRU.

 

 

 

Point to Point Protocol (PPP)

En los años 80 Internet estaba practicamente restringido a instituciones de investigación, agencias gubernamentales y universidades, la mayoria de las máquinas que la conformaban estaban conectadas a través de redes LANs y sólo algunas pocas lo hacian de manera punto a punto utilizando lineas seriales con RS-232-C a pesar de que practicamente cualquier máquina podia soportar este tipo de conexiones.

La causa del poco uso de conexiones punto a punto se debia a la falta de un protocolo para encapsular datagrmas ip a través de lineas seriales, fue ahí donde surgio PPP. Adicionalmente PPP fue desarrollado con la idea de poder realizar muchas actividades adicionales como la verificación de la calidad del enlace, el multiplexaje entre protocolos, la asignación y manejo de direcciones IP, la autentificación del enlace,la negociación para la compresión de datos, la detección de errores, etc.

PPP mantiene el control de los aspectos mencionados anteriormente utilizando LCP (Link Control Protocol) y NCP (Network Control Protocols) para definir los protocolos de nivel de red contenidos dentro de la trama PPP.

Componentes de PPP

Los componentes son:

En la figura adjunta se muestra a grandes rasgos la estructuración de PPP

Funcionamiento de PPP

Antes del establecimiento de la conexión el remitente envía tramas LCP para configurar y , si se desea, verificar el enlace, luego el remitente envía las tramas de NCP para seleccionar y configurar el o los enlaces de red a ser utilizados; luego de esto, los paquetes de cada protocolo de red pueden comenzar a ser enviados.

Descripción del Protocolo

PPP provee un método para transmitir datagramas a través de lineas seriales.

PPP provee un protocolo de encapsulamiento a través de enlaces síncronos y asíncronos. Los enlaces físicos deben ser full-duplex (Un enlace es dupplex si puede enviar y recibir y datos y es full-duplex si puede hacerlo simultaneamente) y pueden ser tanto dedicados como de conmutación de circuitos. PPP utiliza HDLC como base para la encapsulación. El diseño de PPP ha sido desarrolado con el objetivo de soportar hardware de uso común.

Una de las características más importantes de PPP es la capacidad de proveer el multiplexaje de diferentes protocolos a través del mismo enlace.

El Formato de la trama PPP

El formato de la trama de PPP esta basado en el formato de HDLC, a continuación se presenta un gráfico que lo representa y la explicación de los campos que lo conforman.

Value (hex)

Nombre del Protocolo

0001 to 001f

reservado

0021

Internet Protocol

0023

OSI Network Layer

0025

Xerox NS IDP

0027

DECnet Phase IV

0029

Appletalk

002b

Novell IPX

002d

Van Jacobson Compressed TCP/IP

002f

Van Jacobson Uncompressed TCP/IP

0031

Bridging PDU

0033

Stream Protocol (ST-II)

0035

Banyan Vines

0037

reservado

00ff

reservado

0201

802.1d Hello Packets

0231

Luxcom

0233

Sigma Network Systems

8021

Internet Protocol Control Protocol

8023

OSI Network Layer Control Protocol

8025

Xerox NS IDP Control Protocol

8027

DECnet Phase IV Control Protocol

8029

Appletalk Control Protocol

802b

Novell IPX Control Protocol

802d

Reservado

802f

Reservado

8031

Bridging NCP

8033

Stream Protocol Control Protocol

8035

Banyan Vines Control Protocol

c021

Link Control Protocol

c023

Password Authentication Protocol (PAP)

c025

Reporte de la Calidad del Enlace

c223

Challenge Handshake Authentication Protocol

Modo de Operación de un enlace PPP

Para el establecimiento de un enlace PPP cada extremo debe enviar paquetes LCP para configurar y, si se desea, verificar la calidad del canal. Después de que el enlace ha sido establecido se puede proceder a la autenticación y luego enviar paquetes NCP para seleccionar y configurar los protocolos de red a ser utilizados, una vez hecho esto los datagramas de cada protocolo pueden ser enviados.

Adjunto se presenta un diagrama de las fases por las que atraviesa la conexión PPP.

HDLC

El protocolo HDLC (High-level Data Link Control), es usuado como base de transmisiones con PPP, dicho protocolo surge del SDLC (Synchronous Data Link Control) que fue desarrollado por IBM.

HDLC es un protocolo orientado a bit, utilizando bit stuffing para mantener la transparencia en la transmisión de los datos y la secuencia de bits 01111110 para delimitar las tramas. HDLC es muy similar a otros protocolos de su tipo como SDLC y ADCCP (Advanced Data Communication Control Procedure) en su estructura y modo de funcionamiento. Todos ellos tienen una estructura de trama como se muestra a continuación:

El protocolo utiliza el sistema de ventana corrediza, utilizando para ello el campo de tres bits (seq) que indica el número de secuencia de la trama.

El campo next contiene el acknowledge de uno de las tramas enviadas anteriormente, en realidad en el se almacena el número de trama que a⮠?o se ha recibido, de esta manera se pueden realizar los acks mientras se transmiten datos.

El campo P/F (Pool/Final) indica si se estan enviando datos convencionales (P) o si se trata de la trama final (F).

En cuanto a las tramas de tipo supervisor, el campo Type puede contener:

Las tramas de tipo unnumbered son utilizadas para propósitos de control en la transmisión, los posibles controles que se pueden realizar son indicados dentro el campo Modifier

PPP en Linux

Una máquina con Linux puede ser tanto un cliente PPP como un servidor de PPP o ambas cosas al mismo tiempo si la máquina posee 2 o más interfaces punto a punto, como puertos seriales o modems.

Conectando un cliente linux con TCP/IP mediante PPP

Es indispensable para poder conectarse a una red, tener instalado el demonio de ppp (PPP daemon o pppd), por lo general las distribuciones más populares de Linux como lo son Slackware, Red-Hat y Debian Linux vienen con dicho demonio, de no ser así puede obtenerlo en: El demonio PPP.Dentro del mismo paquete puede encontrarse la documentación de como configurarse e instalarse el binario de este demonio.

Otra condición necesaria para poder realizarse el enlace es que el kernel del sistema operativo soporte el protocolo PPP, aunque las distribuciones más conocidas vienen con soporte para PPP ya sea como parte integral del kernel o como un módulo de carga dinámica del mismo. A pesar de ello es recomendable recompilar el kernel para de esta manera tenerlo optimizado para la arquitectura de la máquina. Para que el kernel soporte PPP lo único que se debe hacer es responder afirmativamente en el momento en que el script configure pregunte si se deasea soporte para PPP, que es el primer paso para la recompilación del kernel. Para más información sobre como recompilar el kernel puede consultarse un documento llamado The Linux Kernel HOWTO.

Es importante conocer también información acerca del servidor de PPP del ISP (Internet Service Provider) que en muchos casos puede referirse a nuestro centro educativo. La informaci㮠?ue se debe obtener:

domain  <dominio del isp (ej usb.ve)>
nameserver  <dirección IP de servidor de DNS del isp>
.
.
nameserver  <dirección IP de servidor adicional de DNS>

Un punto importante a señalar es que para el establecimiento de un enlace PPP a través de Linux se requiere tener privilegios de root ya que el proceso requiere de la manipulación de las interfaces de red por parte del demonio PPP (pppd), en muchas distribuciones el pppd tiene el setuid activado, es decir tiene permiso 4755 (con chmod).

Archivos de Configuración de PPP

El demonio de ppp soporta un gran número de opciones, las distribuciones del mismo proveen por defecto unos archivos de configuración así como unos scripts genéricos para realizar e interrumpir conexiones de ppp, a cotinuación se presentan unos archivos que viene con la distribución estanadard de ppp 2.2.


/etc/ppp/scripts/ppp-on

script de conexión por modem

/etc/ppp/scripts/ppp-on-dialer

parte 1 del script ppp-on

/etc/ppp/scripts/ppp-off

script para desconexión

/etc/ppp/options

archivo de opciones de pppd para todas las conexiones

/etc/ppp/options.ttyXX

archivo de opciones de pppd específico a una conexión en ese puerto


Entre las diferentes distribuciones de Linux lo único que cambia es la ubicación de los archivos.

El último de los archivos , /etc/ppp/options.ttyXX, sirve para configurar los diferentes puertos de manera independiente, esto es muy útil , sobre todo cuando deseamos tener un servidor de PPP.

A continuación se presenta un archivo de opciones ppp con la explicación de los campos que en el se encuentran. Las lineas que comienzan con # son comentarios como en cualquier shell script, si se desea usar algunas de las opciones recordar descomentar la linea.

# /etc/ppp/options

 

# Use un ejecutable o un shell script para inicializar la linea

# telefónica. Este script por lo general utiliza el programa "chat"

# para realizar la llamada por modem, al final de este archivo se

# presentará un shell script modelo que utiliza chat.

#connect "echo Es indispensable colocar el comando para la conexión"

 

# Ejecuta el comando o el shell script una vez terminada la sesión

# de ppp. Por ejemplo puede ejecutar comandos para causar que el modem

# descuelgue cuando finaliza el enlace.

#disconnect "chat -- \d+++\d\c OK ath0 OK"

 

# El caracter de escape representado en 32-bit en hexagesimal como

# caracter de control para conexiones asyncronas. Por lo general esta

# opción no tiene uso alguno ya que lo que se suele utilizar son

# conexiones síncronas.

#asyncmap 0

 

# Solicita que el otro extremo realice autenticación antes de

# permitir que los paquetes de red sean enviados o recibidos.

#auth

 

# Utiliza control de flujo mediante hardware, para controlar el flujo

# en el puerto serial.

#crtscts

 

# Utiliza control de flujo mediante software, para controlar el flujo

# en el puerto serial.

#xonxoff

 

# Añade a la tabla de rutas una ruta por defecto a través del

# enlace ppp. La entrada en la tabla de rutas se elimina tan pronto

# como se cierra la conexión.

#defaultroute

 

# Especifica los caracteres que deben ser escapados durante la

# transmisión. Los caracteres sos especificados como una lista de

# valores hexagesimales.

#escape 11,13,ff

 

# No usar las lineas de control del modem

#local

 

# Especifica que pppd debe usar un sistema de lock en el dispositivo

# serial para asegurar que solo él lo esté accesando.

#lock

 

# Usar las lineas de control del modem.

#modem

 

 

# Setear el  MRU [Maximum Receive Unit] es decir el tamaño

# máximo del paquete ppp para informárselo al otro extremo, por

# convención se selecciona el menor de ambos. El número está

# representado en bytes. El valor mínimo es 128 y por defecto es

# 1500, se recomienda 296 bytes (40 bytes de encabezado TCP/IP + 256

# bytes de datos.

#mru 542

 

# Fija el netmask que se va a utilizar para la interfaz de red del

# enlace ppp, por lo general /dev/ppp0

#netmask 255.255.255.0

 

 

# Deshabilita la opción por defecto que es que cuando la

# dirección IP no ha sido establecida localmente debe determinarla

# (si es posible) utilizando el nombre de la máquina (hostname). En

# este caso la dirección ip debe ser provista por el otro extremo

# de la conexión PPP.

#noipdefault

 

# Habilita la opción pasiva de LCP. Con esta opción al tratarse

# de establecerse la conexión con el otro extremo pppd esperará

# indefinidamente hasta recibir una respuesta de LCP válida en vez

# de terminar con la conexión.

#passive

 

# Con esta opción, pppd no transmitirá los paqutes LCP para

# iniciar la conexión hasta que un paquete LCP válido haya

# sido recibido por parte del otro extremo del enlace, esto se usa en

# caso de que la otra máquina haya habilitado la opción de passive.

#silent

 

# Ignora las opciones de LCP que sean transmitidas por parte del otro

# extremo del enlace, esta opción se habilita por lo general por

# razones de seguridad.

#-all

 

# Deshabilita la opción de compresión en las direcciones y en

# los paquetes de control.

#-ac

 

# Deshabilita las negociaciones asíncronas, utiliza los asyncmaps

# por defecto, los caracteres de control.

#-am

 

# El demonio de ppp no hace fork para entrar en background

#-detach

 

# Deshabilita la negociación de dirección IP, con esta opción

# la dirección IP del otro extremo debe setearse en el archivo de

# configuracion (ip-remoto:ip-local).

#-ip

 

# Con esta opción deshabilita la posibilidad de que el pppd pueda

# deteectar loops en el canal de comunicación.

#-mn

 

# Deshabilita la negociación del MRU nombrado arriba y utiliza 1500

# bytes.

#-mru

 

# Requiere que el otro extremo se autentifique utilizando PAP

#+pap

 

# No permite autenticarse al otro extremo con PAP (Password

# Autentication Protocol)

#-pap

 

# Requiere que el otro extremo se autentifique utilizando CHAP

# (Cryptographic Handshake Authentication Protocol)

#+chap

 

# No permite autenticarse al otro extremo con CHAP

#-chap

 

# Deshabilita la opción de poder negociar la compresión de los

# encabezados IP utilizando Van Jacobson Header Compression

#-vj

 

# Incrementa el nivel de depurado en las acciones del pppd. Estas son

# reportadas utilizando el syslog.

#debug

 

# Setea el dominio de la máquina a el que este indicado dentro de

#domain

 

# Habilita el depurado en el driver de PPP del kernel

#kdebug n

 

# Setea el MTU (Maximun Transmit Unit) a n, excepto que el otro

# extremo transmita un valor mas pequeño utilizando el mru.

#mtu

 

# Añade una entrada a la tabla ARP (Address Resolution Protocol)

# con la dirección IP del otro extremo y la dirección Ethernet

# de la máquina cliente.

#proxyarp

 

# Con esta opción pppd enviará un paquete LCP echo-request cada

# n segundos.

#lcp-echo-interval

 

# Con esta opción pppd pensará que  el otro extremo del enlace

# esta caido si  paquetes LCP echo-requests se han enviado sin

# respuesta alguna. Si esto ocurre se cerrará la conexión.

#lcp-echo-failure

 

# Setea el LCP restart interval (timeout de retransmisión) a

# segundos

#lcp-restart

 

 

# Coloca el máximo número de paquetes LCP terminate-request a

#lcp-max-terminate

 

# Setea el número máximo de paquetes LCP configure-requests a

#lcp-max-configure

 

# Setea el número máximo de paquetes LCP configure-NAKs a

# después de enviar paquets configure-Rejects.

#lcp-max-failure

 

# NOTA: Para más información sobre los contenidos de este

# archivo de configuración como la explicación detallada del

# protocolo LCP y de sus distintos paquetes referirse al RFC 1331

Si su proveedor utiliza los protocolos de autenticación PAP o CHAP puede encontrar más información al respecto en el siguiente link: Conexión usando PAP o CHAP

En la mayoria de los casos el acceso a los servidores PPP se realiza mediante scripts, otrogando el login y el passqord como strings de texto, para este tipo de conexiones se puede utilizar los script que se incluyen el la distribución de pppd, ppp-on y ppp-on-dialer, los campos que se deben modificar son:

TELEPHONE=555-1212      # El número del ISP

ACCOUNT=george          # EL login en el sistema

PASSWORD=gracie         # El password de la cuenta

LOCAL_IP=0.0.0.0        # La direcció IP local. Dynamic = 0.0.0.0

REMOTE_IP=0.0.0.0       # La dirección IP remota. Normally 0.0.0.0

NETMASK=255.255.255.0   # El netmask apropiado si se necesita.

En el archivo ppp-on-dialer lo único que se requiere cambiar es la linea:

OK              ATDT$TELEPHONE                  \

 

por

 

OK              ATDP$TELEPHONE                  \

en caso de que se posea una linea de pulso y no de tono.

Una vez terminada la sesión se ejecuta el script ppp-off para cerrar el enlace.

Interconexión de dos redes TCP/IP utilizando PPP

PPP va más allá de un protocolo para comunicarse con un ISP, trataremos un caso muy útil en el que conectaremos dos redes utilizando un enlace PPP establecido por modem en donde una de las dos redes está conectada a Internet, explicaremos desde como configurar los dos modems hasta la preparación de dos máquinas Linux que serviran como routers para el establecimiento de la conexión. El siguiente gráfico presenta un esquema general de como estarán conectadas ambas redes.

Para poder realizar la interconexión necesitamos tener un servidor y un cliente de PPP, la configuración del cliente está explicado en la sección PPP en Linux

Configuración del Servidor de PPP

Como se puede ver en el gráfico el servidor de PPP también funcionará como router en el la red 1, para transferir los paquetes IP a la red al otro extremo del enlace PPP, es por ello la máquina debe ser capaz de reenviar los paquetes IP entre las dos interfaces de red, la de PPP y la de conexión a su red local, que muy probablemente será una red Ethernet, para que la máquina pueda soportarlo se debe recompilar el kernel para que soporte "ip forwarding", para más detalles de como recompilar el kernel puede referirse a Linux Kernel HOWTO.

Primero se considerará el convertir la máquina Linux en un servidor PPP, a grandes rasgos lo que debemos hacer es permitir que el modem en el servidor permita la recepción de llamadas y al ser aceptada se presenta una sesión de terminal para que el script del cliente pueda accesar el login y el passwd, luego se ejecutará en el servidor el pppd, para ello lo que se suele hacer es colocar la ejecución del mismo como parte del script de inicialización o como shell de la cuenta.

Pasos para configurar el servidor de PPP


Para ello se puede utilizar el comando adduser.


En el archivo se debe colocar como una de las últimas lineas /usr/sbin/pppd -detach para que se ejecute tan pronto como el usuario pueda accesar el sistema en el servidor.

·                      ALTLOCK=cua3
·                      ALTLINE=cua3
·                      # line to initialize
·                      INITLINE=cua3
·                      # timeout to disconnect if idle...

·                      TIMEOUT=60
·                      # modem initialization string... 
·                      # format:   ... (chat sequence)
·                      INIT="" AT\r OK\r\n

·                      WAITFOR=RING
·                      CONNECT="" ATA\r CONNECT\s\A

·                      # this line sets the time to delay before sending the login banner

·                      DELAY=1
·                      #DEBUG=010

Si se desea más información sobre el sisgnificado se cada campo a puede con el manual de uugetty o con el documento Linux Serial HOWTO

 

S3:456:respawn:/sbin/uugetty -d /etc/default/uugetty.ttyS3 ttyS3

·                <dirección ip servidor>:<dirección ip del cliente>

La dirección IP del cliente es la que se asignará a este al momento de establecerse el enlace PPP, si el pppd fue configurado para aceptar asignación de dirección IP dinámica.

En el caso presentado, el cliente y el servidor PPP hacen la labor de routers, es por ello que necesitaremos dos subredes, para el enlace ppp y otra para la nueva red. Para ello deberemos subdividir la dirección de red 159.90.120.0 en dos partes, la 159.90.120.0 y la 159.90.120.128, ambas con netmask 255.255.255.128, tomaremos la primera como dirección para el enlace ppp y la segunda para la nueva red.

Primero asignemos las direcciones IP para los dos extremos del enlace PPP, ambos de la red 159.90.120.0, por ejemplo 159.90.120.1 para el servidor de PPP y 159.90.120.2 para el cliente, el cual al establecer el enlace PPP el pppd colocará esta ruta como la ruta por defecto, en el mismo cliente PPP se debe agrgar una ruta a la red 159.90.120.128 hacia la interfaz ethernet, el resto de las máquinas de la nueva red deberan tener como ruta por defecto al la dirección ethernet del cliente PPP. En el otro extremo del enlace establecemos una ruta a 159.90.120.128 con netmask 255.255.255.128 utilizando como gateway al 159.90.120.1. Por últmo debemos añadir una entrada al router de la red 1, todo paquete para la red 159.90.120.128 con netmask 255.255.255.128 hacia la dirección ip de la interfaz ethernet del servidor de PPP. Para más información sobre configuración de redes sobre linux puede consultarse el documento NET-3 HOWTO

Introducción

 

El protocolo PPP proporciona un mecanismo estándar para transportar datagramas de diversos tipos de protocolos a través de un enlace punto a punto. PPP está compuesto por un método para encapsular datagramas multiprotocolo, un protocolo de control de enlace para el establecimiento, configuración y comprobación de la conexión de enlace (LCP) y una familia de protocolos de control de red (NCPs) para establecer y configurar diferentes protocolos del nivel de red.

El protocolo PPP está diseñando para transmitir datos a través de enlaces simples full-duplex que entregan los paquetes de forma ordenada.

Encapsulamiento

 

El encapsulamiento habilita la posibilidad de multiplexar diferentes protocolos de red sobre el mismo enlace. Sólo son necesarios 8 octetos adicionales para encapsular un datagrama de red en una trama PPP. En entornos donde el ancho de banda está muy limitado, esta sobrecarga puede reducirse aún más hasta llegar a tan sólo 2 ó 4 octetos.

Para soportar implementaciones de alta velocidad, el encapsulamiento por defecto utiliza únicamente campos simples, de los cuáles, sólo uno necesita ser examinado para realizar la demultiplexación. La cabecera por defecto y los datos se alinean en unidades de 32 bits, la cola de la trama puede tener una alineación arbitraria.

Protocolo de control de enlace (LCP)

 

LCP se utiliza para que las entidades PPP que se conectan acuerden automáticamente las opciones de formato del encapsulamiento, manejen los límites variables en el tamaño de los paquetes, detecten bucles en los enlaces y otros errores comunes de configuración y terminen el enlace. Además, LCP provee otras características adicionales como autenticación y diagnóstico del enlace.

Protocolo de control de red (NCP)

 

Los enlaces punto a punto suelen agudizar muchos de los problemas que ya existen con los actuales protocolos de red. Por ejemplo, la asignación y administración de las direcciones IP, que es un problema incluso en las redes de área local (LANs), se vuelve especialmente difícil sobre enlaces punto a punto a través de circuitos conmutados. Tales problemas son resueltos por una familia de protocolos de control de red (NCPs), cada uno de los cuales cubre las necesidades específicas de sus respectivos protocolos.

Configuración

 

Se pretende que los enlaces PPP sean fáciles de configurar. Por diseño, el estándar cubre las configuraciones más comunes, pero se pueden especificar mejoras a la configuración por defecto que son comunicadas entre las entidades PPP sin intervención del usuario. Finalmente, el operador puede configurar las opciones del enlace de forma explícita, permitiendo que trabaje en condiciones que de otra forma sería imposible que lo hiciera.

El procedimiento de configuración automática se implementa a través de un mecanismo extensible de negociación de las opciones, en el cual cada entidad describe a la otra sus capacidades y requerimientos. Este mecanismo es válido tanto para el protocolo LCP como para el NCP que corresponda a cada caso.

 

 

 

 

 

El protocolo PPP de control de red para IP (IPCP)

 

El protocolo de control de IP se encarga de configurar, habilitar y inhabilitar los módulos del protocolo IP en ambos extremos de la conexión punto a punto. IPCP emplea el mismo mecanismo de intercambio de paquetes que el protocolo de control de enlace (LCP), pero éste no puede realizarse hasta que PPP haya alcanzado la fase del protocolo del nivel de red; los paquetes que se reciban con anterioridad son descargados sin realizar ningún procesamiento.

El protocolo de control IP es idéntico a LCP con algunas excepciones: sólo un paquete IPCP es encapsulado en una trama PPP y el campo de identificación del protocolo indicará el uso de IPCP, no se utilizan todos los códigos, se establecen restricciones en cuanto al intercambio de paquetes y las opciones de configuración también son distintas.

 

Requisitos de la capa física

 

Desde el punto de vista del protocolo PPP, los canales RDSI se comportan como enlaces síncronos orientados a bit o a carácter. Tales enlaces deben ser full-duplex y pueden ser conmutados o dedicados.

El protocolo PPP expone a la capa física un interfaz orientado a carácter, no ofreciendo mecanismos para que unidades de menor tamaño sean suministradas o aceptadas. El flujo de octetos se define fundamentalmente en los puntos de referencia R o T.

En cuanto a la velocidad de transmisión, no se impone ninguna restricción más allá de los propios límites impuestos por la RDSI.

PPP no requiere la utilización de señales de control. Donde esté disponible, el uso de tales señales, éstas pueden incrementar la funcionalidad y el rendimiento. Algunos formatos de trama pueden requerir el uso de señales de control.

La definición de la codificación de las tramas es responsabilidad de los equipos DTE/DCE que se utilicen y, por tanto, queda fuera del ámbito de la especificación de PPP.

Tramas

 

Para los canales B, en ausencia de una configuración previa, la implementación debe utilizar inicialmente el protocolo HDLC en modo síncrono y orientado a bit.

Debido a configuraciones anteriores, el uso del protocolo HDLC en modo síncrono y orientado a carácter se recomienda donde el equipo de terminación de red se conecte directamente al punto de referencia T y el alineamiento de los datos sea de octetos.

A pesar de que HDLC, LAPB, LAPD y LAPF son perfectamente distinguibles, no deberían utilizarse múltiples técnicas de framing concurrentemente en el mismo canal RDSI, de hecho, no hay ningún requisito para que PPP deba reconocer distintos formatos de trama o conmutar entre ellos sin una configuración específica

.

Señalización fuera de banda

 

La experiencia demuestra que el elemento de información LLC (LLC-IE) no se transmite extremo a extremo de forma fiable, ya que no se asegura que los conmutadores sean todos compatibles y, además, las políticas de los operadores de las redes son diversas. Por tanto, no se debe confiar en la transmisión del LLC-IE para determinar el formato de trama o la codificación. No se han asignado valores de LLC-IE pertenecientes para PPP, por lo que cualquier valor que se reciba no es válido y son ignorados.

 

                                                                          ATRAS