Hispanopedia Wiki
Articulo de referencia

Protocolo punto a punto sobre Ethernet

El Protocolo Punto a Punto sobre Ethernet ( PPPoE ) es un protocolo de red para encapsular tramas del Protocolo Punto a Punto (PPP) dentro de tramas Ethernet . Apareció en 1999,...

Hispanopedia WikiContenido en espanolLectura gratuita

El Protocolo Punto a Punto sobre Ethernet ( PPPoE ) es un protocolo de red para encapsular tramas del Protocolo Punto a Punto (PPP) dentro de tramas Ethernet . Apareció en 1999, en el contexto del auge de DSL como la solución para tunelizar paquetes a través de la conexión DSL a la red IP del proveedor de servicios de Internet (ISP) , y desde allí al resto de Internet . Un libro de redes de 2005 señaló que "La mayoría de los proveedores de DSL utilizan PPPoE, que proporciona autenticación , cifrado y compresión ". [ 1 ] El uso típico de PPPoE implica aprovechar las funcionalidades de PPP para autenticar al usuario con un nombre de usuario y una contraseña, a través del protocolo PAP o a través de CHAP . PAP fue dominante en 2007, pero los proveedores de servicios han estado migrando al más seguro CHAP , porque PAP es un protocolo de texto plano. [ 2 ] Hacia el año 2000, PPPoE también comenzó a convertirse en un método de reemplazo para comunicarse con un módem conectado a una computadora o enrutador a través de una LAN Ethernet, desplazando el método anterior, que había sido USB . Este caso de uso, conectar enrutadores a módems a través de Ethernet, sigue siendo extremadamente común hoy en día.

En los equipos de las instalaciones del cliente , PPPoE puede implementarse en un dispositivo de puerta de enlace residencial unificado que maneja las funciones de módem DSL y enrutamiento IP o, en el caso de un módem DSL simple (sin soporte de enrutamiento), PPPoE puede manejarse detrás de él en un enrutador solo Ethernet separado o incluso directamente en la computadora de un usuario. (El soporte para PPPoE está presente en la mayoría de los sistemas operativos, desde Windows XP , [ 3 ] Linux [ 4 ] hasta Mac OS X. [ 5 ] ) Más recientemente , algunas puertas de enlace residenciales basadas en GPON (en lugar de basadas en DSL) también usan PPPoE, aunque el estado de PPPoE en los estándares GPON es marginal, aunque se menciona en la recomendación ITU-T G.984.1 " Redes ópticas pasivas con capacidad Gigabit (GPON): Características generales" .

PPPoE fue desarrollado por UUNET , Redback Networks (ahora Ericsson) y RouterWare (ahora Wind River Systems ) [ 6 ] y está disponible como un RFC informativo 2516 . 

En el mundo de DSL, se suele entender que PPP funciona sobre ATM (como PPPoA), con ATM como protocolo subyacente de capa 2 y una versión de DSL como protocolo de capa 1, aunque no existe tal limitación en el propio protocolo PPP.

Otros escenarios de uso se distinguen a veces añadiendo como sufijo otro protocolo subyacente. Por ejemplo, PPPoEoE, cuando el transporte es Ethernet, como en el caso de las redes Metro Ethernet . (En esta notación, el uso original de PPPoE se denominaría PPPoEoA, aunque no debe confundirse con PPPoA , que tiene una encapsulación diferente del protocolo PPP).

PPPoE se ha descrito en algunos libros como un protocolo de " capa 2.5 ", [ 2 ] [ 7 ] en cierto sentido rudimentario similar a MPLS porque puede usarse para distinguir diferentes flujos IP que comparten una infraestructura Ethernet, aunque la falta de conmutadores PPPoE que tomen decisiones de enrutamiento basadas en encabezados PPPoE limita su aplicabilidad en ese sentido. [ 7 ]

Fundamentación original

A finales de 1998, el modelo de servicio DSL aún no había alcanzado la escala necesaria para reducir los precios a niveles domésticos. La tecnología ADSL se había propuesto una década antes. [ 8 ] Tanto los posibles proveedores de equipos como los operadores reconocieron que la banda ancha, como el módem de cable o el DSL, eventualmente reemplazaría el servicio de acceso telefónico , pero el hardware (tanto en las instalaciones del cliente como en las de la LEC ) enfrentaba una importante barrera de costos de baja cantidad . Las estimaciones iniciales para el despliegue de DSL de baja cantidad mostraron costos en el rango de US$300–500 ( US$593–988 en 2025 ) para un módem DSL y una tarifa de acceso de US$300 /mes de la compañía telefónica, lo que estaba muy por encima de lo que pagaría un usuario doméstico. Por lo tanto, el enfoque inicial se centró en los clientes de pequeñas empresas y negocios domésticos para quienes un ~ Una línea T1 de 1,5 Mbit/s (en aquel entonces entre 800 y 1500 dólares estadounidenses al mes) no era económica, pero quienes necesitaban más que una conexión telefónica o ISDN podían ofrecerla. Si un número suficiente de estos clientes allanaba el camino, el volumen de usuarios reduciría los precios hasta un nivel que podría resultar atractivo para los usuarios domésticos que utilizaban conexión telefónica.

Perfil de uso diferente

El problema era que los clientes de pequeñas empresas tenían un perfil de uso diferente al de un usuario doméstico de acceso telefónico, incluyendo:

  • Conectar una red LAN completa a Internet;
  • Proporcionar servicios en una red LAN local accesible desde el otro extremo de la conexión;
  • Acceso simultáneo a múltiples fuentes de datos externas, como una VPN corporativa y un proveedor de servicios de Internet (ISP) de uso general;
  • Uso continuo durante toda la jornada laboral, o incluso las 24 horas del día.

