INTERCONEXIÓN TCP/IP

Índice:
v 0. Introducción ................................................................................................. 3
1. Tema 1 - Sección 1 – Introducción y Visión General de Interconexión........ 4
2. Tema 1 - Sección 2 – Tecnologías de Red.................................................. 15
3. Tema 1 - Sección 3 – Interconexión y Modelo Arquitectónico ..................... 25
4. Tema 1 - Sección 4 – Interconexión TCP/IP................................................ 34
5. Sección 5 – Bibliografía .............................................................................. 56

0. INTRODUCCIÓN Este TEMA LLAMADO INTERCONEXIÓN CON TCP/IP, está dividido en las siguientes SEC-
CIONES TEMÁTICAS:
- SECCION 1: Introducción y Visión General de Interconexión,
- SECCION 2: Tecnologías de Red,
- SECCION 3: Interconexión y Modelo Arquitectónico, y
- SECCIÓN 4: Interconexión TCP/IP.

TEMA 1
Sección 1
INTRODUCCIÓN Y VISIÓN GENERAL DE INTERCONEXIÓN

1.1 Interconexión TCP/IP

Las comunicaciones por Internet se han vuelto muy importantes en la vida cotidiana de las personas y las
empresas. Aunque Internet parece que opera como una red unificada, no fue pensada así, dado que ninguna
tecnología de red puede satisfacer todas las demandas de hoy en día. Algunas organizaciones usan tecnolo-
gías cableadas y otras inalámbricas, y en otros casos tecnologías internas, dentro de los edificios, y es posible
que demanden enlaces de comunicaciones especiales para vincular las sucursales de toda la empresa, distri-
buidas en una provincia o país.
En los 1970, la tecnología de interconexión se creó para interconectar diversas redes independientes, que
usen distintas tecnologías, y que operen como una unidad coordinada. La interconexión (internetworking) se
basa en un conjunto de convenciones de comunicaciones que las redes (individuales) usan para operar entre
ellas. Esta tecnología oculta los detalles del hardware de la red y permite que las computadoras se comuni-
quen independientemente de sus conexiones físicas.
La tecnología de interconexión (internet) es abierta, y cualquier empresa puede proponer el hardware y soft-
ware necesarios para comunicarse a través de Internet dado que las especificaciones son públicas. Además,
dado que esta tecnología así fue diseñada, cualquier arquitectura hardware que soporte redes de conmuta-
ción de paquetes podrá hacer funcionar una amplia variedad de aplicaciones y utilizar sistemas operativos
arbitrarios.
Entre los 1970s y 1980s, agencias del gobierno de EUUU establecieron la importancia y potencial de la tecno-
logía de interconexión, y las bases de líneas de investigación dirigidas a hacer posible una Internet global.
Específicamente, la Agencia de Proyectos de Investigación Avanzada de Defensa de EUUU (DARPA) precisó un
conjunto de estándares de red y convenciones para interconectar redes, retransmitir tráfico, y además, deta-
lles para comunicar computadoras. Oficialmente se la conoció como la suite de Protocolos de Internet TCP/IP
o sólo TCP/IP (basado en los nombres de dos de sus principales protocolos de red). Este conjunto de proto-
colos puede usarse para comunicar cualquier conjunto de redes (por ejemplo, Internet).
Desde el punto de vista de los usuarios, Internet parece consistir de un conjunto de aplicaciones que usan la
red subyacente para desarrollar tareas útiles, que trabajan interoperativamente cooperando en la resolución
de problemas computacionales. La mayoría de los usuarios acceden a las aplicaciones desconociendo los ti-
pos de computadoras o redes que se utilizan, los protocolos de comunicaciones, o los caminos que recorren
los datos entre el origen y el destino. Entre los servicios de aplicación más populares:

• World Wide Web: La Web es la mayor fuente de tráfico en el Internet global; por ejemplo, Google
y Facebook usan tecnología Web,

• Acceso en la nube: Esta tecnología coloca facilidades de computación y almacenamiento en centros

de datos de Internet,

• Escritorio Remoto: El servicio de escritorio remoto permite al usuario acceder a una computadora
en un centro de datos remoto como si la computadora fuera local,

• Transferencia de Archivos: El protocolo de transferencia de archivo permite a los usuarios enviar o

recibir una copia de un archivo de datos,

• Correo Electrónico (email): Le permite a los usuarios leer un mensaje, seleccionar un mensaje para
procesamiento, y retransmitir el mensaje o enviar una respuesta, y los

• Servicios de Voz y Video: Los flujos de video y audio transportan una fracción creciente de bits en
Internet.

Mientras, un programador tiene un punto de vista enteramente distinto de Internet que un usuario. Los pro-
veedores de Internet suministran dos servicios que todos los programas de aplicación utilizan:

• Servicio de Transmisión de Paquetes sin Conexión: El servicio sin conexión de una red de conmuta-
ción de paquetes es simplemente aquella internet TCP/IP que retransmite mensajes desde una
computadora a otra en base a la información de dirección que lleve el mensaje. Debido a que cada
paquete se retransmite independientemente, una interconexión de este tipo no garantiza confiabili-
dad y entrega ordenada. Sin embargo, es altamente eficiente.
• Servicio de Transporte de Stream Confiable: Cuando las aplicaciones requieren recuperación auto-
mática de errores de transmisión, pérdida de paquetes o fallas en los conmutadores intermedios a lo
largo del camino de tránsito entre el transmisor y el receptor, se necesita una red confiable. Un ser-
vicio confiable de Internet permite establecer una conexión que se comporta como un enlace de
hardware directo y permanente entre el origen y el destino.

TCP/IP se distingue de algunas tecnologías que soportan ciertos servicios como los mencionados preceden-
temente, al menos por las siguientes características:

• Independencia de la tecnología de red: TCP/IP es independiente de cualquier tipo de hardware o

variedad de tecnologías de red.

• Interconexión universal: Internet permite a cualquier par de computadoras comunicarse a través de

una dirección que se reconoce universalmente.

• Reconocimiento extremo a extremo: Los protocolos de TCP/IP proveen el reconocimiento entre la

fuente original y el último destino, aun cuando no estén conectadas a una red física común.

• Protocolos Estándar de Aplicación: Los protocolos TCP/IP existentes le ofrecen a los programadores
todas las facilidades para el diseño de sus aplicaciones.
1.2 Historia de Internet DARPA comenzó a trabajar con una tecnología de interconexión a mediados de los
1970s, y fue conocida como fundadora de líneas de investigación en redes de conmutación de paquetes y
pionera en varias ideas con su bien conocida ARPANET. ARPANET usó enlaces punto a punto alquilados, pero
también realizó estudios sobre redes de radio y canales de comunicación satelital. DARPA planificó reuniones
informales de investigadores para compartir ideas y discutir sus resultados experimentales sobre las tecnolo-
gías de interconexión. Informalmente, al grupo se lo conoció como el Grupo de Investigación de Internet
(Internet Research Group). En 1979, varios investigadores estaban involucrados en el diseño de los protocolos
y arquitectura del Internet emergente.
El Internet global comenzó alrededor de 1980 cuando DARPA comenzó a convertir las computadoras de sus
redes de investigación a los nuevos protocolos TCP/IP. La ARPANET rápidamente se convirtió en el backbone
del nuevo Internet y fue utilizada por los primeros experimentos de TCP/IP. La transición se completó en el
año 1983.
Para estimular el uso en ambientes universitarios, ARPA hizo una implementación disponible a bajo costo. En
esos momentos, la mayoría de los departamentos de ciencias de la computación universitarios ejecutaban
una versión del sistema operativo UNIX, conocida como la Distribución de Software Berkeley (BSD) de la Uni-
versidad de California. De esta forma, rápidamente se integraron los protocolos TCP/IP y UNIX. Además, UNIX
Berkeley creó una nueva abstracción de sistema operativo conocida como un socket que permitió que las
aplicaciones accedieran a los protocolos de Internet. Esto permitió que los programadores usaran TCP/IP con
poco esfuerzo.
Luego, la National Science Foundation (NSF) jugó un rol activo para expandir la interconexión TCP/IP a tantos
científicos como posible. En 1985, NSF comenzó un programa para establecer redes de acceso centradas al-
rededor de 6 centros con supercomputadoras. En paralelo, varias corporaciones de computadoras, de petró-
leo, automotriz, firmas electrónicas, compañías farmacéuticas se conectaron a Internet. Las compañías me-
dias y pequeñas comenzaron a conectarse en los 1990s.
En 1984, Internet alcanzó más de 1000 computadoras, y para 1993 excedía el 1.000.000. En 2001, el tamaño
excedía 100.000.000, y en 2011, el Internet alcanzó más de 800.000.000 de computadoras unidas permanen-
temente.

1.3 Administración de Internet

