Modulo 2 - Familia de Protocolos TCP-IP

POSTGRADO A DISTANCIA :
INGENIERIA DE TELECOMUNICACIONES
MÓDULO 2
FAMILIA DE PROTOCOLOS TCP / IP
OBJETIVOS
Entre los objetivos mas importantes del presente capitulo tenemos:
• Describir brevemente cada unas de las capas de los modelos OSI y TCP/IP
• Hacer una comparación entre los modelos OSI y TCP/IP
• Desarrollar el protocolo IP y aplicar el direccionamiento IP con subnetting
• Brevemente dar las características mas resaltantes de los protocolos ICMP, ARP,
RARP e IGMP
• Brevemente dar las características mas resaltantes de los protocolos de
enrutamiento OSPF y BGP en la capa de red.
SUMARIO
2.1 Modelos de referencia

2.1.1 Modelo de referencia OSI
2.1.2 Modelo de referencia TCP/IP
2.1.3 Comparación de los modelos OSI y TCP/IP
2.2 Internet Protocol (IP)
2.2.1 Introducción
2.2.2 Funciones del protocolo IP
2.2.3 Formato de la unidad de protocolo IP
2.2.4 Fragmentación
2.2.5 Clases de direcciones
2.3 Subnetting
2.3.1 ¿Cuál es la idea de subnetting?
2.3.2 Mascara de subred
2.3.3 Tipos de subnetting
2.4 Protocolos que trabajan con IP
2.4.1 ICMP
2.4.2 OSPF
2.4.3 BGP
2.4.4 IGMP
DIVISIÓN DE TELEDUCACIÓN 1 REDES DE COMUNICACIÓN DE DATOS

2.5 Capa de acceso a la red

2.5.1 Protocolo ARP
2.5.2 Protocolo RARP
INTRODUCCIÓN
A finales de los años sesenta, el Departamento de Defensa de los Estados Unidos creó la
red Arpanet para poder investigar la comunicación de los paquetes. DARPA (Defense
Advanted Research proyects Agency) fue el organismo que promovió el desarrollo de
ARPANET, red que llegó a interconectar, en 1972, bases militares, centros de investigación,
universidades y laboratorios gubernamentales.
En 1982 se especificó un nuevo conjuntos de protocolos para ARPANET que fue

referenciado por TCP/IP. Se suministraron implementaciones con las versiones 4.1 y 4.2
BSD de UNIX, la cual facilito su expansión.
En 1983 TCP/IP se adoptó como estándar en ARPANET. A su vez una segunda red llamada
MILNET, dedicada exclusivamente a aspectos militares se separó de ARPANET, y así
comenzó a formarse la red INTERNET. Actualmente TCP/IP se considera como el conjunto
de protocolos abiertos, no específicos de un fabricante determinado, más extendido, con lo
que se ha convertido en un estándar de ISO, soportado por la mayoría de los fabricantes en
los sistemas operativos mas extendidos.
En este capítulo se da una visión de los protocolos utilizados en esta red, cuyo nombre,
INTERNET, alude tanto a la organización que se crea para el desarrollo de normas y
arquitecturas, como para la propia red o sus protocolos.

DESARROLLO DEL MÓDULO
2.1 MODELOS DE REFERENCIA
Hasta aquí hemos hablado del modelo de capas en un sentido genérico. Vamos a hablar
ahora con cierto detalle de las dos arquitecturas de redes mas importantes en la actualidad,
correspondientes a los protocolos OSI (Open Systems Interconnection) y TCP/IP
(Transmission Control Protocol/Internet Protocol). Conviene destacar que la arquitectura es
una entidad abstracta, mas general que los protocolos o las implementaciones concretas en
que luego se materializan éstos. Típicamente para cada capa de una arquitectura existirán
uno o varios protocolos, y para cada protocolo habrá múltiples implementaciones. Las
implementaciones cambian continuamente; los protocolos ocasionalmente se modifican o
aparecen otros nuevos que coexisten con los anteriores o los dejan anticuados; sin embargo
una vez definida una arquitectura ésta permanece esencialmente intacta y raramente se
modifica.
2.1.1 El modelo de referencia OSI
En 1977 la ISO (International Organization for Standardization) consideró que esta situación
no era la más conveniente, por lo que entre 1977 y 1983 definió la arquitectura de redes OSI
con el fin de promover la creación de una serie de estándares que especificaran un conjunto
de protocolos independientes de cualquier fabricante. Se pretendía con ello no favorecer a
ninguno a la hora de desarrollar implementaciones de los protocolos correspondientes, cosa
que inevitablemente habría ocurrido si se hubiera adoptado alguna de las arquitecturas
existentes, como la SNA de IBM o la DNA (Digital Network Architecture) de Digital. Se
esperaba llegar a convertir los protocolos OSI en el auténtico Esperanto1 de las redes
telemáticas. Por diversas razones que veremos luego el éxito de los protocolos OSI en la
práctica ha sido mucho menor de lo inicialmente previsto.
Seguramente la aportación más importante de la iniciativa OSI ha sido precisamente su

arquitectura. Ésta ha servido como marco de referencia para describir multitud de redes
correspondientes a diversas arquitecturas, ya que la arquitectura OSI es bien conocida en
entornos de redes, y su generalidad y no-dependencia de ningún fabricante en particular le
hacen especialmente adecuada para estos fines. Por este motivo generalmente a la
arquitectura OSI se la denomina Modelo de Referencia OSI.
1
Lengua inventada que se creo para que la aprendiera todo el mundo. Así todos podrían hablar uno con otro.

Fig. 1.1 Modelo de Referencia OSI
El modelo OSI define siete capas, curiosamente como en la arquitectura SNA si bien la
funcionalidad es diferente. Las capas son las siguientes: Física, Enlace, Red, Transporte,
Sesión, Presentación y Aplicación .
La ISO ha especificado protocolos para todas las capas, aunque algunos son poco
utilizados. En función del tipo de necesidades del usuario no siempre se utilizan todas ellas.
Pasaremos a describir brevemente las funciones desarrolladas por cada una de las capas.
El propósito de este modelo de referencia internacional de normas de interconexión de
sistemas abiertos es proporcionar una base común para la coordinación de normas
relacionadas con el propósito de interconectar sistemas, a la vez que se permite que las
normas existentes sean colocadas en una perspectiva dentro del modelo de referencia
general.
El término interconexión de sistemas abiertos (OSI – Open System Interconnection) califica

normas para el intercambio de información entre sistemas que son abiertos uno al otro en
virtud del uso mutuo de las normas aplicables. Que un sistema sea abierto no implica
ninguna implementación particular de sistemas, tecnología, o medios de interconexión, sino
se refiere al mutuo reconocimiento y soporte de normas aplicables. También es propósito de
esta norma internacional identificar áreas para desarrollar o mejorar las normas, y dar una
referencia común para mantener la consistencia de todas las normas relacionadas. Estas
normas internacionales no intentan servir como una especificación de implementación, o
servir de base para la aprobación de las implementaciones actuales, o proveer el suficiente
nivel de detalle para definir con precisión los servicios y protocolos de la arquitectura de

interconexión; en vez de esto, brindan una estructura conceptual y funcional que permite a
los grupos de expertos internacionales trabajar productiva e independientemente para
desarrollar normas para cada capa del modelo de referencia de la OSI.
2.1.1.1 Principios de estructuras de capas

Una técnica estructural ampliamente aceptada y elegida por la ISO es la de estructura de
capas o de niveles (layering). Las funciones de comunicaciones son particionadas en un
conjunto vertical de capas. Cada capa lleva a cabo un subconjunto de funciones requeridas
para comunicarse con otro sistema. Ésta se basa en la capa próxima de más bajo nivel para
llevar a cabo funciones más primitivas y para coordinar los detalles de estas funciones. Esta
capa provee servicios a la próxima capa más alta. Idealmente, las capas deberían estar
definidas de tal manera que los cambios en una capa no requieran cambios en otra capa.
De esta manera, se divide un problema en un mayor número de problemas más pequeños y,
por ende, más manejables.
Los principios usados en definir las capas OSI son las siguientes:
- No crear más capas de las que sean estrictamente necesarias.

- Crear una frontera en un punto donde la descripción de servicios puede ser pequeña
y el número de interacciones a través de la frontera sea minimizada.
- Crear capas separadas para manejar funciones que son manifiestamente diferentes
en el proceso llevado a cabo o en la terminología involucrada.
- Aglutinar funciones similares dentro de la misma capa.
- Seleccionar barreras en un punto donde la experiencia pasada haya demostrado que
sean exitosas.
- Crear una capa que tenga funciones localizadas fácilmente, de tal manera que la
capa pueda ser totalmente rediseñada y sus protocolos cambiados en una mayor
manera para tomar ventaja de los nuevos avances en la tecnología arquitectural, de
hardware y de software sin cambiar los servicios esperados desde y provistos por las
capas adyacentes.
- Crear una frontera donde pueda ser útil algún punto en el tiempo, para tener una
interface correspondiente normalizada.
- Crear una capa donde haya la necesidad de diferentes niveles de abstracción en el
manejo de los datos, tal como por ejemplo: morfología, sintaxis, semántica, etc.
- Permitir cambios de las funciones de los protocolos que han de hacerse dentro de la
capa sin afectar a otras capas.