Estos requisitos no se adaptaban al retardo de establecimiento de conexión propio de una conexión telefónica, ni a su modelo de un ordenador por un proveedor de servicios de Internet (ISP), ni siquiera al modelo de muchos a uno que ofrecía la combinación de NAT y conexión telefónica. Se necesitaba un nuevo modelo.

PPPoE se utiliza principalmente para:

  • Con servicios de Internet DSL que utilizan PPPoE, un módem - router ( puerta de enlace residencial ) compatible con PPPoE se conecta al servicio DSL. En este caso, tanto el proveedor de servicios de Internet (ISP) como el módem-router deben ser compatibles con PPPoE. (Cabe destacar que, en este caso, la comunicación PPPoE sobre DSL se denomina ocasionalmente PPPoEoA , por "PPPoE sobre ATM ").
  • o cuando un módem DSL compatible con PPPoE se conecta a un enrutador Ethernet compatible con PPPoE mediante un cable Ethernet.

Tiempo de comercialización: lo simple es mejor.

Uno de los problemas al crear un protocolo completamente nuevo para satisfacer estas necesidades era el tiempo. El equipo estaba disponible de inmediato, al igual que el servicio, y desarrollar una pila de protocolos completamente nueva ( Microsoft en ese momento abogaba por la conexión de celdas ATM a escritorio mediante fibra óptica [ 9 ] , y L2TP también estaba en desarrollo, pero aún no estaba cerca de completarse) llevaría tanto tiempo que la oportunidad podría esfumarse. Se tomaron varias decisiones para simplificar la implementación y la estandarización con el fin de ofrecer una solución completa rápidamente y a un menor costo.

Reutilizar las pilas de software existentes

PPPoE pretendía fusionar la infraestructura Ethernet, ampliamente extendida, con el omnipresente protocolo PPP, permitiendo a los proveedores reutilizar su software existente y lanzar productos a corto plazo. Prácticamente todos los sistemas operativos de la época contaban con una pila PPP, y el diseño de PPPoE permitía un sencillo adaptador para encapsular tramas PPP dentro de tramas Ethernet.

Simplificar los requisitos de hardware

Las tecnologías WAN de la competencia (T1, ISDN) requerían un enrutador en las instalaciones del cliente. PPPoE utilizaba un tipo de trama Ethernet diferente , lo que permitía que el hardware DSL funcionara simplemente como un puente , enviando algunas tramas a la WAN e ignorando las demás. La implementación de un puente de este tipo es muchísimo más sencilla que la de un enrutador.

RFC informativo

El RFC 2516 se publicó inicialmente como un RFC informativo (en lugar de un RFC que sirviera como estándar ) por la misma razón: el período de adopción para un RFC que sirviera como estándar era excesivamente largo.

Casos de uso actuales

Hacia el año 2000, el protocolo PPPoE se utilizaba (i) para conectar un módem DSL a un ordenador o enrutador, desplazando el método anterior de usar USB , o (ii) el trío de encabezados de protocolo PPP+PPPoE se utilizaba para conectar un enrutador a un nodo de red, un convertidor de protocolo , situado un poco más arriba en la red, perteneciente al ISP o a un operador mayorista de larga distancia que a su vez se conectaba a las redes IP del ISP y luego a Internet. [ 10 ]

El primer caso de uso, la conexión de enrutador a módem, que implica el llamado 'PPPoEoE' (el trío de protocolos PPPoE sobre una LAN Ethernet física), todavía se utiliza ampliamente hoy en día para conectar módems a enrutadores si se utiliza PPP.

El segundo caso de uso, donde el trío de protocolos PPPoE se utiliza sobre uno o más enlaces de acceso a Internet que alcanzan una profundidad mayor o menor en la red ascendente, según el consenso, solo se sigue utilizando por razones históricas. Sin embargo, dado que PPP sigue siendo popular entre algunos ISP, ya sea como protocolo de tunelización, necesario cuando un ISP utiliza un operador/revendedor de acceso mayorista o porque se desean las características de PPP, o ambas cosas.

Como se mencionó anteriormente, curiosamente, a veces se encuentran encabezados MAC de Ethernet en uso con encabezados PPPoE incluso cuando el protocolo Ethernet no está en uso, es decir, no está presente físicamente en una red Ethernet. Esto parece no tener otro propósito que agregar una sobrecarga de encabezados innecesaria, lo que se conoce como "bloat" . Por ejemplo, en el caso de PPPoEoA , que se analiza más adelante, donde no había Ethernet físico, solo ATM , no solo se agregó una capa innecesaria de encabezados MAC de Ethernet, sino también una capa de adaptación de Ethernet adicional para que Ethernet se ajustara sobre ATM.

En el segundo caso de uso, estos encabezados de protocolo adicionales añaden una cantidad considerable de código innecesario y, por lo tanto, perjudican ligeramente el rendimiento.

En el segundo caso de uso, el uso de PPP+PPPoE+Ethernet MAC se extiende a una distancia variable en sentido ascendente. Puede limitarse a la " primera milla ": un par trenzado de cobre en ADSL o VDSL2 / FTTC que involucra módems y nada más, o también puede usarse más arriba extendiéndose a un BRAS (Servidor de Acceso Remoto de Banda Ancha) o un concentrador de acceso que puede o no gestionar el inicio de sesión, pero que sin duda será un convertidor de protocolo de algún tipo. En un caso de ejemplo, PPPoE se extiende en sentido ascendente hasta un nodo operado por un operador mayorista y termina en él, convirtiéndolo al protocolo de túnel L2TP que crea un túnel a los POP (puntos de presencia) IP del ISP .

