Resumen

  • RFC 3186 convirtió tramas PPP en tramas MAPOS mediante una reescritura mínima en los bordes y restauró los octetos originales al salir, creando una interfaz punto a punto sin una cabecera adicional.
  • El servicio dependía de un par de direcciones, dos cambios de modo, estabilidad en ambos sentidos e aislamiento interno. La fila de inventario era evidencia administrativa, no evidencia de entrega.

El documento apareció en diciembre de 2001 como Informational. La nota del IESG aclaró que no era producto de un grupo de trabajo ni documento de Standards Track. Tampoco garantizaba la revisión amplia asociada a ese proceso. Su arquitectura y su ensayo de referencia son hechos históricos; no prueban despliegue universal.

La idea nacía de la similitud entre las cabeceras. En PPP sobre SONET/SDH, los primeros valores eran fijos. MAPOS usaba esa posición para un destino interno. El conmutador de entrada sustituía uno o dos octetos por la dirección del puerto remoto, el tejido encaminaba la trama y el conmutador de salida recuperaba los valores PPP.

Para el CPE no había una encapsulación nueva. Sin embargo, el estado necesario seguía allí: destino de reescritura, modo de puerto, etiqueta de señal, ruta, correspondencia de direcciones y regla de aislamiento. La transparencia reducía lo que el cliente debía conocer; no reducía automáticamente lo que el operador debía demostrar.

Cambiar al modo túnel implicaba desactivar NSP y SSP en el puerto del cliente, desactivar broadcast y multicast MAPOS, ajustar C2 según el scrambling y habilitar la reescritura. Volver al modo nativo revertía el conjunto. Una sola etiqueta en la consola podía ocultar varios actos ejecutables y varios puntos de fallo.

Después venía el establecimiento. El operador elegía un par MAPOS no usado y configuraba ambos bordes. Solo cuando las rutas y el reenvío eran estables en los dos sentidos debía levantar el enlace hacia los clientes. Desde entonces, los controles PPP LCP podían cruzar de manera transparente.

El par de direcciones identificaba la intención del camino. No demostraba por sí solo que ambos puertos estuvieran en el modo correcto, que el reenvío fuera bidireccional o que una trama concreta hubiera llegado. Por eso la base OAM era útil para evitar duplicados sin convertirse en la fuente ejecutiva del forwarding.

La retirada del camino repetía la división. Primero había que desactivar puertos; luego podía actualizarse la base; más tarde podían restaurarse valores MAPOS. Las tramas que llegaran tras desactivar el destino se descartaban en silencio. El silencio no era una explicación ni un recibo para el emisor.

Las alarmas tampoco tenían la misma vista. Una rotura óptica cercana aparecía en el CPE y el conmutador locales. El extremo remoto seguía físicamente arriba porque la alarma SONET/SDH terminaba en el borde. Allí el fallo emergía cuando expiraban los Echo LCP: enlace arriba, protocolo abajo.

Ese timeout mostraba una falta de respuesta dentro de un plazo. No decía qué tramo falló, si la pérdida era unidireccional o qué hizo la aplicación. El SSP interior podía recalcular la topología al mismo tiempo que el cliente solo veía la ausencia del eco.

El aspecto de circuito privado tampoco reservaba capacidad. MAPOS carecía de QoS en el protocolo y POS no aportaba control de flujo. RFC 3186 reconocía la dificultad de garantizar throughput, exigía capacidad suficiente entre conmutadores y aconsejaba equidad por puerto cuando había sobreventa.

El ensayo de latencia fue específico: OC12c unidireccional al 30 %, equipos y versiones nombrados, parámetros de framing fijados y veinticinco pruebas de 150 segundos por tamaño. El conmutador estudiado obtuvo menos latencia que el router comparado. Esa medición no cubrió toda carga, congestión, pérdida, fabricante ni resultado de usuario.

En seguridad, el texto afirmaba que el CPE no controlaba el interior y difícilmente inyectaría otro flujo. Pero también calificaba el aislamiento por camino como esencial, advertía sobre caminos duplicados y desaconsejaba mezclar modo nativo y túnel hasta que todos los switches aislaran correctamente.

Las tramas MAPOS no incluían dirección de origen. Esa ausencia hacía más difícil separar caminos en un entorno mixto. Que el cliente no viera el interior no significaba que el interior supiera siempre a quién pertenecía cada trama.

La enseñanza de RFC 3186 no es desconfiar de toda abstracción. Es exigir pruebas en la capa donde ocurre cada hecho. La orden de servicio, el par de direcciones, las transiciones de puerto, la estabilidad por sentido, la fila OAM, el aislamiento, los keepalives y la entrega son objetos distintos. Una interfaz transparente puede ser honesta y aun así insuficiente para explicar su propio funcionamiento.