- Crear fronteras para cada capa, para su capa superior y su capa inferior solamente.
Similares principios han sido aplicados a las subcapas.
- Crear más subgrupos y organizaciones o funciones para formar subcapas dentro de
una capa en casos donde servicios de comunicaciones distintivos lo requieran.
- Crear, cuando sea necesario, dos o más capas con una funcionalidad, aunque sea
mínima, para permitir una operación de interface con las capas adyacentes.
- Permitir el by-pass de las subcapas.
El atractivo del enfoque del modelo OSI es su promesa de resolver el problema de

comunicaciones entre computadoras heterogéneas. Dos sistemas, no importantes cuan
diferentes sean, pueden comunicarse efectivamente si ellos tienen en común lo siguiente:
- Que ellos implementen el mismo conjunto de funciones de comunicaciones.

- Que estas funciones estén organizadas en el mismo conjunto de capas. Capas pares
deben proveer la misma función, pero nótese que no necesariamente ellas deben
proveerlas en la misma manera. Las capas pares deben compartir un protocolo
común.
2.1.1.2 Descripción de las capas de OSI

A continuación la descripción de las funciones que cumple cada una de las siete capas:
Física, enlace, Red, Transporte, Sesión, Presentación y Aplicación.
• LA CAPA FÍSICA: Esta capa transmite los bits entre dos entidades (nodos)
directamente conectadas. Puede tratarse de un enlace punto a punto o de una
conexión multipunto (una red broadcast, por ejemplo Ethernet). La comunicación
puede ser dúplex, semi-dúplex o simplex. Si la información se transmite por señales
eléctricas se especifican los voltajes permitidos y su significado (1 ó 0) y
análogamente para el caso de fibra óptica. Se especifican las características
mecánicas del conector, la señalización básica, etc.
Como ejemplos de la capa física podemos mencionar las norma EIA RS-232-C,
utilizada por las puertas COM de los computadores personales, la EIA-RS-449,
CCITT X.21/X.21bis, CCITT V.35. Las normas de redes locales incluyen en sus
especificaciones la capa física (IEEE 802.3 o Ethernet, IEEE 802.5 o Token Ring,
ISO 9314 o FDDI, etc.)
Muchas de las normas que existen en la capa física se refieren a la interfaz utilizada
para conectar un computador con un módem o dispositivo equivalente, que a través
de una línea telefónica conecta con otro módem y computador en el extremo

opuesto. Este es el caso por ejemplo de las normas EIA RS-232-C, EIA-RS-449,
CCITT X.21/X.21bis y CCITT V.35 antes mencionadas. En estos el conector del
computador y el módem son de diferente ‘sexo’ (macho o hembra). En este contexto
se suele utilizar la denominación DTE (Data Terminal Equipment) para referirse al
computador y DCE (Data Circuit-Terminating Equipment) para referirse al módem. El
‘módem’ en ocasiones no es más que un adaptador, ya que por ejemplo la norma
X.21 se utiliza para líneas digitales. En sentido general al equipo que actúa como
adaptador entre el computador y el medio de transmisión se le denomina CSU/DSU
(Channel Service Unit/ Data Service Unit).
• LA CAPA DE ENLACE (DATA LINK): La principal función de la capa de enlace es

ofrecer un servicio de comunicación fiable a partir de los servicios que recibe de la
capa física, también entre dos entidades contiguas de la red. Esto supone que se
realice detección y posiblemente corrección de errores. A diferencia de la capa física,
que transmitía los bits de manera continua, la capa de enlace transmite los bits en
grupos denominados tramas (frames en inglés) cuyo tamaño es típicamente de unos
pocos cientos a unos pocos miles de bytes. Si el paquete recibido de la capa
superior es mayor que el tamaño máximo de trama la capa de enlace debe
encargarse de fragmentarlo, enviarlo y recomponerlo en el lado opuesto. En caso de
que una trama no haya sido transmitida correctamente se deberá enviar de nuevo;
también debe haber mecanismos para reconocer cuando una trama se recibe
duplicada. Generalmente se utiliza algún mecanismo de control de flujo, para evitar
que un transmisor rápido pueda ‘abrumar’ a un receptor lento.
Las redes broadcast utilizan funciones especiales de la capa de enlace para controlar
el acceso al medio de transmisión, ya que éste es compartido por todos los nodos de
la red. Esto añade una complejidad a la capa de enlace que no está presente en las
redes basadas en líneas punto a punto, razón por la cual en las redes broadcast la
capa de enlace se subdivide en dos subcapas: la inferior, denominada subcapa MAC
(Media Access Control) se ocupa de resolver el problema de acceso al medio, y la
superior, subcapa LLC (Logical Link Control) cumple una función equivalente a la
capa de enlace en las líneas punto a punto.
• LA CAPA DE RED: La capa de red se ocupa del control de la subred. Esta es la

capa que tiene ‘conciencia’ de la topología de la red, y se ocupa de decidir por que
ruta va a ser enviada la información; la decisión de la ruta a seguir puede hacerse de
forma estática, o de forma dinámica sobre la base de información obtenida de otros
nodos sobre el estado de la red.

De forma análoga a la capa de enlace la capa de red maneja los bits en grupos
discretos que aquí reciben el nombre de paquetes; motivo por el cual a veces se la
llama la capa de paquete. Los paquetes tienen tamaños variables, pudiendo llegar a
ser muy elevados, sobre todo en protocolos recientes, para poder aprovechar
eficientemente la elevada velocidad de los nuevos medios de transmisión (fibra
óptica, ATM, etc.). Por ejemplo en TCP/IP el tamaño máximo de paquete es de 64
KBytes, pero en el nuevo estándar, llamado IPv6, el tamaño máximo puede llegar a
ser de 4 GBytes (4.294.967.296 Bytes)
Entre las funciones de la capa de red cabe destacar, aparte de la ya mencionada de
elegir la ruta a seguir, el control del tráfico para evitar situaciones de congestión o
'atascos'. En el caso de ofrecer servicios con QoS el nivel de red debe ocuparse de
reservar los recursos necesarios para poder ofrecer el servicio prometido con
garantías. También debe ser capaz de efectuar labores de contabilidad del tráfico en
caso necesario (por ejemplo si el servicio se factura sobre la base de la cantidad de
datos transmitidos)
La capa de red es la más importante en redes de conmutación de paquetes (tales
como X.25 o TCP/IP). Algunos ejemplos de protocolos utilizados en la capa de red
son los protocolos de nivel de paquete y nivel de pasarela CCITT X.25 y X.75, el IP
(Internet Protocol), CCITT/ITU-T Q.931, Q.933, Q.2931, y el OSI CLNP
(ConnectionLess Network Protocol).
• LA CAPA DE TRANPORTE: La capa de transporte es la primera que se ocupa de

comunicar directamente nodos terminales, utilizando la subred como un medio de
transporte transparente gracias a los servicios obtenidos de la capa de red. Por esta
razón se la ha llamado históricamente la capa host-host. También se suele decir que
es la primera capa extremo a extremo.
La principal función de la capa de transporte es fragmentar de forma adecuada los
datos recibidos de la capa superior (sesión) para transferirlos a la capa de red, y
asegurar que los fragmentos llegan y son recompuestos correctamente en su
destino.
En condiciones normales la capa de transporte solicita a la capa de red una conexión
diferente por cada solicitud recibida de la capa de sesión, pero puede haber razones
de costo que aconsejen multiplexar diferentes conexiones en la capa de sesión sobre
una sola conexión en la capa de red o, inversamente, razones de rendimiento
pueden requerir que una conexión solicitada por la capa de sesión sea atendida por
varias conexiones en la capa de red; en ambos casos la capa de transporte se

ocupará de hacer la multiplexación mas adecuada de forma transparente a la capa

de sesión.
La capa de transporte establece el tipo de servicio que recibe la capa de sesión, y en
último extremo los usuarios. Éste podría ser por ejemplo un servicio libre de errores
que entrega los mensajes en el mismo orden en que se envían; también podría ser
un servicio de datagramas, es decir, mensajes independientes sin garantía en cuanto
al orden de entrega ni confirmación de la misma, o un servicio broadcast o multicast
en que los paquetes se distribuyen a múltiples destinos simultáneamente.
El control de flujo, que ha aparecido en capas anteriores, es necesario también en la
capa de transporte para asegurar que un host rápido no satura a uno lento. La capa
de transporte realiza también su propio control de errores, que resulta ahora esencial
pues algunos protocolos modernos como Frame Relay o ATM han reducido o
suprimido totalmente el control de errores de las capas inferiores, ya que con las
mejoras en la tecnología de transmisión de datos éstos son menos frecuentes y se
considera más adecuado realizar esta tarea en el nivel de transporte.
Ejemplos de protocolos de transporte incluyen el CCITT X.224, también llamado
protocolo de transporte OSI TP4 (Transport Protocol 4). En Internet existen dos
protocolos de transporte: TCP y UDP.
• LA CAPA DE SESIÓN: La capa de sesión es la primera que es accesible al usuario,

