PROTOCOLOS DE LA CAPA DE ENLACE DE DATOS

1) PROTOCOLOS ELEMENTALES DE ENLACE DE DATOS

 Un protocolo simplex utópico:

Los datos son transmitidos en una sola dirección; las capas de red tanto del emisor como
del receptor siempre están listas. Podemos ignorar el tiempo de procesamiento. Hay un
espacio infinito de búfer disponible. Y lo mejor de todo, el canal de comunicación entre
las capas de enlace de datos nunca daña ni pierde las tramas. Este protocolo
completamente irreal, al que apodaremos “utopía”, es simplemente para mostrar la
estructura básica en la que nos basaremos. El protocolo consiste en dos procedimientos
diferentes, un emisor y un receptor. El emisor se ejecuta en la capa de enlace de datos
de la máquina de origen y el receptor se ejecuta en la capa de enlace de datos de la
máquina de destino. No se usan números de secuencia ni confirmaciones de recepción,
por lo que no se necesita MAX_SEQ. El único tipo de evento posible es frame arrival (es
decir, la llegada de una trama sin daños). El emisor está en un ciclo while infinito que
sólo envía datos a la línea tan rápido como puede. El cuerpo del ciclo consiste en tres
acciones: obtener un paquete de la (siempre dispuesta) capa de red, construir una
trama de salida usando la variable s y enviar la trama a su destino. Este protocolo sólo
utiliza el campo info de la trama, pues los demás campos tienen que ver con el control
de errores y de flujo, y aquí no hay restricciones de este tipo. Por último, la parte de los
datos se pasa a la capa de red y la capa de enlace de datos se retira para esperar la
siguiente trama, para lo cual se suspende efectivamente hasta que ésta llega. El
protocolo utópico es irreal, ya que no maneja el control de flujo ni la corrección de
errores. Su procesamiento se asemeja al de un servicio sin conexión ni confirmación de
recepción que depende de las capas más altas para resolver estos problemas, aun
cuando un servicio sin conexión ni confirmación de recepción realizaría cierta detección
de errores.

CARACTERISTICAS:
Los datos son transmitidos en una sola dirección
Las capas de red tanto del emisor como el receptor siempre están listas
Podemos ignorar el tiempo de procesamiento
Hay un espacio infinito de búfer disponible
El canal nunca daña ni pierde las tramas
No se confirma la recepción
No se usan números de secuencia
Completamente irreal
Similar a un servicio sin conexión ni confirmación de recepción

 Protocolo simplex de parada y espera para un canal libre de errores:

El problema principal de evitar que el emisor sature al receptor enviando tramas a una
mayor velocidad de la que este último puede procesarlas. Esta situación puede ocurrir
con facilidad en la práctica, por lo que es de extrema importancia evitarla. Sin embargo,
aún existe el supuesto de que el canal está libre de errores y el tráfico de datos sigue
siendo simplex. Una solución es construir un receptor lo suficientemente poderoso
como para procesar un flujo continuo de tramas, una tras otra sin interrupción (lo
equivalente sería definir la capa de enlace de modo que fuera lo bastante lenta como
para que el receptor pudiera mantenerse a la par). Debe tener suficiente capacidad en
el búfer y de procesamiento como para operar a la tasa de transmisión de la línea;
asimismo debe ser capaz de pasar las tramas que se reciben en la capa de red con la
rapidez suficiente. Sin embargo, ésta es una solución para el peor de los casos. Requiere
hardware dedicado y se pueden desperdiciar recursos si el enlace se usa poco. Además,
sólo cambia el problema de tratar con un emisor demasiado rápido a otra parte; en este
caso, a la capa de red. Una solución más general para este dilema es hacer que el
receptor proporcione retroalimentación al emisor. Tras haber pasado un paquete a su
capa de red, el receptor regresa al emisor una pequeña trama ficticia que, de hecho,
autoriza al emisor para que transmita la siguiente trama. Después de enviar una trama,
el protocolo exige que el emisor espere hasta que llegue la pequeña trama ficticia (es
decir, la confirmación de recepción). Este retraso es un ejemplo simple de un protocolo
de control de flujo. Los protocolos en los que el emisor envía una trama y luego espera
una confirmación de recepción antes de continuar se denominan de parada y espera. En
la figura 3-13 se da un ejemplo de un protocolo simplex de parada y espera. Aunque el
tráfico de datos en este ejemplo es simplex, y va sólo desde el emisor al receptor, las
tramas viajan en ambas direcciones. En consecuencia, el canal de comunicación entre
las dos capas de enlace de datos necesita tener capacidad de transferencia de
información bidireccional. Sin embargo, este protocolo implica una alternancia estricta
de flujo: primero el emisor envía una trama, después el receptor envía una trama,
después el emisor envía otra trama, luego el receptor envía otra, y así sucesivamente.
Aquí sería suficiente un canal físico semi-dúplex. Al igual que en el protocolo 1, el emisor
comienza obteniendo un paquete de la capa de red, lo usa para construir una trama y
enviarla a su destino. Sólo que ahora, a diferencia del protocolo 1, el emisor debe
esperar hasta que llegue una trama de confirmación de recepción antes de reiniciar el
ciclo y obtener el siguiente paquete de la capa de red. La capa de enlace de datos emisora
ni siquiera necesita inspeccionar la trama entrante, ya que sólo hay una posibilidad. La
trama entrante siempre es de confirmación de recepción.

