Redestelecomunicacion

Redes de Telecomunicación
Baquero Portero, Isidro

Borrego Checa, Juan
Cámara Mora, Carlos M
Clemente Pascual-Vaca, Emilio
Márquez Giráldez, Laura
Sánchez-Matamoros Pérez, Jose
Morales Castro, Manuel Ángel
Neira Fernández, Rubén
Ojeda Rodrı́guez, Maria Elena
Rodrı́guez Quesada, Agustı́n
Romero del Toro, Maria José
Rueda Borrego, Beltrán
Serrano Muñoz, Fernando
Julio 2007
Índice general
1. Introducción a las redes de telecomunicaciones 5

1.1. Definición. Modelo genérico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Eficiencia, evolución e integración . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Elementos de una red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Elementos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. Elementos no básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Clasificación de las redes de telecomunicaciones en función de cómo actúan sus
conmutadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Tipos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2. Tipos de redes basadas en la conmutación de paquetes atendiendo al fun-
cionamiento interno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.3. Tipos especiales de conmutación de paquetes . . . . . . . . . . . . . . . . 8
1.4.4. Ejemplos. Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Retardos en redes de conmutación de paquetes . . . . . . . . . . . . . . . . . . . 10
1.6. Revisión de los modelos de referencia: el modelo OSI . . . . . . . . . . . . . . . 11
1.6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6.2. Capas o niveles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.3. Comunicación entre sistemas. Primitivas . . . . . . . . . . . . . . . . . . 13
1.6.4. Funciones que se pueden realizar en cada capa . . . . . . . . . . . . . . . 16
1.6.5. Comparación con la jerarquı́a TCP/IP . . . . . . . . . . . . . . . . . . . 17
1
Redes de Telecomunicación 2
2. Redes de área extensa, WAN, Wide Area Networks 18