y es su interfaz más básica con la red. Por ejemplo, mediante los servicios de la capa
de sesión un usuario podría establecer una conexión como terminal remoto de otro
computador. En un sistema multiusuario la capa de sesión se ocupa de ofrecer un
SAP a cada usuario para acceder al nivel de transporte.
• LA CAPA DE PRESENTACIÓN: Hasta aquí nos hemos preocupado únicamente de

intercambiar bits (o bytes) entre dos usuarios ubicados en dos computadores
diferentes. Lo hemos hecho de manera fiable y entregando los datos a la sesión, es
decir al usuario, pero sin tomar en cuenta el significado de los bits transportados. La
capa de presentación se ocupa de realizar las conversiones necesarias para
asegurar que dichos bits se presentan al usuario de la forma esperada. Por ejemplo,
si se envía información alfanumérica de un computador ASCII a uno EBCDIC será
preciso efectuar una conversión, o de lo contrario los datos no serán interpretados
correctamente. Lo mismo podríamos decir de la transferencia de datos enteros,
flotantes, etc. cuando la representación de los datos difiere en los computadores
utilizados.

• LA CAPA DE APLICACIÓN: La capa de aplicación comprende los servicios que el

usuario final está acostumbrado a utilizar en una red telemática, por lo que a menudo
los protocolos de la capa de aplicación se denominan servicios. Dado que se crean
continuamente nuevos servicios, existen muchos protocolos para la capa de
aplicación, uno o más por cada tipo de servicio. Ejemplos de protocolos estándar de
la capa de aplicación son el CCITT X.400, X.420, X.500, FTAM. SMTP, FTP, HTTP,
etc.
2.1.2 El modelo de referencia TCP/IP
En 1969 la agencia ARPA (Advanced Research Projects Agency) del Departamento de

Defensa (DoD, Department of Defense) de los Estados Unidos inició un proyecto de
interconexión de computadores mediante redes telefónicas. Al ser un proyecto desarrollado
por militares en plena guerra fría un principio básico de diseño era que la red debía poder
resistir la destrucción de parte de su infraestructura (por ejemplo a causa de un ataque
nuclear), de forma que dos nodos cualesquiera pudieran seguir comunicados siempre que
hubiera alguna ruta que los uniera. Esto se consiguió en 1972 creando una red de
conmutación de paquetes denominada ARPAnet, la primera de este tipo que operó en el
mundo. La conmutación de paquetes unida al uso de topologías malladas mediante
múltiples líneas punto a punto dio como resultado una red altamente fiable y robusta. Esta
red se basó en el modelo de referencia TCP/IP (DoD Network Architecture).
La ARPAnet fue creciendo paulatinamente, y pronto se hicieron experimentos utilizando

otros medios de transmisión de datos, en particular enlaces por radio y vía satélite; los
protocolos existentes tuvieron problemas para interoperar con estas redes, por lo que se
diseñó un nuevo conjunto o pila de protocolos, y con ellos una arquitectura. Este nuevo
conjunto se denominó TCP/IP (Transmission Control Protocol/Internet Protocol) nombre que
provenía de los dos protocolos más importantes que componían la pila; la nueva
arquitectura se llamó sencillamente modelo TCP/IP, los nuevos protocolos fueron
especificados por vez primera por Cerf y Kahn en un artículo publicado en 1974. A la nueva
red, que se creó como consecuencia de la fusión de ARPAnet con las redes basadas en
otras tecnologías de transmisión, se la denominó Internet.
La aproximación adoptada por los diseñadores del TCP/IP fue mucho más pragmática que
la de los autores del modelo OSI. Mientras que en el caso de OSI se emplearon varios años
en definir con sumo cuidado una arquitectura de capas donde la función y servicios de cada
una estaban perfectamente definidas, y solo después se planteó desarrollar los protocolos

para cada una de ellas, en el caso de TCP/IP la operación fue a la inversa; primero se
especificaron los protocolos, y luego se definió el modelo como una simple descripción de
los protocolos ya existentes. Por este motivo el modelo TCP/IP es mucho más simple que el
OSI. También por este motivo el modelo OSI se utiliza a menudo para describir otras
arquitecturas, como por ejemplo la TCP/IP, mientras que el modelo TCP/IP nunca suele
emplearse para describir otras arquitecturas que no sean la suya propia.
En el modelo TCP/IP se pueden distinguir cuatro capas: La capa host-red; La capa Internet;
La capa de transporte y La capa de aplicación (Fig. 1.2)
Fig. 1.2 Modelo de referencia TCP/IP
• LA CAPA HOST- RED: Esta capa engloba realmente las funciones de la capa física
y la capa de enlace del modelo OSI. El modelo TCP/IP no dice gran cosa respecto a
ella, salvo que debe ser capaz de conectar el host a la red por medio de algún
protocolo que permita enviar paquetes IP. Podríamos decir que para el modelo
TCP/IP esta capa se comporta como una ‘caja negra’. Cuando surge una nueva
tecnología de red (por ejemplo ATM) una de las primeras cosas que aparece es un
estándar que especifica de que forma se pueden enviar sobre ella paquetes IP; A
partir de ahí la capa Internet ya puede utilizar esa tecnología de manera
transparente.

• LA CAPA INTERNET: Esta capa es el ‘corazón’ de la red. Su papel equivale al

desempeñado por la capa de red en el modelo OSI, es decir, se ocupa de encaminar
los paquetes de la forma más conveniente para que lleguen a su destino, y de evitar
que se produzcan situaciones de congestión en los nodos intermedios. Debido a los
requisitos de robustez impuestos en el diseño, la capa Internet da únicamente un
servicio de conmutación de paquetes no orientado a conexión. Los paquetes pueden
llegar desordenados a su destino, en cuyo caso es responsabilidad de las capas
superiores en el nodo receptor la reordenación para que sean presentados al usuario
de forma adecuada.
A diferencia de lo que ocurre en el modelo OSI, donde los protocolos para nada
intervienen en la descripción del modelo, la capa Internet define aquí un formato de
paquete y un protocolo, llamado IP (Internet Protocol), que se considera el protocolo
'oficial' de la arquitectura.
• LA CAPA DE TRANSPORTE: Esta capa recibe el mismo nombre y desarrolla la

misma función que la cuarta capa del modelo OSI, consistente en permitir la
comunicación extremo a extremo (host a host) en la red. Aquí se definen dos
protocolos: el TCP (Transmission Control Protocol) ofrece un servicio CONS fiable,
con lo que los paquetes (aquí llamados mensajes) llegan ordenados y sin errores.
TCP se ocupa también del control de flujo extremo a extremo, para evitar que por
ejemplo un host rápido sature a un receptor mas lento. Ejemplos de protocolos de
aplicación que utilizan TCP son el SMTP (Simple Mail Transfer Program, correo
electrónico) y el FTP (File Transfer Program).
El otro protocolo de transporte es UDP (User Datagram Protocol) que da un servicio
CLNS, no fiable. UDP no realiza control de errores ni de flujo. Una aplicación típica
donde se utiliza UDP es la transmisión de voz y vídeo en tiempo real; aquí el retardo
que introduciría el control de errores produciría mas daño que beneficio: es preferible
perder algún paquete que retransmitirlo fuera de tiempo. Otro ejemplo de aplicación
que utiliza UDP es el NFS (Network File System); aquí el control de errores y de flujo
se realiza en la capa de aplicación.
• LA CAPA DE APLICACIÓN: Esta capa desarrolla las funciones de las capas de

sesión, presentación y aplicación del modelo OSI. La experiencia ha demostrado que
las capas de sesión y presentación son de poca utilidad, debido a su escaso
contenido, por lo que la aproximación adoptada por el modelo TCP/IP parece mas
acertada.

La capa de aplicación contiene todos los protocolos de alto nivel que se utilizan para
ofrecer servicios a los usuarios. Entre estos podemos mencionar tanto los
‘tradicionales’, que existen desde que se creó el TCP/IP: terminal virtual (TelNet),
transferencia de ficheros (FTP), correo electrónico (SMTP) y servidor de nombres
(DNS), como los mas recientes, como el servicio de news (NNTP), el Web (HTTP), el
Gopher, etc.
2.1.3 Comparación de los modelos OSI y TCP/IP
Como ya hemos comentado, la génesis del modelo OSI y DNA fue muy diferente (véase Fig.
1.3). En el caso de OSI primero fue el modelo y después los protocolos, mientras que en DNA
el orden fue inverso. Como consecuencia el modelo OSI es más elegante y esta menos
condicionado por algún protocolo en particular, y se utiliza profusamente como modelo de
referencia para explicar todo tipo de redes. El modelo OSI hace una distinción clara entre
servicios, interfaces y protocolos, conceptos que a menudo se confunden en el modelo DNA.
Se puede decir que la arquitectura (o el modelo) OSI es mas modular y académico que el
DNA.
Pero este mayor nivel de abstracción también tiene sus inconvenientes. Los diseñadores del
modelo OSI no tenían experiencia práctica aplicando su modelo para desarrollar protocolos
y olvidaron algunas funcionalidades importantes. Por ejemplo, las redes broadcast no fueron
previstas inicialmente en la capa de enlace, por lo que se tuvo que insertar a la fuerza la
subcapa MAC para incluirlas. Otro problema era que no se había previsto la interconexión
de redes diferentes, cosa que fue como ya hemos visto el alma mater del modelo TCP/IP.
El modelo OSI tiene siete capas, mientras que el modelo DNA sólo tiene cuatro. Aunque es
desafortunada la fusión de la capa física y la de enlace en una oscura capa host-red, la
fusión de las capas de sesión, presentación y aplicación en una sola en el modelo DNA es
claramente mas lógica que la del modelo OSI.
Otra diferencia fundamental estriba en los servicios orientados a conexión (C-O) o no