La dirección técnica de Internet fue ejercida desde 1983 por el IAB (Internet Architecture Board) cuando
DARPA reorganizó los primeros grupos de investigadores que trabajaban en el desarrollo de TCP/IP. El IAB
decidió que protocolos serían parte de TCP/IP y estableció la política oficial. Pero en 1989, la tecnología TCP/IP
e Internet habían crecido considerablemente respecto a los desarrollos iniciales. Y ya no era tan fácil introdu-
cir cambios en los protocolos debido a la gran cantidad de usuarios y compañías comerciales que eran parte
de la red. Los protocolos TCP/IP e Internet se volvieron una tecnología de producción exitosa y el mercado
comenzó a dominar su evolución.
Para reflejar las realidades políticas y comerciales de TCP/IP e Internet, el IAB fue reorganizado en el verano
de 1989. Los investigadores integraron un grupo subsidiario conocido como Internet Research Task Force
(IRTF) y se creó un nuevo consejo IAB para incluir representantes de aspectos más técnicos sobre los están-
dares de los protocolos y otros detalles con el nombre de Internet Engineering Task Force (IETF). Luego, la
IETF se dividió en más de 20 grupos de trabajo, cada uno de los cuales se focalizaba sobre un problema espe-
cífico, y dividido en una docena de áreas, cada una con su propio gerente. El gerente general y los gerentes
de área constituyen el Internet Engineering Steering Group (IESG). Y el nombre IETF actualmente se refiere al
cuerpo entero, incluyendo el gerente general, los gerentes de área y todos los miembros de todos los grupos.
La IETF gestionó los procesos de estandarización. Los documentos de los protocolos resultantes se mantienen
en un repositorio on-line (www.ietf.org) y quedan disponibles sin cargo. La documentación de trabajo sobre
Internet, las propuestas de protocolos nuevos o revisados, y todos los estándares de TCP/IP aparecen en una
serie de reportes técnicos llamados Internet Request For Comments (RFCs). En la actualidad, la tarea de edi-
ción de las RFCs cae en los gerentes de área de la IETF.
Las RFCs se numeran secuencialmente en orden cronológico. Y a cada RFC nueva o revisada se le asigna un
nuevo número.

1.4 Crecimiento de Internet

Internet ha crecido rápidamente y nuevos protocolos se proponen constantemente. La exigencia y demanda
más significativa no es el crecimiento de las conexiones de red, sino el tráfico adicional y los nuevos patro-
nes de tráfico que aparecen. La Figura 1.1 resume la expansión de Internet. Y las Figuras 1.2 y 1.3 dan un
detalle del crecimiento del número de computadoras unidas a Internet en el tiempo.

Figura 1.1 Crecimiento de internet

Como se observa, Internet ha superado los 3.000.000 de usuarios alrededor del mundo, y se podría suponer
que se ha alcanzado un estado de producción estable. Sin embargo, ni Internet ni TCP/IP son estáticos. Las
innovaciones continúan cuando se desarrolla una nueva aplicación y nuevas tecnologías son usadas para me-
jorar los mecanismos e infraestructura subyacente.
Uno de los esfuerzos más significativos, en Internet y TCP/IP, involucra una revisión del Protocolo de Internet
IP. La versión corriente del Protocolo de Internet (IPv4) ha permanecido casi sin cambios desde su estableci-
miento a fines de los 1970s. Sin dudas, IP ha demostrado claramente que fue una propuesta flexible y potente.
En ese periodo de tiempo se han producido importantes cambios tecnológicos: apareció la tecnología inalám-
brica, el ancho de banda de los enlaces se multiplicó por un factor de 1.000.000, por ejemplo.
A pesar del éxito de IPv4, algunas críticas aparecieron a los comienzos de los 90s, dadas las limitaciones que
significaba para las nuevas aplicaciones de voz y video, y por la cantidad de direcciones disponibles del pro-
tocolo. IETF se propuso formular una versión de IP con la participación de representantes de varias comuni-
dades, como fabricantes de computadoras, vendedores de hardware y software, usuarios, programadores,
compañías de teléfono y la industria de la TV por cable. La IETP asignó a la revisión de la versión de IP el
número 6 (IPv6).
IPV6, inherentemente tiene varios de los conceptos, principios y mecanismos encontrados en IPv4, por lo que
no puede entenderse IPv6 sin entender IPv4. Aunque IPv6 cambia la mayoría de los detalles del protocolo, a
saber:
• Campo de dirección IP más grande: se cuadriplica el tamaño de 32 bits a 128 bits.
• Jerarquía de direcciones extendida: IPv6 usa una espacio de direcciones más grande para crear ni-
veles adicionales de la jerarquía de direcciones.
• Formato de la cabecera: IPv6 usa un nuevo e incompatible formato de paquete que incluye un
conjunto de cabeceras opcionales.
• Opciones mejoradas: IPv6 permite incluir en el paquete información de control no disponible en
IPv4. • Previsión para extensión del protocolo: Permite al IETF adaptar el protocolo a nuevo hardware
de red y nuevas aplicaciones. • Soporte para autoconfiguración y renumeración: IPv6 le permite a un
sitio automatizar los requisitos de cambio de dirección desde un ISP a otro.
• Soporte para asignación de recursos: IPv6 incluye una abstracción de flujo de tráfico y permite ser-
vicios diferenciados.

1.5 Migración a IPv6

Los diseñadores del protocolo planearon el cambio gradual sobre el tiempo para pasar de IPv4 a IPv6. Se usa
el término migración para referirse a este proceso. Los planes de migración pueden agruparse en:

• Una Internet IPv6 separada corriendo en paralelo: El objetivo es que los ISP creen una Internet en
paralelo corriendo IPv6. En la práctica IPv6 e IPv4 pueden compartir varios de los enlaces y dispositi-
vos. Sin embargo, el direccionamiento y el routing deben ser completamente independientemente.
• Islas IPv6 conectadas por IPv4 hasta ISPs con IPv6: El plan permite que las organizaciones individua-
les comiencen el uso de IPv6 antes que los proveedores ISP ejecuten IPv6. Cada organización sería
una isla IPv6 en el medio de un océano IPv4. Para enviar un datagrama entre islas es necesario hacer
la traducción de IPv6 a IPv4 y viceversa.
•Gateways que traduzcan entre IPv4 e IPv6: Esta aproximación usa dispositivos de red que trasladan
direcciones IPv4 a IPv6, y viceversa.

Cada estrategia de migración tiene ventajas y desventajas, y en algunos casos pueden ser complementarias.
Aunque el principal problema es que aún en la actualidad no está claro que ofrece IPv6, como estímulo, al
usuario final, a las organizaciones y a los proveedores. Como un interesante excepción, se ha observado un
cambio significativo en las zonas del mundo que no tienen disponibles direcciones IPv4 y/o se encuentran en
proceso de crecimiento de Internet desde instalaciones nuevas. A nivel de las computadoras individuales,
varios sistemas operativos (Linux, Windows, etc.) han avanzado sobre un stack dual, es decir, que el software
contiene todo lo necesario para IPv4 e IPv6. En la mayoría de los casos, estas dos versiones no interactúan
entre sí, dado que cada lado tiene una dirección IP y puede enviar y recibir paquetes. Esto permite que las
aplicaciones elijan si usarán IPv4, IPv6 o ambos. Lo ideal que la selección fuera automática. Las aplicaciones
más viejas continúan usando IPv4.
 TEMA 1
Sección 2
TECNOLOGÍAS DE RED

2.1 Conmutación de circuitos y conmutación de paquetes

Internet introdujo un nuevo método de interconectar redes individuales y un conjunto de protocolos que
permitieron interactuar computadoras separadas entre sí por varias redes. La tecnología de Internet requiere
distinguir entre los mecanismos de bajo nivel suministrados por el hardware de la red y las facilidades de alto
nivel que proveen los protocolos TCP/IP.

Desde la perspectiva del hardware, las redes se clasifican frecuentemente por las formas de energía que usa
el medio sobre el cual esa energía viaja (por ejemplo, señales eléctricas sobre cable de cobre). Desde una
perspectiva de comunicación, las tecnologías de red pueden separarse en dos grandes categorías que depen-
den de la interface que provean: orientadas a conexión (llamadas de conmutación de circuito) y sin conexión
(conocidas como de conmutación de paquetes).

Las redes orientadas a conexión operan formando una conexión o circuito dedicado entre dos puntos. Una
vez que se ha establecido un circuito, ninguna otra actividad de red decrecerá su capacidad. La principal des-
ventaja de esta tecnología es que los costos del circuito son fijos, independiente del uso. Por ejemplo, en los
sistemas telefónicos tradicionales los costos de la llamada permanecen fijos, aún a pesar de los momentos
en que ninguna parte habla.

Mientras que en las redes sin conexión, del tipo frecuentemente usado para conectar computadoras, se toma
una aproximación completamente diferente. En un sistema sin conexión, los datos se transfieren a través de
una red divididos en pequeñas piezas llamadas paquetes que se multiplexan en conexiones de alta capacidad.
Un paquete transporta información de identificación que le permite al hardware de la red conocer como
enviarlo al destino especificado. Por ejemplo, un archivo a enviar entre dos máquinas debe dividirse en varios
paquetes que viajan a través de la red de a uno por vez. La principal ventaja es que pueden proceder concu-
rrentemente múltiples comunicaciones entre computadoras, a pesar que un par de ellas, que se estén comu-
nicando, reciban menos de la capacidad de la red. Esta desventaja potencial no ha impedido que estas redes
se vuelvan muy populares debido al costo y las prestaciones. Debido a que múltiples computadoras pueden
compartir canales de red, en redes de conmutación de paquetes de alta velocidad, se requieren muy pocas
conexiones, el costo se mantiene bajo y la capacidad usualmente no es un problema.

Para el resto del texto usaremos el término red para referirnos a la tecnología de red sin conexión, salvo que
se indique lo contrario.

Las redes de datos que alcanzan grandes distancias geográficas (por ejemplo, a lo largo de un país) son total-
mente diferentes de aquellas que cubren cortas distancias (por ejemplo, en un edificio). Las tecnologías de
conmutación de paquetes se dividen frecuentemente en dos grandes categorías: Redes WAN (Wide Area
Networks) y Redes LAN (Local Area Networks).