Etapas

El PPPoE tiene dos etapas distintas:

descubrimiento PPPoE

Dado que las conexiones PPP tradicionales se establecen entre dos puntos finales mediante un enlace serie o un circuito virtual ATM ya establecido durante la conexión telefónica, todas las tramas PPP enviadas por la red llegan sin problemas al otro extremo. Sin embargo, las redes Ethernet son de acceso múltiple, donde cada nodo puede acceder a todos los demás. Una trama Ethernet contiene la dirección de hardware del nodo de destino ( dirección MAC ). Esto facilita que la trama llegue a su destino.

Por lo tanto, antes de intercambiar paquetes de control PPP para establecer la conexión Ethernet, las direcciones MAC de ambos extremos deben ser conocidas entre sí para poder codificarlas en dichos paquetes de control. La etapa de descubrimiento PPPoE realiza precisamente esta función. También ayuda a establecer un ID de sesión que se puede utilizar para el intercambio posterior de paquetes y, además, se utiliza para indicar la finalización de la sesión.

Los paquetes de descubrimiento PPPoE se transportan en tramas Ethernet con EtherType configurado en 0x8863.

Sesión de colaboración público-privada

Una vez conocida la dirección MAC del otro extremo y establecida la sesión, comienza la fase de sesión. En esta fase, se encapsulan fragmentos de datos PPP en paquetes PPPoE y se envían al otro extremo. Los primeros paquetes de sesión negociarán la sesión PPP como de costumbre, y posteriormente la mayoría de los paquetes de sesión contendrán fragmentos de datos PPP.

La encapsulación se realiza anteponiendo a los fragmentos PPP el encabezado PPPoE de 6 bytes y transportándolos en tramas Ethernet con EtherType establecido en 0x8864.

Descubrimiento PPPoE (PPPoED)

Si bien el protocolo PPP tradicional es un protocolo punto a punto , PPPoE es inherentemente una relación cliente-servidor, ya que varios hosts pueden conectarse a un proveedor de servicios a través de una única conexión física.

El proceso de descubrimiento consta de cuatro pasos entre el equipo anfitrión, que actúa como cliente, y el concentrador de acceso del proveedor de servicios de Internet (ISP), que actúa como servidor. Estos pasos se describen a continuación. El quinto y último paso consiste en cerrar una sesión existente.

Cliente a servidor: Iniciación (PADI)

PADI significa PPPoE Active Discovery Initiation. [ 11 ]

Si un usuario desea conectarse a Internet mediante DSL, su ordenador primero debe localizar el concentrador de acceso DSL (DSL-AC) en el punto de presencia (POP) de su proveedor de servicios de Internet (ISP). La comunicación por Ethernet solo es posible mediante direcciones MAC . Dado que el ordenador desconoce la dirección MAC del DSL-AC, envía un paquete PADI mediante una difusión Ethernet (MAC: ff:ff:ff:ff:ff:ff). Este paquete PADI contiene la dirección MAC del ordenador que lo envía.

Ejemplo de un paquete PADI:

Trama 1 (44 bytes transmitidos, 44 bytes capturados) Ethernet II, Fuente: 00:50:da:42:d7:df, Horario: ff:ff:ff:ff:ff:ff Descubrimiento PPP sobre Ethernet Versión: 1 Tipo 1 Iniciación de descubrimiento activo de código (PADI) ID de sesión: 0000 Longitud de la carga útil: 24 Etiquetas PPPoE Etiqueta: Nombre del servicio Etiqueta: Host-Uniq Datos binarios: (16 bytes)

Src. (=origen) contiene la dirección MAC del ordenador que envía el PADI. Dst. (=destino) es la dirección de difusión Ethernet. El paquete PADI puede ser recibido por más de un DSL-AC. Solo los equipos DSL-AC que puedan gestionar la etiqueta "Service-Name" deben responder.

Servidor a cliente: Oferta (PADO)

PADO significa PPPoE Active Discovery Offer. [ 11 ]

Una vez que el ordenador del usuario envía el paquete PADI, el DSL-AC responde con un paquete PADO, utilizando la dirección MAC proporcionada en el PADI. El paquete PADO contiene la dirección MAC del DSL-AC, su nombre (por ejemplo, LEIX11-erx para el DSL-AC de T-Com en Leipzig ) y el nombre del servicio. Si más de un DSL-AC de un POP responde con un paquete PADO, el ordenador del usuario selecciona el DSL-AC correspondiente a un POP específico utilizando el nombre o servicio proporcionado.

Aquí hay un ejemplo de un paquete PADO:

Trama 2 (60 bytes transmitidos, 60 bytes capturados) Ethernet II, Origen: 00:0e:40:7b:f3:8a, Horario: 00:50:da:42:d7:df Descubrimiento PPP sobre Ethernet Versión: 1 Tipo 1 Oferta de descubrimiento activo de código (PADO) ID de sesión: 0000 Longitud de la carga útil: 36 Etiquetas PPPoE Etiqueta: Nombre de AC Datos de cadena: lpzbr001 Etiqueta: Host-Uniq Datos binarios: (16 bytes)