orientados a conexión (C-L). El modelo OSI soporta ambos modos en la capa de red, pero
sólo el modo CONS en la capa de transporte, que es la que percibe el usuario. El modelo
TCP/IP en cambio soporta solo CLNS en la capa de red, pero ambos en la de transporte.
Quizá un sutil detalle pueda explicar esta diferencia: el servicio C-O en el ámbito de red hace
mucho más sencillo facturar por tiempo de conexión, cosa a la que están muy acostumbradas

las compañías telefónicas, que son las que han participado activamente en los comités
técnicos de ISO que diseñaron el modelo OSI.
Fig. 1.3 Modelos OSI y TCP/IP
En la práctica los protocolos basados en las normas estándar OSI definidas por la ISO
nunca llegaron a tener gran relevancia en el ámbito mundial, a pesar de que la mayoría de
los grandes fabricantes de computadores y compañías telefónicas impulsaron su utilización
ofreciendo productos y servicios basados en ellos. Las razones principales que motivaron
este fenómeno las podemos resumir en los siguientes puntos:
• Momento inadecuado: Para cuando estaban disponibles productos comerciales

basados en protocolos OSI (finales de los ochenta) ya estaban ampliamente
difundidos los productos basados en los protocolos TCP/IP; Esto era especialmente
cierto en entornos académicos (universidades y centros de investigación), que
aunque económicamente no eran los mejor dotados sí tenían las mayores redes a
nivel mundial.
• Tecnología inapropiada: como ya hemos comentado la elección del modelo de
siete capas para el protocolo OSI era algo forzada. Una de las razones que llevaron
a elegir este número de capas era que coincidía con el del modelo SNA de IBM, que
dominaba el mercado de la informática por aquel entonces; los autores del modelo
OSI creían que aproximándose a SNA tenían mayores posibilidades de éxito. La
complejidad de la arquitectura OSI (análogamente a la SNA) es considerable, y en
muchos aspectos difícil de traducir en programas.

• Implementaciones inadecuadas: en parte como consecuencia de su complejidad,

los productos comerciales que aparecían basados en los protocolos OSI eran muy
caros y poco fiables. Esto creó un círculo vicioso, ya que al ser caros los usuarios no
los compraban, y al no usarse en condiciones reales los nuevos productos no se
depuraban; además, las empresas fabricantes tenían que mantener un alto precio
del software OSI para compensar los elevados costos de desarrollo y mantenimiento.
Como contraste una de las primeras implementaciones de TCP/IP formaba parte del
UNIX de Berkeley, era muy buena y además se distribuía gratuitamente. No es
extraño pues que rápidamente se asociara OSI con baja calidad, complejidad y
costos elevados.
• Mala política: el desarrollo de OSI era patrocinado principalmente por la ISO, las
PTTs europeas, la Comunidad Europea y los gobiernos de sus países miembros; las
decisiones eran fruto de multitud de reuniones de los diversos comités y grupos de
trabajo, y en ocasiones se tomaban en consideración no sólo aspectos técnicos sino
también políticos, buscando el compromiso entre sus miembros. Por el contrario el
desarrollo de TCP/IP seguía un curso mucho más improvisado e informal, cualquier
persona podía (y puede) proponer un nuevo protocolo para su estandarización
independientemente de su nacionalidad, prestigio o situación laboral. Haciendo una
simplificación podríamos decir que OSI funcionaba como una 'democracia
parlamentaria' (similar a un gobierno moderno), mientras que TCP/IP era más similar
a una ONG, o a un movimiento alternativo; esto se reflejaba incluso en la
indumentaria utilizada por uno y otro colectivo. No es de extrañar que en entornos
académicos (de nuevo recordemos los más avanzados en redes globales) se viera
con mucha más simpatía el mecanismo de estandarización del TCP/IP que el de
OSI.
2.2 EL PROTOCOLO INTERNET (IP)
El Protocolo IP (Internet Protocol), es el protocolo del nivel red de TCP/IP. Los detalles que
presentaremos a continuación, corresponden a IPv4 (que es la versión actual del protocolo,
vigente en la mayoría de países) pero en algunos casos mencionaremos las características
relevantes de IPv6 que es la nueva versión. Los principios de ambos protocolos son
idénticos, y la nueva versión sólo incluye mejoras de performance y escalabilidad en la
implementación.
2.2.1 Introducción al protocolo IP

Los distintos protocolos pueden ser:
• No orientados a la Conexión.- cada paquete de datos es enviado a la red sin la

necesidad de que el destino avise la recepción de cada dato. Hay un envío rápido de
la información, pero sin seguridad.
• Orientados a la conexión.- cada vez que un paquete de datos es enviado a la red, el
receptor debe informar al transmisor de su llegada. Hay una conexión virtual entre el
transmisor y el receptor, pero genera un retardo inherente.
El protocolo IP es un protocolo de entrega sin conexión y no confiable:
• Sin conexión: Cada paquete es tratado de manera independiente de todos los

demás. No se mantiene información acerca de datos sucesivos.
• No confiable: ya que la entrega de los paquetes no se garantiza. Es por eso que el
modelo de servicio de Internet es conocido como “best - effort”, es decir, la red
intenta enviar los datos correctamente, pero no lo puede garantizar.
IP tiene dos principios básicos:
End-to-end Argument
La inteligencia y el manejo de las conexiones va en los extremos. Nunca hacemos algo en
los nodos intermedios, si podemos hacerlo en el origen y/o en el destino. De este modo,
todos los costos por saturación, estado por conexión, etc, los manejan los nodos interesados
en la conexión y no el resto. Esto permite no mantener el estado de las conexiones en la red
misma, sino sólo en el origen y el destino.
IP por sobre todas las cosas

La idea es definir un protocolo independiente de la red física, que logre pasar a través de
todos los medios y no dependa de ninguno en particular.
IP se basa en el concepto de una inter-red, que es una red de redes (INTERNET). Es decir,
no conecto un computador con otro, sino una red con otras. Esto me permite factorizar una
buena cantidad de información, puesto que solo debo identificar la red destino para enrutar.
2.2.2 Funciones del protocolo IP
IP especifica:

- Cómo almacenar y reenviar datagramas.

- El plan de numeración.
- Segmentación y reensamblado: no todas las subredes tienen la misma longitud
máxima de paquetes. IP segmenta y reensambla. Esto provoca que IP necesite una
mínima información acerca de la subred sobre la que está implementado.
- No hay corrección de errores ni control de congestión.
2.2.3 Formato de la unidad de protocolo IP
El formato de la unidad de protocolo IP es conocido como DATAGRAMA.
Los datos se empaquetan en un datagrama, que es la unidad utilizada para atravesar las
redes en camino. La idea básica de un datagrama es equivalente a una carta envuelta en un
sobre. Los datos del sobre van en la cabecera del paquete y el contenido va como datos. Al
igual que en la carta, la idea es que al irse ruteando por la red el datagrama queda intacto,
sin modificarse ni la cabecera ni el contenido.
Fig. 1.4 Formato del Datagrama IP
A continuación hay una descripción de cada uno de los campos que forman la cabecera:
• Versión (4 bits): Indica el número de versión del protocolo al que pertenece el

datagrama, lo que permitirá la evolución futura del protocolo y que la transición entre

las versiones se pueda hacer ejecutándose en unas máquinas la versión vieja y en

otras la versión nueva.
• IHL (Internet Header length) (4 bits): Indica la longitud de la cabecera en palabras
de 32 bits (4 bytes). El valor mínimo es cinco (20/4=5). Este campo es necesario por
no ser constante el tamaño de la cabecera como hemos comentado anteriormente.
El valor máximo puede ser 15 (1111) lo que limita la cabecera a 60 bytes (15*4) y en
consecuencia el campo de opciones a 40 (60-20). En el caso de que, por ejemplo, se
quiera registrar la ruta de un paquete este valor puede ser insuficiente y ser
totalmente inútil esta opción.
• Tipo de servicio (8 bits): Permite que el host especifique que clase de servicio
quiere, pudiéndose combinar confiabilidad y velocidad. Para la voz digitalizada es
mas importante realizar la entrega de forma rápida que precisa, mientras que para la
transferencia de ficheros no importa a que velocidad se realiza la transferencia pero
si que esté libre de errores. De los 8 bits, 3 son para el campo de precedencia que
en realidad es una prioridad de 0 (normal) a 7 (para los paquetes de control de red).
A continuación aparecen los bits de seguridad (alta o baja), retardo (alto o bajo
cuando se intenta minimizar el retardo) y rendimiento (normal o alto cuando se
intenta maximizar el rendimiento durante la transmisión del datagrama).
Es importante tener en cuenta que estos valores no son considerados por los
dispositivos de encaminamiento actuales.
Fig. 1.5 Campo tipo de servicio.
El subcampo de precedencia tiene nombres bastante sugestivos aunque no hay una