CARACTERISTICAS:
Los datos son transmitidos en una sola dirección
El canal nunca daña ni pierde las tramas
Se confirma la recepción
No se usan números de secuencia
Existe parada y espera por parte del emisor
Canal físico semi dúplex: emisor y receptor se turnan para enviar(cada uno).
Mantiene aún un canal irreal (perfecto)
 Protocolo simplex de parada y espera para un canal ruidoso: Ahora consideremos
la situación normal de un canal de comunicación que comete errores. Las tramas
pueden llegar dañadas o se pueden perder por completo. Sin embargo, suponemos que
si una trama se daña en tránsito, el hardware del receptor detectará esto cuando calcule
la suma de verificación. Si la trama está dañada de tal manera que pese a ello la suma
de verificación sea correcta (una ocurrencia muy poco probable), este protocolo (y
todos los demás) puede fallar (es decir, tal vez entregue un paquete incorrecto a la capa
de red). A primera vista puede parecer que funcionaría una variación del protocolo 2:
agregar un temporizador. El emisor podría enviar una trama, pero el receptor sólo
enviaría una trama de confirmación de recepción si los datos llegaran correctamente. Si
llegara una trama dañada al receptor, se desecharía. Después de un tiempo el
temporizador del emisor expiraría y éste enviaría la trama otra vez. Este proceso se
repetiría hasta que la trama por fin llegara intacta. Pero el esquema anterior tiene un
defecto fatal. Piense en el problema y trate de descubrir lo que podría salir mal antes de
continuar leyendo. Para ver lo que puede resultar mal, recuerde que el objetivo de la
capa de enlace de datos es proporcionar una comunicación transparente y libre de
errores entre los procesos de las capas de red. La capa de red de la máquina A pasa una
serie de paquetes a su capa de enlace de datos, la cual debe asegurar que se entregue
una serie de paquetes idénticos a la capa de red de la máquina B a través de su capa de
enlace de datos. En particular, la capa de red en B no tiene manera de saber si el paquete
se perdió o duplicó, por lo que la capa de enlace de datos debe garantizar que ninguna
combinación de errores de transmisión, por improbables que sean, pudiera causar la
entrega de un paquete duplicado a la capa de red. Considere el siguiente escenario: 1.
La capa de red de A entrega el paquete 1 a su capa de enlace de datos. La máquina B
recibe correctamente el paquete y lo pasa a su capa de red. B regresa a A una trama de
confirmación de recepción. 2. La trama de confirmación de recepción se pierde por
completo. Nunca llega. La vida sería mucho más sencilla si el canal sólo alterara o
perdiera tramas de datos y no tramas de control, pero desgraciadamente el canal no
hace distinciones. 3. El temporizador de la capa de enlace de datos de A expira en algún
momento. Al no haber recibido una confirmación de recepción, supone
(incorrectamente) que su trama de datos se ha perdido o dañado, y envía otra vez la
trama que contiene el paquete 1. 4. La trama duplicada también llega bien a la capa de
enlace de datos de B y de ahí se pasa de manera inadvertida a la capa de red. Si A está
enviando un archivo a B, parte del archivo se duplicará (es decir, la copia del archivo
reconstruida por B será incorrecta y el error no se habrá detectado). En otras palabras,
el protocolo fallará. Sin duda, lo que se necesita es alguna manera de que el receptor sea
capaz de distinguir entre una trama que está viendo por primera vez y una
retransmisión. La forma evidente de lograr esto es hacer que el emisor ponga un
número de secuencia en el encabezado de cada trama que envía. A continuación, el
receptor puede verificar el número de secuencia de cada trama que llega para ver si es
una trama nueva o un duplicado que debe descartarse. Como el protocolo debe ser
correcto y es probable que el campo de número de secuencia en el encabezado sea
 pequeño como para poder usar el enlace en forma eficiente, surge la pregunta: ¿cuál es