Las tecnologías WAN proveen comunicaciones sobre largas distancias. La mayoría de las tecnologías WAN no
están limitadas en distancia, y pueden comunicar zonas de distintos continentes. Usualmente las WANs ope-
ran a velocidades más bajas que las LANs, y tienen mucho mayor retardo entre conexiones. Las redes LANs
alcanzan mayores velocidades a costa de sacrificar el alcance a distancias largas.
2.2 Esquemas de Direccionamiento Hardware

Los protocolos de Internet deben manipular un aspecto particular de hardware de red: los esquemas hetero-
géneos de direccionamiento. Cada tecnología de hardware define un mecanismo de direccionamiento que
las computadoras usan para especificar el destino para un paquete. Cada computadora unida a una red tiene
asignada una única dirección hardware. Un paquete enviado a través de una red incluye dos direcciones hard-
ware: una dirección destino que especifica el recipiente objetivo y una dirección origen que especifica el
transmisor. La dirección destino es colocada en la misma posición en cada paquete, haciendo posible al hard-
ware de la red examinar la dirección destino fácilmente. Además, un transmisor debe conocer la dirección
del recipiente objetivo (destino), y debe colocarla en el campo de dirección del destino de un paquete antes
de transmitirlo.

Por ejemplo, las siguientes tecnologías, que han sido usadas en Internet, tienen sus propios esquemas de
direccionamiento hardware:
• Ethernet (IEEE 802.3).
• Wi-Fi (IEEE 802.11).
• ZigBee (IEEE 802.15.4).
• Redes de Área Amplia Punto a Punto (SONET).

2.2.1 Ethernet (IEEE 802.3)

Ethernet es el nombre dado a una tecnología LAN de conmutación de paquetes muy popular de los años 70,
estandarizada en 1978 por Xerox, DEC e Intel. Luego, el IEEE liberó la versión compatible IEEE 802.3. Las ver-
siones corrientes se conocen como Gigabit Ethernet y 10 Gigabit Ethernet. Una red Ethernet consiste de un
conmutador (switch) Ethernet al que se unen múltiples computadoras a través de enlaces de cable de cobre
(par trenzado) o fibra óptica de alta velocidad (Fig. 1.4). Cada computadora debe tener una placa de red o
NIC (Network Interface Card) que opera como dispositivo de E/S para enviar o recibir paquetes.

Ethernet soporta broadcast, es decir, que un transmisor puede especificar que un paquete dado debe libe-
rarse a todos las computadoras de la red. Y además, utiliza la semántica de liberación de mejor esfuerzo. Esto
último significa que el hardware no garantiza los envíos ni informa al transmisor si el paquete no pudo entre-
garse. Este concepto es muy importante en el diseño de los protocolos TCP/IP.
El IEEE define un esquema de direccionamiento MAC (Media Access Control) de 48 bits. Una dirección MAC
única se asigna a cada placa de red que depende del fabricante y de su número de serie. Por este motivo,
dado que esta dirección está asociada al dispositivo hardware (placa de red), algunas veces se utiliza el ter-
mino dirección hardware o física como sinónimo de dirección MAC. Esta dirección está asociada a la placa de
red, no a la computadora.

El esquema IEEE 802.3 de direccionamiento MAC de 48 bits provee tres tipos de direcciones:

• Unicast: Se trata de una dirección única asociada a una placa de red como se describió previamente.
Si la dirección destino en un paquete es una dirección unicast, el paquete será liberado exactamente
a una computadora.

• Broadcast: Es una dirección con todos 1s, y se reserva para transmitir a todas las estaciones simul-
táneamente. Cuando un switch recibe un paquete broadcast, es decir, con todos 1s en la dirección
MAC destino, libera una copia del paquete a cada computadora en la red, excepto al transmisor.

• Multicast: Una dirección multicast provee una forma limitada de broadcast sobre un subconjunto
de las computadoras de una red que escuchan una dirección multicast dada. Al conjunto de compu-
tadoras participantes se le llama grupo multicast.

A causa que el término paquete es genérico y puede referirse a cualquier tipo de paquete, se usa el término
trama (frame) para referirse a un paquete que está definido por las tecnologías hardware. Las tramas Ethernet
son de longitud variable. Ninguna trama es más pequeña de 64 bytes o más grande que 1514 bytes. Cada
trama Ethernet contiene un campo de dirección destino y otro campo para la dirección origen, ambos de 48
bits. Además, se incluye un campo de verificación (CRC – Cyclic Redundancy Check) que se usa para determi-
nar la posibilidad de errores en la transmisión (Fig. 1.5).

Los paquetes usados en la mayoría de las tecnologías de red siguen el mismo patrón: el paquete consiste de
una cabecera pequeña con campos fijos, seguido por una carga de datos variables. El tamaño máximo de
carga en una trama Ethernet es de 1500 bytes.

2.2.2 Wi-Fi (IEEE 802.11)

El IEEE ha desarrollado una serie de estándares para redes inalámbricas (wireless) que están muy relacionadas
a Ethernet. Los estándares Wi-Fi tienen un número seguido de un sufijo; por ejemplo: 802.11g y 802.11n. Los
dispositivos wireless pueden incluir hardware de múltiples estándares e interoperar con otros dispositivos.

Cada uno de los estándares Wi-Fi puede usarse de dos formas: como una tecnología de acceso en cuyo caso
una simple estación base (llamada access point) conecta a múltiples estaciones, o una configuración punto a
punto usada para conectar exactamente dos radios wireless.

Las tramas IEEE 802.11 son de longitud variable. Ninguna trama es más pequeña de 40 bytes o más grande
que 2352 bytes. El tamaño máximo de carga en una trama Wi-Fi es de 2312 bytes.
2.2.3 ZigBee (IEEE 802.15.4)

Además de conectar computadoras convencionales, una interconexión puede usarse para comunicar dispo-
sitivos embebidos. El concepto de conectar dispositivos se conoce como una Internet de las cosas. Lógica-
mente que cada dispositivo que se conecta a Internet debe tener un procesador (CPU) embebido e incluir
una interface o placa de red. IEEE ha creado el estándar 802.15.4 para la tecnología de red wireless de baja
potencia, y comunicar dispositivos embebidos pequeños.
Un consorcio de vendedores ha elegido el término ZigBee para referirse a los productos que usan el estándar
IEEE 802.15.4 para las radios y ejecuta un stack de protocolo específico, que incluye IPv6 más otros protocolos
que permiten a un conjunto de nodos wireless organizarse a sí mismos en una malla que puede retransmitir
paquetes a y desde Internet.
La tecnología IEEE 802.15.4 suministra un interesante ejemplo para TCP/IP. El tamaño de paquete es de 127
bytes, pero sólo 102 bytes están disponibles para carga de datos. Además, el estándar define dos formatos
de dirección: una dirección MAC de 63 bits y otra de 16 bits.

2.2.4 Transporte y paquetes ópticos sobre SONET

Las compañías de teléfono originalmente diseñaron circuitos digitalizados para transportar llamadas de voz.
Posteriormente, los circuitos digitales de las compañías se volvieron importantes también para las redes de
datos. Por este motivo, las velocidades de datos multiplexadas no son potencia de diez. Efectivamente, los
circuitos han sido elegidos para transportar múltiplos de 64 Kbps, dado que una llamada de voz usa una co-
dificación conocida como PCM (Pulse Code Modulation) que produce 8000 muestras por segundo de 8 bits
cada una.

Los circuitos digitales más rápidos requieren el uso de fibra. Además, de los estándares que especifican la
transmisión de altas velocidades de datos, las compañías han desarrollado estándares para la transmisión de
las mismas velocidades sobre fibra óptica. La Figura 1.7 lista ejemplos de los estándares OC (Optical Carrier)
y las velocidades de datos de cada uno.

Figura 1.7 Ejemplo de tasas de datos disponibles en circuitos digitales que usan fibra.
El término SONET se refiere a un protocolo de entramado que permite a una portadora multiplexar múltiples
llamadas de teléfono de voz digital sobre una simple conexión. SONET se usa típicamente en conexiones OC.
Así, si un ISP alquila una conexión OC-3, el ISP puede necesitar usar entramado SONET.

2.2.5 Tecnología y dominios de broadcast

Un switch Ethernet forma una simple red LAN al conectar un conjunto de computadoras. Una forma más
avanzada de uso de un switch se conoce como un switch VLAN (Virtual LAN) que permite a un administrador
de red configurar el switch para operar como algunos switchs más pequeños. El administrador puede crear
una o más redes virtuales especificando que computadoras están unidas a que VLAN.

El administrador puede usar VLANs para separar las computadoras de acuerdo a políticas. Por ejemplo, una
compañía puede tener una VLAN para empleados y una VLAN separada para visitantes.

Las computadoras de los empleados pueden tener más privilegios de acceso que las computadoras sobre la
VLAN de los visitantes. Una clave para entender VLANs y su interacción con los protocolos de Internet involu-
cra la forma en que un switch de VLAN manipula los broadcast y los multicast.

Cada VLAN define un dominio de broadcast, lo que significa que cuando una computadora envía un paquete
broadcast, sólo se libera al conjunto de computadoras de la misma VLAN. La misma definición se aplica para
multicast.
Los protocolos de Internet no distinguen entre una VLAN y una red física independiente.

2.2.6 Puentes (Bridges)