definición precisa de para que deben ser usados. Los únicos que están definidos son
el “network control” que sólo es usado dentro de la subred cuando, por ejemplo, se

necesita enviar información de control a un ordenador de la misma subred y el

“internetwork control” que es usado para enviar mensajes relacionados con el
encaminamiento a elementos de otra subred.
Lo que si se pretende es que el principal efecto del subcampo de precedencia sea su
relación con la disciplina de gestión de las colas del dispositivo de encaminamiento.
En este sentido puede priorizar aquellos datagramas que tengan una prioridad mayor
e incluso puede aplicar un control de congestión descartando datagramas de menor
prioridad que estén en el buffer si al llegar un datagrama de mayor prioridad el buffer
está lleno.
El subcampo tipo de servicio es determinado por el sistema origen para indicar el tipo
de calidad servicio que quiere obtener, si es posible, para este datagrama. En
realidad los dispositivos de encaminamiento ignoran este subcampo. Sin embargo, si
un dispositivo de encaminamiento implementa esta capacidad, puede responder al
valor del tipo de servicio de tres maneras:
- Selección de la ruta. La decisión se tomará teniendo en cuenta el tipo de
servicio.
- Servicio de la subred. Se pide en el próximo salto un tipo de servicio que
sea lo mas parecido posible al requerido. Esto se puede hacer en aquellas
redes (por ejemplo ATM) que soporte unas ciertas clases de servicio.
- Disciplina de gestión de colas. Un dispositivo de encaminamiento puede
considerar al campo precedencia y tipo de servicio para determinar como
son gestionadas las colas. Por ejemplo puede dar un tratamiento
preferencial a los datagramas que piden una minimización del retardo.
La tabla 1 muestra los valores del campo tipo de servicio recomendados por defecto.

Tabla 1 Tipos de servicio recomendado por defecto
• Longitud total (16 bits) en bytes que tendrá todo el datagrama, considerando tanto
la cabecera como los datos. Hay que tener en cuenta que el tamaño máximo de un
datagrama es de 65535 bytes lo que puede ser insuficiente en las redes de alta
velocidad.
• Identificador (16 bits): es un número de secuencia que junto a la dirección origen,
la dirección destino y el protocolo de usuario, sirven para que la máquina destino
determine a que datagrama pertenece el fragmento que ha recibido. Todos los
fragmentos de un datagrama contienen el mismo valor en el campo identificador y
este número debe ser único para la dirección origen, la dirección destino y el
protocolo de usuario durante el tiempo en el que el datagrama permanece en el
conjunto de redes.
• Indicadores (3 bits): El primer bit no se utiliza actualmente. El indicador de mas
fragmentos (MF) cuando vale 1 indica que este datagrama tiene mas fragmentos y
toma el valor 0 en el último fragmento. El indicador de no fragmentar (DF) prohibe la
fragmentación cuando vale 1. Es una orden que se le da a los encaminadores de que
no fragmenten el datagrama cuando el destino es incapaz de reensamblarlo. Si este
bit vale 1, el datagrama se descartará si se excede el tamaño máximo en una subred
de la ruta. Por lo tanto, cuando este bit vale 1, es aconsejable usar encaminamiento
por la fuente para evitar subredes cuyo tamaño máximo de paquete sea menor que
el tamaño del datagrama.
• Desplazamiento del fragmento (13 bits): Indica en que posición del datagrama
original, medido en unidades de 8 bytes (64 bits), va el fragmento actual. Debido a

esto, todos los fragmentos excepto el último contienen un campo de datos con una
longitud múltiplo de 8 bytes. Como se proporcionan 13 bits, puede haber un máximo
de 8912 (2**13) fragmentos por datagrama, y por lo tanto el tamaño máximo de un
datagrama es de 65536 bytes, uno mas que el campo de longitud total.
• Tiempo de vida (8 bits): Es un contador que sirve para limitar la vida de un paquete.
Aunque lo lógico sería pensar que cuenta el tiempo en segundos, en realidad lo que
cuenta es el número de saltos de dispositivo de encaminamiento que realiza. Cuando
el contador llega a cero, el paquete se descarta y se envía de una paquete al
computador origen avisándole. Con este mecanismo se consigue que los
datagramas no permanezcan indefinidamente en la red si, por ejemplo, se dañan las
tablas de encaminamiento.
• Protocolo (8 bits): Se utiliza por la capa de red para saber a que protocolo de la
capa de transporte le tiene que enviar el datagrama una vez lo ha reensamblado.
Existen diferentes protocolos de transporte, entre ellos TCP y UDP. En el RFC 1700
se definen todos estos protocolos.
• Suma de comprobación (16 bits): Sirve para verificar el contenido de la cabecera y
es útil para la detección de errores generados durante la transmisión del datagrama.
Como algunos de los campos de la cabecera pueden cambiar en alguno de los
dispositivios de encaminamiento (por ejemplo, el tiempo de vida y algunos campos
relacionados con la segmentación), este valor es verificado y recalculado en cada
uno de los dispositivos de encaminamiento. El algoritmo empleado consiste en
sumar todas las medias palabras de 16 bits a medida que van llegando, usando la
aritmética de complemento a 1, y luego obtener el complemento a 1 del resultado. Se
supone que la suma de comprobación de la cabecera es cero cuando llega. Este
algoritmo es algo mas robusto que una suma normal. Existen algunas técnicas para
acelerar el cálculo.
• Dirección origen (32 bits): Indica el número de red y el número del ordenador que
envía el datagrama.
• Dirección destino (32 bits): Indica el número de red y el número del ordenador al
que se envía el datagrama.
• Opciones (variable): Contiene las opciones solicitadas por el usuario que envía los
datos y se diseñó para que las versiones posteriores del protocolo pudieran incluir
información no considerada originalmente, para que los investigadores pudieran
probar cosas nuevas y para que aquellas aquella información que es utilizada pocas
veces no tuviera asignada unos bits determinados en la cabecera. Cada una de las
opciones empieza en 1 byte que identifica la opción. Algunas de las opciones vienes
seguidas de un campo de 1 byte para indicar la longitud de la opción y a

continuación uno o mas bytes de datos. Hay seis opciones (Seguridad,

Encaminamiento estricto desde el origen, Encaminamiento libre desde el
origen,Registrar la ruta, Identificación de secuencia, Marca de tiempo definidas
actualmente pero no todas son reconocidas por todos los dispositivos de
encaminamiento:
- Seguridad: Permite añadir una etiqueta para indicar lo secreta que es
la información que contiene el datagrama. Por ejemplo, se podría
utilizar para que los dispositivos de encaminamiento no consideren
redes en concreto. Pero en realidad esta etiqueta es ignorada y
realmente para lo único que sirve es para ayudar a los espías a
encontrar con mayor facilidad la información importante !!!
- Encaminamiento estricto desde el origen: Es una secuencia de
direcciones IP que sirve para indicar la trayectoria completa que debe
seguir el datagrama desde el origen hasta el destino. Esta opción es
usada sobre todo cuando los administradores de sistemas envían
paquetes de emergencia porque las tablas de encaminamiento se han
corrompido o para hacer mediciones de tiempo.
- Encaminamiento libre desde el origen: Esuna secuencia de
direcciones IP que sirve para indicar que el datagrama debe pasar
obligatoriamente por esos dispositivos de encaminamiento y en ese
orden, pero también puede pasar por otros dispositivos de
encaminamiento. Esta opción es útil cuando por diversas
consideraciones se deben pasar por algunos dispositivos de
encaminamiento en concreto.
- Registrar la ruta: Sirve para indicar que los dispositivos de
encaminamiento agreguen su dirección IP al campo de opción y de
esta manera tener conocimiento de la ruta seguida por el datagrama.
Se utiliza, por ejemplo, para poder determinar si los algoritmos de
encaminamiento están funcionando correctamente. Los 40 bytes de
tamaño máximo que puede tener el campo de opciones sólo permite
registrar 9 saltos, lo que puede ser en las redes actuales en muchos
casos insuficiente.
- Identificación de secuencia. Se utiliza cuando hay recursos
reservados para un servicio, por ejemplo voz.
- Marca de tiempo: En este caso, además de registrar las direcciones
de los dispositivos de encaminamiento como se hacia en la opción
registrar la ruta, se utilizan 32 bits para guardar una marca de tiempo

expresada en milisegundos. Esta marca es usada principalmente para

buscar fallos en los algoritmos de encaminamiento.
• Relleno (variable): El campo de opciones se rellena para que su tamaño sea
múltiplo de 32 bits (4 bytes)
2.2.4 Fragmentación
En primer lugar, De qué tamaño es un datagrama?. El tamaño para un Datagrama debe ser
tal que permita la encapsulación, esto es, enviar un datagrama completo en una trama
física. El problema está en que el datagrama debe transitar por diferentes redes físicas, con
diferentes tecnologías y diferentes capacidades de transferencia (capacidad máxima de
transferencia de datos de una red física MTU. Para redes ethernet es 1500 bytes por trama).
Cuando un datagrama pasa de una red a otra con un MTU menor a su tamaño es necesario
la fragmentación. A las diferentes partes de un datagrama se les llama fragmento. Al
proceso de reconstrucción del datagrama a partir de sus fragmentos se le llama
Reensamblado de fragmentos.
Al fragmentar divido el datagrama en varios datagramas con (casi) la misma cabecera y los
trozos de los datos en cada uno. El largo de cada datagrama es el que corresponde a cada
fragmento. Cada uno de estos fragmentos será ruteado luego como un datagrama
independiente.
El problema es que si el nivel de transporte envía un datagrama, el receptor debe recibir

también uno (y no varios más pequeños). Para esto, el receptor final ``pega" los fragmentos
para reconstruir el datagrama original (reensamblado).
En esto se usan los otros campos de la cabecera. (ver Figura 1.6)

Fig. 1.6 Proceso de fragmentación
1. Se necesita de un campo de identificación para saber a que datagrama pertenece el

fragmento.
2. Se toma a uno de los fragmentos como referencia. En la figura, sea el fragmento 1de
tamaño 600, entonces el fragmento 2 tendrá un desplazamiento (offset) de 600 y el
fragmento 3 un offset de 1200 con respecto al fragmento de referencia.
3. También es necesario un campo que nos permita saber si el fragmento que llega es
el último (Flag) y otro que indique que no se fragmente.
Ejercicio
Se desea transmitir un mensaje de 1000 bytes, la red tiene un tamaño de datos máximo de
256 Bytes. En cada datagrama IP su header es de 20 bytes. Determinar el numero de
datagramas (fragmentos) requeridos. Además determinar los contenidos de los siguientes
campos en la cabecera del datagrama:
Identificación - Longitud total - Offset de Fragmento - Flag de mas fragmentos
Solución:
Se tiene:
a) El numero máximo de datos por datagrama = 256 –20= 236 bytes