AC-Name -> Los datos de cadena contienen el nombre de la CA, en este caso “lpzbr001” (la DSL-AC Arcor en Leipzig). Src. contiene la dirección MAC de la DSL-AC. La dirección MAC de la DSL-AC también revela el fabricante de la DSL-AC (en este caso Nortel Networks ).

Cliente a servidor: solicitud (PADR)

PADR significa solicitud de descubrimiento activo PPPoE. [ 11 ]

El ordenador del usuario envía un paquete PADR al DSL-AC tras recibir un paquete PADO aceptable de este último. Este paquete confirma la aceptación de la oferta de conexión PPPoE realizada por el DSL-AC que emitió el paquete PADO.

De servidor a cliente: confirmación de sesión (PADS)

PADS significa PPPoE Active Discovery Session-confirmation. [ 11 ]

El paquete PADR anterior es confirmado por el DSL-AC con un paquete PADS, y se proporciona un ID de sesión junto con este. La conexión con el DSL-AC para ese POP se ha establecido completamente.

De un extremo al otro: terminación (PADT)

PADT significa PPPoE Active Discovery Termination. [ 11 ] Este paquete finaliza la conexión con el POP. Puede ser enviado desde la computadora del usuario o desde el DSL-AC.

Sobrecarga del protocolo

PPPoE se utiliza para conectar un PC o un router a un módem mediante un enlace Ethernet y también puede utilizarse para el acceso a Internet a través de DSL en una línea telefónica en la pila de protocolos PPPoE sobre ATM (PPPoEoA) sobre ADSL . PPPoE sobre ATM tiene la mayor sobrecarga de los métodos de entrega DSL más populares, en comparación con, por ejemplo, PPPoA (RFC 2364). [ 12 ] [ 13 ] [ 14 ] [ 15 ]

Uso con DSL: PPPoE sobre ATM (PPPoEoA)

La cantidad de sobrecarga agregada por PPPoEoA en un enlace DSL depende del tamaño del paquete debido a (i) el efecto absorbente del relleno de celdas ATM (que se analiza más adelante), que cancela por completo la sobrecarga adicional de PPPoEoA en algunos casos, (ii) la sobrecarga de PPPoEoA + AAL5 que puede hacer que se requiera una celda ATM adicional completa de 53 bytes, y (iii) en el caso de paquetes IP, la sobrecarga de PPPoE agregada a paquetes que están cerca de la longitud máxima ( ' MRU ' ) puede causar fragmentación IP , que también implica las dos primeras consideraciones para ambos fragmentos IP resultantes. [ 16 ] Sin embargo, ignorando por el momento la fragmentación de ATM e IP, la sobrecarga del encabezado del protocolo para la carga útil de ATM debido a la elección de PPP + PPPoEoA puede ser tan alta como 44 bytes = 2 bytes (para PPP) + 6 (para PPPoE) + 18 (MAC de Ethernet, variable) + 10 (RFC 2684 LLC, variable) + 8 (AAL5 CPCS). [ 12 ] Esta sobrecarga es la que se obtiene al usar la opción de encabezado LLC descrita en RFC 2684 para PPPoEoA. [ 14 ] [ 15 ]

Compárese esto con un protocolo mucho más eficiente en cuanto a encabezados, PPP + PPPoA RFC 2364 VC-MUX sobre ATM+DSL, que tiene una sobrecarga de apenas 10 bytes dentro de la carga útil ATM. (De hecho, simplemente 10 bytes = 2 bytes para PPP + cero para RFC 2364 + 8 (AAL5 CPCS).) [ 13 ] [ 15 ]

Esta cifra de sobrecarga de carga útil AAL5 de 44 bytes se puede reducir de dos maneras: (i) eligiendo la opción RFC 2684 de descartar el FCS MAC Ethernet de 4 bytes, lo que reduce la cifra de 18 bytes anterior a 14, y (ii) utilizando la opción RFC 2684 VC-MUX, cuya contribución de sobrecarga es de tan solo 2 bytes en comparación con la sobrecarga de 10 bytes de la alternativa LLC. Resulta que esta reducción de sobrecarga puede ser una valiosa mejora de la eficiencia. Al usar VC-MUX en lugar de LLC, la sobrecarga de carga útil ATM es de 32 bytes (sin FCS Ethernet) o de 36 bytes (con FCS). [ 12 ] [ 14 ]

ATM AAL5 requiere que un tráiler 'CPCS' de 8 bytes esté siempre presente al final de la última celda ('justificada a la derecha') de la secuencia de celdas ATM que componen el paquete de carga útil AAL5. En el caso de LLC, la sobrecarga total de la carga útil ATM es de 2 + 6 + 18 + 10 + 8 = 44 bytes si está presente el FCS de la MAC Ethernet, o de 2 + 6 + 14 + 10 + 8 = 40 bytes sin FCS. En el caso más eficiente de VC-MUX, la sobrecarga de la carga útil ATM es de 2 + 6 + 18 + 2 + 8 = 36 bytes (con FCS), o de 2 + 6 + 14 + 2 + 8 = 32 bytes (sin FCS).

Sin embargo, la sobrecarga real en términos de la cantidad total de datos de carga útil ATM enviados no es simplemente un valor adicional fijo; solo puede ser cero o 48 bytes (dejando de lado el escenario (iii) mencionado anteriormente, fragmentación IP). Esto se debe a que las celdas ATM tienen una longitud fija con una capacidad de carga útil de 48 bytes, y agregar una mayor cantidad adicional de carga útil AAL5 debido a encabezados adicionales puede requerir que se envíe una celda ATM completa más que contenga el exceso. Las últimas una o dos celdas ATM contienen bytes de relleno según sea necesario para garantizar que la carga útil de cada celda tenga una longitud de 48 bytes. [ 12 ] [ 14 ]