Se usa el término bridging (tender un puente) para referirse a las tecnologías que transportan una copia de
una trama de una red a otra, y el término bridge (puente) para referirse al mecanismo que implementa brid-
ging. La motivación para usar bridging es formar una simple gran red usando bridges para conectar redes más
pequeñas.

La idea clave es que cuando se transfiere una copia de una trama, un bridge no realiza ningún cambio. Es
decir, la trama es meramente replicada y transmitida sobre la otra red. En particular, un bridge no altera las
direcciones fuente ni destino en la trama, y por lo tanto, es transparente, y las computadoras sobre las dos
redes pueden comunicarse directamente.

Originalmente, los vendedores de equipamiento de red vendían los bridges como dispositivos físicos separa-
dos. En la actualidad el bridging ahora está embebido en otros dispositivos. Por ejemplo, los ISPs que proveen
servicios a residentes transmiten tramas Ethernet sobre el Ethernet en la residencia usando bridging desde
el ISP y viceversa.

Un bridge Ethernet adaptativo conecta dos Ethernet, retransmite tramas desde una a otra, y usa la dirección
fuente en los paquetes para aprender que computadoras están sobre que Ethernet. Un bridge usa la ubica-
ción de las computadoras para eliminar las retransmisiones innecesarias.

2.2.7 Congestión y Pérdida de paquetes

En la práctica, la mayoría de las tecnologías de red trabajan tan bien que es fácil asumir completa confiabili-
dad. Sin embargo, a menos que un sistema de paquetes preserve capacidad antes de usarlo, es susceptible a
la congestión y la pérdida de paquetes. Para entender estos aspectos, consideremos un ejemplo trivial: un
switch Ethernet con sólo tres computadoras conectadas. Y supongamos que dos computadoras envían datos
a una tercera como ilustra la Figura 1.8.
Figura 1.8 Una Ethernet con flechas que indica el flujo de tráfico

Se asume que cada una de las conexiones al switch opera en 1 Gbps, y consideremos que sucede si las compu-
tadoras A y B envían datos a la computadora C continuamente. A y B transmitirán datos a una velocidad
agregada de 2 Gbps. Debido a que la conexión a C puede solo manipular la mitad de esa tasa, el enlace a C se
congestionará.
Recordemos que una red Ethernet usa la semántica de liberación de mejor esfuerzo. El switch Ethernet no
tiene forma de informar si un enlace de salida está congestionado. Internamente, un switch tiene una canti-
dad finita de espacio de buffer. Una vez que todos los buffers están llenos, el switch debe descartar las tramas
adicionales que arriban. Por lo tanto, aún con sólo tres computadoras conectadas a una Ethernet, es posible
que se descarten paquetes.
Es importante entender que la congestión y pérdida de paquetes pueden ciertamente ocurrir en las redes de
paquetes. Como veremos luego, será responsabilidad de TCP evitar la congestión.

Tema 1
Seccion 3
Interconexión y modelo arquitectónico

3.1 Interconexión a nivel de aplicación

En la SECCIÓN 2 se han introducido detalles de transmisión de bajo nivel a través de redes de datos particu-
lares. Se necesita describir conceptualmente un esquema que nos permita reunir tecnologías de red diversa
en un todo coordinado. El sistema debe ocultar los detalles del hardware de las redes subyacentes, mientras
suministra servicios de comunicación universal.
Cuando aparecieron las aplicaciones de red heterogéneas, los primeros diseñadores usaron programas de
aplicación específicos llamados gateways de aplicación, para ocultar las diferencias subyacentes y suministrar
una apariencia de uniformidad. Una de las primeras incompatibilidades apareció con los sistemas de emails
comerciales. Cada vendedor diseñó su propio sistema de email. El vendedor eligió un formato para almacenar
los correos, convenciones para identificar un recipiente y un método para transferir un mensaje de email
desde el emisor al destino. Desafortunadamente, los sistemas fueron absolutamente incompatibles.
Cuando se necesitaba una conexión entre sistemas de email, se usaba un gateway de aplicación. El gateway
de aplicación corría sobre una computadora que conectaba ambos sistemas de email como ilustra la Figura
1.9.
El gateway de aplicación debía entender los detalles de las conexiones de red y los protocolos de mensaje,
como así también, de formato de los mensajes de email usado en los dos sistemas de emails. Cuando el
usuario 1 enviaba un mensaje de email al usuario 2, el email del usuario 1 estaba configurado para enviar el
mensaje al gateway de aplicación. El gateway de aplicación debía encargarse de la traslación del mensaje y
de la dirección de email en uno y otro sentido.

El uso de programas de aplicación para ocultar los detalles de red puede parecer completamente razonable.
Esto es especialmente atrayente porque todo puede ser manipulado por una aplicación y no hay necesidad
de hardware adicional. Además, los sistemas de email originarios en las computadoras de los usuarios per-
manecen sin modificaciones. De hecho, ninguno de los usuarios ni el software de email en las computadoras
de los usuarios puede decir que el otro usuario tiene un sistema de email diferente.
Desafortunadamente, la aproximación de gateway de aplicación tiene bastantes limitaciones:

• Se trata de un gateway de aplicación específica y no puede usarse para transferir archivos, conectar
sesiones de chat o retransmitir mensajes de texto.

• No puede resolver cuando hay diferencias de funcionalidad entre los sistemas de email. Por ejem-
plo, cuando uno de ellos permite enviar adjuntos y el otro no.

• Si algunos de los sistemas de email se actualiza, también el sistema del gateway de aplicación.

• El sistema sólo trabaja para dos sistemas de email. La alternativa a usar gateways de aplicación es
un sistema basado en interconexión a nivel de redes.

La idea es que un sistema transfiera paquetes desde una fuente original a su destino último sin usar progra-
mas de aplicación intermedios con algunas ventajas fundamentales:
• Mapear directamente en el hardware de la red subyacente, ganando en eficiencia,

• Separar las actividades de comunicación de datos de los programas de aplicación, permitiendo que
dispositivos intermedios manipulen el tráfico de red sin que entiendan lo que están enviando o reci-
biendo,

• Mantener la flexibilidad del sistema entero que permite construir facilidades de comunicación de
propósito general no limitadas a un uso específico, y
• Sumar o cambiar tecnologías de red sin que esto implique un cambio de los programas de aplica-
ción.
La clave para diseñar una interconexión a nivel de red universal puede encontrarse en el concepto de sistemas
de comunicaciones abstracto conocido como internetworking. Este concepto de internet es muy importante.
Separa las nociones de comunicación de los detalles de las tecnologías de red y oculta los detalles de bajo
nivel a los usuarios y aplicaciones. Además, guía todas las decisiones de diseño de software y explica como
manipular direcciones y rutas físicas.

Hay dos observaciones fundamentales acerca de los sistemas de comunicaciones:

• Ninguna tecnología de hardware de red puede satisfacer todos las condiciones, y

• Los usuarios desean interconexión universal.

La primera observación es tanto económica como técnica. Las tecnologías LAN y WAN no pueden satisfacer
simultáneamente los siguientes requerimientos: alta velocidad, larga distancia y bajo costo. Dado que nin-
guna tecnología puede cumplir con las tres condiciones, se está forzado a considerar múltiples tecnologías
de hardware subyacente. La segunda observación es autoevidente. Un usuario arbitrario le va gustar comu-
nicarse con un punto arbitrario. Y como un consecuencia, se desea un sistema de comunicaciones que no
esté restringido por los límites de las redes físicas.

El objetivo es construir una interconexión cooperativa y unificada de redes que soporte un servicio de comu-
nicación universal. Cada computadora se unirá a una red específica y usará las facilidades de comunicación
dependientes de la tecnología subyacente. Todo nuevo software, insertado entre los mecanismos de comu-
nicación dependientes de la tecnología y los programas de aplicación, ocultará los detalles de bajo nivel y
presentará al conjunto de redes como una simple y gran red. A tal esquema de interconexión se le llama una
internetwork o internet.

3.2 Propiedades y arquitectura de Internet

Se pueden resumir los principios o propiedades fundamentales de Internet de la siguiente manera:

• Encapsulación: Ocultar la arquitectura de internet subyacente a los usuarios y permitir la comuni-

cación sin demandar conocimiento de la estructura de internet.

• Independencia topológica: No obligar al uso de una topología de interconexión de red.

• Independencia de locación: Enviar datos a través de las redes intermedias no demandando que
estén directamente conectadas a las computadoras origen o destino.

• Identificación universal: Todas las computadoras en el internet comparten un conjunto universal de

identificadores de máquina (nombres o direcciones).

• Independencia de redes y computadoras: El conjunto de operaciones para establecer una comuni-

cación o transferir datos debe permanecer independiente de las tecnologías de red subyacente y la
computadora destino.

Teniendo en cuenta estas propiedades y entendiendo como las computadoras se conectan a sus redes indivi-
duales, se debe establecer la forma en cómo las redes se interconectan entre sí para formar la internetwork.
Físicamente, dos redes no pueden conectarse directamente. Las redes usarán un sistema de computadora
intermedio que tenga el hardware necesario para conectarse a cada red. Las computadoras que interconectan
dos redes y pasan paquetes desde una a otra se llaman routers (encaminadores) de internet o routers IP. La
Figura 1.10 considera un ejemplo consistente de dos redes físicas y un router. El router R conecta ambas redes
y debe capturar los paquetes de la Red 1 (2) que tienen como destino las máquinas sobre la red 2 (1), y
viceversa.