la cantidad mínima de bits necesarios para el número de secuencia? El encabezado
podría proveer 1 bit, unos cuantos bits, 1 byte o varios bytes para un número de
secuencia, dependiendo del protocolo. El punto importante es que debe transportar
números de secuencia que sean lo bastante grandes como para que el protocolo
funcione de manera correcta, o de lo contrario no se podrá considerar un verdadero
protocolo.
CARACTERISTICAS:
Los datos son transmitidos en una sola dirección
Las tramas pueden llegar dañadas o perderse por completo
El receptor realiza una verificación de la trama recibida
Se confirma la recepción
Se agrega un temporizador al emisor
Se usan números de secuencia de bit.

2) PROTOCOLOS DE VENTANA DESLIZANTE:

En los protocolos anteriores, las tramas de datos se transmitían en una sola dirección.
En la mayoría de las situaciones prácticas existe la necesidad de transmitir datos en
ambas direcciones. Una manera de lograr una transmisión de datos full-dúplex es tener
dos instancias de uno de los protocolos anteriores, cada uno de los cuales debe usar un
enlace separado para el tráfico de datos simplex (en distintas direcciones). A su vez,
cada enlace se compone de un canal de “ida” (para los datos) y de un canal de “retorno”
(para las confirmaciones de recepción). En ambos casos se desperdicia la capacidad del
canal de retorno casi por completo.

 Un protocolo de ventana deslizante de un bit:

Antes de tratar el caso general, examinemos un protocolo de ventana deslizante con un
tamaño máximo de ventana de 1. Tal protocolo utiliza parada y espera, ya que el emisor
envía una trama y espera su confirmación de recepción antes de transmitir la siguiente.
En la figura 3-16 se describe dicho protocolo. Como los demás, comienza por definir
algunas variables. Next_frame_to_send indica qué trama está tratando de enviar el
emisor. Asimismo, frame_expected indica qué trama espera el receptor. En ambos casos,
0 y 1 son las únicas posibilidades. En circunstancias normales, una de las dos capas de
enlace de datos es la que comienza a transmitir la primera trama. En otras palabras, sólo
uno de los programas de capa de enlace de datos debe contener las llamadas de
procedimiento to_physical_layer y start_timer fuera del ciclo principal. La máquina que
inicia obtiene el primer paquete de su capa de red, construye una trama a partir de él y
la envía. Al llegar esta (o cualquier) trama, la capa de enlace de datos del receptor la
verifica para saber si es un duplicado, igual que en el protocolo 3. Si la trama es la
esperada, se pasa a la capa de red y la ventana del receptor se recorre hacia arriba. El
campo de confirmación de recepción contiene el número de la última trama recibida sin
error. Si este número concuerda con el de secuencia de la trama que está tratando de
enviar el emisor, éste sabe que ha terminado con la trama almacenada en el búfer
(buffer) y que puede obtener el siguiente paquete de su capa de red. Si el número de
secuencia no concuerda, debe seguir tratando de enviar la misma trama. Cada vez que
se recibe una trama, también se regresa una.
 Un protocolo que utiliza retroceso N:

Hasta ahora hemos supuesto que el tiempo de transmisión requerido para que una
trama llegue al receptor más el necesario para que la confirmación de recepción regrese
es insignificante. A veces esta suposición es totalmente falsa. En estas situaciones el
tiempo de viaje de ida y vuelta prolongado puede tener implicaciones importantes para
la eficiencia de la utilización del ancho de banda.

 Un protocolo que usa repetición selectiva: El protocolo de retroceso n funciona