Un ejemplo: En el caso de un paquete IP de 1500 bytes enviado a través de AAL5/ATM con PPPoEoA y RFC2684-LLC, sin tener en cuenta el relleno de celda final por el momento, se comienza con 1500 + 2 + 6 + 18 + 10 + 8 (cola AAL5 CPCS) = 1544 bytes si está presente el FCS de Ethernet, o bien + 2 + 6 + 14 + 10 + 8 = 40 bytes sin FCS. Para enviar 1544 bytes a través de ATM se requieren 33 celdas ATM de 48 bytes, ya que la capacidad de carga útil disponible de 32 celdas × 48 bytes por celda = 1536 bytes no es suficiente. Compárese esto con el caso de PPP + PPPoA que a 1500 + 2 (PPP) + 0 (PPPoA: RFC 2364 VC-MUX) + 8 (cola CPCS) = 1510 bytes cabe en 32 celdas. Entonces el costo real de elegir PPPoEoA más RFC2684-LLC para paquetes IP de 1500 bytes es una celda ATM adicional por paquete IP, una proporción de 33:32. [ 12 ] [ 13 ] [ 14 ] Entonces para paquetes de 1500 bytes, PPPoEoA con LLC es ~3,125% más lento que PPPoA o las opciones óptimas de opciones de encabezado PPPoEoA.

Para algunas longitudes de paquete, la sobrecarga efectiva real adicional de DSL debido a la elección de PPPoEoA en comparación con PPPoA será cero si la sobrecarga adicional del encabezado no es suficiente para necesitar una celda ATM adicional en esa longitud de paquete particular. Por ejemplo, un paquete de 1492 bytes enviado con PPP + PPPoEoA usando RFC2684-LLC más FCS nos da una carga útil ATM total de 1492 + 44 = 1536 bytes = 32 celdas exactamente, y la sobrecarga en este caso especial no es mayor que si estuviéramos usando el protocolo PPPoA eficiente en encabezados, que requeriría 1492 + 2 + 0 + 8 = 1502 bytes de carga útil ATM = 32 celdas también. [ 12 ] [ 14 ] El caso donde la longitud del paquete es 1492 representa la eficiencia óptima para PPPoEoA con RFC2684-LLC en términos de relación, a menos que se permitan paquetes aún más largos.

El uso de PPPoEoA con la opción de encabezado VC-MUX RFC2684 siempre es mucho más eficiente que la opción LLC, ya que la sobrecarga ATM, como se mencionó anteriormente, es de solo 32 o 36 bytes (dependiendo de si se incluye o no la opción Ethernet FCS en PPPoEoA), de modo que un paquete de 1500 bytes que incluye todas las sobrecargas de PPP + PPPoEoA usando VC-MUX equivale a una carga útil ATM total de 1500 + 36 = 1536 bytes si el FCS está presente = 32 celdas ATM exactas, ahorrando así una celda ATM completa. [ 12 ] [ 14 ]

Con paquetes cortos, cuanto mayor sea la sobrecarga del encabezado, mayor será la probabilidad de generar una celda ATM adicional. En el peor de los casos, se podrían enviar 3 celdas ATM en lugar de dos debido a una sobrecarga de encabezado de 44 bytes en comparación con una de 10 bytes, lo que implica un 50 % más de tiempo para transmitir los datos. Por ejemplo, un paquete TCP ACK sobre IPv6 tiene 60 bytes de longitud, y con una sobrecarga de 40 o 44 bytes para PPPoEoA + LLC, esto requiere tres cargas útiles de celdas ATM de 48 bytes. En comparación, PPPoA con sobrecargas de 10 bytes, es decir, 70 bytes en total, cabe en dos celdas. Por lo tanto, el costo adicional de elegir PPPoE/LLC sobre PPPoA es un 50 % más de datos enviados. Sin embargo, PPPoEoA + VC-MUX sería adecuado: con una sobrecarga de 32 o 36 bytes, nuestro paquete IP aún cabe en dos celdas.

En todos los casos, la opción más eficiente para el acceso a internet ADSL basado en ATM es elegir PPPoA (RFC2364) VC-MUX. Sin embargo, si se requiere PPPoEoA, la mejor opción es siempre usar VC-MUX (en lugar de LLC) sin Ethernet FCS, lo que da una sobrecarga de carga útil ATM de 32 bytes = 2 bytes (para PPP) + 6 (para PPPoE) + 14 (Ethernet MAC, sin FCS) + 2 (RFC 2684 VC-MUX) + 8 (trayectoria AAL5 CPCS).

Lamentablemente, algunos servicios DSL requieren el uso de encabezados LLC ineficientes con PPPoE y no permiten la opción VC-MUX, más eficiente. En ese caso, reducir la longitud del paquete, por ejemplo, estableciendo una MTU máxima de 1492, permite recuperar la eficiencia con paquetes largos incluso con encabezados LLC y, como se mencionó anteriormente, evita la generación de celdas ATM adicionales innecesarias.

Sobrecarga en Ethernet

En una LAN Ethernet, la sobrecarga para PPP + PPPoE es fija, de 2 + 6 = 8 bytes , a menos que se produzca fragmentación IP.

MTU/MRU