En la Figura 1.10 se utilizan nubes para representar redes físicas donde el hardware no es importante. Cada
red puede ser una LAN o una WAN, y cada una podrá tener una cantidad (grande o pequeña) de computado-
ras. El uso de nubes enfatiza la diferencia importante entre routers y brigdes. Un router puede conectar redes
arbitrarias y un bridge puede sólo conectar dos redes que usan la misma tecnología.

3.3 Interconexión de múltiples redes con routers IP

Un internet real incluirá múltiples redes y routers. En tal caso, cada router necesita conocer acerca de las
redes más allá de las redes a la cuáles está directamente conectado. La Figura 1.11 considera tres redes in-
terconectadas por dos routers.

En el ejemplo, el router R1 debe transferir todos los paquetes desde la Red 1 a la Red 2 destinados para las
computadoras de la Red 2 o la Red 3. Igualmente, el router R2 debe transferir los paquetes de la Red 3 que
están destinados para, o bien, la Red 2 o la Red 1. Es decir, un router debe manipular paquetes para redes a
las cuales no está conectado. En una gran internet compuesta de varias redes, la tarea del router se vuelve
más compleja, porque también es más difícil tomar decisiones acerca de adonde enviar los paquetes.

El principio de interconexión (TCP/IP) supone sistemas de computadoras especiales llamados routers IP que
proveen interconexión entre redes físicas (no entre computadoras). Para cumplir su función necesitan tener
las rutas correctas para todas las redes en una internet.

Los routers usados en internets TCP/IP son computadoras modestas (similares a una PC) que no necesitan
grandes capacidades de almacenamiento. Esta importante simplificación se debe a que los routers retrans-
miten paquetes basados en las redes destino. La cantidad de información que un router necesita mantener
es proporcional al número de redes de internet, y no del número de computadoras de internet. Hay dos
órdenes de magnitud menos de redes que computadoras en Internet.
3.4 La vista de una interconexión a nivel de usuario
Una internet está diseñada para proveer una conexión universal entre las computadoras independientes de
las redes particulares a las cuales ellas están unidas. Para el usuario final, una internet es una red virtual a la
cual se conectan todas las máquinas independientes de su conexión física. La Figura 1.12 ilustra esta idea.

Figura 1.12 (a) La vista del usuario de una internet TCP/IP en la que cada computadora aparece unida a una simple gran
red, y (b) la estructura de las redes y routers físicos que suministran interconexión.

En la figura, la parte (a) muestra la vista que tiene el usuario. Los usuarios piensan de Internet como un sis-
tema de comunicación unificado. La vista del usuario simplifica los detalles y hace más fácil la conceptualiza-
ción de la comunicación. Mientras que la parte (b) ilustra las redes constituyentes de internet y su intercone-
xión con routers. Cada computadora que se conecta a una internet debe correr el software que “fuerza” esa
vista de una simple red física. Este software debe ocultar los detalles y permitir a los programas de aplicación
enviar y recibir paquetes a locaciones arbitrarias como si la computadora estuviera conectada a una simple
red.
Se vuelven evidentes algunas ventajas principales para los programas de aplicación al suministrar intercone-
xión a nivel de red:

• Independencia de las conexiones físicas: Debido a que los programas de aplicación que se comuni-
can sobre una internet no conocen los detalles de las conexiones subyacentes, pueden ejecutarse sin
cambios en las computadoras cuando se suma o se retiran conexiones físicas. Es el software de inter-
net que necesita reaccionar ante estos cambios. Por ejemplo, cuando un dispositivo portátil se co-
necta a una red Wi-Fi en distintos lugares sucesivamente, no afecta las aplicaciones.

• Independencia de la estructura de internet: Los usuarios no tienen que entender, recordar o espe-
cificar como las redes se conectan, qué tráfico transportan o qué aplicaciones soportan. Las redes
internas de una internet no conocen acerca de las aplicaciones, sólo transportan paquetes. Los pro-
gramadores no conocen la estructura de internet y pueden crear aplicaciones sin que internet deba
modificarse cuando aparece una nueva. Y por lo tanto, los administradores de red pueden cambiar
partes internas de la arquitectura de internet subyacente sin que esto tenga efecto sobre un software
de aplicación.
La Figura 1.12 (b) ilustra un punto acerca de una topología de internet: los routers no proveen conexiones
directas entre todos los pares de redes en una internet. Puede ser necesario pasar a través de varios routers
de redes intermedias para que viaje el tráfico desde una computadora a otra. Así, las redes que participan en
una internet son análogas a un sistema de rutas. Las redes locales alimentan redes más grandes, justamente
como una calle alimenta una ruta provincial o nacional.

3.5 Todas las redes son iguales

Desde el punto de vista de internet, cualquier sistema de comunicación capaz de transferir paquetes cuenta
como una simple red, independiente de su retardo y características de rendimiento, tamaño máximo de pa-
quete o escala geográfica. En esencia, una red LAN como Ethernet, una WAN usada como un backbone, una
redes wireless como un hotspot Wi-Fi, y un enlace punto a punto entre dos computadoras, cada una cuenta
como una red. TCP/IP define una abstracción de “red” que oculta los detalles físicos de la redes. Esta abstrac-
ción ayuda a los protocolos de TCP/IP para ser extremadamente flexibles y potentes. Y la selección de una
tecnología en particular dependerá del arquitecto de red quien debe elegir lo que es más apropiado en cada
caso.

Tema 1
Sección 4
Interconexión TCP/IP

4.1 La necesidad de múltiples protocolos

Las comunicaciones de red son un problema complejo con varios aspectos. Para entender la complejidad
deberíamos pensar en algunos de los problemas que pueden aparecer cuando las computadoras se comuni-
can sobre una red de datos:

• Fallas de hardware: Una computadora o un router pueden fallar por problemas en el hardware o
debido al sistema operativo. Además, un enlace de comunicaciones puede fallar o salirse de servicio.
En cualquier caso, un software del protocolo debe detectar tales fallas y recuperarse si es posible.

• Congestión de red: Las redes tienen capacidad finita, aunque puede pretenderse someterlas a un
exceso de tráfico. El software del protocolo debe organizar una forma de detectar la congestión y
suprimir cualquier tráfico ulterior para evitar que la situación empeore.
• Retardo o pérdida de paquetes: Algunas veces, los paquetes experimentan retardos extremada-
mente largos o simplemente se pierden. El software del protocolo necesita aprender acerca de las
fallas o adaptarse a los grandes retardos.

• Corrupción de los datos: La interferencia eléctrica o magnética, o las fallas del hardware pueden
causar errores de transmisión que corrompan los contenidos de los datos transmitidos. La interferen-
cia puede ser severa en ambientes wireless. El software del protocolo debe detectar y recuperarse de
tales errores.

• Duplicación de datos o arribos fuera de orden: Las redes que ofrecen múltiples rutas pueden trans-
 mitir los paquetes fuera de secuencia o pueden liberar duplicados de paquetes. El software del pro-
tocolo necesita registrar los paquetes y remover los duplicados. Estos problemas no pueden tratarse
fácilmente con una simple especificación de protocolo que los manipule a todos. Esto implica varios
protocolos trabajando cooperativamente. En los múltiples protocolos hay que definir las representa-
ciones necesarias para los datos que se pasan entre los módulos del software de comunicación. Este
pasaje de las presentaciones de los datos entre protocolos usa una secuencia lineal, donde la salida
de un protocolo es la entrada de otro adyacente.

Los módulos del software de los protocolos sobre cada computadora pueden observarse como apilados ver-
ticalmente en capas (layers), como ilustra la Figura 1.13. Cada capa tiene la responsabilidad de manipular una
parte de los problemas de comunicación.

Figura 1.13 La organización conceptual del software de protocolos en capas.

Conceptualmente, el envío de un mensaje de una aplicación sobre una computadora a una aplicación sobre
otra, implica transferir el mensaje hacia abajo a través de las capas sucesivas del software de los protocolos
en la máquina transmisora, retransmitir el mensaje a través de la red y transferir el mensaje hacia arriba a
través de las capas sucesivas del software de los protocolos en la máquina receptora.

Una vez que se ha decidido dividir el problema de comunicaciones y organizar el software de los protocolos
en capas que manipulan un subproblema, es necesario establecer cuántas capas deberían crearse y que fun-
ción debería cumplir cada una. Esto introduce algunas dificultades no menores. Por ejemplo, para un conjunto
de objetivos y restricciones que gobiernen un problema de comunicaciones en particular, es posible elegir
una organización de los protocolos que optimizará el software del protocolo para ese problema en particular.
Además, cuando se consideran servicios a nivel de red generales tales como un transporte confiable, hay
muchas aproximaciones fundamentalmente distintas para resolver este problema. Finalmente, el diseño de
una arquitectura de red (o internet) y la organización del software de protocolos están interrelacionados, y
no puede especificarse una sin la otra.

Existen dos aproximaciones para apilar protocolos que dominan el campo: el modelo OSI y la pila TCP/IP.
4.2 El modelo de referencia OSI de 7 capas

El primer modelo de capas se basó en los trabajos tempranos realizados por la Organización Internacional de
Estandarización (ISO –International Organization for Standarization), conocido como Modelo de Referencia
de Open System Interconnection OSI. Frecuentemente referido como el modelo OSI. Desafortunadamente,
el modelo OSI es un trabajo anterior a Internet, no describe bien los protocolos de Internet y contiene capas
no usadas por los protocolos TCP/IP. Por otro parte, en lugar de una capa dedicada a ‘internet”, el modelo OSI
se diseñó para una simple red y tiene una capa de “red”. El modelo contiene 7 capas conceptuales organizadas
como en la Figura 1.14.