bien si los errores son poco frecuentes, pero si la línea es mala se desperdicia mucho
ancho de banda en las tramas que se retransmiten. El protocolo de repetición selectiva
es una estrategia alterna para que el receptor acepte y coloque en búferes las tramas
que llegan después de una trama dañada o perdida. En este protocolo, tanto el emisor
como el receptor mantienen una ventana de números de secuencia pendiente y
aceptable, respectivamente. El tamaño de la ventana del emisor comienza en 0 y crece
hasta un máximo predefinido. Por el contrario, la ventana del receptor siempre es de
tamaño fijo e igual al máximo predeterminado. El receptor tiene un búfer reservado
para cada número de secuencia dentro de su ventana fija. Cada búfer tiene un bit
asociado (arrived), el cual indica si el búfer está lleno o vacío. Cada vez que llega una
trama, la función between verifica su número de secuencia para ver si cae dentro de la
ventana. De ser así, y si todavía no se recibe, se acepta y almacena. Esta acción se lleva
a cabo sin importar si la trama contiene o no el siguiente paquete que espera la capa de
red. Claro que se debe mantener dentro de la capa de enlace de datos sin pasarla a la
capa de red hasta que se hayan entregado todas las tramas de menor número a la capa
de red en el orden correcto. En la figura 3-21 se presenta un protocolo que usa este
algoritmo. La recepción no secuencial introduce limitaciones adicionales en los
números de secuencia de tramas, que no se presentan en los protocolos en los que las
tramas sólo se aceptan en orden. Podemos ilustrar el problema fácilmente con un
ejemplo. Suponga que tenemos un número de secuencia de 3 bits, de modo que se
permita al emisor transmitir hasta siete tramas antes de tener que esperar una
confirmación de recepción.

LA CAPA DE RED DE INTERNET

El RFC utiliza mucho las ideas establecidas por Clark (1988) y por Saltzer y colaboradores
(1984). Ahora sintetizaremos los que consideramos como los 10 mejores principios (del
más al menos importante).
1. Asegurarse de que funciona: No termine el diseño o estándar hasta que múltiples
prototipos se hayan comunicado entre sí de manera exitosa. Con mucha frecuencia, los
diseñadores primero escriben un estándar de 1000 páginas, logran que se apruebe y
después descubren que tiene demasiadas fallas y no funciona. Entonces escriben una
versión. Ésta no es la manera correcta de proceder.
2. Mantener la simplicidad. Cuando tenga duda, utilice la solución más simple. William de
Occam formuló este principio (la navaja de Occam) en el siglo xiv. Dicho en términos
modernos: combata las características. Si una característica no es absolutamente esencial,
 descártela, especialmente si el mismo efecto se puede alcanzar mediante la combinación de
otras características.
3. Elegir opciones claras. Si hay varias maneras para realizar la misma tarea, elija sólo una.
Tener dos o más formas de hacer lo mismo es buscarse problemas. Con frecuencia, los
estándares tienen múltiples opciones, modos o parámetros debido a que personas
poderosas insisten en que su método es el mejor. Los diseñadores deben resistir con fuerza
esta tendencia. Simplemente diga no.
4. Explotar la modularidad. Este principio lleva directamente a la idea de tener pilas de
protocolos, cuyas capas sean independientes entre sí. De esta forma, si las circunstancias
requieren que un módulo o capa cambie, los otros no se verán afectados.
5. Prevenir la heterogeneidad. En cualquier red grande habrá diferentes tipos de hardware,
facilidades de transmisión y aplicaciones. Para manejarlos, el diseño de la red debe ser
simple, general y flexible.
6. Evitar las opciones y parámetros estáticos. Si los parámetros son inevitables (por
ejemplo, el tamaño máximo del paquete), es mejor hacer que el emisor y el receptor
negocien un valor que definir opciones fijas.
7. Buscar un buen diseño no es necesario que sea perfecto. Con frecuencia, los diseñadores
tienen un buen diseño pero éste no puede manejar algún caso especial. En lugar de
desbaratar el diseño, los diseñadores deberían optar por el buen diseño y dejar que esa
parte la resuelvan las personas con requisitos extraños.
8. Ser estricto cuando envíe y tolerante cuando reciba. En otras palabras, sólo envíe
paquetes que cumplan rigurosamente con los estándares, pero espere paquetes que tal vez
no cumplan del todo y trate de lidiar con ellos.
9. Pensar en la escalabilidad. Si el sistema debe manejar de manera efectiva millones de
hosts y miles de millones de usuarios, no se toleran bases de datos centralizadas de ningún
tipo y la carga se debe dispersar de la manera más equitativa posible entre los recursos
disponibles.
10. Considerar el desempeño y el costo. Si una red tiene un desempeño pobre o un costo
exagerado, nadie la utilizará.
En la capa de red, la Internet puede verse como un conjunto de redes, o Sistemas Autónomos
(AS) interconectados. No hay una estructura real, pero existen varias redes troncales
(backbones) principales. Éstas se construyen a partir de líneas de alto ancho de banda y
enrutadores rápidos. Las más grandes de estas redes troncales, a la que se conectan todos los
demás para llegar al resto de Internet, se llaman redes de Nivel 1. Conectadas a las redes
troncales hay ISP (Proveedores de Servicio de Internet) que proporcionan acceso a Internet
para los hogares y negocios, centros de datos e instalaciones de colocación llenas de máquinas
servidores y redes regionales (de nivel medio). Los centros de datos sirven gran parte del
contenido que se envía a través de Internet. A las redes regionales están conectados más ISP,
LAN de muchas universidades y empresas, y otras redes de punta.
El pegamento que mantiene unida a Internet es el protocolo de capa de red, IP (Protocolo de
Internet, del inglés Internet Protocol). A diferencia de la mayoría de los protocolos de capa de
red anteriores, IP se diseñó desde el principio con la interconexión de redes en mente. Una
buena manera de visualizar la capa de red es la siguiente: su trabajo es proporcionar un medio
de mejor esfuerzo (es decir, sin garantía) para transportar paquetes de la fuente al destino, sin
importar si estas máquinas están en la misma red o si hay otras redes entre ellas.
Funciones básicas de la capa de red U Retransmisión (forwarding):
 mover paquetes desde la entrada del en caminador a una salida apropiada del mismo.