Cuando un módem DSL compatible con PPPoE envía o recibe tramas Ethernet que contienen carga útil PPP + PPPoE a través del enlace Ethernet a un enrutador (o a un PC compatible con PPPoE), PPP + PPPoE añade una sobrecarga adicional de 8 bytes = 2 (PPP) + 6 (PPPoE) incluida en la carga útil de cada trama Ethernet. Esta sobrecarga adicional puede implicar que se imponga un límite de longitud máxima reducido (denominado ' MTU ' o ' MRU ' ) de 1500 − 8 = 1492 bytes a los paquetes IP enviados o recibidos, por ejemplo, en comparación con el límite habitual de 1500 bytes de la carga útil de las tramas Ethernet que se aplica a las redes Ethernet estándar. Algunos dispositivos son compatibles con RFC 4638, que permite negociar el uso de tramas Ethernet no estándar con una carga útil Ethernet de 1508 bytes, a veces denominadas 'baby jumbo frames ', lo que permite una carga útil PPPoE completa de 1500 bytes. Esta capacidad resulta ventajosa para muchos usuarios en casos donde las empresas que reciben paquetes IP han optado (incorrectamente) por bloquear todas las respuestas ICMP para que no salgan de su red, una mala práctica que impide que el descubrimiento de la MTU de la ruta funcione correctamente y que puede causar problemas a los usuarios que acceden a dichas redes si tienen una MTU inferior a 1500 bytes.

Conversión de módem ADSL de PPPoE a PPPoA

El siguiente diagrama muestra un escenario donde un módem ADSL conectado por Ethernet actúa como convertidor de protocolo PPPoE a PPPoA , y el proveedor de servicios ofrece un servicio PPPoA sin comprender PPPoE. En esta cadena de protocolos no existe PPPoEoA. Este es un diseño óptimo en cuanto a eficiencia de protocolo para un módem ADSL independiente conectado a un enrutador mediante Ethernet.

En esta tecnología alternativa, PPPoE simplemente sirve para conectar módems DSL a un enrutador Ethernet (o a un único ordenador). En este caso, no tiene nada que ver con el mecanismo que utiliza un proveedor de servicios de Internet para ofrecer servicios de banda ancha.

Los módems Draytek Vigor 110, 120 y 130 funcionan de esta manera.

Al transmitir paquetes destinados a Internet, el enrutador Ethernet compatible con PPPoE envía tramas Ethernet al módem DSL (que también es compatible con PPPoE). El módem extrae las tramas PPP de las tramas PPPoE recibidas y las envía al DSLAM encapsulándolas según la RFC 2364 (PPPoA), convirtiendo así PPPoE en PPPoA.

En el diagrama, el área representada como "red troncal" también podría corresponder a la red ATM en redes más antiguas; sin embargo, su arquitectura depende del proveedor de servicios. En un diagrama más detallado y específico del proveedor, habría celdas de tabla adicionales en esta área.

Peculiaridades

Dado que la conexión punto a punto establecida tiene una MTU inferior a la de Ethernet estándar (normalmente 1492 frente a los 1500 de Ethernet), a veces puede causar problemas cuando la detección de MTU de ruta se ve obstaculizada por cortafuegos mal configurados . Aunque las MTU más altas son cada vez más comunes en las redes de los proveedores, la solución habitual consiste en utilizar la limitación o reescritura del MSS (tamaño máximo de segmento) de TCP, mediante la cual el concentrador de acceso reescribe el MSS para garantizar que los pares TCP envíen datagramas más pequeños. Si bien la limitación del MSS de TCP resuelve el problema de la MTU para TCP, otros protocolos como ICMP y UDP aún pueden verse afectados.

El RFC 4638 permite que los dispositivos PPPoE negocien una MTU mayor de 1492 si la capa Ethernet subyacente es capaz de manejar tramas jumbo .

Algunos proveedores ( Cisco [ 17 ] y Juniper , por ejemplo) distinguen PPPoE[oA] de PPPoEoE (PPPoE sobre Ethernet), que es PPPoE que se ejecuta directamente sobre Ethernet u otras redes IEEE 802 o sobre Ethernet puenteada sobre ATM , para distinguirlo de PPPoEoA (PPPoE sobre ATM), que es PPPoE que se ejecuta sobre un circuito virtual ATM utilizando RFC 2684 y la encapsulación SNAP de PPPoE. (PPPoEoA no es lo mismo que el Protocolo Punto a Punto sobre ATM (PPPoA), que no utiliza SNAP).

Según un documento de Cisco, "PPPoEoE es una variante de PPPoE en la que el protocolo de transporte de capa 2 es Ethernet o VLAN 802.1q en lugar de ATM. Este método de encapsulación se encuentra generalmente en entornos Metro Ethernet o DSLAM (multiplexor de acceso de línea de abonado digital) Ethernet. El modelo de implementación común es que este método de encapsulación se encuentra típicamente en edificios de múltiples inquilinos u hoteles. Al proporcionar Ethernet al abonado, el ancho de banda disponible es mucho más abundante y se facilita la prestación de servicios adicionales". [ 17 ]

Es posible encontrar módems DSL, como el Draytek Vigor 120, donde PPPoE se limita al enlace Ethernet entre un módem DSL y un enrutador asociado, y el ISP no utiliza PPPoE en absoluto (sino PPPoA ). [ 18 ]

Usos posteriores al DSL y algunas alternativas en estos contextos

ZTE ha patentado un método determinado para usar PPPoE junto con GPON (que implica crear una VLAN a través de OMCI ) . [ 19 ]