Figura 1.14 Modelo de referencia ISO de 7 capas.

Aunque se diseñó para suministrar un modelo conceptual y no una guía de implementación, el esquema de
capas OSI se usó como la base de implementaciones tempranas de protocolos de red. Entre los protocolos
comúnmente asociados con el modelo OSI, la suite de protocolos conocida como X.25 fue probablemente la
más reconocida y ampliamente usada. X.25 fue adoptado para las redes de datos públicas y se volvió espe-
cialmente popular en Europa. Se utilizará X.25 cómo ayuda para entender el modelo de capas OSI.

En X.25 una red opera como un sistema de telefonía. Una red X.25 consiste de switchs de paquetes que con-
tienen la inteligencia necesaria para encaminar paquetes. Las computadoras no se conectan directamente a
los cables de comunicación de la red, sino a través de switchs de paquetes usando una línea de comunicación
serial. La conexión entre un host y un switch de paquete X.25 es una red en miniatura que consiste de un
enlace serie. Los hosts deben seguir un procedimiento complicado para transferir paquetes a través de la red.

Las capas de los protocolos especifican varios aspectos de la red:

• Capa física: X.25 especifica un estándar para la interconexión física entre las computadoras y los
switchs de paquetes de la red. En el modelo de referencia, la capa 1 especifica la interconexión física,
incluyendo las características eléctricas de tensión y corriente.
 • Capa de enlace de datos: La capa 2 de X.25 especifica cómo los datos viajan entre una computadora
y el switch de paquetes al cual está conectado. X.25 usa el término trama para referirse a una unidad
de datos cuando lo transfiere un switch de paquetes. Debido a que el hardware subyacente libera
sólo un stream de bits, el protocolo de capa 2 debe definir el formato de las tramas y especificar cómo
las dos máquinas reconocen los límites de la trama. A causa que los errores de transmisión pueden
destruir los datos, el protocolo de capa 2 incluye detección de error, como así también un mecanismo
de timeout que causa que una computadora reenvíe una trama hasta que ha sido transferida correc-
tamente. Es importante entender que la transferencia exitosa en capa 2 significa que una trama ha
sido pasada al switch de paquetes de la red; no significa que el switch de paquete haya sido capaz de
retransmitir o liberar el paquete.

• Capa de red: El modelo de referencia OSI especifica que la capa 3 contiene la funcionalidad que
completa la definición de la interacción entre el host y la red. Se la llama capa de subred de red o de
comunicaciones. La capa define la unidad básica de transferencia a través de la red e incluye los con-
ceptos de direccionamiento y retransmisión al destino. A causa que la capa 2 y 3 son conceptualmente
independientes, el tamaño del paquete de capa 3 puede ser mayor que el tamaño de las tramas de
capa 2. Es decir, una computadora puede crear un paquete de capa 3 y luego la capa 2 puede dividirlo
en piezas más pequeñas para transferir al switch de paquetes.

• Capa de transporte: La capa 4 provee confiabilidad extremo a extremo teniendo a la computadora

destino comunicada con la computadora origen. La idea es que aun cuando las capas inferiores de los
protocolos suministren controles de confiabilidad en cada transferencia, la capa de transporte provee
una verificación extra para asegurar que ninguna máquina en el medio falle.

• Capa de sesión: Las capas superiores del modelo OSI describen cómo el software de protocolo
puede estar organizado para manipular toda la funcionalidad necesaria para los programas de aplica-
ción. Cuando el modelo OSI fue establecido, las redes eran usadas para conectar una terminal (una
pantalla y un teclado) a una computadora remota. De hecho, el servicio ofrecido por las primeras
redes de datos públicas se focalizaban para proveer acceso de terminal. La capa 5 manipulaba estos
detalles.

• Capa de presentación: La capa 6 del modelo OSI fue pensada para estandarizar el formato de los
datos que los programas de aplicación enviaban sobre una red. Una de las desventajas de la estanda-
rización de los formatos se debe a que las nuevas aplicaciones no pueden desplegarse hasta que el
formato de los datos no ha sido estandarizado. Otra desventaja aparece cuando los grupos específicos
solicitan el derecho para representaciones estandarizadas apropiadas para sus dominios de aplicación
(por ejemplo, los grupos que especifican formatos de datos para video digital son grupos que mani-
pulan estándares para video más que grupos que estandarizan redes). Consecuentemente, los están-
dares de presentación son usualmente ignorados.
• Capa de aplicación: La capa 7 del modelo OSI incluye los programas de aplicación que usan la red.
Por ejemplo, programas de correo electrónico y de transferencia de archivos.

4.3 El modelo de referencia TCP/IP de 5 capas

El segundo mayor modelo de capas no apareció desde una cuerpo o institución de estándares formal. El mo-
delo surgió desde investigadores que diseñaron el Internet y la suite de protocolos TCP/IP. Cuando los proto-
colos TCP/IP se volvieron populares, los proponentes del más viejo modelo OSI intentaron ajustar el modelo
OSI para acomodarlo a TCP/IP. Sin embargo, el problema no pudo resolverse dado que modelo OSI original
no proveía una capa de internet, y las capas de sesión y presentación no eran pertinentes a los protocolos
TCP/IP.

Una de las mayores diferencias conceptuales entre los modelos de capa OSI e Internet aparecen debido a la
forma en que fueron definidos. El modelo OSI fue prescriptivo, es decir, la organización ISO convocó a un
comité que escribió las especificaciones de cómo los protocolos deberían construirse. Luego, comenzaron a
implementar los protocolos. La cuestión importante es que el modelo anticipa la implementación. Por el con-
trario, el modelo de Internet es descriptivo, dado que los investigadores consumieron años entendiendo
cómo estructurar los protocolos, construyendo implementaciones prototipo, y documentando los resultados.
Luego que los investigadores comprendieron el diseño se construyó el modelo.

Los protocolos TCP/IP están organizados en 5 capas conceptuales; 4 capas definen el procesamiento de pa-
quetes y una 5° capa define el hardware de red convencional. La figura 1.15 muestra las capas conceptuales
y lista la forma de los datos que pasan entre cada par sucesiva de capas.

Figura 1.15 Modelo de referencia TCP/IP de 5 capas.

El propósito general de cada capa es el siguiente:

• Capa de aplicación: En la capa superior, los usuarios invocan los programas de aplicación que acce-
den a los servicios disponibles a través de una internet TCP/IP. Una aplicación interactúa con uno de
los protocolos de la capa de transporte para enviar o recibir los datos. Cada programa de aplicación
pasa los datos en la forma requerida por la capa de transporte para el envío.

• Capa de transporte: La función primaria de la capa de transporte es suministrar comunicación desde

un programa de aplicación a otro. Tales comunicaciones son llamados extremo a extremo a causa que
involucran las aplicaciones sobre dos puntos extremos más que los routers intermedios. Una capa de
transporte puede regular el flujo de información. Puede también proveer transporte confiable, ase-
gurando que los datos arriben sin error y en secuencia. Para hacer esto, el software del protocolo de
transporte, del lado de la recepción, envía reconocimientos y del lado de transmisión retransmite los
paquetes perdidos. El software de transporte divide el stream de datos a transmitir en pequeñas
piezas (algunas veces llamadas segmentos) y pasa cada paquete de acuerdo a una dirección destino
 a la capa siguiente para transmisión. Como se describe luego, una computadora de propósito general
puede tener múltiples aplicaciones accediendo a internet en un momento. La capa de transporte
debe aceptar los datos desde algunas aplicaciones y enviarlos a la capa siguiente más baja. Para hacer
esto, a cada segmento le suma información adicional, incluyendo los valores que identifican que pro-
grama de aplicación envía los datos y que aplicación en el extremo de recepción recibe los datos. Los
protocolos de transporte también usan un checksum para protegerse contra los errores que causan
el cambio de bits. La máquina receptora usa el checksum para verificar que el segmento arribó intacto
y usa la información del destino para identificar el programa de aplicación al cuál debería liberarse.

• Capa de internet: La capa de internet manipula la comunicación desde una computadora a otra.
Acepta las solicitudes para enviar un paquete desde la capa de transporte con una identificación de
la computadora a la cual el paquete debería enviarse. El software del protocolo encapsula el paquete
de transporte en un paquete IP, llena la cabecera y envía el paquete IP directamente al destino (si el
destino está sobre la red local), o lo envía a un router para que sea retransmitido a través de internet
(si el destino es remoto). El software de la capa de internet también manipula los paquetes IP entran-
tes, verificando su validez y usando el algoritmo de retransmisión para decidir si el paquete debería
procesarse localmente o retransmitirlo. Para los paquetes destinados a la máquina local, el software
de la capa de internet elige el protocolo de transporte que gestionará el paquete.

• Capa de interface de red: La capa más baja del software TCP/IP comprende una capa de interface
de red responsable de aceptar los paquetes IP y retransmitirlos a una red específica. Una interface de
red puede consistir de un driver de dispositivo (por ejemplo, cuando la red es LAN a la cual la compu-
tadora se vincula) o un subsistema complejo que implementa un protocolo de enlace de datos.

En la práctica, el software del protocolo de Internet TCP/IP es mucho más complejo que el modelo simple de
la Figura 1.15. Cada capa toma decisiones acerca de la corrección del mensaje y elige una acción apropiada
en base al tipo de mensaje o la dirección destino. Por ejemplo, la capa de internet en la máquina receptora
debe decidir si el mensaje ha alcanzado el destino correcto. La capa de transporte debe decidir qué programa
de aplicación debería recibir el mensaje.