U Encaminamiento (routing): determina la ruta tomada por los paquetes desde el
origen al destino P Algoritmos de encaminamiento Analogía: pedir direcciones en una
esquina de una ciudad (forwarding) tener un mapa de todo el trayecto (routing)

PROTOCOLO IPV4
IPv4 es la versión 4 del Protocolo de Internet (IP o Inernet Protocol) y constituye la primera
versión de IP que es implementada de forma extensiva. IPv4 es el principal protocolo utilizado
en el Nivel de Red del Modelo TCP/IP para Internet. Fue descrito inicial mente en el RFC
791 elaborado por la Fuerza de Trabajo en Ingeniería de Internet
(IETFo Internet Engineering Task Force) en septiembre de 1981, documento que dejó obsoleto
al RFC 760 de Enero de 1980.

IPv4 es un protocolo orientado hacia datos que se utiliza para comunicación entre redes a
través de interrupciones (switches) de paquetes (por ejemplo a través de Ethernet). Tiene las
siguientes características:

 Es un protocolo de un servicio de datagramas no fiable (también referido como

de mejor esfuerzo).
 No proporciona garantía en la entrega de datos.
 No proporciona ni garantías sobre la corrección de los datos.
 Puede resultar en paquetes duplicados o en desorden.

Todos los problemas mencionados se resuelven en el nivel superior en el modelo TCP/IP, por
ejemplo, a través de TCP o UDP.
El propósito principal de IP es proveer una dirección única a cada sistema para asegurar que
una computadora en Internet pueda identificar a otra.

Direcciones.

IPv4 utiliza direcciones de 32 bits (4 bytes) que limita el número de direcciones posibles a
utilizar a 4, 294, 967,295 direcciones únicas. Sin embargo, muchas de estas están reservadas
para propósitos especiales como redes privadas, Multidifusión (Multicast), etc. Debido a esto se
reduce el número de direcciones IP que realmente se pueden utilizar, es esto mismo lo que ha
impulsado la creación de IPv6 (actualmente en desarrollo) como reemplazo eventual dentro de
algunos años para IPv4.

Representación de las direcciones.

Cuando se escribe una dirección IPv4 en cadenas, la notación más común es la decimal con
puntos. Hay otras notaciones basadas sobre los valores de los octetos de la dirección IP.
  Direcciones IP:
Una característica que define a IPv4 consiste en sus direcciones de 32 bits. Cada host
y enrutador de Internet tiene una dirección IP que se puede usar en los campos
Dirección de origen y Dirección de destino de los paquetes IP. Es importante tener
en cuenta que una dirección IP en realidad no se refiere a un host, sino a una interfaz
de red, por lo que si un host está en dos redes, debe tener dos direcciones IP. Sin
embargo, en la práctica la mayoría de los hosts están en una red y, por ende, tienen
una dirección IP. En contraste, los enrutadores tienen varias interfaces y, por lo
tanto, múltiples direcciones IP.

Protocolos de control en Internet

El IP que se utiliza para la transferencia de datos, Internet tiene varios protocolos