Según se informa, PPPoE sobre GPON es utilizado por proveedores de servicios minoristas como Internode de la Red Nacional de Banda Ancha de Australia , [ 20 ] Orange de Francia, [ 21 ] Antel de Uruguay, [ 22 ] Globe Telecom de Filipinas [ 23 ] y Aruba FTTH de Italia [ 24 ] en redes GPON públicas de OpenFiber .

El RFC 6934, "Aplicabilidad del mecanismo de control de nodo de acceso a redes de banda ancha basadas en PON", que defiende el uso del protocolo de control de nodo de acceso en PON para, entre otras cosas, autenticar el acceso de los suscriptores y gestionar sus direcciones IP, y cuyo primer autor es un empleado de Verizon, excluye PPPoE como una encapsulación aceptable para GPON: "La encapsulación del protocolo en BPON se basa en la encapsulación multiprotocolo sobre la capa de adaptación ATM 5 (AAL5), definida en [RFC2684]. Esto cubre PPP sobre Ethernet (PPPoE, definido en [RFC2516]) o IP sobre Ethernet (IPoE). La encapsulación del protocolo en GPON siempre es IPoE." [ 25 ]

El estándar 10G-PON (XG-PON) ( G.987 ) proporciona autenticación mutua 802.1X de la ONU y la OLT, además del método OMCI heredado de G.984 . [ 26 ] G.987 también agrega soporte para autenticar otros equipos en las instalaciones del cliente más allá de la ONU (por ejemplo, en una MDU), aunque esto se limita a puertos Ethernet, también manejados a través de 802.1X. (Se supone que la ONU debe snoop mensajes RADIUS encapsulados en EAP en este escenario y determinar si la autenticación fue exitosa o no). [ 27 ] Hay cierto soporte para PPPoE especificado en los estándares OMCI , pero solo en términos de que la ONU puede filtrar y agregar etiquetas VLAN para el tráfico en función de su encapsulación (y otros parámetros), lo que incluye PPPoE entre los protocolos que la ONU debe poder discernir. [ 28 ]

El documento TR-200 del Broadband Forum , "Uso de EPON en el contexto de TR-101" (2011), que también se refiere a 10G-EPON , dice: "La OLT y la ONU de múltiples suscriptores DEBEN poder realizar la función de agente intermedio PPPoE, como se especifica en la Sección 3.9.2/TR-101". [ 29 ]

Un libro sobre Ethernet en la primera milla señala que DHCP puede usarse en lugar de PPPoE para configurar un host para una sesión IP, aunque indica que DHCP no reemplaza completamente a PPPoE si también se desea cierta encapsulación (si bien los puentes VLAN pueden cumplir esta función) y que, además, DHCP no proporciona autenticación (del suscriptor), lo que sugiere que IEEE 802.1X también es necesario para una "solución completa" sin PPPoE. [ 30 ] (Este libro asume que PPPoE se aprovecha para otras características de PPP además de la encapsulación, incluyendo IPCP para la configuración del host y PAP o CHAP para la autenticación).

Existen razones de seguridad para utilizar PPPoE en un entorno de medio compartido (que no sea DSL/ATM), como las redes de comunicación por línea eléctrica , con el fin de crear túneles separados para cada cliente. [ 31 ]

PPPoE se utiliza ampliamente en líneas WAN, incluidas las FTTx . Muchos gateways residenciales FTTx proporcionados por los ISP tienen integradas las funciones de enrutamiento.

Véase también

