2.

1 Historia
El precursor de Internet fue un experimento acadmico que se llev a cabo en los aos
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 relacin con Leonard Kleinrock de MIT2, Roberts se imagin ARPANET como una
red de rea amplia para la transmisin de la informacin en forma de paquetes. Una labor
basada en ideas similares se haba desarrollado en paralelo en la compaa RAND y en
NPL y algunos de sus estndares 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 lnea, 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 aos siguientes, se conectaron rpidamente ms 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). Ms tarde
en ese mismo ao, se aadieron las primeras conexiones a travs del pas, 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 bsico para lectura y envo de
mensajes por correo electrnico, impulsado por la necesidad de los programadores de
ARPANET de hacerse con un mecanismo de sencilla coordinacin. El email pronto pas a
ser la aplicacin ms de moda por ms de una dcada. La red ARPANET se convirti en
una oficina de correos digital de

G. Roberts, MIT: Towards a Cooperative Network of Time-Shared Computers, 1966

Leonard Kleinrock, MIT: Information Flow in Large Communication Nets, Mayo, 1961.

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 investigacin y tratar
temas de diversos intereses. Sin embargo, el rpido crecimiento de ARPANET cre la
necesidad de un software ms completo y de protocolos que controlaran una complejidad
cada vez mayor. En concreto, NCP confiaba en que ARPANET proporcionara una
fiabilidad completa. Si algn paquete se perda, el protocolo (y supuestamente cualquier
aplicacin que ste soportara) se estancaran. La colaboracin entre Robert Kahn (de
DARPA) y Vinton Cerf (de Standford) nos condujo hasta los protocolos actuales. En 19784
publicaron la especificacin del Transmission Control Protocol (TCP) (Protocolo de control
de transmisin) 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 haba dividido en MILNET (la parte militar) y en lo que ms tarde
llegara 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 dems a principios de la dcada permitieron la interconexin de
algunas de estas redes.
A principios de los 80, la National Science Foundation (NSF) anunci abiertamente su
intencin de atender a la comunidad universitaria al completo. Como resultado de su
financiacin, en 1986 surgi NSFNET esto ms tarde constituira el pilar de las
comunicaciones de la primera Internet. La NSF tambin fund enormes centros
informticos en Princeton, Cornell, Pittsburgh, UIUC y UCSD para suministrar a cada
uno un alto poder informtico. Esto provoc un aumento de conexiones, sobre todo desde
las universidades. De hecho, aunque en 1986 existan algo ms de 5.000 hosts en
Internet, este nmero aumentara a ms de 28.000 durante el ao siguiente. Sin embargo,
el NSF haba prohibido el uso del pilar NSFNET, el segmento a escala nacional de la
NSFNET, para propsitos que no apoyasen la educacin y la investigacin.
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 lnea. 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, pgs. 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, haba menos de 200 ordenadores en lnea. En 1989, eran muchos ms de
100.000. Esto quera 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 ao 1984. El DNS permiti un mecanismo distribuido escalable para
resolver la jerarqua de los nombres de los hosts (ej. www.akamai.com) en una direccin
de Internet.
El aumento del tamao de Internet tambin desafi las capacidades de los enrutadores y
origin problemas de congestin de ancho de banda que los protocolos TCP/IP no haban
tenido en cuenta. En 1989, TCP haba sido revisado para facilitar el control de la
congestin y evitar as el colapso de la red. Los enrutadores se modificaron tambin para
controlar una complejidad que iba en aumento. Al principio, exista un nico algoritmo
distribuido para el enrutamiento, que fue implementado uniformemente por todos los
enrutadores de Internet. Cuando el nmero de redes en Internet se dispar, este diseo
inicial no pudo extenderse como se requera, as que se reemplaz por un modelo de
enrutamiento jerrquico, 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 vctima de su inesperado e imprevisto xito, fue desmantelada,
dejando una amplia red de redes conocida como Internet. El nmero de hosts super esta
vez los 300.000. Sin embargo, incluso en 1990, el trfico comercial estaba todava
prohibido en el eje de NSFNET. Durante este tiempo, exista un autntico miedo entre los
investigadores de que Internet se colapsase bajo su propio peso y por tanto se mostraba
reticencia a aumentar el trfico en ella. Finalmente, en 1991 se levant la veda comercial
y ello condujo al desarrollo de un gran nmero de aplicaciones de Internet.
En la University of Minnesota, un equipo dirigido por un programador informtico, Mark
MaCahill, dio a conocer gopher en 1991, el primer modo point-and-click de navegar por
los archivos de Internet. Diseado en un principio para facilitar las comunicaciones en el
campus, gopher se distribuy de forma gratuita en Internet. MaCahill lo llam la primera

aplicacin de Internet que hasta mam puede usar. 1991 fue tambin el ao en el que
Tim Berners-Lee, que trabajaba para CERN en Suiza, hizo pblico el primer cdigo
informtico 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) crearan finalmente un navegador grfico para el World
Wide Web llamado Mosaic. Andreesen continuara 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 ao, NFS cre InterNIC para facilitar
servicios especficos de Internet, como los relacionados con el registro y las bases de
datos del host. Por tanto, al final, la gestin de Internet se traslad hacia el dominio
pblico con una supervisin 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 haba 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
investigacin a ms de 155 Mbps.
Internet est muy lejos de aquellos cuatro host que se conectaron en lnea en 1969. En el
ao 2002, haba aproximadamente 350 millones de hosts un nmero que se ha previsto
que crezca bastante. Los diseadores 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 intrnseca, no hay directorio ni ndice y el espacio para
las direcciones es diminuto.
La naturaleza descentralizada de Internet trae consigo muchos desafos 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 nmero de
diferentes servicios subyacentes que deben facilitarse. Entre estos se encuentran el envo
de bits a travs de varios medios de transmisin, datos de enrutamiento entre mquinas
de redes distintas, facilitar la deteccin del error, la correccin y una conectividad de
confianza, regular el flujo y la definicin de formatos para la aplicacin. La mayora de
estas funciones son en gran medida independientes de la red y son lo suficientemente
genricas para que se normalicen. Como consecuencia, y para reducir la complejidad del
diseo, las redes se disponen como una serie de capas o niveles, construidas unas sobre
otras. El nmero exacto, los nombres, contenidos y funciones de cada capa puede variar
de red a red, pero su propsito es ofrecer ciertos servicios a las capas ms altas,
5

Esta seccin 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

protegindolas de detalles sobre cmo 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 aade por regla general, informacin 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 aade 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 informacin de control como tamaos, tiempos y otros campos de este tipo.
Pueden contener tambin nmeros de secuencia (para permitir que la capa
correspondiente de la mquina destino entregue los mensajes en un orden adecuado si
las capas inferiores no mantienen la secuencia). Todo esto hace que el tamao de un
paquete tpico tenga un lmite de entre 46 y 1500 bytes.
Las entidades que constan de las correspondientes capas en mquinas distintas se
llaman peers. Las reglas y convenciones que se utilizan para la comunicacin entre stas
son conocidas como protocolos. Dicho de otro modo, un protocolo es fundamentalmente
un acuerdo entre las partes comunicantes sobre cmo debera transcurrir la comunicacin
(mediante la especificacin y el formato de los mensajes enviados entre los pares
iguales).
La arquitectura de capa de redes se ver ms detalladamente en el Apndice 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 aplicacin conoce mejor cules son sus verdaderos requisitos
comunicativos y que una capa ms baja trate de implementar cualquier caracterstica al
otro lado transportando como mnimo los datos, pone en peligro algo que no es
exactamente lo que se requiere, en cuyo caso, la aplicacin terminar volviendo a
implementar esa funcin de un modo distinto que sea ms til.
El argumento se explicar ms detalladamente en otra parte6
2.2.3