Si usa un numero exacto de bytes tenemos = 29x8= 232 bytes

Se requerirán entonces: 5 datagramas : 4 de 232 bytes y 1 de 72 bytes
b) En la cabecera se tiene:
Identificación 20 20 20 20 20
Total 232+20 232+20 232+20 232+20 232+20
Offset segmento 0 29 58 87 116
Flag de mas segmentos 1 1 1 1 1
2.2.5 Clases de direcciones IP
Para el nivel red, se define un espacio de direcciones de 32 bits, que serán usados en forma
única para identificar cada computador conectado a Internet. En enero de 2003 había más
de 170 millones de computadoras conectadas a Internet en más de 200 mil países alrededor
del mundo.
Eso no incluye todos los sistemas que están detrás de las paredes, es decir, había muchos
mas sistemas conectados a la Internet que no eran directamente accesibles a través de la
Internet.
China acaba de sobrepasar los 800 millones de usuarios, lo que la hace la población más
fuerte de personas conectadas a la Internet en todo el mundo. Le sigue los Estados Unidos
con 165 millones y Japón con 100 millones. El 57 por ciento de los norteamericanos están
conectados a la red mundial y esto no es una cosa pequeña. Este es uno de los principales
motivos de la aparición de IPv6, protocolo que permitirá salvar este gran inconveniente.
Los 32 bits definidos como dirección IP, teóricamente permitirían la utilización de 4.000
millones de direcciones diferentes (2^32) . Sin embargo, como veremos más adelante, se
pierden muchas por la forma de asignar esas direcciones.
Los 32 bits se dividen en 2 campos:
• Campo de red: nombra la red a la que está conectado el sistema (bits superiores).

• Campo de host: identifica el equipo dentro de la subred (bits inferiores).
Fig. 1.7 Formato de la dirección IP
Dirección IP = <número de red (net ID)><número de host (host ID)>
La notación de las direcciones IP es en base a cuatro decimales separados por un punto

(cada decimal codifica un byte: 0 - 255). Por ejemplo: 146 . 83 . 4 . 11
Existen cinco tipos básicos de direcciones en función de la longitud de los campos:
CLASE A
El primer bit, el más significativo, va a cero indicando dirección de tipo A. Esta clase de
direcciones permite tener muchos sistemas conectados en una única subred siendo idónea
para grandes redes con muchos equipos. No interesa, sin embargo, para pequeñas redes
locales con pocos equipos, pues se desperdiciarían multitud de direcciones.
La clase A comprende redes desde 1.0.0.0 hasta 126.0.0.0. El número de red está
contenido en el primer octeto. Esta clase ofrece 126 redes y un campo para el host de 24
bits, permitiendo aproximadamente 1,6 millones host por red .
CLASE B
El primer bit ha de ir a ´1´ y el segundo a ´0´.
La clase B comprende las redes desde 128.0.0.0 hasta 191.255.0.0; el número de red está
en los dos primeros octetos. Esta clase permite 16.320 redes con 65.024 hosts cada una.
CLASE C
Los tres bits más significativos deben ser ´110´ para indicar el tipo de clase.
Las redes de clase C van desde 192.0.0.0 hasta 223.255.255.0, con el número de red
contenido en los tres primeros octetos. Esta clase permite cerca de 2 millones de redes con
más de 254 hosts.
CLASE D (224.0.0.0 - 240.0.0.0)

Esta clase está pensada para direcciones de multicast o multidestino. Con una dirección de
este tipo se envía un mismo datagrama a un grupo de equipos previamente definidos. De
esta forma, nos ahorramos tener que generar un datagrama para cada destinatario con cada
dirección unicast o individual si el contenido del datagrama es el mismo para todos. No
debemos confundir, sin embargo, multicast con broadcast. Con broadcast un datagrama se
enviaría a todos los usuarios y no a un grupo de ellos.
Las direcciones multicast han de comenzar con los bits ´1110´.
CLASE E (241.0.0.0 - 248.0.0.0 )

La clase E está reservada para posibles usos futuros.
Inicialmente, las direcciones se separaron en clases A, B y C según sus bits. La idea era
que la separación entre bits de red y bits de host es en un byte distinto para cada clase.
En la siguiente figura se muestra las clase de IP:
Fig. 1.8 Clases de direcciones IP.
También hay algunas direcciones IP que están reservadas para propósitos especiales y por
tanto ningún nodo puede tener esa dirección:
Dirección 0.- Está reservada para dispositivos que no conocen su dirección. En ciertas
circunstancias es posible para un dispositivo no conocer el número de la red en la que se

encuentra, o incluso su número de dispositivo dentro de la red. Por ejemplo, 0.0.0.23 puede
ser un dispositivo que sabe que su numero de orden es el 23, pero desconoce la dirección
de su red.
Dirección 0.0.0.0.- se denomina encaminamiento por defecto, y tiene que ver con la ruta
por la que el IP encamina los datagramas.
Dirección de la propia red.- La dirección de red con todo ceros en la parte del campo de
host especifica sólo el número de la red. Por ejemplo 128.30.0.0 representa la red de clase
B 123.30.
Dirección de broadcast.- Son las direcciones IP en las cuales el campo del host son todos
unos, (ej. 128.30.255.255). Son utilizadas para interrogar a todos los dispositivos situados
en una subred, ya que el destino de un paquete con una dirección de broadcast son todos
los nodos de la red. Por ejemplo, para enviar un mensaje a todos los dispositivos
conectados a
la red 128.3 se enviaría un mensaje con la dirección 128.3.255.255. Por convenio el

estándar también permite el empleo de 255.255.255.255 para referirse a todos los host
conectados a la red local.
Direcciones de loopback.- Son la 127.0.0.0 y 127.0.0.1. Estas direcciones son utilizadas

por las aplicaciones y procesos de los nodos para pruebas, diagnósticos de la tarjeta, etc.
Este conjunto de restricciones deben tenerse siempre en cuenta a la hora de asignar las
direcciones a los equipos conectados a una red para obtener un correcto funcionamiento de
las aplicaciones.
Algunos rangos de direcciones de cada una de las clases de red han sido reservados y
designados como rangos de direcciones “reservadas” o “privadas”. Estas direcciones están
reservadas para el uso de redes privadas y no son encaminadas en Internet. Son usadas
normalmente por organizaciones con su propia intranet, pero incluso las redes pequeñas
suelen encontrarlas útiles. Las direcciones de red reservadas se muestran en la tabla 2:

Clase Redes
A 10.0.0.0 hasta 10.255.255.255
B 172.16.0.0 hasta 172.31.0.0
C 192.168.0.0 hasta 192.168.255.0
Tabla 2. Direcciones de red reservadas
2.3 SUBNETTING
Existieron muchas razones que llevaron a dividir las grandes redes en subredes o subnets
entre las cuales podemos mencionar:
• El principio de asignación de direcciones IP es demasiado inflexible: Clase A, B y C.

y no facilita realizar cambios en la configuración de una red.
• El crecimiento de hosts obliga a dividir una red en varias sub-redes, sin la necesidad
de disponer de nuevas direcciones IP.
• El subnetting reduce el tamaño de las tablas de ruteo.
2.3.1 ¿Cuál es la idea de SUBNETTING?
El número de host es dividido en dos partes:
• Un segundo número de red o subred y

• Un número de host.
Es decir, Se agrega un nivel jerárquico en la dirección, sólo interpretado localmente.
Fig. 1.9 Subnetting

