Redes Tele Comunica C I On

Redes de Telecomunicaci on
Baquero Portero, Isidro

Borrego Checa, Juan
C amara Mora, Carlos M
Clemente Pascual-Vaca, Emilio
M arquez Gir aldez, Laura
S anchez-Matamoros Perez, Jose
Morales Castro, Manuel

Angel
Neira Fern andez, Ruben
Ojeda Rodrguez, Maria Elena
Rodrguez Quesada, Agustn
Romero del Toro, Maria Jose
Rueda Borrego, Beltran
Serrano Mu noz, Fernando
Julio 2007
Indice general
1. Introducci on a las redes de telecomunicaciones 5
1.1. Denici on. Modelo generico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. Eciencia, evoluci on e integracion . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Elementos de una red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.1. Elementos b asicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.3.2. Elementos no b asicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Clasicaci on de las redes de telecomunicaciones en funcion de c omo act uan sus
conmutadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.1. Tipos b asicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.4.2. Tipos de redes basadas en la conmutaci on de paquetes atendiendo al fun-
cionamiento interno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4.3. Tipos especiales de conmutacion de paquetes . . . . . . . . . . . . . . . . 8
1.4.4. Ejemplos. Internet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Retardos en redes de conmutaci on de paquetes . . . . . . . . . . . . . . . . . . . 10
1.6. Revisi on de los modelos de referencia: el modelo OSI . . . . . . . . . . . . . . . 11
1.6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.6.2. Capas o niveles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.6.3. Comunicaci on entre sistemas. Primitivas . . . . . . . . . . . . . . . . . . 13
1.6.4. Funciones que se pueden realizar en cada capa . . . . . . . . . . . . . . . 16
1.6.5. Comparacion con la jerarqua TCP/IP . . . . . . . . . . . . . . . . . . . 17
1
Redes de Telecomunicaci on 2
2. Redes de area extensa, WAN, Wide Area Networks 18
2.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2. Funciones b asicas del nivel de red . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.1. Direccionamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.2. Encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3. Control de congesti on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.2.4. Integracion de redes heterogeneas . . . . . . . . . . . . . . . . . . . . . . 22
3. Direccionamiento 23
3.1. Tipos de direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.1. Clasicacion seg un el ambito o alcance . . . . . . . . . . . . . . . . . . . 23
3.1.2. Clasicacion seg un la jerarqua . . . . . . . . . . . . . . . . . . . . . . . 23
3.2. Formatos de direcciones m as 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. M aquinas 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. Difusion de mensajes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4. Integracion de redes 38
4.1. Introducci on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2. Ejemplo de integraci on de redes con IPv4 . . . . . . . . . . . . . . . . . . . . . . 39
4.3. Formato de los paquetes IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.1. Fragmentacion de paquetes IPv4 . . . . . . . . . . . . . . . . . . . . . . 41
4.3.2. Opciones m as usuales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.4. Tablas de encaminamiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5. Encaminamiento 53
5.1. Tipos de direcciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.2. Clasicaci on de mecanismos de encaminamiento . . . . . . . . . . . . . . . . . . 54
5.3. Jerarqua 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 area local (LAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.5. PROXY ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.6. C alculo de rutas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.6.1. Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.6.2. Algoritmo del camino mas corto . . . . . . . . . . . . . . . . . . . . . . . 70
5.7. Distribuci on de la informaci on . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 especcos de encaminamiento . . . . . . . . . . . . . . . . . . . . . . 84
5.8.1. Protocolos intradominio (IGP) . . . . . . . . . . . . . . . . . . . . . . . . 87
5.8.2. Protocolos interdominio (EGP) . . . . . . . . . . . . . . . . . . . . . . . 90
5.8.3. TEMA 6: Control de congestion . . . . . . . . . . . . . . . . . . . . . . 96
5.8.4. Clasicacion de los mecanismos de control de congesti on . . . . . . . . . 97
6. Capa de transporte 99
6.1. Introducci on a la capa de transporte . . . . . . . . . . . . . . . . . . . . . . . . 99
6.2. Jerarqua TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2.1. UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.2.2. TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7. Evoluci on de los equipos y tendencas 118
7.1. Introducci on a IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.2. Direccionamiento en IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
7.3. Direcciones especiales en IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
7.4. Organizaci on de las direcciones en IPv6 . . . . . . . . . . . . . . . . . . . . . . . 122
7.5. Asignaci on 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 Movil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
7.10. Introduccion a IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
7.11. Introduccion a las VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Captulo 1
Introducci on a las redes de
telecomunicaciones
1.1. Denicion. Modelo generico
Podemos denir una red de telecomunicaciones como aquella que proporciona una comu-
nicaci on eciente entre m ultiples entidades usando distintas tecnologas (electrica, electr onica,
electromagnetica...).
El modelo general de una red de telecomunicaciones (g. 1.1) se compone de:
Figura 1.1: Modelo general de una red de telecomunicaciones.
Fuente: genera informaci on.
Transmisor: transforma informaci on en se nales.
Sistema de transmisi on: transporta se nales.
Receptor: inverso del transmisor.
Destino: donde llega la informaci on.
5
1.2. Eciencia, evoluci on e integraci on
Para mejorar la eciencia usamos conmutadores, dando lugar a estructuras jer arquicas exis-
ten distintas redes dependiendo del servicio que se quiera ofrecer con dicha red (g. 1.2):
Figura 1.2: Interconexion de dos redes mediante un conmutador.
Redes p ublicas: RTB, X.25, TV por cable.
Redes privadas: Centralitas, red de datos (red de area local)
RDSI: Red unica que se concibi o para que pudiera servir para ofrecer cualquier tipo de
servicio. La tecnologa ATM es la que iba a soportar RDSI.
1.3. Elementos de una red
1.3.1. Elementos basicos
Acceso: parte de la red que va del sistema origen al primer conmutador (bucle de abonado).
Conmutaci on: conjunto de conmutadores que forman la red.
Transmision: conjunto de enlaces que une los conmutadores. Se usan tecnicas de multiple-
xi on para compartir enlaces. Al conjunto de conmutadores y enlaces se les denomina red
dorsal.
Se nalizacion: parte de la red que controla su funcionamiento. Hay dos tipos de se nalizaci on:
usuario-red, que comunica al usuario con el sistema, y red-red, que utiliza el sistema para
organizarse.
1.3.2. Elementos no basicos
Sincronizaci on: corresponde a toda la parte que se encarga de sintonizar un transmisor con
un receptor.
Gesti on: se encarga de los fallos (detectarlos, corregirlos...), monitorizacion y taricacion.
Servicios: es la parte de red que sirve para ofrecer distintos servicios.
1.4. Clasicaci on de las redes de telecomunicaciones en
funcion de c omo act uan sus conmutadores
1.4.1. Tipos basicos
Redes basadas en conmutaci on de circuitos: se basan en establecer una reserva de recur-
sos para la comunicaci on. 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 telef onicas. Sin embargo, no es adecuado para comunicacion entre orde-
nadores, ya que estos 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 conmutaci on de paquetes: pensadas para fuentes intermitentes a rafa-
gas y cuando los destinos cambian rapidamente. Utilizan multiplexion estadstica. Fig.
1.3.
Figura 1.3: Red de conmutaci on de paquetes.
1.4.2. Tipos de redes basadas en la conmutaci on 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 m as lento
si existe gran cantidad de paquetes, pero permite adaptarse mejor a los cambios de la red.
1.4.3. Tipos especiales de conmutacion de paquetes
Conmutaci on de mensajes: cuando llega a un conmutador la informaci on que se ha ido frag-
mentando en paquetes, se reensambla, se analiza y se vuelve a enviar el paquete frag-
ment andolo de nuevo. Sirve cuando queremos interconectar redes con funcionamientos
muy distintos.
Conmutaci on de celulas: los paquetes son de tama no jo y peque nos. Al ser de tama no jo,
los c alculos son mas sencillos y rapidos de realizar (incluso se pueden realizar por hard-
ware), pero la probabilidad de fragmentaci on es m as alta. Por ser de tama no peque no, la
cabecera ocupara proporcionalmente un tama no mayor, lo que disminuye el rendimiento,
pero a cambio presenta la ventaja de tener un tiempo de transmisi on menor. Un tiempo de
transmisi on menor minimiza el problema de que llegue un paquete mientras estas trans-
mitiendo. Ademas, 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:
Conmutaci on de circuitos: RTB (Red Telefonica B asica).
Conmutaci on de paquetes: Internet.
Veremos en profundidad el segundo ejemplo, Internet.
Descripcion interna
Funciona con conmutacion de paquetes. Sus componentes seran sistemas nales (hosts),
conmutadores intermedios (encaminadores o routers), enlaces de comunicacion (punto a punto,
red de area local) y otros dispositivos como repetidores o puentes.
Organizaci on
Protocolos: Jerarqua 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 peque nas compa nas. Los tier 2 proveen a los tier 3. Los
grandes proveedores, llamados tier 1 o Internet Backbone Provider (IBP), s olo dan acceso
a proveedores tier 2 o compa nas muy grandes. Los tier 1 tienen alcance internacional y
est an interconectados entre s (g. 1.4).
Figura 1.4: Internet Service Providers o ISPs.
Descripcion externa
Permite aplicaciones distribuidas.
Presenta dos tipos de servicios:
No orientado a conexi on y no able
Orientado a conexion y able.
No garantiza retardo en ninguno de los casos.
1.5. Retardos en redes de conmutaci on 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.
Transmision: el tiempo de transmision depende de la longitud del paquete (L, en bits) y de su
capacidad (C, en bits por segundo), ecuaci on 1.1.
t
transmision
=
L
C
(1.1)
Propagaci on: el tiempo de propagacion depende de la distancia que separa a los nodos emisor
y receptor (D, metros) y de la velocidad con la que se propaga la se nal (V, metros por
segundo), ecuacion 1.2.
t
propagacion
=
D
V
(1.2)
En la g. 1.5 podemos ver de forma esquem atica los distintos retardos que intervienen en
una transmision entre el equipo A y el B.
Para estudiar el tiempo de encolado se emplea la teora de colas, donde:
N umero de paquetes por segundo que llegan al sistema (tasa de llegada):
Tasa de salida del sistema:
C
L
Intensidad de traco:

(
C
L
)
. Si es 1, la cola se hace innita.
Figura 1.5: Retardos que intervienen en una transmisi on.
1.6. Revisi on de los modelos de referencia: el modelo OSI
1.6.1. Introduccion
Cuando los equipos telematicos empezaron a conectarse en red hace unas decadas, cada
fabricante desarroll o 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 desarroll o 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 interconexion de equipos dividiendolo
en varios problemas menores. Esta solucion es menos eciente que una solucion directa (una
que aborde simultaneamente todos los procesos implicados en la comunicaci on), pero es mucho
m as sencilla de implementar. Ademas, tiene la gran ventaja de que las distintas capas pueden
ir desarrollandose por separado, sin que ello repercuta en el resto de capas, por lo que podra
cambiarse toda la infraestructura de una capa determinada sin que el resto se enterara del
cambio.
Existen algunos terminos que conviene tener claros al hablar del modelo OSI:
Entidad: Cada capa se descompone en entidades. Una entidad no es m as que un modulo es-
pecializado que realiza una o varias de las funciones que le corresponden a dicha capa. Si
antes decamos que el modelo OSI aborda el problema de la interconexion de equipos di-
vidiendolo en varios problemas menores, en cada capa esos problemas menoresvuelven
a dividirse en problemas mas peque nos a un.
PDU (Protocol Data Unit): Se denomina PDU a la unidad que intercambia informaci on
entre entidades pares de distintos sistemas (entidades de la misma capa pero en maquinas
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.
en
tre dos capas.
Primitivas: Son las ordenes que se envan entre capas contiguas. Son necesarias para poder
acceder al servicio.
1.6.2. Capas o niveles
Nivel 1: Fsico: Se encarga de transmitir la se nal por el medio fsico. Controla par ametros
como niveles de tensi on, tipos de se nal, etc. Libera a las capas superiores de las funciones
que impongan los diferentes medios de transmisi on.
Nivel 2: Enlace: Es responsable de la transferencia de informaci on entre nodos adyacentes.
Nivel 3: Red: Ofrece comunicaci on extremo a extremo poniendo de acuerdo a los sistemas
intermedios.
Nivel 4: Transporte: Es muy similar al nivel de red, ya que tambien se ocupa de la transfe-
rencia de informaci on extremo a extremo. La diferencia est a en que la capa de transporte
lo hace independiente de cualquier nodo intermedio, mientras que la capa de red realiza su
funci on coordin andolos. Ofrece servicios que la capa de red no ofrece:
Fiabilidad: por si la capa de red ofrece un servicio no able, transporte puede emular
uno able si se requiere.
Orientaci on a conexi on.
Multiplexi on: el nivel de red puede ofrecer una sola comunicaci on de una maquina a
otra, mientras que el nivel cuatro puede a nadir multiplexi on para tener mas canales.
Nivel 5: Sesi on: Ofrece mecanismos para organizar y sincronizar dialogos entre maquinas. Per-
mite a las aplicaciones marcar el progreso del dialogo (insertando puntos de sincronismo)
y determinar que sistema est a en posesion del turno, as como retomar un di alogo que se
haya interrumpido (por ejemplo, si hay alg un error en la transmisi on).
Nivel 6: Presentaci on: Se ocupa de la compatibilidad sint actica (c omo se representa la infor-
maci on). Para ello ofrece una forma can onica de representar informacion independiente a
la implementaci on de los distintos sistemas.
Nivel 7: Aplicaci on: Se ocupa de la compatibilidad sem antica (lo que representa la informa-
ci on).
1.6.3. Comunicaci on entre sistemas. Primitivas
Las entidades residentes en una capa necesitan comunicarse con las entidades gemelas re-
sidentes en otros sistemas. Dicha comunicacion se realiza mediante el intercambio de mensajes
denominados PDU.
Aunque desde un punto de vista logico cada capa se comunica directamente con su equi-
valente de otro sistema, la realidad es que cada capa va pasando la informacion que quiere
transmitir a la inferior, hasta llegar a la mas baja (nivel fsico), que es la unica que se comunica
realmente. Para ello, seg un la informacion va atravesando de forma descendente las distintas
capas del modelo, se van a nadiendo encabezamientos que contienen la informaci on de control.
El conjunto resultante se transmite por el canal, y en el destino seguir a el camino inverso, es
decir, cada encabezamiento ser a utilizado s olo por la capa receptora del mismo nivel; los en-
cabezamientos destinados a las capas superiores son completamente ignorados, permitiendo la
evoluci on independiente de cada una de las capas.
Como ilustra la g. 1.6, cuando una capa quiere mandar informacion 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 traves del SAP, generando un SDU (Service Data Unit) que pasa a
dicha capa. A este N-SDU se le a nade una cabecera llamada PCI (Protocol Control Information).
La PCI contiene informacion que solamente es util para la capa par, de modo que cuando una
capa recibe una PDU, extrae la PCI, la interpreta y enva 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:
Petici on (REQ, Request)
Indicaci on (IND, Indication)
Respuesta (RESP, Response)
Conrmaci on (CONF, Conrmation)
Seg un el tipo de primitivas que utilice, un servicio puede ser:
No conrmado: s olo utiliza REQ e IND.
Conrmado: usa los 4 tipos, REQ, IND, RESP y CONF.
Por otro lado, si atendemos al tipo de conexion, los servicios pueden clasicarse en:
Orientados a conexi on (CO, Connection Oriented): necesitan establecer una conexi on entre
emisor y receptor antes de enviar los datos.
No orientados a conexi on (CL, Connectionless).
Es importante recalcar que el hecho de que un servicio sea conrmado o no conrmado es
totalmente independiente de que sea CO o CL. Aunque algunas de las combinaciones puedan pa-
recer extra nas, pueden darse cualquiera de las 4 posibilidades que podran obtenerse al combinar
el tipo de primitivas utilizadas y la orientaci on a conexi on.
De forma esquematica, el funcionamiento de las primitivas sera el de la g. 1.7.
Figura 1.7: Uso de primitivas.
El envo de primitivas lleva asociado, en general, la generacion de PDUs, pero no tiene por
que. Por ejemplo, la m aquina B puede aprovechar un paquete que contenga una peticion suya
hacia A e incluir en dicho paquete una respuesta de B a una petici on 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 (seg un el nivel de errores de cada capa), ya que el control
de errores consume recursos del sistema Habitualmente se realiza en las capas bajas: fsica,
de enlace, de red y de transporte.
Control de ujo: Si un receptor se ve desbordado por la informaci on que recibe (le llegan m as
datos de los que es capaz de procesar), puede pedirle a un emisor que se frene.
Establecimiento de la conexi on Dentro de un mismo sistema puede haber capas cuya co-
municaci on este orientada a conexi on y capas que no, dependiendo de lo que interese al
dise nar el sistema.
Segmentaci on y reensamblado: Cada nivel tiene un tama no m aximo 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 informaci on. Denida en la recomendacion X.200.
Concatenaci on-separaci on.
Multiplexion-demultiplexion: Cosiste en ofrecer el servicio de varios SAP del nivel N+1 a
traves de un SAP del nivel N (g. 1.8). Se usa de forma habitual en servicios CO.
Figura 1.8: Multiplexion.
Figura 1.9: Comparacion OSI-TCP.
1.6.5. Comparaci on con la jerarqua TCP/IP
La Jerarqua TCP/IP solo tiene 5 capas, cuya correspondencia con las 7 de la pila OSI es
la de la g. 1.9.
Captulo 2
Redes de area extensa, WAN, Wide
Area Networks
2.1. Introducci on
Existen varias formas de conectar varios ordenadores:
Punto a punto: cada ordenador se conecta directamente al resto, mediante un cable fsico
exclusivo.
Red de area local (RAL o LAN): Hablamos de una red de area local cuando tenemos varios
equipos interconectados de modo que pueden comunicarse entre s sin necesidad de pasar
por conmutadores y/o encaminadores. C omo se observa en la g. 2.1.
En una LAN, los equipos pueden interconectarse de dos formas:
Si todos los equipos trabajan con el mismo nivel fsico (por ejemplo, todos se conectan
a traves de interfaces Ethernet), para interconectarlos usamos un repetidor (hub).
Dicho dispositivo solo presenta funciones de la capa 1 (fsica).
Para conectar equipos que utilizan interfaces no compatibles se utiliza un puente (en
ingles, bridge). El puente presenta funciones de las capas 1 y 2 (fsica y enlace).
Red de area extensa (RAE o WAN): para interconectar varias redes de area 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 signica que puede encaminar traco. Adem as de encaminar, puede controlar y ltrar
el traco que pase por el. Al unir varias redes LAN con encaminadores, obtenemos una red
de area extensa.
C omo se observa en la g. 2.2, si la m aquina A se quisiera conectar al PC de la segunda
red, tendra que seguir el siguiente camino: Saldra de la capa 7 del PC A, pasara por la capa 1
del hub, por la capa 3 del router, por la capa 2 del bridge y de all pasara a la capa 7 del PC.
De forma m as esquematica, una WAN se puede representar como en la g. 2.3.
No hay que confundir el servicio ofrecido por nivel de red (orientado a conexi on o no
orientado a conexi on) con el funcionamiento interno de los encaminadores (circuito virtual o
datagrama). Normalmente, orientado a conexion se relaciona con circuito virtual, pero podemos
tener TCP (que es orientado a conexi on) sobre datagramas.
2.2. Funciones basicas del nivel de red
Figura 2.2: Comunicacion atravesando una WAN.
Nota: Saber cuales son las funciones basicas del nivel de red es concepto muy basico e
importante de cara al examen.
2.2.1. Direccionamiento
Identicaci on unvoca de los nodos de la red. Las direcciones son unicas en todo el nivel de
red. Si el enlace es punto a punto no hacen falta direcciones.
2.2.2. Encaminamiento
B usqueda 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 cuales son los nodos vecinos y adyacentes.
Distribucion de informaci on: distribuir la informacion que cada encaminador posee.
Calculo de rutas: se calculan rutas con la informaci on que posee el encaminador y la que le
envan los otros.
Figura 2.3: Esquema generico de una WAN.
Nota: Saber cu ales son las partes que componen el encaminamiento es concepto muy
b asico e importante de cara al examen.
2.2.3. Control de congesti on
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 informacion adicional en los paquetes.
Figura 2.4: Comportamiento ideal, con info. de control y real en situaci on de congesti on.
Como se ilustra en la g. 2.4, los diferentes comportamientos frente a la situaci on de con-
gesti on son los siguientes:
En el caso ideal la informaci on que sale es igual a la que entra. Esto ocurre hasta que llegamos
al punto de saturacion del sistema, en que independientemente de la informacion que entre,
la salida es la misma, el m aximo que permita el sistema.
En el caso ideal con informacion de control se pierde un poco de rendimiento al tener en
cuenta que parte de los recursos se dedican a la comunicaci on entre conmutadores.
En el caso real entran en accion dos efectos que no tenamos en cuenta anteriormente:
que algunos paquetes se pierden y es necesario retransmitirlos,
y que el sistema no posee una memoria innita, sino limitada.
Por tanto, pasado un punto (punto de congesti on), el sistema empieza a perder paquetes
debido a que su memoria est a llena. Ademas, se puede llegar a un punto en que todos los recursos
del sistema se dediquen al control de congestion, y perdamos la capacidad de transmitir (punto
de bloqueo). Es necesario buscar un compromiso entre congesti on y rendimiento. Lo mejor sera
una menor congestion a costa de un menor rendimiento.
2.2.4. Integraci on de redes heterogeneas
El mejor sitio para conectar redes heterogeneas es el nivel de red, ya que es dicho nivel el
que posee la informaci on m as util para poder traducir los paquetes entre una red y otra.
Captulo 3
Direccionamiento
3.1. Tipos de direcciones
3.1.1. Clasicaci on seg un el ambito o alcance
Locales: las direcciones est an restringidas a un cierto entorno. Sera suciente 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 unicas que los fabricantes asignan a cada tarjeta de red, aunque solo hace falta que
sean unicas dentro de una misma LAN.
3.1.2. Clasicaci on seg un la jerarqua
Jerarquicas: si dos de estas direcciones tienen una parte com un, los caminos que deben
seguirse para llegar a ellas tambien tienen una parte com un.
Planas: coincidencias en una parte de las direcciones no implican que los caminos a recorrer
vayan a tener una parte com un. Ej. Dos tarjetas de red del mismo fabricante comparten los
24 primeros bits de su direcci on MAC, y no tienen por que instalarse en la misma subred.
23
3.2. Formatos de direcciones mas extendidos
3.2.1. IPv4
Introducci on
Se trata de direcciones globales y jer arquicas de 32 bits (4 octetos). Tienen dos partes, red
y host (tambien llamadas subred y maquina, respectivamente). Todas las m aquinas cuya parte
de red coincida, deben poder comunicarse directamente sin pasar por un router; dicho de otro
modo, esas m aquinas podran comunicarse mediante el nivel de enlace. En ese caso se dice que
esas maquinas son directamente accesibles.
Clases de direcciones IP. Direcciones especiales
Existen 3 tipos fundamentales de direcciones IPv4, que se distinguen seg un 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 n umero m aximo de direcciones que podemos conseguir son 16777216.
0XXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX
Clase B: La parte de red la foman los 16 primeros bits. El n umero m aximo de direcciones
son 65536.
10XXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX
Clase C: La parte de red la foman los 24 primeros bits. El n umero maximo de direcciones
son 256.
110XXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX
Adem as de estas tres fundamentales, existen otras dos clases de direcciones, aunque su uso
est a poco extendido:
Clase D: direcci on de grupo (multidifusi on o multicast). Sirven para enviar un mismo
datagrama simultaneamente a varios destinatarios de un mismo grupo. Su formato es el
siguiente:
1110XXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX
Tienen dos particularidades:
No pueden usarse como direccion de origen, solo de destino.
Necesitan usar el protocolo IGMP para ser encaminadas. Esto signica que solo se
podran usar estas direcciones entre redes que esten unidas por routers que ha-
blenmulticast, lo que en la practica ocurre muy pocas veces.
Clase E: este tipo de direcciones est an 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 especco,
independientemente de lo que pudiera indicar a priori su clase:
255.255.255.255 - Direcci on de difusion general (tambien llamada de difusi on local o
limitada): cuando se enva un datagrama con esta direccion de destino, la tarjeta de red lo
enva a todos los nodos de la red local. Si la LAN esta interconectada con otras mediante
un router, este NO retransmite el datagrama fuera de la red.
127.xxx.xxx.xxx - Direccion reexiva: cuando se enva un datagrama a esta direccion,
vuelve a la misma m aquina que lo envi o. Sirve generalmente para realizar pruebas y
diagn osticos del sistema.
Direcciones de uso privado - no tienen por que ser unicas, esto es, s se pueden repetir
dentro de distintas redes locales, pero est an 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 m aquinas que esten dentro de una red local direccionadas con una direccion
privada puedan comunicarse con otras redes remotas a traves 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 validas para poder ser enviadas a traves de una WAN.
Mascaras
El esquema de direccionamiento de IPv4 que acabamos de ver (denominado por clases o
classful) es muy comodo y sencillo de gestionar, pero tiene el inconveniente de ser poco exible.
Por ello surgieron las mascaras (y su implementacion oblig o a realizar ciertas modicaciones
en los protocolos de encaminamiento, como veremos).
Una m ascara no es mas que un grupo de 32 bits divididos en 4 octetos (como las direcciones
IPv4) que indican hasta donde llega la parte de red de una direcci on dada. Su formato es el
de una serie de unos seguido de una serie de ceros (salvo los casos lmite 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
Tambien pueden expresarse mediante una notacion compacta, que consiste en poner una
barra seguida del n umero de unos que tiene la mascara justo tras la direcci on a la que se
aplica. Por ejemplo, para aplicar la mascara anterior a la direcci on 138.4.3.120 podramos usar
indistintamente:
138.4.3.120/255.255.255.128 o 138.4.3.120/25
Las macaras pueden usarse de diversas maneras para dar mayor exibilidad al sistema de
direccionamiento IPv4. Veremos algunas de estas formas con mayor detalle, y otras simplemente
las nombraremos.
Subnetting con subredes homogeneas (FLSM - Fixed Length Subnet Mask)
Inicialmente se desarroll o dentro de algunas grandes empresas que lo empleaban para
optimizar sus redes, pero acabo convirtiendose en un est andar.
El esquema classfulque acabamos de ver presenta varios problemas:
Las direcciones de clase A est an sobredimensionadas, ya que pueden albergar millones
de hosts, lo que difcilmente una tecnologa LAN podra soportar. Ademas, son muy
escasas, y por tanto caras.
Por otro lado, las direcciones de clase B tambien son demasiado grandes para ser
empleadas como unidad mnima. Por ejemplo, si una compa na tiene 2000 m aquinas,
necesitar a una direccion B, que le permitir a direccionar 65536 m aquinas. Como vemos,
esto es muy ineciente, ya que se desperdician m as de 60000 direcciones.
No permite el fraccionamiento interno de la red; si se quiere aislar el tr aco entre dos
grupos de m aquinas, es necesario asignar una direcci on a cada grupo.
El subnetting permite introducir routers dentro de una LAN y realizar subredes dentro de
una misma direcci on de red tipo B (te oricamente puede usarse tambien 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 atr as con los esquemas de direccionamiento origi-
nales de IPv4), pero desde dentro de la red es como si se hubiera dividido en varias LANs
m as peque nas, lo que permite gestionar el traco de red mucho mejor.
Su funcionamiento es muy simple: se trata de dividir el campo host de una direccion 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 m ascara, que
debera tener tantos unos seguidos como el campo de red originalmas el n umero de bits
que queramos ampliarlo. Es mas f acil verlo gr acamente en la g. 3.2.
Figura 3.2: Ejemplo de subnetting.
Al aplicar la m ascara, aparecen nuevas direcciones reservadas:
Direcci on de la subred: IP AND MASK
Direcci on de difusi on de la subred: IP OR (MASK negada)
La direcci on de subred no se usa (no est a asignada a ning un host de la red, s olo se uti-
liza para crculos de direccionamiento). En cambio, la direccion de difusi on de la subred
s; conviene resaltar que, a diferencia de la direccion de difusion general, la direcci on de
difusi on de subred s puede emplearse para transmitir datagramas a equipos que no est an
en la misma red fsica, pudiendo atravesar routers (siempre que est an en la misma subred).
Cada subred ira desde la (direcci on de subred+1) hasta la (direcci on de difusi on de la
subred -1), por lo que cada una tendra:
n
o
direcciones = 2
LongitudCampoHost
2 (3.1)
Desde el exterior, no habr a diferencia alguna, pero internamente el router tendr a un ma-
yor control sobre el tr aco en cada subred; por ejemplo, cuando se indica la direccion de
difusi on de la subred, el datagrama debe llegar a todos los nodos de la subred, pero no sale
fuera de esta.
Subnetting con subredes no homogeneas (VLSM-Variable Length Subnet Mask)
La principal restricci on del subnetting que acabamos de ver es que la mascara debe ser la
misma para todas las subredes. Esto es lo mismo que decir que todas las subredes tendr an
el mismo tama no, ya que en todos los casos los campos de subred y host tendr an el mismo
n umero de bits. Con este esquema se desaprovechan muchas direcciones.
Con VLSM se pretende dar a un m as exibilidad, ya que permite que distintas subredes
tengan m ascaras distintas (permite crear sub-subredes, por decirlo de alguna manera),
permitiendo de esta manera ajustar mas los tama nos de las subredes al n umero de maquinas
que estan dentro de ellas y desaprovechando menos direcciones.
El esquema VLSM no es compatible con el esquema classful, ya que es necesario modicar
el protocolo de red para que pueda transportar las m ascaras de las subredes adem as de las
direcciones IP.
No veremos nada m as acerca de este esquema de direccionamiento.
Supernetting
Supongamos que se desea montar una red con 900 equipos. Para poder direccionarla, una
direcci on de clase C (254 hosts) sera insuciente, pero usar una de clase B (65536 hosts)
implicara desperdiciar miles de direcciones utiles. Esta situaci on se dio mucho, pues redes
de tama no medio se vean obligadas a pedir una direccion de clase B a pesar de desapro-
vechar la mayor parte del espacio de direcciones, lo que llev o a un rapido agotamiento de
este tipo de direcciones.
El supernetting naci o como soluci on a este problema: b asicamente consiste en la asociaci on
de varias direcciones consecutivas (normalmente de clase C) para formar una especie de
super-red(en contraposici on al termino subred) mayor. La forma de hacerlo es sencilla:
se toman varias direcciones consecutivas y se les asocia a todas la misma mascara. El
router solo deber a recordar la primera direcci on del grupo y la m ascara (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
ser a exactamente igual salvo por los ultimos bits. Supongamos que en nuestro caso el campo
de red de la primera direcci on acaba con los bits 00; de esta forma, las tres direcciones
siguientes acabar an en 01, 10 y 11, pero el resto del campo de red ser a exactamente igual
al de la primera direccion.
Figura 3.3: Ejemplo de supernetting
Como puede verse, el supernetting tiene una restriccion: las direcciones s olo 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 m ascaras. 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 fusion
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 caractersticas 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, adem as de la
direcci on, la m ascara.
Los protocolos de enrutamiento deben ser capaces de transportar las m
00e1scaras.
Permite ajustar mas el tama no de las redes al necesario, desaprovechando menos
direcciones, gracias al uso de m ascaras de tama no variable.
3.2.2. Otros esquemas de direccionamiento
ISO/NSAP
Sus direcciones tienen longitud variable, hasta un maximo de 20 octetos.
X.121
Se usa en redes X.25. La direccion esta compuesta por dgitos, no por octetos, hasta un
tama no m aximo de 14 dgitos, y consta de dos campos:
TERMINAL (10 dgitos) + RED (hasta 4 dgitos)
Los dgitos del campo de red tienen signicado geogr aco, ya que identican al pas.
E.164
Propia de la red telef onica actual. Se compone de un maximo de 15 dgitos, que se dividen en
tres campos. Cuando se usan estas direcciones para la interconexi on de redes tienen el siguiente
formato:
PA
IS (3 dgitos) + Codigo de identicaci on (entre 1 y 4 dgitos) + n

o
de abonado (12-X
dgitos)
F.69
Se usa en la red Telex.
IPv6 o IPng (nueva generaci on)
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 direcci on lleva dos puntos seguidos de otros dos (::), indica que la cantidad de cifras
hexadecimales que faltan son todos ceros en esa posici on (4 ceros, 8 ceros, etc). Por ejemplo:
1234:5678:90AB:0000:FCB7:0000:0000:FFA7
En este caso vemos como nos faltara ocho ceros y los pondramos en la posicion de los :: como
en el primer ejemplo. No podramos reemplazar los primeros cuatro ceros (negrita) a la vez que
los ultimos ocho poque no sabramos que cantidad de ceros iran en cada posicion.
Adem as se pueden indicar los ultimos 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 solo host.
Multicast: como IPv4, dirigida a varios host.
Anycast: es como si fuese una direccion de grupo pero con que llegue a uno del grupo es
suciente.
3.3. Algunos ejemplos de funcionamiento de IPv4
3.3.1. Maquinas directamente accesibles
Supongamos la situacion de la gura 3.4 El equipo A no conoce la mascara de B, s olo 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:
IP
a
&MASC
a
(3.2)
IP
b
&MASC
a
(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 ser an de la forma que indica la gura 3.5:
Si ambos resultados no son identicos, el ser a el encaminador el que tenga que encargarse
de hacer llegar los datos a B, y los datagramas que salen de A quedaran como la gura
3.6:
Para poder realizar comunicaciones a traves 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
direcci on hardware (Ethernet MAC) que corresponde a una determinada direccion IP. Para ello
se enva un paquete (ARP request) a la direcci on de multidifusi on de la red (broadcast (MAC
= )) conteniendo la direcci on IP por la que se pregunta, y se espera a que esa
m aquina (u otra) responda (ARP reply) con la direcci on Ethernet que le corresponde. Cada
m aquina mantiene una cache con las direcciones traducidas para reducir el retardo y la carga.
ARP permite a la direcci on de Internet ser independiente de la direcci on Ethernet, pero esto
solo funciona si todas las m aquinas lo soportan.
3.3.2. Subnetting
Supongamos el rango de direcciones denido por: 193.147.160.0/21. El n umero total de
direcciones que tendremos disponible, teniendo en cuenta que hay que reservar dos para direcci on
de red y la de difusi on sera de:
2
3221
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 gura 3.7.
La primera, de 512-2=510 usuarios se podra direccionar de la siguiente forma (hay m as de una
soluci on posible):
Figura 3.7: Ejercicio 1
193.147.160.0/23 Dir de subred: 193.147.160.0 Dir de difusi on: 193.147.161.255
La segunda de los mismos usuarios sera:
Y la tercera de 1024-2=1022 usuarios sera:
En realidad a todas las subredes habra que quitarle un usuario mas, 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 direcci on del rango de la subred. Visto desde fuera de la red,
todas las subredes comparten los 21 primeros bits de la direccion 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 m ascaras de los 3 equipos es la misma:
255.255.255.248 (29 bits a uno). Figura 3.8.
Figura 3.8: Ejercicio 2
En teora, podramos pensar que, estando en la misma red local, todos los equipos deberan
poder comunicarse directamente a traves del nivel de enlace (estar directamente accesibles).
Aunque esto debera ser as, lo cierto es que el uso de mascaras puede hacer que no siempre sea
posible.
En nuestro ejemplo, si A quiere enviar un datagrama a B o C, lo primero que hara sera
comprobar sus direcciones con su mascara, con lo que obtendra:
IP
a
&MASC
a
= 150,214,4,0 (3.5)
IP
b
&MASC
a
= 150,214,4,8 (3.6)
IP
c
&MASC
a
= 150,214,4,8 (3.7)
Si A quiere mandar algo a B o C debe enviarlo al router, ya que interpreta que no est an
accesibles. Si B quiere enviar algo a C lo puede hacer directamente sin pasar por el encaminador.
Por tanto, el router deber a tener dos interfaces de red, que seran 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 denir lo siguiente:
Direcci on de subred y de difusi on.
Cu al es la mejor direcci on de subred y mascara que agrupe a las tres?
3.3.5. Difusi on de mensajes
En este ejemplo, vemos c omo el ordenador A enva un paquete a tres direcciones de difusion
distintas. En el caso de los paquetes enviados a 181.168.7.255 (la direccion de difusi on de la
subred), el paquete llega a todas las m aquinas de la subred. Es el mismo caso que con el paquete
enviado a 255.255.255.255 (la direcci on de difusi on 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 reenva. Figura 3.9.
Figura 3.9: Reenvo de los paquetes de difusion
El caso del paquete dirigido a 173.15.23.255 es diferente. El router, al ver que la direccion
de difusi on 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 sera recibido por todos los componentes de
dicha subred.
Captulo 4
Integraci on de redes
4.1. Introducci on
Cuando se dise na una red de datos se desea sacar el maximo rendimiento de sus capacidades.
Para conseguir esto, la red debe estar preparada para efectuar conexiones a traves de otras redes,
sin importar que caractersticas posean.
El objetivo de la Interconexi on de Redes (internetworking) es dar un servicio de comunica-
ci on de datos que involucre diversas redes con diferentes tecnologas de forma transparente para
el usuario. Este concepto hace que las cuestiones tecnicas particulares de cada red puedan ser
ignoradas al dise nar las aplicaciones que utilizar an los usuarios de los servicios.
Algunas de las ventajas que plantea la interconexi on de redes de datos, son:
Compartici on de recursos dispersos.
Coordinaci on de tareas de diversos grupos de trabajo.
Reducci on de costes, al utilizar recursos de otras redes.
Aumento de la cobertura geogr aca.
Los dispositivos de interconexi on de redes sirven para superar las limitaciones fsicas de los
elementos b asicos de una red, extendiendo las topologas de esta.
Como vimos en temas anteriores, el nivel de red es el m as apropiado para integrar distintas
redes. En este tema vamos a ver de que forma podemos conectar redes heterogeneas, centrandonos
fundamentalmente en las redes TCP-IP.
38
4.2. Ejemplo de integraci on de redes con IPv4
Supongamos que queremos comunicar dos m aquinas distantes. Como puede verse en la
gura 4.1, el circuito fsico que hay entre ambas atraviesa redes de distinto tipo:
Figura 4.1: Ejemplo de interconexi on de una red heterogenea. Nota: CNLP (Connection Less
Net Protocol)
Desde el punto de vista de los equipos que se comunican, lo m as sencillo sera usar un
solo protocolo com un, sin que tuvieran que lidiarcon los distintos tipos de redes que hay entre
ambos; y justamente eso es lo que se hace al usar IP: cada m aquina debe preocuparse unicamente
de generar un paquete IP indicando, principalmente, su propia direccion IP y la direcci on IP de
destino, y sera el protocolo el que se preocupe de llevar los datos desde el origen al destino a
traves de cualesquiera redes fsicas que haya entre ambos.
Para que podamos usar IP sobre cualquier tipo de red se necesita un metodo de resolucion
de direcciones. En nuestro ejemplo, necesitaramos un metodo mediante el cual el ordenador A
fuera capaz de obtener la direcci on X.25 del router R1 a partir de su IP; una vez en R1, que
encontrara la direcci on ethernet del router R2; y nalmente, una vez en R2, que encontrara
la direcci on CLNP del equipo B. Para ello se usa ARP, que funciona de la siguiente manera:
Cuando un ordenador quiere enviar un paquete a una direccion IP de un router u otro PC de su
misma red, primero enva un mensaje ARP (que es de difusi on) preguntando a que direcci on de
nivel de enlace pertenece esa IP (direccion de nivel de red). El router correspondiente respon-
der a indicando su MAC (su direccion 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 gura 4.2:
Figura 4.2: Cabecera IP
Las 5 primeras las (primeros 20 octetos) son lo que se denomina la parte ja de la cabecera,
y siempre ir an en cada datagrama, de modo que el tama no mnimo de cada datagrama IP es de
20 octetos. A continuaci on vendra un campo opcional de tama no variable, y nalmente, si los
hubiera, los datos (tambien de tama no variable). Veamos una descripci on detalla de cada uno
de los campos:
Version (4 bits): versi on del protocolo. Para IPv4 aparecer a un 4.
Logitud de la Cabecera (4 bits): indica, en grupos de 4 octetos, el tama no de la
cabecera IP (parte ja+opciones). Dado que el tama no mnimo es 20 octetos, el valor
mnimo de este campo es 5.
ToS=Type of Service (8 bits): inicialmente era un campo opcional que los routers
antiguos ignoraban, pero hoy en da se utiliza para la tecnologa QoS (Quality of Service,
calidad de servicio). En concreto se utiliza en los Servicios Diferenciales. En estos, el TOS
identica el tipo de traco que lleva cada paquete (Tranferencia de cheros, voz sobre
IP, etc.). As, cada router tratar a 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 dar an prioridad a los paquetes VoIP pero los desechar an
si tienen que hacerlos esperar demasiado.
Longitud total del paquete (16 bits): indica, en n umero de octetos, el tama no total del
datagrama IP, incluyendo cabecera y datos. Sirve para que el nivel IP del destino sea capaz
de descartar el relleno a nadido por niveles inferiores. La longitud maxima del paquete es
de:
2
16
1 = 65535 octetos. (4.1)
Identicador (16 bits), Flags (3bits) y Desplazamiento y Oset (13 bits): estos
3 campos se utilizan para controlar la fragmentacion de los paquetes, y se describen con
detenimiento en el apartado de Fragmentacion 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 innitos saturando la red.
Protocolo (8bits): contiene un identicador 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 m as que la suma de paridad de todos los bits de la cabecera.
Opciones: se describen en el apartado de Opciones mas usuales.
4.3.1. Fragmentaci on de paquetes IPv4
Dado que los paquetes IP pueden atravesar redes de muy distinto tipo, cada una con un
tama no m aximo de paquete, a menudo ocurre que el tama no del paquete IP a enviar es de-
masiado grande y hay que dividirlo en trozos m as peque nos antes de pasarlo al nivel inferior.
Esto es lo que se conoce como fragmentacion de paquetes. Es evidente que en el receptor, los
paquetes deberan volver a unirse hasta obtener los paquetes IP originales, en lo que se denomina
reensamblado.
Veamos un primer ejemplo sencillo de fragmentaci on: supongamos que el router A quiere
enviarle al router B un paquete IP que contiene 3980 Bytes (octetos) m as los 20 Bytes de cabecera
y que nuestro nivel inferior acepta datagramas de, como maximo, 1500 Bytes. Figura 4.3.
Figura 4.3: Ejemplo de fragmentaci on
El router A divide los 3980 Bytes de datos en 3 fragmentos, cada uno con un tama no
m aximo de 1480 Bytes. De esta forma obtenemos 2 paquetes de 20+1480=1500 Bytes y uno de
20+1020=1040 Bytes. Notense varias cosas:
La cabecera del paquete original (el de 4000 Bytes) no se incluye en los fragmentos.
Los paquetes nales no deben superar el tama no maximo incluyendo las nuevas cabeceras.
Por eso hemos dividido los datos en paquetes de 1480 Bytes como maximo, para que al
a nadir la cabecera IP no superemos los 1500 Bytes.
Si sumamos, todos los Bytes nales, incluidas las cabeceras, vemos que el tama no total se
ve incrementado, ya que cada nuevo fragmento a nade una nueva cabecera.
Es importante observar que la fragmentaci on de un paquete puede darse en cualquier parte
del caminoque siguen los paquetes desde el emisor hasta el receptor, pero el reensamblado solo
se efect ua en el receptor.
El protocolo IPv4 implementa un sistema para controlar la fragmentaci on 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 fragmentacion, y que ser an de vital importancia
a la hora del reensamblado. Figura 4.4.
Figura 4.4: Campos de control de la fragmentaci on
Veamos una descripci on detallada de cada uno:
Identicador (16bits): es un identicador unvoco del datagrama original antes de frag-
mentar (en el ejemplo el de 4000 Bytes). Se usa cuando se solicitan reenvos. Debe ser
unico a nivel de pareja IPorigen/IPdestino. Para ello, el origen lleva un contador interno
con el que numera cada paquete que enva e incrementa el contador en uno. Para evitar
confusiones en caso de que el sistema se caiga y restituya demasiado rapido y se mezclen
n umeros, el contador no empieza en cero, sino en una cifra aleatoria. Adem as, 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 habra confusi on, ya
que el ultimo paquete que us o el identicador ya no estara en la red.
Flags o banderas (3 bits): se trata de tres bits indicadores, cada uno con una funci on:
Cero: siempre a cero (no tiene funcion asignada).
MF (More Fragments): vale 0 en el ultimo fragmento (no hay m as fragmentos
detr as) y 1 en otro caso. Si el datagrama es unico (no hubo fragmentacion) tambien
vale 0. Cada vez que un datagrama se fragmenta, se pone el MF a uno en todos los
fragmentos salvo en el ultimo, que se le pone el del datagrama del que proviene.
DF (Dont Fragment): indica al router que no debe fragmentar el paquete en
ning un caso. En el caso de no poderse enviar un datagrama tan grande, ser a desechado
por el router.
Oset 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
querr a decir que van 100x8=800 bytes. Esto se debe a que s olo disponemos de 13 bits
para denir el oset, que en muchos casos pueden ser m as que insucientes.
Se comienza a contar el Oset 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,
tendr an el Oset denido con respecto al datagrama original del que partieron todos
y no con respecto al fragmento justo anterior.
Para ilustrar esto con m as detalle vamos a suponer que A enva el primer paquete por el
router de arriba, sin problemas de fragmentacion, mientras que los paquetes 2 y 3 van a ser
enviados por B, donde vuelve a surgir la necesidad de fragmentaci on, como se aprecia en la
gura 4.5.
Figura 4.5: Ejemplo de fragmentaci on m ultiple
Veamos de forma detallada y paso a paso el desglose de las cabeceras de fragmentaci on,
con los valores que iran tomando en cada paquete fragmentado. Originalmente, en el emisor,
no tenemos m as que un solo datagrama, y los valores de los campos de fragmentacion de su
cabecera seran los que se muestran en la tabla 4.3.1:
Paquete 1
Cabecera 20 octetos
Datos 3980 octetos
Oset 0
MF 0 (por ser el unico paquete existente)
En el router A se produce la primera fragmentaci on, 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
Oset 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
Oset 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
Oset 370 370+100=470
MF 1 0
4.3.2. Opciones mas usuales
Como se dijo en su momento, este campo es opcional. En el se indicar an los servicios
opcionales que quieran utilizarse s olo cuando vayan a ser usados. Hay que tener en cuenta que,
al no ser campos obligatoriosno 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 especicar las IPs de los routers por los que debe ir pasando el
paquete. Dicho de otro modo, el origen especica de forma explcita la ruta que deberan
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 el.
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 direcci on de nivel de enlace que aparece en el
destino del paquete; esta direcci on puede ser:
La del propio router. Pasa el paquete al nivel superior para analizarlo. No lo reenva.
La de difusi on. En este caso tenemos dos posibilidades:
Que sea la general (255.255.255.255): no se reenva.
Que sea la de subred (SUBRED.255): tampoco se reenva.
Cualquier direcci on distinta a las anteriores. En ese caso, el paquete ser a enrutado, en
funci on de la IP de destino, siguiendo las tablas de encaminamiento.
Una tabla de encaminamiento consta de varias entradas (las), cada una de las cuales consta
de 5 campos (columnas). Los campos son los siguientes:
Direcci on de Red (enadelante DirRed): es una direcci on IP que engloba toda una red.
Suele acabar en cero.
Mascara de Red (en adelante Mask): dene, aplicada al campo anterior, la extensi on de
la red (vease el apartado 2.1.3 del tema anterior para una descripci on mas detallada).
Metrica: es el n umero 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. Tambien 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 tendra:
DirRed Mascara Metrica 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 mascara. A igual
longitud de m ascara, se ordena de menor a mayor metrica.
Cada vez que llega un paquete al nivel 3 se le aplica la m ascara de la primera entrada. Si el
resultado coincide con la DirRed de esa entrada ser a enviado a la IPnext por la interfaz especi-
cada. 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 modica, pues para que el paquete llegue a su destino se usara el nivel de enlace,
es decir, la MAC de destino (MACdest) s cambia, la IPdest no.
La ultima entrada de todas debe ser la salida por defecto (Gateway). Tanto su mascara
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, coincidir an con la entrada por defecto.
El algoritmo que usan los routers se muestra en la gura 4.6.
A continuaci on vamos a ver un ejemplo de tablas de encaminamiento. Tenemos una red con
la topologa que muestra la gura 4.7.
En ella, tabla de encaminamiento de A tendra el aspecto que se muestra en la gura 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 mascara 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(MaskZ) > Long(MaskX) > Long(MaskY ) (4.2)
La tabla de encaminamiento de B quedara como se indica en la gura 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 m ascara lo sucientemente 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 suposicion de los tama nos de las mascaras de redes anterior quedara
ahora as:
24 > Long(MaskZ) > Long(MaskX) > Long(MaskY ) (4.3)
Y para el router C, se muestra en la gura 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 ultima la representan las restantes entradas, correspondientes
a las restantes redes tambien conectadas a C.
Puntos importantes a tener en cuenta son los siguientes:
Las entradas deben estar ordenadas de mayor a menor longitud de m ascara 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 topologa de la red, mediante el cual
193.0.0.192/26 cuelga ahora de D y no de A como se muestra en la gura 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 mas traum aticos. En principio ya no se podran
agrupar las LANs 193.0.0.* sino que habra 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 coincidiran con la primera entrada mientras que los que no seran 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 vera afectada por este cambio de topologa 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: Modicaci on del ejemplo de tablas de encainamiento
Captulo 5
Encaminamiento
5.1. Tipos de direcciones
Se denomina encaminamiento al conjunto de procedimientos que permiten establecer las
rutas optimas. Es la funci on basica del nivel de red.
Se puede dividir en tres partes o funciones:
Establecimiento de vecindades: Se trata de encontrar informacion de los nodos adyacentes
para comunicarse con ellos.
Distribuci on de informacion: La informaci on recibida de los nodos adyacentes es compartida
por todos los nodos.
C alculo de rutas: Con la informaci on que nos llega de la distribuci on podemos calcular la
ruta optima a un destino.
Un encaminador se puede esquematizar como una maquina con la siguiente estructura:
BIE es la Base de Informacion de Encaminamiento (en ingles RIB, Routing Information
Base), la base de datos que se consulta para decidir y formar la BIR. La informacion de la
BIE se consigue mediante interaccion con el entorno local de cada nodo (cada nodo observa
sus enlaces) y mediante la recepci on de informaci on 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 Informaci on de Reenvo (en ingles FIB, Forwarding Information Base).
Es la tabla que se consulta para hacer el reenvo de los paquetes.
53
Figura 5.1: Esquema de un encaminador.
5.2. Clasicaci on de mecanismos de encaminamiento
Los mecanismos de encaminamiento se pueden clasicar seg un el ambito en:
Encaminamiento jado 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 donde reenviar el paquete. Este
ultimo mecanismo es el que utiliza en el funcionamiento normal de la red.
Si los clasicamos seg un la capacidad de adaptacion tenemos:
Encaminamiento estatico: si hay alg un cambio en la red, el router no hace ning un
cambio en su conguraci on. Los encaminadores solamente poseen BIR, no BIE ni modulo
de calculo de rutas.
Encaminamiento dinamico o adaptativo: la conguracion del router cambia a lo largo
del tiempo. Dentro de este tipo de encaminamiento podemos encontrar a su vez distintos
tipos seg un su organizacion.
Aislado: No se tiene en cuenta la informacion de los otros nodos a la hora de en-
caminar. Tiene un calculo de rutas muy simple. Ejemplos: Inundacion (el paquete
llega al router y se reenva por todas las interfaces excepto por aquella por la que
lleg o), Patata Caliente (enva el paquete por la primera interfaz disponible, de forma
aleatoria. Los paquetes se pondran a dar vueltas por la red y en alg un momento
llegar an a su destino) y reenvo por la interfaz menos cargada.
Centralizado: El c alculo de rutas s olo lo hace el nodo central. Los nodos recogen
la informaci on de sus vecinos y la envan 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 produciran bucles, pero el nodo central se convierte en un punto crtico
(cuello de botella).
Distribuido: Son los m as utilizados. En este tipo de encaminamiento todos los nodos
son iguales, todos envan y reciben informacion de control y todos calculan, a partir
de su BIE, sus tablas de encaminamiento. La adaptaci on a cambios es optima siempre
y cuando estos sean noticados.
Nos centraremos en el encaminamiento salto a salto dinamico distribuido.
5.3. Jerarqua de encaminamiento y direccionamiento
Si tenemos una red que va aumentando de tama no hace que aumente la dimension de la
BIE y, por tanto, tambien de la BIR. Esto supone un mayor consumo de memoria, de CPU y de
ancho de banda para intercambiar informaci on de control. Veamos un ejemplo en la ilustracion
6.2:
Figura 5.2: Red sin niveles de jerarqua.
La forma de encaminamiento la elegimos nosotros. En este caso la tabla del nodo 1 quedara
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 jerarqua
Si jerarquizamos el sistema nombrando los nodos como en la ilustraci on 6.3, la tabla dismi-
nuye considerablemente de tama no pero a costa de perder precisi on.
11 11
12 12
13 13
14 12
2x 12
3x 13
Cuadro 5.2: Tabla de rutas para la red con niveles de jerarqua
Vemos como la nueva tabla tiene aproximadamente la mitad de tama no que la anterior,
pero el precio que hemos de pagar por ello es que para alcanzar algunos nodos ser a necesario
realizar m as 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 mas.
A un se podra introducir un nivel m as de jerarqua:
La tabla de encaminamiento quedara as:
Figura 5.3: Red con jerarqua.
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 direcci on de
nivel de red y del nivel de enlace de los nodos adyacentes.
Permitir a los sistemas nales (SF = host = nodo) encontrar los SI adyacentes, distinguir
cu ales son los nodos adyacentes y encontrar la direcci on 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 area local (LAN).
5.4.1. Enlace punto a punto
El SI necesita saber la direcci on del sistema nal de nivel 3.
Figura 5.4: Red con niveles y subniveles de jerarqua.
Solucion ISO: Dispone de un protocolo denominado ESH (end system hello). Peri odica-
mente, el SF enva por el enlace un mensaje hello con el cual el SF indica al SI su direccion
de nivel 3.
Solucion TCP/IP: No se envan mensajes, sino que se utiliza la conguracion de los nodos.
Se resuelve a partir de la direcci on y de la m ascara. En el enlace punto a punto bastara
con una m ascara de 30 bits, que nos proporciona un sistema con 4 direcciones: una para
direcci on de red, otra para difusi on, otra para el SI y otra para el SF.
5.4.2. Red de area local (LAN)
La notaci on que usaremos en este apartado es la siguiente: SF
3
B
representa la direccion del
nivel de red (nivel 3) del sistema nal 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 jerarqua
Figura 5.5: Esquema de un enlace punto a punto.
1. SI : SF
3
A
SF
3
B
. El SI debe conocer la direccion de nivel 3 de los sistemas nales A y B.
2. SI : SF
2
A
SF
2
B
. El SI debe saber cu al es la direcci on de nivel 2 de los sistemas nales A y
B.
3. SF : SI
2
X
. Cualquier sistema nal debe conocer la direcci on de nivel 2 del sistema inter-
medio al que est a conectado.
4. SFA SFB, SFA : SF
2
B. A quiere enviar algo a B. Como estan unidos fsicamente en
una LAN no hace falta que pase por ning un SI, pero A necesita conocer la direccion 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 traves del nivel
de enlace.
5. SFA SIB SFC. Encaminar los mensajes de A a C a traves del SIB.
6. Suponemos que no hay SI. SFA SFB, SFA : SF
2
B
. Si no hay SI y A quiere enviar un
mensaje a B, A necesita conocer la direcci on de nivel de enlace de B.
Solucion ISO
Existen 3 tipos de mensajes:
Figura 5.6: Ejemplo de una LAN.
ESH (Hola del SF): Los sistemas nales envan este mensaje a una direcci on destino de
grupo que la escuchan todos los SI.
ISH (Hola del SI): El SI enva este mensaje por todas sus interfaces a todos los sistemas
nales con los que este conectados directamente.
Redirecci on: Es un mensaje en el cual el SI especica al SF por d onde debe enviar los men-
sajes a un destino determinado. Por ejemplo cuando un SI recibe un paquete y lo reenva
por la misma interfaz que la recibi o, enva un mensaje al que lo envio para informarle de
que ese destinatario est a visible directamente. Lo vemos en estas ilustraciones.
Otro ejemplo de redirecci on es el siguiente:
Con esto SFA conoce el par de direcciones de nivel 3 y nivel 2 necesarias (SF
3
C
SI
2
B
) para
alcanzar a SF
C
.
Por tanto, los mensajes de ESH e ISH permitir an la soluci on de:
ESH: soluciona los problemas 1 y 2 al tener direcci on de nivel 2 y 3 de SF.
ISH: soluciona el problema 3 al tener direcci on de nivel 2 y 3 de SI.
Figura 5.7: SF
A
le quiere enviar un mensaje a SF
B
. B se encuentra directamente accesible por
el nivel de enlace, pero A no lo sabe. A enva 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:
Envo peri odico de ESH a todos los SI
Envo directo de ESH a los SF
Cache de SI (CSI): Almacena la relaci on direcci on de nivel 3 - direccion de nivel 2 de los
sistemas intermedios.
SI
3
1
SI
2
1
SI
3
2
SI
2
2
Cache Destino (CD): Esta tabla contiene una relaci on entre la direcci on de nivel 3 destino
y la direcci on nivel 2 que debemos poner en el mensaje para que alcance dicho destino.
Almacena tanto mensajes de redireccion como ESH.
Mensajes de redirecci on SF
3
X
SY
2
Z
Hola de SF directo (ESH) SF
3
X
SY
2
K
SY
2
Z
= SI
2
Z
o SF
2
Z
Donde SF
3
X
representa la direcci on de nivel de red del destino nal de nuestro paquete, y
SY
2
Z
y SY
2
K
seran la direcci on 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 reenva a su destino, B. Pero, adem as, el SI se da
cuenta de que para reenviarlo ha tenido que usar el mismo enlace por el que le lleg o. Por tanto,
le dice a A que los siguientes paquetes con destino a B los debe enviar a la direcci on 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, este se borrara.
El algoritmo seguira los siguientes pasos cuando un SF quiera transmitir un paquete a un
destino identicado por su direcci on de nivel 3 (D
3
):
1. BuscaD
3
en la cache destino (CD) Si la encuentra, se lo enva (D
3
, X
2
)
2. Si no Busca en CSI una entrada cualquiera y se lo enva (D
3
, SI
2
X
)
3. Si la CSI est a vaca, enva un mensaje de difusi on dentro de su LAN, ya que es el alcance
que tienen las direcciones de nivel de enlace (D3, SF
2
)
Veamos como se solucionaran los problemas que nos quedan:
Supondremos que las caches est an vacas.
1. Si el SF
A
quiere enviar algo a SF
D
y SF
A
s olo sabe SF
3
D
, aplica el algoritmo de los SF.
Como las caches se encuentran vacas se enva un mensaje de difusi on dentro de su LAN,
rellenando la tabla de CSI de SFA con las direcciones de nivel de enlace SI
2
A
y SI
2
B
. El
mensaje sale a traves de alguno de estos sistemas intermedios.
Figura 5.9: SFA quiere enviar algo a SF
C
. A no sabe donde est a C, as que enva el paquete a
un SI aleatoriamente. En este caso, lo enva al SI
A
.
2. Si SF
A
desea enviar algo a SF
C
, el mensaje tendr a como direccion de red la direcci on
destino de SF
C
y como direccion de enlace la direcci on de nivel 2 de SI
A
o de SI
B
.
N red N enlace datos
SF
3
C
SI
2
A
...
Si ha sido enviado a traves del SI
A
,SI
A
lo reenva a SI
B
por la misma interfaz y avisara
a SF
A
, mediante un mensaje de redireccion, de que el destino est a alcanzable a traves de
SI
B
(se vio en uno de los ejemplos de redirecci on). Esta informaci on la almacenara SF
A
en su cache de destinos (CD) de la siguiente forma:
SF
3
C
SI
2
B
3. Si SF
A
desea enviar algo a SF
B
en principio lo hara a traves de SI
A
. Como este sistema
intermedio tiene que reenviar el mensaje por la misma interfaz por la que lo recibio, enviara
un mensaje de redireccion a SF
A
para comunicarle que SF
B
est a accesible directamente
(se vio en uno de los ejemplos de redirecci on). Esta informaci on la almacena SF
A
en su
cache de destino por lo que la CD de SF
A
quedara as:
SF
3
C
SI
2
B
SF
3
B
SF
2
B
Figura 5.10: El SI
A
consulta su tabla de encaminamiento y ve que para enviar un paquete a
C ha de pasar por SI
B
. Por tanto, reenva el paquete a SI
B
. Pero SI
A
se da cuenta de que al
reenviar el paquete ha usado el mismo interfaz por el que lo recibio, as que comunica a S
F
A
que, cuando tenga que enviar un paquete a SF
C
, lo tiene que mandar a la direcci on de enlace
de SI
B
.
4. Si caen los SI, desues de un cierto tiempo se borrara la cache de CSI y CD. Si ahora SF
A
quiere enviarle algo a SF
B
y suponiendo que los SI est an cados y las tablas borradas, SF
A
enviara un mensaje de difusi on tal que as:
N red N enlace datos
SF
3
B
SF
2
B
...
El SF
B
contestara a SF
A
con un mensaje ESH directo indic andole en este su direccion
de nivel de enlace. SF
A
lo almacena en su cache de destinos y ya podran compartir
informaci on.
Solucion TCP/IP
En esta arquitectura cada host conoce su IP, su m ascara y la IP del router por defecto.
Para traducir las direcciones IP en direcciones de nivel de enlace (direcci on MAC), TCP/IP
cuenta con el protocolo ARP (Address Resolution Protocol, RFC 826). Si un sistema quiere
encontrar la direcci on de nivel de red que pertenece a una determinada IP, este enva un paquete
(ARP REQUEST) a la direcci on de difusi on de la red en el que se indica la IP por la que se
Figura 5.11: Ejemplo de una LAN
pregunta. La m aquina implicada, si existe, responde con otro mensaje (ARP RESPONSE) donde
le indica su direcci on MAC.
El protocolo ICMP(Internet Control Message Protocol, RFC 792) permite enviar mensaje
de redirecci on. 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
m as adelante con un ejemplo.
Veamos como soluciona TCP/IP los mismos problemas anteriores:
1. SI : SF
3
A
SF
3
B
. El SI debe conocer la direccion de nivel 3 de los sistemas nales A y B.
2. SI : SF
2
A
SF
2
B
. El SI debe saber cu al es la direcci on de nivel 2 de los sistemas nales A y
B.
3. SF : SI
2
X
. Cualquier sistema nal debe conocer la direcci on de nivel 2 del sistema inter-
medio al que est a conectado.
4. SF
A
SF
B
, SF
A
: SF
2
B
. A quiere enviar algo a B. Como est an unidos fsicamente en
una LAN no hace falta que pase por ning un SI, pero A necesita conocer la direccion 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 traves del nivel
de enlace.
5. SF
A
SI
B
SF
C
. Encaminar los mensajes de A a C a traves del SIB.
6. Suponemos que no hay SI. SF
A
SF
B
, SF
A
: SF
2
B
. Si no hay SI y A quiere enviar un
mensaje a B, A necesita conocer la direcci on de nivel de enlace de B.
El problema 1 se puede solucionar con el uso de la m ascara. Dado que cada enlace del SI
tendr a asignadas una IP y una mascara, 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 nales dentro de una misma LAN y A quiere conocer
la direcci on de nivel de enlace de B, A enviara un mensaje de difusi on ARP REQUEST con la
direcci on IP de B. B contestara con un mensaje directo ARP RESPONSE en el que le indica
a A su direcci on de nivel de enlace. En la cache de A se almacenara 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 nal quiere conocer la direccion de nivel de enlace del router.
Por conguraci on los hosts saben su IP, su mascara y la direcci on IP del router por defecto.
Usando ARP conseguir a la direccion de nivel de enlace del router. Para ello la direcci on IP debe
ser accesible directamente (al multiplicar bit a bit la m ascara 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 SF
A
quiere enviar algo a SF
C
, el SI
A
debe enviar
un mensaje de redirecci on a SF
A
para que lo que enve a SF
C
lo haga a traves de SI
B
. En
TCP/IP contamos con ICMP para enviar los mensajes de redirecci on. En este caso, el mensaje
de redireccion que SIA enva a SFA contiene una pareja de IPs (IP
SF
C
, IP
SI
B
), es decir, dos
direcciones de nivel de red en vez de una direccion de nivel de red y una de nivel de enlace como
haca la norma ISO. El SF
A
es el que se encarga de traducir la direcci on IP del SI
B
(SI
3
B
) a la
direcci on de nivel de enlace del SI
B
.
Otros protocolos relacionados con ARP son:
RARP (ARP reverse RFC 903): Sirve para averiguar una direccion IP a partir de una
direcci on 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 difusi on nuestra direccion MAC, consi-
guiendo de un servidor BOOTP la IP. Tambien permite conocer la direccion de un servidor
de cheros y una lista de cheros a descargar ( util si se quiere que al arrancar la maquina
se instale un sistema operativo desde un servidor de cheros, por ejemplo).
DHCP (RFC 2131): Es una evoluci on del BOOTP, que ademas de lo que este proporcio-
naba da mas informaci on (como la direccion del servidor DNS, la del router por defecto...).
Se puede usar cuando tenemos m as m aquinas que IPs disponibles, ya que las IPs se asig-
nan dinamicamente cuando la m aquina lo requiere. Dichas IPs pueden tener un tiempo de
asignaci on limitado, de modo que pasado ese tiempo caducan y es necesario solicitar otra
direcci on.
InARP (RFC 2390): Inverse ARP. Cuando se tiene una conexion 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 unica red. Para
ello, el router responder a a paquetes ARP dirigidos a destinos situados al otro lado del router,
simulando as que dichos destinos son accesibles directamente. Se ver a m as 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 est an
separados por un router con Proxy ARP (en este caso, el router R esta haciendo Proxy ARP de
A y B por R
1
). Lo primero que hara C ser a 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 haciendose pasar por A. Cuando C enva el paquete, lo enva con la MAC del router y
Figura 5.13: Ejemplo de PROXY ARP
la IP de A. El paquete llega al router, y este averigua cual es la direcci on de enlace verdadera
de A y lo enruta hacia all. De esta forma el paquete llega a su destino y las m aquinas C, D y
E ven a A y B directamente accesibles.
Una aclaraci on: en el ejemplo anterior hemos supuesto que las caches ARP de todos los
equipos est an vacas. Es por ello por lo que es necesario enviar mensajes ARP para averiguar las
direcciones de nivel de enlace. Para paquetes posteriores, simplemente se enviaran datos a las
direcciones que ya conocemos.
N otese que no sera necesario hacer Proxy ARP de C, D y E por R2. Para que las m aquinas
A y B puedan comunicarse sin problemas con el resto de su red, s olo es necesario poner como
router por defecto al router R. Esto no sera 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 tecnica sin
que lo sepa el router de salida al exterior de la red. Esta tecnica se emplea en redes virtuales para
simular que los equipos estan conectados de forma local. Entre las desventajas del Proxy ARP
est an la escalabilidad (ya que se requiere una resolucion ARP para cada dispositivo enrutado de
esta forma) y la abilidad, pudiendo ocasionar problemas si existe alg un software anti-intrusos.
El software detectara que una misma MAC responde a varias IPs distintas, y podra pensar que
se trata de un intruso realizando suplantacion de identidad (spoong).
Problema: Suponer que las tablas ARP estan vacas. Dibujar los mensajes que se envan
cuando B quiere enviar un datagrama a A. Dibujar tambien los datagramas que se envan cuando
A enva un datagrama a B. Representar los mensajes con la siguiente notaci on: TIPO(D
3
,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. Calculo de rutas
5.6.1. Introducci on
El c alculo de rutas se dene como el c alculo del mejor camino suponiendo que ya tenemos
informaci on de la red. El primer objetivo de este mecanismo es obtener una funci on a optimizar:
funci on de optimizaci on. A los parametros de esta funcion se les denominan metricas.
El metodo consistir a en m aximizar o minimizar esas metricas seg un convenga (por ejemplo,
si la variable que estamos manejando es el retardo, convendra minimizarla. Si se trata de los
benecios obtenidos, interesara maximizarla).
Las metricas pueden ser de 2 tipos:
GLOBALES: Miden una cualidad de la red completa. Algunos ejemplos son:
Saturacion maxima: se mide en cada nodo. Para nuestra ruta habra que ver en
que nodo se da la saturacion m axima.
Retardo global medio: Se trata del retardo de cada enlace ponderado por el n umero
de paquetes que lo atraviesa.
LOCALES: A cada enlace se le asigna un valor. Ahora a cada camino (sucesion de enlaces)
se le asigna otro valor en funcion del valor a nadido de los enlaces. La funci on optima
ser a los caminos que maximicen o minimicen el valor anterior. Dentro de las metricas
locales, podemos clasicarlas en:
ADITIVAS: Su funci on optima depende de la suma del valor asociado a cada enlace
en el camino. P.ej. N umero de saltos, retardo medio en el camino.
C
ONCAVAS: Su funcion optima depende del mnimo del valor asociado a cada enlace
en el camino. P.ej. Capacidad del enlace, MTU (Unidad Maxima de Transmisi on, nos
da informaci on acerca del tama no maximo de la SDU (Unidad de Datos del Servicio)).
MULTIPLICATIVAS: Su funci on optima depende del producto del valor asociado a
cada enlace en el camino. P.ej. Probabilidad de error.
5.6.2. Algoritmo del camino mas corto
Es un mecanismo que emplea metricas locales aditivas. El valor de cada enlace se le llama
coste, longitud o peso. Este algoritmo nace debido al caracter dinamico del coste de los enlaces.
Dicho coste puede cambiar constantemente (por ejemplo, si consideramos el coste como el retardo
de los paquetes o la saturaci on del enlace) y provocar oscilaciones.
El objetivo de este algoritmo es obtener al arbol de expansion de distancia mnima a un
nodo concreto, esto es, el conjunto de enlaces con los caminos m as cortos de todos los nodos al
nodo destino. Se le llama arbol porque no se forman bucles y se le dice de expansion porque
contiene todos los nodos de la red.
Vamos a estudiar 2 tipos de algoritmos del camino m as corto: el algoritmo de Bellman- Ford
y el algoritmo de Dijkstra.
Figura 5.15: Ejemplo de red.
Figura 5.16:

Arbol de expansi on de distancia mnima a A.
Algoritmo de Bellman-Ford
Obtiene la distancia mnima de todos los nodos a un nodo destino (al que denominamos
nodo 1). Usaremos la siguiente notacion:
D
n
i
= Distancia mnima del nodo i al nodo 1 a traves de caminos de n saltos o menos.
Denimos:
D
n
i
= 0n
D
0
i
= i = 1
D
n+1
i
= mn
jN(i)
[d
ij
+ D
n
j
], donde d
ij
=coste, longitud o peso del enlace entre i y j (si no
hay, se considera innito) y N(i) es el conjunto de nodos adyacentes a i.
Cuando se alcanza D
n+1
i
= D
n
i
i , se dice que se ha encontrado el camino m as corto.
Esta representaci on gr aca equivale a la siguiente tabla de costes:
Figura 5.17: Ejemplo para el algoritmo de Bellman-Ford.
d
ij
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 mnimas al nodo 1, considerando que el n umero maximo de saltos
que se pueden dar es 1:
D
1
2
= min(d
21
+D
01
; d
23
+D
03
; ...) = 1
D
1
3
= 4
D
1
4
=
D
1
5
=
Ahora repetimos los c alculos, considerando que el m aximo n umero de saltos es 2, despues 3...
as hasta que en una de las iteraciones los resultados no cambien respecto a la iteraci on 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:
D
n
i
D
1
D
2
D
3
D
4
D
5
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 asncrono, que comienza con:
D
1
= 0
D
i
= i = j
Cada nodo enva a sus vecinos los D
i
obtenidos y recibe de sus vecinos los D
j
obtenidos por
ellos mediante la ecuaci on de Bellman-Ford (D
i
= min(d
ij
+ D
j
)). Entonces, el nodo i calcula
Di = min
jN(i)
(d
ij
+ D
j
), donde N(i) representa los nodos adyacentes a i. Es decir, cada nodo
calcula la distancia mnima a los nodos de la red a partir de la informaci on que recibe de sus
vecinos. El proceso se repite de forma iterativa, y al nal converge en el camino m as corto,
donde se tendra la distancia mnima. Este algoritmo presenta la ventaja de que s olo es necesario
conocer de antemano a los nodos vecinos al nuestro, no a toda la red como ocurra 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 mnima de todos los nodos con el nodo 1. La notaci on que se usa es:
D
i
= Estimacion de la distancia mnima al nodo 1. A esto lo llamaremos etiqueta.
P = Conjunto de nodos cuya etiqueta no es una estimacion de la distancia, sino que es la
distancia real. En cada iteracion del algoritmo conseguiremos que m as 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:
D
1
= 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. N otese co-
mo, inicialmente, sabemos que la distancia del nodo 1 al nodo 1 es cero, pero no conocemos
ninguna otra distancia.
D
j
= d
ij
j = 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 innito.
El algoritmo iterativo es el siguiente:
1. Encontrar i / P : D
i
= min
i / P
D
j
, es decir, de todos los nodos buscamos aquel que tenga
la etiqueta tentativa mnima (lo llamaremos nodo i) y lo a nadimos al conjunto P. Una vez
que lo a nadimos al conjunto P, su etiqueta se vuelve permanente (no cambia).
2. P = P i, esto es, a nadimos el nodo que acabamos de conseguir al conjunto P.
3. Si P contiene a todos los nodos, naliza el algoritmo.
4. Recalcular las etiquetas tentativas de la siguiente forma: j / P , D
j
= min(D
j
; d
ij
+D
i
).
Esto equivale a comparar la distancia que ya tena de la iteracion anterior a la que obtengo
ahora si en lugar del camino escogido anteriormente, escojo el camino que atraviesa el nodo
i. En realidad, s olo hay que calcular la de los vecinos al nodo a nadido a P, porque los otros
no variar an.
5. Volver a 1.
Veamos el ejemplo anterior usando el algoritmo de Dijkstra:
Como era de esperar, con este metodo 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 esto solo ocurre si hay m as de un camino mnimo al nodo 1.
Ejercicio: Calcular el camino mas corto de todos los nodos al nodo C, usando ambos algo-
ritmos
5.7. Distribuci on de la informacion
Vamos a ver dos tipos de algoritmos para la distribucion de informaci on: 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 aplicacion del algoritmo de Bellman-Ford distribuido asncrono aplicado a
todos los nodos y no a uno s olo como se hizo anteriormente.
Con este algoritmo se siguen estos pasos:
Cada nodo conoce su identicador.
Cada nodo conoce el coste de sus enlaces: Estado de las vecindades
Cada nodo comienza con un vector VDi=(, , , ...,0 (en la posici on i),,...,) se
denomina vector distancia del nodo i. Este vector tendr a en cuenta todos los nodos de la
red.
Cada nodo transmite su vector distancia V D
i
a sus vecinos. Se transmite: o peri odicamente
o cuando cambia el V D
i
o cuando se activa un enlace Lo que realmente se transmite es una
lista de duplas del tipo < nodo, distancia >: V D
i
= {< id, distancia>,..., < i, 0 >,..., < id,
distancia>}. Para disminuir el ancho de banda gastado, aquellas duplas cuya distancias
sean no se envan, por lo que el otro extremo las supone. El primer V D
i
, por tanto,
ser a V D
i
={ <i, 0> } Cada nodo almacena una copia del vector distancia m as reciente
que haya recibido para cada enlace.
Cada nodo calcula V D
i
minimizando d
ij
+ D
j
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 D
i
si:
Se recibe V D
i
distinto del almacenado.
Cae el enlace a j, entonces se descarta la informacion que se posea de j y se recalcula
el V D
i
completo.
Cambia el coste de un enlace.
Presenta una ventaja, la comunicaci on se da entre nodos adyacentes por lo que solo es
necesario emplear el nivel de enlace. Se enva mucha informaci on, pero a pocos equipos. El
problema que presenta, dado que se basa en el algoritmo Bellman-Ford distribuido asncrono, es
que la convergencia puede ser lenta. Ve amoslo con un ejemplo:
En esta situaci on los vectores de distancias convergen a esta situaci on:
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 aplicacion de ambos algoritmos.
Figura 5.21: Ejemplo de lentitud en convergencia.
Los vectores que cada nodo tiene almacenados por cada interfaz seran:
A B
A
B
C
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 m as el salto de B a A. Como ha cambiado su vector se
lo enva a A. A calculara su vector y le dara (0 1 4), que enviara a B. B recalcula y obtiene
(1 0 5). Esto provoca un crculo vicioso que hace que la distancia a C crezca. Para solucionarlo,
cuando se rebase un valor lmite se considera el enlace cado y C inaccesible.
A medida que la red aumenta de tama no, la convergencia se complica.
5.7.2. Estados de los enlaces
La informaci on que se enva es la distancia a los vecinos. Esta informaci on 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 informaci on, pero se enva a mas destinos. Los pasos que sigue son:
Cada nodo (SI) sabe su identicador 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 identicador de los vecinos. LSP={<id, coste>, <id, coste>, ...}
Los LSP se envan a todos los sistemas intermedios de la red.
Cada SI creara un mapa completo y hara el c alculo de rutas (p.e. con Dijkstra)
Los paquetes LSP se construyen y se envan:
periodicamente.
cuando aparece un nuevo vecino.
cuando cambia el coste del enlace.
cuando cae un enlace.
Los inconvenientes de este metodo son los siguientes: si no conseguimos que los paquetes LSP
les lleguen a todos los nodos de la red se pueden producir bucles. Tambien puede que se gasten
muchos recursos con el envo de LSP.
Para que los LSP lleguen a todos los nodos no podemos basarnos en encaminamiento porque
todava no lo tenemos (recordemos que la fase en la que estamos actualmente, la distribuci on de
informaci on, es previa al encaminamiento). Se usa el metodo de inundacion 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 mas recientes o usar numeraci on. La soluci on pasa por un esquema que mezcla la
numeraci on y el tiempo. Como metodo b asico se usa la numeraci on. A cada paquete se le asocia
un n umero de secuencia y ademas se le indicar a la edad (contador que se va decrementando
con el tiempo y en cada salto) como mecanismo de autodestrucci on, esto es, cuando se alcance
edad=0 se rechaza el paquete. El LSP contendr a por tanto: origen, SN (n umero de secuencia),
edad y datos. No lleva destino porque est a dirigido a todos los routers de la red.
Si el LSP que le llega a un nodo tiene un n umero de secuencia mayor que el almacenado,
guardamos la informaci on y lo reemitimos decrementando la edad. Cuando se almacena tambien
va decrementando su edad con el transcurso del tiempo y normalmente no llegar a a cero. Si llega
un LSP con el SN menor del que tenemos almacenado se descarta.
El problema que se plantea ahora es la sincronizacion del reloj con los demas.
Figura 5.23: Recepci on del paquete.
[h]
LSP/enlace 1 2 3
origen=R5 envo LSP 1 1 0
SN=17 envo ACK 0 0 1
ALGORITMO:
1. Al inicio la tabla est a vaca. Supondremos que los mensajes recibidos tendr an EDAD= 0.
2. Periodicamente se recorre la tabla. Para cada enlace, si envo LSP vale 1, se enva el LSP
correspondiente y se mantiene envo LSP a 1. Si envo ACK vale 1, enva ACK y se le asigna
el valor 0 a envo ACK. El razonamiento que lleva a este comportamiento es el siguiente:
manteniendo envo LSP a 1 me aseguro de que el paquete llegar a a su destino, ya que
lo estare retransmitiendo hasta que me llegue conrmacion de su llegada. Sin embargo el
ACK solo lo envo una vez, ya que, si se perdiera el paquete, el LSP correspondiente me
sera reenviado por el emisor original y yo volvera a conrmarlo.
3. Si recibe un LSP por enlace j: Si es nuevo (de otro enlace que no tena) o es m as reciente
(de un origen que ya tena pero con un SN mayor) se realiza lo siguiente:
Figura 5.24: Reenvo del paquete.
Se decrementa la edad en 1 unidad.
Se almacena en memoria
Para todo enlace distinto de j se pone envo LSP=1 y envo ACK=0, y para el enlace
j se pone envo LSP=0 y envo 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
aquel por el que recib el que tengo en memoria): Para el enlace j se pone envo LSP a 0 y
envo ACK a 1.
Esto se hace para evitar bucles en los que una serie de nodos se enven informacion que ya
tienen. Podemos ver un ejemplo en el siguiente dibujo:
En este caso, C enva el mismo LSP a A y B. Supongamos que, por cualquier razon, B
reenva el LSP mas r apido que A. A A le llegara un LSP por A-B que ya le haba llegado
por el enlace A-C, luego pone envo LSP a 0 en el enlace AB (para no enviarle a B un LSP
que ya tiene) y envo ACK del enlace A-B a 1. As, le enva 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 pondra para
ese enlace j el valor envo LSP a 0 y envo ACK a 0. Poner envo ACK a 0 puede parecer
un poco extra no, pero si analizamos la situacion es f acil 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 envo de LSPs.
haber puesto envo LSP a 0 en el enlace. Entonces, enviarle un ACK no tiene sentido, ya
que el unico uso del ACK es forzar al otro extremo a poner envo 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 tena 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 enva 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 lleg o 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 est a en memoria (mismo
SN) responde con un ACK por ese enlace y se reenva por los demas enlaces para informar que
ese nodo no est a 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 enviara un ACK al
emisor. (Para m as informaci on sobre encaminamiento, consultar Interconnections, de Radia
Perlman, Ed Addison-Wesley)
Problema: C omo se propagaran los paquetes LSP cuando cae el enlace A-E si nos centra-
mos unicamente en aquellos cuyo origen es A? Cuantas copias apareceran en total?
Figura 5.26: Ejercicio.
5.7.3. LSP en una LAN
Figura 5.27: Esquema de una LAN con m ultiples 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 m aquina 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 interconexion total uniendolos.
Cada router tiene que poner el estado del enlace a cada uno de los vecinos, por lo que enviara
un mensaje con tantas parejas enlace-estado como routers haya en la red. Esto multiplicado por
el n umero de routers lleva a un gran gasto de recursos.
Para solucionarlo, podemos transformar la malla virtual en una conexi on en estrella virtual.
Para ello, se selecciona al uno de los routers, al que se llama router designado. Este router, adem as
de realizar las funciones de router normal, funciona como router designado, es decir, ademas de
su direccion origen presenta una direcci on nueva que no existe fsicamente. Al usar un router
designado, no es necesario que cada router enve un LSP a cada nodo de la red. Simplemente
enviar a un LSP con todas las parejas enlace-coste al router designado, y este se encargara de
retransmitirlo en difusion.
N otese que, aunque el paquete a enviar contenga la misma informaci on, al enviarse a muchos
menos destinos se reduce considerablemente el traco en la red.
Figura 5.28: LSP que se envan en condiciones normales.
Figura 5.29: LSP que se envan si se usa router designado (en este caso, se ha designado al router
3.
Por otra parte, en una LAN no se envan asentimientos entre los nodos, ya que aumentara
considerablemente el traco de la red. Para compensar esto el router designado enva un paquete
llamado SNP (resumen de los n umeros de secuencia) a todos los nodos de la LAN. En el SNP
se indican los n umeros de secuencia de los LSP de todos los nodos de la red. Los vecinos lo
comparan con lo que tienen en memoria y s olo 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 (signicara que se ha perdido un LSP antes de llegar al router designado), el nodo enva
el LSP de nuevo.
5.8. Protocolos especcos de encaminamiento
Para describir las redes, se usa un modelo jerarquico basado en dominios. Distinguimos dos
tipos de dominios:
Dominio administrativo: comprende una parte de la red que es administrada por una unica
autoridad.
Dominio de encaminamiento: es una parte de un dominio administrativo en la que se sigue
un mismo criterio para el encaminamiento.
Area: es una regi on de la red en la que se utilizan protocolos intradominio.

Las ventajas de realizar esta divisi on son:
Escalabilidad: recordemos que, al usar vector de distancias, la velocidad de convergencia
decrece r apidamente al aumentar la red. Con la divisi on en dominios reducimos el ambito
del vector, con lo que conseguimos una convergencia mas r apida. Por otra parte, si usamos
LSP ser a necesario enviar los paquetes en difusi on a toda la red. Con redes grandes, el
consumo de recursos puede ser excesivo.
Autonoma de gesti on: la division permite que los propietarios o gestores sean los adminis-
tradores de la red. Adem as, se puede decidir que informaci on se comparte con el exterior
y cual se mantiene oculta.
Los protocolos de encaminamiento se dividen en dos tipos, seg un el ambito:
Intradominio: propaga informaci on dentro de un mismo dominio. Los criterios que se usan
para el encaminamiento son tecnicos. Busca optimizar la eciencia. 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 informacion entre distintos dominios, que pueden presentar dis-
tintos criterios para el encaminamiento, basados en cuestiones administrativas. Permiten
formular restricciones sobre el tr aco 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: Divisi on de dominios.
Existen dos tipos de protocolos:
Intradominio: Poseen unicidad de criterios (se basa en criterios tecnicos). Buscan optimizar
la eciencia.
Interdominio: Poseen distintos criterios (basados en criterios administrativos o polticos).
Estos criterios son m as restrictivos que los anteriores.
Deniciones:
D.A. (Dominio Administrativo): Parte de la red administrada por una sola autoridad.
D.E. (Dominio de Encaminamiento): Subdivisi on de D.A. con especicaciones.
Areas: Subdivision de D.E.

Entre D.E.-D.E. y D.A.-D.A. se dan los protocolos interdominio mientras que entre areas y
dentro de las areas 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 m ascaras
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 tama no de la red. De
ah viene el benecio de dividir los dominios.
Autonoma de gesti on: 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 como 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 elecci on es obvia: todos los mensajes que tengan que salir del dominio
se enviar an a ese router. Pero si hubiera mas de un router, habr a que ver hacia cual de ellos se
enva el mensaje. O bien se congura manualmente, o se selecciona seg un alg un algoritmo. En
este ultimo caso, habra que:
Obtener la informaci on de alcanzabilidad traves de otros dominios (es decir, otros dominios
me tendr an que comunicar a que direcciones puedo llegar atraves andolos). Los dominios
que sirven para conectar a otros dominios se llaman dominios de tr ansito.
Propagar esta informacion 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 metrica, ya que distintos dominios pueden tener
conceptos distintos de lo que es la metrica (para uno puede ser el retardo, para otro el
n umero de saltos, etc.). Lo que s se usara para escoger el mejor camino es el n umero de
dominios que hay que atravesar, procurando que este par ametro 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)
Especicado en:
Version 1- RFC 1058
Version 2- RFC 2453
Emplea el VD (Vector Distancia). Por defecto, consideramos que el coste de cada enlace
es 1. Este protocolo mide el n umero de saltos. El m aximo n umero de saltos es 15. Si es mayor
que 15, no se tiene en cuenta. De ah que sea una buena elecci on de protocolo en caso de redes
peque nas.
Cada 30 segundos se resfrescan los datos de los vecinos enviando un mensaje de anuncio. Si
en 180 segundos no se recibe informaci on de alg un vecino, toda la informaci on acerca de el se
desecha.
Existen 2 tipos de mensajes:
Respuesta (RESP): es un mensaje que contiene el vector de distancias. Este mensaje se
enva a los vecinos.
Solicitud (REQ): fuerza a uno de los vecinos a que te enve un mensaje RESP.
La Versi on 1 no soportaba m ascaras mientras la Versi on 2 s. Cada vecino se denir a por el
par dir.IP/M ascara. 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 como se construye un paquete RIP, podemos ver dos cosas. Desde el punto
de vista de la eciencia, es un desperdicio de cabeceras. Este gasto de cabeceras se justica
porque haciendolo as es mas facil programar el protocolo en una m aquina real. Tambien debemos
resaltar el que use UDP (mas concretamente, su puerto 520). Debido a esto, el envo de mensajes
es no able.
Protocolo OSPF (Open Shortest Path First)
Este protocolo viene determinado en RFC 2328. La palabra .
O
pen que aparece en su nombre
signica que no es un protocolo propietario. Shortest Path First signica que emplea el estado
de los enlaces (LSP). No emplea ni Dijkstra ni Bellman-Ford.
Cada enlace tiene su propio coste. Por defecto ser a 1, pero lo usual es que el administrador
de la red asigna un valor inversamente proporcional a la capacidad del enlace. Se envan 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 (identicador 89 en el campo
protocolo).
Algunas caractersticas que presenta este protocolo son:
Se basa en la transmision de LSPs.
Seguridad: Se puede autenticar al otro extremo mediante:
Password (no se usa)
MD5: Se a nade un n umero de secuencia que impide la reproducci on.
Figura 5.32: Algoritmo de autenticaci on mediante hash.
Multicast: Un paquete puede llegar a varios nodos. En realidad, se emplea una variante
llamada MCSPF (MultiCast Service Path Finding).
Jerarqua: Permite realizar divisiones dentro de un dominio, llamadas areas. En Internet, a
cada dominio se le llama Sistema Autonomo (AS). La jerarqua 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 area hacia dentro del area resumiendo la informaci on de
fuera del area pero dentro del dominio o viceversa.
Tipo 4 - LSP - Router borde de area hacia dentro del area 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 basandose en los c alculos realizados mediante protocolos interdominio.
Figura 5.33: Jerarqua en Internet.
5.8.2. Protocolos interdominio (EGP)
BGP (Border Gateway Protocol)
Est a denido 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 Aut onomos) que hay que atravesar
para llegar a un destino. Por tanto, requiere informaci on de alcanzabilidad.
Los routers de salida establecen conexiones TCP entre ellos que se llaman sesiones BGP.
El protocolo TCP es able, es decir, se encarga de reenviar la informacion que se haya podido
perder. Existen dos tipos de sesiones BGP: las sesiones externas, o eBGP, que sirven para obtener
la informacion de alcanzabilidad, y las sesiones internas, o iBGP, que propagan la informacion
obtenida a traves de eBGP dentro de un dominio.
Figura 5.34: Tipos de sesiones.
En la siguiente ilustracion podemos ver como, mediante el protocolo BGP, se transmite
la informacion de alcanzabilidad entre varios sistemas aut onomos. Podemos ver que las IPs
involucradas forman parte de un mismo bloque, el 138.16.64.0/22, que es la informacion que
transmitimos.
Figura 5.35: Envo de informacion mediante BGP.
Exite un organismo encargado de gestionar esto protocolo, IANA, autoridad encargada de la
asignaci on de n umeros en Internet, que fue sustituido por el actual ICANN (Internet Corporation
Assigned Names and Numbers).
Las rutas se denen utilizando rutas, que est an compuestas por un prejo y varios atributos.
El prejo, a su vez, se compone de direcci on de red y m ascara. Entre los posibles atributos
encontramos:
AS-PATH: Camino para llegar al destino. Se da como una lista de ASN (N umero de
identicaci on de Sistema Aut onomo, de 16 bits). Se emplea para decidir sobre el mejor
camino, que ser a aquel con menor AS-PATH.
NEXT-HOP: La direcci on IP del que enva esa ruta. Es interesante para sistemas aut ono-
mos conectados por varios routers.
Los router BGP manejan 3 tipos de bases de datos, en lugar de la RIB habitual.

Estas son:
RIB de entrada: contiene los anuncios recibidos de otros routers, ltrados mediante una
serie de polticas de entrada. Es una tabla con una entrada por cada sesion BGP.
RIB local: es unica para cada router, y es la que se usa para decidir el encaminamiento.
Se crea ltrando la RIB de entrada. Esta tabla, junto a la conguraci on del router y los
protocolos intradominio, forman la FIB.
RIB de salida: controla que informacion se anuncia. Se forma ltrando la RIB local con la
poltica de salida.
Figura 5.36: L ogica para la creaci on de las RIBs.
En BGP, se sigue este algoritmo para la selecci on 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 m as cerca.
4. Si estuvieran todos a la misma distancia, se escoge seg un el identicador BGP, que es unico
para cada router. Esta eleccion es simplemente para deshacer el empate, no tiene ning un
sentido.
El Sistema Autonomo puede considerarse como terminal (stub) o de transito (transit).
Un sistema congurado como stub solamente cursa tr aco cuyo origen o destino sea el mismo.
Un sistema de transito, sin embargo, permite que lo atraviese tr aco que va destinado a otros
sistemas. Los sistemas de tr ansito anuncian las rutas que se pueden alcanzar a traves de ellos,
generalmente seg un acuerdos economicos (anuncian las rutas que les pueden reportar benecios).
Figura 5.37: Ejemplo con varios SA interconectados.
En la gr aca, W e Y seran claramente sistemas terminales. X se puede congurar para que
sea de transito o terminal, permitiendo que anuncie rutas o no, respectivamente. Una situaci on
que se da con cierta frecuencia es que un sistema aut onomo terminal este conectado a dos
proveedores de servicio (ISPs). En este caso, X podra 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 p ublicas que este bajo el control del ISP. Si un AS est a conectado
a dos ISPs al mismo tiempo, se presentan dos opciones:
Solicitar un rango de direcciones p ublicas, independiente de cualquier ISP. Es una soluci on
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 propagar a por toda la red a traves de ambos AS.
En ocasiones, varios sistemas autonomos se unen para crear una confederaci on. 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 unico AS.
Figura 5.38: Problema de la creacion de confederaciones.
Vemos que la creaci on de confederaciones a veces evita que se pueda escoger el camino
optimo. En la ilustraci on, si el AS 33 quisiera llegar hasta el ASN 38, el camino m as corto sera
a traves de 1, 37 y 4. Sin embargo, desde fuera vemos a la confederaci on como un s olo AS, no
tenemos acceso a informaci on sobre los AS de su interior. Si siguieramos ese camino, estaramos
entrando dos veces en el AS 15, lo cual no est a permitido (se prohbe que una ruta pase dos
veces por un mismo AS para evitar bucles). La ruta a seguir tendra que ser la marcada con
lnea continua, que tiene un salto m as que la ruta optima.
Reectores de rutas
Figura 5.39: Uso de reectores de rutas.
Los reectores de rutas se utilizan para evitar tener que realizar un mallado total de cone-
xiones iBGP dentro de un AS. El reector de rutas est a unido al mallado total, y ademas existen
varios nodos que se conectan unicamente al reector de rutas. Aunque normalmente lo que se
aprende por una conexion iBGP no se puede retransmitir por otra conexi on iBGP, el reector
de rutas viola esta norma y enva toda la informaci on de que dispone por sus enlaces. Mediante
el uso de reectores se ahorra la creacion de muchas conexiones, pero hay que tener en cuenta
que el reector es un elemento centralizado, y como tal un fallo en el reector sera catastr oco
para la red.
Veamos ahora un ejemplo real de conguraci on 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 direcci on 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 congesti on
Introducci on
En una red de conmutacion ideal, la situaci on de congestion nunca llega a producirse. Al
tener los nodos memoria innita, ning un paquete se pierde, independientemente del tr aco. Pero
en una situaci on real, cada cola solo puede almacenar un n umero limitado de paquetes, por lo
que es necesario un mecanismo que impida que la red se congestione y se bloquee el traco.
Dada una red de conmutaci on de paquetes, la evolucion 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 teorica. Igualmente podemos calcular la carga normalizada
como los paquetes por segudo que entran al sistema dividido por la capacidad te orica.
La carga en el sistema puede aumentar por varias razones:
Encaminamiento defectuoso: un encaminamiento perfecto repartira la carga lo mejor po-
sible, por lo que retrasa la congesti on del sistema. Hay que tener en cuenta que solamente
la retrasara: si la entrada de datos es superior a la capacidad del sistema para procesarlos,
por muy bueno que sea el encaminamiento acabar a 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 saturaci on de las colas (overow). Al perderse paquetes, es
necesario retransmitirlos, por lo que aumenta la carga. Esto provoca un crculo vicioso que hace
que el sistema llegue al punto de bloqueo.
Para evitar este crculo vicioso, se utilizan los mecanismos de control de congestion.
No hay que confundir mecanismos de control de congesti on con mecanismos de control de
ujo. En control de ujo, el extremo receptor da ordenes al transmisor para que reduzca o frene
su transmisi on. En control de congestion, es la red la que lo decide. El control de ujo puede ser
consecuencia del control de congesti on.
5.8.4. Clasicaci on de los mecanismos de control de congesti on
Los mecanismos de control de congestion se pueden clasicar seg un 3 caractersticas:
Seg un lugar de realizacion:
En los encaminadores: son los encaminadores los que tienen mayor responsabilidad
en el control de congesti on.
En los sistemas nales: la responsabilidad del control de congestion recae en su
mayor parte sobre los sistemas nales.
Ojo, aunque el lugar de realizaci on sea en los encaminadores, siempre una peque na parte
del procesamiento la tendran que realizar los sistemas nales. Igualmente ocurre en el caso
contrario.
Seg un el mecanismo en que esten basados:
Basados en realimentaci on: Los sistemas nales reciben ordenes sobre como de-
ben comportarse (es decir, si deben aumentar el traco que transmiten o reducirlo).
Estas ordenes pueden provenir de los encaminadores (si es un mecanismo localiza-
do en encaminadores) o puede ser que los mismos sistemas nales tomen decisiones
basadas en lo que observan que ocurre en la red (por ejemplo, si ven que se est an per-
diendo paquetes, podran decidir reducir su tasa de transmision). Este ultimo metodo
est a asociado con los mecanismos de congestion localizados en sistemas nales.
Basados en reserva: un sistema nal tiene que pedir permiso antes de inyectar in-
formaci on 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 conmutacion de paquetes, y realizar una reserva de recursos es
contraproducente en general). La reserva que se produce es virtual.
Seg un la forma de darle derechos de transmisi on al emisor:
Basado en creditos: el emisor recibe una serie de creditos. Por cada credito, puede
introducir un paquete en la red. La asignaci on de creditos es dinamica, similar a una
ventana deslizante.
Basados en tasa: el emisor tiene una velocidad maxima a la que puede transmitir
paquetes.
Captulo 6
Capa de transporte
6.1. Introducci on 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 nales los que se entienden extremo a extremo,
sin importarles la red intermedia.
Figura 6.1: Nivel de transporte.
La capa de transporte puede a nadir las siguientes funcionalidades:
Fiabilidad.
Orientaci on a conexi on.
Posibilidad de multiplexi on de conexiones.
99
ISO normaliz o y deni o 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 numeraci on superior capaz de recuperar mas errores; TP4 es capaz de recuperar
casi cualquier error, pero tambien es el m as complejo). Tambien se denieron servicios ofrecidos
por el nivel de transporte, tanto orientados a conexi on como no orientados a conexi on.
Estos protocolos tenan 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. Jerarqua TCP/IP
6.2.1. UDP
Protocolo de Datagrama de Usuario (User Datagram Protocol). Denido en la RFC 768.
Es un protocolo con el cual se ofrece un servicio no orientado a conexion (CL, Connection
Less) y no able. Esto era pr acticamente lo que ofreca el nivel de red, IP, pero la diferencia
es que con UDP se a nade la capacidad de multiplexion (MUX). En UDP se utiliza el n umero
de puerto para multiplexion: los mensajes van a la misma m aquina pero dentro de ella van a
una aplicacion u otra dependiendo del n umero de puerto. Por tanto, una direcci on UDP tiene la
forma:
Direcci on UDP = Direcci on IP +Puerto UDP (6.1)
En la cabecera IP se indica que la informaci on que est a encapsulada es un paquete UDP
poniendo en el campo protocolo el valor correspondiente a UDP, que es 17.
En la cabecera UDP van el n umero de puerto origen y el n umero de puerto destino (al
igual que en la de IP iban la IP origen y la IP destino). Los n umeros 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 estan reservados para aplicaciones especcas. Por
ejemplo:
69: puerto para TFTP, Trivial File Transfer Protocol (transferencia de cheros trivial).
513: puerto para who, que permite conocer quien ocupa el equipo en ese momento.
La longitud total del segmento mide el tama no del segmento completo (cabecera y datos)
en octetos.
Checksum es un c odigo de redundancia que detecta errores. Para calcularlo, se tienen
en cuenta las direcciones IP del datagrama donde va este segmento, es decir, tomamos
informaci on del nivel inferior (en OSI, eso sera una HEREJA).
Algunos campos aceptan valores especiales:
Si ponemos checksum = 0 en la trama, estaramos indicando que no est a calculado el
c odigo de redundancia.
Si ponemos puerto origen = 0 no estaramos indicando el origen, por lo que el destino
no podr a contestar.
6.2.2. TCP
Protocolo de Control de Transmision (Transmission Control Protocol). Denido en la RFC
793. Con este protocolo se puede ofrecer un servicio orientado a conexion (CO,Connection Orien-
ted) y able (adem as de ofrecer multiplexi on, al igual que UDP). Al ser un servicio CO es d uplex
(se pueden enviar datos en ambos sentidos, da igual quien haya iniciado la conexi on). Dicha co-
nexi on est a identicada por una direcci on TCP:
Direcci on UDP = Direcci on IP +Puerto UDP (6.2)
El n umero de puerto sirve para poder multiplexar. Veamos un ejemplo:
Figura 6.5: Ejemplo de multiplexi on.
En la m aquina con IP1 tengo 3 conexiones distintas con la misma IP y puerto origen. Las
conexiones con la maquina IP2 se diferencian en el n umero de puerto destino, puesto que TCP2
es distinto que TCP3 en IP2. Vemos que una conexion IP esta denida unvocamente por
4 parametros: IP origen, puerto origen, IP destino y puerto destino. Se pueden repetir
hasta 3 de estos parametros en dos conexiones distintas, pero nunca los cuatro a la vez.
Podemos tener un servidor asociado a un n umero de puerto. Por ejemplo, si TCP1 fuera
el puerto asociado con un servidor FTP (puerto 21), estaramos transriendo cheros hacia el
mismo puerto, pero desde maquinas distintas (llegan datos desde 2 y 3).
La abilidad es este tipo de conexion 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 informaci on y lo que hacemos es
retransmitir. El modelo que se usa en estos casos es el siguiente:
Figura 6.6: Modelo de colas para transmisi on en TCP.
La m aquina destino recibe en un buer y, cuando comprueba que no falta nada y todo
est a 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. S olo se obliga a que lo que se enva a la capa adyacente
este en el mismo orden en que se envi o. Al contrario que OSI, ni siquiera se obliga a que el
tama no del paquete que se envi o 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 reenva 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 enva al nivel
inferior. Este entonces lo pone en una cola, y lo transmite cuando considere oportuno. Hay dos
modicaciones 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 buer lo antes posible. Existe un
ag dentro de la trama que se enva (recordemos que un ag 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 estan 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 ag) y adem as es obligatorio
indicar cuantos de los datos son urgentes.
En TCP existe control de ujo: el receptor frena al emisor, diciendole el receptor al emisor
la cantidad de octetos que puede enviar sin esperar asentimiento. Esto es lo que se llama tama no
de ventana. Aqu se usa ventana deslizante (regulable seg un lo que desee el receptor). Como la
conexi on es d uplex, lo que pasa en un sentido pasa tambien 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 multiplexi on. Son de 16
bits cada uno (van de 0 a 65535)
N umero de secuencia: en vez de numerarse los segmentos, se numeran los octetos (Los
octetos tienen su propio n umero de orden. Se pone el n umero 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 n umero con el
que se comienza a numerar los octetos es aleatorio, y se decide en el establecimiento de la
conexi on. Un ejemplo sera:
Figura 6.8: Numeracion de octetos en la cabecera TCP.
Asentimiento: Se enva el n umero 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 tama no de la cabecera,
en unidades de 4 octetos (32 bits). El tama no mnimo 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: Seccion de ags 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, signica 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 conexion cuando vale 1. Veremos su uso en un apartado
posterior.
SYN(SYNchronous idle, espera sncrona): se usa en el establecimiento de la conexi on,
para ponerse de acuerdo ambos extremos.
FIN: para el cierre de la conexion. Al contrario que RST, que cierra la conexi on de
forma abrupta, con FIN se comienza un proceso de negociaci on para el cierre.
Tama no de ventana: Le dice al receptor el n umero de octetos que puede enviar sin tener
que esperar asentimiento. Si est a a 0, no podr a mandar nada.
Checksum: Aqu en el calculo del checksum, tambien se tienen en cuenta las direcciones
IP (nivel inferior).
Campos opcionales: al igual que la cabecera IP, los campos opcionales deberan ser m utiplos
de 4 octetos. Si no lo son, se a nadira 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 el.
Es un protocolo bueno porque es muy simple, pero da poca informacion. Eso podemos verlo
en el ejemplo anterior, con el paquete de n umero de secuencia 2500 (resaltado en un recuadro),
que se ha retransmitido sin ser necesario. Cuando perdemos una r afaga de paquetes sabemos
que el primero se ha perdido, pero no sabemos si tambien se han perdido los que siguen. Hay
dos formas de enfrentarse a esta situaci on:
Ser conservativos: Retransmitir el que se piensa que se ha perdido y esperar asentimiento.
Si es el unico que se haba perdido, llegar a el asentimiento de todo el conjunto completo,
Figura 6.10: Funcionamiento de los asentimientos en TCP.
en el ejemplo ACK=4500. Pero si se haban 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 ineciente.
Ser agresivos: Retransmitir todo aunque lo dem as no se haya perdido, pero de esta forma
gastamos ancho de banda y mas recursos.
Realmente el problema no tiene una solucion optima, depende de la implementacion.
Funcionamiento de la ventana deslizante:
La ventana autorizada representa lo que puedo enviar sin recibir asentimiento. Vemos como
con asentimientos se va desplazando el borde inferior de la ventana y con el tama no se limita el
borde superior. Para implementar el mecanismo de retransmision, 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 calculo
del temporizador debe ser acorde con el comportamiento de la red.
Calculo del temporizador de retransmisi on de TCP:
El tiempo que pasa desde que se enva un paquete hasta que se retransmite es par ametro
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: Denicion 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 estimacion, el RTT estimado,
seg un la siguiente formula:
RTT
est
= RTT
estant
(1 ) +RTT
medido
() (6.3)
Con ello conseguimos suavizar el RTT. Tambien podemos calcular la desviaci on y suavizarla:
DESV
est
= DESV
estant
(1 )+ | RTT
estant
| (6.4)
Con estos par ametros podemos calcular el valor del temporizador:
TEMP = RTT
est
+DESV
est
(6.5)
El resultado ser a un poco m as grande que lo que tarda en llegar el ACK, pero no mucho
m as.
Ahora se nos presenta un nuevo problema. Si retransmitimos un segmento y nos llega un
ACK, no podemos saber si ese ACK se reere al segmento original o a la retransmisi on.
Figura 6.13: Ambig uedad 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 f ormula de RTT.
En su lugar, con cada retransmisi on se aumenta el temporizador de los segmentos enviados y no
asentidos al doble (hasta un valor maximo). Cuando no hay retransmisi on ya se vuelve a medir
el temporizador mediante la f ormula.
Control de congesti on 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 historicamente se llame control de
congesti on, realmente lo que hace es ayudar para que no haya congestion, no la controla. Sera
un control de congestion si todas las comunicaciones de una red se hicieran usando el protocolo
TCP exclusivamente.
Hemos visto que en los segmentos aparece un campo que especica la ventana indicada por
el receptor. Adem as de esa, en TCP hay otra ventana que es la ventana de congesti on, la cual
se va reduciendo cuando se estima que hay congestion. El mnimo 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 congesti on) (6.6)
Si no hay congesti on, la ventana autorizada sera la ventana indicada por el receptor. El
c a1lculo de la ventana de congesti on se realiza de la siguiente forma: cada vez que se estima que
hay congesti on (se considera que hay congesti on si hay que retransmitir un segmento),
se disminuye el tama no de la ventana de congestion a la mitad. Eso se har a as hasta
que la ventana alcance el tama no mnimo de un segmento (que no un octeto). Recordemos
que, como el algoritmo de Karn controla la retransmisi on, 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 congesti on en el tama no 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 tama no 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 aclaraci on: la notaci on del nombre de los protocolos puede dar lugar a equvocos. El pro-
tocolo de arranque lento en realidad es mas ra1pido que el segundo. En el primero, cuando
recibes un asentimiento ya puedes mandar m as 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 empezar an a recibir asentimientos repetidos (como se puede ver en la g10). 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 congestion: disminuye la ventana
de congesti on a la mitad y los temporizadores se duplican. Establecimiento de conexion: Durante
el establecimiento de la conexi on se negocian par ametros como el tama no maximo de segmento
y los n umeros de secuencia iniciales en cada sentido. Se hace en tres etapas:
Figura 6.14: Protocolo para establecimiento de la conexi on
1. Uno de los extremos enva un paquete, compuesto s olo de una cabecera con el bit SYN a
1 (expresa el deseo de iniciar una conexi on) y un n umero de secuencia arbitrario X (ser a1
el n umero de secuencia inicial en ese sentido de la transmision).
2. El otro extremo le responde con otro paquete, compuesto exclusivamente de una cabecera,
con el bit SYN a 1 (el tambien desea establecer una conexi on en el otro sentido, recordemos
que en TCP las conexiones son d uplex), el n umero de secuencia Y (n umero de secuencia
inicial en su sentido de la transmision) y asiente el n umero 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 n umero de secuencia es ahora X+1,
y asiente el n umero de secuencia enviado por el otro extremo con un ACK a Y+1. En
este momento, se considera que la conexi on est a establecida y se pueden empezar a enviar
datos en ambos sentidos. De hecho, el extremo de la izquierda podra haber empezado a
enviar datos justo despues 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 ning un octeto de datos. Esto se hace as porque se
considera que el bit SYN puesto a 1 equivale a enviar un octeto de datos
(tambien ocurrira esto con el bit FIN, como veremos mas adelante). Otra cuesti on que
llama la atencion es que se utilice un n umero de secuencia arbitrario, en lugar de empezar
siempre por 0. Esto se hace as para evitar confusiones: si empez aramos siempre por 0, al
abrir una conexion, cerrarla r apidamente y volverla a abrir podran confundirse los paquetes
pertenecientes a cada una de las conexiones (tendran n umeros de secuencia similares). Para
evitar esto, adem as de usar n umeros aleatorios, TCP recuerda los n umeros de secuencia
que utilizo en las ultimas conexiones para no repetir los mismos n umeros contra los mismos
destinos.
Cierre de la conexion:
Para el cierre de la conexi on no la tiene que cerrar el extremo que la abri o. Lo que si es que
hay que cerrarla en ambos sentidos por separado. Puede que cerremos la conexi on en un
sentido pero en el otro sentido a un queden paquetes por enviar. Se enviar an los paquetes y
despues se cerrar a el otro sentido de la conexion. Una vez cerrado un sentido de la conexi on,
el transmisor correspondiente a ese sentido queda limitado a enviar asentimientos, no puede
enviar datos.
Figura 6.15: Caso m as simple: ambas conexiones se cierran
Algunos detalles a tener en cuenta sobre el segundo caso:
Como decamos, el extremo transmisor de la conexion cerrada solamente puede transmitir
cabeceras con asentimientos, no datos. Hay que resaltar que todas las cabeceras tendran
el n umero de secuencia correspondiente al que tendran si enviaran datos, pero
dicho n umero de secuencia no cambia porque no se enva ning un octeto de datos.
Figura 6.16: Caso complejo: primero se cierra un sentido y despues otro
Una conexion se considera cerrada cuando se recibe el asentimiento al paquete que contena
el bit FIN a 1. Es necesario cerrar cada uno de los dos sentidos.
Hay un caso especial de cierre de conexion, llamado liberacion abrupta. Se suele dar
cuando hay alg un error. El cierre de la conexi on es sin negociaci on, 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-
ma no mnimo 20 octetos e IP tiene una cabecera de tama no mnimo 20 octetos. Por otra parte,
el nivel de enlace que se use tambien tendra su propia cabecera que a nadir a esto. Esto quiere
decir que, independientemente del tama no de los datos, estamos transmitiendo una cabecera de
al menos 40 octetos en cada datagrama.
Existe un fenomeno, llamado sndrome de la ventana tonta (Silly Window Syndro-
me), en el que se desperdicia mucho ancho de banda en cabeceras. El fen omeno consiste en lo
siguiente:
El extremo receptor (B) necesita que el extremo transmisor (A) se frene moment aneamente
porque el buer de recepci on de B est a saturado. Para ello, le enva como tama no de
ventana de transmisi on el valor 0.
Figura 6.17: Liberaci on abrupta por cada de uno de los extremos
B se recupera un poco, consigue un espacio de un octeto en su buer y enva a A el tama no
de ventana de transmision 1 (es decir, puede transmitir un octeto de datos)
Si A transmite, estara enviando un paquete con 1 octeto de datos y mas de 40 de cabeceras.
El rendimiento sera inferior al 2,5 %.
Para evitar esto, cuando B enve un tama no de ventana 0 a A, tendr a que esperar antes de
cambiar el tama no de ventana de transmisi on de A. No podra enviarle un tama no de ventana
distinto a A hasta que ocurra una de estas dos condiciones:
En el buer de B cabe un segmento de A (es decir, el tama no de segmento que se negoci o en
el establecimiento de la conexi on).
La mitad del buer de B est a vaco.
Tambien puede darse la situacion de que el transmisor tenga poca informacion que enviar.
En ese caso, se hace lo siguiente:
Si todo lo que A ha enviado est a asentido, A enva lo poco que tenga que enviar (aunque
s olo 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 nales con la siguiente torre de protocolos:
Figura 6.18: Liberaci on abrupta por exceso de retraso durante establecimiento de conexion
Nos dan los siguientes datos:
Retardo de propagacion:105ns
Caudal ofrecido en el nivel fsico: 64Kbps (nota: K = 10
3
)
La ventana TCP es ja de 2000 octetos.
La ventana LAPB es ja a 6 tramas.
Queremos transmitir 40.000 octetos de datos
Suponer que en el establecimiento y cierre de la conexion no se envan datos, tan solo
cabeceras.
Suponer la conexi on LAPB previamente establecida.
Figura 6.19: Torre de protocolos del ejercicio
Se pide:
Cu anto tiempo se tarda en establecer la conexion? Y el cierre?
Tiempo mnimo de transmision 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
gui ondel nal 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 tama no de los segmentos TCP, nos encontramos con un problema
de optimizaci on. Cuanto mayor sea el segmento, mayor es el rendimiento (ya que hay mas datos
para la misma cabecera). Pero, como tenemos una ventana limitada, tambien ser a mayor el
tiempo muerto que nos pasamos sin transmitir, mientras llega el asentimiento:
A la larga nos interesa estar el mnimo tiempo sin transmitir, que se haga 0, para tener envo
contin uo en ese punto. Con ello disminuye el rendimiento (m as cabecera para los mismos datos),
Figura 6.21: Tiempo muerto en funcion del tama no de trama
pero transmitimos m as 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 jo. Si nos sale que el n umero optimo
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 transmisi on de LAPB no deja transmitir mas de 6 tramas.
Captulo 7
Evoluci on de los equipos y tendencas
7.1. Introducci on a IPv6
IPv6 es una evolucion de IPv4. Est a 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
est an 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 direcci on IPv6 v alida sera:
3FFE : 0501 : 0008 : 0000 : 0260 : 97FF : FE40 : EFAB
Adem as, se permiten dos simplicaciones para las direcciones: se puede sustituir una
cadena de ceros de cualquier longitud por ::, y adem as los ultimos 4 octetos se pueden
representar igual que se representaban las direcciones en IPv4. Aplicando esto al ejemplo
anterior, la direccion sera equivalente a poner:
3FFE : 0501 : 0008 :: 0260 : 97FF : 254.64.239.171
Es importante tener claro que solo se puede sustituir una cadena de ceros por
118
::. Si hay varias, como en la direcci on anterior, lo normal es escoger la m as larga.
Al igual que en IPv4, existe una serie de direcciones especiales. Antes de explicarlas, vamos
a aclarar la notaci on que vamos a utilizar para representarlas. En IPv6, un prejo de direcci on
especial se representa como:
Direcci on IPv6/n umero
y se interpreta como que todas las direcciones que empiecen por los primeros n ume-
ro bits de la Direccion IPv6 pertenecen a ese tipo de direcciones. Por ejemplo, si decimos
que la direccion de tipo multicast es FF00 ::/8, nos referimos a que cualquier direcci on cuyos
primeros 8 bits coincidan con los primeros 8 bits de FF00 :: es una direccion multicast. En este
caso en particular, estaramos diciendo que una direcci on que empiece por 11111111 (FF) es una
direcci on multicast.
Hay que tener mucho cuidado con esto, ya que estamos representando las direccio-
nes en hexadecimal y la mascara como n umero de bits. Esto puede llevar a situaciones
curiosas: por ejemplo, si decimos que una direcci on Unique Local Unicast (se ver a m as tarde) em-
pieza por FC00 ::/7, hay que tener una especial precauci on. FC, en binario, equivale a 11111100.
Como tomamos los 7 primeros bits, valdr an tanto las direcciones que empiezan por 11111100
(FC) como las que empiezan por 11111101 (FD). Por tanto, una direccion que empiece por FD
tambien entra dentro de FC00 :: /7!
7.3. Direcciones especiales en IPv6
Unspecied(no especicadas): Son las direcciones ::/128 (todos los bits a 0). Se usan en el
campo origen cuando queremos enviar algo y todava no tenemos una direccion asignada.
Loopback (bucle local): Son las direcciones ::1/128 (todos los bits a 0 y el ultimo 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 despues cualquier direcci on de 4 octetos). Sirven para encapsular direc-
ciones IPv4 en IPv6.
Multicast (para m ultiples destinos): Son las direcciones FF00::/8 (primeros 8 bits a 1).
Existen varias direcciones especiales:
Direcciones de difucion para nodos:
Difusi on para nodos local: Es la direcci on FF01::1. Alcanzan todas las entidades
IP dentro de un mismo nodo.
Difusi on para nodos en el enlace: Es la direccion FF02::1. Los paquetes llegan a
todos los nodos alcanzables sin pasar por un router.
Direcci on de difusi on para routers:
Difusi on para routers local: Es la direccion FF01::2. Alcanza al propio nodo que
la enva.
Difusi on para routers en el enlace: Es la direccion FF02::2. Los paquetes llegan a
todos los routers alcanzables sin atravesar un router.
Difusi on para routers en el site: Es la direcci on 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 llegar a hasta el borde de la red que controlamos
nosotros (hasta el router de salida a Internet).
Direcci on de difusi on de nodo solicitado(solicited-node):
es una direccion especial, cuyo prop osito es sustituir al protocolo ARP (como se
ver a en el estudio de la resoluci on de direcciones dentro del apartado ICMPv6). Esta
direcci on est a asociada a una direccion unicast, y se construye de la siguiente forma:
Es decir, se toma como prejo la direccion FF02::1:FF00:0/104 (el paquete empieza por
FF02::1:FF) y se ponen a continuacion los ultimos 24 bits de la direccion unicast asociada.
A nivel de enlace, la direccion MAC destino que se utiliza en Ethernet se crea de esta forma:
esto es, copiamos los ultimos 32 bits de la direccion IPv6 destino como ultimos 32 bits
de la direcci on MAC, y lo prejamos con 2 octetos que nos van a indicar que es una direcci on de
difusi on: 33 33. Cuando un nodo reciba un paquete con esta direccion de enlace, lo aceptara por
empezar por 33 33. Entonces mirara los ultimos 4 octetos de la direccion MAC: si se corresponden
con los ultimos 4 octetos de su direcci on IP multicast solicitada, aceptar a el paquete. En caso
contrario, lo descartar a. La ventaja de usar este metodo es que todos los calculos anteriores se
pueden programar a nivel hardware, con lo que se consigue una gran velocidad.
Existe una peque na probabilidad de que varios nodos tengan iguales los ultimos 32 bits
de la direcci on multicast solicitada. Si eso ocurriera y el nodo aceptara el paquete por error, al
pasarlo a su nivel de red se dara cuenta de que la direcci on IP destino no es la suya y descartara
el paquete entonces.
Anycast (cualquier destino de un grupo): Sintacticamente, son como las direcciones
unicast. Sin embargo, al usar este tipo de direcciones, estaremos enviando un paquete a un
grupo de maquinas. La diferencia con multicast es que, mientras que un paquete enviado
a una direccion multicast tiene que llegar a todos los destinos, un paquete enviado a una
direcci on anycast tiene que llegar a uno y s olo a uno de los destinos del grupo, en
general al m as 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 podran llegar a el 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 ambito de validez es un enlace de IPv6 (en IPv6 se considera un
enlace a un conjunto de m aquinas unidas por un medio com un, tal que en el las m aquinas
se pueden comunicar sin que sus paquetes atraviesen un router). Por tanto, dos
nodos a los que se les haya asignado una direcci on local al enlace s olo 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. Adem as, los nodos
pueden asignar automaticamente este tipo de direcciones.
Unique Local Unicast (Direcciones locales unicas): Son las direcciones FC00::/7 (empie-
zan por 1111 110). Son muy parecidas a las anteriores con la ventaja de que, al ser m as
amplia la parte variable de la direcci on, es muy poco probable que dos de estas direcciones
coincidan. Por tanto, siempre que no se salga a una red p ublica (Internet), la probabilidad
de que dos m aquinas puedan comunicarse entre s es alta incluso aunque haya que atravesar
distintos enlaces o incluso sites.
Global Unicast (Direcciones globales): Son direcciones unicas en el mundo. En teora, cual-
quier direcci on que no caiga en ninguno de los rangos de direcciones especiales, es una
direcci on global. En la pr actica, hasta ahora solo se han asignado las direcciones 2000::/3
(empiezan por 001).
En resumen los tipos existentes de direcciones son:
7.4. Organizaci on de las direcciones en IPv6
IPv6 sigue la misma losofa que introdujo IPv4: las direcciones IP est an formadas por una
parte de red, com un a todas las interfaces que est an 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 identica a cada interfaz de forma unvoca. En IPv6, la parte de red se divide a su vez
en prejo global e identicador 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 tama no del prejo global sean n= 48 bits (si se
van a crear subredes) o n= 64 bits(si solo va a haber una red). Sin embargo, en algunos casos
particulares se utilizan prejos globales de n48 bits. Por tanto, la forma de una direccion IPv6
que no empiece por 000 ser a:
7.5. Asignaci on de direcciones en IPv6
La asignacion de direcciones puede ser:
Manual
Mediante DHCPv6 (RFC 3315)
Por autoconguraci on: al arrancar, cada nodo genera una direcci on local al enlace o una
direcci on global (seg un lo especicado por la RFC 2462). En este tipo de asignaci on, la
parte de red de la direcci on generada puede ser:
Si se ha generado una direccion local al enlace, la parte de red ser a FE80::/64.
Para otro tipo de direcciones, la direcci on de red se toma de anuncios peri odicos que
hace el router a toda la red. En dichos mensajes, el router anuncia tanto su direccion
(para que los nodos la tomen como direcci on de gateway) como el prejo que deben
tener los nodos de la red.
Para explicar c omo 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 estandar del IEEE (rec. 802.1). Son direcciones de 48 bits,
unicas en el mundo.
Direcciones EUI-64: Son un estandar m as moderno del IEEE. Son muy parecidas a
las direcciones MAC, pero su tama no es de 64 bits en lugar de 48.
En ambos casos, los dos ultimos bits del primer octeto de la direccion son bits con un
signicado especial. El bit n umero 7 es el bit global/local. Dicho bit indica si una direccion
es unica en el mundo (si vale 0) o bien puede estar repetida (si vale 1). El bit de gru-
po/individual se utiliza para identicar si la direccion destino es una direccion individual
(si vale 0) o una direccion de grupo (si vale 1).
Una vez conocemos los tipos de direcciones existentes, veamos como se usan al generar una
direcci on IPv6 por autoconguracion:
Si tenemos una direccion EUI-64: Se utiliza el llamado formato modicado UEI-
64. Para generar la parte de host, usamos la direcci on EUI-64 que tenemos pero con
el bit global/local invertido (por eso se llama modicado).
Si tenemos una direccion MAC: Ampliamos la direccion a 64 bits introduciendo
en el centro de la direccion MAC dos octetos: FF FE. Adem as, tambien
invertimos el bit global/local.
No es evidente a primera vista la necesidad de invertir el bit global/local. En principio, una
direcci on de enlace que tenga un ambito local se podra generar a mano. Lo m as probable
es que la persona que la escriba ponga por comodidad una serie de bits a 0 y al nal un
valor (es decir, empezara asignando ::1, despues ::2...). Pero si lo hace as, como el bit
global/local es de los primeros, lo estara poniendo a cero. Eso signicara que la direcci on
que se esta escribiendo es unica en el mundo, lo cual no es verdad ya que nos la estamos
inventando. Para evitar esta situaci on, se decidi o que en este tipo de direcciones el bit
global/local a 0 signicara que la direccion es local, y a 1 que la direcci on es unica en el
mundo (justo lo contrario de lo que deni o el IEEE). Por tanto, es necesario invertir el bit
global/local de las direcciones del IEEE para darle el signicado que nosotros queremos.
7.6. Formato de datagramas IPv6
El formato que siguen los datagramas IPv6 es el siguiente:
Version: indica la versi on del protocolo (en este caso, la 6).
Clase de tr aco: marca los datagramas seg un el tipo de tr aco que transportan (sensible
a retardos, de baja prioridad, etc.)
Etiqueta de ujo (Flow Label): Se asigna la misma etiqueta a paquetes que esten relacio-
nados entre s (por ejemplo, a aquellos que pertenezcan a una misma conexi on).
Longitud de la carga (o payload): mide lo que hay despues de los 40 octetos de cabecera.
Se mide en octetos.
Next Header (siguiente cabecera): En IPv6, los par ametros 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
Lmite de saltos (Hop Limit): equivale al TTL de IPv4. Dene el n umero maximo de routers
que puede atravesar el paquete antes de ser descartado.
Direcci on 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 codican mediante TLV (Tipo, Longitud, Valor). En este tipo de codica-
ci on, cada opci on estar a compuesta de un campo tipo de tama no jo, un campo longitud
de tama no jo y un campo valor de tama no indicado por el campo longitud. El tipo de la
opcion indica varias cosas:
Si el router puede modicar la opcion.
Si el router no entiende la opci on, 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 tama no m ultiplo de 4 octetos. En caso de
necesidad, se utiliza relleno.
Cabecera de enrutamiento (Routing): permite que el nodo origen del mensaje especique
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 cuantas direcciones de las contenidas en
el paquete quedan por atravesar. Inicialmente sera N.
Destinos: son las direcciones IP de los routers que deber a 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, pondramos la direcci on del destino nal, 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 direcci on IP del destino nal del mensaje. Un ejemplo del
uso de esta cabecera es el siguiente:
Vemos como el paquete del ordenador con IP a router (IP ) como direccion destino en la
cabecera IP. Cuando el paquete llega al router b b, este lo interpreta y, como el n umero de
segmentos restantes es 3, cuenta 3 IPs desde el nal 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 nal
sepa por que routers ha pasado la informaci on. Este procedimiento se repite hasta que el
n umero de segmentos restantes es 0, en cuyo caso la maquina que interpreta el paquete
sabe que es para ella.
Algo a resaltar es que, aunque estemos especicando una serie de routers por los
que el paquete debe pasar obligatoriamente, entre ellos puede pasar por routers
que no hayamos especicado.
Cabecera de opciones de destino (Destination Options): Es una cabecera extremo a extremo
(s olo 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 enva un mensaje con estas caractersticas, los nodos de la lista de enrutamiento ver an
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 s olo la ver a el nodo nal.
7.8. Protocolo ICMPv6
Es una evolucion del protocolo ICMP que se usaba en IPv4. En este protocolo se denen
una gran cantidad de mensajes, aunque nosotros s olo estudiaremos los mensajes que se usan para
el establecimiento de vecindades. Su c odigo 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 signicado:
Tipo (8 bits): indica el tipo de mensaje. Si es un mensaje de error se representa con el bit
m as signicativo a 0; un mensaje de informaci on se representa con el bit m as signicativo
a 1.
C odigo (8 bits): sirve para distinguir los diversos mensajes de cada tipo. Si para un cierto
tipo s olo hay un mensaje, vale 0.
Checksum (16 bits): para comprobar la integridad del mensaje.
Cuerpo del mensaje: su estructura vara seg un el mensaje que estemos transmitiendo.
En establecimiento de vecindades se usan cuatro mensajes ICMPv6 distintos:
RS (Router Solicitation, solicitud a router): Este mensaje lo envan los nodos a los
routers cuando necesitan conocer alg un par ametro de estos. Se envan con la direcci on
multicast de routers como destino.
RA (Router Advertisement, anuncio de router): los routers envan estos mensajes
periodicamente o como respuesta a un RS. SIrve para anunciar varios par ametros: el ta-
ma no m aximo de paquete que soportan (MTU), si son routers de salida de la red o no...
Entre estos par ametros, el m as importante es el prejo de red. Los nodos deben conocer
este valor para poder autocongurarse. El mensaje RA se enva periodicamente con la di-
recci on destino multicast de nodos. Si se enva como respuesta a una petici on RS, se hace
con direccion destino multicast solicitada.
NS (Neighbor Solicitation, solicitud a vecino): Se utiliza este tipo de mensajes con
tres nes:
Resoluci on de direcciones: en lugar de utilizar el protocolo ARP, para hallar la direc-
ci on de enlace asociada a una direcci on IP se enva un mensaje NS a la direcci on
multicast solicitada correspondiente a la direccion IP que se desea resolver.
El nodo correspondiente recibira el mensaje y respondera con un mensaje NA,
en el que indicar a su direcci on de nivel de enlace.
Detecci on de direcciones duplicadas (Duplicate Address Detection): hemos visto que
existen metodos de conguracion automatica, en los que cada nodo se asigna una
direcci on. Esto puede provocar una situaci on en la que dos nodos se asignen la misma
direcci on. Para evitarlo, antes de comenzar a funcionar cada nodo enva un
mensaje NS para comprobar que su direccion sea unica. En el mensaje NS
intenta resolver su propia IP: si nadie responde, signica que nadie tiene esa IP y
puede asign arsela sin problemas. Si alguien responde, tendr a 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 util, por ejemplo, si
un nodo ha estado comunic andose con otro durante un tiempo, y esa comunicaci on ha
terminado. Para volver a comunicarse con el mismo nodo, primero deber a comprobar
si a un sigue funcionando con la misma direccion. Para ello, enviara un mensaje probe
al nodo.
NA (Neighbor Advertisement, anuncio de vecino): Se enva como respuesta a un
NS. Tambien se enva en caso de que un nodo cambie su direccion de enlace, para anunciar
el cambio.
REDIR (Redireccion): Al igual que en ISO, se enva un mensaje de redireccion para
indicarle a un nodo la direccion correcta de nivel de red a la que tiene que asociar una IP.
Como novedad, ademas de direcci on IP se puede incluir en el mensaje la direcci on de nivel
de enlace del destino, con lo que el nodo se ahorra una resoluci on de direcciones.
7.9. IPv6 Movil
IPv6 movil, denido en las RFC 3775 y 3776, es un protocolo que permite que un nodo
(llamado MN, Mobile Node o nodo m ovil) se traslade fsicamente pero siga recibiendo paquetes
dirigidos a el, independientemente de la red a la que este conectado. Comencemos explicando la
terminologa que vamos a usar:
El nodo m ovil es la m aquina que se va a desplazar a traves de la red. Inicialmente, per-
teneeer a a la red del home agent, que es su router por defecto. A lo largo del ejemplo, nos
comunicaremos con otra m aquina, perteneciente a otra red, a la que llamaremos CN (Corres-
pondent Node, nodo correspondiente).
Cuando el nodo movil esta conectado en su red origen, tiene asignada una direccion 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 direcci on destino la del CN, como
direcci on origen la HA y se enviar a al home agent para que lo enrute.
Si el nodo m ovil se conecta a otra red, tendr a que cambiar su direcci on a una perteneciente
a la nueva red. A esta nueva direccion la llamaremos CoA (Care-of Address, literalmente
direcci on de cuidado). Para que los mensajes dirigidos a la HA sigan llegando al nodo m ovil, lo
que hace el nodo m ovil es establecer un t unel con su home agent. Para ello, enva un mensaje
BU (Binding Update, actualizaci on 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 t unel que hemos creado consiste en que el home agent act ua de repetidor. Cuando recibe
un mensaje IPv6 con direccion destino la direcci on HA, encapsula dicho mensaje dentro de otro
mensaje IPv6 con direcci on destino CoA y lo enva. Con eso consigue que el traslado del nodo
m ovil sea transparente a la red. Para optimizar la comunicacion, existe la posibilidad de que el
nodo movil enve al nodo correspondiente un BU. Si el nodo correspondiente est a congurado
para entender los BU, se puede establecer comunicacion entre ellos. Se utilizan cabeceras de
enrutamiento para .
en
ga nar.
a
TCP, de modo que vea la direccion CoA como HA.
7.10. Introducci on a IPsec
IPsec, denido en las RFC 4301-4309, 2403-2405 y 2410-2412, es un mecanismo que sirve
para asegurar la condencialidad y la integridad a traves de una red IP. Encripta los mensajes
y permite averiguar si han sido modicados a lo largo del trayecto.
IPsec implementa:
Protocolos de seguridad:
AH (Authentication Header, cabecera de autenticacion): sirve para vericar la inte-
gridad.
ESP (Encapsulating Security Payload, encapsulamiento de la carga de seguridad):
sirve para condencialidad y para integridad.
Protocolos de gesti on de claves (Key Management):
IKEv2 (Internet Key Exchange, intercambio de claves por Internet)
Algoritmos a usar, de encriptacion y de hash.
7.11. Introducci on a las VPN
Las VPN (Virtual Private Net, red privada virtual) son redes privadas virtuales que se
crean sobre una infraestructura p ublica. Es com un 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 trav nes de una red no
segura) y el consumo de ancho de banda.

Redes Tele Comunica C I On

Cargado por

Copyright:

Formatos disponibles

También podría gustarte

Redes Tele Comunica C I On

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

Redes Tele Comunica C I On

Cargado por

Copyright:

Formatos disponibles

Redes de Telecomunicaci on

Baquero Portero, Isidro

IS (3 dgitos) + Codigo de identicaci on (entre 1 y 4 dgitos) + n

Area: es una regi on de la red en la que se utilizan protocolos intradominio.

Areas: Subdivision de D.E.

También podría gustarte