Protocolos contemporneos

J.H. Saltzer, D.P. Reed y D.D. Clark. End-to-End Arguments in System Design, MIT-LCS

En esta seccin se vern brevemente algunos de los protocolos usados con ms

frecuencia. Puede encontrar una descripcin ms exhaustiva de cada uno de ellos en el
documento RFC (Request For Comment) (Peticin 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 dems protocolos puestos finalmente en capas sobre IP o usados para apoyar a
IP desde abajo.
IP es el protocolo ms bsico 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 comunicacin que puede transportar paquetes IP. Casi
todas las dems 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 informacin relativa a las direcciones. Adems, IP no
hace ningn 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 verificacin 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 travs de la
red.
Fragmentacin: los paquetes IP pueden estar divididos o fragmentados en
paquetes pequeos. Esto permite que un paquete grande viaje por una red que
slo puede manejar paquetes ms pequeos. 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 priorizacin del trfico 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
travs de la red (enrutamiento fuente), que encuentre la ruta que el paquete toma
(grabacin 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
operacin 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:

Los RFCs pertinentes pueden encontrarse en: www.ietf.org, www.w3.org y www.freesoft.org

Notificacin 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 algn tipo de fallo. Un
paquete TCP o UDP dirigido a un nmero de puerto sin destinatario adjunto
tambin se presenta mediante ICMP.
Notificacin de congestin: cuando un enrutador empieza a acumular en el bfer
demasiados paquetes por no ser capaz de transmitirlos tan rpidamente como
stos se reciben, ste generar mensajes ICMP de disminucin del trfico desde
el origen. Dirigidos al remitente, estos mensajes deberan hacer que se
disminuyera la velocidad de transmisin del paquete. Por supuesto, generar
demasiados mensajes de este tipo provocara an ms congestin en la red, de
modo que se utilizan con moderacin.
Notificacin del tiempo de espera: si el campo TTL de un paquete IP baja a cero,
el enrutador, deshacindose 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 pequeos y vigilando las
mensajes ICMP de tiempo de espera.
Ayuda para la resolucin de problemas: ICMP admite una funcin Eco, que
simplemente enva un paquete entre dos hosts en un viaje de ida y vuelta. Ping,
que es una herramienta comn de gestin de red, est basado en esta
caracterstica. 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
prdidas.

2.2.3.3 Protocolo de control de transmisin (TCP)

Este protocolo est pensado en gran medida para compensar las deficiencias de IP,
proporcionando conexiones de secuencias fiables que oculten la mayora de los defectos
de IP. El conjunto TCP/IP recibe este nombre porque la mayora de dichos protocolos
estn basados en TCP, que est a su vez implementado sobre IP.
TCP aade gran funcionalidad al servicio IP sobre el que se encuentra superpuesto:
Flujos: los datos de TCP estn organizados como un flujo de bytes, muy similar a
un fichero. El carcter 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 nmeros secuenciales se utilizan para coordinar cules son los
datos que se transmiten y reciben. TCP planear una retransmisin si determina
que los datos se han perdido.
Adaptacin a la red: TCP asimilar dinmicamente las caractersticas del retraso
de una red y regular su funcionamiento para maximizar el rendimiento sin
sobrecargar la red.
Control de flujo: TCP controla los bfers de datos y coordina el trfico, de forma
que sus bfers no se excedern. Los remitentes rpidos sern detenidos de vez
en cuando para que puedan seguir el ritmo de los destinatarios ms lentos.
Sea cual sea la aplicacin en concreto, TCP funciona casi siempre como transmisin fullduplex. Los algoritmos descritos a continuacin funcionan en ambas direcciones, de un
modo casi completamente independiente. Algunas veces es til pensar en una sesin
TCP como dos flujos de bytes por separado que viajan en direcciones opuestas. No existe
ningn mecanismo en TCP que asocie los datos de los flujos de bytes enviados con los
que viajan en sentido inverso. TCP muestra un comportamiento asimtrico (es decir,

transferencia de datos hacia delante pero no al revs), slo durante el inicio de conexin y
las secuencias de cierre o viceversa.
TCP utiliza un nmero de secuencia de 32 bits que cuenta los bytes del flujo de datos.
Cada paquete TCP contiene el nmero de secuencia inicial de los datos de ese paquete y
el nmero de secuencia (llamado nmero de reconocimiento) del ltimo byte recibido
desde el par remoto. Con esta informacin, se implementa un protocolo de ventana
deslizante. Los nmeros de secuencia que van hacia delante y que vuelven hacia atrs
son completamente independientes y cada par TCP debe controlar tanto su propio
nmero de secuencia como el nmero que el par remoto est usando.
TCP utiliza un nmero de indicativos de control para controlar la conexin. Algunos de
estos indicativos estn relacionados con un nico paquete, como el indicativo URG, que
seala los datos vlidos 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 nmero de secuencia. Cada indicativo ocupa un nico byte.
Cada punto final de una conexin TCP tendr un bfer para almacenar los datos que se
transmiten por la red antes de que la aplicacin est lista para leer esos datos. Esto
permite que la transferencia de red ocurra mientras las aplicaciones estn activas con otro
procesamiento, mejorando el rendimiento global.
Para evitar que la memoria intermedia se sature, TCP coloca un campo de Tamao de
ventana en cada paquete que transmite. Este campo contiene la cantidad de datos que
pueden transmitirse al bfer o memoria intermedia. Si este nmero desciende a cero, el
TCP remoto no puede enviar ms datos. Debe esperar hasta que el espacio del bfer est
disponible y reciba un paquete que anuncie que el valor del campo de tamao de ventana
no es cero.
En algunas ocasiones, el espacio del bfer es demasiado pequeo. Esto sucede cuando
el producto ancho de banda-retraso de la red sobrepasa el tamao del bfer. La solucin
ms sencilla consiste en aumentar la memoria intermedia, pero en casos extremos, el
mismo protocolo se convierte en un obstculo (porque no posee un tamao 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
ingls). 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 confirmacin. 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
lgica - cunto tiempo debemos esperar? no tiene una respuesta simple. Por cable
Ethernet, se necesitaran tan slo unos pocos microsegundos para obtener una
respuesta. Si el trfico debe fluir por la red Internet de rea amplia, uno o dos segundos
podran ser razonables durante periodos de mxima utilizacin. Si nos estamos
comunicando con un paquete de instrumentacin de un satlite, que va a toda velocidad
hacia Marte, podran necesitarse unos minutos antes de obtener una respuesta. No existe
respuesta para la pregunta cunto tiempo?
Todas las implementaciones TCP modernas tratan de responder a esta cuestin
controlando el intercambio normal de paquetes de datos y realizando un clculo del
tiempo que representa demasiado tiempo. Este proceso se conoce como clculo de
Round-Trip Time (RTT) (Tiempo de viaje completo). Los clculos de RTT constituyen uno
de los parmetros de rendimiento ms 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 conexin. Si el clculo de RTT es demasiado bajo, los paquetes se

retransmiten innecesariamente; si ste es demasiado alto, la conexin 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 conexin 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 ms que IP:
Nmeros de puerto: UDP proporciona nmeros de puerto de 16 bits para permitir
que mltiples procesos utilicen servicios UDP en el mismo host. Una direccin
UDP es la combinacin de una direccin IP de 32 bits y el nmero de puerto de 16
bits.
Suma de verificacin: 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
verificacin simplemente se descarta y no lleva a cabo ninguna otra accin.
2.2.3.5 Protocolo simple de transferencia de correo (SMTP)
ste es el protocolo estndar de Internet para la transferencia de correo electrnico host a
host (entre sistemas) y acta tradicionalmente sobre el puerto TCP 25. Es decir, un
usuario de UNIX puede escribir telnet y a continuacin el nombre del host 25 y conectar
con un servidor SMTP, si hay uno presente.
SMTP usa un tipo de protocolo asimtrico de peticin-respuesta, de moda a comienzos de
los 80, que an se ve ocasionalmente, la mayora de las veces en protocolos de correo. El
protocolo est diseado para ser tan til para el ordenador como para el hombre, aunque
no muestra demasiada compasin 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 lnea y aparecen
enumerados bajo el comando HELP. Desde el punto de vista del remitente, las respuestas
al comando adoptan siempre la forma de lneas de texto, que comienzan cada una por un
cdigo de tres dgitos que identifica el resultado de la operacin, un carcter de
continuacin para indicar las otras lneas que siguen y adems, informacin textual
arbitraria con carcter informativo para el hombre.
Si la entrega de correo falla, sendmail (la implementacin SMTP ms importante) pondr
los mensajes de correo en cola y volver a intentar la entrega ms tarde. Sin embargo, se
usa un algoritmo de backoff, no hay ningn mecanismo para enviar todos los elementos
hosts de Internet por mail, SMTP no facilita ningn servicio de buzn de correo o cualquier
elemento especial aparte de la transferencia de correo electrnico. Por estas razones,
SMTP no es una buena eleccin para los hosts que estn situados detrs de lneas
sumamente inciertas (como los mdems). Se puede designar a un host con mejor
conexin, como un DNS encargado del intercambio de correo, adems de organizar un
plan de transmisin. 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 peridica 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 conexin queda descartada ya que no permite
un pleno acceso a Internet.

2.2.3.6 Protocolo simple de gestin de red (SNMP)

Este es bsicamente un protocolo de peticin-respuesta que se ejecuta sobre UDP (en los
puertos 161 y 162), aunque la operacin TCP es posible. SNMP es un protocolo
asimtrico, que opera entre una estacin de gestin (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 funcin genrica get o set sobre sus variables de MIB. La
estacin de gestin presenta la interfaz del usuario. Las estaciones de gestin simples
pueden construirse con los servicios de la lnea comandos UNIX. Otros ms complejos (y
caros) recopilan datos del mdulo MIB durante el tiempo y utilizan las GUI para trazar
mapas de red.
Una operacin SNMP adopta la forma de Unidad de datos de protocolo (PDU), que es
bsicamente una palabra elegante para referirse a un paquete. La versin 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 estacin de administracin sobre los resultados de una
GetRequest o SetRequest devolviendo una indicacin 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 estacin de administracin no conoce el nombre exacto MIB
del objeto que solicita. GetNextRequest no requiere la especificacin 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 caracterstica,
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 estacin de administracin sobre un evento poco comn que pueda
requerir una atencin especial (como un enlace que falla). En la versin 2, las
traps se nombran en el espacio del MIB. Los MIB ms recientes especifican los
objetos de administracin que controlan la forma en que se envan 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 conexin correcta, el cliente transmite un mensaje de
solicitud al servidor, que enva un mensaje de respuesta. Los mensajes HTTP pueden ser
ledos por el hombre y un servidor HTTP puede funcionar manualmente con un comando
como el servidor telnet 80.
El mensaje HTTP ms 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 mtodo
ofrece una reducida gestin de errores y su uso se ha descartado por el del mtodo ms
completo que se describir a continuacin.
Un mensaje completo HTTP 1.0 comienza por GET url HTTP/1.0. La adicin del tercer
campo indica que se utilizan cabeceras completas. El cliente puede enviar entonces
campos adicionales de cabeceras (uno por lnea) terminando el mensaje con una lnea en
blanco. El servidor contesta de forma similar, primero con una serie de lneas de
cabecera, luego con una lnea en blanco y, por ltimo, con el documento propiamente
dicho.

A continuacin 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 utilizacin de cabeceras completas se recomienda por varios motivos:
La primera lnea de una cabecera de servidor incluye un cdigo de respuesta
indicando el xito o el fallo en la operacin.
Uno de los campos de cabecera del servidor ser Content-type:, que especifica el
tipo MIME que describe cmo se debe interpretar el documento.
Si el documento ha cambiado de lugar, el servidor puede especificar su nueva
ubicacin 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 ms
rpidos puedan rastrear a los clientes en las solicitudes.
Adems de las solicitudes GET, los clientes tambin pueden enviar solicitudes HEAD y
POST, de las cuales, las POST son las ms 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 lnea en blanco, el cliente enva los
datos. La cabecera debe contener un campo Content-Length:, que permite que el servidor
determine cundo 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 ms antiguos, que sigue utilizndose de
forma generalizada y que se implementa utilizando el protocolo TCP.
Los objetivos del FTP son:
Promocionar la comparticin de archivos (programas informticos 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 diseado
fundamentalmente para que lo utilicen los programas.

2.3 Direccionamiento
2.3.1

Direccionamiento bsico

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. Estn formadas por un nmero de 32 bits, representado con una
notacin 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 direccin 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. Adems, el direccionamiento IP tambin admite
asignaciones por interfaz. Esto quiere decir que las direcciones IP se asignan
basndose 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 podra tener una direccin IP para cada una de ellas. Dicho de otro modo,
una direccin IP no necesita hacer referencia a un host. Es ms, a lo que hace referencia
es a una interfaz.
Cada direccin consta de dos partes: un nmero de red y un nmero de host. En los
albores de Internet, las fronteras de estas dos partes venan definidas nicamente por la
clase de direccin IP y este mtodo de direccionamiento reciba el nombre de modelo de
clases. Existen cinco clases principales (de la A a la E) y a continuacin 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 nmero 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 limitacin de todos los hosts de una red a contener el mismo nmero 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 nmero 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 nmero de red que,
posteriormente, debe anunciarse. Adems, mover una mquina de una LAN a otra
requiere modificar su direccin IP y esto, a su vez, implica la modificacin de los archivos
de configuracin y un cambio de entorno, mientras que la otra mquina, al adoptar una
direccin IP de reciente creacin, puede recibir datos que en realidad iban dirigidos a la
mquina anterior.
Con el fin de solucionar estos problemas, se introdujo el concepto de subred como
ampliacin al sistema original creado a mediados de la dcada de 1980. Este concepto
hace referencia a la subdivisin de una red basada en clases en varias subredes (esta
definicin se actualizar en las siguientes secciones para reflejar la introduccin del
enrutamiento sin clases). Como resultado, la empresa mencionada anteriormente podra
comenzar con una direccin de clase B y no con una de clase C y, a medida que las
necesidades de la mquina aumentasen, podra optar por dividir su nmero de host de 16
bits en un nmero de subred de 8 bits y otro nmero de host de 8 bits, consiguiendo 256
LAN, cada una de ellas con 256 hosts. Este cambio no sera apreciable de forma externa,
por lo que la adjudicacin 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 reduccin drstica del tamao de las
tablas de enrutamiento. Esto se basa en el hecho de que cada enrutador slo 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 direccin en la cabecera del paquete IP y en la mscara de subred
del enrutador. sta ltima es un nmero de 32 bits que determina cmo se divide una
direccin IP en porciones de red y de host. Por ejemplo, en una red estndar de clase B,
la mscara 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 porcin de red se ampla. Ms concretamente, una
mscara de subred de 255.255.255.0 dividira el espacio de la direccin de clase B
utilizando su tercer byte, y sera necesaria para generar 256 LAN, cada una de ellas con
256 hosts. Al ejecutar un AND de la direccin IP del paquete y de la mscara de subred,
el enrutador puede deshacerse de la parte host del nmero y buscar el resultado en su
tabla para decidir sobre un posterior redireccionamiento si fuera necesario. Como las
mscaras de subred se utilizan bit a bit, mscaras 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
informacin 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 trfico que fluya por otras redes.
2.3.3

El problema de los tres osos

En teora, 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 prctica 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 pequea. Una red de

clase B con 65.536 direcciones tiene el tamao justo. Inspirada en el cuento de Ricitos de
oro y los tres osos, esta situacin se conoce como el problema de los tres osos en la
jerga de Internet.
Como resultado, se utiliza un nmero cada vez mayor de redes de clase C, por lo que se
ha producido un aumento vertiginoso en el tamao de las tablas de enrutamiento, hecho
ste que complica an ms los casos en el modelo de clases.
Finalmente, junto con los dos problemas planteados arriba, la creciente demanda de
direcciones IP tambin ha generado una necesidad de convertir el proceso de asignacin
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 bsicos de CIDR

CIDR es un sustituto del proceso de asignacin 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 slo 32 hosts o a aqullas que tienen ms de 500.000. Con esto se consigue que
la asignacin de direcciones sea mucho ms precisa y se ajuste a las necesidades
concretas de una empresa.
Una direccin CIDR incluye:
La direccin IP estndar de 32 bits.
Informacin 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 direccin 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 definicin de subred se ha actualizado a la
subdivisin de un bloque CIDR en varios bloques CIDR ms pequeos. Es importante
mencionar en este punto que el lmite del prefijo para las direcciones CIDR no est
obligado a ser mayor que el de las mscaras naturales de red. Las redes existen donde el
lmite del prefijo contiene menos bits que la mscara natural de red y stas reciben el
nombre de superredes. Por ejemplo, una red de clase C 198.32.1.0 tiene una mscara
natural de 255.255.255.0 (mscara creada por la propia definicin de la red y por las
proporciones de hosts de cada clase, es decir, una clase A tiene una mscara natural de
255.0.0.0, una clase B, una de 255.255.0.0, etc.). La representacin 198.32.0.0/16, por
otra parte, tiene una mscara ms corta que la natural y es, en consecuencia, una
superred segn nuestra definicin.
2.3.4.2 Adicin de enrutamiento jerrquico para minimizar las entradas de la tabla de
enrutamiento
El mtodo CIDR (en concreto, la posibilidad de crear superredes tal y como se entienden
en la seccin anterior) permite la adicin de enrutamiento, que consiste en la capacidad
de fusionar varios prefijos que tengan cierto nmero de bits de peso en comn. De forma
alternativa, la adicin tambin puede explicarse como una situacin 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 continuacin:

204.71.1.0/24 asignado a PequeoCliente1 204.71.2.0/24 asignado a PequeoCliente2

204.71.128.0/22 asignado a ClienteMedio 204.71.136.0/20 asignado a ClienteGrande.
Durante el intercambio de informacin con otros ISP, ISP1 slo 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 mtodo resulta ser una estructura ms organizada similar a la de las redes
telefnicas. Un nodo de red de eje de alto nivel slo analiza los bits ms altos y luego
encamina el paquete al nodo del eje especfico responsable. ste, a continuacin, busca
en los bits ms bajos y encamina el paquete a los nodos subtendidos que son
responsables. Al aplicar esta tcnica de forma recurrente, los paquetes terminan por
alcanzar su destino. En general, CIDR termina siendo una estructura nueva de Internet,
ms jerrquica, 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. Adems de la reduccin intrnseca del
tamao de las tablas de enrutamiento, este enfoque tambin consigue lograr un sistema
en el que, ms que buscar asignaciones de direcciones directamente desde InterNIC,
resulta posible obtenerlas de forma descentralizada.
2.3.4.3 Regla de enrutamiento de coincidencia ms especfica
Encaminar a todos los destinos utilizando la tcnica 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
mscara ms larga. Por ejemplo, un enrutador con las siguientes dos rutas en su tabla de
enrutamiento:
198.32.1.0/24 a travs de la ruta 1 198.32.0.0/16 a travs de la ruta 2
intentar buscar coincidencias del host 198.32.1.1 con el destino que tenga el prefijo ms
largo y, en consecuencia, se enviar el trfico por la ruta 1. Dicho de otra manera, las
redes ms especficas (en el sentido de que son una subred del total o de un bloque
CIDR) prevalecen, ya que ofrecen ms informacin sobre la ubicacin de una red.
2.3.4.4 Problemas asociados a la adicin
La adicin, si no se aplica correctamente, podra conllevar la aparicin de agujeros
negros. Esto tiene lugar cuando el trfico llega y se detiene en una mquina que no
representa el destino esperado, pero en la que no es posible efectuar un reenvo. Estas
situaciones pueden darse, por ejemplo, si un cliente se conecta a un proveedor nico y
tiene un espacio de direccin IP totalmente distinto. Esto podra ser el resultado de un
cambio de proveedores por parte del cliente sin haber modificado antes la direccin de
asignacin. 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 aadir la
direccin y, adems, 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 direccin. El efecto
global de la utilizacin de direcciones ajenas al espacio de la direccin del proveedor se
resume en que se deben instalar ms rutas en las tablas de enrutamiento globales. Otra
situacin que podra 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 slo 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 algn cliente que no est en multihome con ellos
y cualquier adicin podra crear un agujero negro. En consecuencia, los ISP deben

observar cada uno de estos rangos de direcciones IP que tienen en comn con otro ISP
ms all de su propio espacio de direcciones. stas son a menudo ms especficas que
las direcciones para el bloque CIDR del ISP que las asign originalmente y, por lo tanto, el
trfico se encamina fundamentalmente a travs de los ISP que no emitieron la IP.
Una solucin para estos clientes multihome es adquirir IP de cada uno de los ISP a los
que estn conectados, pero esto provoca la prdida de rutas en la organizacin
multihome. Si uno de los ISP tiene problemas, el trfico del host multihome de la IP
obtenida desde ese ISP se perder, ya que no se publica en ningn otro lugar. Este hecho
anula, en gran parte, el propsito del multihoming. Un enfoque alternativo requiere tomar
una direccin totalmente distinta del espacio de direccin 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 especfica a estas direcciones de nueva
creacin, con lo que se generaran 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 debera ser suficiente para cualquiera - Bill Gates, 1981
32 bits debera ser espacio suficiente para las direcciones - Vinton Cerf, 1977

Con el gran crecimiento inesperado y sin precedentes de Internet, se ha hecho cada vez
ms obvio que los das del IPv4 (la implementacin actual del protocolo IP analizada en
secciones anteriores) estn contados. Los problemas de disminucin de espacio de
direcciones y el control de un registro central siguen estando ah y la llegada del CIDR
slo ha servido como parche temporal. Actualmente, los registros no pueden dar
respuesta a solicitudes de grandes bloques IP y se espera que para el ao 2008 las
direcciones IPv4 se hayan terminado. Este hecho proviene del aumento de las
comunicaciones mviles de tercera generacin, la demanda impuesta por los pases
emergentes que no estuvieron presentes en la fiebre del oro del IPv4 y la llegada de las
redes locales. Adems, est el aumento drstico del tamao de las tablas de rutas (que
ascienden a aproximadamente 60.000 entradas en la actualidad) debido a una falta
inherente de cualquier red o consideracin de enrutamiento. Dejando a un lado los
problemas de la memoria esttica, esto provoca una degradacin del rendimiento, ya que
los algoritmos actuales no escalan de forma lineal. El IPv4 tambin 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 tambin puede denominarse
como ausencia de calidad de servicio o CdS y se suele entender como la limitacin
para ir ms all del servicio de datagrama de mejor esfuerzo disponible en la actualidad,
que se centra solamente en una mtrica arbitraria nica: el peso administrativo o el
recuento de saltos. Por ltimo, el IPv4 tambin parece adolecer de la ausencia de un
mecanismo intrnseco 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 prdidas de privacidad, prdidas de integridad de
datos, intercambios de identidades o negaciones del servicio.
Quiz el problema ms imperioso al que se enfrenta la Internet IP es la disminucin de
direcciones. Las soluciones concebidas a corto y largo plazo estn an en fase de
desarrollo. La solucin 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 ms 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 solucin: alguna forma de

reutilizacin de direcciones, ya sea complementando al CIDR o relegndolo al olvido. La

solucin de reutilizacin 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 disminucin de direcciones. Las direcciones IP
globales nicas se asignan siguiendo los mtodos actuales de asignacin 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 tambin 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 solucin IPv6/Ipng

Para afrontar las limitaciones del IPv4, se ha propuesto un nuevo protocolo denominado
IPv6 o IPng (IP de nueva generacin). En la actualidad existe una infraestructura de IPv6
en Internet, pero an no se han implementado los DNS.
El IPv6 cuenta con varias caractersticas. Para empezar, proporciona un espacio de
direcciones aumentado de 128 bits que permite IP globales nicas para todos los
dispositivos. Adems, tambin ofrece un enrutamiento ms eficaz gracias a una
estructura jerrquica que consigue la asignacin de direcciones aadidas desde el
principio. Sin embargo, los clientes multihome representan un fracaso en esta jerarqua y
actualmente es bastante comn que las empresas recurran al multihome. El IPv6 tambin
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 trfico de 8 bits.
Por ltimo, los problemas de seguridad se abordan con la introduccin del IPSec, que
utiliza un nuevo conjunto de cabeceras aadidas para asegurar el payload del paquete IP.
stas incluyen la autenticacin de cabecera (AH) y el payload de seguridad encapsulado
(ESP).
2.3.7

La transicin del IPv4 al IPv6

La idea ms importante en la que se basa la transicin del IPv4 al IPv6 es que Internet es
demasiado grande y est demasiado descentralizada para tener un da D (un da
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 slo funcionan con el IPv4 puedan seguir operando tanto tiempo como
sea posible. No se espera la conclusin de este proceso hasta el ao 2010. Adems, la
aparicin de los NAT ha retrasado la adopcin generalizada del IPv6. Aunque son muchos
los que detestan los NAT, su uso proporciona la funcionalidad principal del IPv6: un mayor
nmero de direcciones de host. Los NAT han reducido hasta ahora de forma eficaz la
presin para implementar una solucin ms elegante a largo plazo al problema de la
8

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

disminucin de direcciones. El espacio de direcciones aumentado que brindan los NAT ha

conseguido que sean menos los que estn dispuestos a adoptar este nuevo protocolo de
red. Por lo tanto, parece que tendremos IPv4 para largo.
Sin embargo, tras la transicin, los nodos del IPv4 deberan (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 deberan poder comunicarse
con otros nodos del IPv6, incluso cuando parte de su infraestructura slo sea compatible
con el IPv4. Se han definido dos mecanismos principales para contribuir a esta transicin
y se analizan a continuacin.
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 versin de la cabecera para decidir en qu
pila se procesa el paquete recibido.
2.3.7.2 Tunelizacin
Se trata de la tcnica empleada en muchas situaciones en las que un paquete IP se enva
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 transicin del IPv6, la tunelizacin se utiliza
para enviar un paquete IPv6 a travs de una porcin de red que slo admita IPv4. Esto
significa que el paquete IPv6 se encapsula dentro de una cabecera de IPv4 que contenga
la direccin del punto final del tnel en su cabecera y se transmite a travs de una porcin
exclusiva de la red IPv4 para, despus, 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 desencapsulacin.

2.4 Enrutamiento
Internet est formada por millones de ordenadores y cualquier de ellos puede, en teora,
comunicarse con el otro. Sin embargo, no todos los equipos estn vinculados fsicamente
entre s y la informacin se transmite desde un punto a otro utilizando un paradigma de
almacenamiento y reenvo. Los paquetes de datos se transmiten entre equipos enlazados
fsicamente y se encaminan a travs de la red hacia sus destinos. Distintos protocolos de
enrutamiento son los que definen las reglas para el reenvo de los paquetes. En esta
seccin abordaremos el estudio de estos protocolos.
2.4.1

Modelo topolgico

La arquitectura de rea extensa de Internet est dividida en un nmero de sistemas

autnomos (AS) conectados arbitrariamente. Un AS es un conjunto de enrutadores y
hosts regidos por una administracin tcnica nica (normalmente una entidad comercial
nica) que utilizan uno o varios protocolos de pasarela interior (IGP) y mtricas 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 trmino sistema
autnomo refuerza en este caso el hecho de que, aunque se utilicen varios IGP y mtricas
distintas, la administracin 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 administracin tcnica comn. 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 trfico portado dentro de un AS comienza o termina en dicho AS (esto es,
o bien la direccin IP origen o la direccin IP de destino del paquete IP identifica un host
interno de dicho AS). El trfico que se ajusta a esta descripcin recibe el nombre de
trfico local. El trfico que no se ajusta a esta descripcin recibe el nombre de trfico de
trnsito. Teniendo en cuenta la forma concreta de un AS para gestionar el trfico de
trnsito, los AS pueden dividirse en las siguientes categoras:
AS de stub: es aqul que se conecta a otro AS. En lo que a enrutamiento se
refiere, podra entenderse como una simple ampliacin del otro AS. De hecho,
muchas redes con conexin simple a Internet no tienen un nmero nico de AS
asignado y sus direcciones de red se tratan como parte del AS padre.
AS de trnsito: tiene conexiones a ms de un AS y puede utilizarse como
conducto para el trfico (trfico de trnsito) entre otros AS. Los proveedores de
servicios de Internet ms importantes son AS de trnsito.
AS multihome: tiene conexiones a ms de un AS, pero no permite el paso del
trfico de trnsito, aunque sus hosts internos s pueden encaminar trfico a travs
de varios AS.
Se trata de la configuracin caracterstica de redes empresariales grandes con varias
conexiones redundantes a Internet, pero que no desean que el trfico de otros pase por
sus redes.
2.4.2

Tipos de protocolos de enrutamiento

Para una red determinada que pueda representarse como un grfico 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 envan actualizaciones
peridicas 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 ms corto (determinado por la normativa) que ofrece las rutas al
resto de los nodos disponibles.
Los algoritmos de protocolo DV slo utilizan la informacin de los nodos cercanos. Estos
protocolos suelen ser descentralizados e iterativos y estn basados en algoritmos como el
de Bellman-Ford para las rutas ms cortas. Los protocolos DV tambin suelen ser
relativamente escalables. El protocolo DV bsico recibe el nombre de protocolo de
informacin de enrutamiento (RIP). El protocolo de pasarela fronterizo (BGP) utiliza
esencialmente un algoritmo DV, pero con varios cambios aadidos. Trataremos este
asunto ms 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 informacin incorrecta. Podra
desembocar en bucles infinitos y desincronizar la red. La convergencia en los protocolos

DV suele ser baja. De hecho, la topologa 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
asignacin parcial de la red. Cuando una red cambia de estado (de activa a inactiva o
viceversa), se enva una notificacin 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 ms corta primero) es un ejemplo de
protocolo LS.
Como cada nodo da una buena idea del grfico de red y las actualizaciones slo
requieren la adicin o eliminacin de nodos y extremos, los protocolos LS convergen ms
rpidamente hacia un estado estable que los protocolos DV. Tambin son ms fiables,
fciles de depurar y con menor intensidad de ancho de banda que los protocolos DV.
Por otro lado, los protocolos LS suelen ser ms complejos que los protocolos DV.
Tambin tienden a ser ms intensivos en trminos de memoria y de clculo 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 optimizacin de una mtrica 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 informacin entre sistemas
autnomos en la Internet global. Se trata de un protocolo distancia-vector que permite que
cada AS ignore la mtrica basada en la distancia con mtricas basadas en normativas
cuando se seleccionan las mejores rutas.
2.4.3.1 Motivaciones de diseo
El diseo de un BGP estuvo motivado por tres importantes necesidades:
Escalabilidad. La divisin 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
nmero 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 diseo. 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 priorizacin de las
preferencias locales.
Cooperacin en circunstancias competitivas. El BGP se dise en gran parte para
gestionar la transicin desde NSFNET hacia una situacin en la que la infraestructura
principal ya no se ejecutase mediante una entidad administrativa. El enrutamiento en
Internet se gestionara mediante un gran nmero de ISP mutuamente competitivos que
cooperaran 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 disposicin
cualquier conjunto de posibilidades.
2-20

MIT 18.996

Clase 2 13 de febrero, 2002

Primavera de 2002

Figure 2.4. Sistemas autnomos 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 autnomos con relaciones
de peering entre s. Esto crea un grfico no dirigido en el que los vrtices representan los
AS y los extremos representan las conexiones directas fiables entre los AS. Cada vrtice
mantiene el rbol encaminado de ruta ms corta especificando las mejores rutas a los
otros vrtices. Las rutas son seleccionadas por cada AS basndose en su propia
normativa y en las mejores rutas prximas.
Un vrtice reconoce el conjunto de rutas disponibles mediante los anuncios de las rutas
prximas. Los vrtices envan dichos anuncios siempre que las tablas de enrutamiento
cambian. Estos anuncios contienen, entre otros, informacin 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 vrtice tiene ms de una ruta en un destino determinado, se selecciona la
mejor de todas. Primero se selecciona segn las preferencias locales del vrtice y, a
continuacin, se escoge la ruta con la distancia-vector ms corta. Las coincidencias se
solucionan de forma arbitraria.
Los anuncios de rutas sufren transformaciones a medida que pasan de un vrtice al
siguiente. En concreto, cada vez que se transmite una ruta, el vrtice adjunta su
identificador a la ruta-vector de la ruta. Los bucles pueden evitarse de esta manera, ya
que ningn vrtice acepta anuncios de ruta cuya ruta-vector aparezca en el propio vrtice.
A medida que los anuncios se propagan por la red, cada vrtice mejora de forma iterativa
su visin del resto de las rutas disponibles. Por ltimo, se espera que el sistema converja
a un estado estable. En este estado final, cada vrtice conoce la mejor ruta hacia el resto
de los vrtices. Como existen preferencias locales, la definicin sobre qu hace que una
ruta sea la mejor puede variar de nodo A medida que los anuncios se propagan por la
red, cada vrtice mejora de forma iterativa su visin del resto de las rutas disponibles. Por
ltimo, se espera que el sistema converja a un estado estable. En este estado final, cada
vrtice conoce la mejor ruta hacia el resto de los vrtices. Como existen preferencias
locales, la definicin 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
conexin TCP fiable entre uno y otro e intercambian mensajes para abrir y confirmar los
parmetros de conexin. El flujo inicial de datos es la tabla de enrutamiento BGP al
completo. Ms tarde, se envan 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 eliminacin de mensajes si sus AS ya estn presentes en este vector.
Un enrutador utiliza normativas de importacin para transformar las actualizaciones de
ruta entrantes. Estas normativas de importacin incluyen la negacin de una actualizacin
o la aceptacin de la actualizacin y la asignacin de una preferencia local para indicar el
grado de aptitud de la ruta. De forma similar, las normativas de exportacin 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 mxima prioridad en la seleccin. La longitud de la ruta-vector del
AS es el segundo criterio ms importante. Puede que no sea la distancia ms corta, ya
que slo debe contar el nmero de AS que se necesitan encaminar. Los enrutadores
tambin pueden utilizar la ruta del AS mediante la repeticin de los identificadores del AS
para localizar las rutas menos aptas a otros AS. Por ltimo, sealar que las coincidencias
se evitan de forma arbitraria. Debido a estos factores y a algunas decisiones de
implementacin de enrutadores especficas de los proveedores, resulta prcticamente
imposible determina las mejores rutas slo a partir de las relaciones de conectividad.
BGP utiliza TCP, lo que proporciona un envo ordenado y fiable y no necesita una
actualizacin peridica de toda la tabla de enrutamiento. Un portavoz BGP debe, por lo
tanto, retener la versin actual de todas las tablas de enrutamiento BGP y de todos sus
peers en la duracin de la conexin. Los mensajes KeepAlive se envan de forma
peridica en las dos direcciones para garantizar que la sesin BGP sigue ejecutndose.
Si no existen dichos mensajes, la sesin BGP se cierra y todas las rutas adquiridas en
dicha sesin se eliminan de las tablas de enrutamiento de sus respectivos peers.
Los mensajes de notificacin se envan como respuesta a errores o condiciones
especiales. Si una conexin presenta una condicin de error, se enviar un mensaje de
notificacin y se cerrar la conexin. Sin embargo, el BGP no se dise para gozar de
una rpida deteccin y recuperacin de fallos, por lo que estos mecanismo no suelen ser
especialmente tiles en escalas de tiempo pequeas.

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 estndar en el que se utiliza BGP. Los enrutadores
fronterizos de un AS determinado se conectan a los enrutadores de otros AS a travs 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 travs 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 trnsito para
otros AS (como suele ser el caso, al menos para un nmero reducido de rutas), debe
prestarse atencin para garantizar una visibilidad constante de las rutas dentro del AS.
En general, cada AS tendr ms de un enrutador fronterizo que participar en las sesiones
eBGP con los AS prximos. Durante este proceso, cada enrutador eBGP obtendr
informacin sobre algn subconjunto de reglas conocidas por el AS. Como uno de los
objetivos del BGP es permitir que cada AS sea tratado como una entidad monoltica
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
informacin 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 informacin contenida en el resto.

2-23

MIT 18.996

Clase 2 13 de febrero, 2002

Primavera de 2002

Es importante sealar que un iBGP no es un IGP como RIP o OSPF. De hecho, los mensajes
enviados durante una sesin iBGP se encaminan dentro del AS con cualquier IGP que est
operativo. Las sesiones iBGP slo proporcionan un medio por el cual los enrutadores dentro de
un AS pueden utilizar el mismo protocolo (BGP) para intercambiar informacin completa.
2.4.3.2.5 La cuestin de la convergencia
Informalmente, un sistema BGP puede representarse por un estado S = <G, Normativa(G), S0>,
incluyendo un grfico AS G = (V, E), y conteniendo normativas de importacin 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 activacin de cualquier vj, el sistema
permanece en el estado S. Una secuencia de activacin del sistema simplemente es una
secuencia que proporciona los vrtices 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 activacin. 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 mayora 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 garanta alguna de que la interaccin de normativas definidas independientemente
puedan ser razonables globalmente. En teora, un conjunto de normativas bien configuradas
localmente puede seguir provocando anomalas 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 podra contribuir a una gran cantidad de inestabilidad en el sistema de
enrutamiento global. La fluctuacin de la topologa 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 creacin de agujeros negros en paquetes (con rutas de anuncios de AS que, en
esencia, no tiene y con la eliminacin de paquetes que se envan 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 seccin se incluye un ejemplo de un sistema BGP no soluble denominado Bad
Gadget (mal aparato). Ninguna ejecucin 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 visin 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 travs de una secuencia de cuatro activaciones. Los nodos negros
representan un nodo activndose, es decir, anunciando sus rutas. Las flechas rojas indican
las rutas.
En (1) no se han realizado anuncios y ningn nodo conoce las rutas. En (2) el nodo 0 anuncia
todas las rutas directas hacia l y cada nodo toma la conexin 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
ms 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 ms 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 intuicin. A continuacin se incluye una visin general de la prueba.
Para que este sistema tenga una solucin debe lograr un estado final. Es fcil ver que en el
caso de sistemas de destino nico, en un estado final el grfico inducido por la ruta del AS de
cada vrtice al destino es un rbol con races en el destino y que este estado final puede
alcanzarse mediante la activacin de todos los nodos del primer orden del rbol (esta
conclusin est extrada del documento). Utilizando este hecho, podemos demostrar que este
sistema es divergente.
Slo es necesario tener en cuenta diecisis rboles extendidos con raz en AS 0. Cualquier
rbol que no se expanda en este grfico no puede ser una solucin, ya que cada AS 1, 2 y 3
tiene una ruta directa hacia d. Adems, al tratarse de un sistema simtrico, slo 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 activacin 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 cambiarn su seleccin de mejores rutas hacia d estn marcados
con un crculo 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 fcil ver que el sistema no tiene
solucin.
Este sistema divergente podra parecer un ejemplo artificioso y hacernos pensar que en la prctica
esta divergencia podra cuestionarse en un BGP. En la siguiente seccin 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 prctica? Existen varias historias horribles sobre redes que de forma
accidental se establecieron de forma autnoma como sumideros de trfico y hay algunas pruebas
sobre oscilaciones crnicas.
Tambin 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 comnmente estaban basados en el procesador de la serie
relativamente ligera 68000 de Motorola. La alta inestabilidad sola 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
agitacin de rutas. En este modo de oscilacin patolgica, 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 travs del enrutador inactivo y transmite actualizaciones que reflejan el cambio de la
topologa en cada uno de sus peers. Por su parte, tras la recuperacin de problemas transitorios de
CPU, el enrutador fallido intentar reiniciar una sesin BGP de peering con cada uno de los otros
enrutadores y generar un estado de transmisiones dump. Esta carga aumentada provocar que
an ms enrutadores fallen e iniciar una tormenta que comenzar a afectar a secciones ms
grandes de Internet. Varias de las tormentas de agitacin de rutas ocurridas hasta ahora han
causado la inactividad de millones de clientes de red. La ltima generacin de enrutadores de
varios proveedores proporciona un mecanismo por el cual el trfico 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 implementacin concretas de ciertos proveedores. Sin embargo, tras el
desarrollo de enrutadores actualizados por los ISP, esta inestabilidad ha decrecido en gran medida.
La heurstica como la disminucin de los anuncios de rutas tambin ha mejorado las propiedades del
BGP. As que, aunque en teora es posible que BGP diverja, se ha demostrado empricamente 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 geogrficos. Observaron desfases que ascendan 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. Adems de las
distintas anomalas especficas de cada proveedor, la razn fundamental para la convergencia pasa
por que los protocolos de ruta-vector consideran varias rutas de una longitud determinada en
contraposicin a los protocolos de distancia-vector, que slo 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 nmero 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 nmero de portavoces
BGP no predeterminados en un grfico completo con normativa predeterminada. Adems, no existe
ningn conocimiento global en los protocolos de ruta-vector, por lo que las heursticas de
optimizacin 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 autnomos vinculada por un BGP y un destino accesible desde un
vrtice (x), en ocasiones es til saber si el destino es accesible desde cualquier otro vrtice (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 determinacin de la existencia de la accesibilidad en un
sistema BGP es NP-completa. Esto puede demostrarse mediante la reduccin 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 informacin de
accesibilidad entre AS a los usuarios de Internet. El registro de enrutamiento de Internet (IRR,
del que RADB
forma parte) mantiene la informacin de enrutamiento de los ISP por separado en varios
depsitos pblicos como intento de coordinacin de una normativa de enrutamiento global. La
base de datos de la normativa de enrutamiento del IRR incluye informacin 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 travs de la
infraestructura de red del registrador.
Hasta no hace mucho, se ha advertido un especial inters por el estudio y el diseo de la topologa
de Internet, especialmente en el nivel de los sistemas autnomos (AS). En la actualidad, estas
actividades se consideran ms como medidas de anlisis y diseo (en su mayora a partir de
bases de datos como la RADB) para deducir el grfico de conectividad de los AS de Internet y
describir sus propiedades, explicando los orgenes y las causas de algunas de las funciones
observadas ms sorprendentes y diseando simuladores que generan estructuras de grficos que
coincidan con los grficos de conectividad AS medidos. Tambin 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 nmero significativo de conexiones AS
existentes permanecen ocultas en la mayora 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
informacin proporcionada a la RADB puede ser filtrada de forma selectiva por las empresas. Por
ejemplo, se sabe que un nmero creciente de ISP utilizan el IRR para filtrar los anuncios de rutas
en los enrutadores fronterizos (la mayora 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 ms propiedades el protocolo BGP, tanto de forma matemtica
como empricamente. A continuacin 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 grfico de evaluacin, Eval(S), se define como el grfico que se
dirigir, en cada estado s accesible hay un vrtice etiquetado por s en Eval(S) y si s y s son estados
accesibles y las transiciones a s y a s con la activacin de algn conjunto de vrtices no vaco 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 vrtices (v) del conjunto de vrtices del sistema BGP existe un extremo
entre s y s llamado v.
Asimetra
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 asimetra 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 oscilacin de protocolo que no termine nunca.
Solubilidad/Insolubilidad (SD)
Dado un sistema S con un nico destino d originado por algn 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 subgrfico de Eval(S) que (1) no contiene un estado final y (2) no tiene arcos
dirigidos hacia el subgrfico. Este problema es NP-hard.
Solidez K
Dado un sistema soluble S que slo tiene un nico destino d originado por algn AS w, permanecer S
soluble ante un posible fallo de k vnculos? 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 aplicacin
PPDU Unidad de datos de protocolo de presentacin
SPDU Unidad de datos de protocolo de sesin
TPDU Unidad de datos de protocolo de transferencia

Apndice A
El modelo OSI est formado por:
1. Capa fsica: La capa fsica est relacionada con la transmisin de bits sin compresin
en un canal de comunicacin. Los problemas de diseo estn relacionados con
garantizar que cuando un extremo enva 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, cuntos microsegundos tarda un
bit, si la transmisin se realiza de forma simultnea en las dos direcciones, cmo se
establece la conexin inicial y cmo se concluye cuando los dos extremos han
terminado y cuntos pins tiene un conector de red y cuntos se utilizan. Los problemas
de diseo tienen que ver, en gran parte, con interfaces mecnicas, elctricas y de
procedimientos y con el medio de transmisin fsica, que se encuentra debajo de la
capa fsica. El diseo de la capa fsica puede considerarse dentro del dominio de la
ingeniera elctrica.
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 transmisin sin compresin y transformarlo en una lnea libre de
errores de transmisin 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 recepcin devueltos por el
receptor. Como la capa fsica slo 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 lmites 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 atencin 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 diseo es determinar cuntos paquetes se
encaminan desde el origen hasta el destino. Las rutas deben estar basadas en tablas
estticas que estn enlazadas con la red y que no suelen cambiar. Tambin deben
calcularse al principio de cada conexin, por ejemplo, en una sesin de terminal.
Finalmente, pueden ser muy dinmicas 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, interferirn entre s y formarn cuellos de botella. El control
de estas congestiones tambin es responsabilidad de la capa de red.
Ejemplo: IPv4, IPv6.
4. Capa de transporte: la funcin bsica de la capa de transporte es aceptar datos
en una capa de sesin, dividirlos en unidades ms pequeas si es necesario,
enviarlos a la capa de red y garantizar que todas las partes llegan correctamente al
otro extremo. Adems, todo esto debe realizarse de forma eficiente aislando la capa
de sesin de los posibles cambios que puedan producirse en la tecnologa del
hardware. En condiciones normales, la capa de transporte crea una conexin distinta
de red para cada conexin de transporte necesaria para la capa de sesin. Ahora
bien, si la conexin 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 conexin de red
resulta caro, la capa de transporte puede multiplexar varias conexiones de transporte
en la misma conexin 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
sesin. La capa de transporte tambin determine el tipo de servicio ofrecido a la capa
de sesin y, en ltima instancia, los usuarios de la red. El tipo ms usual de conexin
de transporte es un canal punto a punto sin errores que enva mensajes en el orden
en que fueron enviados. No obstante, tambin son posibles otros tipos de transporte,
de servicio y de mensajes aislados de transporte sin garanta alguna sobre el orden
de envo, as como difusin de mensajes a varios destinos. El tipo de servicio viene
determinado cuando se establece la conexin. La capa de transporte es una capa real
punto a punto y origen a destino. Dicho de otra manera, un programa de la mquina
origen mantiene una conversacin con un programa similar en la mquina 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 sesin: la capa de sesin permite que usuarios de distintas mquinas
puedan establecer sesiones entre s. Una sesin permite el transporte comn de
datos, tal y como ocurre con la capa de transporte, pero tambin proporciona
servicios mejorados que resultan de gran utilidad en ciertas aplicaciones. Una sesin
puede utilizarse para permitir que el usuario inicie sesin en un sistema remoto de
comparticin de tiempo o que transfiera un archivo entre dos mquinas. Uno de los
servicios de la capa de sesin es la administracin del control de dilogo. Las
sesiones permiten que el trfico fluya en ambas direcciones al mismo tiempo o slo
en una cada vez. Si el trfico slo puede ir en una direccin, la capa de sesin ayuda
a saber de quin es el turno. Un servicio relacionado con la sesin es la gestin de
testigos. En algunos protocolos, resulta esencial que los dos extremos no intenten
realizar la misma operacin al mismo tiempo. Para gestionar estas actividades, la
capa de sesin ofrece testigos que pueden intercambiarse. nicamente el extremo
que tenga el testigo podr realizar la operacin crtica. Otro servicio de sesin es la
sincronizacin. Piense en los problemas que pueden surgir al intentar establecer una
transferencia de archivos de dos horas entre dos mquinas de una red con un tiempo
medio de una hora antes de que falle. Tras la cancelacin 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 sesin ofrece un
mtodo de insercin de puntos de comprobacin en el flujo de datos para que, al caer
la red, slo deban repetirse los datos situados despus de este punto de
comprobacin.
Ejemplo: RPC Portmapper
6. Capa de presentacin: la capa de presentacin lleva a cabo funciones que
suelen solicitarse con frecuencia para encontrar una solucin 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 slo muestran inters por mover bits de forma
fiable entre varios puntos, la capa de presentacin se encarga de la sintaxis y de la
semntica de la informacin transmitida. Un ejemplo caracterstico del servicio de
presentacin es la codificacin de datos de forma acordada y normalizada. La
mayora 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, nmeros de coma flotante y estructuras de datos formadas por elementos
ms simples. Los distintos equipos contienen distintos cdigos 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
codificacin estndar que se utilizar en la red. La tarea de gestionar estas
estructuras de datos abstractos y convertirlos en la representacin utilizada por los
equipos en las redes estndar la lleva a cabo la capa de presentacin. Esta capa
tambin se encarga de otros aspectos de la representacin de informacin. Por
ejemplo, la compresin de datos puede utilizarse aqu para reducir el nmero de bits
2-33

MIT 18.996

Clase 2 13 de febrero, 2002

Primavera
de 2002

que se deben transmitir y la criptografa suele requerirse para la privacidad y la

autenticacin.
Ejemplo: HTTP, FTP, Telnet, DNS, SNMP, NFS
7. Capa de aplicacin: la capa de aplicacin 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 complicacin 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 insercin 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 porcin 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 tambin realice dicho movimiento. Todo el software del terminal virtual se
encuentra en la capa de aplicacin. Otra funcin de la capa de aplicacin es la
transferencia de archivos. Los distintos sistemas de archivos tienen diferentes
convenciones de nomenclatura de archivos, formas distintas de representar lneas
de texto, etc. Transferir un archivo entre dos sistemas distintos requiere el
tratamiento de stas y otras incompatibilidades. Esta tarea tambin es
responsabilidad de la capa de aplicacin, al igual que el correo electrnico, las
entradas de tareas remotas, la bsqueda en directorios y otras utilidades generales
y concretas.
Ejemplos: correo electrnico, 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