Ejemplo: Dirección de clase A
Fig. 1.10 Subnetting en una dirección de clase A
En nuestro ejemplo, “n” bits serán seleccionados para definir el número de subredes que se
necesitan. Para hacer el cálculo de las mismas, es necesario excluir las direcciones IP
reservadas, es decir, las compuestas por unos y ceros, ya que estas direcciones no pueden
ser contabilizadas como direcciones de redes independientes.
Una vez definida la cantidad de subredes que necesitamos, podemos despejar el valor de
“n”.
En el ejemplo, se trabaja con una dirección clase A, pero el subnetting es aplicable a todo
tipo de redes, tanto clase B como C.
2.3.2 Concepto de Máscara de Subnet
Para identificar en la dirección local el número de subnet y el número de host se usa una
máscara de subnet.
La máscara de subset está representada por un número de 32 bits, expresado en notación

decimal con puntos, como una dirección IP. Los bits en “1” de la máscara indican que los
correspondientes bits de una dirección IP conforman la dirección de red, los bits en “0”
indican host.

El router tendrá en cuenta la máscara de subred para tomar las desiciones de ruteo.
Dada una dirección IP representada por (D_IP), entonces la dirección de red será
reprensada como:
Dir. de red = (D_IP) AND MASCARA
Fig. 1.11 Mascara de subred de una dirección de clase A
Ejemplo simple de Máscara

Fig. 1.12 Calculo de la mascara de subred
Como vemos en el ejemplo, para determinar la dirección de subred, es necesario identificar

los bits de la dirección IP asociados a la subred, esto a través de la máscara; una vez que
sabemos cuantos y cuales son, completamos los bits que representan a los hosts con ceros
y esta será la dirección de subred.
Muchas veces la máscara es representada por la cantidad de “1”s que contenga; asi en el
ejemplo:
IP: 200.60.172.142 Mask: 255.255.255.224 es equivalente a:

200.60.172.142 / 27
2.3.3 Tipos de subnetting
Subnetting estático
• Todas la sub-redes obtienen desde la red una misma máscara de subnet.
• Simple de implementar y fácil de mantener.
• Mal uso de las direcciones en pequeñas subredes.
Subnetting de longitud variable (VLS)

• Sub-red con diferentes cantidad de hosts requieren diferentes máscaras de subred.

• Cada sub-red puede usar diferentes máscaras de subnet.

• Una sub-red puede ser dividida en varias subredes.
2.3.4 Ejemplos de subnetting
En el esquema que se explica a continuación se tiene:
En un esquema como el presentado, la mayoría del tráfico se generará en la red local.

Para direccionar pediremos una clase B (138.4.0.0) que da para 64K direcciones, pues una
clase C sólo me da para 255 máquinas que no son muchas.
Si asigno ese prefijo a un segmento, ¿cómo asigno los otros?
Convendría además que el resto de internet viese mi red con el mismo prefijo (pues podría
asignar múltiples direcciones C, una por segmento, pero además de derrochar direcciones,
desde fuera se vería nuestra red casi como una tela de araña...)
Solución:
La solución es precisamente el subnetting, gracias al cual puedo compartir un prefijo de red

entre distintas subredes

Ahora, como vemos en la figura inferior, nos dan 16 bits fijos, pero en los otros 16, la frotera
entre lo que es subred y sistema la fijamos nosotros (p. ej. si divido en 8 bits y 8 bits puedo
tener 256 segmentos y 256 sistemas por segmento)
Así puedo asignar un número de subred a cada subred y uno de sistema a cada sistema y el
resto de internet me sigue viendo como 138.4.
Ejemplo de tabla:
Máscaras:
Me dice cuánto de la dirección que aparece en la tabla es significativo para encaminar (1:
significativo 0: no). 255.255.255.0 => si los tres primeros bytes coinciden con los de mi
dirección, uso esta entrada para encaminar ( 138.4.2.1 se encamina con la 1ª entrada).
La máscara que se usa en la escuela es la siguiente:

Ejemplo:
Con la máscara anterior y una dirección genérica IP 138.4.0.0, vamos analizar las distintas
direcciones de subredes y sistemas que obtendremos
La primera subred será la que tenga por dirección base la misma 138.4.0.0.
En ella los sistemas tendrán direcciones desde 138.4.0.1 a 138.4.0.62, siendo la 138.4.0.63
la dirección de broadcast.
La segunda subred tendrá por dirección 138.4.0.64.
En ella los sitemas irán desde 138.4.0.65 hasta 138.4.0.126 y usaremos 138.4.0.127 para
broadcast.
Y así sucesivamente hasta acabar la asignación
NOTAS
El resto de la red no tiene por qué enterarse de que yo utilizo subnetting
Actualmente se tiende al Supernetting o CIRD (Classless Interdomain Routing), que sería la
interpolación del concepto al resto de Internet.

2.4 PROTOCOLOS QUE TRABAJAN SOBRE IP
2.4.1 ICMP (Internet Control Message Protocol – Protocolo de Mensajes de Control

de Internet):
Permite el intercambio de mensajes de control y de supervisión entre dos PCs. Toda

anomalía detectada por el protocolo IP provoca el intercambio de mensajes ICMP entre los
nodos de la red. Este protocolo forma parte de la capa Internet y usa la facilidad de enviar
paquetes IP para enviar mensajes.
ICMP es un protocolo de control que utilizan los dispositivos de encaminamiento para

notificar las diferentes incidencias que pueden haber en una red IP. Proporciona información
de realimentación sobre los problemas que ocurren y por ejemplo se utiliza cuando: un
datagrama no puede alcanzar el destino; el encaminador no tiene la capacidad suficiente
para almacenar temporalmente el datagrama y enviarlo y, el caminador indica a una PC que
envíe el tráfico por una ruta más corta.
2.4.1.1 Los mensajes ICMP

Estos mensajes se envian encapsulados en datagramas IP. El protocolo IP considera como
datos los mensajes ICMP. Como hemos visto anteriormente los datagramas IP se
componen de una cabecera IP y del campo de Datos, que en este caso consta de una
cabecera ICMP y de un campo datos como muestra la figura:
Fig. 1.13 Encapsulación del mensaje ICMP
La estructura del mensaje ICMP se muestra a continuación:

Fig. 1.14 Formato del mensaje ICMP.
- Type: Especifica el tipo de mensaje.

- Code: Contiene el codigo del error que afecta al datagrama al que se refiere el
mensaje IP.
- Checksum: Consta de 16 bits que son el resultado de realizar el complemento a uno
del resultado obtenido al realizar la suma de complementos a uno del mensaje ICMP
comenzando desde el campo “Type”.
- Datos ICMP: Normalmente el campo datos contiene una parte del mensaje IP
original (mensaje causante de generar el mensaje ICMP).
2.4.1.2 Tipos de mensaje ICMP

Existen los siguientes tipos:
- Mensajes de Destino inalcanzable (ICMP-3): indica que el nodo destino es

inalcanzable.
- Mensajes de control de congestión (ICMP-4): indica al nodo fuente que existen
problemas de congestión en el nodo destino, para que reduzca su velocidad de
emisión de datagramas.
- Mensaje de Redireccionamiento (ICMP-5): utilizado por los routers para indicar una
ruta alterna.
- Mensaje de Tiempo excedido (ICMP – 11): indica la expiración del valor del tiempo
de vida de un datagrama.
Estos cuatro tipos de mensaje se denominan Mensajes de error. Existen determinadas

circunstancias en las cuales no deben generarse esta clase de mensajes:
o Para responder a otro mensaje de error ICMP.
o Para responder a un datagrama IP cuya dirección de destino es una dirección
IP de difusión.
- Problema de parámetros (ICMP-12): indica un problema en el datagrama IP.

- Respuesta de eco (ICMP-8): utilizado como un diagnóstico para determinar la

accesabilidad de un nodo IP.
2.4.2 El protocolo OSPF (Open Shortest Path First – abrir primero la trayectoria mas
corta):
Este protocolo está definido en el RFC 1583 y se usa muy frecuentemente como protocolo
de encaminamiento interior en redes TCP/IP. La función del OSPF es encontrar la
trayectoria mas corta de un dispositivo de encaminamiento a todos los demás. Cada
dispositivo de encaminamiento tiene almacenada en una base de datos la topología de la
red de la que forma parte.
2.4.3 BGP (protocolo de pasarela frontera - Border Gateway Protocol)
El protocolo de pasarela frontera (BGP – “border gateway protocol”) se encarga de mover

paquetes de una red a otra pero en algunos casos debe preocuparse de otras cuestiones
que no tienen porque estar relacionadas con el objetivo de mover los paquetes de la forma
más eficiente posible.
Los diferentes dispositivos de encaminamiento BGP se comunican entre sí estableciendo