de control complementarios que se utilizan en la capa de red, como ICMP, ARP y
DHCP. En esta sección los analizaremos por separado y describiremos las versiones
que corresponden a IPv4, ya que son los protocolos de uso común. ICMP y DHCP
tienen versiones similares para IPv6; el equivalente de ARP se llama NDP (Protocolo
de Descubrimiento de Vecino, del inglés Neighbor Discovery Protocol ) para IPv6.
ICMP: Protocolo de Mensajes de Control en Internet Los enrutadores supervisan
muy de cerca el funcionamiento de Internet. Cuando ocurre algo inesperado
durante el procesamiento de un paquete en un enrutador, ICMP (Protocolo de
Mensajes de Control en Internet, del inglés Internet Control Message Protocol )
informa sobre el evento al emisor. ICMP también se utiliza para probar Internet.
Hay definidos alrededor de una docena de tipos de mensajes ICMP, cada uno de los
cuales se transporta encapsulado en un paquete IP. El mensaje DESTINATION
UNREACHABLE (DESTINO INACCESIBLE) se usa cuando el enrutador no puede
localizar el destino o cuando un paquete con el bit DF no puede entregarse porque
hay una red de “paquetes pequeños” que se interpone en el camino.
 Protocolo de Resolución de Direcciones: Aunque en Internet cada
máquina tiene una o más direcciones IP, en realidad éstas no son suficientes
para enviar paquetes. Las NIC (Tarjetas de Interfaz de Red) de la capa de
enlace de datos no entienden las direcciones de Internet. En el caso de
Ethernet, cada NIC de las que se hayan fabricado viene equipada con una
dirección Ethernet única de 48 bits. Los fabricantes de NIC Ethernet
solicitan un bloque de direcciones Ethernet al IEEE para asegurar que no
haya dos NIC con la misma dirección (y evitar conflictos en caso de que las
dos NIC aparezcan alguna vez en la misma LAN). Las NIC envían y reciben
tramas basadas en direcciones Ethernet de 48 bits. No saben nada sobre
direcciones IP de 32 bits. La pregunta ahora es: ¿cómo se convierten las
direcciones IP en direcciones de la capa de enlace de datos, como Ethernet?
Para explicar cómo funciona esto, veamos el ejemplo de la figura 5-61 en
donde se muestra una universidad pequeña con dos redes /24. Una red (CC)
es una Ethernet conmutada y está en el Departamento de Ciencias
Computacionales. Tiene el prefijo 192.32.65.0/24. La otra LAN (IE), que
también es Ethernet conmutada, está en el Departamento de Ingeniería
Eléctrica y tiene el prefijo 192.32.63.0/24. Las dos LAN están conectadas
por un enrutador IP. Cada máquina en una Ethernet y cada interfaz en el
 enrutador tienen una dirección única de Ethernet, etiquetadas de E1 a E6,
además de una dirección IP única en la red CC o IE.
 OSPF: un protocolo de enrutamiento de puerta de enlace interior
Hemos terminado nuestro estudio acerca de cómo se reenvían los paquetes
en Internet. Ya es tiempo para pasar al tema siguiente: el enrutamiento en
Internet. Como lo mencionamos antes, Internet se compone
www.FreeLibros.me 406 LA CAPA DE RED CAP. 5 de una gran cantidad de
redes independientes o Sistemas Autónomos (AS), los cuales son operados
por distintas organizaciones, por lo general una empresa, universidad o ISP.
Dentro de su propia red, una organización puede usar su propio algoritmo
de enrutamiento interno, o enrutamiento intradominio, como se le conoce
con más frecuencia. Sin embargo, hay sólo unos cuantos protocolos estándar
que son populares. En esta sección estudiaremos el problema del
enrutamiento intradominio y analizaremos el protocolo OSPF, que se utiliza
mucho en la práctica. Un protocolo de enrutamiento intradominio también
se conoce como protocolo de puerta de enlace interior. En la siguiente
sección, estudiaremos el problema de enrutamiento entre redes operadas
de manera independiente, o enrutamiento interdominio. Para ese caso,
todas las redes deben usar el mismo protocolo de enrutamiento
interdominio, o protocolo de puerta de enlace exterior. El protocolo que se
utiliza en internet es BGP (Protocolo de Puerta de Enlace de Frontera, del
inglés Border Gateway Protocol ). Los primeros protocolos de enrutamiento
intradominio usaban un diseño de vector de distancia basado en el
algoritmo Bellman-Ford distribuido, que se heredó de ARPANET. RIP
(Protocolo de Información de Enrutamiento, del inglés Routing Information
Protocol ) es el principal ejemplo que se usa en la actualidad. Funciona bien
en sistemas pequeños, pero su desempeño disminuye a medida que las
redes aumentan su tamaño. También sufre del problema del conteo al
infinito y por lo general de una convergencia lenta. ARPANET cambió a un
protocolo de estado del enlace en mayo de 1979 debido a estos problemas;
en 1988, la IETF empezó a trabajar en un protocolo de estado del enlace
para el enrutamiento intradominio. Ese protocolo, conocido como OSPF
(Abrir primero la ruta más corta, del inglés Open Shortest Path First), se
convirtió en un estándar en 1990. Se valió de un protocolo llamado IS-IS
(Sistema Intermedio a Sistema Intermedio, del inglés Intermediate-System
to Intermediate-System), el cual se convirtió en un estándar de ISO. Debido
a su herencia compartida, los dos protocolos son mucho más parecidos que
diferentes. Si desea conocer la historia completa, consulte el RFC 2328. Son
los protocolos de enrutamiento intradominio dominantes; la mayoría de los
distribuidores ofrecen ahora soporte para ambos. OSPF se utiliza más en las
redes de compañías; IS-IS se utiliza más en las redes de ISP. De los dos,
veremos un bosquejo sobre la forma en que funciona OSPF.
 BGP: el protocolo de enrutamiento de Puerta de Enlace Exterior