Una diferencia primaria entre el modelo de capas más simple ilustrado en la Figura 1.15 y el software de
protocolo en un sistema real aparece a causa que una computadora o un router pueden tener múltiples in-
terfaces de red y múltiples protocolos en cada capa. La Figura 1.16 muestra dicha complejidad comparando
las capas y los módulos de software.

El diagrama conceptual en la Figura 1.16 (a) muestra 5 capas de protocolos con una simple caja representando
cada capa. La ilustración más realista del software en la Figura 1.16 (b) muestra que ciertamente puede haber
una capa con un protocolo (Capa 3). Sin embargo, pueden haber múltiples aplicaciones en Capa 5, y más que
una aplicación puede usar un protocolo de transporte dado. Y en general, los protocolos de Internet tienen
múltiples protocolos de transportes en Capa 4, múltiples redes físicas en Capa 1 y múltiples módulos de in-
terfaces de red en Capa 2.
Fig.1.16 Una comparación de (a) el stack de protocolos conceptual y (b) una vista más realista del software de protoco-
los con múltiples interfaces de red y múltiples protocolos.

La Figura 1.16 (b) también presenta cómo pueden existir múltiples protocolos independientes por arriba de
IP, y otros tantos por debajo de IP, aunque todos los tráficos IP entrantes y salientes deben pasar a través de
IP. El modelo de capas nocaptura todos los detalles, pero ayuda a entender que un mensaje saliente atrave-
sará tres capas de protocolos intermedios ante de ser enviado a la red. Además, puede usarse para explicar
la diferencia entre un sistema final (las computadoras de usuario) y los sistemas intermedios (los routers). La
Figura 1.17 muestra la pila de capas usada en una internet con tres redes conectadas por dos routers.

Fig. 1.17 Capas de protocolos conceptuales necesarias en las computadoras y los routers para transferir un mensaje
desde una aplicación en la computadora A a una aplicación en la computadora B

En la Figura, una aplicación en la computadora A envía datos usando el protocolo de transporte para trans-
mitirlos a una aplicación que los recibe sobre una computadora B. El mensaje desciende a través del stack de
protocolos en la computadora A, y se transmite a través de la Red 1 al Router 1. Cuando alcanza el primer
router, el paquete pasa hasta la Capa de internet (Capa 3), que retransmite el paquete sobre la Red 2 al Router
2. En el Router 2, el mensaje pasa hasta la Capa 3, y es retransmitido sobre la Red 3 al destino. Cuando alcanza
la máquina destino final, el mensaje pasa hasta la capa de transporte, que libera el mensaje a la aplicación
receptora.

Se observa que los protocolos TCP/IP colocan mucho de la inteligencia en los hosts. Los routers, en Internet,
retransmiten los paquetes, pero no participan en los servicios de capa superior como los hosts.
4.4 El principio de pila de capas de protocolos

Independientemente del esquema de capas particular o las funciones de las capas, la operación de protocolos
apilados se basa sobre una idea fundamental. La idea, llamada principio de pila de capas de protocolos, puede
establecerse brevemente así.

Los protocolos apilados se diseñan de modo que la capa n en el destino recibe exactamente el mismo
objeto enviado por la capa n en el origen.

Aunque puede parecer obvio o trivial, el principio enunciado provee un importante fundamento que nos
ayuda en el diseño, implementación y entendimiento de los protocolos. Específicamente, el principio ofrece:

• Independencia de diseño de protocolo: Colocando una garantía en los ítems que pasan entre cada
par de capas, el principio de capas permite a los diseñadores de protocolos trabajar sobre una capa
por vez. Un diseñador de protocolos puede focalizarse sobre el intercambio de mensajes para una
capa dada con la certeza que las capas inferiores no alterarán los mensajes. Por ejemplo, cuando se
crea una aplicación de transferencia de archivo, un diseñador solo necesita imaginar dos copias de la
aplicación de transferencia de archivo ejecutándose sobre dos computadoras. La interacción entre
los dos copias puede planearse sin pensar en los otros protocolos debido a que el diseñador puede
asumir que cada mensaje será liberado exactamente como fue enviado. La idea que la red no debería
cambiar los mensajes parece tan obvia a los programadores de aplicación que la mayoría de ellos no
pueden pensar en construir las aplicaciones de red sin este concepto.

Afortunadamente, el principio de capas trabaja también para el diseño de los protocolos de capa inferior. Por
ejemplo, cuando un diseñador de protocolo trabaja sobre un nuevo protocolo de transporte, este puede asu-
mir que el módulo de protocolo de transporte en la máquina destino recibirá el mensaje si es enviado por el
módulo de protocolo de transportesobre la máquina transmisora. La idea clave es que un protocolo de trans-
porte puede diseñarse independientemente de los otros protocolos.

• Definición de la propiedad extremo a extremo: Informalmente, clasificamos un tecnología de red

como extremo a extremo si la tecnología suministra comunicaciones desde la fuente original al des-
tino último. La definición informal también se usa con los protocolos. El principio de capas nos per-
mite ser más preciso: decimos que un protocolo es extremo a extremo si y sólo si el principio de capas
se aplica entre la fuente original y el destino último. Otros protocolos se clasifican como máquina a
máquina debido a que el principio de capas sólo se aplica a través de un salto de red.

Para entender cómo se aplica en la practica el principio de capas, consideremos dos computadoras conecta-
das a una red. La Figura 1.18 ilustra las capas del software de protocolo ejecutándose en cada computadora
y los mensajes que pasan entre ellas.
Figura 1.18 El principio de capas cuando pasa a través de una red desde una aplicación en una computadora a una apli-
cación en la otra.

La ilustración del principio de capas es incompleta a causa que el diagrama en la Figura 1.18 solo muestra el
apilado para dos computadoras conectadas a una simple red. La Figura 1.19 muestra un ejemplo dónde un
mensaje se envía desde un programa de aplicación sobre una computadora a un programa de aplicación
sobre otra computadora a través de un router. Como se observa en dicha figura, el mensaje liberado usa dos
tramas de red separadas, una para la transmisión desde la computadora 1 al router R y otra desde el router
R a la computadora 2. El principio de capas de red establece que la trama liberada al router R es idéntica a la
trama enviada por la computadora 1, y la trama liberada a la computadora 2 es idéntica a la trama enviada
por el router R. Sin embargo, las dos tramas definitivamente diferirán. Para los protocolos de aplicación y de
transporte, el principio de capas se aplica extremo a extremo. Es decir, el mensaje liberado sobre la compu-
tadora 2 es exactamente el mismo mensaje que el protocolo envía a la computadora 1.

Fig. 1.19 El principio de capas cuando se pasa un mensaje desde una aplicación en una computadora, a través de un
router, y se entrega a una aplicación en otra computadora.
Es fácil entender que para las capas superiores, el principio de capas se aplica extremo a extremo y que para
las capas inferiores se aplica a una simple transferencia de máquina a máquina. Aunque no es fácil observar
cómo el principio de capas se aplica a la capa de internet. El objetivo del diseño de Internet fue presentar una
gran red virtual, con la capa de internet enviando los paquetes a través de la internet virtual de forma análoga
como el hardware de red envía tramas a través de una simple red. Así, parece lógico imaginar un paquete IP
enviado desde la fuente original al último destino, e imaginar al principio de capas garantizando que el último
destino reciba exactamente el paquete IP que la fuente original envió. Sin embargo, debe aclararse que un
paquete contiene campos tales como el contador “time to live” que debe cambiarse cada vez que el paquete
pasa a través de un router. Entonces, el último destino no recibirá exactamente el mismo paquete IP que
envió la fuente. Se concluye que aunque la mayoría de los paquetes IP permanecen intactos cuando pasan a
través de una internet TCP/IP, el principio de capas sólo se aplica a los paquetes a través de una simple trans-
ferencia de máquinas. Por lo tanto, la Figura 1.19 muestra a la capa de Internet suministrando un servicio de
máquina a máquina más que un servicio extremo a extremo.

4.5 El apilado de capas en redes de mallas

Las tecnologías hardware utilizadas en la mayoría de las redes garantizan que cada computadora unida puede
alcanzar directamente a las otras computadoras. Sin embargo, algunas tecnologías no garantizan las conexio-
nes directas. Por ejemplo, la tecnología Wireless ZigBee usa radios wireless de baja potencia que tienen un
rango limitado. Consecuentemente, si los sistemas ZigBee se despliegan en varias habitaciones de una resi-
dencia, la interferencia de estructuras metálicas puede significar que una radio dada pueda ser capaz de al-
canzar alguna, pero no todas las otras radios. Igualmente, un gran ISP (Internet Service Provider) podría elegir
alquilar un conjunto de circuitos digitales punto a punto para interconectar varios sitios. Aunque cada radio
ZigBee puede sólo alcanzar un subconjunto de los nodos y cada circuito digital sólo conecte 2 puntos, nor-
malmente se habla de red ZigBee y que un ISP tiene una red. Para distinguir tales tecnologías de las tecnolo-
gías de redes convencionales, se usa el término malla para caracterizar un sistema de comunicaciones cons-
truido con varios enlaces individuales.

