Arpanet

MIT 18.996: Temas sobre informática teórica: problemas de investigación en Internet
Clase 2 – 13 de Febrero, 2002
Profesor: Ravi Sundaram
Primavera de 2002
Copistas: Zeeshan Syed, Asfandyar Qureshi
2.1 Historia
El precursor de Internet fue un experimento académico que se llevó a cabo en los años
60. Fundada por la Defence Advanced Research Projects Agency (DARPA), la propuesta
para ARPANET fue publicada en primer lugar por Lawrence G. Roberts en 19661. Influido
por su relación con Leonard Kleinrock de MIT2, Roberts se imaginó ARPANET como una
red de área amplia para la transmisión de la información en forma de paquetes. Una labor
basada en ideas similares se había desarrollado en paralelo en la compañía RAND y en
NPL y algunos de sus estándares fueron adoptados por DARPA.
A finales de 1969, cuatro ordenadores host se conectaron conjuntamente a la inicial red
ARPANET y la prometedora red Internet se puso en marcha. Uno por uno, los
ordenadores de UCLA (conectados en septiembre), el Standford Research Institute (SRI,
en octubre), la University of California, Santa Barbara (en noviembre) y por último la
University of Utah (en diciembre) entraron en línea, todos ellos comunicados por
conexiones de 56 Kbps. El 29 de octubre, Charley Kline de UCLA, envió los primeros
paquetes cuando intentó entrar en SRI. Este primer intento provocó un bloqueo del
sistema al introducir la letra G de LOGIN (registro).
No obstante, durante los años siguientes, se conectaron rápidamente más ordenadores a
ARPANET. En 1970, el Network Working Group3 publicó el primer protocolo host a host
llamado Network Control Protocol (NCP) (Protocolo de control de capa de red). Más tarde
en ese mismo año, se añadieron las primeras conexiones a través del país, entre UCLA,
RAND y MIT. En 1973 la red ARPANET se expandió a nivel internacional con conexiones
al University College de Londres, Inglaterra y al Royal Radar Establishment de Noruega.
En Marzo de 1972, Ray Tomlinson de BBN creó el software básico para lectura y envío de
mensajes por correo electrónico, impulsado por la necesidad de los programadores de
ARPANET de hacerse con un mecanismo de sencilla coordinación. El email pronto pasó a
ser la aplicación más de moda por más de una década. La red ARPANET se convirtió en
una oficina de correos digital de
1
G. Roberts, MIT: “Towards a Cooperative Network of Time-Shared Computers”, 1966
2
Leonard Kleinrock, MIT: “Information Flow in Large Communication Nets”, Mayo, 1961.
3
C.S. Carr, S. Crocker, V.G. Cerf, “Host-Host Communication Protocol in the ARPA Network,” en las actas de
AFIPS de SJCC.
Figura 2.1. ARPANET 1971
alta velocidad que la gente utilizaba para colaborar en proyectos de investigación y tratar
temas de diversos intereses. Sin embargo, el rápido crecimiento de ARPANET creó la
necesidad de un software más completo y de protocolos que controlaran una complejidad
cada vez mayor. En concreto, NCP confiaba en que ARPANET proporcionara una
fiabilidad completa. Si algún paquete se perdía, el protocolo (y supuestamente cualquier
aplicación que éste soportara) se estancarían. La colaboración entre Robert Kahn (de
DARPA) y Vinton Cerf (de Standford) nos condujo hasta los protocolos actuales. En 19784
publicaron la especificación del Transmission Control Protocol (TCP) (Protocolo de control
de transmisión) y el Internet Protocol (IP) (Protocolo de Internet). Los dos protocolos a la
vez facilitaron los medios para transmitir paquetes de forma segura a cualquier host de la
red.
En 1982 ARPANET se había dividido en MILNET (la parte militar) y en lo que más tarde
llegaría a ser Internet. Por esa época, a comienzos de los 80, surgieron redes tales como
USENET, BITNET, CSNET y un host de otras. Exceptuando a BITNET y USENET, estas
primeras redes (incluyendo a ARPANET) estaban destinadas a ser construidas con un
objetivo y restringidas en gran medida a grupos limitados de estudiosos. Los acuerdos
entre DARPA y los demás a principios de la década permitieron la interconexión de
algunas de estas redes.
A principios de los 80, la National Science Foundation (NSF) anunció abiertamente su
intención de atender a la comunidad universitaria al completo. Como resultado de su
financiación, en 1986 surgió NSFNET – esto más tarde constituiría el pilar de las
comunicaciones de la primera Internet. La NSF también fundó enormes centros
informáticos – en Princeton, Cornell, Pittsburgh, UIUC y UCSD – para suministrar a cada
uno un alto poder informático. Esto provocó un aumento de conexiones, sobre todo desde
las universidades. De hecho, aunque en 1986 existían algo más de 5.000 hosts en
Internet, este número aumentaría a más de 28.000 durante el año siguiente. Sin embargo,
el NSF había prohibido el uso del pilar NSFNET, el segmento a escala nacional de la
NSFNET, para propósitos que “no apoyasen la educación y la investigación”.
El 2 de noviembre de 1988, se soltó en la red un gusano que afectó a casi 6.000 de los
60.000 ordenadores que se encontraban en línea. Finalmente aniquilado y erradicado por
investigadores de Berkeley y MIT, el gusano dejó al descubierto algunos agujeros de
4
V. G. Cerf y R. E. Kahn, “A protocol for packet network interconnection”, IEEE Trans. Comm. Tech., vol.
COM-22, V 5, págs. 627-641, mayo de 1974.
seguridad graves en la creciente red. Como respuesta a las necesidades mostradas
durante este incidente, DARPA creó el Computer Emergency Response Team (CERT).
Figura 2.2. ARPANET 1980
En 1978, había menos de 200 ordenadores en línea. En 1989, eran muchos más de
100.000. Esto quería decir que tener una sencilla tabla con todos los hosts no era ya
viable, y Mockapetris de USC/ISI inventó el Domain Name System (Sistema de nombre de
dominio) (DNS) en el año 1984. El DNS permitió un mecanismo distribuido escalable para
resolver la jerarquía de los nombres de los hosts (ej. www.akamai.com) en una dirección
de Internet.
El aumento del tamaño de Internet también desafió las capacidades de los enrutadores y
originó problemas de congestión de ancho de banda que los protocolos TCP/IP no habían
tenido en cuenta. En 1989, TCP había sido revisado para facilitar el control de la
congestión y evitar así el colapso de la red. Los enrutadores se modificaron también para
controlar una complejidad que iba en aumento. Al principio, existía un único algoritmo
distribuido para el enrutamiento, que fue implementado uniformemente por todos los
enrutadores de Internet. Cuando el número de redes en Internet se disparó, este diseño
inicial no pudo extenderse como se requería, así que se reemplazó por un modelo de
enrutamiento jerárquico, con un protocolo llamado Interior Gateway Protocol (IGP)
utilizado dentro de cada zona de Internet, y un Exterior Gateway Protocol (EGP) para unir
todas las zonas.
En 1990, ARPANET, feliz víctima de su inesperado e imprevisto éxito, fue desmantelada,
dejando una amplia red de redes conocida como Internet. El número de hosts superó esta
vez los 300.000. Sin embargo, incluso en 1990, el tráfico comercial estaba todavía
prohibido en el eje de NSFNET. Durante este tiempo, existía un auténtico miedo entre los
investigadores de que Internet se colapsase bajo su propio peso y por tanto se mostraba
reticencia a aumentar el tráfico en ella. Finalmente, en 1991 se levantó la veda comercial
y ello condujo al desarrollo de un gran número de aplicaciones de Internet.
En la University of Minnesota, un equipo dirigido por un programador informático, Mark
MaCahill, dio a conocer “gopher” en 1991, el primer modo point-and-click de navegar por
los archivos de Internet. Diseñado en un principio para facilitar las comunicaciones en el
campus, gopher se distribuyó de forma gratuita en Internet. MaCahill lo llamó “la primera
aplicación de Internet que hasta mamá puede usar”. 1991 fue también el año en el que
Tim Berners-Lee, que trabajaba para CERN en Suiza, hizo público el primer código
informático del World Wide Web en “alt.hypertext”, un grupo de noticias relativamente
inofensivo. Marc Andreesen y un grupo de estudiantes programadores del NCSA (el
National Center for Supercomputing Applications situado en el campus de la University of
Illinois en Urbana Champaign) crearían finalmente un navegador gráfico para el World
Wide Web llamado Mosaic. Andreesen continuaría hasta fundar Netscape.
Finalmente, el gobierno comenzó a apartarse del mantenimiento de Internet. En mayo de
1993, tuvo lugar la última solicitud a NSFNET para obtener puntos de acceso privados a
la red (Network Access Points) (NAPs). Ese mismo año, NFS creó InterNIC para facilitar
servicios específicos de Internet, como los relacionados con el registro y las bases de
datos del host. Por tanto, al final, la gestión de Internet se trasladó hacia el dominio
público con una supervisión cada vez menor por parte del gobierno.
Sin embargo, en una entrevista con CNN en marzo de 1999, el vicepresidente Al Gore se
jactaba de haber tomado “la iniciativa de crear Internet”.
El espectacular crecimiento de Internet había acarreado la necesidad de un nuevo eje de
comunicaciones. En 1995, el eje de NSFNET se sustituyó por vBNS –servicio de alto
rendimiento desarrollado por MCI, que conectaba algunas universidades y centros de
investigación a más de 155 Mbps.
Internet está muy lejos de aquellos cuatro host que se conectaron en línea en 1969. En el
año 2002, había aproximadamente 350 millones de hosts – un número que se ha previsto
que crezca bastante. Los diseñadores iniciales de los protocolos y de la arquitectura que
conforman Internet no tuvieron en cuenta la multitud de cuestiones que surgen del nivel
actual de complejidad: el enrutamiento no es del todo óptimo, las conexiones y los hosts
son poco fiables, no hay seguridad intrínseca, no hay directorio ni índice y el espacio para
las direcciones es diminuto.
La naturaleza descentralizada de Internet trae consigo muchos desafíos y oportunidades.
Durante este tiempo, mucha gente ha intentado retocar la arquitectura original para poder
controlar nuevas situaciones, pero como es de esperar, actualmente Internet no
proporciona un rendimiento óptimo5.
2.2 Protocolos de Internet
2.2.1
Capas de redes
Desarrollar software para redes es una tarea complicada debido al afinado número de
diferentes servicios subyacentes que deben facilitarse. Entre estos se encuentran el envío
de bits a través de varios medios de transmisión, datos de enrutamiento entre máquinas
de redes distintas, facilitar la detección del error, la corrección y una conectividad de
confianza, regular el flujo y la definición de formatos para la aplicación. La mayoría de
estas funciones son en gran medida independientes de la red y son lo suficientemente
genéricas para que se normalicen. Como consecuencia, y para reducir la complejidad del
diseño, las redes se disponen como una serie de capas o niveles, construidas unas sobre
otras. El número exacto, los nombres, contenidos y funciones de cada capa puede variar
de red a red, pero su propósito es ofrecer ciertos servicios a las capas más altas,
5
Esta sección está basada principalmente en las dos fuentes siguientes: [1] Barry M. Leiner, Vinton
G. Cerf, David D. Clark, Robert E. Kahn, Leonard Kleinrock, Daniel C. Lynch, Jon Postel, Larry G.
Roberts, Stephen Wolff, “A Brief History of the Internet” y [2] Robert H. Zakon, “Hobbes’ Internet
Timeline”, http://www.zakon.org/robert/internet/timeline
protegiéndolas de detalles sobre cómo se han implementado en realidad los servicios
ofrecidos. De este modo, las capas implementan abstracciones y ofrecen a las
aplicaciones construidas por encima de ellas una serie de servicios bien definidos.
Figura 2.3. Ejemplo de un paquete con cabeceras y colas
Cada capa de una red añade por regla general, información adicional al paquete que ésta
recibe de la capa que se encuentra justo encima de ella (como se muestra en la figura
2.3). Esto está pensado para que lo interprete únicamente la correspondiente capa que se
encuentra en el otro extremo. Se denomina cabecera cuando se añade al principio del
paquete y cola cuando se pega al final. La parte de los datos que pertenece a la capa
justo de encima se conoce con el nombre de payload. Las colas y cabeceras contienen
normalmente información de control como tamaños, tiempos y otros campos de este tipo.
Pueden contener también números de secuencia (para permitir que la capa
correspondiente de la máquina destino entregue los mensajes en un orden adecuado si
las capas inferiores no mantienen la secuencia). Todo esto hace que el tamaño de un
paquete típico tenga un límite de entre 46 y 1500 bytes.
Las entidades que constan de las correspondientes capas en máquinas distintas se
llaman peers. Las reglas y convenciones que se utilizan para la comunicación entre éstas
son conocidas como protocolos. Dicho de otro modo, un protocolo es fundamentalmente
un acuerdo entre las partes comunicantes sobre cómo debería transcurrir la comunicación
(mediante la especificación y el formato de los mensajes enviados entre los pares
iguales).
La arquitectura de capa de redes se verá más detalladamente en el Apéndice A.
2.2.2
Argumento end-to-end (Chequeo de punta a cabo)
El principio, llamado argumento end-to-end, indica que las funciones situadas en los
niveles bajos de un sistema pueden resultar superfluas o de poco valor si se comparan
con el coste que supone proporcionarlas en ese nivel bajo. La idea clave de este
argumento es que una aplicación conoce mejor cuáles son sus verdaderos requisitos
comunicativos y que una capa más baja trate de implementar cualquier característica al
otro lado transportando como mínimo los datos, pone en peligro algo que no es
exactamente lo que se requiere, en cuyo caso, la aplicación terminará volviendo a
implementar esa función de un modo distinto que sea más útil.
El argumento se explicará más detalladamente en otra parte6
2.2.3
6
Protocolos contemporáneos
J.H. Saltzer, D.P. Reed y D.D. Clark. “End-to-End Arguments in System Design”, MIT-LCS
En esta sección se verán brevemente algunos de los protocolos usados con más
frecuencia. Puede encontrar una descripción más exhaustiva de cada uno de ellos en el
documento RFC (Request For Comment) (Petición de comentarios) que se asocia con
cada protocolo7
2.2.3.1
Protocolo de Internet (IP)
Este protocolo proporciona todos los servicios de transporte de datos de Internet, con
todos los demás protocolos puestos finalmente en capas sobre IP o usados para apoyar a
IP desde abajo.
IP es el protocolo más básico de Internet. El único requisito de un segmento de red para
poder funcionar en una red TCP/IP es enviar paquetes IP. De hecho, una red TCP/IP se
puede definir como un medio de comunicación que puede transportar paquetes IP. Casi
todas las demás funciones TCP/IP se construyen superponiendo capas sobre IP.
IP es un protocolo de datagrama que trata cada paquete por separado. Esto significa que
cada paquete debe contener toda la información relativa a las direcciones. Además, IP no
hace ningún intento por determinar si los paquetes llegan a su destino o por tomar las
medidas adecuadas si no es así. IP únicamente contiene la suma de verificación de la
cabecera, los contenidos del paquete no se validan de este modo.
IP proporciona varios servicios:
• Direccionamiento: las cabeceras IP contienen direcciones de 32 bits que
identifican a los hosts remitentes y destinatarios. Los enrutadores intermedios
utilizan estas direcciones para seleccionar una ruta para el paquete a través de la
red.
• Fragmentación: los paquetes IP pueden estar divididos o fragmentados en
paquetes pequeños. Esto permite que un paquete grande viaje por una red que
sólo puede manejar paquetes más pequeños. IP fragmenta y vuelve a armar los
paquetes.
• Timeout (tiempo de espera) del paquete: Cada paquete IP contiene un campo de
tiempo de vida (TTL) que disminuye cada vez que un enrutador maneja el
paquete. Si el TTL llega a cero, el paquete se descarta, impidiendo así que los
paquetes permanezcan en un bucle infinito y que colapsen la red. Este tiempo se
fija por lo general a 30 al principio.
• Tipo de servicio: IP soporta la priorización del tráfico al permitir que los paquetes
sean etiquetados con un tipo de servicio abstracto. Esto casi nunca se utiliza.
• Opciones: IP proporciona varios elementos opcionales, permitiendo que el
remitente de un paquete establezca los requisitos sobre la ruta que éste toma a
través de la red (enrutamiento fuente), que encuentre la ruta que el paquete toma
(grabación de la ruta) y que etiquete los paquetes con elementos de seguridad.
2.2.3.2 Protocolo de control de mensajes de Internet (ICMP)
Este es un protocolo necesario estrictamente integrado con IP. Los mensajes ICMP, que
se entregan en paquetes IP, se utilizan para mensajes out-of-band relacionados con una
operación o fallo en la red. Por supuesto, dado que ICMP utiliza IP, la entrega de un
paquete ICMP es poco fiable, así que los hosts no pueden contar con recibir paquetes
ICMP por cualquier problema en la red. Algunas de las funciones de ICMP son:
7
Los RFCs pertinentes pueden encontrarse en: www.ietf.org, www.w3.org y www.freesoft.org
•
•
•
•
Notificación de error: los errores en la red se anuncian, como cuando no se puede
acceder a un host o una parte completa de la red debido a algún tipo de fallo. Un
paquete TCP o UDP dirigido a un número de puerto sin destinatario adjunto
también se presenta mediante ICMP.
Notificación de congestión: cuando un enrutador empieza a acumular en el búfer
demasiados paquetes por no ser capaz de transmitirlos tan rápidamente como
éstos se reciben, éste generará mensajes ICMP de disminución del tráfico desde
el origen. Dirigidos al remitente, estos mensajes deberían hacer que se
disminuyera la velocidad de transmisión del paquete. Por supuesto, generar
demasiados mensajes de este tipo provocaría aún más congestión en la red, de
modo que se utilizan con moderación.
Notificación del tiempo de espera: si el campo TTL de un paquete IP baja a cero,
el enrutador, deshaciéndose del paquete, normalmente generará un paquete
ICMP en el que se notifique este hecho. TraceRoute es una herramienta que traza
rutas en la red enviando paquetes con valores TTL pequeños y vigilando las
mensajes ICMP de tiempo de espera.
Ayuda para la resolución de problemas: ICMP admite una función Eco, que
simplemente envía un paquete entre dos hosts en un viaje de ida y vuelta. Ping,
que es una herramienta común de gestión de red, está basado en esta
característica. Ping transmitirá una serie de paquetes, midiendo el promedio de
veces que se hace un viaje de ida y vuelta y calculando los porcentajes de
pérdidas.
2.2.3.3 Protocolo de control de transmisión (TCP)
Este protocolo está pensado en gran medida para compensar las deficiencias de IP,
proporcionando conexiones de secuencias fiables que oculten la mayoría de los defectos
de IP. El conjunto TCP/IP recibe este nombre porque la mayoría de dichos protocolos
están basados en TCP, que está a su vez implementado sobre IP.
TCP añade gran funcionalidad al servicio IP sobre el que se encuentra superpuesto:
• Flujos: los datos de TCP están organizados como un flujo de bytes, muy similar a
un fichero. El carácter de datagrama de la red está oculto. Existe un mecanismo
(el puntero urgente) que permite que los datos out-of-band sean marcados
expresamente.
• Entrega fiable: los números secuenciales se utilizan para coordinar cuáles son los
datos que se transmiten y reciben. TCP planeará una retransmisión si determina
que los datos se han perdido.
• Adaptación a la red: TCP asimilará dinámicamente las características del retraso
de una red y regulará su funcionamiento para maximizar el rendimiento sin
sobrecargar la red.
• Control de flujo: TCP controla los búfers de datos y coordina el tráfico, de forma
que sus búfers no se excederán. Los remitentes rápidos serán detenidos de vez
en cuando para que puedan seguir el ritmo de los destinatarios más lentos.
Sea cual sea la aplicación en concreto, TCP funciona casi siempre como transmisión fullduplex. Los algoritmos descritos a continuación funcionan en ambas direcciones, de un
modo casi completamente independiente. Algunas veces es útil pensar en una sesión
TCP como dos flujos de bytes por separado que viajan en direcciones opuestas. No existe
ningún mecanismo en TCP que asocie los datos de los flujos de bytes enviados con los
que viajan en sentido inverso. TCP muestra un comportamiento asimétrico (es decir,
transferencia de datos hacia delante pero no al revés), sólo durante el inicio de conexión y
las secuencias de cierre o viceversa.
TCP utiliza un número de secuencia de 32 bits que cuenta los bytes del flujo de datos.
Cada paquete TCP contiene el número de secuencia inicial de los datos de ese paquete y
el número de secuencia (llamado número de reconocimiento) del último byte recibido
desde el par remoto. Con esta información, se implementa un protocolo de ventana
deslizante. Los números de secuencia que van hacia delante y que vuelven hacia atrás
son completamente independientes y cada par TCP debe controlar tanto su propio
número de secuencia como el número que el par remoto está usando.
TCP utiliza un número de indicativos de control para controlar la conexión. Algunos de
estos indicativos están relacionados con un único paquete, como el indicativo URG, que
señala los datos válidos del campo Puntero urgente. Sin embargo, existen dos indicativos,
SYN y FIN, que requieren una entrega fiable ya que marcan el comienzo y el fin del flujo
de datos. Para asegurar la entrega fiable de estos dos indicativos, se les asignan
posiciones dentro del espacio número de secuencia. Cada indicativo ocupa un único byte.
Cada punto final de una conexión TCP tendrá un búfer para almacenar los datos que se
transmiten por la red antes de que la aplicación esté lista para leer esos datos. Esto
permite que la transferencia de red ocurra mientras las aplicaciones están activas con otro
procesamiento, mejorando el rendimiento global.
Para evitar que la memoria intermedia se sature, TCP coloca un campo de Tamaño de
ventana en cada paquete que transmite. Este campo contiene la cantidad de datos que
pueden transmitirse al búfer o memoria intermedia. Si este número desciende a cero, el
TCP remoto no puede enviar más datos. Debe esperar hasta que el espacio del búfer esté
disponible y reciba un paquete que anuncie que el valor del campo de tamaño de ventana
no es cero.
En algunas ocasiones, el espacio del búfer es demasiado pequeño. Esto sucede cuando
el producto ancho de banda-retraso de la red sobrepasa el tamaño del búfer. La solución
más sencilla consiste en aumentar la memoria intermedia, pero en casos extremos, el
mismo protocolo se convierte en un obstáculo (porque no posee un tamaño de ventana
suficientemente grande). Bajo estas condiciones, se califica a la red como una LFN (Long
Fat Network (red de larga distancia de banda ancha) – pronunciada como "elefante" en
inglés). RFC 1072 habla de las redes LFN.
Cuando un host transmite un paquete TCP a su igual, éste debe esperar un periodo de
tiempo para obtener confirmación. Si la respuesta no llega dentro del tiempo esperado, se
asume que el paquete se ha perdido y se vuelven a transmitir los datos. La pregunta
lógica - ¿cuánto tiempo debemos esperar? – no tiene una respuesta simple. Por cable
Ethernet, se necesitarían tan sólo unos pocos microsegundos para obtener una
respuesta. Si el tráfico debe fluir por la red Internet de área amplia, uno o dos segundos
podrían ser razonables durante periodos de máxima utilización. Si nos estamos
comunicando con un paquete de instrumentación de un satélite, que va a toda velocidad
hacia Marte, podrían necesitarse unos minutos antes de obtener una respuesta. No existe
respuesta para la pregunta ¿cuánto tiempo?
Todas las implementaciones TCP modernas tratan de responder a esta cuestión
controlando el intercambio normal de paquetes de datos y realizando un cálculo del
tiempo que representa “demasiado tiempo”. Este proceso se conoce como cálculo de
Round-Trip Time (RTT) (Tiempo de viaje completo). Los cálculos de RTT constituyen uno
de los parámetros de rendimiento más importantes en un intercambio TCP, especialmente
cuando se piensa que en una transferencia importante de tiempo indefinido, todas las
implementaciones TCP al final lanzan paquetes y los retransmiten, sin importar la buena
calidad de la conexión. Si el cálculo de RTT es demasiado bajo, los paquetes se
retransmiten innecesariamente; si éste es demasiado alto, la conexión puede quedarse
parada mientras el host permanece en tiempo de espera.
2.2.3.4 Protocolo de datagrama de usuario (UDP)
Este protocolo facilita el acceso de los usuarios a los servicios IP. La entrega de
paquetes UDP es similar a la de paquetes IP – datagramas sin conexión que pueden ser
desechados antes de alcanzar su objetivo. UDP es útil cuando TCP resulta demasiado
complejo, demasiado lento o simplemente innecesario.
UDP proporciona algunas funciones más que IP:
• Números de puerto: UDP proporciona números de puerto de 16 bits para permitir
que múltiples procesos utilicen servicios UDP en el mismo host. Una dirección
UDP es la combinación de una dirección IP de 32 bits y el número de puerto de 16
bits.
• Suma de verificación: A diferencia de IP, UDP verifica la suma de sus datos,
asegurando la integridad de los mismos. Un paquete que falle en la suma de
verificación simplemente se descarta y no lleva a cabo ninguna otra acción.
2.2.3.5 Protocolo simple de transferencia de correo (SMTP)
Éste es el protocolo estándar de Internet para la transferencia de correo electrónico host a
host (entre sistemas) y actúa tradicionalmente sobre el puerto TCP 25. Es decir, un
usuario de UNIX puede escribir telnet y a continuación el nombre del host 25 y conectar
con un servidor SMTP, si hay uno presente.
SMTP usa un tipo de protocolo asimétrico de petición-respuesta, de moda a comienzos de
los 80, que aún se ve ocasionalmente, la mayoría de las veces en protocolos de correo. El
protocolo está diseñado para ser tan útil para el ordenador como para el hombre, aunque
no muestra demasiada compasión con el hombre. Desde el punto de vista del servidor, en
el documento RFC se facilita una lista clara de comandos bien documentados. Para el
hombre, todos los comandos finalizan claramente en saltos de línea y aparecen
enumerados bajo el comando HELP. Desde el punto de vista del remitente, las respuestas
al comando adoptan siempre la forma de líneas de texto, que comienzan cada una por un
código de tres dígitos que identifica el resultado de la operación, un carácter de
continuación para indicar las otras líneas que siguen y además, información textual
arbitraria con carácter informativo para el hombre.
Si la entrega de correo falla, sendmail (la implementación SMTP más importante) pondrá
los mensajes de correo en cola y volverá a intentar la entrega más tarde. Sin embargo, se
usa un algoritmo de backoff, no hay ningún mecanismo para enviar todos los elementos
hosts de Internet por mail, SMTP no facilita ningún servicio de buzón de correo o cualquier
elemento especial aparte de la transferencia de correo electrónico. Por estas razones,
SMTP no es una buena elección para los hosts que están situados detrás de líneas
sumamente inciertas (como los módems). Se puede designar a un host con mejor
conexión, como un DNS encargado del intercambio de correo, además de organizar un
plan de transmisión. Actualmente, se pueden utilizar dos configuraciones fundamentales.
Una consiste en configurar los buzones de correo POP y un servidor POP en el host de
intercambio y en permitir que todos los usuarios usen clientes de correo POP. La otra
posibilidad se centra en fijar una transferencia de correo SMTP periódica desde el host de
intercambio a otro host local de intercambio SMTP que haya estado poniendo en cola
todo el correo saliente. Por supuesto, esta conexión queda descartada ya que no permite
un pleno acceso a Internet.
2.2.3.6 Protocolo simple de gestión de red (SNMP)
Este es básicamente un protocolo de petición-respuesta que se ejecuta sobre UDP (en los
puertos 161 y 162), aunque la operación TCP es posible. SNMP es un protocolo
asimétrico, que opera entre una estación de gestión (inteligente) y un agente (silencioso).
El agente es el dispositivo que se gestiona – su software tiene que implementar algunos
tipos de paquetes simples y una función genérica get o set sobre sus variables de MIB. La
estación de gestión presenta la interfaz del usuario. Las estaciones de gestión simples
pueden construirse con los servicios de la línea comandos UNIX. Otros más complejos (y
caros) recopilan datos del módulo MIB durante el tiempo y utilizan las GUI para trazar
mapas de red.
Una operación SNMP adopta la forma de Unidad de datos de protocolo (PDU), que es
básicamente una palabra elegante para referirse a un paquete. La versión 1 de SNMP
admite cinco posibles PDU:
• GetRequest/SetRequest proporciona una lista de objetos y, posiblemente, valores
que deben establecerse en (SetRequest). En cualquiera de los dos casos, el
agente devuelve una respuesta GetResponse.
• GetResponse informa a la estación de administración sobre los resultados de una
GetRequest o SetRequest devolviendo una indicación de error y una lista de las
obligaciones de los valores y variables.
• GetNextRequest se utiliza para realizar una transversal de la tabla y en otros
casos en los que la estación de administración no conoce el nombre exacto MIB
del objeto que solicita. GetNextRequest no requiere la especificación de un
nombre exacto; si no existe un objeto con el nombre especificado, se devuelve el
siguiente objeto en el MIB. Tenga en cuenta que para admitir esta característica,
los MIB deben ser (y son) conjuntos ordenados de forma rigurosa.
• Trap es la única PDU enviada por un agente por iniciativa propia. Se utiliza para
notificar a la estación de administración sobre un evento poco común que pueda
requerir una atención especial (como un enlace que falla). En la versión 2, las
traps se nombran en el espacio del MIB. Los MIB más recientes especifican los
objetos de administración que controlan la forma en que se envían las traps.
2.2.3.7 Protocolo de transferencia de hipertexto
Funciona con conexiones TCP, normalmente en el puerto 80, que pueden ignorarse y
utilizar otro puerto. Tras una conexión correcta, el cliente transmite un mensaje de
solicitud al servidor, que envía un mensaje de respuesta. Los mensajes HTTP pueden ser
leídos por el hombre y un servidor HTTP puede funcionar manualmente con un comando
como el servidor telnet 80.
El mensaje HTTP más simple es “GET url”, al que el servidor responde enviando el
documento con dicho nombre. Si el documento no existe, el servidor probablemente
enviará un mensaje de HTML cifrado informando sobre este hecho. Este sencillo método
ofrece una reducida gestión de errores y su uso se ha descartado por el del método más
completo que se describirá a continuación.
Un mensaje completo HTTP 1.0 comienza por “GET url HTTP/1.0”. La adición del tercer
campo indica que se utilizan cabeceras completas. El cliente puede enviar entonces
campos adicionales de cabeceras (uno por línea) terminando el mensaje con una línea en
blanco. El servidor contesta de forma similar, primero con una serie de líneas de
cabecera, luego con una línea en blanco y, por último, con el documento propiamente
dicho.
A continuación se incluye una muestra de intercambio de HTTP 1.0:
GET / HTTP/1.0 >
>
< HTTP/1.0 200 OK
< Date: Wed, 18 Sep 1996 20:18:59 GMT < Server: Apache/1.0.0
< Content-type: text/html
< Content-length: 1579
< Last-modified: Mon, 22 Jul 1996 22:23:34 GMT <
< HTML document
La utilización de cabeceras completas se recomienda por varios motivos:
• La primera línea de una cabecera de servidor incluye un código de respuesta
indicando el éxito o el fallo en la operación.
• Uno de los campos de cabecera del servidor será Content-type:, que especifica el
tipo MIME que describe cómo se debe interpretar el documento.
• Si el documento ha cambiado de lugar, el servidor puede especificar su nueva
ubicación con el campo Location:, permitiendo así que el cliente pueda reintentar
de forma transparente la solicitud utilizando la nueva URL.
• Los campos Authorization: y WWW-Authenticate: permiten que los controles de
acceso se ubiquen en los documentos Web.
• El campo Referer: permite que el cliente informe al servidor sobre la URL del
documento que ha generado la solicitud, permitiendo que los servidores más
rápidos puedan rastrear a los clientes en las solicitudes.
Además de las solicitudes GET, los clientes también pueden enviar solicitudes HEAD y
POST, de las cuales, las POST son las más importantes. Las POST se utilizan en los
formularios HTML y en otras operaciones que requieren que el cliente transmita un bloque
de datos al servidor. Tras enviar la cabecera y la línea en blanco, el cliente envía los
datos. La cabecera debe contener un campo Content-Length:, que permite que el servidor
determine cuándo se han recibido todos los datos.
2.2.3.8 Protocolo de transferencia de archivos (FTP)
Se trata de uno de los protocolos de Internet más antiguos, que sigue utilizándose de
forma generalizada y que se implementa utilizando el protocolo TCP.
Los objetivos del FTP son:
• Promocionar la compartición de archivos (programas informáticos y datos).
• Apoyar el uso directo o indirecto (mediante programas) de equipos remotos.
• Proteger al usuario frente a las variaciones de los sistemas de almacenamiento de
archivos en los hosts.
• Transferir datos de forma fiable y eficiente.
Los servidores FTP se conectan al puerto 21. El FTP utiliza dos conexiones: una se utiliza
como canal de datos y la otra como canal de control. Las conexiones de datos se inician
en el servidor desde su puerto 20 hacia un puerto ubicado en el cliente e identificado con
el comando PORT. El cliente solicita los archivos utilizando comandos enviados por el
canal de control y los transmite mediante el canal de datos.
El FTP, aunque el usuario puede utilizarlo en un terminal, está diseñado
fundamentalmente para que lo utilicen los programas.
2.3 Direccionamiento
2.3.1
Direccionamiento básico
En el sistema existente, los hosts de Internet se referencian por medio de direcciones IP
ubicadas en la cabecera de los paquetes IP y se utilizan para encaminar los paquetes
hacia su destino. Están formadas por un número de 32 bits, representado con una
notación separada por puntos a.b.c.d (por ejemplo, 10.0.0.1), donde a, b, c y d son cada
uno de 1 byte.
El direccionamiento IP utiliza una direccionamiento basado en prefijos. Los prefijos
iniciales de la dirección IP pueden utilizarse para tomar decisiones generales de
enrutamiento. Por ejemplo, los primeros 16 bits pueden identificar a Akamai, los primeros
20 bits, su oficina en Boston, los primeros 26 bits, una Ethernet concreta en la oficina y los
32 bits al completo, un host particular. Además, el direccionamiento IP también admite
asignaciones por interfaz. Esto quiere decir que las direcciones IP se asignan
basándose en las interfaces, de tal forma que un host único puede tener varias
direcciones IP si cuenta con varias interfaces. Por ejemplo, un host con interfaz Ethernet e
interfaz serie podría tener una dirección IP para cada una de ellas. Dicho de otro modo,
una dirección IP no necesita hacer referencia a un host. Es más, a lo que hace referencia
es a una interfaz.
Cada dirección consta de dos partes: un número de red y un número de host. En los
albores de Internet, las fronteras de estas dos partes venían definidas únicamente por la
clase de dirección IP y este método de direccionamiento recibía el nombre de modelo de
clases. Existen cinco clases principales (de la A a la E) y a continuación nos centraremos
en las tres primeras.
2.3.1.1 Direccionamiento de clase A
Una red de clase A está representada por un 0 como primer bit. Está seguida de 7 bits de
red y 24 bits de host. Como resultado, el byte inicial oscila entre 0 y 127, llevando a un
total de 128 redes de clase A posibles (este número es, en realidad, menor, ya que
algunos de los valores no se utilizan) y 16777216 hosts por cada red de este tipo.
2.3.1.2 Direccionamiento de clase B
Una red de clase B está representada por una secuencia de 10 en los dos primeros bits. A
éstos les siguen 14 bits de red y 16 bits de host. Como resultado, el byte inicial oscila
entre 128 y 191, llevando a un total de 16384 redes de clase B posibles y 655366 hosts
por cada red de este tipo.
2.3.1.3 Direccionamiento de clase C
Una red de clase C está representada por una secuencia de 110 en los primeros tres bits.
A éstos les siguen 21 bits de red y 8 bits de host. Como resultado, el byte inicial oscila
entre 192 y 223, llevando a un total de 2097152 redes de clase C posibles y 256 hosts por
cada red de este tipo.
2.3.2
Subredes
La limitación de todos los hosts de una red a contener el mismo número de red puede
causar problemas a medida que la red crece. Por ejemplo, una empresa que comienza
con una LAN de clase C en Internet, con el tiempo, puede terminar con varias LAN, cada
una de ellas con su propio enrutador y número de red de clase C. Esto puede suponer un
problema, ya que cada vez que se instala una nueva red, el administrador del sistema
debe ponerse en contacto con InterNIC para obtener un nuevo número de red que,
posteriormente, debe anunciarse. Además, mover una máquina de una LAN a otra
requiere modificar su dirección IP y esto, a su vez, implica la modificación de los archivos
de configuración y un cambio de entorno, mientras que la otra máquina, al adoptar una
dirección IP de reciente creación, puede recibir datos que en realidad iban dirigidos a la
máquina anterior.
Con el fin de solucionar estos problemas, se introdujo el concepto de subred como
ampliación al sistema original creado a mediados de la década de 1980. Este concepto
hace referencia a la subdivisión de una red basada en clases en varias subredes (esta
definición se actualizará en las siguientes secciones para reflejar la introducción del
enrutamiento sin clases). Como resultado, la empresa mencionada anteriormente podría
comenzar con una dirección de clase B y no con una de clase C y, a medida que las
necesidades de la máquina aumentasen, podría optar por dividir su número de host de 16
bits en un número de subred de 8 bits y otro número de host de 8 bits, consiguiendo 256
LAN, cada una de ellas con 256 hosts. Este cambio no sería apreciable de forma externa,
por lo que la adjudicación de una nueva subred no requiere ponerse en contacto con
InterNIC ni modificar las bases de datos externas.
Una ventaja importante de las subredes reside en la reducción drástica del tamaño de las
tablas de enrutamiento. Esto se basa en el hecho de que cada enrutador sólo debe
realizar el seguimiento del resto de subredes y hosts locales dentro de su propia subred.
Cuando llega un paquete, todo lo que debe hacer el enrutador es ejecutar un operador
AND booleano de la dirección en la cabecera del paquete IP y en la máscara de subred
del enrutador. Ésta última es un número de 32 bits que determina cómo se divide una
dirección IP en porciones de red y de host. Por ejemplo, en una red estándar de clase B,
la máscara de subred es 255.255.0.0, ya que los dos primeros bytes son todo unos (bytes
de red) y los últimos dos bytes son todo ceros (bytes de host). En una red de subred
similar a la propuesta anteriormente, la porción de red se amplía. Más concretamente, una
máscara de subred de 255.255.255.0 dividiría el espacio de la dirección de clase B
utilizando su tercer byte, y sería necesaria para generar 256 LAN, cada una de ellas con
256 hosts. Al ejecutar un AND de la dirección IP del paquete y de la máscara de subred,
el enrutador puede deshacerse de la parte host del número y buscar el resultado en su
tabla para decidir sobre un posterior redireccionamiento si fuera necesario. Como las
máscaras de subred se utilizan bit a bit, máscaras como 255.255.240.0 (4 bits de subred y
12 bits de host) son perfectamente normales.
Un aspecto importante que no hay que olvidar es que no es posible dividir una red de
subredes en partes aisladas. Como resultado, todas las subredes son contiguas, ya que la
información de enrutamiento no puede transmitirse a entidades que no sean miembro.
Dentro de una red, todas las subredes deben poder comunicarse con el resto de subredes
sin generar tráfico que fluya por otras redes.
2.3.3
El problema de los tres osos
En teoría, en el modelo de clases presentado anteriormente, son posibles 4.000 millones
de direcciones IP diferentes. A primera vista, esto puede resultar adecuado para los 350
millones de hosts que hay actualmente en Internet. Sin embargo, la práctica de organizar
el espacio de las direcciones por clases utiliza millones de ellos. En la mayor parte de las
organizaciones, una red de clase A con 16 millones de direcciones resulta demasiado
grande y una red de clase C con 256 direcciones resulta demasiado pequeña. Una red de
clase B con 65.536 direcciones tiene el tamaño justo. Inspirada en el cuento de Ricitos de
oro y los tres osos, esta situación se conoce como el “problema de los tres osos” en la
jerga de Internet.
Como resultado, se utiliza un número cada vez mayor de redes de clase C, por lo que se
ha producido un aumento vertiginoso en el tamaño de las tablas de enrutamiento, hecho
éste que complica aún más los casos en el modelo de clases.
Finalmente, junto con los dos problemas planteados arriba, la creciente demanda de
direcciones IP también ha generado una necesidad de convertir el proceso de asignación
de direccionamiento IP a partir de un registro central. Para tratar todos estos problemas,
se introdujo el concepto de enrutamiento de interdominio sin clases.
2.3.4
Enrutamiento de interdominio sin clases
2.3.4.1 Conceptos básicos de CIDR
CIDR es un sustituto del proceso de asignación de las direcciones de clase A, B y C
(como ya se ha visto anteriormente) con un prefijo de red generalizado. En vez de estar
limitado por identificadores (o prefijos) de 8, 16 ó 24 bits, el CIDR utiliza en la actualidad
prefijos que van de 13 a 27 bits. Así, los bloques de direcciones pueden asignarse a redes
con tan sólo 32 hosts o a aquéllas que tienen más de 500.000. Con esto se consigue que
la asignación de direcciones sea mucho más precisa y se ajuste a las necesidades
concretas de una empresa.
Una dirección CIDR incluye:
• La dirección IP estándar de 32 bits.
• Información sobre la cantidad de bits que se utilizan en el prefijo de red.
Con ello se consiguen direcciones con la forma a.b.c.d/m. Por ejemplo, podemos tener
una dirección CIDR 201.14.02.48/25. En ella, “/25” indica que los primeros 25 bits se
utilizan para identificar la red única.
Como resultado de estos desarrollos, la definición de subred se ha actualizado a la
subdivisión de un bloque CIDR en varios bloques CIDR más pequeños. Es importante
mencionar en este punto que el límite del prefijo para las direcciones CIDR no está
obligado a ser mayor que el de las máscaras naturales de red. Las redes existen donde el
límite del prefijo contiene menos bits que la máscara natural de red y éstas reciben el
nombre de superredes. Por ejemplo, una red de clase C 198.32.1.0 tiene una máscara
natural de 255.255.255.0 (máscara creada por la propia definición de la red y por las
proporciones de hosts de cada clase, es decir, una clase A tiene una máscara natural de
255.0.0.0, una clase B, una de 255.255.0.0, etc.). La representación 198.32.0.0/16, por
otra parte, tiene una máscara más corta que la natural y es, en consecuencia, una
superred según nuestra definición.
2.3.4.2 Adición de enrutamiento jerárquico para minimizar las entradas de la tabla de
enrutamiento
El método CIDR (en concreto, la posibilidad de crear superredes tal y como se entienden
en la sección anterior) permite la adición de enrutamiento, que consiste en la capacidad
de fusionar varios prefijos que tengan cierto número de bits de peso en común. De forma
alternativa, la adición también puede explicarse como una situación en la que una entrada
de enrutamiento de alto nivel representa a varios enrutamientos de menor nivel en tablas
de enrutamiento globales. Como ejemplo, consideremos el caso en que ISP1 ha asignado
el bloque CIDR 204.71.0.0/16. Éste se subasignará por ISP1 a otros clientes tal y como se
muestra a continuación:
204.71.1.0/24 asignado a PequeñoCliente1 204.71.2.0/24 asignado a PequeñoCliente2
204.71.128.0/22 asignado a ClienteMedio 204.71.136.0/20 asignado a ClienteGrande.
Durante el intercambio de información con otros ISP, ISP1 sólo necesita anunciar el
prefijo único 204.71.0.0/16 y no todos y cada uno de los prefijos empleados por sus
clientes por separado.
Este método resulta ser una estructura más organizada similar a la de las redes
telefónicas. Un nodo de red de eje de alto nivel sólo analiza los bits más altos y luego
encamina el paquete al nodo del eje específico responsable. Éste, a continuación, busca
en los bits más bajos y encamina el paquete a los nodos subtendidos que son
responsables. Al aplicar esta técnica de forma recurrente, los paquetes terminan por
alcanzar su destino. En general, CIDR termina siendo una estructura nueva de Internet,
más jerárquica, en la que cada dominio obtiene sus direcciones IP de un nivel superior.
Los servicios del registro pueden asignar las direcciones a los ISP quienes, a su vez, las
subasignan a sus clientes y así sucesivamente. Además de la reducción intrínseca del
tamaño de las tablas de enrutamiento, este enfoque también consigue lograr un sistema
en el que, más que buscar asignaciones de direcciones directamente desde InterNIC,
resulta posible obtenerlas de forma descentralizada.
2.3.4.3 Regla de enrutamiento de coincidencia más específica
Encaminar a todos los destinos utilizando la técnica de direccionamiento CIDR siempre se
lleva a cabo siguiendo un proceso largo de coincidencias. Un enrutador que se ha
decidido entre dos prefijos de distinta longitud en la misma red siempre seguirá al de la
máscara más larga. Por ejemplo, un enrutador con las siguientes dos rutas en su tabla de
enrutamiento:
198.32.1.0/24 a través de la ruta 1 198.32.0.0/16 a través de la ruta 2
intentará buscar coincidencias del host 198.32.1.1 con el destino que tenga el prefijo más
largo y, en consecuencia, se enviará el tráfico por la ruta 1. Dicho de otra manera, las
redes “más específicas” (en el sentido de que son una subred del total o de un bloque
CIDR) prevalecen, ya que ofrecen más información sobre la ubicación de una red.
2.3.4.4 Problemas asociados a la adición
La adición, si no se aplica correctamente, podría conllevar la aparición de agujeros
negros. Esto tiene lugar cuando el tráfico llega y se detiene en una máquina que no
representa el destino esperado, pero en la que no es posible efectuar un reenvío. Estas
situaciones pueden darse, por ejemplo, si un cliente se conecta a un proveedor único y
tiene un espacio de dirección IP totalmente distinto. Esto podría ser el resultado de un
cambio de proveedores por parte del cliente sin haber modificado antes la dirección de
asignación. Normalmente, en estas situaciones, se anima (o se obliga) a los clientes a
que vuelvan a numerar, pero si no ocurre así, el nuevo proveedor no podrá añadir la
dirección y, además, el antiguo proveedor no podrá hacerlo de forma tan eficiente como
antes, ya que se habrá creado un agujero negro en el espacio de la dirección. El efecto
global de la utilización de direcciones ajenas al espacio de la dirección del proveedor se
resume en que se deben instalar más rutas en las tablas de enrutamiento globales. Otra
situación que podría darse es el caso en el que los clientes, con el fin de evitar verse a
merced de un ISP en concreto, se conectan a varios proveedores (esto es, se convierten
en multihome) pero tienen IP asignadas sólo a uno de ellos. A menudo resulta imposible
que los otros ISP agreguen las IP de estos clientes, ya que una o varias de las
direcciones intermediarias pertenecen a algún cliente que no está en multihome con ellos
y cualquier adición podría crear un agujero negro. En consecuencia, los ISP deben
observar cada uno de estos rangos de direcciones IP que tienen en común con otro ISP
más allá de su propio espacio de direcciones. Éstas son a menudo más específicas que
las direcciones para el bloque CIDR del ISP que las asignó originalmente y, por lo tanto, el
tráfico se encamina fundamentalmente a través de los ISP que no emitieron la IP.
Una solución para estos clientes multihome es adquirir IP de cada uno de los ISP a los
que están conectados, pero esto provoca la pérdida de rutas en la organización
multihome. Si uno de los ISP tiene problemas, el tráfico del host multihome de la IP
obtenida desde ese ISP se perderá, ya que no se publica en ningún otro lugar. Este hecho
anula, en gran parte, el propósito del multihoming. Un enfoque alternativo requiere tomar
una dirección totalmente distinta del espacio de dirección de todos los ISP a los que el
cliente está conectado. Sin embargo, en este caso la desventaja es que todos los
enrutadores de Internet deben tener una ruta específica a estas direcciones de nueva
creación, con lo que se generarían tablas de enrutamiento muy grandes.
2.3.5
Problemas asociados al IPv4 – escalabilidad, seguridad y calidad del servicio
“Creo que hay un mercado mundial para, tal vez, cinco ordenadores” - Thomas Watson, 1943
“640 K debería ser suficiente para cualquiera” - Bill Gates, 1981
“32 bits debería ser espacio suficiente para las direcciones” - Vinton Cerf, 1977
Con el gran crecimiento inesperado y sin precedentes de Internet, se ha hecho cada vez
más obvio que los días del IPv4 (la implementación actual del protocolo IP analizada en
secciones anteriores) están contados. Los problemas de disminución de espacio de
direcciones y el control de un registro central siguen estando ahí y la llegada del CIDR
sólo ha servido como parche temporal. Actualmente, los registros no pueden dar
respuesta a solicitudes de grandes bloques IP y se espera que para el año 2008 las
direcciones IPv4 se hayan terminado. Este hecho proviene del aumento de las
comunicaciones móviles de tercera generación, la demanda impuesta por los países
emergentes que no estuvieron presentes en la “fiebre del oro” del IPv4 y la llegada de las
redes locales. Además, está el aumento drástico del tamaño de las tablas de rutas (que
ascienden a aproximadamente 60.000 entradas en la actualidad) debido a una falta
inherente de cualquier red o consideración de enrutamiento. Dejando a un lado los
problemas de la memoria estática, esto provoca una degradación del rendimiento, ya que
los algoritmos actuales no escalan de forma lineal. El IPv4 también echa en falta la
ausencia de un mecanismo incorporado que cumpla los requisitos del servicio que deben
cumplirse en la red mientras se transporta un flujo. Esto también puede denominarse
como ausencia de calidad de servicio o CdS y se suele entender como la limitación
para ir más allá del servicio de datagrama de “mejor esfuerzo” disponible en la actualidad,
que se centra solamente en una métrica arbitraria única: el peso administrativo o el
recuento de saltos. Por último, el IPv4 también parece adolecer de la ausencia de un
mecanismo intrínseco de seguridad, que desemboca en caras modificaciones de
aplicaciones y hosts para poder protegerlos frente a diversos ataques. Si no se tiene este
mecanismo, es posible que tengan lugar pérdidas de privacidad, pérdidas de integridad de
datos, intercambios de identidades o negaciones del servicio.
Quizá el problema más imperioso al que se enfrenta la Internet IP es la disminución de
direcciones. Las soluciones concebidas a corto y largo plazo están aún en fase de
desarrollo. La solución a corto plazo es el CIDR (enrutamiento de interdominio sin clases).
Las soluciones a largo plazo consisten en varias propuestas de nuevos protocolos de
Internet con direcciones más largas. Es posible, no obstante, que el CIDR no sea
suficiente para mantener Internet hasta que las soluciones a largo plazo puedan
implementarse. En consecuencia, se ha planteado otra solución: alguna forma de
reutilización de direcciones, ya sea complementando al CIDR o relegándolo al olvido. La
solución de reutilización de direcciones se basa en ubicar los traductores de direcciones
de red (NAT)8 en la frontera de los dominios stub. Cada cuadro NAT tiene una tabla
formada por pares de direcciones IP y direcciones globales únicas. Las direcciones IP
incluidas en el dominio stub no son globales ni únicas. Se reutilizan en otros dominios y
con ello se resuelve el problema de disminución de direcciones. Las direcciones IP
globales únicas se asignan siguiendo los métodos actuales de asignación de direcciones
CIDR. La principal ventaja del NAT es que puede instalarse sin necesidad de modificar ni
los hosts ni los enrutadores. Ahora bien, los NAT también presentan numerosos
inconvenientes9 que van desde su incapacidad para gestionar protocolos arbitrarios, hasta
el hecho de que representan puntos únicos de fallos y reducen la fiabilidad total del
sistema.
2.3.6
La solución IPv6/Ipng
Para afrontar las limitaciones del IPv4, se ha propuesto un nuevo protocolo denominado
IPv6 o IPng (IP de nueva generación). En la actualidad existe una infraestructura de IPv6
en Internet, pero aún no se han implementado los DNS.
El IPv6 cuenta con varias características. Para empezar, proporciona un espacio de
direcciones aumentado de 128 bits que permite IP globales únicas para todos los
dispositivos. Además, también ofrece un enrutamiento más eficaz gracias a una
estructura jerárquica que consigue la asignación de direcciones añadidas desde el
principio. Sin embargo, los clientes multihome representan un fracaso en esta jerarquía y
actualmente es bastante común que las empresas recurran al multihome. El IPv6 también
reserva campos de estas cabeceras de paquetes para encargarse de la seguridad y de la
CdS. Con el fin de enfrentarse al problema de la CdS, la cabecera del IPv6 tiene dos
campos; una etiqueta de flujo de 20 bits y un indicador de clase de tráfico de 8 bits.
Por último, los problemas de seguridad se abordan con la introducción del IPSec, que
utiliza un nuevo conjunto de cabeceras añadidas para asegurar el payload del paquete IP.
Éstas incluyen la autenticación de cabecera (AH) y el payload de seguridad encapsulado
(ESP).
2.3.7
La transición del IPv4 al IPv6
La idea más importante en la que se basa la transición del IPv4 al IPv6 es que Internet es
demasiado grande y está demasiado descentralizada para tener un “día D” (un día
concreto en el que cada host y enrutador se actualicen desde el IPv4 al IPv6). Por lo
tanto, el IPv6 necesita desarrollarse progresivamente de tal forma que los hosts y los
enrutadores que sólo funcionan con el IPv4 puedan seguir operando tanto tiempo como
sea posible. No se espera la conclusión de este proceso hasta el año 2010. Además, la
aparición de los NAT ha retrasado la adopción generalizada del IPv6. Aunque son muchos
los que detestan los NAT, su uso proporciona la funcionalidad principal del IPv6: un mayor
número de direcciones de host. Los NAT han reducido hasta ahora de forma eficaz la
presión para implementar una solución más elegante a largo plazo al problema de la
8
9
K. Egevang, P. Francis, “The IP Network Address Translator (NAT)” - RFC1631
Keith Moore “Things that NATs break,” http://www.cs.utk.edu/ moore/what-natsbreak.html
disminución de direcciones. El espacio de direcciones aumentado que brindan los NAT ha
conseguido que sean menos los que estén dispuestos a adoptar este nuevo protocolo de
red. Por lo tanto, parece que tendremos IPv4 para largo.
Sin embargo, tras la transición, los nodos del IPv4 deberían (idealmente) poder
comunicarse con el resto de nodos del IPv4 y con algunos conjuntos de nodos admitidos
por el IPv6 de forma indefinida. Asimismo, los hosts del IPv6 deberían poder comunicarse
con otros nodos del IPv6, incluso cuando parte de su infraestructura sólo sea compatible
con el IPv4. Se han definido dos mecanismos principales para contribuir a esta transición
y se analizan a continuación.
2.3.7.1 Funcionamiento de doble pila
La idea de este concepto es bastante sencilla. Los nodos del IPv6 se ejecutan tanto en
IPv6 como en IPv4 y utilizan el campo de la versión de la cabecera para decidir en qué
pila se procesa el paquete recibido.
2.3.7.2 Tunelización
Se trata de la técnica empleada en muchas situaciones en las que un paquete IP se envía
como payload de otro paquete IP; es decir, se adjunta una nueva cabecera IP en frente de
la cabecera de un paquete IP existente. En la transición del IPv6, la tunelización se utiliza
para enviar un paquete IPv6 a través de una porción de red que sólo admita IPv4. Esto
significa que el paquete IPv6 se encapsula dentro de una cabecera de IPv4 que contenga
la dirección del punto final del túnel en su cabecera y se transmite a través de una porción
exclusiva de la red IPv4 para, después, desencapsularse en el punto final. El punto final
puede ser un enrutador o un host. En cualquiera de los dos casos debe ser capaz de
procesar el paquete IPv6 tras la desencapsulación.
2.4 Enrutamiento
Internet está formada por millones de ordenadores y cualquier de ellos puede, en teoría,
comunicarse con el otro. Sin embargo, no todos los equipos están vinculados físicamente
entre sí y la información se transmite desde un punto a otro utilizando un paradigma de
almacenamiento y reenvío. Los paquetes de datos se transmiten entre equipos enlazados
físicamente y se encaminan a través de la red hacia sus destinos. Distintos protocolos de
enrutamiento son los que definen las reglas para el reenvío de los paquetes. En esta
sección abordaremos el estudio de estos protocolos.
2.4.1
Modelo topológico
La arquitectura de área extensa de Internet está dividida en un número de sistemas
autónomos (AS) conectados arbitrariamente. Un AS es un conjunto de enrutadores y
hosts regidos por una administración técnica única (normalmente una entidad comercial
única) que utilizan uno o varios protocolos de pasarela interior (IGP) y métricas comunes
para encaminar los paquetes dentro del AS y utilizan un protocolo de pasarela exterior
(EGP) para encaminar los paquetes hacia y desde otros AS. El uso del término sistema
autónomo refuerza en este caso el hecho de que, aunque se utilicen varios IGP y métricas
distintas, la administración de un AS tiene para el resto de AS un plan único y coherente
de enrutamiento interior y presenta una imagen constante de los destinos que se pueden
alcanzar. Cada AS se identifica de forma única mediante un entero de 16 bits asignado
por InterNIC y utilizado por los EGP para implementar la directiva de enrutamiento y evitar
los bucles de enrutamiento de alto nivel. Un AS puede entenderse como un conjunto de
prefijos de direcciones IP de CIDR que comparten una administración técnica común. Por
ejemplo, el bloque CIDR desde 208.130.28.0 a 208.130.31.255, así como la red
201.64.75.0 puede ser un AS 2934. La red del MIT es un AS 3.
Gran parte del tráfico portado dentro de un AS comienza o termina en dicho AS (esto es,
o bien la dirección IP origen o la dirección IP de destino del paquete IP identifica un host
interno de dicho AS). El tráfico que se ajusta a esta descripción recibe el nombre de
“tráfico local”. El tráfico que no se ajusta a esta descripción recibe el nombre de “tráfico de
tránsito”. Teniendo en cuenta la forma concreta de un AS para gestionar el tráfico de
tránsito, los AS pueden dividirse en las siguientes categorías:
• AS de stub: es aquél que se conecta a otro AS. En lo que a enrutamiento se
refiere, podría entenderse como una simple ampliación del otro AS. De hecho,
muchas redes con conexión simple a Internet no tienen un número único de AS
asignado y sus direcciones de red se tratan como parte del AS padre.
• AS de tránsito: tiene conexiones a más de un AS y puede utilizarse como
conducto para el tráfico (tráfico de tránsito) entre otros AS. Los proveedores de
servicios de Internet más importantes son AS de tránsito.
• AS multihome: tiene conexiones a más de un AS, pero no permite el paso del
tráfico de tránsito, aunque sus hosts internos sí pueden encaminar tráfico a través
de varios AS.
Se trata de la configuración característica de redes empresariales grandes con varias
conexiones redundantes a Internet, pero que no desean que el tráfico de otros pase por
sus redes.
2.4.2
Tipos de protocolos de enrutamiento
Para una red determinada que pueda representarse como un gráfico no directo conectado
(en el que los extremos representan las conexiones directas entre las entidades de red)
existen dos clases generales de protocolos que pueden utilizarse para encaminar
paquetes entre nodos.
2.4.2.1 Protocolos distancia-vector
Este tipo de protocolo de enrutamiento requiere que cada enrutador simplemente informe
a sus vecinos sobre su tabla de enrutamiento. Los enrutadores envían actualizaciones
periódicas de enrutamiento que incluyen un vector de las distancias al resto de nodos. En
cada ruta de red, los enrutadores receptores seleccionan al vecino que se anuncia al
menor coste y agregan su entrada a la tabla de enrutamiento. Como resultado, cada nodo
tiene el árbol de ruta más corto (determinado por la normativa) que ofrece las rutas al
resto de los nodos disponibles.
Los algoritmos de protocolo DV sólo utilizan la información de los nodos cercanos. Estos
protocolos suelen ser descentralizados e iterativos y están basados en algoritmos como el
de Bellman-Ford para las rutas más cortas. Los protocolos DV también suelen ser
relativamente escalables. El protocolo DV básico recibe el nombre de protocolo de
información de enrutamiento (RIP). El protocolo de pasarela fronterizo (BGP) utiliza
esencialmente un algoritmo DV, pero con varios cambios añadidos. Trataremos este
asunto más adelante en profundidad.
El enrutamiento basado en los protocolos DV puede causar muchos problemas si los
enlaces no son estables o si los nodos anuncian información incorrecta. Podría
desembocar en bucles infinitos y desincronizar la red. La convergencia en los protocolos
DV suele ser baja. De hecho, la topología de una red puede tardar minutos e incluso
horas en sincronizarse, independientemente de los recursos computacionales que haya
disponibles en cada nodo.
2.4.2.2 Protocolos Link-State (LS)
Los protocolos Link-State requieren que cada enrutador mantenga al menos una
asignación parcial de la red. Cuando una red cambia de estado (de activa a inactiva o
viceversa), se envía una notificación llamada aviso de estado de enlace (link state) a
toda la red. Todos los enrutadores advierten el cambio y vuelven a calcular sus rutas en
concordancia. El protocolo OSPF (abrir ruta más corta primero) es un ejemplo de
protocolo LS.
Como cada nodo da una buena idea del gráfico de red y las actualizaciones sólo
requieren la adición o eliminación de nodos y extremos, los protocolos LS convergen más
rápidamente hacia un estado estable que los protocolos DV. También son más fiables,
fáciles de depurar y con menor intensidad de ancho de banda que los protocolos DV.
Por otro lado, los protocolos LS suelen ser más complejos que los protocolos DV.
También tienden a ser más intensivos en términos de memoria y de cálculo local. Los
protocolos LS no escalan tan bien como los DV, por lo que los protocolos como el OSPF
suelen utilizarse normalmente para encaminar paquetes de forma interna dentro de un
AS. Los IGP suelen estar relacionados con la optimización de una métrica de ruta
concreta y su escalabilidad no supone un problema importante.
2.4.3 Protocolo de pasarela fronterizo (BGP)
El protocolo de pasarela fronterizo (BGP) es un protocolo de enrutamiento de interdominio
de facto utilizado para intercambiar la accesibilidad de información entre sistemas
autónomos en la Internet global. Se trata de un protocolo distancia-vector que permite que
cada AS ignore la métrica basada en la distancia con métricas basadas en normativas
cuando se seleccionan las mejores rutas.
2.4.3.1 Motivaciones de diseño
El diseño de un BGP estuvo motivado por tres importantes necesidades:
• Escalabilidad. La división de Internet en distintos dominios de enrutamiento (los AS) se
realizó en tiempos de NSFNET. Un requisito importante del BGP era garantizar que la
infraestructura de enrutamiento de Internet permaneciese escalable a medida que el
número de redes conectadas aumentaba.
• Normativa. La capacidad de cada AS para implementar y afianzar varias formas de
normativas de enrutamiento era un objetivo importante de diseño. Algunas de las
consecuencias de esto fueron el desarrollo de estructuras de atributos de BGP para
anuncios de rutas, la permisividad del filtrado de las mismas y la priorización de las
preferencias locales.
• Cooperación en circunstancias competitivas. El BGP se diseñó en gran parte para
gestionar la transición desde NSFNET hacia una situación en la que la infraestructura
principal ya no se ejecutase mediante una entidad administrativa. El enrutamiento en
Internet se gestionaría mediante un gran número de ISP mutuamente competitivos que
cooperarían libremente para proporcionar conectividad global. El protocolo de
enrutamiento se creó entonces para permitir que los AS pudiesen tomar decisiones
estrictamente locales sobre la forma de encaminar los paquetes teniendo a su disposición
cualquier conjunto de posibilidades.
2-20
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de 2002
Figure 2.4. Sistemas autónomos en BGP
2.4.3.2 El protocolo BGP-4
2.4.3.2.1 Un modelo idealizado
Los protocolos modelan Internet como un conjunto de sistemas autónomos con relaciones
de peering entre sí. Esto crea un gráfico no dirigido en el que los vértices representan los
AS y los extremos representan las conexiones directas fiables entre los AS. Cada vértice
mantiene el árbol encaminado de ruta más corta especificando las mejores rutas a los
otros vértices. Las rutas son seleccionadas por cada AS basándose en su propia
normativa y en las mejores rutas próximas.
Un vértice reconoce el conjunto de rutas disponibles mediante los anuncios de las rutas
próximas. Los vértices envían dichos anuncios siempre que las tablas de enrutamiento
cambian. Estos anuncios contienen, entre otros, información sobre los AS que necesitan
utilizarse en la ruta. Con ellos se consigue la distancia-vector o la ruta-vector de la ruta.
Siempre que un vértice tiene más de una ruta en un destino determinado, se selecciona la
mejor de todas. Primero se selecciona según las preferencias locales del vértice y, a
continuación, se escoge la ruta con la distancia-vector más corta. Las coincidencias se
solucionan de forma arbitraria.
Los anuncios de rutas sufren transformaciones a medida que pasan de un vértice al
siguiente. En concreto, cada vez que se transmite una ruta, el vértice adjunta su
identificador a la ruta-vector de la ruta. Los bucles pueden evitarse de esta manera, ya
que ningún vértice acepta anuncios de ruta cuya ruta-vector aparezca en el propio vértice.
A medida que los anuncios se propagan por la red, cada vértice mejora de forma iterativa
su visión del resto de las rutas disponibles. Por último, se espera que el sistema converja
a un estado estable. En este estado final, cada vértice conoce la mejor ruta hacia el resto
de los vértices. Como existen preferencias locales, la definición sobre qué hace que una
ruta sea la mejor puede variar de nodo A medida que los anuncios se propagan por la
red, cada vértice mejora de forma iterativa su visión del resto de las rutas disponibles. Por
último, se espera que el sistema converja a un estado estable. En este estado final, cada
vértice conoce la mejor ruta hacia el resto de los vértices. Como existen preferencias
locales, la definición sobre qué hace que una ruta sea la mejor puede variar de nodo
2-21
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de 2002
2.4.3.2.2 El protocolo
Dos sistemas (normalmente dos enrutadores fronterizos en distintos AS) forman una
conexión TCP fiable entre uno y otro e intercambian mensajes para abrir y confirmar los
parámetros de conexión. El flujo inicial de datos es la tabla de enrutamiento BGP al
completo. Más tarde, se envían actualizaciones incrementales a medida que las tablas de
enrutamiento cambian. Hay dos tipos de actualizaciones. El primero son los anuncios, que
son cambios en las rutas existentes o en rutas nuevas. El otro son las retiradas, que
informan que el peer que nombró las rutas ya no está disponible.
Los anuncios del BGP contienen un conjunto de prefijos formados, a su vez, por un
conjunto de atributos asociados a él. El atributo de ruta AS es un vector que enumera
todos los AS (en orden inverso) por los que este anuncio de ruta del prefijo ha pasado.
Tras cruzar una frontera AS, el primer enrutador toma el único identificador de su propio
AS a este vector antes de seguir propagando el anuncio. Los enrutadores evitan los
bucles mediante la eliminación de mensajes si sus AS ya están presentes en este vector.
Un enrutador utiliza normativas de importación para transformar las actualizaciones de
ruta entrantes. Estas normativas de importación incluyen la negación de una actualización
o la aceptación de la actualización y la asignación de una preferencia local para indicar el
grado de aptitud de la ruta. De forma similar, las normativas de exportación permiten que
un enrutador determine si debe enviar la mejor ruta a un vecino y, de ser así, qué
sugerencia debe enviarle para utilizarla.
Los enrutadores BGP utilizan los campos de los anuncios de las rutas para determinar
qué rutas deben utilizar en la tabla de enrutamiento. Generalmente, las rutas adquiridas
de forma externa (mediante eBGP) son preferibles a las adquiridas internamente
(mediante iBGP). Las preferencias locales que representan cualquier normativa local
arbitraria obtienen la máxima prioridad en la selección. La longitud de la ruta-vector del
AS es el segundo criterio más importante. Puede que no sea la distancia más corta, ya
que sólo debe contar el número de AS que se necesitan encaminar. Los enrutadores
también pueden utilizar la ruta del AS mediante la repetición de los identificadores del AS
para localizar las rutas menos aptas a otros AS. Por último, señalar que las coincidencias
se evitan de forma arbitraria. Debido a estos factores y a algunas decisiones de
implementación de enrutadores específicas de los proveedores, resulta prácticamente
imposible determina las mejores rutas sólo a partir de las relaciones de conectividad.
BGP utiliza TCP, lo que proporciona un envío ordenado y fiable y no necesita una
actualización periódica de toda la tabla de enrutamiento. Un portavoz BGP debe, por lo
tanto, retener la versión actual de todas las tablas de enrutamiento BGP y de todos sus
peers en la duración de la conexión. Los mensajes KeepAlive se envían de forma
periódica en las dos direcciones para garantizar que la sesión BGP sigue ejecutándose.
Si no existen dichos mensajes, la sesión BGP se cierra y todas las rutas adquiridas en
dicha sesión se eliminan de las tablas de enrutamiento de sus respectivos peers.
Los mensajes de notificación se envían como respuesta a errores o condiciones
especiales. Si una conexión presenta una condición de error, se enviará un mensaje de
notificación y se cerrará la conexión. Sin embargo, el BGP no se diseñó para gozar de
una rápida detección y recuperación de fallos, por lo que estos mecanismo no suelen ser
especialmente útiles en escalas de tiempo pequeñas.
2-22
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de 2002
Figure 2.5. Sesiones iBGP
2.4.3.2.3 eBGP: enrutamiento inter-AS
El BGP externo (eBGP) es un modo estándar en el que se utiliza BGP. Los enrutadores
fronterizos de un AS determinado se conectan a los enrutadores de otros AS a través de
sesiones BGP. Estos enrutadores proporcionan los únicos puntos de entrada y salida de
sus AS. Implementan reglas de filtrado de rutas e intercambian un subconjunto de las
mismas mediante BGP y enrutadores en otros AS a través de sesiones BGP.
2.4.3.2.4 iBGP: coherencia intra-AS
Si un AS en concreto tiene varios portavoces BGP y proporciona servicio de tránsito para
otros AS (como suele ser el caso, al menos para un número reducido de rutas), debe
prestarse atención para garantizar una visibilidad constante de las rutas dentro del AS.
En general, cada AS tendrá más de un enrutador fronterizo que participará en las sesiones
eBGP con los AS próximos. Durante este proceso, cada enrutador eBGP obtendrá
información sobre algún subconjunto de reglas conocidas por el AS. Como uno de los
objetivos del BGP es permitir que cada AS sea tratado como una entidad monolítica
abstracta, es fundamental que cada enrutador del AS tenga un concepto completo de las
rutas disponibles para el eBGP en todo el AS.
La coherencia se consigue permitiendo que los enrutadores fronterizos intercambien
información mediante iBGP. Los enrutadores eBGP se conectan entre sí dentro del AS y
mantienen sesiones iBGP entre sí. Estas sesiones permiten que cada enrutador actualice sus
tablas con la información contenida en el resto.
2-23
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de 2002
Es importante señalar que un iBGP no es un IGP como RIP o OSPF. De hecho, los mensajes
enviados durante una sesión iBGP se encaminan dentro del AS con cualquier IGP que esté
operativo. Las sesiones iBGP sólo proporcionan un medio por el cual los enrutadores dentro de
un AS pueden utilizar el mismo protocolo (BGP) para intercambiar información completa.
2.4.3.2.5 La cuestión de la convergencia
Informalmente, un sistema BGP puede representarse por un estado S = <G, Normativa(G), S0>,
incluyendo un gráfico AS G = (V, E), y conteniendo normativas de importación para cada vj en V
y con un estado inicial S0 = (c0,1, c0,2,c0,n) donde c0,j es el destino originado por vj en el
estado S0. Si vj se activa, obtiene anuncios de ruta de sus vecinos intermediarios y selecciona
las mejores rutas. Se dice que el estado S es final si en la activación de cualquier vj, el sistema
permanece en el estado S. Una secuencia de activación del sistema simplemente es una
secuencia que proporciona los vértices vj y el orden en que se activan.
Se dice que un sistema BGP es convergente si concluye en un estado final independiente de la
secuencia de activación. Se dice que el sistema es soluble si cuenta con un estado final. Al
contrario de lo que ocurre con protocolos distancia-vector puros, como el RIP, el BGP no
garantiza la convergencia.
Las normativas BGP se implementan de forma local en la actualidad con mucho o poco
conocimiento global. Aunque la mayoría de los conflictos de las normativas de enrutamiento son
gestionables, siempre existe la posibilidad de que puedan provocar divergencias en el protocolo.
Las normativas de enrutamiento de cada AS por separado pueden ser razonables localmente,
pero no hay garantía alguna de que la interacción de normativas definidas independientemente
puedan ser razonables globalmente. En teoría, un conjunto de normativas bien configuradas
localmente puede seguir provocando anomalías de enrutamiento globales. Es posible, por lo
tanto, que un conjunto de AS intercambie mensajes en todo momento sin converger hacia un
conjunto de rutas estable.
Esta divergencia del BGP podría contribuir a una gran cantidad de inestabilidad en el sistema de
enrutamiento global. La fluctuación de la topología de red puede tener un efecto directo en el
rendimiento final. Una red que no haya logrado convergencia puede descartar paquetes o
enviarlos inutilizados. En casos extremos, la ausencia de convergencia puede tener como
resultado la creación de agujeros negros en paquetes (con rutas de anuncios de AS que, en
esencia, no tiene y con la eliminación de paquetes que se envían por dichas rutas). En
consecuencia, con el fin de que una red basada en BGP pueda funcionar eficientemente, debe
ser convergente. Por desgracia, son muchos los sistemas BGP que no gozan de convergencia.
2.4.3.2.6 El sistema Bad Gadget
En esta sección se incluye un ejemplo de un sistema BGP no soluble denominado “Bad
Gadget” (mal aparato). Ninguna ejecución del protocolo BGP puede llegar a un enrutamiento
estable en este sistema. La red “Bad Gadget” se presenta en la figura 2.6, donde cada nodo
representa un AS y los extremos representan las conexiones entre los AS.
Supongamos que existe un destino único con d originado en AS 0. La normativa se implementa
de tal forma que cada AS opta por la ruta en el sentido de las agujas del reloj de longitud 2 sobre
el resto de las rutas hacia 0. Es decir, AS 3 opta por la ruta 3 - 2 - 0 y no por la 3 - 0.
Puede demostrarse así que este sistema es divergente. Esta prueba se documenta en un estudio
de Griffen y Wilfong10. En este tema se presenta una visión general.
2-24
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de 2002
Figura 2.6. Red Bad Gadget
Un ejemplo es el primero presentado abajo para proporcionar una idea intuitiva. La figura 2.7
muestra el sistema a través de una secuencia de cuatro activaciones. Los nodos negros
representan un nodo activándose, es decir, anunciando sus rutas. Las flechas rojas indican
las rutas.
En (1) no se han realizado anuncios y ningún nodo conoce las rutas. En (2) el nodo 0 anuncia
todas las rutas directas hacia él y cada nodo toma la conexión directa hacia 0 como la mejor
ruta. En (3) el nodo 1 anuncia sus rutas, que hacen que el nodo 2 cambie su ruta hacia la
más adecuada en el sentido de las agujas del reloj. En (4) el nodo 3 anuncia sus rutas y hace
que el nodo 1 cambie. Por último, en (5) el nodo 0 se anuncia de nuevo y el nodo 2 vuelve a
cambiar. Si vamos más allá con este razonamiento, podemos obtener la prueba de que no se
está estableciendo ninguna ruta estable. La prueba formal presentada en el documento
verifica esta intuición. A continuación se incluye una visión general de la prueba.
Para que este sistema tenga una solución debe lograr un estado final. Es fácil ver que en el
caso de sistemas de destino único, en un estado final el gráfico inducido por la ruta del AS de
cada vértice al destino es un árbol con raíces en el destino y que este estado final puede
alcanzarse mediante la activación de todos los nodos del primer orden del árbol (esta
conclusión está extraída del documento). Utilizando este hecho, podemos demostrar que este
sistema es divergente.
Sólo es necesario tener en cuenta dieciséis árboles extendidos con raíz en AS 0. Cualquier
árbol que no se expanda en este gráfico no puede ser una solución, ya que cada AS 1, 2 y 3
tiene una ruta directa hacia d. Además, al tratarse de un sistema simétrico, sólo los seis
casos presentados en la figura 2.8 son relevantes.
10
Este ejemplo se estudia detalladamente en los siguientes documentos: [1] Timothy Griffn and Gordon
T. Wilfong, “An Analysis of BGP Convergence Properties” SIGCOMM [2] K. Varadhan, R. Govindan & D.
Estrin, “Persistent Route Oscillations in Inter-Domain Routing” ISI TR 96-631
2-25
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de 2002
Figura 2.7. Ejemplo de activación de Bad Gadget
Figura 2.8. Posibles árboles de enrutamiento para Bad Gadget
2-26
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de 2002
En la figura 2.8, los AS que cambiarán su selección de mejores rutas hacia d están marcados
con un círculo con relleno. Cada AS marcado puede seleccionar una ruta en el sentido contrario a
las agujas del reloj de longitud 2 o invertir la ruta directa a d. Es fácil ver que el sistema no tiene
solución.
Este sistema divergente podría parecer un ejemplo artificioso y hacernos pensar que en la práctica
esta divergencia podría cuestionarse en un BGP. En la siguiente sección se incluyen algunos
aspectos de la inestabilidad del BGP en Internet.
2.4.3.2.7 Observaciones sobre la inestabilidad
¿Diverge el BGP en la práctica? Existen varias historias horribles sobre redes que de forma
accidental se establecieron de forma autónoma como sumideros de tráfico y hay algunas pruebas
sobre oscilaciones crónicas.
También se han observado algunos casos de convergencia desfasada hasta 50 minutos. Aun así, BGP
por lo general ha demostrado ser convergente en Internet.
Es posible que los enrutadores de Internet experimenten cargas de CPU importantes y problemas
de memoria a altos niveles de inestabilidad de enrutamiento. En 1997 por ejemplo, muchos de los
enrutadores de Internet desarrollados comúnmente estaban basados en el procesador de la serie
relativamente ligera 68000 de Motorola. La alta inestabilidad solía causar problemas en el consumo
de memoria y en el retraso del procesamiento de las colas de paquetes. A menudo, los retrasos en el
procesamiento eran tan acusados que los enrutadores desfasaban el enrutamiento en paquetes
KeepAlive que, en consecuencia, se marcaban como inactivos o no localizables por otros
enrutadores.
La experiencia con NSFNet y los ejes de área extensa han demostrado que un enrutador que no
consigue funcionar con gran inestabilidad de enrutamiento puede provocar una “tormenta de
agitación de rutas”. En este modo de oscilación patológica, los enrutadores sobrecargados son
marcados como no localizables por los peers BGP a medida que van fallando para mantener el
intervalo requerido de transmisiones KeepAlive. Como los enrutadores se marcan como no
localizables, los enrutadores peer seleccionan rutas alternativas para los destinos previamente
localizables a través del enrutador “inactivo” y transmite actualizaciones que reflejan el cambio de la
topología en cada uno de sus peers. Por su parte, tras la recuperación de problemas transitorios de
CPU, el enrutador “fallido” intentará reiniciar una sesión BGP de peering con cada uno de los otros
enrutadores y generará un estado de transmisiones dump. Esta carga aumentada provocará que
aún más enrutadores fallen e iniciará una “tormenta” que comenzará a afectar a secciones más
grandes de Internet. Varias de las tormentas de agitación de rutas ocurridas hasta ahora han
causado la inactividad de millones de clientes de red. La última generación de enrutadores de
varios proveedores proporciona un mecanismo por el cual el tráfico BGP obtiene mayor prioridad y
los mensajes KeepAlive resisten incluso en condiciones de alta inestabilidad.
La mayor parte de la inestabilidad de los enrutadores de Internet es resultado de los fallos de
software y de decisiones de implementación concretas de ciertos proveedores. Sin embargo, tras el
desarrollo de enrutadores actualizados por los ISP, esta inestabilidad ha decrecido en gran medida.
La heurística como la disminución de los anuncios de rutas también ha mejorado las propiedades del
BGP. Así que, aunque en teoría es posible que BGP diverja, se ha demostrado empíricamente que
en última instancia resulta convergente.
No obstante, son muchos los casos de convergencia desfasada. En un estudio11, Labovitz et al
introdujeron fallos BGP (anuncios/extracciones) de prefijos variados y longitudes de ruta de AS en
sesiones de peering IP en varios puntos geográficos. Observaron desfases que ascendían hasta a
50 en su estudio. De hecho, los tiempos de convergencia de enrutamiento tras los fallos se
encontraban en el orden de decenas de minutos.
11
“Delayed Internet Routing Convergence” C. Labovitz, A. Ahuja, A. Bose & F. Jahanian,
Proceedings of SIGCOMM 200
2-27
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de
2002
Esta latencia puede entenderse estudiando la forma en que BGP explora las rutas. Además de las
distintas anomalías específicas de cada proveedor, la razón fundamental para la convergencia pasa
por que los protocolos de ruta-vector consideran varias rutas de una longitud determinada en
contraposición a los protocolos de distancia-vector, que sólo consideran una ruta de una longitud
determinada. En Labovitz et al construyen un ejemplo en el que tienen en cuenta cada ruta libre de
bucle de la malla al completo (hay un número exponencial de dichas rutas). Se ha demostrado que
existe un posible orden de mensajes de tal forma que BGP explore todas las rutas posibles de AS,
con todas las longitudes posibles. BGP es, por lo tanto, O(N!), donde N es el número de portavoces
BGP no predeterminados en un gráfico completo con normativa predeterminada. Además, no existe
ningún conocimiento global en los protocolos de ruta-vector, por lo que las heurísticas de
optimización no son muchas. Así, no resulta sorprendente que la convergencia tarde bastante
tiempo en conseguirse.
2.4.3.2.8 Accesibilidad en un AS
Dada una red de sistemas autónomos vinculada por un BGP y un destino accesible desde un
vértice (x), en ocasiones es útil saber si el destino es accesible desde cualquier otro vértice (y). La
accesibilidad es una propiedad que se presenta si existe un estado final del sistema en el que hay
una ruta desde y hacia el destino. La determinación de la existencia de la accesibilidad en un
sistema BGP es NP-completa. Esto puede demostrarse mediante la reducción de 3-SAT y la prueba
se presenta en el documento de Griffen y Wilfong.
La base de datos de arbitraje de enrutamiento (RADB) pretende ofrecer información de
accesibilidad entre AS a los usuarios de Internet. El registro de enrutamiento de Internet (IRR,
del que RADB
forma parte) mantiene la información de enrutamiento de los ISP por separado en varios
depósitos públicos como intento de coordinación de una normativa de enrutamiento global. La
base de datos de la normativa de enrutamiento del IRR incluye información de enrutamiento a
varios niveles (por ejemplo, prefijos de direcciones distintas, AS, etc.) Las rutas se registran con
la RADB de forma voluntaria. Registrar una ruta en la RADB implica que el registrador es capaz
de proporcionar accesibilidad en el destino, es decir, es posible acceder al destino a través de la
infraestructura de red del registrador.
Hasta no hace mucho, se ha advertido un especial interés por el estudio y el diseño de la topología
de Internet, especialmente en el nivel de los sistemas autónomos (AS). En la actualidad, estas
actividades se consideran más como medidas de análisis y diseño (en su mayoría a partir de
bases de datos como la RADB) para deducir el gráfico de conectividad de los AS de Internet y
describir sus propiedades, explicando los orígenes y las causas de algunas de las funciones
observadas más sorprendentes y diseñando simuladores que generan estructuras de gráficos que
coincidan con los gráficos de conectividad AS medidos. También pueden utilizarse para obtener un
contexto realista para el aislamiento de fallos. En un documento reciente de Chang et al12, se
observaba que estas bases de datos nos muestran que un número significativo de conexiones AS
existentes permanecen ocultas en la mayoría de las tablas de enrutamiento BGP.
El conocimiento sobre la conectividad de Internet puede proporcionarnos un marco de trabajo
mejor para entender el comportamiento del BGP en la realidad. Por desgracia, mucha de la
información proporcionada a la RADB puede ser filtrada de forma selectiva por las empresas. Por
ejemplo, se sabe que un número creciente de ISP utilizan el IRR para filtrar los anuncios de rutas
en los enrutadores fronterizos (la mayoría de ISP europeos utilizan de forma activa). El
12
H. Chang, R. Govindan, S. Jamin et al, “On Inferring AS level Connectivity from BGP
Routing Tables”
2-28
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de
2002
conocimiento de este comportamiento puede influir en las rutas que se registran en la RADB.
2.4.3.2.9 Otros resultados de complejidad del BGP
Se han estudiado muchas más propiedades el protocolo BGP, tanto de forma matemática
como empíricamente. A continuación se incluyen algunos otros resultados de complejidad del
BGP. Algunas de estas propiedades se presentan abajo tal y como se incluyen en el documento
de Wilfong y Griffen.
Para un sistema S BGP, el gráfico de evaluación, Eval(S), se define como el gráfico que se
dirigirá, en cada estado s accesible hay un vértice etiquetado por s en Eval(S) y si s y s’ son estados
accesibles y las transiciones a s y a s’ con la activación de algún conjunto de vértices no vacío A,
entonces habrá un extremo dirigido desde s a s’ etiquetado por A en Eval(S). Un estado s en Eval(S)
es final si para todos los vértices (v) del conjunto de vértices del sistema BGP existe un extremo
entre s y s’ llamado v.
² Asimetría
Dado un sistema S BGP, AS v en S, AS w en S, un destino d1 originado por w, un
destino d2 originado por v, ¿existe un estado final s en Eval(S) en el que la ruta desde
v a d1 no sea la inversa de la ruta desde w a d2? La asimetría es NP-completa.
² Solubilidad/Insolubilidad
Dado un sistema S, ¿existe un estado final en Eval(S)? ¿O podemos afirmar que no existe
un estado final en Eval(S)? La solubilidad y la insolubilidad son NP-completas.
Observe que un sistema insoluble no puede converger hacia un estado estable, ya que no
existe ninguno. De forma operativa, esto significa que en sistemas insolubles, es probable
que BGP tienda hacia una “oscilación de protocolo” que no termine nunca.
² Solubilidad/Insolubilidad (SD)
Dado un sistema S con un único destino d originado por algún AS w, ¿existe un estado final
en Eval(S)? ¿O podemos afirmar que no existe un estado final en Eval(S)? Estos problemas
son NP-hard.
² Trampas
Dado un sistema S, ¿contiene Eval(S) una trampa? Formalmente, podemos definir una
trampa como un subgráfico de Eval(S) que (1) no contiene un estado final y (2) no tiene arcos
dirigidos hacia el subgráfico. Este problema es NP-hard.
² Solidez K
Dado un sistema soluble S que sólo tiene un único destino d originado por algún AS w, ¿permanecerá S
soluble ante un posible fallo de k vínculos? Este problema es NP-hard.
² Unicidad
Dado un sistema S, ¿existe exactamente un estado final en Eval(S)? Este problema es NP-hard.
2-29
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera de 2002
² Multiplicidad
Dado un sistema S, ¿existen varios estados finales posibles en Eval(S)? Este problema
es NP-hard.
Figure A.1. Modelo de referencia OSI
APDU – Unidad de datos de protocolo de aplicación
PPDU – Unidad de datos de protocolo de presentación
SPDU – Unidad de datos de protocolo de sesión
TPDU – Unidad de datos de protocolo de transferencia
Apéndice A
El modelo OSI está formado por:
1. Capa física: La capa física está relacionada con la transmisión de bits sin compresión
en un canal de comunicación. Los problemas de diseño están relacionados con
garantizar que cuando un extremo envía 1 bit, se recibe en el otro extremo como 1 bit, y
no como un bit 0.
Las preguntas comunes en este caso son la cantidad de voltios necesarios para
representar un 1 y la cantidad para representar un 0, cuántos microsegundos tarda un
bit, si la transmisión se realiza de forma simultánea en las dos direcciones, cómo se
establece la conexión inicial y cómo se concluye cuando los dos extremos han
terminado y cuántos pins tiene un conector de red y cuántos se utilizan. Los problemas
de diseño tienen que ver, en gran parte, con interfaces mecánicas, eléctricas y de
procedimientos y con el medio de transmisión física, que se encuentra debajo de la
capa física. El diseño de la capa física puede considerarse dentro del dominio de la
ingeniería eléctrica.
Ejemplo: RDSI, CAT 1, ADSL, ATM, FDDI, cables coaxiales
2-31
2-30
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera
de 2002
2. Capa de enlace de datos: la tarea principal de la capa de enlace de datos es
obtener un medio de transmisión sin compresión y transformarlo en una línea libre de
errores de transmisión en la capa de red. Para conseguirlo, el emisor divide los datos
en marcos de datos (normalmente de cientos de bytes), transmite los marcos
secuencialmente y procesa los marcos de aviso de recepción devueltos por el
receptor. Como la capa física sólo acepta y transmite una secuencia de bits sin tener
en cuenta el significado de la estructura, dependerá de la capa de enlace de datos
crear y reconocer los límites de los marcos. Esto puede realizarse adjuntando
patrones de bits especiales al comienzo y al final de cada marco. Si hay una
posibilidad de que estos patrones de bits se produzcan en los datos, es preciso
prestar especial atención para evitar confusiones.
Ejemplo: SLIP, PPP, 802.2 SNAP, Ethernet II
3. Capa de red: La capa de red está relacionada con el control del funcionamiento de
la subred. Un problema clave de diseño es determinar cuántos paquetes se
encaminan desde el origen hasta el destino. Las rutas deben estar basadas en tablas
estáticas que están “enlazadas” con la red y que no suelen cambiar. También deben
calcularse al principio de cada conexión, por ejemplo, en una sesión de terminal.
Finalmente, pueden ser muy dinámicas y calcularse de nuevo para cada paquete,
reflejando así el estado actual de la carga de red. Si hay muchos paquetes en la
subred al mismo tiempo, interferirán entre sí y formarán cuellos de botella. El control
de estas congestiones también es responsabilidad de la capa de red.
Ejemplo: IPv4, IPv6.
4. Capa de transporte: la función básica de la capa de transporte es aceptar datos
en una capa de sesión, dividirlos en unidades más pequeñas si es necesario,
enviarlos a la capa de red y garantizar que todas las partes llegan correctamente al
otro extremo. Además, todo esto debe realizarse de forma eficiente aislando la capa
de sesión de los posibles cambios que puedan producirse en la tecnología del
hardware. En condiciones normales, la capa de transporte crea una conexión distinta
de red para cada conexión de transporte necesaria para la capa de sesión. Ahora
bien, si la conexión de transporte requiere un alto rendimiento, la capa de transporte
puede crear varias conexiones de red, dividir los datos entre las conexiones de red y
mejorar así el rendimiento. Por otro lado, si crear y mantener una conexión de red
resulta caro, la capa de transporte puede multiplexar varias conexiones de transporte
en la misma conexión de red para reducir costes. En todos los casos, la capa de
transporte es necesaria para que el multiplexado sea transparente para la capa de
sesión. La capa de transporte también determine el tipo de servicio ofrecido a la capa
de sesión y, en última instancia, los usuarios de la red. El tipo más usual de conexión
de transporte es un canal punto a punto sin errores que envía mensajes en el orden
en que fueron enviados. No obstante, también son posibles otros tipos de transporte,
de servicio y de mensajes aislados de transporte sin garantía alguna sobre el orden
de envío, así como difusión de mensajes a varios destinos. El tipo de servicio viene
determinado cuando se establece la conexión. La capa de transporte es una capa real
punto a punto y origen a destino. Dicho de otra manera, un programa de la máquina
origen mantiene una conversación con un programa similar en la máquina de destino
utilizando cabeceras de mensajes y mensajes de control.
2-32
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera
de 2002
Ejemplo: TCP,UDP
5. Capa de sesión: la capa de sesión permite que usuarios de distintas máquinas
puedan establecer sesiones entre sí. Una sesión permite el transporte común de
datos, tal y como ocurre con la capa de transporte, pero también proporciona
servicios mejorados que resultan de gran utilidad en ciertas aplicaciones. Una sesión
puede utilizarse para permitir que el usuario inicie sesión en un sistema remoto de
compartición de tiempo o que transfiera un archivo entre dos máquinas. Uno de los
servicios de la capa de sesión es la administración del control de diálogo. Las
sesiones permiten que el tráfico fluya en ambas direcciones al mismo tiempo o sólo
en una cada vez. Si el tráfico sólo puede ir en una dirección, la capa de sesión ayuda
a saber de quién es el turno. Un servicio relacionado con la sesión es la gestión de
testigos. En algunos protocolos, resulta esencial que los dos extremos no intenten
realizar la misma operación al mismo tiempo. Para gestionar estas actividades, la
capa de sesión ofrece testigos que pueden intercambiarse. Únicamente el extremo
que tenga el testigo podrá realizar la operación crítica. Otro servicio de sesión es la
sincronización. Piense en los problemas que pueden surgir al intentar establecer una
transferencia de archivos de dos horas entre dos máquinas de una red con un tiempo
medio de una hora antes de que falle. Tras la cancelación de cada transferencia, la
transferencia al completo debe iniciarse otra vez y probablemente fallará de nuevo
cuando la red caiga. Para eliminar este problema, la capa de sesión ofrece un
método de inserción de puntos de comprobación en el flujo de datos para que, al caer
la red, sólo deban repetirse los datos situados después de este punto de
comprobación.
Ejemplo: RPC Portmapper
6. Capa de presentación: la capa de presentación lleva a cabo funciones que
suelen solicitarse con frecuencia para encontrar una solución y no dejar que el
usuario tenga que resolver el problema. En concreto, y al contrario de lo que ocurre
con el resto de capas inferiores que sólo muestran interés por mover bits de forma
fiable entre varios puntos, la capa de presentación se encarga de la sintaxis y de la
semántica de la información transmitida. Un ejemplo característico del servicio de
presentación es la codificación de datos de forma acordada y normalizada. La
mayoría de programas de usuarios no intercambian cadenas de bits binarios de
forma aleatoria. Intercambian cosas como nombres de personas, fechas, cantidades
de dinero y facturas. Estos elementos se representan con cadenas de caracteres,
enteros, números de coma flotante y estructuras de datos formadas por elementos
más simples. Los distintos equipos contienen distintos códigos para representar las
cadenas de caracteres, los enteros, etc. Con el fin de hacer posible que los equipos
puedan comunicarse entre sí con distintas representaciones, las estructuras de
datos que se intercambian pueden definirse de forma abstracta y con una
codificación estándar que se utilizará en la red. La tarea de gestionar estas
estructuras de datos abstractos y convertirlos en la representación utilizada por los
equipos en las redes estándar la lleva a cabo la capa de presentación. Esta capa
también se encarga de otros aspectos de la representación de información. Por
ejemplo, la compresión de datos puede utilizarse aquí para reducir el número de bits
2-33
MIT 18.996
Clase 2 – 13 de febrero, 2002
Primavera
de 2002
que se deben transmitir y la criptografía suele requerirse para la privacidad y la
autenticación.
Ejemplo: HTTP, FTP, Telnet, DNS, SNMP, NFS
7. Capa de aplicación: la capa de aplicación contiene una variedad de protocolos
que suelen ser necesarios. Por ejemplo, existen cientos de tipos de terminales no
compatibles en el mundo. Piense en la complicación de un editor de pantalla
completa que supuestamente debe funcionar en muchos tipos de terminales
distintos, cada uno de ellos con apariencias de pantalla diferentes, secuencias de
escape para la inserción y borrado de texto, movimiento del cursor, etc. Una forma
de solucionar este problema es definir un terminal virtual de red abstracto para el
que los editores y otros programas puedan escribir. Para administrar cada tipo de
terminal, debe escribirse una porción de software que asigne las funciones del
terminal virtual de red al terminal real. Por ejemplo, cuando el editor mueve el
cursor del terminal virtual hacia la esquina superior izquierda de la pantalla, este
software debe enviar la secuencia de comandos adecuada para que el terminal
real también realice dicho movimiento. Todo el software del terminal virtual se
encuentra en la capa de aplicación. Otra función de la capa de aplicación es la
transferencia de archivos. Los distintos sistemas de archivos tienen diferentes
convenciones de nomenclatura de archivos, formas distintas de representar líneas
de texto, etc. Transferir un archivo entre dos sistemas distintos requiere el
tratamiento de éstas y otras incompatibilidades. Esta tarea también es
responsabilidad de la capa de aplicación, al igual que el correo electrónico, las
entradas de tareas remotas, la búsqueda en directorios y otras utilidades generales
y concretas.
Ejemplos: correo electrónico, grupos de noticias, servicios de directorio, servicios
de archivos
2-34
MIT 18.996
Primavera
de 2002
Referencias
[1] ”Computer Networks”, Andrew S. Tanenbaum
[2] ”Internet Routing Architectures”, Bassam Halabi
[3] ”Computer Networks: A Systems Approach”, Bruce S. Davie, et al
[4] ”OSI Reference Model”, http://www.rad.com/networks/1994/osi/intro.htm
Clase 2 – 13 de febrero, 2002
2-35