Dentro de un solo sistema autónomo, OSPF e IS-IS son los protocolos
de uso común. Entre los sistemas autónomos se utiliza un protocolo
diferente, conocido como BGP (Protocolo de Puerta de Enlace de
Frontera, del inglés Border Gateway Protocol ). Se necesita un
protocolo diferente debido a que los objetivos de un protocolo
intradominio y de un protocolo interdominio no son los mismos.
Todo lo que tiene que hacer un protocolo intradominio es mover
paquetes de la manera más eficiente posible desde el origen
hasta el destino. No tiene que preocuparse por las políticas. En
contraste, los protocolos de enrutamiento interdominio tienen que
preocuparse en gran manera por la política (Metz, 2001). Por
ejemplo, tal vez un sistema autónomo corporativo desee la
habilidad de enviar paquetes a cualquier sitio de Internet y recibir
paquetes de cualquier sitio de Internet. Sin embargo, quizás no
esté dispuesto a llevar paquetes de tránsito que se originen en un
AS foráneo y estén destinados a un AS foráneo diferente, aun
cuando su propio AS se encuentre en la ruta más corta entre los
dos sistemas autónomos foráneos (“Ése es su problema, no el
nuestro”). Por otro lado, podría estar dispuesto a llevar el tráfico
del tránsito para sus vecinos o incluso para otros sistemas
autónomos específicos que hayan pagado por este servicio. Por
ejemplo, las compañías telefónicas podrían estar contentas de
actuar como empresas portadoras para sus clientes, pero no para
otros. En general, los protocolos de puerta de enlace exterior (y
BGP en particular) se han diseñado para permitir que se
implementen muchos tipos de políticas de enrutamiento en el
tráfico entre sistemas autónomos. Las políticas típicas implican
consideraciones políticas, de seguridad, o económicas. Algunos
ejemplos de posibles restricciones de enrutamiento son:
1. No transportar tráfico comercial en la red educativa.
2. Nunca enviar tráfico del Pentágono por una ruta a través de
Irak.
3. Usar TeliaSonera en vez de Verizon porque es más económico.
4. No usar AT&T en Australia porque el desempeño es pobre.
5. El tráfico que empieza o termina en Apple no debe transitar por
Google.
Como puede imaginar de esta lista, las políticas de enrutamiento
pueden ser muy individuales. A menudo son propietarias pues
contienen información comercial delicada. Sin embargo,
podemos describir algunos patrones que capturan el
razonamiento anterior de la compañía y que se utilizan con
frecuencia como un punto de partida. Para implementar una
política de enrutamiento hay que decidir qué tráfico puede fluir a
través de cuáles enlaces entre los sistemas autónomos. Una
política común es que un ISP cliente pague a otro ISP proveedor
por entregar paquetes a cualquier otro destino en Internet y recibir
los paquetes enviados desde cualquier otro destino. Se dice que
el ISP cliente compra servicio de tránsito al ISP proveedor. Es justo
igual que cuando un cliente doméstico compra servicio de
acceso a Internet con un ISP. Para que funcione, el proveedor
debe anunciar las rutas a todos los destinos en Internet al cliente
a través del enlace que los conecta. De esta forma, el cliente
tendrá una ruta para enviar paquetes a cualquier parte. Por el
contrario, el cliente sólo debe anunciar al proveedor las rutas a los
destinos en su red. Esto permitirá al proveedor enviar tráfico al
cliente sólo para esas direcciones; al cliente no le conviene
manejar el tráfico destinado a otras partes.