conexiones TCP. El protocolo BGP es fundamentalmente un protocolo de vector distancia
en el que cada dispositivo de encaminamiento mantiene el coste a cada destino y la
trayectoria seguida. Estos valores son dados periódicamente a cada uno de los vecinos
enviando mensajes. La esencia de BGP es el intercambio de información de
encaminamiento entre dispositivos de encaminamiento. La información de encaminamiento
actualizada se va propagando a través de un conjunto de redes.
2.4.4 IGMP (Internet Group Management Protocol)
Es usado, por ejemplo, para informar a los dispositivos de encaminamiento que un miembro
del grupo multicast está en la red conectada al nodo. Está información de los miembros del
grupo multicast también es transmitida al emisor del multicast utilizando este protocolo.
2.5 CAPA DE ACCESO A LA RED
La capa de Acceso a la Red es la capa que se encarga de todos los detalles que necesita
un paquete IP para realizar un enlace físico. Emite al medio físico los flujos de bit y recibe

los que de él provienen. Consiste en los manejadores de los dispositivos que se conectan al
medio de transmisión.
Las funciones incluidas en este nivel incluye el encapsulamiento de los datagramas IP en

tramas que son transmitidas a la red. También traza las direcciones IP a las direcciones
físicas usadas por la red. Una de sus características es identificar cada computador en la
red. La dirección IP debe ser convertida en una dirección apropiada para la red física sobre
la cual el datagrama es transmitido.
La información que será transmitida es recibida de la capa de Internet. La información de la

capa de acceso a la red se agrega en la forma de una cabecera la cual es añadida en el
principio de los datos.
Esta capa se encuentra fuertemente ligada a los protocolos ARP y RARP
2.5.1 Protocolo ARP (ADDRESS RESOLUTION PROTOCOL)
El protocolo de Resolución de Direcciones ARP (Address Resolutión Protocol) es un

protocolo que se utiliza para convertir las direcciones IP en direcciones de la red física (por
ejemplo direcciones MAC). Las especificaciones de ARP están descritas en la RFC 826.
Los protocolos TCP/IP direccional los distintos host de la Internet mediante direcciones IP
pero al intentar enviar un datagrama a su destino (por ejemplo: 128.3.4.7), es necesario
encontrara la dirección de la red física. Por ello, en cada host existe un módulo ARP cuya
misión es convertir las direcciones IP en direcciones físicas que puedan entender los
manejadores. Para poder realizar esta conversión, este módulo utiliza una tabla,
denominada tabla de direcciones ARP, que la mayoría de los computadores trata como si
fuera una memoria intermedia (“cache”), de forma que la información que lleva mucho
tiempo sin utilizarse se borra.
Cuando se envía un datagrama IP a un host destino, el módulo ARP busca en la Tabla de

Direcciones la correspondencia entre la dirección IP y la dirección física. Si existe la entrada
en la tabla se procede a la transmisión.
Si, por el contrario, la dirección IP del host destino no se encuentra en la tabla de

direcciones, se genera una petición ARP que se difunde a través de toda la red. El paquete

que engloba esta petición se compone, entre otros, de los campos que muestra la figura
1.15.
Fig. 1.15 Petición ARP
Si alguna de las maquinas de la red reconoce su propia dirección IP en el paquete de

petición, envia un mensaje de respuesta al host origen. A su vez, la respuesta se compone
de los campos que muestra la figura 1.16.
Fig. 1.16 Respuesta ARP
La dirección física del host destino se introduce a continuación en la tabla de direcciones del
host origen.

Fig. 1.15 ARP local
2.5.2 Protocolo RARP (REVERSE ADDRESS RESOLUTION PROTOCOL)
Cuando existen máquinas sin disco duro tenemos el problema de no tener memoria para
almacenar una dirección IP para la máquina en cuestión, para ello se desarrollo el protocolo
RARP que es similar al protocolo ARP con la diferencia de que este se encarga de pedir la
dirección IP al servidor RARP de la red y almacenarla en la memoria ROM del dispositivo.
Para ello la máquina emite un mensaje por difusión el cual es recibido por el servidor o
servidores RARP y manda de regreso la IP que pertenece a este equipo (Fig. 1.16)

Fig. 1.16 Reverse RARP

ENLACES DE INTERES
• El protocolo Internet
Español:
http://burete.forodigital.es/angel/programacion/Redes/Protocolos/Tcp_Ip.html
Inglés:
http://gsyc.escet.urjc.es/docencia/asignaturas/itig-
transmision_datos/transpas/node8.html
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ip.htm
http://www.rfc-editor.org/rfcxx00.html
• ICMP:
Español:
http://es.tldp.org/Manuales-LuCAS/GARL2/garl2/x-087-2-issues.icmp.html

Modulo 2 - Familia de Protocolos TCP-IP

Cargado por

Copyright:

Formatos disponibles

Modulo 2 - Familia de Protocolos TCP-IP

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modulo 2 - Familia de Protocolos TCP-IP

Cargado por

Copyright:

Formatos disponibles

POSTGRADO A DISTANCIA :

FAMILIA DE PROTOCOLOS TCP / IP

Entre los objetivos mas importantes del presente capitulo tenemos:

2.1 Modelos de referencia

DIVISIÓN DE TELEDUCACIÓN 1 REDES DE COMUNICACIÓN DE DATOS

2.5 Capa de acceso a la red

En 1982 se especificó un nuevo conjuntos de protocolos para ARPANET que fue

DIVISIÓN DE TELEDUCACIÓN 2 REDES DE COMUNICACIÓN DE DATOS

DESARROLLO DEL MÓDULO

2.1 MODELOS DE REFERENCIA

2.1.1 El modelo de referencia OSI

Seguramente la aportación más importante de la iniciativa OSI ha sido precisamente su

DIVISIÓN DE TELEDUCACIÓN 3 REDES DE COMUNICACIÓN DE DATOS

Fig. 1.1 Modelo de Referencia OSI

El término interconexión de sistemas abiertos (OSI – Open System Interconnection) califica

DIVISIÓN DE TELEDUCACIÓN 4 REDES DE COMUNICACIÓN DE DATOS

2.1.1.1 Principios de estructuras de capas

- No crear más capas de las que sean estrictamente necesarias.

DIVISIÓN DE TELEDUCACIÓN 5 REDES DE COMUNICACIÓN DE DATOS

El atractivo del enfoque del modelo OSI es su promesa de resolver el problema de

- Que ellos implementen el mismo conjunto de funciones de comunicaciones.

2.1.1.2 Descripción de las capas de OSI

DIVISIÓN DE TELEDUCACIÓN 6 REDES DE COMUNICACIÓN DE DATOS

• LA CAPA DE ENLACE (DATA LINK): La principal función de la capa de enlace es

• LA CAPA DE RED: La capa de red se ocupa del control de la subred. Esta es la

DIVISIÓN DE TELEDUCACIÓN 7 REDES DE COMUNICACIÓN DE DATOS

• LA CAPA DE TRANPORTE: La capa de transporte es la primera que se ocupa de

DIVISIÓN DE TELEDUCACIÓN 8 REDES DE COMUNICACIÓN DE DATOS

ocupará de hacer la multiplexación mas adecuada de forma transparente a la capa

• LA CAPA DE SESIÓN: La capa de sesión es la primera que es accesible al usuario,

• LA CAPA DE PRESENTACIÓN: Hasta aquí nos hemos preocupado únicamente de

DIVISIÓN DE TELEDUCACIÓN 9 REDES DE COMUNICACIÓN DE DATOS

• LA CAPA DE APLICACIÓN: La capa de aplicación comprende los servicios que el

2.1.2 El modelo de referencia TCP/IP

En 1969 la agencia ARPA (Advanced Research Projects Agency) del Departamento de

La ARPAnet fue creciendo paulatinamente, y pronto se hicieron experimentos utilizando

DIVISIÓN DE TELEDUCACIÓN 10 REDES DE COMUNICACIÓN DE DATOS

Fig. 1.2 Modelo de referencia TCP/IP

DIVISIÓN DE TELEDUCACIÓN 11 REDES DE COMUNICACIÓN DE DATOS

• LA CAPA INTERNET: Esta capa es el ‘corazón’ de la red. Su papel equivale al

• LA CAPA DE TRANSPORTE: Esta capa recibe el mismo nombre y desarrolla la

• LA CAPA DE APLICACIÓN: Esta capa desarrolla las funciones de las capas de

DIVISIÓN DE TELEDUCACIÓN 12 REDES DE COMUNICACIÓN DE DATOS

2.1.3 Comparación de los modelos OSI y TCP/IP

Otra diferencia fundamental estriba en los servicios orientados a conexión (C-O) o no

DIVISIÓN DE TELEDUCACIÓN 13 REDES DE COMUNICACIÓN DE DATOS

Fig. 1.3 Modelos OSI y TCP/IP

• Momento inadecuado: Para cuando estaban disponibles productos comerciales

DIVISIÓN DE TELEDUCACIÓN 14 REDES DE COMUNICACIÓN DE DATOS

• Implementaciones inadecuadas: en parte como consecuencia de su complejidad,

2.2 EL PROTOCOLO INTERNET (IP)

2.2.1 Introducción al protocolo IP

DIVISIÓN DE TELEDUCACIÓN 15 REDES DE COMUNICACIÓN DE DATOS

Los distintos protocolos pueden ser:

• No orientados a la Conexión.- cada paquete de datos es enviado a la red sin la

El protocolo IP es un protocolo de entrega sin conexión y no confiable:

• Sin conexión: Cada paquete es tratado de manera independiente de todos los

IP tiene dos principios básicos:

IP por sobre todas las cosas

2.2.2 Funciones del protocolo IP