El modelo de capas debería también funcionar en una red de mallas. Y ello depende de cómo los paquetes
se retransmiten a través de los enlaces. Si las retransmisiones ocurren en capa 2, la malla entera puede mo-
delarse como una simple red física. Se usa el término “malla inferior” (mesh-under) para describir tal situa-
ción. Por el contrario si IP manipula las retransmisiones, la malla debe modelarse como redes individuales. Se
usa el término “ruta sobre IP” (IP route-over), frecuentemente abreviado a “ruta sobre” para describir tales
casos. Con más precisión:

• Route-over: La mayoría de los ISP usan route-over. El ISP usa circuitos digitales alquilados para in-
terconectar routers y un router individual ve a cada circuito como una simple red. IP manipula todas
las retransmisiones y el router usa los protocolos de routing (encaminamiento) de Internet estándar.

• Mesh-under: La tecnología IEEE 802.15.4 usada en las redes ZigBee puede configurarse para actuar
como enlaces individuales o como una red completa. Es decir, pueden organizarse a sí mismos como
una simple red malla acordando el descubrimiento de vecinos y formar una red meshunder de capa
2 que retransmite los paquetes sin usar IP, o pueden formar enlaces individuales y permiten que IP
manipule la retransmisión. En términos del modelo de capas, el único cambio que introduce la apro-
ximación de mesh-under es un módulo de software que debe sumarse a la interface de red para
controlar las retransmisiones en los enlaces individuales. Se dice que el nuevo software controla la
retransmisión intranetwork. El nuevo software se conoce algunas veces como subcapa intranet, como
ilustra la Figura 1.20.
Figura 1.20 (a) Posición conceptual de una subcapa intranet que manipula las retransmisiones usando una aproximación
mesh-under, y (b) la correspondiente organización software.

Además de una subcapa intranet que manipula las retransmisiones a través del conjunto de enlaces indivi-
duales, no se requiere ningún otro cambio en todo el esquema de capas para acomodar la aproximación
mesh-under. Es interesante mencionar que ZigBee utiliza una modificación menor de la idea que se acaba de
describir. Aunque se recomienda usar la aproximación route-over, el consorcio ZigBee no recomienda los pro-
tocolos de routing IP estándar. En lugar de ello, el stack ZigBee usa un protocolo de routing especial que
aprende acerca de los destinos en la malla ZigBee y luego configura las retransmisiones IP a través de los
enlaces individuales.

La desventaja principal de la aproximación route-over es que prolifera varias rutas en la capa IP (una por cada
conexión entre 2 máquinas), causando que las tablas de retransmisión IP sean más grandes que lo necesario.
La desventaja principal de la aproximación mesh-under es que usa una tabla de retransmisión y un protocolo
de routing separados para actualizar la tabla de retransmisión. El protocolo de routing extra implica tráfico
adicional, pero debido a que la red de malla es mucho más pequeña que Internet y puede ser mucho más
estática, un protocolo de routing de malla de propósito especial puede ser más eficiente que un protocolo de
routing IP de propósito general. Una desventaja final de la aproximación mesh-under es que el routing intra-
net “antecede” al routing IP, lo que puede conducir a problemas de routing más difíciles de diagnosticar y
reparar.

4.6 Dos límites importantes en el modelo TCP/IP

El modelo de capas incluye dos límites conceptuales que pueden no ser obvios: un límite de direcciones de
protocolo que separa el direccionamiento de alto y bajo nivel, y un límite de sistema operativo que separa el
software de protocolo de los programa de aplicación. La Figura 1.21 ilustra los límites.
Fig. 1.21 Dos límites conceptuales en el modelo de capas.

Los límites se caracterizan por:

• Límite de direcciones de protocolo de alto nivel: Se ha descrito las direcciones usadas por varios
tipos de hardware de red. Posteriormente se describirá los protocolos de Internet y el direcciona-
miento Internet. Es importante distinguir dónde usarán las dos formas de direccionamiento. El mo-
delo de capas lo deja claro. Hay un límite conceptual entre la Capa 2 y la Capa 3. Las direcciones
hardware (MAC) son usadas en las Capas 1 y 2, pero no más arriba. Las direcciones de internet son
usadas por las Capas 3 a 5, pero no por el hardware subyacente. Resumiendo: Los programas de
aplicación y todo el software de protocolo desde la capa de internet hacia arriba usan sólo direcciones
de Internet; las direcciones usadas por el hardware de red están aisladas en las capas inferiores.

• Límite de sistema operativo: Existe otro límite importante: la división entre el software de protocolo
que se implementa en un sistema operativo y no en el software de aplicación. Aunque los investiga-
dores han experimentado que una parte de TCP/IP esté en una aplicación, la mayoría de las imple-
mentaciones colocan el software de protocolo en el sistema operativo, dónde puede ser compartido
por todas las aplicaciones. El límite es importante debido a que el pasaje de datos entre los módulos
dentro del sistema operativo es mucho menos oneroso que pasar datos entre el sistema operativo y
una aplicación. Se necesita una API especial que permita que una aplicación interactúe con el soft-
ware de protocolo.

4.7 Optimizaciones entre capas del modelo TCP/IP

Se ha dicho que el apilado de capas es una idea fundamental que suministra la base para el diseño de proto-
colos. Esto permite al diseñador dividir un problema complicado en subproblemas y resolver cada uno inde-
pendientemente. Desafortunadamente, el software que resulta de una división en capas estricta puede ser
extremadamente ineficiente. Como un ejemplo, consideremos el trabajo de la capa de transporte. La misma
debe aceptar un stream de bytes desde un programa de aplicación, dividir el stream en segmentos, y enviar
cada segmento a través de la internet subyacente. Para optimizar las transferencias, la capa de transporte
debería elegir el tamaño de segmento más grande que se permitirá viajar en una trama de la red. En particu-
lar, si la máquina destino está unida directamente a la misma red como el origen, sólo una red física estará
involucrada en la transferencia y el emisor puede optimizar el tamaño de segmento para esa red. Si el soft-
ware de protocolo preserva estrictamente el apilado de capas, la capa de transporte no puede saber cómo el
módulo de internet retransmitirá el tráfico o a cuáles redes ataca directamente. Y por lo tanto, la capa de
transporte no entenderá los formatos de los paquetes usados por las capas inferiores, ni será capaz de deter-
minar cuántos bytes se sumarán a la cabecera del mensaje a enviar. Así, el apilado de capas estricto impedirá
a la capa de transporte optimizar las transferencias.
Usualmente el implementador relaja el esquema de apilado de capas estricto cuando construye el software
de protocolo. Ellos permiten que las capas superiores de un stack de protocolos obtengan información tales
como el tamaño de paquete máximo o la ruta que se usa. Cuando se asignan buffers de segmentos, los pro-
tocolos de la capa de transporte pueden usar la información para optimizar el procesamiento, dejando sufi-
ciente espacio para las cabeceras que sumarán los protocolos de capa inferior. Igualmente, los protocolos de
capa inferior frecuentemente retienen todas las cabeceras de una trama entrante cuando pasan la trama a
los protocolos de capa superior. Tales optimizaciones pueden generar importantes mejoras en eficiencia
mientras se conserva la estructura de capas básica.

4.8 La idea básica de multiplexación y demultiplexación

Los protocolos de comunicación usan un par de técnicas conocidas como muliplexación y demultiplexación a
través de la jerarquía de capas. Cuando se envía un mensaje, la computadora origen incluye bits adicionales
que almacenan metadatos, tales como el tipo de mensaje, la identidad del programa de aplicación que envía
los datos, y el conjunto de protocolos que han sido usados. En el extremo receptor, una computadora destino
usa los meta-datos para guiar el procesamiento.

Por ejemplo, en el caso de Ethernet, las tramas incluyen un campo type que especifica que transporta la
trama. Se verá luego que la trama Ethernet puede contener un paquete IPv4 o un paquete IPv6. El transmisor
envía el campo type en la trama para indicar que está enviándose. Cuando la trama arriba al destino, el soft-
ware de protocolo en la computadora receptora usa el type de la trama para elegir un módulo de protocolo
para procesar la trama. Se dice que el software demultiplexa las tramas entrantes. La Figura 1.22 ilustra el
concepto.

Figura 1.22 Ilustración de la demultiplexación que usa un campo tipo en la cabecera de la trama. La demultiplexación se
usa en la mayoría de las redes, incluyendo Ethernet y Wi-Fi.

La multiplexación y demultiplexación ocurren en cada capa. La demultiplexación ilustrada en la Figura 1.22

ocurre en la capa de interface de red o de Capa 2. Para entender la demultiplexación en capa 3, se puede
considerar una trama que contenga un paquete IP. Se ha visto que una trama demultiplexada pasará el pa-
quete al módulo IP para su procesamiento. Una vez que ha sido verificado que el paquete es válido (es decir,
ha sido liberado al destino correcto), IP efectuará una demultiplexación ulterior pasando el paquete al módulo
de protocolo de transporte apropiado.
El protocolo IP puede conocer que protocolo de transporte usó el emisor dado que cada paquete IP contiene
en la cabecera un campo type (similar a Ethernet). El transmisor configura el campo type de IP para indicar
qué protocolo de transporte ha sido usado. La Figura 1.23 ilustra cómo IP demultiplexa entre tres protocolos
ejemplos.

Figura 1.23 Ilustración de demultiplexación de los paquetes IP entrantes basados en el campo type de la cabecera IP.

Para garantizar el acuerdo universal sobre los tipos, en los estándares se especifican los valores a usarse. Por
ejemplo, el IEEE especifica un conjunto de valores para los tipos Ethernet y la IETF especifica valores para el
protocolo de Internet.