PROTOCOLOS DE TRANSPORTE

ELEMENTOS DE LOS PROTOCOLOS DE TRANSPORTE:

El servicio de transporte se implementa mediante un protocolo de
transporte entre las dos entidades de transporte. En ciertos
aspectos, los protocolos de transporte se parecen a los protocolos
de enlace de datos que estudiamos con detalle en el capítulo 3.
Ambos se encargan del control de errores, la secuenciación y el
control de flujo, entre otros aspectos. Sin embargo, existen
diferencias considerables entre los dos, las cuales se deben a
disimilitudes importantes entre los entornos en que operan ambos
protocolos, como se muestra en la figura 6-7. En la capa de enlace
de datos, dos enrutadores se comunican de forma directa
mediante un canal físico, ya sea cableado o inalámbrico,
mientras que, en la capa de transporte, ese canal físico se
sustituye por la red completa. Esta diferencia tiene muchas
implicaciones importantes para los protocolos.
Direccionamiento:
Cuando un proceso de aplicación (por ejemplo, un usuario)
desea establecer una conexión con un proceso de aplicación
remoto, debe especificar a cuál se conectará (el transporte sin
conexión tiene el mismo problema: ¿a quién debe enviarse cada
mensaje?). El método que se emplea por lo general es definir
direcciones de transporte en las que los procesos puedan
escuchar las solicitudes de conexión. En Internet, estos puntos
terminales se denominan puertos. Usaremos el término genérico
TSAP (Punto de Acceso al Servicio de Transporte, del inglés
Transport Service Access Point) para indicar un punto terminal
específico en la capa de transporte. Así, no es sorpresa que los
puntos terminales análogos en la capa de red (es decir,
direcciones de capa de red) se llamen NSAP (Punto de Acceso al
Servicio de Red, del inglés Network Service Access Points). Las
direcciones IP son ejemplos de NSAP. Los procesos de aplicación,
tanto clientes como servidores, se pueden enlazar por sí mismos a
un TSAP para establecer una conexión a un TSAP remoto. Estas
conexiones se realizan a través de puntos NSAP en cada host,
como se muestra. El propósito de tener puntos TSAP es que, en
algunas redes, cada computadora tiene un solo NSAP, por lo que
se necesita alguna forma de diferenciar los múltiples puntos
terminales de transporte que comparten ese punto NSAP.

Establecimiento de una conexión: El proceso de establecer una

conexión suena fácil, pero en realidad es sorprendentemente
complicado. A primera vista parecería suficiente con que una
entidad de transporte enviara tan sólo un segmento CONNECTION
REQUEST al destino y esperara una respuesta CONNECTION
ACCEPTED. El problema ocurre cuando la red puede perder,
retrasar, corromper y duplicar paquetes. Este comportamiento
causa complicaciones serias. Imagine una red que está tan
congestionada que las confirmaciones de recepción casi nunca
regresan a tiempo, y cada paquete expira y se retransmite dos o
tres veces. Suponga que la red usa datagramas en su interior y que
cada paquete sigue una ruta diferente. Algunos de los paquetes
podrían atorarse en un congestionamiento de tráfico dentro de la
red y tardar mucho tiempo en llegar. Es decir, se pueden retardar
en la red y reaparecer mucho después, cuando el emisor piense
que se han perdido. La peor pesadilla posible es la siguiente. Un
usuario establece una conexión con un banco y envía mensajes
para indicar al banco que transfiera una gran cantidad de dinero
a la cuenta de una persona no del todo confiable. Por desgracia,
los paquetes toman la ruta escénica hacia el destino y parten
para explorar un rincón lejano de la red. Entonces el temporizador
del emisor expira y envía todos los paquetes de nuevo. Esta vez los
paquetes toman la ruta más corta y se entregan con rapidez, por
lo que el emisor libera la conexión. Por desgracia, en un momento
dado el lote inicial de paquetes sale finalmente de su escondite y
llega al destino en orden; le pide al banco que establezca una
nueva conexión y que transfiera dinero (otra vez).