Referencias

  1. ↑ James Boney (2005). Cisco IOS en pocas palabras . O'Reilly Media, Inc. pág. 88. ISBN  978-0-596-55311-1.
  2. 1 2 Philip Golden; Hervé Dedieu; Krista S. Jacobsen (2007). Implementación y aplicaciones de la tecnología DSL . Taylor & Francis. pág. 479. ISBN  978-1-4200-1307-8.
  3. ↑ "Cómo crear una conexión PPPoE en Windows XP" . Archivado del original el 3 de diciembre de 2013. Consultado el 11 de diciembre de 2013 .
  4. ↑ "Configuración de Linux" . www.tldp.org . Consultado el 26 de marzo de 2019 .
  5. ↑ "Conexión a Internet con PPPoE (Mac OS X v10.5 y versiones anteriores)" . Soporte técnico de Apple . Consultado el 26 de marzo de 2019 .
  6. ↑ Wind River Systems adquiere RouterWare, Inc. Findarticles.com (5 de julio de 1999). Consultado el 27 de septiembre de 2011. Archivado el 26 de mayo de 2005 en Wayback Machine .
  7. 1 2 Michael Beck (2005). Ethernet en la primera milla : El estándar IEEE 802.3ah EFM . McGraw Hill Professional. pág. 27. ISBN   978-0-07-146991-3.
  8. ↑ Richard D. Gitlin; Sailesh K. Rao; Jean-Jacques Werner; Nicholas Zervos (8 de mayo de 1990). "Método y aparato para la transmisión de banda ancha de señales digitales entre, por ejemplo, una central telefónica y las instalaciones del cliente" . Patente estadounidense 4,924,492 .
  9. ↑ "TouchWave se asocia con Telogy Networks para software de comunicaciones integradas VoIP" . Business Wire . 5 de octubre de 1998. Consultado el 16 de diciembre de 2008 .
  10. ↑ "¿Qué es el protocolo punto a punto sobre Ethernet (PPPoE)?" . TechTarget . 20 de agosto de 2025 . Consultado el 21 de enero de 2026 .
  11. 1 2 3 4 5 Mamakos, L.; Simone, D.; Wheeler, R.; Carrel, D.; Evarts, J.; Lidl, K. (febrero de 1999). "Un método para transmitir PPP sobre Ethernet (PPPoE)" . tools.ietf.org . doi : 10.17487/RFC2516 . Consultado el 26 de marzo de 2019 .
  12. 1 2 3 4 5 6 7 Dirk Van Aken, Sascha Peckelbeen Sobrecarga(s) de encapsulación en redes de acceso ADSL Archivado el 12 de abril de 2021 en Wayback Machine , junio de 2003
  13. 1 2 3 Kaycee, Manu; Gross, George; Malis, Andrew; Stephens, John; Lin, Arthur (julio de 1998). "PPP Over AAL5" . tools.ietf.org . doi : 10.17487/RFC2364 . Recuperado el 26 de marzo de 2019 .
  14. 1 2 3 4 5 6 7 Grossman, Dan; Heinanen, Juha (septiembre de 1999). "Encapsulación multiprotocolo sobre capa 5 de adaptación ATM" . herramientas.ietf.org . doi : 10.17487/RFC2684 . Consultado el 26 de marzo de 2019 .
  15. 1 2 3 "Artículo de Simon Farnsworth" . farnz.org.uk . Consultado el 26 de marzo de 2019 .
  16. ↑ Sobrecarga(s) de encapsulación en redes de acceso ADSL.
  17. 1 2 "Comprensión de la agregación de acceso de banda ancha" (PDF) . Cisco Systems . 2 de mayo de 2005.
  18. ↑ "Vigor120 - DrayTek Corp" . Archivado del original el 23 de febrero de 2014. Consultado el 10 de febrero de 2014 .
  19. ↑ "Sistema de red óptica pasiva con capacidad Gigabit y método de configuración de protocolo punto a punto sobre Ethernet implementado mediante el mismo" . google.com . Consultado el 26 de marzo de 2019 .
  20. ↑ "Internode :: Soporte :: Guías :: Acceso a Internet :: NBN :: FTTP" . www.internode.on.net . Archivado del original el 13 de septiembre de 2013.     
  21. ↑ "¡La nueva comunidad de TP-Link se ha lanzado oficialmente! - Comunidad de TP-Link" . community.tp-link.com . Archivado del original el 26 de marzo de 2019. Consultado el 26 de marzo de 2019 .
  22. ↑ «Introducción Básica a Wi-Fi» . Antel (en español). Antel.
  23. ↑ "YouTube" . www.youtube.com . Archivado del original el 8 de junio de 2014. Consultado el 26 de marzo de 2019 .
  24. ↑ «Configuración del router y módem ADSL | Guía Aruba» . guía.aruba.it . Consultado el 10 de marzo de 2022 .
  25. ↑ Bitar, Nabil N.; Wadhwa, Sanjay; Haag, Thomas; Hongyu, Li (junio de 2013). "RFC 6934 - Aplicabilidad del mecanismo de control del nodo de acceso a redes de banda ancha basadas en redes ópticas pasivas (PON)" . datatracker.ietf.org . Consultado el 26 de marzo de 2019 .
  26. ↑ Dave Hood y Elmar Trojer (2012). Redes ópticas pasivas con capacidad Gigabit . John Wiley & Sons. pág. 200. ISBN  978-1-118-15558-5.
  27. ↑ Dave Hood y Elmar Trojer (2012). Redes ópticas pasivas con capacidad Gigabit . John Wiley & Sons. págs. 207 y 274-275. ISBN  978-1-118-15558-5.
  28. ↑ Dave Hood y Elmar Trojer (2012). Redes ópticas pasivas con capacidad Gigabit . John Wiley & Sons. págs. 261 y 271. ISBN  978-1-118-15558-5.
  29. ↑ "Recursos publicados por el Foro de Banda Ancha - Recursos - Wiki del BBF" (PDF) . www.broadband-forum.org . Consultado el 31 de marzo de 2025 .
  30. ↑ Michael Beck (2005). Ethernet en la primera milla : El estándar IEEE 802.3ah EFM . McGraw Hill Professional. pág. 241. ISBN   978-0-07-146991-3.
  31. ↑ Xavier Carcelle (2009). Comunicaciones por línea eléctrica en la práctica . Artech House. pág. 235. ISBN  978-1-59693-336-1.
  • RFC 2516 - Un método para transmitir PPP sobre Ethernet (PPPoE) 
  • RFC 3817 - Protocolo de tunelización de capa 2 (L2TP) Retransmisión de descubrimiento activo para PPP sobre Ethernet (PPPoE) 
  • RFC 4638 - Admisión de una Unidad Máxima de Tránsito/Unidad Máxima de Recepción (MTU/MRU) mayor que 1492 en el Protocolo Punto a Punto sobre Ethernet (PPPoE) 
  • RFC 4938 - Extensiones de PPP sobre Ethernet (PPPoE) para el flujo de crédito y las métricas de enlace 
  • Patente estadounidense 6891825 - Método y sistema para proporcionar acceso multiusuario a una red de conmutación de paquetes.
  • TR-043 - Protocolos en la interfaz U para el acceso a redes de datos mediante ATM/DSL, Edición 1.0, agosto de 2001

Obtenido de " https://en.wikipedia.org/w/index.php?title=Point-to-Point_Protocol_over_Ethernet&oldid=1352424453 "