2.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2. Funciones básicas del nivel de red . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1. Direccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2. Encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3. Control de congestión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.4. Integración de redes heterogéneas . . . . . . . . . . . . . . . . . . . . . . 22
3. Direccionamiento 23
3.1. Tipos de direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1. Clasificación según el ámbito o alcance . . . . . . . . . . . . . . . . . . . 23
3.1.2. Clasificación según la jerarquı́a . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Formatos de direcciones más extendidos . . . . . . . . . . . . . . . . . . . . . . 24
3.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.2. Otros esquemas de direccionamiento . . . . . . . . . . . . . . . . . . . . 30
3.3. Algunos ejemplos de funcionamiento de IPv4 . . . . . . . . . . . . . . . . . . . . 32
3.3.1. Máquinas directamente accesibles . . . . . . . . . . . . . . . . . . . . . . 32
3.3.2. Subnetting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.3.3. Varios interfaces de red en una misma LAN . . . . . . . . . . . . . . . . 34
3.3.4. Ejercicio propuesto en clase . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.5. Difusión de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4. Integración de redes 38
4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2. Ejemplo de integración de redes con IPv4 . . . . . . . . . . . . . . . . . . . . . . 39
4.3. Formato de los paquetes IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.1. Fragmentación de paquetes IPv4 . . . . . . . . . . . . . . . . . . . . . . 41
4.3.2. Opciones más usuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4. Tablas de encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5. Encaminamiento 53
5.1. Tipos de direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2. Clasificación de mecanismos de encaminamiento . . . . . . . . . . . . . . . . . . 54
5.3. Jerarquı́a de encaminamiento y direccionamiento . . . . . . . . . . . . . . . . . . 55
5.4. Establecimiento de vecindades (Neighbour creating) . . . . . . . . . . . . . . . . 57
5.4.1. Enlace punto a punto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.4.2. Red de área local (LAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.5. PROXY ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.6. Cálculo de rutas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.6.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.6.2. Algoritmo del camino más corto . . . . . . . . . . . . . . . . . . . . . . . 70
5.7. Distribución de la información . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.7.1. Vector de distancias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.7.2. Estados de los enlaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.7.3. LSP en una LAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
5.8. Protocolos especı́ficos de encaminamiento . . . . . . . . . . . . . . . . . . . . . . 84
5.8.1. Protocolos intradominio (IGP) . . . . . . . . . . . . . . . . . . . . . . . . 87
5.8.2. Protocolos interdominio (EGP) . . . . . . . . . . . . . . . . . . . . . . . 90
5.8.3. TEMA 6: Control de congestión . . . . . . . . . . . . . . . . . . . . . . 96
5.8.4. Clasificación de los mecanismos de control de congestión . . . . . . . . . 97
6. Capa de transporte 99
6.1. Introducción a la capa de transporte . . . . . . . . . . . . . . . . . . . . . . . . 99
6.2. Jerarquı́a TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2.1. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7. Evolución de los equipos y tendencı́as 118

7.1. Introducción a IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2. Direccionamiento en IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3. Direcciones especiales en IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.4. Organización de las direcciones en IPv6 . . . . . . . . . . . . . . . . . . . . . . . 122
7.5. Asignación de direcciones en IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 122
7.6. Formato de datagramas IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
7.7. Cabeceras de opciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
7.8. Protocolo ICMPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
7.9. IPv6 Móvil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.10. Introducción a IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.11. Introducción a las VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Capı́tulo 1
Introducción a las redes de

telecomunicaciones
1.1. Definición. Modelo genérico

Podemos definir una red de telecomunicaciones como aquella que proporciona una comu-
nicación eficiente entre múltiples entidades usando distintas tecnologı́as (eléctrica, electrónica,
electromagnética...).
El modelo general de una red de telecomunicaciones (fig. 1.1) se compone de:
Figura 1.1: Modelo general de una red de telecomunicaciones.
Fuente: genera información.

Transmisor: transforma información en señales.
Sistema de transmisión: transporta señales.
Receptor: inverso del transmisor.
Destino: donde llega la información.
5
1.2. Eficiencia, evolución e integración

Para mejorar la eficiencia usamos conmutadores, dando lugar a estructuras jerárquicas exis-
ten distintas redes dependiendo del servicio que se quiera ofrecer con dicha red (fig. 1.2):
Figura 1.2: Interconexión de dos redes mediante un conmutador.
Redes públicas: RTB, X.25, TV por cable.

Redes privadas: Centralitas, red de datos (red de área local)
RDSI: Red única que se concibió para que pudiera servir para ofrecer cualquier tipo de
servicio. La tecnologı́a ATM es la que iba a soportar RDSI.
1.3. Elementos de una red

1.3.1. Elementos básicos
Acceso: parte de la red que va del sistema origen al primer conmutador (bucle de abonado).
Conmutación: conjunto de conmutadores que forman la red.
Transmisión: conjunto de enlaces que une los conmutadores. Se usan técnicas de multiple-
xión para compartir enlaces. Al conjunto de conmutadores y enlaces se les denomina red
dorsal.
Señalización: parte de la red que controla su funcionamiento. Hay dos tipos de señalización:
usuario-red, que comunica al usuario con el sistema, y red-red, que utiliza el sistema para
organizarse.
1.3.2. Elementos no básicos

Sincronización: corresponde a toda la parte que se encarga de sintonizar un transmisor con
un receptor.
Gestión: se encarga de los fallos (detectarlos, corregirlos...), monitorización y tarificación.
Servicios: es la parte de red que sirve para ofrecer distintos servicios.
1.4. Clasificación de las redes de telecomunicaciones en

función de cómo actúan sus conmutadores
1.4.1. Tipos básicos

Redes basadas en conmutación de circuitos: se basan en establecer una reserva de recur-
sos para la comunicación. Este sistema es muy adecuado con fuentes que emiten a una tasa
constante y que durante un cierto tiempo hablan con el mismo destino, como pueden ser
las conversaciones telefónicas. Sin embargo, no es adecuado para comunicación entre orde-
nadores, ya que éstos no tienen tasa constante y cambian constantemente de destinos, por
lo que si reservamos un canal exclusivamente para ellos gran parte del tiempo lo estaremos
desaprovechando.
Redes basadas en conmutación de paquetes: pensadas para fuentes intermitentes a ráfa-

gas y cuando los destinos cambian rápidamente. Utilizan multiplexión estadı́stica. Fig.
1.3.
Figura 1.3: Red de conmutación de paquetes.

1.4.2. Tipos de redes basadas en la conmutación de paquetes aten-

diendo al funcionamiento interno
Circuito virtual: consiste en preparar el camino para mandar una serie de paquetes de forma
que todos sigan la misma ruta. Al transmitir el primer paquete, se calcula la ruta hacia el
destino. Todos los paquetes posteriores con el mismo destino siguen la misma ruta.
Datagrama: en este caso, el camino se busca para cada paquete individualmente. Es más lento
si existe gran cantidad de paquetes, pero permite adaptarse mejor a los cambios de la red.
1.4.3. Tipos especiales de conmutación de paquetes

Conmutación de mensajes: cuando llega a un conmutador la información que se ha ido frag-
mentando en paquetes, se reensambla, se analiza y se vuelve a enviar el paquete frag-
mentándolo de nuevo. Sirve cuando queremos interconectar redes con funcionamientos
muy distintos.
Conmutación de células: los paquetes son de tamaño fijo y pequeños. Al ser de tamaño fijo,
los cálculos son más sencillos y rápidos de realizar (incluso se pueden realizar por hard-
ware), pero la probabilidad de fragmentación es más alta. Por ser de tamaño pequeño, la
cabecera ocupará proporcionalmente un tamaño mayor, lo que disminuye el rendimiento,
pero a cambio presenta la ventaja de tener un tiempo de transmisión menor. Un tiempo de
transmisión menor minimiza el problema de que llegue un paquete mientras estás trans-
mitiendo. Además, el tiempo de llenado (tiempo que se tarda en crear un paquete, por
ejemplo si estamos muestreando) es menor, lo cual es una ventaja.
1.4.4. Ejemplos. Internet

Existen dos ejemplos claros de redes que utilizan cada uno de los dos sistemas comentados
en el apartado 1.4.1:
Conmutación de circuitos: RTB (Red Telefónica Básica).
Conmutación de paquetes: Internet.
Veremos en profundidad el segundo ejemplo, Internet.

Descripción interna
Funciona con conmutación de paquetes. Sus componentes serı́an sistemas finales (hosts),
conmutadores intermedios (encaminadores o routers), enlaces de comunicación (punto a punto,
red de área local) y otros dispositivos como repetidores o puentes.
Organización
Protocolos: Jerarquı́a TCP/IP
Normas: RFC (IETF)
Proveedores de servicios: los Internet Service Provider (ISP) son los que componen la red
dorsal. Se estructuran en 3 niveles, llamados ”tiers”. Los proveedores tier 3 son los que
dan acceso a nivel residencial o a pequeñas compañı́as. Los tier 2 proveen a los tier 3. Los
grandes proveedores, llamados tier 1 o Internet Backbone Provider (IBP), sólo dan acceso
a proveedores tier 2 o compañı́as muy grandes. Los tier 1 tienen alcance internacional y
están interconectados entre sı́ (fig. 1.4).
Figura 1.4: Internet Service Providers o ISPs.
Descripción externa
Permite aplicaciones distribuidas.

Presenta dos tipos de servicios:

• No orientado a conexión y no fiable
• Orientado a conexión y fiable.
No garantiza retardo en ninguno de los casos.
1.5. Retardos en redes de conmutación de paquetes

Existen cuatro tipos de retardos:
Procesamiento: se denomina tiempo de procesamiento el tiempo que tarda el conmutador en

decidir qué hacer con un paquete. Es aproximadamente constante.
Encolado: se denomina tiempo de encolado al tiempo que tiene que esperar un paquete a que
se transmitan otros. Es muy variable, lo que hace que se convierta en el principal problema
de la fuente.
Transmisión: el tiempo de transmisión depende de la longitud del paquete (L, en bits) y de su
capacidad (C, en bits por segundo), ecuación 1.1.
L
ttransmisión = (1.1)
C
Propagación: el tiempo de propagación depende de la distancia que separa a los nodos emisor
y receptor (D, metros) y de la velocidad con la que se propaga la señal (V, metros por
segundo), ecuación 1.2.
D
tpropagación = (1.2)
V
En la fig. 1.5 podemos ver de forma esquemática los distintos retardos que intervienen en
una transmisión entre el equipo A y el B.
Para estudiar el tiempo de encolado se emplea la teorı́a de colas, donde:
Número de paquetes por segundo que llegan al sistema (tasa de llegada): λ

C
Tasa de salida del sistema: L
λ
Intensidad de tráfico: . Si es ≥ 1, la cola se hace infinita.
( CL )
Figura 1.5: Retardos que intervienen en una transmisión.
1.6. Revisión de los modelos de referencia: el modelo OSI
1.6.1. Introducción
Cuando los equipos telemáticos empezaron a conectarse en red hace unas décadas, cada
fabricante desarrolló su propia arquitectura, de manera que era imposible conectar en la misma
red equipos de distintos fabricantes (a menos que los fabricantes hubieran desarrollado interfaces
entre sus equipos). Como alternativa a los sistemas propietarios, la UIT-T desarrolló la norma
X.200, con el objetivo de interconectar sistemas de distintos fabricantes (interoperabilidad). Esta
norma es lo que conocemos como modelo OSI (Open System Interconnection).
Se trata de un modelo de capas en el que cada una de dichas capas:
Ofrece un servicio a la inmediatamente superior.
Recibe servicios de la capa inferior a ella.

De esta forma, el modelo OSI aborda el problema de la interconexión de equipos dividiéndolo

en varios ”problemas menores”. Esta solución es menos eficiente que una solución directa (una
que aborde simultáneamente todos los procesos implicados en la comunicación), pero es mucho
más sencilla de implementar. Además, tiene la gran ventaja de que las distintas capas pueden
ir desarrollándose por separado, sin que ello repercuta en el resto de capas, por lo que podrı́a
cambiarse toda la infraestructura de una capa determinada sin que el resto se enterara del
cambio.
Existen algunos términos que conviene tener claros al hablar del modelo OSI:
Entidad: Cada capa se descompone en entidades. Una entidad no es más que un módulo es-
pecializado que realiza una o varias de las funciones que le corresponden a dicha capa. Si
antes decı́amos que el modelo OSI aborda el problema de la interconexión de equipos di-
vidiéndolo en varios ”problemas menores, en cada capa esos ”problemas menores”vuelven
a dividirse en problemas más pequeños aún.
PDU (Protocol Data Unit): Se denomina PDU a la unidad que intercambia información
entre entidades pares de distintos sistemas (entidades de la misma capa pero en máquinas
distintas).
Servicio: lo que ofrece cada capa a la inmediatamente superior. Para ofrecer un servicio, las
entidades de una capa colaboran con las entidades gemelas de la misma capa residentes
en otros sistemas. En general, el servicio que una capa N ofrece a la capa N+1 consiste en
transmitir datos.
Protocolo: conjunto de reglas que rige el intercambio de PDUs entre entidades pares.
SAP (Service Access Point): es la forma que tiene una capa de ofrecer un servicio. Los SAP
constituyen la ”frontera.o ”interfaz.entre dos capas.
Primitivas: Son las órdenes que se envı́an entre capas contiguas. Son necesarias para poder
acceder al servicio.
1.6.2. Capas o niveles

Nivel 1: Fı́sico: Se encarga de transmitir la señal por el medio fı́sico. Controla parámetros
como niveles de tensión, tipos de señal, etc. Libera a las capas superiores de las funciones
que impongan los diferentes medios de transmisión.
Nivel 2: Enlace: Es responsable de la transferencia de información entre nodos adyacentes.

Nivel 3: Red: Ofrece comunicación extremo a extremo poniendo de acuerdo a los sistemas
intermedios.
Nivel 4: Transporte: Es muy similar al nivel de red, ya que también se ocupa de la transfe-
rencia de información extremo a extremo. La diferencia está en que la capa de transporte
lo hace independiente de cualquier nodo intermedio, mientras que la capa de red realiza su
función coordinándolos. Ofrece servicios que la capa de red no ofrece:
Fiabilidad: por si la capa de red ofrece un servicio no fiable, transporte puede emular
uno fiable si se requiere.
Orientación a conexión.
Multiplexión: el nivel de red puede ofrecer una sola comunicación de una máquina a
otra, mientras que el nivel cuatro puede añadir multiplexión para tener más canales.
Nivel 5: Sesión: Ofrece mecanismos para organizar y sincronizar diálogos entre máquinas. Per-
mite a las aplicaciones marcar el progreso del diálogo (insertando puntos de sincronismo)
y determinar qué sistema está en posesión del turno, ası́ como retomar un diálogo que se
haya interrumpido (por ejemplo, si hay algún error en la transmisión).
Nivel 6: Presentación: Se ocupa de la compatibilidad sintáctica (cómo se representa la infor-

mación). Para ello ofrece una forma canónica de representar información independiente a
la implementación de los distintos sistemas.
Nivel 7: Aplicación: Se ocupa de la compatibilidad semántica (lo que representa la informa-

ción).
1.6.3. Comunicación entre sistemas. Primitivas

Las entidades residentes en una capa necesitan comunicarse con las entidades gemelas re-
sidentes en otros sistemas. Dicha comunicación se realiza mediante el intercambio de mensajes
denominados PDU.
Aunque desde un punto de vista lógico cada capa se comunica directamente con su equi-
valente de otro sistema, la realidad es que cada capa va pasando la información que quiere
transmitir a la inferior, hasta llegar a la más baja (nivel fı́sico), que es la única que se comunica
realmente”. Para ello, según la información va atravesando de forma descendente las distintas
capas del modelo, se van añadiendo encabezamientos que contienen la información de control.
El conjunto resultante se transmite por el canal, y en el destino seguirá el camino inverso, es
decir, cada encabezamiento será utilizado sólo por la capa receptora del mismo nivel; los en-
cabezamientos destinados a las capas superiores son completamente ignorados, permitiendo la
evolución independiente de cada una de las capas.
Como ilustra la fig. 1.6, cuando una capa quiere mandar información lo hace en forma
de PDUs. Para ello, la entidad correspondiente de la capa N+1 utiliza los servicios que la capa
inferior (la capa N) le ofrece a través del SAP, generando un SDU (Service Data Unit) que pasa a
dicha capa. A este N-SDU se le añade una cabecera llamada PCI (Protocol Control Information).
La PCI contiene información que solamente es útil para la capa par, de modo que cuando una
capa recibe una PDU, extrae la PCI, la interpreta y envı́a la SDU a la capa superior.
Figura 1.6: Intercambio de PDUs entre entidades pares mediante los servicios que ofrecen las
capas inferiores.
Los SAP, como ya se ha visto, proporcionan servicios a la capa inmediatamente superior, y lo

hacen mediante las denominadas primitivas de servicio. Existen 4 tipos:
Petición (REQ, Request)

Indicación (IND, Indication)

Respuesta (RESP, Response)
Confirmación (CONF, Confirmation)
Según el tipo de primitivas que utilice, un servicio puede ser:
No confirmado: sólo utiliza REQ e IND.

Confirmado: usa los 4 tipos, REQ, IND, RESP y CONF.
Por otro lado, si atendemos al tipo de conexión, los servicios pueden clasificarse en:
Orientados a conexión (CO, Connection Oriented): necesitan establecer una conexión entre
emisor y receptor antes de enviar los datos.
No orientados a conexión (CL, Connectionless).
Es importante recalcar que el hecho de que un servicio sea confirmado o no confirmado es

totalmente independiente de que sea CO ó CL. Aunque algunas de las combinaciones puedan pa-
recer extrañas, pueden darse cualquiera de las 4 posibilidades que podrı́an obtenerse al combinar
el tipo de primitivas utilizadas y la orientación a conexión.
De forma esquemática, el funcionamiento de las primitivas serı́a el de la fig. 1.7.
Figura 1.7: Uso de primitivas.
El envı́o de primitivas lleva asociado, en general, la generación de PDUs, pero no tiene por
qué. Por ejemplo, la máquina B puede aprovechar un paquete que contenga una petición suya
hacia A e incluir en dicho paquete una respuesta de B a una petición anterior de A.
1.6.4. Funciones que se pueden realizar en cada capa

Control de errores: Aunque puede realizarse en todas las capas, lo mejor es buscar un com-
promiso entre calidad y servicio (según el nivel de errores de cada capa), ya que el control
de errores consume recursos del sistema Habitualmente se realiza en las capas bajas: fı́sica,
de enlace, de red y de transporte.
Control de flujo: Si un receptor se ve desbordado por la información que recibe (le llegan más
datos de los que es capaz de procesar), puede pedirle a un emisor que se frene.
Establecimiento de la conexión Dentro de un mismo sistema puede haber capas cuya co-
municación esté orientada a conexión y capas que no, dependiendo de lo que interese al
diseñar el sistema.
Segmentación y reensamblado: Cada nivel tiene un tamaño máximo de SDU admisible.

Cuando el nivel inferior no admite una SDU que queremos transmitir por ser demasia-
do grande, se puede trocear (fragmentar) esa SDU en varias en el emisor, volviendo a
unirla (reensamblarla) en el receptor. Hay otras operaciones parecidas, que no veremos en
profundidad:
Bloqueo-desbloqueo: Crea bloques de información. Definida en la recomendación X.200.

Concatenación-separación.
Multiplexión-demultiplexión: Cosiste en ofrecer el servicio de varios SAP del nivel N+1 a

través de un SAP del nivel N (fig. 1.8). Se usa de forma habitual en servicios CO.
Figura 1.8: Multiplexión.

Figura 1.9: Comparación OSI-TCP.
1.6.5. Comparación con la jerarquı́a TCP/IP

La Jerarquı́a TCP/IP sólo tiene 5 capas, cuya correspondencia con las 7 de la pila OSI es
la de la fig. 1.9.
Capı́tulo 2
Redes de área extensa, WAN, Wide

Area Networks
2.1. Introducción
Existen varias formas de conectar varios ordenadores:
Punto a punto: cada ordenador se conecta directamente al resto, mediante un cable fı́sico
exclusivo.
Red de área local (RAL o LAN): Hablamos de una red de área local cuando tenemos varios
equipos interconectados de modo que pueden comunicarse entre sı́ sin necesidad de pasar
por conmutadores y/o encaminadores. Cómo se observa en la fig. 2.1.
En una LAN, los equipos pueden interconectarse de dos formas:
Si todos los equipos trabajan con el mismo nivel fı́sico (por ejemplo, todos se conectan
a través de interfaces Ethernet), para interconectarlos usamos un repetidor (hub).
Dicho dispositivo solo presenta funciones de la capa 1 (fı́sica).
Para conectar equipos que utilizan interfaces no compatibles se utiliza un puente (en
inglés, bridge). El puente presenta funciones de las capas 1 y 2 (fı́sica y enlace).
Red de área extensa (RAE o WAN): para interconectar varias redes de área local, se nece-
sita un encaminador o router. Este dispositivo posee funcionalidades de la capa 3 (red), lo
18
Figura 2.1: Concepto de LAN y WAN.
que significa que puede encaminar tráfico. Además de encaminar, puede controlar y filtrar
el tráfico que pase por él. Al unir varias redes LAN con encaminadores, obtenemos una red
de área extensa.
Cómo se observa en la fig. 2.2, si la máquina A se quisiera conectar al PC de la segunda

red, tendrı́a que seguir el siguiente camino: Saldrı́a de la capa 7 del PC A, pasarı́a por la capa 1
del hub, por la capa 3 del router, por la capa 2 del bridge y de allı́ pasarı́a a la capa 7 del PC.
De forma más esquemática, una WAN se puede representar como en la fig. 2.3.
No hay que confundir el servicio ofrecido por nivel de red (orientado a conexión o no
orientado a conexión) con el funcionamiento interno de los encaminadores (circuito virtual o
datagrama). Normalmente, orientado a conexión se relaciona con circuito virtual, pero podemos
tener TCP (que es orientado a conexión) sobre datagramas.
2.2. Funciones básicas del nivel de red

Figura 2.2: Comunicación atravesando una WAN.
Nota: Saber cuáles son las funciones básicas del nivel de red es concepto muy básico e
importante de cara al examen.
2.2.1. Direccionamiento
Identificación unı́voca de los nodos de la red. Las direcciones son únicas en todo el nivel de
red. Si el enlace es punto a punto no hacen falta direcciones.
2.2.2. Encaminamiento
Búsqueda de un camino para que los paquetes atraviesen la red desde el emisor hasta el
receptor. Se divide el problema en:
Establecimiento de vecindades: saber cuáles son los nodos vecinos y adyacentes.
Distribución de información: distribuir la información que cada encaminador posee.
Cálculo de rutas: se calculan rutas con la información que posee el encaminador y la que le
envı́an los otros.
Figura 2.3: Esquema genérico de una WAN.
Nota: Saber cuáles son las partes que componen el encaminamiento es concepto muy
básico e importante de cara al examen.
2.2.3. Control de congestión

La red dedica parte de sus recursos para controlarse a sı́ misma, de modo que se eviten
bloqueos. Para ello, el nivel de red debe introducir información adicional en los paquetes.
Figura 2.4: Comportamiento ideal, con info. de control y real en situación de congestión.
Como se ilustra en la fig. 2.4, los diferentes comportamientos frente a la situación de con-
gestión son los siguientes:
En el caso ideal la información que sale es igual a la que entra. Esto ocurre hasta que llegamos
al punto de saturación del sistema, en que independientemente de la información que entre,
la salida es la misma, el máximo que permita el sistema.
En el caso ideal con información de control se pierde un poco de rendimiento al tener en

cuenta que parte de los recursos se dedican a la comunicación entre conmutadores.
En el caso real entran en acción dos efectos que no tenı́amos en cuenta anteriormente:
que algunos paquetes se pierden y es necesario retransmitirlos,

y que el sistema no posee una memoria infinita, sino limitada.
Por tanto, pasado un punto (punto de congestión), el sistema empieza a perder paquetes
debido a que su memoria está llena. Además, se puede llegar a un punto en que todos los recursos
del sistema se dediquen al control de congestión, y perdamos la capacidad de transmitir (punto
de bloqueo). Es necesario buscar un compromiso entre congestión y rendimiento. Lo mejor serı́a
una menor congestión a costa de un menor rendimiento.
2.2.4. Integración de redes heterogéneas

El mejor sitio para conectar redes heterogéneas es el nivel de red, ya que es dicho nivel el
que posee la información más útil para poder traducir los paquetes entre una red y otra.
Capı́tulo 3
Direccionamiento
3.1. Tipos de direcciones
3.1.1. Clasificación según el ámbito o alcance

Locales: las direcciones están restringidas a un cierto entorno. Serı́a suficiente con el direc-
cionamiento en el nivel de enlace.
Globales: alcanzan a toda la red (son por tanto direcciones del nivel de red).
En el nivel de enlace se usan normalmente direcciones MAC de 48 bits (IEEE 802.11). Son
direcciones únicas que los fabricantes asignan a cada tarjeta de red, aunque sólo hace falta que
sean únicas dentro de una misma LAN.
3.1.2. Clasificación según la jerarquı́a

Jerárquicas: si dos de estas direcciones tienen una parte común, los caminos que deben
seguirse para llegar a ellas también tienen una parte común.
Planas: coincidencias en una parte de las direcciones no implican que los caminos a recorrer
vayan a tener una parte común. Ej. Dos tarjetas de red del mismo fabricante comparten los
24 primeros bits de su dirección MAC, y no tienen por qué instalarse en la misma subred.
23
3.2. Formatos de direcciones más extendidos
3.2.1. IPv4
Introducción
Se trata de direcciones globales y jerárquicas de 32 bits (4 octetos). Tienen dos partes, red
y host (también llamadas subred y máquina, respectivamente). Todas las máquinas cuya parte
de red coincida, deben poder comunicarse directamente sin pasar por un router; dicho de otro
modo, esas máquinas podrı́an comunicarse mediante el nivel de enlace. En ese caso se dice que
esas máquinas son directamente accesibles.
Clases de direcciones IP. Direcciones especiales
Existen 3 tipos fundamentales de direcciones IPv4, que se distinguen según el valor de sus
primeros bits:
Clase A: La parte de red la foman los 8 primeros bits mientras que la parte de host son los
siguientes 24 bits. El número máximo de direcciones que podemos conseguir son 16777216.
0XXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX
Clase B: La parte de red la foman los 16 primeros bits. El número máximo de direcciones
son 65536.
10XXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX
Clase C: La parte de red la foman los 24 primeros bits. El número máximo de direcciones
son 256.
110XXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX
Además de estas tres fundamentales, existen otras dos clases de direcciones, aunque su uso
está poco extendido:
Clase D: dirección de grupo (multidifusión o multicast). Sirven para enviar un mismo

datagrama simultáneamente a varios destinatarios de un mismo grupo. Su formato es el
siguiente:
1110XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX
Tienen dos particularidades:
• No pueden usarse como dirección de origen, sólo de destino.

• Necesitan usar el protocolo IGMP para ser encaminadas. Esto significa que sólo se
podrán usar estas direcciones entre redes que estén unidas por routers que ”ha-
blen”multicast, lo que en la práctica ocurre muy pocas veces.
Clase E: este tipo de direcciones están reservadas para usos experimentales y posibles
usos futuros. Su formato es el siguiente:
1111XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX
Figura 3.1: Tabla resumen de las clases de direcciones.
Existe una serie de direcciones IPv4, denominadas especiales, que tienen un uso especı́fico,
independientemente de lo que pudiera indicar a priori su clase:
255.255.255.255 - Dirección de difusión general (también llamada de difusión local o

limitada): cuando se envı́a un datagrama con esta dirección de destino, la tarjeta de red lo
envı́a a todos los nodos de la red local. Si la LAN está interconectada con otras mediante
un router, éste NO retransmite el datagrama fuera de la red.
127.xxx.xxx.xxx - Dirección reflexiva: cuando se envı́a un datagrama a esta dirección,
vuelve a la misma máquina que lo envió. Sirve generalmente para realizar pruebas y
diagnósticos del sistema.
Direcciones de uso privado - no tienen por qué ser únicas, esto es, sı́ se pueden repetir
dentro de distintas redes locales, pero están aisladas de la WAN. Son tres rangos:
• 10.0.0.0 - 10.255.255.255
• 172.16.0.0 - 172.31.255.255
• 192.168.0.0 - 192.168.255.255
Para que las máquinas que estén dentro de una red local direccionadas con una dirección
privada puedan comunicarse con otras redes remotas a través de una WAN se utiliza el protocolo
de encaminamiento NAT (Network Address Translation). Este protocolo se implementa general-
mente en los routers, y se encarga de traducir de forma transparente al usuario las direcciones
IPv4 privadas en direcciones IPv4 válidas para poder ser enviadas a través de una WAN.
Máscaras
El esquema de direccionamiento de IPv4 que acabamos de ver (denominado ”por clases o

classful”) es muy cómodo y sencillo de gestionar, pero tiene el inconveniente de ser poco flexible.
Por ello surgieron las máscaras (y su implementación obligó a realizar ciertas modificaciones
en los protocolos de encaminamiento, como veremos).
Una máscara no es más que un grupo de 32 bits divididos en 4 octetos (como las direcciones
IPv4) que indican hasta dónde llega la parte de red de una dirección dada. Su formato es el
de una serie de unos seguido de una serie de ceros (salvo los casos lı́mite de ”todo unos y todo
ceros”, claro), es decir, que no puede haber ceros intercalados entre los unos, ni unos entre los
ceros. Suelen expresarse en decimal, como las direcciones; por ejemplo:
11111111.11111111.11111111.10000000=255.255.255.128
También pueden expresarse mediante una ”notación compacta”, que consiste en poner una
barra seguida del número de unos que tiene la máscara justo tras la dirección a la que se
aplica. Por ejemplo, para aplicar la máscara anterior a la dirección 138.4.3.120 podrı́amos usar
indistintamente:
138.4.3.120/255.255.255.128 ó 138.4.3.120/25
Las mácaras pueden usarse de diversas maneras para dar mayor flexibilidad al sistema de
direccionamiento IPv4. Veremos algunas de estas formas con mayor detalle, y otras simplemente
las nombraremos.
Subnetting con subredes homogéneas (FLSM - Fixed Length Subnet Mask)

Inicialmente se desarrolló dentro de algunas grandes empresas que lo empleaban para
optimizar sus redes, pero acabó convirtiéndose en un estándar.
El esquema ”classful”que acabamos de ver presenta varios problemas:
• Las direcciones de clase A están sobredimensionadas, ya que pueden albergar millones

de hosts, lo que difı́cilmente una tecnologı́a LAN podrı́a soportar. Además, son muy
escasas, y por tanto caras.
• Por otro lado, las direcciones de clase B también son demasiado grandes para ser
empleadas como ”unidad mı́nima”. Por ejemplo, si una compañı́a tiene 2000 máquinas,
necesitará una dirección B, que le permitirá direccionar 65536 máquinas. Como vemos,
esto es muy ineficiente, ya que se desperdician más de 60000 direcciones.
• No permite el fraccionamiento interno de la red; si se quiere aislar el tráfico entre dos
grupos de máquinas, es necesario asignar una dirección a cada grupo.
El subnetting permite introducir routers dentro de una LAN y realizar subredes dentro de
una misma dirección de red tipo B (teóricamente puede usarse también en las clase A y
C, pero es muy poco habitual). Desde el exterior, es como si la LAN original no hubiera
cambiado (permite compatibilidad hacia atrás con los esquemas de direccionamiento origi-
nales de IPv4), pero desde dentro de la red es como si se hubiera dividido en varias LANs
más pequeñas, lo que permite gestionar el tráfico de red mucho mejor.
Su funcionamiento es muy simple: se trata de dividir el campo host de una dirección IP
como las que vimos en el apartado anterior en dos, asignando una de estas partes al campo
de red para formar un ”campo de red extendido”. Para ello se emplea una máscara, que
deberá tener tantos unos seguidos como el campo de red ”original”más el número de bits
que queramos ampliarlo. Es más fácil verlo gráficamente en la fig. 3.2.
Figura 3.2: Ejemplo de subnetting.

Al aplicar la máscara, aparecen nuevas direcciones reservadas:
• Dirección de la subred: IP AND MASK

• Dirección de difusión de la subred: IP OR (MASK negada)
La dirección de subred no se usa (no está asignada a ningún host de la red, sólo se uti-
liza para cı́rculos de direccionamiento). En cambio, la dirección de difusión de la subred
sı́; conviene resaltar que, a diferencia de la dirección de difusión general, la dirección de
difusión de subred sı́ puede emplearse para transmitir datagramas a equipos que no están
en la misma red fı́sica, pudiendo atravesar routers (siempre que están en la misma subred).
Cada subred irá desde la (dirección de subred+1) hasta la (dirección de difusión de la
subred -1), por lo que cada una tendrá:
no direcciones = 2LongitudCampoHost − 2 (3.1)
Desde el exterior, no habrá diferencia alguna, pero internamente el router tendrá un ma-
yor control sobre el tráfico en cada subred; por ejemplo, cuando se indica la dirección de
difusión de la subred, el datagrama debe llegar a todos los nodos de la subred, pero no sale
fuera de ésta.
Subnetting con subredes no homogéneas (VLSM-Variable Length Subnet Mask)

La principal restricción del subnetting que acabamos de ver es que la máscara debe ser la
misma para todas las subredes. Esto es lo mismo que decir que todas las subredes tendrán
el mismo tamaño, ya que en todos los casos los campos de subred y host tendrán el mismo
número de bits. Con este esquema se desaprovechan muchas direcciones.
Con VLSM se pretende dar aún más flexibilidad, ya que permite que distintas subredes
tengan máscaras distintas (permite crear sub-subredes, por decirlo de alguna manera),
permitiendo de esta manera ajustar más los tamaños de las subredes al número de máquinas
que están dentro de ellas y desaprovechando menos direcciones.
El esquema VLSM no es compatible con el esquema ”classful”, ya que es necesario modificar
el protocolo de red para que pueda transportar las máscaras de las subredes además de las
direcciones IP.
No veremos nada más acerca de este esquema de direccionamiento.
Supernetting
Supongamos que se desea montar una red con 900 equipos. Para poder direccionarla, una
dirección de clase C (254 hosts) serı́a insuficiente, pero usar una de clase B (65536 hosts)
implicarı́a desperdiciar miles de direcciones útiles. Esta situación se dio mucho, pues redes
de tamaño medio se veı́an obligadas a pedir una dirección de clase B a pesar de desapro-
vechar la mayor parte del espacio de direcciones, lo que llevó a un rápido agotamiento de
este tipo de direcciones.
El supernetting nació como solución a este problema: básicamente consiste en la asociación
de varias direcciones consecutivas (normalmente de clase C) para formar una especie de
”super-red”(en contraposición al término ”subred”) mayor. La forma de hacerlo es sencilla:
se toman varias direcciones consecutivas y se les asocia a todas la misma máscara. El
router sólo deberá recordar la primera dirección del grupo y la máscara (por lo que no es
compatible con el sistema ”classful”).
Veamos un ejemplo para nuestra red de 900 equipos. Necesitaremos 4 direcciones de clase
C (254 x 4 = 1016 hosts) que sean consecutivas, ya que en ese caso su campo de red
será exactamente igual salvo por los últimos bits. Supongamos que en nuestro caso el campo
de red de la primera dirección acaba con los bits 00; de esta forma, las tres direcciones
siguientes acabarán en 01, 10 y 11, pero el resto del campo de red será exactamente igual
al de la primera dirección.
Figura 3.3: Ejemplo de supernetting
Como puede verse, el supernetting tiene una restricción: las direcciones sólo pueden agru-
parse en conjuntos que sean potencias de 2 (de 2 en 2, de 4 en 4, de 8 en 8), debido a la
forma de aplicar las máscaras. Se siguen desaprovechando algunas direcciones, pero desde
luego no tantas como con el esquema classful.
CIDR (Classless InterDomain Routing)

Es el esquema que se utiliza actualmente en Internet. Consiste en una especie de fusión
entre los conceptos de VLSM y supernetting, y soluciona (al menos de forma temporal)
los dos principales problemas que estaba teniendo internet:
• Agotamiento de direcciones
• Crecimiento excesivo de las tablas de enrutamiento
Sus principales caracterı́sticas son:
• Las clases de direcciones (A, B, C, etc) dejan de tener sentido. Esto permite que
cualquier red esté dentro de cualquier rango (no siendo necesario hacer subredes dentro
de una de clase B, como en el subnetting, o agrupar direcciones de clase C, como en
el supernetting).
• Las entradas en las tablas de enrutamiento de los routers deben tener, además de la
dirección, la máscara.
• Los protocolos de enrutamiento deben ser capaces de transportar las m0̆0e1scaras.
• Permite ajustar más el tamaño de las redes al necesario, desaprovechando menos
direcciones, gracias al uso de máscaras de tamaño variable.
3.2.2. Otros esquemas de direccionamiento

ISO/NSAP
Sus direcciones tienen longitud variable, hasta un máximo de 20 octetos.
X.121
Se usa en redes X.25. La dirección está compuesta por dı́gitos, no por octetos, hasta un
tamaño máximo de 14 dı́gitos, y consta de dos campos:
TERMINAL (10 dı́gitos) + RED (hasta 4 dı́gitos)
Los dı́gitos del campo de red tienen significado geográfico, ya que identifican al paı́s.
E.164
Propia de la red telefónica actual. Se compone de un máximo de 15 dı́gitos, que se dividen en

tres campos. Cuando se usan estas direcciones para la interconexión de redes tienen el siguiente
formato:
PAÍS (3 dı́gitos) + Código de identificación (entre 1 y 4 dı́gitos) + no de abonado (12-X
dı́gitos)
F.69
Se usa en la red Télex.
IPv6 ó IPng (nueva generación)
Direcciones de 128 bits (16 octetos). Cada octeto se expresa como dos cifras en hexadecimal
y cada cuatro cifras hexadecimales se separan por dos puntos (:). Ejemplo:
1234:5678:90AB:0000:FCB7:0000:0000:FFA7
Si la dirección lleva dos puntos seguidos de otros dos (::), indica que la cantidad de cifras
hexadecimales que faltan son todos ceros en esa posición (4 ceros, 8 ceros, etc). Por ejemplo:
1234:5678:90AB:0000:FCB7:0000:0000:FFA7
En este caso vemos como nos faltarı́a ocho ceros y los pondrı́amos en la posicion de los :: como
en el primer ejemplo. No podrı́amos reemplazar los primeros cuatro ceros (negrita) a la vez que
los últimos ocho poque no sabrı́amos que cantidad de ceros irı́an en cada posición.
Además se pueden indicar los últimos cuatro octetos en formato IPv4. Por ejemplo:
::193.147.162.5 = 0000:0000:0000:0000:0000:0000:193.147.162.5
Las direcciones IPv6 pueden ser de tres tipos:
Unicast: como en IPv4, dirigida a un sólo host.

Multicast: como IPv4, dirigida a varios host.
Anycast: es como si fuese una dirección de grupo pero con que llegue a uno del grupo es
suficiente.
3.3. Algunos ejemplos de funcionamiento de IPv4
3.3.1. Máquinas directamente accesibles

Supongamos la situación de la figura 3.4 El equipo A no conoce la máscara de B, sólo su
Figura 3.4: Ejemplo
IP. Para que A pueda saber si B está o no accesible debe realizar lo siguiente:
Compara los resultados de estas dos operaciones:
IPa &M ASCa (3.2)
IPb &M ASCa (3.3)
Si ambos resultados son iguales indica que el nodo es directamente accesible, y las tramas
del nivel de enlace que transmite el equipo A serán de la forma que indica la figura 3.5:
Si ambos resultados no son idénticos, el será el encaminador el que tenga que encargarse
de hacer llegar los datos a B, y los datagramas que salen de A quedarı́an como la figura
3.6:
Para poder realizar comunicaciones a través del nivel de enlace, se utiliza el protocolo ARP
(Address Resolution Protocol). Es un protocolo de nivel de red responsable de encontrar la
Figura 3.5: Datagrama de A a B si B es directamente accesible
Figura 3.6: Datagrama de A a B si B no es directamente accesible
dirección hardware (Ethernet MAC) que corresponde a una determinada dirección IP. Para ello
se envı́a un paquete (ARP request) a la dirección de multidifusión de la red (broadcast (MAC
= ff ff ff ff ff ff)) conteniendo la dirección IP por la que se pregunta, y se espera a que esa
máquina (u otra) responda (ARP reply) con la dirección Ethernet que le corresponde. Cada
máquina mantiene una caché con las direcciones traducidas para reducir el retardo y la carga.
ARP permite a la dirección de Internet ser independiente de la dirección Ethernet, pero esto
solo funciona si todas las máquinas lo soportan.
3.3.2. Subnetting
Supongamos el rango de direcciones definido por: 193.147.160.0/21. El número total de
direcciones que tendremos disponible, teniendo en cuenta que hay que reservar dos para dirección
de red y la de difusión será de:
232−21 − 2 = 2046 direcciones (3.4)
Supongamos que nuestro objetivo es hacer 3 subredes de aproximadamente 1000 usuarios

en una y 500 en las otras dos. El esquema de lo que queremos se puede apreciar en la figura 3.7.
La primera, de 512-2=510 usuarios se podrı́a direccionar de la siguiente forma (hay más de una
solución posible):
Figura 3.7: Ejercicio 1
193.147.160.0/23 Dir de subred: 193.147.160.0 Dir de difusión: 193.147.161.255
La segunda de los mismos usuarios serı́a:
Y la tercera de 1024-2=1022 usuarios serı́a:
En realidad a todas las subredes habrı́a que quitarle un usuario más, ya que una de estas
direcciones la tenemos que asignar a la interfaz del router con la que está conectada la subred.
Normalmente se toma la primera dirección del rango de la subred. Visto desde fuera de la red,
todas las subredes comparten los 21 primeros bits de la dirección IP.
3.3.3. Varios interfaces de red en una misma LAN

Supongamos una LAN en la que tenemos, entre otros, 3 equipos llamados A, B y C. La
red se conecta a Internet mediante un router, y las máscaras de los 3 equipos es la misma:
255.255.255.248 (29 bits a uno). Figura 3.8.
Figura 3.8: Ejercicio 2
En teorı́a, podrı́amos pensar que, estando en la misma red local, todos los equipos deberı́an
poder comunicarse directamente a través del nivel de enlace (estar ”directamente accesibles”).
Aunque esto deberı́a ser ası́, lo cierto es que el uso de máscaras puede hacer que no siempre sea
posible.
En nuestro ejemplo, si A quiere enviar un datagrama a B o C, lo primero que harı́a serı́a
comprobar sus direcciones con su máscara, con lo que obtendrı́a:
IPa &M ASCa = 150,214,4,0 (3.5)
IPb &M ASCa = 150,214,4,8 (3.6)

IPc &M ASCa = 150,214,4,8 (3.7)
Si A quiere mandar algo a B o C debe enviarlo al router, ya que interpreta que no están
accesibles. Si B quiere enviar algo a C lo puede hacer directamente sin pasar por el encaminador.
Por tanto, el router deberá tener dos interfaces de red, que serı́an 150.214.4.1 (para la subred
donde se encuentra A) y 150.214.4.9 (para la subred donde se encuentran B y C).
3.3.4. Ejercicio propuesto en clase

Asignar direcciones a 3 subredes con al menos 50 direcciones cada una a partir de 193.0.0.0.
Para cada una definir lo siguiente:
Dirección de subred y de difusión.
¿Cuál es la mejor dirección de subred y máscara que agrupe a las tres?
3.3.5. Difusión de mensajes

En este ejemplo, vemos cómo el ordenador A envı́a un paquete a tres direcciones de difusión
distintas. En el caso de los paquetes enviados a 181.168.7.255 (la dirección de difusión de la
subred), el paquete llega a todas las máquinas de la subred. Es el mismo caso que con el paquete
enviado a 255.255.255.255 (la dirección de difusión general). En ambos casos, el router, al ver
que el paquete va dirigido a la subred a la cual pertenece el interfaz por el que le llega el paquete,
no reenvı́a. Figura 3.9.
Figura 3.9: Reenvı́o de los paquetes de difusión
El caso del paquete dirigido a 173.15.23.255 es diferente. El router, al ver que la dirección
de difusión no es la de la subred por la que le llega el paquete, decide reenviarlo. Tras viajar
por la red, llegará a la subred deseada. El mensaje serı́a recibido por todos los componentes de
dicha subred.
Capı́tulo 4
Integración de redes
4.1. Introducción
Cuando se diseña una red de datos se desea sacar el máximo rendimiento de sus capacidades.
Para conseguir esto, la red debe estar preparada para efectuar conexiones a través de otras redes,
sin importar qué caracterı́sticas posean.
El objetivo de la Interconexión de Redes (internetworking) es dar un servicio de comunica-
ción de datos que involucre diversas redes con diferentes tecnologı́as de forma transparente para
el usuario. Este concepto hace que las cuestiones técnicas particulares de cada red puedan ser
ignoradas al diseñar las aplicaciones que utilizarán los usuarios de los servicios.
Algunas de las ventajas que plantea la interconexión de redes de datos, son:
Compartición de recursos dispersos.

Coordinación de tareas de diversos grupos de trabajo.
Reducción de costes, al utilizar recursos de otras redes.
Aumento de la cobertura geográfica.
Los dispositivos de interconexión de redes sirven para superar las limitaciones fı́sicas de los
elementos básicos de una red, extendiendo las topologı́as de esta.
Como vimos en temas anteriores, el nivel de red es el más apropiado para integrar distintas
redes. En este tema vamos a ver de qué forma podemos conectar redes heterogéneas, centrándonos
fundamentalmente en las redes TCP-IP.
38
4.2. Ejemplo de integración de redes con IPv4

Supongamos que queremos comunicar dos máquinas distantes. Como puede verse en la
figura 4.1, el circuito fı́sico que hay entre ambas atraviesa redes de distinto tipo:
Figura 4.1: Ejemplo de interconexión de una red heterogénea. Nota: CNLP (Connection Less
Net Protocol)
Desde el punto de vista de los equipos que se comunican, lo más sencillo serı́a usar un
solo protocolo común, sin que tuvieran que ”lidiarçon los distintos tipos de redes que hay entre
ambos; y justamente eso es lo que se hace al usar IP: cada máquina debe preocuparse únicamente
de generar un paquete IP indicando, principalmente, su propia dirección IP y la dirección IP de
destino, y será el protocolo el que se preocupe de llevar los datos desde el origen al destino a
través de cualesquiera redes fı́sicas que haya entre ambos.
Para que podamos usar IP sobre cualquier tipo de red se necesita un método de resolución
de direcciones. En nuestro ejemplo, necesitarı́amos un método mediante el cual el ordenador A
fuera capaz de obtener la dirección X.25 del router R1 a partir de su IP; una vez en R1, que
encontrara la dirección ethernet del router R2; y finalmente, una vez en R2, que encontrara
la dirección CLNP del equipo B. Para ello se usa ARP, que funciona de la siguiente manera:
Cuando un ordenador quiere enviar un paquete a una dirección IP de un router u otro PC de su
misma red, primero envı́a un mensaje ARP (que es de difusión) preguntando a qué dirección de
nivel de enlace pertenece esa IP (dirección de nivel de red). El router correspondiente respon-
derá indicando su MAC (su dirección de nivel de enlace). Algunos sistemas permiten el proceso
inverso, obtener una IP a partir de una MAC.
4.3. Formato de los paquetes IPv4

El formato general de un datagrama IP se aprecia en la figura 4.2:
Figura 4.2: Cabecera IP
Las 5 primeras filas (primeros 20 octetos) son lo que se denomina la ’parte fija de la cabecera,
y siempre irán en cada datagrama, de modo que el tamaño mı́nimo de cada datagrama IP es de
20 octetos. A continuación vendrı́a un campo opcional de tamaño variable, y finalmente, si los
hubiera, los datos (también de tamaño variable). Veamos una descripción detalla de cada uno
de los campos:
Versión (4 bits): versión del protocolo. Para IPv4 aparecerá un 4.
Logitud de la Cabecera (4 bits): indica, en grupos de 4 octetos, el tamaño de la

cabecera IP (parte fija+opciones). Dado que el tamaño mı́nimo es 20 octetos, el valor
mı́nimo de este campo es 5.
ToS=Type of Service (8 bits): inicialmente era un campo opcional que los routers
antiguos ignoraban, pero hoy en dı́a se utiliza para la tecnologı́a QoS (Quality of Service,
calidad de servicio). En concreto se utiliza en los Servicios Diferenciales. En estos, el TOS
identifica el tipo de tráfico que lleva cada paquete (Tranferencia de ficheros, voz sobre
IP, etc.). Ası́, cada router tratará cada paquete de acuerdo al contenido. Por ejemplo, los
paquetes de VoIP (Voz sobre IP) requieren poco retardo pero importa poco que se pierdan
algunos. De esta forma, los routers darán prioridad a los paquetes VoIP pero los desecharán
si tienen que hacerlos esperar demasiado.
Longitud total del paquete (16 bits): indica, en número de octetos, el tamaño total del
datagrama IP, incluyendo cabecera y datos. Sirve para que el nivel IP del destino sea capaz
de descartar el relleno añadido por niveles inferiores. La longitud máxima del paquete es
de:
216 − 1 = 65535 octetos. (4.1)
Identificador (16 bits), Flags (3bits) y Desplazamiento y Offset (13 bits): estos
3 campos se utilizan para controlar la fragmentación de los paquetes, y se describen con
detenimiento en el apartado de Fragmentación de paquetes IPv4.
TTL = Time To Life (8bits): el tiempo de vida se inicializa en el emisor con un

valor entero, que se irá decrementando en una o varias unidades cada vez que el paquete
atraviesa un router. Si llega a cero, se destruye el paquete. De esta forma se evita que
paquetes perdidos queden atrapados en bucles infinitos saturando la red.
Protocolo (8bits): contiene un identificador del protocolo al que pertenece la PDU que
va en el campo de datos, como por ejemplo TCP.
Checksum (16bits): se trata de un sistema de control de la cabecera. Es muy simple, ya

que no es más que la suma de paridad de todos los bits de la cabecera.
Opciones: se describen en el apartado de Opciones más usuales.
4.3.1. Fragmentación de paquetes IPv4

Dado que los paquetes IP pueden atravesar redes de muy distinto tipo, cada una con un
tamaño máximo de paquete, a menudo ocurre que el tamaño del paquete IP a enviar es de-
masiado grande y hay que dividirlo en trozos más pequeños antes de pasarlo al nivel inferior.
Esto es lo que se conoce como ”fragmentación de paquetes”. Es evidente que en el receptor, los
paquetes deberı́an volver a unirse hasta obtener los paquetes IP originales, en lo que se denomina
”reensamblado”.
Veamos un primer ejemplo sencillo de fragmentación: supongamos que el router A quiere
enviarle al router B un paquete IP que contiene 3980 Bytes (octetos) más los 20 Bytes de cabecera
y que nuestro nivel inferior acepta datagramas de, como máximo, 1500 Bytes. Figura 4.3.
Figura 4.3: Ejemplo de fragmentación
El router A divide los 3980 Bytes de datos en 3 fragmentos, cada uno con un tamaño
máximo de 1480 Bytes. De esta forma obtenemos 2 paquetes de 20+1480=1500 Bytes y uno de
20+1020=1040 Bytes. Nótense varias cosas:
La cabecera del paquete original (el de 4000 Bytes) no se incluye en los fragmentos.
Los paquetes finales no deben superar el tamaño máximo incluyendo las nuevas cabeceras.
Por eso hemos dividido los datos en paquetes de 1480 Bytes como máximo, para que al
añadir la cabecera IP no superemos los 1500 Bytes.
Si sumamos, todos los Bytes finales, incluidas las cabeceras, vemos que el tamaño total se
ve incrementado, ya que cada nuevo fragmento añade una nueva cabecera.
Es importante observar que la fragmentación de un paquete puede darse en cualquier parte

del ”camino”que siguen los paquetes desde el emisor hasta el receptor, pero el reensamblado sólo
se efectúa en el receptor.
El protocolo IPv4 implementa un sistema para controlar la fragmentación y el reensambla-
do. Para ello, como vimos en el apartado anterior, hay varios campos en la cabecera de todo
datagrama IP que se encargan de controlar la fragmentación, y que serán de vital importancia
a la hora del reensamblado. Figura 4.4.
Figura 4.4: Campos de control de la fragmentación
Veamos una descripción detallada de cada uno:
Identificador (16bits): es un identificador unı́voco del datagrama original antes de frag-

mentar (en el ejemplo el de 4000 Bytes). Se usa cuando se solicitan reenvı́os. Debe ser
único a nivel de pareja IPorigen/IPdestino. Para ello, el origen lleva un contador interno
con el que numera cada paquete que envı́a e incrementa el contador en uno. Para evitar
confusiones en caso de que el sistema se caiga y restituya demasiado rápido y se mezclen
números, el contador no empieza en cero, sino en una cifra aleatoria. Además, se obliga al
sistema a que tarde en arrancar al menos el tiempo que tarda un paquete en desaparecer
de la red. De este modo, aunque coincidieran las cifras aleatorias no habrı́a confusión, ya
que el último paquete que usó el identificador ya no estará en la red.
Flags o banderas (3 bits): se trata de tres bits indicadores, cada uno con una función:
• Cero: siempre a cero (no tiene función asignada).
• MF (More Fragments): vale 0 en el último fragmento (no hay más fragmentos
detrás) y 1 en otro caso. Si el datagrama es único (no hubo fragmentación) también
vale 0. Cada vez que un datagrama se fragmenta, se pone el MF a uno en todos los
fragmentos salvo en el último, que se le pone el del datagrama del que proviene.
• DF (Don’t Fragment): indica al router que no debe fragmentar el paquete en
ningún caso. En el caso de no poderse enviar un datagrama tan grande, será desechado
por el router.
Offset o desplazamiento (13 bits): indica el lugar que ocupaba el fragmento actual
dentro del fragmento original. Hay que tener en cuenta las siguientes cosas:
• Se cuenta en grupos de 8 bytes, es decir, que si este campo vale 100 en realidad
querrá decir que van 100x8=800 bytes. Esto se debe a que sólo disponemos de 13 bits
para definir el offset, que en muchos casos pueden ser más que insuficientes.
• Se comienza a contar el Offset sin tener en cuenta la cabecera del datagrama original,
esto es, el desplazamiento es relativo al inicio del campo de datos, no al inicio del
datagrama.
• Los fragmentos de un paquete que a su vez es un fragmento de otro datagrama,

tendrán el Offset definido con respecto al datagrama original del que partieron todos
y no con respecto al fragmento justo anterior.
Para ilustrar esto con más detalle vamos a suponer que A envı́a el primer paquete por el
router de arriba, sin problemas de fragmentación, mientras que los paquetes 2 y 3 van a ser
enviados por B, donde vuelve a surgir la necesidad de fragmentación, como se aprecia en la
figura 4.5.
Figura 4.5: Ejemplo de fragmentación múltiple
Veamos de forma detallada y paso a paso el desglose de las cabeceras de fragmentación,

con los valores que irán tomando en cada paquete fragmentado. Originalmente, en el emisor,
no tenemos más que un solo datagrama, y los valores de los campos de fragmentación de su
cabecera serán los que se muestran en la tabla 4.3.1:
Paquete 1
Cabecera 20 octetos
Datos 3980 octetos
Offset 0
MF 0 (por ser el único paquete existente)
En el router A se produce la primera fragmentación, dando lugar a los siguientes paquetes

que se aprecian en la tabla 4.3.1:
Paquete 1 Paquete 2 Paquete 3

Cabecera 20 octetos 20 octetos 20 octetos
Datos 1480 octetos=185 grupos de 8 octetos 1480 octetos 102 octetos
Offset 0 185 185+185=370
MF 1 1 0
En el router B, los paquetes vuelven a dividirse. El resultado se muestra en la tabla 4.3.1.
Paquete 2.1 Paquete 2.2

Cabecera 20 octetos 20 octetos
Datos 800 octetos=100 grupos de 8 octetos 680 octetos
Offset 185 185+100=285
MF 1 1
Paquete 3.1 Paquete 3.2
Cabecera 20 octetos 20 octetos
Datos 800 octetos=100 grupos de 8 octetos 220 octetos
Offset 370 370+100=470
MF 1 0
4.3.2. Opciones más usuales

Como se dijo en su momento, este campo es opcional. En él se indicarán los servicios
opcionales que quieran utilizarse sólo cuando vayan a ser usados. Hay que tener en cuenta que,
al no ser campos ”obligatorios”no todos los routers los implementan; cuando quieran usarse se
deberá saber bien lo que se hace y los equipos de los que se dispone.
Son muchas las posibilidades, y solo veremos algunas:
Source Routing: sirve para especificar las IPs de los routers por los que debe ir pasando el
paquete. Dicho de otro modo, el origen especifica de forma explı́cita la ruta que deberán
seguir los datagramas hasta el destino.
Source Recording: cada router escribe su IP en el paquete antes de reenviarlo. De esta

forma, en el destino se puede saber de forma exacta la ruta seguida por cada paquete
hasta llegar a él.
TimeStamp: cada router escribe en el paquete el instante en el que lo encaminan. Permite

hacer controles de tiempo para las distintas rutas.
4.4. Tablas de encaminamiento

Cuando un router recibe un paquete, mira la dirección de nivel de enlace que aparece en el
destino del paquete; esta dirección puede ser:
La del propio router. Pasa el paquete al nivel superior para analizarlo. No lo reenvı́a.
La de difusión. En este caso tenemos dos posibilidades:
• Que sea la general (255.255.255.255): no se reenvı́a.

• Que sea la de subred (SUBRED.255): tampoco se reenvı́a.
Cualquier dirección distinta a las anteriores. En ese caso, el paquete será enrutado, en
función de la IP de destino, siguiendo las tablas de encaminamiento.
Una tabla de encaminamiento consta de varias entradas (filas), cada una de las cuales consta
de 5 campos (columnas). Los campos son los siguientes:
Dirección de Red (enadelante DirRed): es una dirección IP que engloba toda una red.
Suele acabar en cero.
Máscara de Red (en adelante Mask): define, aplicada al campo anterior, la extensión de
la red (véase el apartado 2.1.3 del tema anterior para una descripción más detallada).
Métrica: es el número de routers por los que debe pasar un paquete antes de alcanzar el
siguiente salto.
IP del siguiente salto (en adelante IPnext): es la IP del siguiente router al que se debe
enviar el paquete para que llegue a su destino. También llamada Next Hop.
Interfaz: indica la interfaz (tarjeta de red) por la que se debe enviar ese paquete.
Y en la tabla 4.4 vemos el aspecto que tendrı́a:
DirRed Máscara Métrica IPnext Interfaz

Dir1 Mask1 ... Dest1 ...
Dir2 Mask2 ... Dest2 ...
... ... ... ... ...
0.0.0.0 0.0.0.0 ... Router por defecto ...
La tabla de encaminamiento se ordena de mayor a menor longitud de máscara. A igual

longitud de máscara, se ordena de menor a mayor métrica.
Cada vez que llega un paquete al nivel 3 se le aplica la máscara de la primera entrada. Si el
resultado coincide con la DirRed de esa entrada será enviado a la IPnext por la interfaz especi-
ficada. Si el resultado no coincide, se pasa a comprobar la segunda entrada y ası́ sucesivamente.
La tabla de encaminamiento se aplica en orden, de arriba hacia abajo. A pesar de que el
paquete es reenviado a IPnext, la IP de destino (en adelante IPdest) que aparece en el datagrama
recibido no se modifica, pues para que el paquete llegue a su destino se usarı́a el nivel de enlace,
es decir, la MAC de destino (MACdest) sı́ cambia, la IPdest no.
La última entrada de todas debe ser la salida por defecto (Gateway). Tanto su máscara
como su DirRed son 0.0.0.0, eso garantiza coincidencia con cualquier IP de destino. Todos los
paquetes que no hayan encontrado coincidencia antes, coincidirán con la entrada por defecto.
El algoritmo que usan los routers se muestra en la figura 4.6.
A continuación vamos a ver un ejemplo de tablas de encaminamiento. Tenemos una red con
la topologı́a que muestra la figura 4.7.
En ella, tabla de encaminamiento de A tendrı́a el aspecto que se muestra en la figura 4.4.

193.0.0.0 255.255.255.192 0 - 1
193.0.0.64 255.255.255.192 0 - 2
193.0.0.128 255.255.255.192 0 - 3
193.0.0.192 255.255.255.192 0 - 4
DirRedZ MaskZ 1 IP.D.1 5
DirRedX MaskX 0 - 5
DirRedY MaskY 1 IP.B.1 5
0.0.0.0 0.0.0.0 1 IP.B.1 5
A la hora de ordenar la tabla hemos supuesto que la máscara de la red del router A tiene
una longitud mayor que la de Z, a su vez mayor que la de X y esta que la de Y:
26 > Long(M askZ) > Long(M askX) > Long(M askY ) (4.2)
La tabla de encaminamiento de B quedarı́a como se indica en la figura 4.4.

193.0.0.0 255.255.255.0 1 IP.A.5 1
DirRedX MaskX 0 - 1
DirRedY MaskY 0 - 2
0.0.0.0 0.0.0.0 1 IP.C.1 2
Aquı́ se observa el detalle de que hemos agrupado las 4 LANs que empiezan por 193.0.0.*
en una sola, haciendo la máscara lo suficientemente grande. Esto es posible gracias a que todos
los paquetes que son enviados al cualquiera de esas LANs es enviado al router A.
Por supuesto que la suposición de los tamaños de las máscaras de redes anterior quedarı́a
ahora ası́:
24 > Long(M askZ) > Long(M askX) > Long(M askY ) (4.3)
Y para el router C, se muestra en la figura 4.4.

193.0.0.0 255.255.255.0 2 IP.B.2 1
DirRedZ MaskZ 2 IP.B.2 1
DirRedX MaskX 1 IP.B.2 1
... ... ... ... ...
Los puntos suspensivos de la última fila representan las restantes entradas, correspondientes
a las restantes redes también conectadas a C.
Puntos importantes a tener en cuenta son los siguientes:
Las entradas deben estar ordenadas de mayor a menor longitud de máscara para optimizar
el funcionamiento del router.
Direcciones contiguas pueden ser agrupadas, en ocasiones.
La IP del siguiente nodo (IPnext) debe ser accesible directamente.
Supongamos que realizamos el siguiente cambio en la topologı́a de la red, mediante el cual

193.0.0.192/26 cuelga ahora de D y no de A como se muestra en la figura 4.8.
La nueva tabla de A se puede apreciar en la tabla 4.4.

193.0.0.0 255.255.255.192 0 - 1
193.0.0.64 255.255.255.192 0 - 2
193.0.0.128 255.255.255.192 0 - 3
193.0.0.192 255.255.255.192 1 IP.D.1 5
DirRedX MaskX 0 - 5
DirRedY MaskY 1 IP.B.1 5
0.0.0.0 0.0.0.0 1 IP.B.1 5
Para el router B los cambios son mucho más traumáticos. En principio ya no se podrı́an
agrupar las LANs 193.0.0.* sino que habrı́a que subdividirlas de la forma que se indica en la
tabla 4.4.

193.0.0.192 255.255.255.192 1 IP.D.1 1
193.0.0.128 255.255.255.192 1 IP.A.5 1
193.0.0.0 255.255.255.128 1 IP.A.5 1
DirRedX MaskX 0 - 1
DirRedY MaskY 0 - 2
0.0.0.0 0.0.0.0 1 IP.C.1 2
Donde hemos agrupado las redes 193.0.0.0/26 y 193.0.0.64/26 en 193.0.0.0/25. Sin embargo
la red 193.0.0.128/26 debe ir separada.
Hay un truco para evitarnos esto y consiste en aprovechar que las entradas se comprueban
en orden. Si la entrada correspondiente a la red 193.0.0.192/26 estuviese justo encima de la
correspondiente a 193.0.0.0/24 todo funcionará correctamente. Ası́ todos los paquetes con destino
a 193.0.0.192/26 coincidirı́an con la primera entrada mientras que los que no serı́an procesados
normalmente justo como estaba antes. Se ilustra en la tabla 4.4.

193.0.0.192 255.255.255.192 1 IP.D.1 1
193.0.0.0 255.255.255.0 1 IP.A.5 1
DirRedX MaskX 0 - 1
DirRedY MaskY 0 - 2
0.0.0.0 0.0.0.0 1 IP.C.1 2
La tabla de C no se verı́a afectada por este cambio de topologı́a dado que todos los paquetes
destinados a 193.0.0.0/24 siguen siendo enviados a IP.B.2.
Figura 4.6: Algoritmo de un router

Figura 4.7: Ejemplo de tablas de encaminamiento
Figura 4.8: Modificación del ejemplo de tablas de encainamiento

Capı́tulo 5
Encaminamiento
5.1. Tipos de direcciones

Se denomina encaminamiento al conjunto de procedimientos que permiten establecer las
rutas óptimas. Es la función básica del nivel de red.
Se puede dividir en tres partes o funciones:
Establecimiento de vecindades: Se trata de encontrar información de los nodos adyacentes

para comunicarse con ellos.
Distribución de información: La información recibida de los nodos adyacentes es compartida
por todos los nodos.
Cálculo de rutas: Con la información que nos llega de la distribución podemos calcular la
ruta óptima a un destino.
Un encaminador se puede esquematizar como una máquina con la siguiente estructura:
BIE es la Base de Información de Encaminamiento (en inglés RIB, Routing Information

Base), la base de datos que se consulta para decidir y formar la BIR. La información de la
BIE se consigue mediante interacción con el entorno local de cada nodo (cada nodo observa
sus enlaces) y mediante la recepción de información de control procedentes de otros nodos
vecinos que informan del conocimiento que estos nodos tienen sobre el estado de la red.
BIR es la Base de Información de Reenvı́o (en inglés FIB, Forwarding Information Base).
Es la tabla que se consulta para hacer el reenvı́o de los paquetes.
53
Figura 5.1: Esquema de un encaminador.
5.2. Clasificación de mecanismos de encaminamiento

Los mecanismos de encaminamiento se pueden clasificar según el ámbito en:
Encaminamiento fijado en el origen: El origen decide la ruta completa hacia el destino

(por ejemplo, el source routing de IP).
Encaminamiento salto a salto: En cada salto se decide dónde reenviar el paquete. Este
último mecanismo es el que utiliza en el funcionamiento normal de la red.
Si los clasificamos según la capacidad de adaptación tenemos:
Encaminamiento estático: si hay algún cambio en la red, el router no hace ningún

cambio en su configuración. Los encaminadores solamente poseen BIR, no BIE ni módulo
de cálculo de rutas.
Encaminamiento dinámico o adaptativo: la configuración del router cambia a lo largo

del tiempo. Dentro de este tipo de encaminamiento podemos encontrar a su vez distintos
tipos según su organización.
• Aislado: No se tiene en cuenta la información de los otros nodos a la hora de en-

caminar. Tiene un cálculo de rutas muy simple. Ejemplos: Inundación (el paquete
llega al router y se reenvı́a por todas las interfaces excepto por aquella por la que
llegó), Patata Caliente (envı́a el paquete por la primera interfaz disponible, de forma
aleatoria. Los paquetes se pondrı́an a dar vueltas por la red y en algún momento
llegarán a su destino) y reenvı́o por la interfaz menos cargada.
• Centralizado: El cálculo de rutas sólo lo hace el nodo central. Los nodos recogen
la información de sus vecinos y la envı́an al nodo central. Estas rutas son muy con-
sistentes dado que el nodo central conoce perfectamente la estructura completa de la
red y no se producirán bucles, pero el nodo central se convierte en un punto crı́tico
(cuello de botella).
• Distribuido: Son los más utilizados. En este tipo de encaminamiento todos los nodos
son iguales, todos envı́an y reciben información de control y todos calculan, a partir
de su BIE, sus tablas de encaminamiento. La adaptación a cambios es óptima siempre
y cuando éstos sean notificados.
Nos centraremos en el encaminamiento salto a salto dinámico distribuido.
5.3. Jerarquı́a de encaminamiento y direccionamiento

Si tenemos una red que va aumentando de tamaño hace que aumente la dimensión de la
BIE y, por tanto, también de la BIR. Esto supone un mayor consumo de memoria, de CPU y de
ancho de banda para intercambiar información de control. Veamos un ejemplo en la ilustración
6.2:
Figura 5.2: Red sin niveles de jerarquı́a.

La forma de encaminamiento la elegimos nosotros. En este caso la tabla del nodo 1 quedarı́a
de la siguiente forma:
Destino Siguiente nodo

1 1
2 2
3 7
4 7
5 2
6 7
7 7
8 7
9 2
10 2
Cuadro 5.1: Tabla de rutas para la red sin niveles de jerarquı́a
Si jerarquizamos el sistema nombrando los nodos como en la ilustración 6.3, la tabla dismi-
nuye considerablemente de tamaño pero a costa de perder precisión.

11 11
12 12
13 13
14 12
2x 12
3x 13
Cuadro 5.2: Tabla de rutas para la red con niveles de jerarquı́a
Vemos como la nueva tabla tiene aproximadamente la mitad de tamaño que la anterior,
pero el precio que hemos de pagar por ello es que para alcanzar algunos nodos será necesario
realizar más saltos. Por ejemplo, para llegar al nodo 3, el camino antes era 1 → 7 → 6 → 8 → 3,
mientras que ahora se convierte en 1 → 2 → 10 → 5 → 9 → 3, es decir, damos un salto más.
Aún se podrı́a introducir un nivel más de jerarquı́a:
La tabla de encaminamiento quedarı́a ası́:
Figura 5.3: Red con jerarquı́a.
5.4. Establecimiento de vecindades (Neighbour creating)

Los objetivos del establecimiento de vecindades son los siguientes:
Permitir a los sistemas intermedios (SI = router = encaminador) encontrar la dirección de

nivel de red y del nivel de enlace de los nodos adyacentes.
Permitir a los sistemas finales (SF = host = nodo) encontrar los SI adyacentes, distinguir
cuáles son los nodos adyacentes y encontrar la dirección del nivel de enlace de los nodos
adyacentes.
Este establecimiento lo veremos en dos escenarios distintos; en un enlace punto a punto y en una
red de área local (LAN).
5.4.1. Enlace punto a punto

El SI necesita saber la dirección del sistema final de nivel 3.
Figura 5.4: Red con niveles y subniveles de jerarquı́a.
Solución ISO: Dispone de un protocolo denominado ESH (end system hello). Periódica-
mente, el SF envı́a por el enlace un mensaje hello con el cual el SF indica al SI su dirección
de nivel 3.
Solución TCP/IP : No se envı́an mensajes, sino que se utiliza la configuración de los nodos.
Se resuelve a partir de la dirección y de la máscara. En el enlace punto a punto bastarı́a
con una máscara de 30 bits, que nos proporciona un sistema con 4 direcciones: una para
dirección de red, otra para difusión, otra para el SI y otra para el SF.
5.4.2. Red de área local (LAN)

La notación que usaremos en este apartado es la siguiente: SFB3 representa la dirección del
nivel de red (nivel 3) del sistema final B.
Los problemas que debemos de solucionar en este tipo de redes son:

111 111
112 112
113 113
114 112
2xx 112
Cuadro 5.3: Tabla de rutas para la red con varios niveles de jerarquı́a
Figura 5.5: Esquema de un enlace punto a punto.
1. SI : SFA3 SFB3 . El SI debe conocer la dirección de nivel 3 de los sistemas finales A y B.

2. SI : SFA2 SFB2 . El SI debe saber cuál es la dirección de nivel 2 de los sistemas finales A y
B.
2
3. SF : SIX . Cualquier sistema final debe conocer la dirección de nivel 2 del sistema inter-
medio al que está conectado.
4. SF A → SF B, SF A : SF 2 B. A quiere enviar algo a B. Como están unidos fı́sicamente en
una LAN no hace falta que pase por ningún SI, pero A necesita conocer la dirección de
nivel de enlace de B. Si por desconocimiento o error A enviara el mensaje a un SI, debe
existir alguna forma para que el SI le comunique a A que B está accesible a través del nivel
de enlace.
5. SF A → SIB → SF C. Encaminar los mensajes de A a C a través del SIB.
6. Suponemos que no hay SI. SF A → SF B, SF A : SFB2 . Si no hay SI y A quiere enviar un
mensaje a B, A necesita conocer la dirección de nivel de enlace de B.
Solución ISO
Existen 3 tipos de mensajes:

Figura 5.6: Ejemplo de una LAN.
ESH (Hola del SF): Los sistemas finales envı́an este mensaje a una dirección destino de
grupo que la escuchan todos los SI.
ISH (Hola del SI): El SI envı́a este mensaje por todas sus interfaces a todos los sistemas
finales con los que esté conectados directamente.
Redirección: Es un mensaje en el cual el SI especifica al SF por dónde debe enviar los men-
sajes a un destino determinado. Por ejemplo cuando un SI recibe un paquete y lo reenvı́a
por la misma interfaz que la recibió, envı́a un mensaje al que lo envió para informarle de
que ese destinatario está visible directamente. Lo vemos en estas ilustraciones.
Otro ejemplo de redirección es el siguiente:

Con esto SFA conoce el par de direcciones de nivel 3 y nivel 2 necesarias (SFC3 − SIB2 ) para
alcanzar a SFC .
Por tanto, los mensajes de ESH e ISH permitirán la solución de:
ESH: soluciona los problemas 1 y 2 al tener dirección de nivel 2 y 3 de SF.
ISH: soluciona el problema 3 al tener dirección de nivel 2 y 3 de SI.

Figura 5.7: SFA le quiere enviar un mensaje a SFB . B se encuentra directamente accesible por
el nivel de enlace, pero A no lo sabe. A envı́a el mensaje destinado a B al SI.
Veamos el comportamiento de los SF ante los problemas que nos quedan (los problemas 4, 5 y
6). Para ello estudiamos el algoritmo de los SF:
Envı́o periódico de ESH a todos los SI

Envı́o directo de ESH a los SF
Caché de SI (CSI): Almacena la relación dirección de nivel 3 - dirección de nivel 2 de los
sistemas intermedios.
SI13 SI12
SI23 SI22
Caché Destino (CD): Esta tabla contiene una relación entre la dirección de nivel 3 destino
y la dirección nivel 2 que debemos poner en el mensaje para que alcance dicho destino.
Almacena tanto mensajes de redirección como ESH.
Mensajes de redirección SFX3 SYZ2

Hola de SF directo (ESH) SFX3 SYK2
SYZ2 = SIZ2 ó SFZ2

Donde SFX3 representa la dirección de nivel de red del destino final de nuestro paquete, y
SYZ2 y SYK2 serı́an la dirección de nivel de enlace del primer nodo al que hemos de mandar
el paquete para que llegue al destinatario (SY puede ser tanto un SF como un SI).
Figura 5.8: El SI lee el mensaje entrante y lo reenvı́a a su destino, B. Pero, además, el SI se da

cuenta de que para reenviarlo ha tenido que usar el mismo enlace por el que le llegó. Por tanto,
le dice a A que los siguientes paquetes con destino a B los debe enviar a la dirección de nivel de
enlace de B, no a la del SI.
Estas tablas tienen asignados unos temporizadores de envejecimiento, es decir, si vence el

temporizador sin haberse refrescado el registro, éste se borrará.
El algoritmo seguirá los siguientes pasos cuando un SF quiera transmitir un paquete a un
destino identificado por su dirección de nivel 3 (D3 ):
1. BuscaD3 en la caché destino (CD) Si la encuentra, se lo envı́a (D3 , X 2 )
2. Si no Busca en CSI una entrada cualquiera y se lo envı́a (D3 , SIX

2
)
3. Si la CSI está vacı́a, envı́a un mensaje de difusión dentro de su LAN, ya que es el alcance
que tienen las direcciones de nivel de enlace (D3, ∨SF 2 )
Veamos como se solucionarı́an los problemas que nos quedan:

Supondremos que las cachés están vacı́as.
1. Si el SFA quiere enviar algo a SFD y SFA sólo sabe SFD3 , aplica el algoritmo de los SF.
Como las cachés se encuentran vacı́as se envı́a un mensaje de difusión dentro de su LAN,
rellenando la tabla de CSI de SFA con las direcciones de nivel de enlace SIA2 y SIB2 . El
mensaje sale a través de alguno de estos sistemas intermedios.
Figura 5.9: SFA quiere enviar algo a SFC . A no sabe donde está C, ası́ que envı́a el paquete a
un SI aleatoriamente. En este caso, lo envı́a al SIA .
2. Si SFA desea enviar algo a SFC , el mensaje tendrá como dirección de red la dirección
destino de SFC y como dirección de enlace la dirección de nivel 2 de SIA o de SIB .
N red N enlace datos

SFC3 SIA2 ...
Si ha sido enviado a través del SIA ,SIA lo reenvı́a a SIB por la misma interfaz y avisarı́a
a SFA , mediante un mensaje de redirección, de que el destino está alcanzable a través de
SIB (se vio en uno de los ejemplos de redirección). Esta información la almacenarı́a SFA
en su caché de destinos (CD) de la siguiente forma:
SFC3 SIB2
3. Si SFA desea enviar algo a SFB en principio lo harı́a a través de SIA . Como este sistema
intermedio tiene que reenviar el mensaje por la misma interfaz por la que lo recibió, enviarı́a
un mensaje de redirección a SFA para comunicarle que SFB está accesible directamente
(se vio en uno de los ejemplos de redirección). Esta información la almacena SFA en su
caché de destino por lo que la CD de SFA quedarı́a ası́:
SFC3 SIB2
SFB3 SFB2
Figura 5.10: El SIA consulta su tabla de encaminamiento y ve que para enviar un paquete a
C ha de pasar por SIB . Por tanto, reenvı́a el paquete a SIB . Pero SIA se da cuenta de que al
reenviar el paquete ha usado el mismo interfaz por el que lo recibió, ası́ que comunica a SF A
que, cuando tenga que enviar un paquete a SFC , lo tiene que mandar a la dirección de enlace
de SIB .
4. Si caen los SI, desués de un cierto tiempo se borrarı́a la caché de CSI y CD. Si ahora SFA
quiere enviarle algo a SFB y suponiendo que los SI están caı́dos y las tablas borradas, SFA
enviarı́a un mensaje de difusión tal que ası́:
N red N enlace datos

SFB3 ∀SFB2 ...
El SFB contestarı́a a SFA con un mensaje ESH directo indicándole en este su dirección
de nivel de enlace. SFA lo almacena en su caché de destinos y ya podrı́an compartir
información.
Solución TCP/IP
En esta arquitectura cada host conoce su IP, su máscara y la IP del router por defecto.
Para traducir las direcciones IP en direcciones de nivel de enlace (dirección MAC), TCP/IP
cuenta con el protocolo ARP (Address Resolution Protocol, RFC 826). Si un sistema quiere
encontrar la dirección de nivel de red que pertenece a una determinada IP, este envı́a un paquete
(ARP REQUEST) a la dirección de difusión de la red en el que se indica la IP por la que se
Figura 5.11: Ejemplo de una LAN
pregunta. La máquina implicada, si existe, responde con otro mensaje (ARP RESPONSE) donde
le indica su dirección MAC.
El protocolo ICMP (Internet Control Message Protocol, RFC 792) permite enviar mensaje
de redirección. En este protocolo se encapsulan en el mismo mensaje dos direcciones IP, es decir,
dos direcciones de nivel de red, no una de red y otra de enlace como en casos anteriores. Esta
diferencia con respecto a los mensajes de reencaminamiento de ISO se explicará detenidamente
más adelante con un ejemplo.
Veamos como soluciona TCP/IP los mismos problemas anteriores:
1. SI : SFA3 SFB3 . El SI debe conocer la dirección de nivel 3 de los sistemas finales A y B.
2. SI : SFA2 SFB2 . El SI debe saber cuál es la dirección de nivel 2 de los sistemas finales A y
B.
2
3. SF : SIX . Cualquier sistema final debe conocer la dirección de nivel 2 del sistema inter-
medio al que está conectado.
4. SFA → SFB , SFA : SF 2 B . A quiere enviar algo a B. Como están unidos fı́sicamente en
una LAN no hace falta que pase por ningún SI, pero A necesita conocer la dirección de
nivel de enlace de B. Si por desconocimiento o error A enviara el mensaje a un SI, debe
existir alguna forma para que el SI le comunique a A que B está accesible a través del nivel
de enlace.
5. SFA → SIB → SFC . Encaminar los mensajes de A a C a través del SIB.
6. Suponemos que no hay SI. SFA → SFB , SFA : SFB2 . Si no hay SI y A quiere enviar un
mensaje a B, A necesita conocer la dirección de nivel de enlace de B.
El problema 1 se puede solucionar con el uso de la máscara. Dado que cada enlace del SI
tendrá asignadas una IP y una máscara, yo se todas las direcciones posibles de nivel de red de
cada enlace. Los problemas 2, 4 y 6 se pueden resolver haciendo uso del protocolo ARP.
Ejemplo: Si A y B son dos sistemas finales dentro de una misma LAN y A quiere conocer
la dirección de nivel de enlace de B, A enviarı́a un mensaje de difusión ARP REQUEST con la
dirección IP de B. B contestarı́a con un mensaje directo ARP RESPONSE en el que le indica
a A su dirección de nivel de enlace. En la caché de A se almacenarı́a la IP y la MAC de B,
mientras que en la caché de B se guarda la IP y la MAC de A.
En el problema 3, el sistema final quiere conocer la dirección de nivel de enlace del router.
Por configuración los hosts saben su IP, su máscara y la dirección IP del router por defecto.
Usando ARP conseguirá la direccion de nivel de enlace del router. Para ello la dirección IP debe
ser accesible directamente (al multiplicar bit a bit la máscara con la IP propia y del router debe
salir el mismo resultado).
En el problema 5 se trata de averiguar qué router es mejor para llegar a un determinado
destino. Si nos acordamos del ejemplo en que SFA quiere enviar algo a SFC , el SIA debe enviar
un mensaje de redirección a SFA para que lo que envı́e a SFC lo haga a través de SIB . En
TCP/IP contamos con ICMP para enviar los mensajes de redirección. En este caso, el mensaje
de redirección que SIA envı́a a SF A contiene una pareja de IPs (IPSFC , IPSIB ), es decir, dos
direcciones de nivel de red en vez de una dirección de nivel de red y una de nivel de enlace como
hacı́a la norma ISO. El SFA es el que se encarga de traducir la dirección IP del SIB (SI 3 B ) a la
dirección de nivel de enlace del SIB .
Otros protocolos relacionados con ARP son:
RARP (ARP reverse RFC 903): Sirve para averiguar una dirección IP a partir de una
dirección de enlace. Se usa en maquinas que no tienen unidad de almacenamiento (tienen
MAC pero no tienen IP).
BOOTP (RFC 951): Al arrancar enviamos por difusión nuestra dirección MAC, consi-
guiendo de un servidor BOOTP la IP. También permite conocer la dirección de un servidor
de ficheros y una lista de ficheros a descargar (útil si se quiere que al arrancar la máquina
se instale un sistema operativo desde un servidor de ficheros, por ejemplo).
DHCP (RFC 2131): Es una evolución del BOOTP, que además de lo que éste proporcio-
naba da más información (como la dirección del servidor DNS, la del router por defecto...).
Se puede usar cuando tenemos más máquinas que IPs disponibles, ya que las IPs se asig-
nan dinámicamente cuando la máquina lo requiere. Dichas IPs pueden tener un tiempo de
asignación limitado, de modo que pasado ese tiempo caducan y es necesario solicitar otra
dirección.
InARP (RFC 2390): Inverse ARP. Cuando se tiene una conexión punto a punto te permite
averiguar la IP del otro extremo.
5.5. PROXY ARP

Es un mecanismo que permite tener niveles de enlace separados por un router que ejecute
PROXY ARP. Su objetivo es simular que todos esos enlaces pertenecen a una única red. Para
ello, el router responderá a paquetes ARP dirigidos a destinos situados al otro lado del router,
simulando ası́ que dichos destinos son accesibles directamente. Se verá más claro con un ejemplo:
Figura 5.12: Ejemplo de PROXY ARP
Supongamos que el equipo C quiere enviar al equipo A un paquete y que ambos están
separados por un router con Proxy ARP (en este caso, el router R está haciendo Proxy ARP de
A y B por R1 ). Lo primero que hará C será enviar un paquete ARP a su red local preguntando
por la MAC del equipo A. Este paquete no llega a A, sino que es el router quien responde con
su MAC haciéndose pasar por A. Cuando C envı́a el paquete, lo envı́a con la MAC del router y
Figura 5.13: Ejemplo de PROXY ARP
la IP de A. El paquete llega al router, y éste averigua cual es la dirección de enlace verdadera

de A y lo enruta hacia allı́. De esta forma el paquete llega a su destino y las máquinas C, D y
E ven a A y B directamente accesibles.
Una aclaración: en el ejemplo anterior hemos supuesto que las cachés ARP de todos los
equipos están vacı́as. Es por ello por lo que es necesario enviar mensajes ARP para averiguar las
direcciones de nivel de enlace. Para paquetes posteriores, simplemente se enviarı́an datos a las
direcciones que ya conocemos.
Nótese que no serı́a necesario hacer Proxy ARP de C, D y E por R2. Para que las máquinas
A y B puedan comunicarse sin problemas con el resto de su red, sólo es necesario poner como
router por defecto al router R. Esto no serı́a posible en la zona de la derecha, ya que el router
por defecto es el que da acceso al exterior, el gateway.
La ventaja del Proxy ARP es la sencillez. Una red puede extenderse usando esta técnica sin
que lo sepa el router de salida al exterior de la red. Esta técnica se emplea en redes virtuales para
simular que los equipos están conectados de forma local. Entre las desventajas del Proxy ARP
están la escalabilidad (ya que se requiere una resolución ARP para cada dispositivo enrutado de
esta forma) y la fiabilidad, pudiendo ocasionar problemas si existe algún software anti-intrusos.
El software detectarı́a que una misma MAC responde a varias IPs distintas, y podrı́a pensar que
se trata de un intruso realizando suplantación de identidad (spoofing).
Problema: Suponer que las tablas ARP están vacı́as. Dibujar los mensajes que se envı́an
cuando B quiere enviar un datagrama a A. Dibujar también los datagramas que se envı́an cuando
A envı́a un datagrama a B. Representar los mensajes con la siguiente notación: TIPO(D3 ,D2)
Figura 5.14: Problema de PROXY APRP
R1=172.16.0.1/24
R2=172.16.1.121/16, hace Proxy ARP de A y B
B=172.16.1.120/16. Su router por defecto es Gateway.
A=172.16.0.2/24. Su router por defecto es R.
5.6. Cálculo de rutas
5.6.1. Introducción
El cálculo de rutas se define como el cálculo del mejor camino suponiendo que ya tenemos
información de la red. El primer objetivo de este mecanismo es obtener una función a optimizar:
función de optimización. A los parámetros de esta función se les denominan métricas.
El método consistirá en máximizar o minimizar esas métricas según convenga (por ejemplo,
si la variable que estamos manejando es el retardo, convendrá minimizarla. Si se trata de los
beneficios obtenidos, interesará maximizarla).
Las métricas pueden ser de 2 tipos:
GLOBALES: Miden una cualidad de la red completa. Algunos ejemplos son:
• Saturación máxima: se mide en cada nodo. Para nuestra ruta habrı́a que ver en
qué nodo se da la saturación máxima.
• Retardo global medio: Se trata del retardo de cada enlace ponderado por el número
de paquetes que lo atraviesa.
LOCALES: A cada enlace se le asigna un valor. Ahora a cada camino (sucesión de enlaces)
se le asigna otro valor en función del valor añadido de los enlaces. La función óptima
será los caminos que maximicen o minimicen el valor anterior. Dentro de las métricas
locales, podemos clasificarlas en:
• ADITIVAS: Su función óptima depende de la suma del valor asociado a cada enlace
en el camino. P.ej. Número de saltos, retardo medio en el camino.
• CÓNCAVAS: Su función óptima depende del mı́nimo del valor asociado a cada enlace
en el camino. P.ej. Capacidad del enlace, MTU (Unidad Máxima de Transmisión, nos
da información acerca del tamaño máximo de la SDU (Unidad de Datos del Servicio)).
• MULTIPLICATIVAS: Su función óptima depende del producto del valor asociado a
cada enlace en el camino. P.ej. Probabilidad de error.
5.6.2. Algoritmo del camino más corto

Es un mecanismo que emplea métricas locales aditivas. El valor de cada enlace se le llama
coste, longitud o peso. Este algoritmo nace debido al carácter dinámico del coste de los enlaces.
Dicho coste puede cambiar constantemente (por ejemplo, si consideramos el coste como el retardo
de los paquetes o la saturación del enlace) y provocar oscilaciones.
El objetivo de este algoritmo es obtener al árbol de expansión de distancia mı́nima a un
nodo concreto, esto es, el conjunto de enlaces con los caminos más cortos de todos los nodos al
nodo destino. Se le llama árbol porque no se forman bucles y se le dice de expansión porque
contiene todos los nodos de la red.
Vamos a estudiar 2 tipos de algoritmos del camino más corto: el algoritmo de Bellman- Ford
y el algoritmo de Dijkstra.
Figura 5.15: Ejemplo de red.
Figura 5.16: Árbol de expansión de distancia mı́nima a A.
Algoritmo de Bellman-Ford
Obtiene la distancia mı́nima de todos los nodos a un nodo destino (al que denominamos
nodo 1). Usaremos la siguiente notación:
Din = Distancia mı́nima del nodo i al nodo 1 a través de caminos de n saltos o menos.
Definimos:
Din = 0∀n
Di0 = ∞∀i 6= 1
Din+1 = mı́nj∈N (i) [dij + Djn ], donde dij =coste, longitud o peso del enlace entre i y j (si no
hay, se considera infinito) y N(i) es el conjunto de nodos adyacentes a i.
Cuando se alcanza Din+1 = Din ∀i , se dice que se ha encontrado el camino más corto.
Esta representación gráfica equivale a la siguiente tabla de costes:
Figura 5.17: Ejemplo para el algoritmo de Bellman-Ford.
dij 1 2 3 4 5
1 0 ∞ ∞ ∞ ∞
2 1 0 2 ∞ ∞
3 ∞ 8 ∞ 0 4
4 ∞ 8 ∞ 0 4
5 ∞ ∞ 2 2 0
Calculamos las distancias mı́nimas al nodo 1, considerando que el número máximo de saltos
que se pueden dar es 1:
D21 = min(d21 + D01 ; d23 + D03 ; ...) = 1
D31 = 4
D41 = ∞
D51 = ∞
Ahora repetimos los cálculos, considerando que el máximo número de saltos es 2, después 3...
ası́ hasta que en una de las iteraciones los resultados no cambien respecto a la iteración anterior
(por ejemplo, en nuestro caso la distancia permitiendo 5 saltos es igual que si permitimos 4). Si
realizamos todas las combinaciones posibles resulta la siguiente tabla:
Din D1 D2 D3 D4 D5
0 0 ∞ ∞ ∞ ∞
1 0 1 4 ∞ ∞
2 0 1 2 9 6
3 0 1 2 9 4
4 0 1 2 8 4
5 0 1 2 8 4
Existe una variante, el algoritmo de Bellman-Ford distribuido ası́ncrono, que comienza con:
D1 = 0
Di = ∞∀i 6= j
Cada nodo envı́a a sus vecinos los Di obtenidos y recibe de sus vecinos los Dj obtenidos por
ellos mediante la ecuación de Bellman-Ford (Di = min(dij + Dj )). Entonces, el nodo i calcula
Di = minj∈N (i) (dij + Dj ), donde N(i) representa los nodos adyacentes a i. Es decir, cada nodo
calcula la distancia mı́nima a los nodos de la red a partir de la información que recibe de sus
vecinos. El proceso se repite de forma iterativa, y al final converge en el camino más corto,
donde se tendrá la distancia mı́nima. Este algoritmo presenta la ventaja de que sólo es necesario
conocer de antemano a los nodos vecinos al nuestro, no a toda la red como ocurrı́a con el
algoritmo Bellman-Ford. Sin embargo, es un algoritmo en el que la convergencia se produce de
forma muy lenta.
Algoritmo de Dijkstra
Obtiene la distancia mı́nima de todos los nodos con el nodo 1. La notación que se usa es:
Di = Estimación de la distancia mı́nima al nodo 1. A esto lo llamaremos etiqueta.
P = Conjunto de nodos cuya etiqueta no es una estimación de la distancia, sino que es la
distancia real. En cada iteración del algoritmo conseguiremos que más estimaciones se vayan
haciendo permanentes, por lo que P se irá incrementando hasta contener a todos los nodos de
la red.
Las suposiciones iniciales del algoritmo son:
D1 = 0. Es una etiqueta permanente (ya que sabemos con seguridad que la distancia del
nodo 1 al nodo 1 es siempre 0)
P = 1. Es el conjunto de distancias que sabemos con seguridad que son ciertas. Nótese co-
mo, inicialmente, sabemos que la distancia del nodo 1 al nodo 1 es cero, pero no conocemos
ninguna otra distancia.
Dj = dij ∀j 6= i. Esto es, inicialmente se considera que la distancia del nodo 1 al nodo j es
el coste del enlace que los une, si existiera. Si no existe, vale infinito.
El algoritmo iterativo es el siguiente:
1. Encontrar i ∈/ P : Di = mini∈P/ Dj , es decir, de todos los nodos buscamos aquel que tenga
la etiqueta tentativa mı́nima (lo llamaremos nodo i) y lo añadimos al conjunto P. Una vez
que lo añadimos al conjunto P, su etiqueta se vuelve permanente (no cambia).
2. P = P ∪ i, esto es, añadimos el nodo que acabamos de conseguir al conjunto P.
3. Si P contiene a todos los nodos, finaliza el algoritmo.
4. Recalcular las etiquetas tentativas de la siguiente forma: ∀j ∈ / P , Dj = min(Dj ; dij + Di ).

Esto equivale a comparar la distancia que ya tenı́a de la iteración anterior a la que obtengo
ahora si en lugar del camino escogido anteriormente, escojo el camino que atraviesa el nodo
i. En realidad, sólo hay que calcular la de los vecinos al nodo añadido a P, porque los otros
no variarán.
5. Volver a 1.
Veamos el ejemplo anterior usando el algoritmo de Dijkstra:

Como era de esperar, con este método se obtienen los mismos resultados que conseguimos
con el algoritmo de Bellman-Ford. Existe la posibilidad de que los dos algoritmos den resultados
diferentes, pero ésto sólo ocurre si hay más de un camino mı́nimo al nodo 1.
Ejercicio: Calcular el camino más corto de todos los nodos al nodo C, usando ambos algo-
ritmos
5.7. Distribución de la información

Vamos a ver dos tipos de algoritmos para la distribución de información: los algoritmos
basados en el vector de distancias y los algoritmos basados en el estado de los enlaces.
Figura 5.18: Ejemplo para el algoritmo de Dijkstra.
5.7.1. Vector de distancias

Consiste en la aplicación del algoritmo de Bellman-Ford distribuido ası́ncrono aplicado a
todos los nodos y no a uno sólo como se hizo anteriormente.
Con este algoritmo se siguen estos pasos:
Cada nodo conoce su identificador.
Cada nodo conoce el coste de sus enlaces: Estado de las vecindades
Cada nodo comienza con un vector VDi=(∞, ∞, ∞, ...∞,0 (en la posición i),∞,...,∞) se
denomina vector distancia del nodo i. Este vector tendrá en cuenta todos los nodos de la
red.
Cada nodo transmite su vector distancia V Di a sus vecinos. Se transmite: o periódicamente

o cuando cambia el V Di o cuando se activa un enlace Lo que realmente se transmite es una
lista de duplas del tipo < nodo, distancia >: V Di = {< id, distancia>,..., < i, 0 >,..., < id,
distancia>}. Para disminuir el ancho de banda gastado, aquellas duplas cuya distancias
sean ∞ no se envı́an, por lo que el otro extremo las supone. El primer V Di , por tanto,
será V Di ={ <i, 0> } · Cada nodo almacena una copia del vector distancia más reciente
que haya recibido para cada enlace.
Cada nodo calcula V Di minimizando dij + Dj para cada elemento del vector, y teniendo
en cuenta todos los enlaces que posee. ·
Figura 5.19: Ejemplo para el algoritmo de Dijkstra.
Se recalcula V Di si:
• Se recibe V Di distinto del almacenado.

• Cae el enlace a j, entonces se descarta la información que se posea de j y se recalcula
el V Di completo.
• Cambia el coste de un enlace.
Presenta una ventaja, la comunicación se da entre nodos adyacentes por lo que sólo es
necesario emplear el nivel de enlace. Se envı́a mucha información, pero a pocos equipos. El
problema que presenta, dado que se basa en el algoritmo Bellman-Ford distribuido ası́ncrono, es
que la convergencia puede ser lenta. Veámoslo con un ejemplo:
En esta situación los vectores de distancias convergen a esta situación:
A B C
Dist. a A 0 1 2
Dist. a B 1 0 1
Dist. a C 2 1 0
Figura 5.20: Ejercicio para la aplicación de ambos algoritmos.
Figura 5.21: Ejemplo de lentitud en convergencia.
Los vectores que cada nodo tiene almacenados por cada interfaz serı́an:
A BA BC C
1 0 2 1
0 1 1 0
1 2 0 1
Figura 5.22: Ejemplo.
Si cae el enlace B-C, desechamos el vector de B (1 0 1) y el que tiene almacenado en la

interfaz con C (2 1 0). B recalcula su vector y le da (1 0 3) ya que cree que por el camino de
la izquierda, C está accesible en 2 saltos más el salto de B a A. Como ha cambiado su vector se
lo envı́a a A. A calcuları́a su vector y le darı́a (0 1 4), que enviarı́a a B. B recalcula y obtiene
(1 0 5). Esto provoca un cı́rculo vicioso que hace que la distancia a C crezca. Para solucionarlo,
cuando se rebase un valor lı́mite se considera el enlace caı́do y C inaccesible.
A medida que la red aumenta de tamaño, la convergencia se complica.
5.7.2. Estados de los enlaces

La información que se envı́a es la distancia a los vecinos. Esta información se la mandamos
a todos los nodos de la red, por lo que cada nodo puede conseguirse su propio mapa de la red.
Se maneja menos información, pero se envı́a a más destinos. Los pasos que sigue son:
Cada nodo (SI) sabe su identificador y el de sus vecinos.
Cada nodo construye LSP (Link State Packet, paquete de estado de los enlaces) que con-
tiene la lista de coste e identificador de los vecinos. LSP={<id, coste>, <id, coste>, ...}
Los LSP se envı́an a todos los sistemas intermedios de la red.
Cada SI crearı́a un mapa completo y harı́a el cálculo de rutas (p.e. con Dijkstra)
Los paquetes LSP se construyen y se envı́an:
periódicamente.
cuando aparece un nuevo vecino.
cuando cambia el coste del enlace.
cuando cae un enlace.
Los inconvenientes de este método son los siguientes: si no conseguimos que los paquetes LSP
les lleguen a todos los nodos de la red se pueden producir bucles. También puede que se gasten
muchos recursos con el envı́o de LSP.
Para que los LSP lleguen a todos los nodos no podemos basarnos en encaminamiento porque
todavı́a no lo tenemos (recordemos que la fase en la que estamos actualmente, la distribución de
información, es previa al encaminamiento). Se usa el método de inundación que puede hacer
que se llene la red de LSP. El mecanismo para controlar la cantidad de LSP es que el nodo se
quede con los más recientes o usar numeración. La solución pasa por un esquema que mezcla la
numeración y el tiempo. Como método básico se usa la numeración. A cada paquete se le asocia
un número de secuencia y además se le indicará la edad (contador que se va decrementando
con el tiempo y en cada salto) como mecanismo de autodestrucción, esto es, cuando se alcance
edad=0 se rechaza el paquete. El LSP contendrá por tanto: origen, SN (número de secuencia),
edad y datos. No lleva destino porque está dirigido a todos los routers de la red.
Si el LSP que le llega a un nodo tiene un número de secuencia mayor que el almacenado,
guardamos la información y lo reemitimos decrementando la edad. Cuando se almacena también
va decrementando su edad con el transcurso del tiempo y normalmente no llegará a cero. Si llega
un LSP con el SN menor del que tenemos almacenado se descarta.
El problema que se plantea ahora es la sincronización del reloj con los demás.
Figura 5.23: Recepción del paquete.
LSP/enlace 1 2 3
[h] origen=R5 envı́o LSP 1 1 0
SN=17 envı́o ACK 0 0 1
ALGORITMO:
1. Al inicio la tabla está vacı́a. Supondremos que los mensajes recibidos tendrán EDAD6= 0.
2. Periódicamente se recorre la tabla. Para cada enlace, si envı́o LSP vale 1, se envı́a el LSP
correspondiente y se mantiene envı́o LSP a 1. Si envı́o ACK vale 1, envı́a ACK y se le asigna
el valor 0 a envı́o ACK. El razonamiento que lleva a este comportamiento es el siguiente:
manteniendo envı́o LSP a 1 me aseguro de que el paquete llegará a su destino, ya que
lo estaré retransmitiendo hasta que me llegue confirmación de su llegada. Sin embargo el
ACK sólo lo envı́o una vez, ya que, si se perdiera el paquete, el LSP correspondiente me
serı́a reenviado por el emisor original y yo volverı́a a confirmarlo.
3. Si recibe un LSP por enlace j: Si es nuevo (de otro enlace que no tenı́a) o es más reciente
(de un origen que ya tenı́a pero con un SN mayor) se realiza lo siguiente:
Figura 5.24: Reenvı́o del paquete.
Se decrementa la edad en 1 unidad.

Se almacena en memoria
Para todo enlace distinto de j se pone envı́o LSP=1 y envı́o ACK=0, y para el enlace
j se pone envı́o LSP=0 y envı́o ACK=1.
4. Si recibe LSP por enlace j duplicado (es decir, coincide el SN y el origen con el de alguno
de los LSP que tenemos almacenados en la tabla, pero me llega por un enlace distinto que
aquél por el que recibı́ el que tengo en memoria): Para el enlace j se pone envı́o LSP a 0 y
envı́o ACK a 1.
Esto se hace para evitar bucles en los que una serie de nodos se envı́en información que ya
tienen. Podemos ver un ejemplo en el siguiente dibujo:
En este caso, C envı́a el mismo LSP a A y B. Supongamos que, por cualquier razón, B
reenvı́a el LSP más rápido que A. A A le llegarı́a un LSP por A-B que ya le habı́a llegado
por el enlace A-C, luego pone envı́o LSP a 0 en el enlace AB (para no enviarle a B un LSP
que ya tiene) y envı́o ACK del enlace A-B a 1. Ası́, le envı́a un ACK a B para que no le
siga retransmitiendo el LSP.
5. Si se recibe un ACK por el enlace j de un nodo que ya está en memoria. Se pondrı́a para
ese enlace j el valor envı́o LSP a 0 y envı́o ACK a 0. Poner envı́o ACK a 0 puede parecer
un poco extraño, pero si analizamos la situación es fácil entender el por qué. Al haber
recibido un ACK de otro nodo, forzosamente el nodo que te ha enviado el ACK tiene que
Figura 5.25: Ejemplo de envı́o de LSPs.
haber puesto envı́o LSP a 0 en el enlace. Entonces, enviarle un ACK no tiene sentido, ya
que el único uso del ACK es forzar al otro extremo a poner envı́o LSP a 0 en el enlace.
6. Si se recibe algo que no cumple ninguno de los casos anteriores, se rechaza el paquete.
Hasta ahora, siempre hemos considerado que la edad del paquete tenı́a un valor distinto a
0. Veamos la utilidad de este campo: Si tenemos un LSP en memoria y la edad llega a 0:
Descartamos los datos.
Se envı́a a todos los vecinos el LSP con edad 0.
Se espera asentimiento o al temporizador.
Se olvida completamente del origen que envió el LSP que llegó a edad 0.
Si ese origen le manda un nuevo LSP lo trata como si fuese un enlace nuevo.
Cuando alguien recibe un LSP con edad 0 y coincide con el que está en memoria (mismo
SN) responde con un ACK por ese enlace y se reenvı́a por los demás enlaces para informar que
ese nodo no está accesible por ese enlace. Se esperan ACKs hasta que venza el temporizador. Si
vence, nos olvidamos del enlace.
Si se recibe un LSP con edad 0 en el que no se conoce el origen o no coincide con el SN,
el LSP no se propaga para que no se queden viajando por la red y solo se enviarı́a un ACK al
emisor. (Para más información sobre encaminamiento, consultar ”Interconnections”, de Radia
Perlman, Ed Addison-Wesley)
Problema: ¿Cómo se propagarı́an los paquetes LSP cuando cae el enlace A-E si nos centra-
mos únicamente en aquellos cuyo origen es A? ¿Cuántas copias aparecerı́an en total?
Figura 5.26: Ejercicio.
5.7.3. LSP en una LAN
Figura 5.27: Esquema de una LAN con múltiples routers.
En una LAN tenemos un medio compartido que utilizan todos los nodos de la red. Si
intentamos utilizar el algoritmo de los LSP tal y como estaba, cada router verá un enlace virtual
con cada máquina de la red. Esto provoca que todos los routers pertenecientes a la misma LAN
se consideren vecinos entre ellos, como si hubiera una malla de interconexión total uniéndolos.
Cada router tiene que poner el estado del enlace a cada uno de los vecinos, por lo que enviarı́a
un mensaje con tantas parejas enlace-estado como routers haya en la red. Esto multiplicado por
el número de routers lleva a un gran gasto de recursos.
Para solucionarlo, podemos transformar la malla virtual en una conexión en estrella virtual.
Para ello, se selecciona al uno de los routers, al que se llama router designado. Este router, además
de realizar las funciones de router normal, funciona como router designado, es decir, además de
su dirección origen presenta una dirección nueva que no existe fı́sicamente. Al usar un router
designado, no es necesario que cada router envı́e un LSP a cada nodo de la red. Simplemente
enviará un LSP con todas las parejas enlace-coste al router designado, y éste se encargará de
retransmitirlo en difusión.
Nótese que, aunque el paquete a enviar contenga la misma información, al enviarse a muchos
menos destinos se reduce considerablemente el tráfico en la red.
Figura 5.28: LSP que se envı́an en condiciones normales.
Figura 5.29: LSP que se envı́an si se usa router designado (en este caso, se ha designado al router
3.
Por otra parte, en una LAN no se envı́an asentimientos entre los nodos, ya que aumentarı́a
considerablemente el tráfico de la red. Para compensar esto el router designado envı́a un paquete
llamado SNP (resumen de los números de secuencia) a todos los nodos de la LAN. En el SNP
se indican los números de secuencia de los LSP de todos los nodos de la red. Los vecinos lo
comparan con lo que tienen en memoria y sólo en el caso de que no concuerde (SN menor) le
pide que le retransmita el paquete. En caso de que el nodo detecte que su SN es mayor que el del
SNP (significarı́a que se ha perdido un LSP antes de llegar al router designado), el nodo envı́a
el LSP de nuevo.
5.8. Protocolos especı́ficos de encaminamiento

Para describir las redes, se usa un modelo jerárquico basado en dominios. Distinguimos dos
tipos de dominios:
Dominio administrativo: comprende una parte de la red que es administrada por una única
autoridad.
Dominio de encaminamiento: es una parte de un dominio administrativo en la que se sigue

un mismo criterio para el encaminamiento.
Área: es una región de la red en la que se utilizan protocolos intradominio.
Las ventajas de realizar esta división son:
Escalabilidad: recordemos que, al usar vector de distancias, la velocidad de convergencia

decrece rápidamente al aumentar la red. Con la división en dominios reducimos el ámbito
del vector, con lo que conseguimos una convergencia más rápida. Por otra parte, si usamos
LSP será necesario enviar los paquetes en difusión a toda la red. Con redes grandes, el
consumo de recursos puede ser excesivo.
Autonomı́a de gestión: la división permite que los propietarios o gestores sean los adminis-
tradores de la red. Además, se puede decidir qué información se comparte con el exterior
y cuál se mantiene oculta.
Los protocolos de encaminamiento se dividen en dos tipos, según el ámbito:
Intradominio: propaga información dentro de un mismo dominio. Los criterios que se usan
para el encaminamiento son técnicos. Busca optimizar la eficiencia. Algunos son:
• En TCP/IP, se usan RIP (Routing Information Protocol) y OSPF (Open Shortest

Path First).
• En OSI, existe el protocolo IS-IS.
Interdominio: transmite información entre distintos dominios, que pueden presentar dis-
tintos criterios para el encaminamiento, basados en cuestiones administrativas. Permiten
formular restricciones sobre el tráfico encaminado. Algunos son:
• Encaminamiento manual.
• En TCP/IP, se usan EGP (External Gateway Protocol) y BGP (Border Gateway
Protocol).
• En OSI, se usa IDRP (Inter-Domain Routing Protocol).
Figura 5.30: División de dominios.
Existen dos tipos de protocolos:
Intradominio: Poseen unicidad de criterios (se basa en criterios técnicos). Buscan optimizar
la eficiencia.
Interdominio: Poseen distintos criterios (basados en criterios administrativos o polı́ticos).
Estos criterios son más restrictivos que los anteriores.
Definiciones:
D.A. (Dominio Administrativo): Parte de la red administrada por una sola autoridad.
D.E. (Dominio de Encaminamiento): Subdivisión de D.A. con especificaciones.
Áreas: Subdivisión de D.E.
Entre D.E.-D.E. y D.A.-D.A. se dan los protocolos interdominio mientras que entre áreas y
dentro de las áreas se dan los protocolos intradominio. Algunos de los protocolos existentes son:
Intradominio:
• ISO: SI-SI (LSP) (SI: Sistema Intermedio)

• TCP/IP: RIP (Router Information Protocol): Muy simple, usa el vector de distancias.
No soporta máscaras
• OSPF ( parecido a SI-SI)
Interdominio:
• TCP/IP: EGP (empleaba algo parecido a VD, está en desuso), BGP

• ISO: IDRP (parecido a BGP)
Las ventajas de dividir en dominios la red son:
Escalabilidad: Pueden estar basados en VDs o en LSPs .
• El problema de VDs era la convergencia.

• El problema de los LSPs era la cantidad de recursos que se empleaban.
Por tanto, en ambas opciones hay ventajas si se reduce el tamaño de la red. De
ahı́ viene el beneficio de dividir los dominios.
Autonomı́a de gestión: Permite que los propietarios o gestores sean los administradores y
ocultar una serie de detalles internos de la red.
Ya hemos visto en el apartado 6 cómo conseguir el mejor camino dentro de un dominio.

Para salir del dominio es necesario usar el router de salida (gateway router). En caso de tener un
solo router de salida, la elección es obvia: todos los mensajes que tengan que salir del dominio
se enviarán a ese router. Pero si hubiera más de un router, habrá que ver hacia cuál de ellos se
envı́a el mensaje. O bien se configura manualmente, o se selecciona según algún algoritmo. En
este último caso, habrá que:
Obtener la información de alcanzabilidad través de otros dominios (es decir, otros dominios
me tendrán que comunicar a qué direcciones puedo llegar atravesándolos). Los dominios
que sirven para conectar a otros dominios se llaman dominios de tránsito.
Propagar esta información dentro del dominio.
Escoger el mejor camino. Hay que destacar que en este caso no se puede escoger el mejor
camino como el que tenga una mejor métrica, ya que distintos dominios pueden tener
conceptos distintos de lo que es la métrica (para uno puede ser el retardo, para otro el
número de saltos, etc.). Lo que sı́ se usará para escoger el mejor camino es el número de
dominios que hay que atravesar, procurando que este parámetro sea lo menor posible.
Los protocolos encargados de esta tarea son los protocolos interdominio. Pasemos a
analizar los 2 tipos de protocolos existentes:
5.8.1. Protocolos intradominio (IGP)

Protocolo RIP (Routing Information Protocol)
Especificado en:
Versión 1- RFC 1058
Versión 2- RFC 2453
Emplea el VD (Vector Distancia). Por defecto, consideramos que el coste de cada enlace
es 1. Este protocolo mide el número de saltos. El máximo número de saltos es 15. Si es mayor
que 15, no se tiene en cuenta. De ahı́ que sea una buena elección de protocolo en caso de redes
pequeñas.
Cada 30 segundos se resfrescan los datos de los vecinos enviando un mensaje de anuncio. Si
en 180 segundos no se recibe información de algún vecino, toda la información acerca de él se
desecha.
Existen 2 tipos de mensajes:
Respuesta (RESP): es un mensaje que contiene el vector de distancias. Este mensaje se

envı́a a los vecinos.
Solicitud (REQ): fuerza a uno de los vecinos a que te envı́e un mensaje RESP.
La Versión 1 no soportaba máscaras mientras la Versión 2 sı́. Cada vecino se definirá por el
par dir.IP/Máscara. La estructura de un paquete RIP es (donde L2 representa la cabecera del
protocolo que se use en nivel de enlace):
Figura 5.31: Estructura de un paquete RIP.
Si observamos cómo se construye un paquete RIP, podemos ver dos cosas. Desde el punto
de vista de la eficiencia, es un desperdicio de cabeceras. Este gasto de cabeceras se justifica
porque haciéndolo ası́ es más fácil programar el protocolo en una máquina real. También debemos
resaltar el que use UDP (más concretamente, su puerto 520). Debido a esto, el envı́o de mensajes
es no fiable.
Protocolo OSPF (Open Shortest Path First)
Este protocolo viene determinado en RFC 2328. La palabra .Open” que aparece en su nombre
significa que no es un protocolo propietario. Shortest Path First significa que emplea el estado
de los enlaces (LSP). No emplea ni Dijkstra ni Bellman-Ford.
Cada enlace tiene su propio coste. Por defecto será 1, pero lo usual es que el administrador
de la red asigna un valor inversamente proporcional a la capacidad del enlace. Se envı́an LSP,
por defecto, cada 30 minutos. Este protocolo se encapsula directamente sobre IP, pero indicando
en el campo protocolo de la cabecera IP que se trata de OSPF (identificador 89 en el campo
protocolo).
Algunas caracterı́sticas que presenta este protocolo son:
Se basa en la transmisión de LSPs.

Seguridad: Se puede autentificar al otro extremo mediante:
• Password (no se usa)
• MD5: Se añade un número de secuencia que impide la reproducción.
Figura 5.32: Algoritmo de autentificación mediante hash.
Multicast: Un paquete puede llegar a varios nodos. En realidad, se emplea una variante
llamada MCSPF (MultiCast Service Path Finding).
Jerarquı́a: Permite realizar divisiones dentro de un dominio, llamadas áreas. En Internet, a

cada dominio se le llama Sistema Autónomo (AS). La jerarquı́a se establece de la siguiente
forma:
Para RAL, aparecen router designado y router designado de backup, por si falla el designado.
En OSPF, a los paquetes del estado de los enlaces se les denomina LSA (Link State An-
nouncement/Advertisement). Se distinguen 5 tipos de LSA:
Tipo 1 - LSP - Router informa a los vecinos
Tipo 2 - LSP - Router designado
Tipo 3 - LSP - Router borde de área hacia dentro del área resumiendo la información de
fuera del área pero dentro del dominio o viceversa.
Tipo 4 - LSP - Router borde de área hacia dentro del área indicando el camino hacia los
nodos o routers de salida.
Tipo 5 - LSP - Router de salida a todo el dominio indicando las redes accesibles fuera del
dominio basándose en los cálculos realizados mediante protocolos interdominio.
Figura 5.33: Jerarquı́a en Internet.
5.8.2. Protocolos interdominio (EGP)

BGP (Border Gateway Protocol)
Está definido en las RFC 4271 (BGP-4), 1772 y 1773. Emplea un vector de caminos, algo
parecido al vector distancia pero que lista los AS (Sistemas Autónomos) que hay que atravesar
para llegar a un destino. Por tanto, requiere información de alcanzabilidad.
Los routers de salida establecen conexiones TCP entre ellos que se llaman sesiones BGP.
El protocolo TCP es fiable, es decir, se encarga de reenviar la información que se haya podido
perder. Existen dos tipos de sesiones BGP: las sesiones externas, o eBGP, que sirven para obtener
la información de alcanzabilidad, y las sesiones internas, o iBGP, que propagan la información
obtenida a través de eBGP dentro de un dominio.
Figura 5.34: Tipos de sesiones.
En la siguiente ilustración podemos ver cómo, mediante el protocolo BGP, se transmite

la información de alcanzabilidad entre varios sistemas autónomos. Podemos ver que las IPs
involucradas forman parte de un mismo bloque, el 138.16.64.0/22, que es la información que
transmitimos.
Figura 5.35: Envı́o de información mediante BGP.
Exite un organismo encargado de gestionar esto protocolo, IANA, autoridad encargada de la

asignación de números en Internet, que fue sustituido por el actual ICANN (Internet Corporation
Assigned Names and Numbers).
Las rutas se definen utilizando rutas, que están compuestas por un prefijo y varios atributos.
El prefijo, a su vez, se compone de dirección de red y máscara. Entre los posibles atributos
encontramos:
AS-PATH: Camino para llegar al destino. Se da como una lista de ASN (Número de
identificación de Sistema Autónomo, de 16 bits). Se emplea para decidir sobre el mejor
camino, que será aquel con menor AS-PATH.
NEXT-HOP: La dirección IP del que envı́a esa ruta. Es interesante para sistemas autóno-
mos conectados por varios routers.
Los router BGP manejan 3 tipos de bases de datos, en lugar de la RIB habitual. Éstas son:
RIB de entrada: contiene los anuncios recibidos de otros routers, filtrados mediante una
serie de polı́ticas de entrada. Es una tabla con una entrada por cada sesión BGP.
RIB local: es única para cada router, y es la que se usa para decidir el encaminamiento.
Se crea filtrando la RIB de entrada. Esta tabla, junto a la configuración del router y los
protocolos intradominio, forman la FIB.
RIB de salida: controla qué información se anuncia. Se forma filtrando la RIB local con la
polı́tica de salida.
Figura 5.36: Lógica para la creación de las RIBs.
En BGP, se sigue este algoritmo para la selección de rutas:
1. Se escoge con mayor preferencia la ruta local.

2. . Si hay varias con el mismo valor, se escoge la de menor AS-PATH.
3. Si hay varias con el mismo valor, se escoge aquella cuyo Next-Hop esté más cerca.
4. Si estuvieran todos a la misma distancia, se escoge según el identificador BGP, que es único
para cada router. Esta elección es simplemente para deshacer el empate, no tiene ningún
sentido.
El Sistema Autónomo puede considerarse como terminal (stub) o de tránsito (transit).

Un sistema configurado como stub solamente cursa tráfico cuyo origen o destino sea él mismo.
Un sistema de tránsito, sin embargo, permite que lo atraviese tráfico que va destinado a otros
sistemas. Los sistemas de tránsito anuncian las rutas que se pueden alcanzar a través de ellos,
generalmente según acuerdos económicos (anuncian las rutas que les pueden reportar beneficios).
Figura 5.37: Ejemplo con varios SA interconectados.
En la gráfica, W e Y serı́an claramente sistemas terminales. X se puede configurar para que

sea de tránsito o terminal, permitiendo que anuncie rutas o no, respectivamente. Una situación
que se da con cierta frecuencia es que un sistema autónomo terminal esté conectado a dos
proveedores de servicio (ISPs). En este caso, X podrı́a ser una empresa que tenga contratado
acceso a Internet con los proveedores B y C. Normalmente, un ISP te asigna direcciones privadas
o bien un rango de direcciones públicas que esté bajo el control del ISP. Si un AS está conectado
a dos ISPs al mismo tiempo, se presentan dos opciones:
Solicitar un rango de direcciones públicas, independiente de cualquier ISP. Es una solución

que no se suele adoptar, debido al excesivo coste.
Pedir un rango de direcciones privadas a uno de los dos ISP, y anunciarlo a ambos ISP. La
ruta se propagará por toda la red a través de ambos AS.
En ocasiones, varios sistemas autónomos se unen para crear una confederación. Aunque los
AS que las componen son independientes y tienen cada uno un ASN propio, de cara al exterior
se presentan como si formaran un único AS.
Figura 5.38: Problema de la creación de confederaciones.
Vemos que la creación de confederaciones a veces evita que se pueda escoger el camino
óptimo. En la ilustración, si el AS 33 quisiera llegar hasta el ASN 38, el camino más corto serı́a
a través de 1, 37 y 4. Sin embargo, desde fuera vemos a la confederación como un sólo AS, no
tenemos acceso a información sobre los AS de su interior. Si siguiéramos ese camino, estarı́amos
entrando dos veces en el AS 15, lo cual no está permitido (se prohı́be que una ruta pase dos
veces por un mismo AS para evitar bucles). La ruta a seguir tendrı́a que ser la marcada con
lı́nea continua, que tiene un salto más que la ruta óptima.
Reflectores de rutas
Figura 5.39: Uso de reflectores de rutas.
Los reflectores de rutas se utilizan para evitar tener que realizar un mallado total de cone-
xiones iBGP dentro de un AS. El reflector de rutas está unido al mallado total, y además existen
varios nodos que se conectan únicamente al reflector de rutas. Aunque normalmente lo que se
aprende por una conexión iBGP no se puede retransmitir por otra conexión iBGP, el reflector
de rutas viola esta norma y envı́a toda la información de que dispone por sus enlaces. Mediante
el uso de reflectores se ahorra la creación de muchas conexiones, pero hay que tener en cuenta
que el reflector es un elemento centralizado, y como tal un fallo en el reflector serı́a catastrófico
para la red.
Veamos ahora un ejemplo real de configuración de un AS. Vamos a suponer que los routers
implicados utilizan el sistema operativo IOS (Internetwork Operating System) de Cisco. Los
comandos que utilizaremos son:
router bgp x: Indica a un router que pertenece al AS con ASN x.

neighbor x remote-as y: Indica a un router que la dirección IP x pertenece a un router que
forma parte del AS con ASN y.
Si tenemos una serie de routers dispuestos de la siguiente forma:
Figura 5.40: Ejemplo.
algunos de los comandos que tendremos que ejecutar en los routers son:
Router A Router RTB Router RTC

router bgp 100 router bgp 200 router bgp 200
neighbor129.213.1.1remote-as200 neighbor129.213.1.2 remote-as100 neighbor175.220.212.1remote-as200
neighbor175.220.1.2remote-as200
5.8.3. TEMA 6: Control de congestión

Introducción
En una red de conmutación ideal, la situación de congestión nunca llega a producirse. Al

tener los nodos memoria infinita, ningún paquete se pierde, independientemente del tráfico. Pero
en una situación real, cada cola solo puede almacenar un número limitado de paquetes, por lo
que es necesario un mecanismo que impida que la red se congestione y se bloquee el tráfico.
Dada una red de conmutación de paquetes, la evolución de la carga es la siguiente:
El rendimiento normalizado se puede calcular como la velocidad de salida de paquetes del

sistema partido por la capacidad teórica. Igualmente podemos calcular la carga normalizada
como los paquetes por segudo que entran al sistema dividido por la capacidad teórica.
La carga en el sistema puede aumentar por varias razones:
Encaminamiento defectuoso: un encaminamiento perfecto repartirı́a la carga lo mejor po-

sible, por lo que retrasa la congestión del sistema. Hay que tener en cuenta que solamente
la retrasarı́a: si la entrada de datos es superior a la capacidad del sistema para procesarlos,
por muy bueno que sea el encaminamiento acabará por saturarse el sistema.
Lentitud en los conmutadores.
Al aumentar la carga, se llena la memoria de los nodos del sistema. Esto provoca que aumente
el retardo y se pierdan paquetes por saturación de las colas (overflow). Al perderse paquetes, es
necesario retransmitirlos, por lo que aumenta la carga. Esto provoca un cı́rculo vicioso que hace
que el sistema llegue al punto de bloqueo.
Para evitar este cı́rculo vicioso, se utilizan los mecanismos de control de congestión.
No hay que confundir mecanismos de control de congestión con mecanismos de control de
flujo. En control de flujo, el extremo receptor da órdenes al transmisor para que reduzca o frene
su transmisión. En control de congestión, es la red la que lo decide. El control de flujo puede ser
consecuencia del control de congestión.
5.8.4. Clasificación de los mecanismos de control de congestión

Los mecanismos de control de congestión se pueden clasificar según 3 caracterı́sticas:
Según lugar de realización:
• En los encaminadores: son los encaminadores los que tienen mayor responsabilidad
en el control de congestión.
• En los sistemas finales: la responsabilidad del control de congestión recae en su
mayor parte sobre los sistemas finales.
Ojo, aunque el lugar de realización sea en los encaminadores, siempre una pequeña parte
del procesamiento la tendrán que realizar los sistemas finales. Igualmente ocurre en el caso
contrario.
Según el mecanismo en que estén basados:
• Basados en realimentación: Los sistemas finales reciben órdenes sobre como de-
ben comportarse (es decir, si deben aumentar el tráfico que transmiten o reducirlo).
Estas órdenes pueden provenir de los encaminadores (si es un mecanismo localiza-

do en encaminadores) o puede ser que los mismos sistemas finales tomen decisiones
basadas en lo que observan que ocurre en la red (por ejemplo, si ven que se están per-
diendo paquetes, podrı́an decidir reducir su tasa de transmisión). Este último método
está asociado con los mecanismos de congestión localizados en sistemas finales.
• Basados en reserva: un sistema final tiene que pedir permiso antes de inyectar in-
formación en la red. Se suele usar al establecer conexiones. Aunque se llamen ”basados
en reserva” no se produce una reserva real de capacidad (recordemos que estamos ha-
blando de redes de conmutación de paquetes, y realizar una reserva de recursos es
contraproducente en general). La reserva que se produce es virtual.
Según la forma de darle derechos de transmisión al emisor:
• Basado en créditos: el emisor recibe una serie de créditos. Por cada crédito, puede
introducir un paquete en la red. La asignación de créditos es dinámica, similar a una
ventana deslizante.
• Basados en tasa: el emisor tiene una velocidad máxima a la que puede transmitir
paquetes.
Capı́tulo 6
Capa de transporte
6.1. Introducción a la capa de transporte

Si recordamos los niveles que hemos estudiado hasta ahora, el nivel de enlace era solo entre
nodos adyacentes. En el nivel de red, tenamos que tener en cuenta los nodos intermedios. En la
capa de transporte, sin embargo, son los sistemas finales los que se entienden extremo a extremo,
sin importarles la red intermedia.
Figura 6.1: Nivel de transporte.
La capa de transporte puede añadir las siguientes funcionalidades:
Fiabilidad.
Orientación a conexión.
Posibilidad de multiplexión de conexiones.
99
ISO normalizó y definió 5 protocolos de nivel de transporte, denominados de TP0 a TP5.

TP0 es muy simple y se utiliza si el nivel de red ofrece un servicio muy bueno. Si se empieza
a tener errores en el nivel de red pasamos a TP1, TP2, TP3, y TP4 (siendo cada uno de los
protocolos con numeración superior capaz de recuperar más errores; TP4 es capaz de recuperar
casi cualquier error, pero también es el más complejo). También se definieron servicios ofrecidos
por el nivel de transporte, tanto orientados a conexión como no orientados a conexión.
Estos protocolos tenı́an muchas opciones y aplicaciones, pero no se usan porque se implan-
taron los protocolos de transporte de IP: TCP y UDP.
Figura 6.2: Protocolos de transporte en TCP/IP.
6.2. Jerarquı́a TCP/IP
6.2.1. UDP
Protocolo de Datagrama de Usuario (User Datagram Protocol). Definido en la RFC 768.
Es un protocolo con el cual se ofrece un servicio no orientado a conexión (CL, Connection
Less) y no fiable. Esto era prácticamente lo que ofreca el nivel de red, IP, pero la diferencia
es que con UDP se añade la capacidad de multiplexión (MUX). En UDP se utiliza el número
de puerto para multiplexión: los mensajes van a la misma máquina pero dentro de ella van a
una aplicación u otra dependiendo del número de puerto. Por tanto, una dirección UDP tiene la
forma:
Dirección U DP = Dirección IP + P uerto U DP (6.1)
En la cabecera IP se indica que la información que está encapsulada es un paquete UDP

poniendo en el campo protocolo el valor correspondiente a UDP, que es 17.
En la cabecera UDP van el número de puerto origen y el número de puerto destino (al
igual que en la de IP iban la IP origen y la IP destino). Los números de puerto, al estar
Figura 6.3: Encapsulamiento de UDP.
Figura 6.4: Formato de la cabecera UDP.
formados por 16 bits, pueden ser del 0 al 65535. Sin embargo, el usuario no puede escoger
uno cualquiera: los puertos de 0 a 1023 están reservados para aplicaciones especı́ficas. Por
ejemplo:
• 69: puerto para TFTP, Trivial File Transfer Protocol (transferencia de ficheros trivial).
• 513: puerto para who, que permite conocer quien ocupa el equipo en ese momento.
La longitud total del segmento mide el tamaño del segmento completo (cabecera y datos)
en octetos.
Checksum es un código de redundancia que detecta errores. Para calcularlo, se tienen

en cuenta las direcciones IP del datagrama donde va este segmento, es decir, tomamos
información del nivel inferior (en OSI, eso sera una HEREJı́A).
Algunos campos aceptan valores especiales:

Si ponemos checksum = 0 en la trama, estaramos indicando que no está calculado el

código de redundancia.
Si ponemos puerto origen = 0 no estaramos indicando el origen, por lo que el destino

no podrá contestar.
6.2.2. TCP
Protocolo de Control de Transmisión (Transmission Control Protocol). Definido en la RFC
793. Con este protocolo se puede ofrecer un servicio orientado a conexión (CO,Connection Orien-
ted) y fiable (además de ofrecer multiplexión, al igual que UDP). Al ser un servicio CO es dúplex
(se pueden enviar datos en ambos sentidos, da igual quien haya iniciado la conexión). Dicha co-
nexión está identificada por una dirección TCP:
Dirección U DP = Dirección IP + P uerto U DP (6.2)
El número de puerto sirve para poder multiplexar. Veamos un ejemplo:
Figura 6.5: Ejemplo de multiplexión.
En la máquina con IP1 tengo 3 conexiones distintas con la misma IP y puerto origen. Las
conexiones con la máquina IP2 se diferencian en el número de puerto destino, puesto que TCP2
es distinto que TCP3 en IP2. Vemos que una conexión IP está definida unı́vocamente por
4 parámetros: IP origen, puerto origen, IP destino y puerto destino. Se pueden repetir
hasta 3 de estos parámetros en dos conexiones distintas, pero nunca los cuatro a la vez.
Podemos tener un servidor asociado a un número de puerto. Por ejemplo, si TCP1 fuera
el puerto asociado con un servidor FTP (puerto 21), estarı́amos transfiriendo ficheros hacia el
mismo puerto, pero desde máquinas distintas (llegan datos desde 2 y 3).
La fiabilidad es este tipo de conexión se puede conseguir mediante asentimiento y retrans-
misiones. Cada paquete tiene que ser asentido. Si enviamos datos y no recibimos asentimientos
durante un cierto tiempo, suponemos que se ha perdido la información y lo que hacemos es
retransmitir. El modelo que se usa en estos casos es el siguiente:
Figura 6.6: Modelo de colas para transmisión en TCP.
La máquina destino recibe en un buffer y, cuando comprueba que no falta nada y todo
está en orden, se lo pasa al nivel superior. Si llega bien, manda asentimiento. Si no, no manda
nada y espera a que se retransmita. La interfaz entre las capas (es decir, la forma de pasarse
los datos) no está normalizada. Sólo se obliga a que lo que se envı́a a la capa adyacente
esté en el mismo orden en que se envió. Al contrario que OSI, ni siquiera se obliga a que el
tamaño del paquete que se envió y el del paquete que el receptor pasa al nivel superior sea el
mismo. Tampoco está normalizado lo que se hace con los datos si algo no llega. Lo
normal es, si tienes una serie de paquetes pero te falta uno, que almacenes los que tienes y los
que van llegando hasta que el origen te reenvı́a el que te falta. Entonces, se pasan todos de golpe
al nivel superior. Lo que sı́ está normalizado es el conjunto de PDUs que se intercambian.
Normalmente, a la hora de enviar un datagrama, el nivel superior se lo envı́a al nivel
inferior. Este entonces lo pone en una cola, y lo transmite cuando considere oportuno. Hay dos
modificaciones de este funcionamiento:
Mecanismo PUSH: tampoco está normalizado. Mediante este mecanismo, el nivel superior
obliga al nivel inferior a enviar todo lo que tenga en el buffer lo antes posible. Existe un
flag dentro de la trama que se envı́a (recordemos que un flag es una variable binaria, que
puede valer 1 en caso de que algo sea cierto y 0 en caso de que sea falso) en la que se indica
que esos datos han sido mandados de forma obligada.
Datos urgentes: los paquetes que están marcados como datos urgentes pueden saltarse todas
las colas. Se ponen siempre al principio del segmento en el que viajan. En la cabecera, se
debe indicar que el segmento lleva datos urgentes (con un flag) y además es obligatorio
indicar cuántos de los datos son urgentes.
En TCP existe control de flujo: el receptor frena al emisor, diciéndole el receptor al emisor
la cantidad de octetos que puede enviar sin esperar asentimiento. Esto es lo que se llama tamaño
de ventana. Aquı́ se usa ventana deslizante (regulable según lo que desee el receptor). Como la
conexión es dúplex, lo que pasa en un sentido pasa también en el contrario.
Estudiemos la cabecera TCP en detalle:
Figura 6.7: Fomato de cabecera en TCP.
Puerto origen y puerto destino: como ya hemos visto, se usa para multiplexión. Son de 16
bits cada uno (van de 0 a 65535)
Número de secuencia: en vez de numerarse los segmentos, se numeran los octetos (Los
octetos tienen su propio número de orden. Se pone el número del primer octeto que va
en el segmento). Tiene mucho sentido numerar los octetos en lugar de los segmentos, ya
que los segmentos pueden tener longitud variable. Hay que resaltar que el número con el
que se comienza a numerar los octetos es aleatorio, y se decide en el establecimiento de la
conexión. Un ejemplo serı́a:
Figura 6.8: Numeración de octetos en la cabecera TCP.
Asentimiento: Se envı́a el número de orden del primer octeto que se espera recibir. A
la vez que mandas datos se pueden mandar asentimientos, para optimizar el gasto de ancho
de banda. El mecanismo de asentimiento se explica con detalle en el siguiente apartado.
THL (TCP Header Length, longitud de cabecera TCP): Contiene el tamaño de la cabecera,
en unidades de 4 octetos (32 bits). El tamaño mı́nimo de la cabecera TCP son 20
octetos, al igual que en la cabecera IP. Es obligatorio conocer este dato de memoria,
se puede preguntar expresamente en el examen.
Flags:
Figura 6.9: Sección de flags de la cabecera TCP.

• URG: Indica que el paquete contiene datos urgentes. Recordemos que estos datos se
ponen al principio del segmento, se pueden saltar el orden normal y acceden al nivel
superior cuanto antes. Si no contiene datos urgentes, se pone a 0.
• ACK(ACKnowledgement, asentimiento): Si vale 0, se ignora el campo asentimiento.
Si vale 1, significa que el campo asentimiento de la cabecera contiene un asentimiento.
• PSH: se pone a 1 cuando se fuerza el PUSH. Ası́ cuando lo recibe el otro extremo,
sabe que son datos obligados (pushed) por el receptor.
• RST: bit de reset. Aborta la conexión cuando vale 1. Veremos su uso en un apartado
posterior.
• SYN (SYNchronous idle, espera sı́ncrona): se usa en el establecimiento de la conexión,
para ponerse de acuerdo ambos extremos.
• FIN: para el cierre de la conexión. Al contrario que RST, que cierra la conexión de
forma abrupta, con FIN se comienza un proceso de negociación para el cierre.
Tamaño de ventana: Le dice al receptor el número de octetos que puede enviar sin tener
que esperar asentimiento. Si está a 0, no podrá mandar nada.
Checksum: Aquı́ en el cálculo del checksum, también se tienen en cuenta las direcciones
IP (nivel inferior).
Campos opcionales: al igual que la cabecera IP, los campos opcionales deberán ser mútiplos
de 4 octetos. Si no lo son, se añadirá relleno hasta conseguirlo.
Detalles de TCP:
Funcionamiento de los asentimientos
Como se numeran los octetos, lo que se asienten son los octetos, no las tramas. Se usa un
tipo de asentimiento que se llama asentimiento acumulativo. Cuando asientes un octeto, asientes
todos los que han llegado antes que él.
Es un protocolo bueno porque es muy simple, pero da poca información. Eso podemos verlo
en el ejemplo anterior, con el paquete de número de secuencia 2500 (resaltado en un recuadro),
que se ha retransmitido sin ser necesario. Cuando perdemos una ráfaga de paquetes sabemos
que el primero se ha perdido, pero no sabemos si también se han perdido los que siguen. Hay
dos formas de enfrentarse a esta situación:
Ser conservativos: Retransmitir el que se piensa que se ha perdido y esperar asentimiento.

Si es el único que se habı́a perdido, llegará el asentimiento de todo el conjunto completo,
Figura 6.10: Funcionamiento de los asentimientos en TCP.
en el ejemplo ACK=4500. Pero si se habı́an perdido los siguientes, se convierte en un

protocolo de parada y espera (manda y espera asentimiento, ası́ con todos los que se hayan
perdido). Esto es muy ineficiente.
Ser agresivos: Retransmitir todo aunque lo demás no se haya perdido, pero de esta forma
gastamos ancho de banda y más recursos.
Realmente el problema no tiene una solución óptima, depende de la implementación.

Funcionamiento de la ventana deslizante:
La ventana autorizada representa lo que puedo enviar sin recibir asentimiento. Vemos cómo
con asentimientos se va desplazando el borde inferior de la ventana y con el tamaño se limita el
borde superior. Para implementar el mecanismo de retransmisión, se asocia a cada segmento un
Figura 6.11: Funcionamiento de la ventana desliante en TCP.
temporizador. Cuando cumple el temporizador, el segmento asociado se retransmite. El cálculo

del temporizador debe ser acorde con el comportamiento de la red.
Cálculo del temporizador de retransmisión de TCP:
El tiempo que pasa desde que se envı́a un paquete hasta que se retransmite es parámetro
muy importante. Hay que tener en cuenta que, si ese tiempo demasiado corto, a menudo trans-
mitiremos paquetes sin necesidad. Por contrario, si es demasiado largo, tardaremos mucho en
retransmitir y habrá tiempo muerto en que no estaremos transmitiendo nada.
Figura 6.12: Definición del Round Trip Time
Podemos medir el tiempo desde que se transmite un segmento hasta que llega el ACK
correspondiente. Este tiempo se conoce como tiempo de ida y vuelta, RTT (Round Trip Time)
y nos puede servir para determinar el temporizador. El RTT medio es muy oscilante porque al
atravesar la red, el retraso es muy variable. Lo que se hace es una estimación, el RTT estimado,
según la siguiente fórmula:
RT Test = RT Testant (1 − δ) + RT Tmedido (δ) (6.3)
Con ello conseguimos suavizar el RTT. También podemos calcular la desviación y suavizarla:
DESVest = DESVestant (1 − ρ)+ | RT Testant | ρ (6.4)
Con estos parámetros podemos calcular el valor del temporizador:
T EM P = RT Test + ηDESVest (6.5)
El resultado será un poco más grande que lo que tarda en llegar el ACK, pero no mucho
más.
Ahora se nos presenta un nuevo problema. Si retransmitimos un segmento y nos llega un
ACK, no podemos saber si ese ACK se refiere al segmento original o a la retransmisión.
Figura 6.13: Ambigüedad del RTT
El asentimiento de TCP es acumulativo y no hay forma de saber con qué original se mide
el asentimiento, por lo que no hay forma de medir el RTT. Para ello usamos el algoritmo de
KARN: Cuando hay que retransmitir no se calcula el temporizador con la fórmula de RTT.
En su lugar, con cada retransmisión se aumenta el temporizador de los segmentos enviados y no
asentidos al doble (hasta un valor máximo). Cuando no hay retransmisión ya se vuelve a medir
el temporizador mediante la fórmula.
Control de congestión de TCP:
En TCP, cuando el extremo que está transmitiendo estima que la red está congestionada,
se frena. Pero el resto de los protocolos no se frenan (por ejemplo UDP), ası́ que utilizan lo que
deja libre TCP y acaban saturando la red. Por tanto, aunque históricamente se llame çontrol de
congestión”, realmente lo que hace es ayudar para que no haya congestión, no la controla. Serı́a
un control de congestión si todas las comunicaciones de una red se hicieran usando el protocolo
TCP exclusivamente.
Hemos visto que en los segmentos aparece un campo que especifica la ventana indicada por
el receptor. Además de esa, en TCP hay otra ventana que es la ventana de congestión, la cual
se va reduciendo cuando se estima que hay congestión. El mı́nimo de estas dos ventanas es la
ventana autorizada (lo que puedo transmitir sin esperar asentimientos).
V entana autorizada = min(ventana indicada por receptor, ventana de congestión) (6.6)
Si no hay congestión, la ventana autorizada será la ventana indicada por el receptor. El

cá1lculo de la ventana de congestión se realiza de la siguiente forma: cada vez que se estima que
hay congestión (se considera que hay congestión si hay que retransmitir un segmento),
se disminuye el tamaño de la ventana de congestión a la mitad. Eso se hará ası́ hasta
que la ventana alcance el tamaño mı́nimo de un segmento (que no un octeto). Recordemos
que, como el algoritmo de Karn controla la retransmisión, aumentamos los temporizadores de
los segmentos enviados y no asentidos al doble.
A la hora de aumentar la ventana, se siguen dos procedimientos:
Arranque lento: Se utiliza cuando empezamos a aumentar la ventana. Por cada ACK que
llegue, se incrementa la ventana de congestión en el tamaño de 1 segmento.
Otro protocolo, sin nombre: Se utiliza cuando se alcanza cierto umbral mediante el proto-
colo anterior. En este caso, se incrementa la ventana en el tamaño de 1 segmento cada vez
que se recibe ACK para toda la ventana (es decir, tantos asentimientos como segmentos
quepan en la ventana). Por ejemplo, con segmentos de 1000 octetos y una ventana de 3000
octetos, al recibir 3 asentimientos la ventana pasará a valer 4000 octetos.
Una aclaración: la notación del nombre de los protocolos puede dar lugar a equı́vocos. El pro-
tocolo de arranque lento en realidad es más rá1pido que el segundo. En el primero, cuando
recibes un asentimiento ya puedes mandar más datos. En el segundo, necesitas varios asenti-
mientos antes de aumentar la ventana.
Mecanismo Fast Retransmit-Fast Recovery:
Permite retransmitir antes de que venzan los temporizadores. Si un segmento se pierde,

se empezarán a recibir asentimientos repetidos (como se puede ver en la fig10). Si llegan 3
asentimientos repetidos (es decir, el ACK original y otros 3 iguales), aunque no haya vencido el
temporizador se retransmite el segmento y se considera que hay congestión: disminuye la ventana
de congestión a la mitad y los temporizadores se duplican. Establecimiento de conexión: Durante
el establecimiento de la conexión se negocian parámetros como el tamaño máximo de segmento
y los números de secuencia iniciales en cada sentido. Se hace en tres etapas:
Figura 6.14: Protocolo para establecimiento de la conexión
1. Uno de los extremos envı́a un paquete, compuesto sólo de una cabecera con el bit SYN a
1 (expresa el deseo de iniciar una conexión) y un número de secuencia arbitrario X (será1
el número de secuencia inicial en ese sentido de la transmisión).
2. El otro extremo le responde con otro paquete, compuesto exclusivamente de una cabecera,
con el bit SYN a 1 (él también desea establecer una conexión en el otro sentido, recordemos
que en TCP las conexiones son dúplex), el número de secuencia Y (número de secuencia
inicial en su sentido de la transmisión) y asiente el número de secuencia X que le envió el
otro extremo con un ACK a X+1.
3. El extremo que inició el procedimiento indica que su número de secuencia es ahora X+1,
y asiente el número de secuencia enviado por el otro extremo con un ACK a Y+1. En
este momento, se considera que la conexión está establecida y se pueden empezar a enviar
datos en ambos sentidos. De hecho, el extremo de la izquierda podrı́a haber empezado a
enviar datos justo después de recibir el asentimiento a X+1.
Si recordamos el funcionamiento de los asentimientos, cabe preguntarse por qué se asiente

X+1 e Y+1 si no se ha enviado ningún octeto de datos. Esto se hace ası́ porque se
considera que el bit SYN puesto a 1 equivale a enviar un octeto de datos
(también ocurrirá esto con el bit FIN, como veremos más adelante). Otra cuestión que
llama la atención es que se utilice un número de secuencia arbitrario, en lugar de empezar
siempre por 0. Esto se hace ası́ para evitar confusiones: si empezáramos siempre por 0, al
abrir una conexión, cerrarla rápidamente y volverla a abrir podrán confundirse los paquetes
pertenecientes a cada una de las conexiones (tendrán números de secuencia similares). Para
evitar esto, además de usar números aleatorios, TCP recuerda los números de secuencia
que utilizó en las últimas conexiones para no repetir los mismos números contra los mismos
destinos.
Cierre de la conexión:
Para el cierre de la conexión no la tiene que cerrar el extremo que la abrió. Lo que si es que
hay que cerrarla en ambos sentidos por separado. Puede que cerremos la conexión en un
sentido pero en el otro sentido aún queden paquetes por enviar. Se enviarán los paquetes y
después se cerrará el otro sentido de la conexión. Una vez cerrado un sentido de la conexión,
el transmisor correspondiente a ese sentido queda limitado a enviar asentimientos, no puede
enviar datos.
Figura 6.15: Caso más simple: ambas conexiones se cierran
Algunos detalles a tener en cuenta sobre el segundo caso:
Como decı́amos, el extremo transmisor de la conexión cerrada solamente puede transmitir

cabeceras con asentimientos, no datos. Hay que resaltar que todas las cabeceras tendrán
el número de secuencia correspondiente al que tendrán si enviaran datos, pero
dicho número de secuencia no cambia porque no se envı́a ningún octeto de datos.
Figura 6.16: Caso complejo: primero se cierra un sentido y después otro
Una conexión se considera cerrada cuando se recibe el asentimiento al paquete que contenı́a
el bit FIN a 1. Es necesario cerrar cada uno de los dos sentidos.
Hay un caso especial de cierre de conexión, llamado liberación abrupta. Se suele dar
cuando hay algún error. El cierre de la conexión es sin negociación, inmediato y no requiere
asentimiento. Veamos dos ejemplos en los que se da este tipo de cierre:
Aspectos del rendimiento de TCP: Recordemos que TCP tiene una cabecera de ta-
maño mı́nimo 20 octetos e IP tiene una cabecera de tamaño mı́nimo 20 octetos. Por otra parte,
el nivel de enlace que se use también tendrá su propia cabecera que añadir a esto. Esto quiere
decir que, independientemente del tamaño de los datos, estamos transmitiendo una cabecera de
al menos 40 octetos en cada datagrama.
Existe un fenómeno, llamado sı́ndrome de la ventana tonta (Silly Window Syndro-
me), en el que se desperdicia mucho ancho de banda en cabeceras. El fenómeno consiste en lo
siguiente:
El extremo receptor (B) necesita que el extremo transmisor (A) se frene momentáneamente
porque el buffer de recepción de B está saturado. Para ello, le envı́a como tamaño de
ventana de transmisión el valor 0.
Figura 6.17: Liberación abrupta por caı́da de uno de los extremos
B se recupera un poco, consigue un espacio de un octeto en su buffer y envı́a a A el tamaño

de ventana de transmisión 1 (es decir, puede transmitir un octeto de datos)
Si A transmite, estará enviando un paquete con 1 octeto de datos y más de 40 de cabeceras.
El rendimiento será inferior al 2,5 %.
Para evitar esto, cuando B envı́e un tamaño de ventana 0 a A, tendrá que esperar antes de
cambiar el tamaño de ventana de transmisión de A. No podrá enviarle un tamaño de ventana
distinto a A hasta que ocurra una de estas dos condiciones:
En el buffer de B cabe un segmento de A (es decir, el tamaño de segmento que se negoció en

el establecimiento de la conexión).
La mitad del buffer de B está vacı́o.
También puede darse la situación de que el transmisor tenga poca información que enviar.
En ese caso, se hace lo siguiente:
Si todo lo que A ha enviado está asentido, A envı́a lo poco que tenga que enviar (aunque
sólo sea un octeto).
Si falta algo de lo que A ha enviado por asentir, A espera a tener bastantes datos para
llenar un segmento o bien a que llegue un asentimiento. Entonces, A puede transmitir.
PROBLEMA:Sean dos sistemas finales con la siguiente torre de protocolos:
Figura 6.18: Liberación abrupta por exceso de retraso durante establecimiento de conexión
Nos dan los siguientes datos:
Retardo de propagación:105ns
Caudal ofrecido en el nivel fı́sico: 64Kbps (nota: K = 103 )
La ventana TCP es fija de 2000 octetos.
La ventana LAPB es fija a 6 tramas.
Queremos transmitir 40.000 octetos de datos
Suponer que en el establecimiento y cierre de la conexión no se envı́an datos, tan solo

cabeceras.
Suponer la conexión LAPB previamente establecida.

Figura 6.19: Torre de protocolos del ejercicio
Se pide:
¿Cuánto tiempo se tarda en establecer la conexión? ¿Y el cierre?

Tiempo mı́nimo de transmisión de los datos.
FUNCIONAMIENTO DE LAPB:
LAPB es un protocolo del nivel de enlace. Para tramas sueltas se tiene una sobrecarga de
6 octetos. Para tramas continuas se tiene una sobrecarga de cabecera con 5 octetos (porque el
”guión”del final sirve para la trama siguiente, como si fuera el del principio de la trama).
Figura 6.20: Encadenado de tramas LAPB
A la hora de decidir el tamaño de los segmentos TCP, nos encontramos con un problema
de optimización. Cuanto mayor sea el segmento, mayor es el rendimiento (ya que hay más datos
para la misma cabecera). Pero, como tenemos una ventana limitada, también será mayor el
tiempo muerto que nos pasamos sin transmitir, mientras llega el asentimiento:
A la larga nos interesa estar el mı́nimo tiempo sin transmitir, que se haga 0, para tener envı́o
continúo en ese punto. Con ello disminuye el rendimiento (más cabecera para los mismos datos),
Figura 6.21: Tiempo muerto en función del tamaño de trama
pero transmitimos más tiempo. Lo complicado es que la ventana TCP se mide en octetos y la
de LAPB en tramas.
Nota importante: El tiempo de asentimiento es fijo. Si nos sale que el número óptimo
de tramas a mandar antes de que llegue el asentimiento de la primera es mayor que 6, hay que
truncar a 6 porque la ventana de transmisión de LAPB no deja transmitir más de 6 tramas.
Capı́tulo 7
Evolución de los equipos y tendencı́as
7.1. Introducción a IPv6

IPv6 es una evolución de IPv4. Está reglado por la RFC 2460 del IETF. Una de las prin-
cipales motivaciones para que apareciera IPv6 fue la escasez de direcciones IP de IPv4, que ya
están casi agotadas en el mundo.
7.2. Direccionamiento en IPv6

IPv6 utiliza direcciones IP de 128 bits (16 octetos), en lugar de los 32 bits que usaba
IPv4. Recordemos del tema 3, Direccionamiento, que dichas direcciones se representan en
hexadecimal, por parejas de octetos separadas por : . Una dirección IPv6 válida serı́a:
3F F E : 0501 : 0008 : 0000 : 0260 : 97F F : F E40 : EF AB
Además, se permiten dos simplificaciones para las direcciones: se puede sustituir una
cadena de ceros de cualquier longitud por ::, y además los últimos 4 octetos se pueden
representar igual que se representaban las direcciones en IPv4. Aplicando esto al ejemplo
anterior, la dirección serı́a equivalente a poner:
3F F E : 0501 : 0008 :: 0260 : 97F F : 254.64.239.171
Es importante tener claro que sólo se puede sustituir una cadena de ceros por
118
::. Si hay varias, como en la dirección anterior, lo normal es escoger la más larga.
Al igual que en IPv4, existe una serie de direcciones especiales. Antes de explicarlas, vamos
a aclarar la notación que vamos a utilizar para representarlas. En IPv6, un prefijo de dirección
especial se representa como:
Dirección IPv6/número
y se interpreta como que todas las direcciones que empiecen por los primeros núme-
ro bits de la Dirección IPv6 pertenecen a ese tipo de direcciones. Por ejemplo, si decimos
que la dirección de tipo multicast es F F 00 ::/8, nos referimos a que cualquier dirección cuyos
primeros 8 bits coincidan con los primeros 8 bits de F F 00 :: es una dirección multicast. En este
caso en particular, estarı́amos diciendo que una dirección que empiece por 11111111 (FF) es una
dirección multicast.
Hay que tener mucho cuidado con esto, ya que estamos representando las direccio-
nes en hexadecimal y la máscara como número de bits. Esto puede llevar a situaciones
curiosas: por ejemplo, si decimos que una dirección Unique Local Unicast (se verá más tarde) em-
pieza por F C00 ::/7, hay que tener una especial precaución. FC, en binario, equivale a 11111100.
Como tomamos los 7 primeros bits, valdrán tanto las direcciones que empiezan por 11111100
(FC) como las que empiezan por 11111101 (FD). ¡Por tanto, una dirección que empiece por FD
también entra dentro de F C00 :: /7!
7.3. Direcciones especiales en IPv6
Unspecified(no especificadas): Son las direcciones ::/128 (todos los bits a 0). Se usan en el
campo origen cuando queremos enviar algo y todavı́a no tenemos una dirección asignada.
Loopback (bucle local): Son las direcciones ::1/128 (todos los bits a 0 y el último a 1).
Equivalente a 127.0.0.1 de IPv4.
IPv4-mapped (direcciones IPv4 ”mapeadas”): Son las direcciones ::FFFF:0:0/96 (80 bits
a 0, 16 bits a 1 y después cualquier dirección de 4 octetos). Sirven para encapsular direc-
ciones IPv4 en IPv6.
Multicast (para múltiples destinos): Son las direcciones FF00::/8 (primeros 8 bits a 1).
Existen varias direcciones especiales:
• Direcciones de difución para nodos:
◦ Difusión para nodos local: Es la dirección FF01::1. Alcanzan todas las entidades
IP dentro de un mismo nodo.
◦ Difusión para nodos en el enlace: Es la dirección FF02::1. Los paquetes llegan a
todos los nodos alcanzables sin pasar por un router.
• Dirección de difusión para routers:
◦ Difusión para routers local: Es la dirección FF01::2. Alcanza al propio nodo que
la envı́a.
◦ Difusión para routers en el enlace: Es la dirección FF02::2. Los paquetes llegan a
todos los routers alcanzables sin atravesar un router.
◦ Difusión para routers en el site: Es la dirección FF05::2. Los paquetes llegan a
todos los routers que pertenecen al site, es decir, a los routers que pertenecen a
nuestra red interna. El paquete llegará hasta el borde de la red que controlamos
nosotros (hasta el router de salida a Internet).
• Dirección de difusión de nodo solicitado(solicited-node):

es una dirección especial, cuyo propósito es sustituir al protocolo ARP (como se
verá en el estudio de la resolución de direcciones dentro del apartado ICMPv6). Esta
dirección está asociada a una dirección unicast, y se construye de la siguiente forma:
Es decir, se toma como prefijo la dirección FF02::1:FF00:0/104 (el paquete empieza por
FF02::1:FF) y se ponen a continuación los últimos 24 bits de la dirección unicast asociada.
A nivel de enlace, la dirección MAC destino que se utiliza en Ethernet se crea de esta forma:
esto es, copiamos los últimos 32 bits de la dirección IPv6 destino como últimos 32 bits
de la dirección MAC, y lo prefijamos con 2 octetos que nos van a indicar que es una dirección de
difusión: 33 33. Cuando un nodo reciba un paquete con esta dirección de enlace, lo aceptará por
empezar por 33 33. Entonces mirará los últimos 4 octetos de la dirección MAC: si se corresponden
con los últimos 4 octetos de su dirección IP multicast solicitada, aceptará el paquete. En caso
contrario, lo descartará. La ventaja de usar este método es que todos los cálculos anteriores se
pueden programar a nivel hardware, con lo que se consigue una gran velocidad.
Existe una pequeña probabilidad de que varios nodos tengan iguales los últimos 32 bits
de la dirección multicast solicitada. Si eso ocurriera y el nodo aceptara el paquete por error, al
pasarlo a su nivel de red se darı́a cuenta de que la dirección IP destino no es la suya y descartarı́a
el paquete entonces.
Anycast (cualquier destino de un grupo): Sintácticamente, son como las direcciones

unicast. Sin embargo, al usar este tipo de direcciones, estaremos enviando un paquete a un
grupo de máquinas. La diferencia con multicast es que, mientras que un paquete enviado
a una dirección multicast tiene que llegar a todos los destinos, un paquete enviado a una
dirección anycast tiene que llegar a uno y sólo a uno de los destinos del grupo, en
general al más cercano.
Unicast: Son direcciones que representan a una interfaz (como en IPv4), o bien a un
grupo de interfaces (esto es una novedad de IPv6). La utilidad de asignar una misma
IP a varias interfaces es, en general, para conseguir un reparto de carga:
Haciendo esto ası́, los paquetes que vayan al router podrán llegar a él por 3 interfaces
diferentes, sin necesidad de que los equipos de la LAN lo sepan. Existen tres tipos de direcciones
unicast:
Link Local Unicast (Direcciones locales al enlace): Son las direcciones FE80::/10 (empie-
zan por 1111 1110 10). Su ámbito de validez es un enlace de IPv6 (en IPv6 se considera un
enlace a un conjunto de máquinas unidas por un medio común, tal que en él las máquinas
se pueden comunicar sin que sus paquetes atraviesen un router). Por tanto, dos
nodos a los que se les haya asignado una dirección local al enlace sólo pueden comunicarse
entre sı́ si no hay routers entre ellos. Es un mecanismo parecido al de las direcciones priva-
das de IPv4: se pueden repetir direcciones en distintas redes privadas. Además, los nodos
pueden asignar automáticamente este tipo de direcciones.
Unique Local Unicast (Direcciones locales únicas): Son las direcciones FC00::/7 (empie-
zan por 1111 110). Son muy parecidas a las anteriores con la ventaja de que, al ser más
amplia la parte variable de la dirección, es muy poco probable que dos de estas direcciones
coincidan. Por tanto, siempre que no se salga a una red pública (Internet), la probabilidad
de que dos máquinas puedan comunicarse entre sı́ es alta incluso aunque haya que atravesar
distintos enlaces o incluso sites.
Global Unicast (Direcciones globales): Son direcciones únicas en el mundo. En teorı́a, cual-
quier dirección que no caiga en ninguno de los rangos de direcciones especiales, es una
dirección global. En la práctica, hasta ahora sólo se han asignado las direcciones 2000::/3
(empiezan por 001).
En resumen los tipos existentes de direcciones son:
7.4. Organización de las direcciones en IPv6

IPv6 sigue la misma filosofı́a que introdujo IPv4: las direcciones IP están formadas por una
parte de red, común a todas las interfaces que están unidas a nivel de enlace (y por tanto
pueden comunicarse sin atravesar un router), y una parte de host, que combinada con la parte
de red identifica a cada interfaz de forma unı́voca. En IPv6, la parte de red se divide a su vez
en prefijo global e identificador de subred.
Las direcciones que no empiecen por 000 (en binario) han de tener obligatoriamente 64
bits de interfaz. Se aconseja que los valores del tamaño del prefijo global sean n= 48 bits (si se
van a crear subredes) o n= 64 bits(si sólo va a haber una red). Sin embargo, en algunos casos
particulares se utilizan prefijos globales de n¡48 bits. Por tanto, la forma de una dirección IPv6
que no empiece por 000 será:
7.5. Asignación de direcciones en IPv6

La asignación de direcciones puede ser:
Manual
Mediante DHCPv6 (RFC 3315)

Por autoconfiguración: al arrancar, cada nodo genera una dirección local al enlace o una
dirección global (según lo especificado por la RFC 2462). En este tipo de asignación, la
parte de red de la dirección generada puede ser:
• Si se ha generado una dirección local al enlace, la parte de red será FE80::/64.
• Para otro tipo de direcciones, la dirección de red se toma de anuncios periódicos que
hace el router a toda la red. En dichos mensajes, el router anuncia tanto su dirección
(para que los nodos la tomen como dirección de gateway) como el prefijo que deben
tener los nodos de la red.
Para explicar cómo se genera la parte de host, es necesario conocer las direcciones de nivel
de enlace que existen en la actualidad. Las que se suelen utilizar son dos:
• Direcciones MAC: Son un estándar del IEEE (rec. 802.1). Son direcciones de 48 bits,
únicas en el mundo.
• Direcciones EUI-64: Son un estándar más moderno del IEEE. Son muy parecidas a
las direcciones MAC, pero su tamaño es de 64 bits en lugar de 48.
En ambos casos, los dos últimos bits del primer octeto de la dirección son bits con un
significado especial. El bit número 7 es el bit global/local. Dicho bit indica si una dirección
es única en el mundo (si vale 0) o bien puede estar repetida (si vale 1). El bit de gru-
po/individual se utiliza para identificar si la dirección destino es una dirección individual
(si vale 0) o una dirección de grupo (si vale 1).
Una vez conocemos los tipos de direcciones existentes, veamos cómo se usan al generar una
dirección IPv6 por autoconfiguración:
• Si tenemos una dirección EUI-64: Se utiliza el llamado formato modificado UEI-

64. Para generar la parte de host, usamos la dirección EUI-64 que tenemos pero con
el bit global/local invertido (por eso se llama modificado).
• Si tenemos una dirección MAC: Ampliamos la dirección a 64 bits introduciendo

en el centro de la dirección MAC dos octetos: FF FE. Además, también
invertimos el bit global/local.
No es evidente a primera vista la necesidad de invertir el bit global/local. En principio, una

dirección de enlace que tenga un ámbito local se podrı́a generar a mano. Lo más probable
es que la persona que la escriba ponga por comodidad una serie de bits a 0 y al final un
valor (es decir, empezarı́a asignando ::1, después ::2...). Pero si lo hace ası́, como el bit
global/local es de los primeros, lo estarı́a poniendo a cero. Eso significarı́a que la dirección
que se esta escribiendo es única en el mundo, lo cual no es verdad ya que nos la estamos
inventando. Para evitar esta situación, se decidió que en este tipo de direcciones el bit
global/local a 0 significara que la dirección es local, y a 1 que la dirección es única en el
mundo (justo lo contrario de lo que definió el IEEE). Por tanto, es necesario invertir el bit
global/local de las direcciones del IEEE para darle el significado que nosotros queremos.
7.6. Formato de datagramas IPv6

El formato que siguen los datagramas IPv6 es el siguiente:
Versión: indica la versión del protocolo (en este caso, la 6).
Clase de tráfico: marca los datagramas según el tipo de tráfico que transportan (sensible
a retardos, de baja prioridad, etc.)
Etiqueta de flujo (Flow Label): Se asigna la misma etiqueta a paquetes que estén relacio-
nados entre sı́ (por ejemplo, a aquellos que pertenezcan a una misma conexión).
Longitud de la carga (o payload): mide lo que hay después de los 40 octetos de cabecera.
Se mide en octetos.
Next Header (siguiente cabecera): En IPv6, los parámetros opcionales se incluyen como
extensiones de la cabecera dentro de la carga. Next Header indica de qué tipo es la primera
cabecera que hay en la carga. Algunos valores son:
• 6 - TCP
• 17 - UDP
• 58 - ICMPv6
• 0 - Hop-by-hop options
• 60 - Destination options
Lı́mite de saltos (Hop Limit): equivale al TTL de IPv4. Define el número máximo de routers
que puede atravesar el paquete antes de ser descartado.
Dirección origen y destino: compuestas por 16 octetos cada una.
7.7. Cabeceras de opciones
Cabecera de opciones salto a salto (Hop By Hop Options): Esta cabecera la lee e interpretan
todos los routers que atraviese el paquete.
Las opciones se codifican mediante TLV (Tipo, Longitud, Valor). En este tipo de codifica-
ción, cada opción estará compuesta de un campo tipo de tamaño fijo, un campo longitud
de tamaño fijo y un campo valor de tamaño indicado por el campo longitud. El tipo de la
opción indica varias cosas:
• Si el router puede modificar la opción.
• Si el router no entiende la opción, indica si tiene que descartar el paquete o no.
• Si el router descarta el paquete, si debe avisar al origen con un mensaje ICMP o no.
La cabecera Hop-by-Hop tiene que tener un tamaño múltiplo de 4 octetos. En caso de

necesidad, se utiliza relleno.
Cabecera de enrutamiento (Routing): permite que el nodo origen del mensaje especifique
una serie de routers por los cuales el mensaje debe pasar obligatoriamente. Es parecido al
source routing de IPv4. Su forma es:
• Segments left (segmentos restantes): Indica cuántas direcciones de las contenidas en

el paquete quedan por atravesar. Inicialmente será N.
• Destinos: son las direcciones IP de los routers que deberá atravesar el paquete.
El funcionamiento de esta cabecera es el siguiente: inicialmente, el paquete se crea poniendo

como destino en la cabecera IP la IP del primer router por el que debe pasar
el mensaje (en condiciones normales, pondrı́amos la dirección del destino final, pero este
caso es especial). El destino 1 de la cabecera de routing será el segundo router por el que
debemos pasar, el destino 2 el tercer router... ası́ hasta llegar al destino N de la cabecera
de routing, que será la dirección IP del destino final del mensaje. Un ejemplo del
uso de esta cabecera es el siguiente:
Vemos como el paquete del ordenador con IP a router (IP ) como dirección destino en la
cabecera IP. Cuando el paquete llega al router b b, éste lo interpreta y, como el número de
segmentos restantes es 3, cuenta 3 IPs desde el final de la cabecera de routing y copia la
IP que encuenta (IP ) en el campo destino de c la cabecera IP. Al mismo tiempo, pone la
que estaba en el destino IP donde estaba IP . c Esto se hace ası́ para que el destino final
sepa por qué routers ha pasado la información. Este procedimiento se repite hasta que el
número de segmentos restantes es 0, en cuyo caso la máquina que interpreta el paquete
sabe que es para ella.
Algo a resaltar es que, aunque estemos especificando una serie de routers por los
que el paquete debe pasar obligatoriamente, entre ellos puede pasar por routers
que no hayamos especificado.
Cabecera de opciones de destino (Destination Options): Es una cabecera extremo a extremo

(sólo la ve el nodo destino, los routers intermedios no pueden interpretarla). Existe un caso
especial, en que se combina con la cabecera de enrutamiento:
Si se envı́a un mensaje con estas caracterı́sticas, los nodos de la lista de enrutamiento verán
la cabecera de opciones de destino 1 (ya que el paquete marca su IP como destino en la
cabecera IP). Sin embargo, la cabecera de opciones de destino 2 sólo la verá el nodo final.
7.8. Protocolo ICMPv6

Es una evolución del protocolo ICMP que se usaba en IPv4. En este protocolo se definen
una gran cantidad de mensajes, aunque nosotros sólo estudiaremos los mensajes que se usan para
el establecimiento de vecindades. Su código de cabecera (el que tiene que aparecer en el campo
Next Header de la cabecera anterior) es 58. La cabecera ICMPv6 tiene la siguiente forma:
donde los campos tienen el siguiente significado:
Tipo (8 bits): indica el tipo de mensaje. Si es un mensaje de error se representa con el bit
más significativo a 0; un mensaje de información se representa con el bit más significativo
a 1.
Código (8 bits): sirve para distinguir los diversos mensajes de cada tipo. Si para un cierto
tipo sólo hay un mensaje, vale 0.
Checksum (16 bits): para comprobar la integridad del mensaje.
Cuerpo del mensaje: su estructura varı́a según el mensaje que estemos transmitiendo.
En establecimiento de vecindades se usan cuatro mensajes ICMPv6 distintos:
RS (Router Solicitation, solicitud a router): Este mensaje lo envı́an los nodos a los
routers cuando necesitan conocer algún parámetro de éstos. Se envı́an con la dirección
multicast de routers como destino.
RA (Router Advertisement, anuncio de router): los routers envı́an estos mensajes

periódicamente o como respuesta a un RS. SIrve para anunciar varios parámetros: el ta-
maño máximo de paquete que soportan (MTU), si son routers de salida de la red o no...
Entre estos parámetros, el más importante es el prefijo de red. Los nodos deben conocer
este valor para poder autoconfigurarse. El mensaje RA se envı́a periódicamente con la di-
rección destino multicast de nodos. Si se envı́a como respuesta a una petición RS, se hace
con dirección destino multicast solicitada.
NS (Neighbor Solicitation, solicitud a vecino): Se utiliza este tipo de mensajes con

tres fines:
• Resolución de direcciones: en lugar de utilizar el protocolo ARP, para hallar la direc-

ción de enlace asociada a una dirección IP se envı́a un mensaje NS a la dirección
multicast solicitada correspondiente a la dirección IP que se desea resolver.
El nodo correspondiente recibirá el mensaje y responderá con un mensaje NA,
en el que indicará su dirección de nivel de enlace.
• Detección de direcciones duplicadas (Duplicate Address Detection): hemos visto que

existen métodos de configuración automática, en los que cada nodo se asigna una
dirección. Esto puede provocar una situación en la que dos nodos se asignen la misma
dirección. Para evitarlo, antes de comenzar a funcionar cada nodo envı́a un
mensaje NS para comprobar que su dirección sea única. En el mensaje NS
intenta resolver su propia IP: si nadie responde, significa que nadie tiene esa IP y
puede asignársela sin problemas. Si alguien responde, tendrá que cambiar su IP y
volver a comprobarla. Por seguridad, los mensajes se retransmiten varias veces.
• Sondeo (Probe): comprueba que un nodo esté accesible. Esto es útil, por ejemplo, si
un nodo ha estado comunicándose con otro durante un tiempo, y esa comunicación ha
terminado. Para volver a comunicarse con el mismo nodo, primero deberá comprobar
si aún sigue funcionando con la misma dirección. Para ello, enviarı́a un mensaje probe
al nodo.
NA (Neighbor Advertisement, anuncio de vecino): Se envı́a como respuesta a un

NS. También se envı́a en caso de que un nodo cambie su dirección de enlace, para anunciar
el cambio.
REDIR (Redirección): Al igual que en ISO, se envı́a un mensaje de redirección para

indicarle a un nodo la dirección correcta de nivel de red a la que tiene que asociar una IP.
Como novedad, además de dirección IP se puede incluir en el mensaje la dirección de nivel
de enlace del destino, con lo que el nodo se ahorra una resolución de direcciones.
7.9. IPv6 Móvil

IPv6 móvil, definido en las RFC 3775 y 3776, es un protocolo que permite que un nodo
(llamado MN, Mobile Node o nodo móvil) se traslade fı́sicamente pero siga recibiendo paquetes
dirigidos a él, independientemente de la red a la que esté conectado. Comencemos explicando la

terminologı́a que vamos a usar:
El nodo móvil es la máquina que se va a desplazar a través de la red. Inicialmente, per-

teneeerá a la red del home agent, que es su router por defecto. A lo largo del ejemplo, nos
comunicaremos con otra máquina, perteneciente a otra red, a la que llamaremos CN (Corres-
pondent Node, nodo correspondiente).
Cuando el nodo móvil está conectado en su red origen, tiene asignada una dirección a la
que llamaremos HA (Home Address). En este estado, el nodo se comporta como cualquier nodo
normal de la red: un mensaje dirigido al CN llevará como dirección destino la del CN, como
dirección origen la HA y se enviará al home agent para que lo enrute.
Si el nodo móvil se conecta a otra red, tendrá que cambiar su dirección a una perteneciente
a la nueva red. A esta nueva dirección la llamaremos CoA (Care-of Address, literalmente
dirección de cuidado). Para que los mensajes dirigidos a la HA sigan llegando al nodo móvil, lo
que hace el nodo móvil es establecer un túnel con su home agent. Para ello, envı́a un mensaje
BU (Binding Update, actualización de enlace) a su home agent, en el que indica su CoA.
El home agent responde con un mensaje BA (Binding Acknowledge, asentimiento de
enlace).
El túnel que hemos creado consiste en que el home agent actúa de repetidor. Cuando recibe
un mensaje IPv6 con dirección destino la dirección HA, encapsula dicho mensaje dentro de otro
mensaje IPv6 con dirección destino CoA y lo envı́a. Con eso consigue que el traslado del nodo
móvil sea transparente a la red. Para optimizar la comunicación, existe la posibilidad de que el
nodo móvil envı́e al nodo correspondiente un BU. Si el nodo correspondiente está configurado
para entender los BU, se puede establecer comunicación entre ellos. Se utilizan cabeceras de
enrutamiento para .engañar.a TCP, de modo que vea la dirección CoA como HA.
7.10. Introducción a IPsec
IPsec, definido en las RFC 4301-4309, 2403-2405 y 2410-2412, es un mecanismo que sirve
para asegurar la confidencialidad y la integridad a través de una red IP. Encripta los mensajes
y permite averiguar si han sido modificados a lo largo del trayecto.
IPsec implementa:
Protocolos de seguridad:
• AH (Authentication Header, cabecera de autenticación): sirve para verificar la inte-

gridad.
• ESP (Encapsulating Security Payload, encapsulamiento de la carga de seguridad):

sirve para confidencialidad y para integridad.
Protocolos de gestión de claves (Key Management):
• IKEv2 (Internet Key Exchange, intercambio de claves por Internet)
Algoritmos a usar, de encriptación y de hash.
7.11. Introducción a las VPN
Las VPN (Virtual Private Net, red privada virtual) son redes privadas virtuales que se
crean sobre una infraestructura pública. Es común usarlas para conectar distintas sucursales de
una empresa. Es una alternativa barata al alquiler de enlaces punto a punto. Como problemas,
presenta la seguridad (puede haber mensajes importantes viajando a travñes de una red no
segura) y el consumo de ancho de banda.

Redestelecomunicacion

Cargado por

Información del documento

Título original

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

Redestelecomunicacion

Cargado por

Copyright:

Formatos disponibles

Redes de Telecomunicación

Baquero Portero, Isidro

1. Introducción a las redes de telecomunicaciones 5

2. Redes de área extensa, WAN, Wide Area Networks 18

7. Evolución de los equipos y tendencı́as 118

Introducción a las redes de

1.1. Definición. Modelo genérico

Figura 1.1: Modelo general de una red de telecomunicaciones.

Fuente: genera información.

1.2. Eficiencia, evolución e integración

Figura 1.2: Interconexión de dos redes mediante un conmutador.

Redes públicas: RTB, X.25, TV por cable.

1.3. Elementos de una red

1.3.2. Elementos no básicos

Gestión: se encarga de los fallos (detectarlos, corregirlos...), monitorización y tarificación.

Servicios: es la parte de red que sirve para ofrecer distintos servicios.

1.4. Clasificación de las redes de telecomunicaciones en

1.4.1. Tipos básicos

Redes basadas en conmutación de paquetes: pensadas para fuentes intermitentes a ráfa-

Figura 1.3: Red de conmutación de paquetes.

1.4.2. Tipos de redes basadas en la conmutación de paquetes aten-

1.4.3. Tipos especiales de conmutación de paquetes

1.4.4. Ejemplos. Internet

Conmutación de circuitos: RTB (Red Telefónica Básica).

Conmutación de paquetes: Internet.

Veremos en profundidad el segundo ejemplo, Internet.

Protocolos: Jerarquı́a TCP/IP

Normas: RFC (IETF)

Figura 1.4: Internet Service Providers o ISPs.

Permite aplicaciones distribuidas.

Presenta dos tipos de servicios:

1.5. Retardos en redes de conmutación de paquetes

Procesamiento: se denomina tiempo de procesamiento el tiempo que tarda el conmutador en

Para estudiar el tiempo de encolado se emplea la teorı́a de colas, donde:

Número de paquetes por segundo que llegan al sistema (tasa de llegada): λ

Figura 1.5: Retardos que intervienen en una transmisión.

1.6. Revisión de los modelos de referencia: el modelo OSI

Ofrece un servicio a la inmediatamente superior.

Recibe servicios de la capa inferior a ella.

De esta forma, el modelo OSI aborda el problema de la interconexión de equipos dividiéndolo

1.6.2. Capas o niveles

Nivel 2: Enlace: Es responsable de la transferencia de información entre nodos adyacentes.

Nivel 6: Presentación: Se ocupa de la compatibilidad sintáctica (cómo se representa la infor-

Nivel 7: Aplicación: Se ocupa de la compatibilidad semántica (lo que representa la informa-

1.6.3. Comunicación entre sistemas. Primitivas

Los SAP, como ya se ha visto, proporcionan servicios a la capa inmediatamente superior, y lo

Petición (REQ, Request)

Indicación (IND, Indication)

Según el tipo de primitivas que utilice, un servicio puede ser:

No confirmado: sólo utiliza REQ e IND.

Es importante recalcar que el hecho de que un servicio sea confirmado o no confirmado es

Figura 1.7: Uso de primitivas.

1.6.4. Funciones que se pueden realizar en cada capa

Segmentación y reensamblado: Cada nivel tiene un tamaño máximo de SDU admisible.

Bloqueo-desbloqueo: Crea bloques de información. Definida en la recomendación X.200.

Multiplexión-demultiplexión: Cosiste en ofrecer el servicio de varios SAP del nivel N+1 a

Figura 1.8: Multiplexión.

Figura 1.9: Comparación OSI-TCP.

1.6.5. Comparación con la jerarquı́a TCP/IP

Redes de área extensa, WAN, Wide

En una LAN, los equipos pueden interconectarse de dos formas:

Figura 2.1: Concepto de LAN y WAN.

Cómo se observa en la fig. 2.2, si la máquina A se quisiera conectar al PC de la segunda