Introduccion comunicaciones

libro abierto / serie apuntes Pablo Ruiz M´zquiz
u

Redes y sistemas de comunicaci´n
o
¬¬¬¬0.6.0

Un libro libre de Alqua

004.738

ALQ
RSC

´
Redes y sistemas de comunicacion

† lomo para ediciones impresas

http://alqua.org/libredoc/RSC

Pablo Ruiz M´zquiz
u pablo@alqua.org http://alqua.org/people/pablo

Redes y sistemas de comunicaci´n
o
versi´n 0.6.0
o
15 de abril de 2004

alqua,madeincommunity

c
copyleft
Copyright (c) 2004 Pablo Ruiz M´zquiz.
u
This work is licensed under the Creative Commons Attribution-NonCommercial-ShareAlike License. To
view a copy of this license, visit http://creativecommons.org/licenses/by-nc-sa/1.0/ or send a letter to
Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Copyright (c) 2004 Pablo Ruiz M´zquiz.
u
Este trabajo cae bajo las provisiones de la licencia Atribuci´n-No Comercial-Comparte Igual de Creative
o
Commons. Para ver una copia de esta licencia visite http://creativecommons.org/licenses/by-nc-sa/1.0/
o escriba una carta a Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.

Serie apuntes
´
Area inform´tica
a

CDU 004.738

Editores
Pablo Ruiz M´zquiz
u pablo@alqua.org

Notas de producci´n
o

´
Plantilla latex-book-es-b.tex, v. 0.1 (C) Alvaro Tejero Cantero.
compuesto con software libre

´
Indice general

Portada I

Copyleft VI

´
Indice general VII

1. Modelos de referencia 1
1.1. Clasificaciń de redes . . . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . 1
1.2. Tćnicas de conmutaciń . . . . . . . . . . . . . . .
e o . . . . . . . . . . . . 3
1.3. Jerarqu´ de protocolos y arquitectura de red . . . .
ıa . . . . . . . . . . . . 5
1.3.1. Terminolog´ de unidades de datos . . . . . .
ıa . . . . . . . . . . . . 7
1.3.2. Primitivas de servicio . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.4. Diseõ de capas para desarrollar una arquitectura de
n red . . . . . . . . . . 10
1.5. Modelo OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.5.1. Funciones de las capas . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5.2. Defectos de OSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.6. Introducciń a TCP/IP . . . . . . . . . . . . . . . .
o . . . . . . . . . . . . 15
1.6.1. Defectos de TCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.7. Elementos o dispositivos de interconexiń . . . . . .
o . . . . . . . . . . . . 15

2. Nivel de enlace 17
2.1. Mecanismos de acceso al medio . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.1. Est´ticos (TDM,FDM) . . . . . . . . . . .
a . . . . . . . . . . . . . . 18
2.1.2. Din´micos . . . . . . . . . . . . . . . . . .
a . . . . . . . . . . . . . . 18
2.2. Formato de trama definido por el estńdar 802.3
a . . . . . . . . . . . . . . 26
2.2.1. Codificaciń de la seãl para MAC . . . .
o n . . . . . . . . . . . . . . 27
2.2.2. Retroceso exponencial binario . . . . . . . . . . . . . . . . . . . . . 27
2.3. LLC (Logic Link Central) . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1. M´todos reales de detecciń de errores . .
e o . . . . . . . . . . . . . . 29
2.3.2. M´todos de correcciń de errores . . . . .
e o . . . . . . . . . . . . . . 30
2.3.3. Mecanismos de control de flujo . . . . . . . . . . . . . . . . . . . . 31
2.3.4. HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4. Nivel de enlace de la arquitectura TCP/IP . . . . . . . . . . . . . . . . . . 35

vii

´
INDICE GENERAL

3. Nivel de Red 37
3.1. Tipos de servicios proporcionados . . . . . . . . . . . . . . . . . . . . . . . 37
3.2. Organizaciń interna de la red .
o . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.1. Circuitos virtuales . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.2.2. Datagramas CL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3. Protocolo IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.4. Enrutamiento IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4. ARP y RARP 45
4.1. Introducciń
o . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5. ICMP, PING y TRACEROUTE 47
5.1. ICMP: Internet Control Messaging Protocol . . . . . . . . . . . . . . . . . 47
5.2. Ping y Traceroute . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6. Enrutamiento IP 49

Bibliograf´
ıa 53

´
Indice alfab´tico
e 54

Historia 55

Creative Commons Deed 57

Manifiesto de Alqua 59

El proyecto libros abiertos de Alqua 63

Otros documentos libres 67

viii Redes y sistemas de comunicaciń - 0.6.0
o

1 Modelos de referencia
Hemos llegado al estado actual en donde la transmisiń de informaciń se produce
o o
a escala mundial todos los d´ porque en el siglo XX el tratamiento y gestiń de la
ıas o
datos sufrieron un empuje extraordinario y porque el desarrollo de las computadoras fue
impresionante. Aparecieron n-formatos en los que esa informaciń pod´ estar contenida
o ıa
(telefon´ radio/TV, dispositivos magn´ticos, etc). Desde que en los comienzos se impuso
ıa, e
la arquitectura de Mainframe se ha ido evolucionando hasta descentralizar los sistemas
de c´lculo y potenciar las comunicaciones entre ellos1 hasta crear lo que conocemos como
a
red. Como consecuencia inmediata de este paso, el tratamiento de la informaciń se ve
o
en la necesidad de una unificaciń para organizar mejor y ser m´s eficiente.
o a
Veamos un par de definiciones que nos ayudarń a aclarar conceptos de partida:
a

Red de computadoras es una colecciń interconectada de computadoras autńomas.
o o
Dos computadoras se consideran interconectadas cuando son capaces de intercam-
biar informaciń y este trasvase no se realiza en un marco de dependencia Maestro-
o
Esclavo. Es decir, en una red de computadoras, todas ellas son autńomas y podr´
o ıan
trabajar por s´ solas si fuese necesario.
ı

Sistema distribuido es una red de computadores gestionadas de tal manera que la red
global se le esconde al usuario, que trabaja con ella de forma transparente2 .

Las redes de computadoras aportan a la empresa el poder compartir recursos y usuarios,
una alta fiabilidad y el abaratamiento de costes mientras que al usuario le permite, sobre
todo, el acceso a sistemas remotos.

1.1. Clasificaciń de redes
o
No existe una clasificaciń definitiva pero lo intentaremos mediante dos criterios ge-
o
nerales.

1. Segń la tecnolog´ de transmisiń usada
u ıa o

a) Redes de difusiń (tambiń llamadas broadcast)
o e
Comparten un canal o un medio de difusiń y se caracterizan por la gestiń
o o
del medio compartido y el direccionamiento de la informaciń. La ventaja
o
inmediata es que podemos enviar informaciń a muchas computadoras a la
o
1
Entre otros motivos, el omnipresente econ´mico
o
2
Un buen ejemplo es el sistema de exportaciń de directorios de UNiX, el Network File System NFS.
o

1


vez gracias al mecanismo de broadcast. Este tipo de redes utiliza una topolog´
ıa
v´lida para redes pequeãs ya que es vital que el retardo sea pequeõ para
a n n
evitar que haya colisiones entre transmisiones de diferentes computadoras3 .
Váse la figura 1.1.
e

Figura 1.1: Esquema de red de difusiń
o

b) Redes punto a punto
Se caracterizan por crear canales dedicados entre m´quinas mediante el uso
a
intensivo del enrutamiento. Una vez creado el canal de comunicaciń, los
o
nodos intermedios s´lo se ocupan de reenv´ los datos al nodo marcado por
o ıar
el camino. Váse la figura 1.2 para un detalle gr´fico.
e a

UAX

nodo de computación
o sistema intermedio
tabla de enrutado

UCM

Figura 1.2: Esquema de una red Punto a Punto unida a dos redes de difusiń
o

2. Segń la escala
u

a) Redes de ´rea local (LAN)
a
Longitud: 10m-1km
Velocidad de transmisiń: 10Mbps, 100Mbps, Gbps.
o
Modelo de transmisiń: Generalmente se suele usar el modelo de red de
o
difusiń.
o

3
Si us´ramos esta arquitectura de red para una red interoceńica muy probablemente varios ordenadores
a a
a la vez creer´ tener el canal libre ya que el net-lag no ser´ despreciable lo que provocar´ un caos de
ıan ıa ıa
colisiones entre diferentes informaciones enviadas.

2 Redes y sistemas de comunicaciń - 0.6.0
o

1.2 Tćnicas de conmutaciń
e o

Topolog´ Lo m´s sencillo ser´ un bus, pero tambiń es posible una de
ıa: a ıa e
estrella (equivalente a una en forma de bus4 ) y otra de anillo (topol´gi-
o
camente diferente de las otras dos)
b) Redes de ´rea metropolitana (MAN). Son muy similares a las LAN pero las
a
clasificamos en un grupo aparte porque tienen un estńdar definido para ellas.
a
Este estńdar es la norma 802.6 (IEEE). Se denominan tambiń Bus Local
a e
´
de Area Distribuida (DQDB). Para m´s informaciń, consultar el cap´
a o ıtulo 4
del Tannembaum.
Longitud: 1km-10km
Topolog´ Definida por el estńdar. Est´ formanda por dos buses unidi-
ıa: a a
reccionales (simplex), en donde las m´quinas estń conectadas como se
a a
muestra en la figura 1.3. Si una m´quina decide emitir a una m´quina
a a
situada a un lado concreto utilizar´ la interfaz de red correspondiente (en
a
la figura 1.3 las hemos representado por pequeãs flechas que salen de los
n
hosts). Lo mismo se aplica para recibir informaciń de otros hosts.
o

¦§
¤

¥
¤

¥
¤

¥
¤

¥
¤

¥

bus 1
¤

¥
¤

¥
¤

¥
¤

¥
¤

¥
¤

¥
¤

¥
¤

¥
¤

¥
¤

¥
¤

¥
¤

¥

¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¢ ¢£

bus 2

Figura 1.3: Esquema de una red metropolitana

c) Redes de ´rea extensa (WAN). Estń compuestas principalmente por l´
a a ıneas
de transmisiń del tipo que sean y dispositivos de conmutaciń. En esta clasi-
o o
ficaciń encajan bien las redes punto a punto. En este tipo de redes los nodos
o
de conmutaciń suelen ser m´quinas dedicadas5 .
o a
Longitud: >10km

1.2. Tćnicas de conmutaciń
e o
Conmutar El procesamiento que realiza un nodo que recibe informaciń de una l´
o ınea
por una determinada interfaz y la reenv´ por otra interfaz, con el objetivo de que
ıa
llegue a un destinatario final (direccionamiento).

4
un simple cable, generalmente coaxial, que une a todos los ordenadores.
5
En este caso, entendemos como m´quinas dedicadas aqu´llas que estń expresamente diseãdas a nivel
a e a n
hardware para ejercer una funciń determinada.
o

http://alqua.org/libredoc/RSC 3


Los criterios para conmutar son m´ltiples y los veremos m´s adelante pero en relaciń
u a o
a las tćnicas de conmutaciń sabemos que hay dos b´sicas.
e o a

1. Conmutaciń de circuitos. Se caracteriza por reservar un camino dedicado para una
o
determinada comunicaciń entre un terminal origen y un terminal destino. Siendo
o
camino un canal l´gico o capacidad determinada de la red, que puede pertenecer
o
tanto a una l´
ınea dedicada como a una compartida, y que en cada enlace va saltando
de nodo a nodo desde el origen hasta el destino.

Figura 1.4: La red telefńica no es m´s que una red Punto a Punto
o a

Ejemplo La l´ınea de tel´fono es un claro ejemplo de conmutaciń de circuitos. La
e o
l´
ınea no es un cable f´ısicamente reservado (aunque en algunos tramos s´ lo ı
sea) sino que se reparte la capacidad del canal. Para esto existen dos tćnicas,
e
FDM (multiplexaciń por divisiń de frecuencia) y TDM (multiplexaciń por
o o o
divisiń de tiempo).
o

Existen varias fases en este proceso

o a ´
a) Establecimiento de comunicaciń al nodo m´s cercano. Este nodo realiza una
conmutaciń de la transmisiń hacia el siguiente nodo m´s cercano, etc. Fi-
o o a
nalmente llegamos al nodo destino, que devuelve un asentimiento.
b) Transmisiń de la informaciń en modo Full-Duplex (simultńeamente y en
o o a
los dos sentidos).
c) Liberar recursos de camino para cerrar el circuito. Puede cerrarlo quien desee
de los dos terminales.

En este tipo de comunicaciń existe cierta ineficiencia ya que hay vac´ de in-
o ıos
formaciń en el circuito que no se aprovechan. Sin embargo, una vez establecido
o
el circuito (se pierde algo de tiempo para calcular el camino ´ptimo) los tiempos
o
de retardo son muy cortos. Como restricciń importante podemos decir que es
o
obligatorio que ambos terminales emitan a una misma velocidad.
Este tipo de transmisiń es bueno para unos servicios (voz) y malo para otros
o
(cuando es necesario el uso intensivo de las capacidades de la l´
ınea).

o

1.3 Jerarqu´ de protocolos y arquitectura de red
ıa

2. Conmutaciń de paquetes. Los mensajes se parten en unidades m´s pequeãs de-
o a n
nominadas paquetes. Ahora los enlaces f´
ısicos no se reparten de forma est´tica sino
a
de forma din´mica y se van asignando recursos segń se van necesitando. De esta
a u
forma, los nodos se convierten en unidades m´s complejas que gestionan colas y
a
segń vayan teniendo capacidad van enviando paquetes a diferentes nodos.
u
Las caracter´
ısticas fundamentales de este tipo de conmutaciń son
o

a) Eficiencia: si no hay transmisiń de una comunicaciń, no se reserva ningń
o o u
recurso y ´ste queda libre para otra comunicaciń.
e o
b) Los terminales finales no estń obligados a transmitir a idńticas velocida-
a e
des. Los nodos intermedios se encargan de adecuar velocidades (concepto de
buffer 6 ).
c) No existe una saturaciń propiamente dicha (aunque el recurso f´
o ısico pue-
de llegar a provocarla), sino un aumento del retardo en la transmisiń de
o
paquetes. A m´s demanda, mayor tiempo de retardo.
a
d ) No todos los paquetes son iguales (hay algunos de ellos que tienen m´s prio-
a
ridad que otros) y eso los nodos lo sabrń gestionar.
a

Debido al tipo de tr´fico de computadoras (a r´fagas: con tiempos muertos y
a a
tiempos de transmisiń) este sistema de conmutaciń es el m´s adecuado para
o o a
ellas ya que no es tan importante que el tiempo de retardo sea alto. Sin embargo,
las necesidades de la industria comienzan a mirar a las redes de conmutaciń o
de paquetes para servicios tradicionalmente asociados a conmutaciń de circuitos.
o
Esto implicar´ que haya que identificar estos servicios de alguna forma para que los
a
nodos entiendan que estos paquetes nuevos presentan una gran prioridad frente a
otros. Esta gestiń del ancho de banda es muy complicada pero se intenta priorizar
o
el tr´fico gracias a una correcta identificaciń de paquetes o agrupaciones por parte
a o
de grandes nodos pseudointeligentes (en el apartado de software ań se est´ muy
u a
verde y las protoimplementaciones se realizan actualmente mediante soluciones
hardware).

1.3. Jerarqu´ de protocolos y arquitectura de red
ıa
Evidentemente, es necesario que todos los terminales utilicen el mismo protocolo para
comunicarse. Como esta tarea parec´ inabarcable se ide´ una estructura de niveles, cada
ıa o
uno de los cuales est´ especializado en una funciń, confiando en que esta disecciń del
a o o
problema ayudase a implementar una arquitectura viable.
Cada una de las entidades pares (extremos asociados) que han intervenido en la comu-
nicaciń lo han he hecho mediante un protocolo (Váse la figura 1.5). Una capa inferior
o e

6
Si un terminal emite a menor velocidad que el otro, el nodo intermedio acumular´ datos para realizar
a
env´ mayores. Si se da el caso contrario, el nodo intermedio fragmentar´ lo recibido en otros pedazos
ıos a
y los enviar´ espaciados en el tiempo.
a



Entidades pares

"me gustan "I like cars"
los coches" Protocolo

Servicio

Traductor Traductor
ESP−GAL Protocolo GAL−ING
"Góstame os
coches"

Servicio

Secretaria FAX
Protocolo
FAX

Figura 1.5: Esquema de una estructura por niveles

de la transmisiń ofrece un servicio a la capa superior. Toda capa es usuaria de la abajo
o
y proveedora de la de arriba, siendo el n´mero de capas N. Como puede apreciarse, el
u
objetivo es dividir la complejidad.
Vamos a definir una arquitectura de red como el conjunto de protocolos y las capas
que nos permiten la comunicaciń entre m´quinas.
o a
Otras dos definiciones importantes son:

Protocolo es un formato de mensaje m´s una regla de intercambio de ese mensaje entre
a
entidades pares.
Servicio es la capacidad de comunicaciń que ofrece una capa inferior o proveedora a
o
una capa superior o usuaria.

Segń vamos subiendo en las capas, las funcionalidades se van volviendo m´s potentes y
u a
menos relacionadas con la comunicaciń en s´ (es decir, la abstracciń va aumentando).
o ı o
Por otro lado, en lo m´s bajo de la estructura a capas tenemos el medio f´
a ısico, que es
aquel medio sobre el que se realiza la comunicaciń.
o

El diseõ de mi torre de protocolos deber´ ser de tal forma que el cambio
n ıa
de unos de los protocolos no afecte a la comunicaciń. En la prćtica sucede
o a
pocas veces pero los protocolos diseãdos de esta manera disfrutan de una
n
mejor calidad de vida. Veremos m´s sobre esto en referencia al modelo OSI
a
y al modelo actual.

o

ıa

1.3.1. Terminolog´ de unidades de datos
ıa

IDU Unidad de datos
de Interfaz
Capa N+1 ICI SDU

SAP (service access point)
Interfaz
PDU
ICI SDU SDU
Capa N
cabecera de
protcolo

Capa N−1 ICI SDU SDU

Figura 1.6: Esquema de capas

La capa N ofrecer´ un servicio a la capa N + 1 a trav´s de una interfaz que contiene
a e
un SAP (Service Access Point). Los servicios de la capa N , por tanto, estń disponibles
a
a trav´s del SAP (que tiene asignada una direcciń) para la capa N + 1.
e o
Llamaremos unidad de datos de interfaz IDU a lo que la capa superior env´ al ıa
SAP para requerir el servicio de comunicaciń. Esta IDU est´ compuesta por la ICI
o a
(informaciń de control de interfaz, que lleva el control del env´ y la SDU (Unidad de
o ıo)
datos del servicio, lo que propiamente se desea enviar).
En la capa inferior tenemos la ICI y la SDU enviados. A la SDU le colocamos una cabe-
cera espec´ıfica de protocolo. A esa suma de SDU y cabecera de protocolo la designamos
con PDU (unidad de datos de protocolo).
Ejemplo En una red telefńica el SAP ser´ la roseta de la pared con direcciń el n´mero
o ıa o u
de tel´fono.
e
Las capas proveedoras pueden ofrecer dos tipos de servicios a las capas usuarias supe-
riores
1. Servicio orientado a conexiń (CO). Son aquellos servicios en los que hay un esta-
o
blecimiento previo de conexiń antes de la transmisiń de datos y desconexiń. Es
o o o
una idea similar al funcionamiento de la conmutaciń de circuitos pero orientada
o
a los servicios.
2. Servicio no orientado a conexiń (CL). Son aquellos servicios en donde no existe
o
una conexiń entre terminales.
o

Ejemplo El env´ de una carta por correo postal, que se deja en el buzń y uno se
ıo o
olvida de ella.



De hecho, lo primero que se introduce no tiene por qu´ ser lo primero que llega,
e
todo lo contrario que en CO.

Fiabalidad de un servicio Un servicio es fiable cuando ´ste garantiza la correcta entrega
e
de la informaciń. Esto se traduce en la necesidad de implementar lo siguiente:
o
el receptor notifica el haber recibido el mensaje (asentimiento). En general, los
servicios CO son fiables mientras que los CL no lo son.

Ejemplo Si estamos sirviendo p´ginas de un libro para que sean le´
a ıdas, deber´
ıan
dar un servicio CO para que las p´ginas lleguen por orden y el servicio sea
a
fiable dado que parece fundamental recibir el OK del receptor tras cada p´gina
a
le´
ıda.
Ejemplo Servir v´ıdeo digital bajo demanda. Ha de ser CO para poder asegurarse
la proyecciń secuencial pero no queremos que sea fiable ya que el tr´fico ge-
o a
nerado por asentimiento no es rentable al consumir una cantidad significativa
de ancho de canal y nadie desea ver, de pronto, fotogramas pasados que fueron
enviados incorrectamente en su momento.
Ejemplo Correo electrńico. Es un claro ejemplo de servicio CL. “Ya llegar´”. En
o a
principio no es fiable pero se puede implementar un acuse de recibo y pasar´ıa
a ser fiable.

1.3.2. Primitivas de servicio
Un servicio ¿c´mo se implementa formalmente? Con un conjunto de operaciones que
o
denominaremos primitivas de servicios. Estas primitivas son como llamadas al servicio
demandando funciones o acciones, o bien informes de acciones ya realizadas7 .
Existen cuatro tipos de primitivas de servicio (para un ejemplo gr´fico váse la figura
a e
1.7)
1º Request 2º Indication

N+1 N+1

N N

4º Confirm 3º Response

Figura 1.7: Esquema de un request-indication-response-confirm

1. Peticiones (request): Una entidad le pide al servicio que haga algo. “Deseo conec-
tarme”.
7
Estar´ bien realizar una analog´ entre estas primitivas y las primitivas de sistema, que encontramos en
ıa ıa
los sistemas operativos. ¿Comparten la atomicidad?

o

ıa

2. Indicaciones (indication): Se informa a una entidad que ha sucedido algo (gene-
ralmente, una peticiń). “Alguien desea conectarse”.
o

3. Respuestas (response): La respuesta de una entidad a un suceso. “Dile que le he
o´
ıdo”.

4. Confirmaciones (confirm): Informar a un entidad de que ha llegado una respuesta
de un peticiń suya anterior. “El de all´ me dice que ha recibido el mensaje”.
o ı

Un servicio fiable utilizar´ las cuatro primitivas mientras que los no fiables s´lo emplean
a o
los dos primeros.

Ejemplo Queremos un servicio orientado a conexiń que tendr´ las siguientes 8 primiti-
o a
vas divididas en la parte de conexiń CONNECT, la de transmisiń de informaciń
o o o
DATA y la de desconexiń DISCONNECT.
o

1. CONNECT.request
2. CONNECT.indication
3. CONNECT.response
4. CONNECT.confirm
5. DATA.request
6. DATA.indication
7. DISCONNECT.request
8. DISCONNECT.indication

El usuario de la computadora 1 env´ desde la capa N + 1 un request y la compu-
ıa
tadora 2 recibe un indication, devuelve un response y la computadora 1 recibe
un confirm.
Para entender el proceso entero, nos hemos valido de una supuesta conversaciń
o
entre dos personas mediante intermediarios (váse la figura 1.8)
e

1. Quiero saber si est´s ah´ [1]
a ı
2. Quieren saber si est´s ah´ [2]
a ı
3. Diles que estoy aqu´ [3]
ı
4. Me dicen que te diga que est´ ah´ [4]
a ı
5. Quiero que venga a cenar [5]
6. Me dicen que ´l desea que vayas a cenar [6]
e
7. Deseo desconectar [7]
8. Desea cortar la comunicaciń [8]
o



N+1 1 4 5 6 7
Computadora 1
N

2 3 6 5 8
N+1
Computadora 2
N

Figura 1.8: Esquema de las capas en el ejemplo de una conversaciń con intermediarios
o

1.4. Diseõ de capas para desarrollar una arquitectura de red
n
Los siguientes elementos son necesarios para la correcta especificaciń de una red
o

1. Direccionamiento: B´sicamente, nos proporciona direcciones de interfaces. Cuan-
a
to m´s subimos en el protocolo m´s subirń las funcionalidades y menos tendrń
a a a a
que ver con la comunicaciń f´
o ısica en s´
ı.

2. Transferencia de informaciń: Debemos fijar reglas de transferencia de infor-
o
maciń (en una direcciń -simplex-, ambas -half-duplex-, ambas simultńeamente
o o a
-full-duplex-). Generalmente, la transmisiń ser´ siempre full-duplex salvo en capas
o a
inferiores y casos puntuales en donde el medio f´ısico no aguante ese sistema.

3. Detecciń y correcciń de errores: Serń utiles c´digos redundantes para de-
o o a ´ o
tectar errores u obligar a una respuesta, para conseguir los llamados c´digos auto-
o
corregidos.

4. Numeraciń de paquetes: Es necesario para la reconstrucciń de la transmisiń
o o o
por el receptor de forma consistente.

5. Mecanismo de control de flujo: Sirven para adecuar las diferentes velocidades
de los interfaces de red. Veremos varios de estos mecanismos.

6. Mecanismos de control de congestiń: Sirven para evitar la saturaciń de los
o o
nodos intermedios.

7. Mecanismo de segmentaciń y concatenaciń: En ocasiones las diferentes
o o
capas de la arquitectura no soportan tamaõs iguales de PDU de forma que ser´
n a
necesario proveer a nuestra red con herramientas de divisiń de la PDU en varias
o
SDU y a la inversa para reconstruir esa segmentaciń en la entidad par. Ya m´s
o a
raro resulta encontrar la necesidad de concatenar PDUs pequeãs en una grande
n
pero es de gran utilidad para reducir la informaciń de control y aprovechar al
o
m´ximo los recursos del canal.
a

o

1.5 Modelo OSI

8. Multiplexaciń y Divisiń: Dividir los recursos que tiene un canal entre dife-
o o
rentes comunicaciones (Multiplexaciń) o separar diferentes comunicaciones para
o
que vayan en diferentes canales (Divisiń). La multiplexaciń normalmente exige
o o
un servicio CO tanto en la capa usuaria como en la capa proveedora. No confun-
dir Multiplexaciń con segmentaciń. Evidentemente, habr´ que poder identificar
o o a
correctamente las diferentes comunicaciones.

1.5. Modelo OSI
OSI quiere decir Open System Interconnection y fue definido por la ISO (International
Organization of Standards) en 19838 .
A finales de los aõs 60, y partiendo del entorno militar, se pens´ en crear redes
n o
de conmutaciń de paquetes tolerante a fallos capaces de viajar por medios diferentes.
o
Este planteamiento lleg´ al entorno universitario y se produjo un crecimiento r´pido de
o a
sistemas de este tipo por lo que fue necesario definir un estńdar para poder especificar
a
cualquier arquitectura de red.
La propuesta OSI fue la siguiente:
Para un terminal o host propusieron una estructura de 7 capas como puede apreciarse
en la figura 1.9.
Sistema final

Aplicación
Presentación

Sesión

Transporte
Red
Enlace

Física

Figura 1.9: Esquema de una estructura de 7 capas para el sistema final de OSI

mientras que para un nodo intermedio propuesieron una estructura de 3 capas orien-
tado al enturtamiento (figura 1.10) .
Adem´s, se adjuntaron una serie de recomendaciones o reglas a seguir9 :
a

1. Se debe crear una capa siempre que se necesite un nivel de abstracciń diferente.
o
8
S´ las mismas siglas para todo. Esperamos que el contexto ayude.
ı,
9
Es interesante comprobar c´mo los consejos aqu´ enumerados guardan estrecha relaciń con aquellos
o ı o
propuestos en el desarrollo orientado a objetos en la programaciń. Para m´s informaciń a este respecto
o a o
puede consultarse [1].



Sistema intermedio
Red

Enlace

Fisica

Figura 1.10: Esquema de una estructura de 3 capas para el sistema intermedio de OSI

2. Cada capa ha de realizar una funciń bien definida.
o
3. Las capas han de implementarse de tal manera que el flujo de informaciń a trav´s
o e
de los interfaces de capa sea el m´
ınimo posible.
4. Las capas deben ser suficientes en n´mero para que no exista la posibilidad de
u
agrupar demasiadas funcionalidades en una capa individual pero asimismo no de-
ben ser tantas que la complejidad de la arquitectura de red se dispare. Tan malo
es sobrecargar una sola capa con funciones como pasar a tener muchas capas que
nos dificulte la implementaciń.
o

Sistema final Sistema final

Aplicación Aplicación
Presentación Presentación

Sesión Sesión

Transporte Sistema intermedio Transporte
Red Red Red
Enlace Enlace Enlace

Física Fisica Física

Figura 1.11: Esquema de comunicaciń entre terminales de OSI
o

1.5.1. Funciones de las capas
Veremos aqu´ con m´s detalle cada una de las capas del diseõ propuesto por OSI.
ı a n
Nivel f´
ısico: El medio f´ısico ser´ el encargado de transmitir los bits (la PDU ser´
a a
en este caso el bit). El diseõ ha de ser fiable de forma que si se mete un 1, al otro
n
lado haya un 1 y no exista una degradaciń excesiva. Los par´metros que entran
o a
en juego en este nivel son:

o

1.5 Modelo OSI

• Voltaje que se asocia al valor l´gico 1, y el voltaje asociado al valor l´gico 0
o o
(Váse la figura 1.12). Si el medio f´
e ısico no es lo suficientemente fiable para
poder distinguir los dos voltajes, no sabremos reconstruir correctamente la
informaciń.
o
• Periodo que dura el valor l´gico. A menor periodo mayor aprovechamiento del
o
canal (aunque no conviene forzar los l´
ımites de nuestros sistemas de mediciń
o
al otro extremo).
• Tiempo de establecimiento de conexiń, entendiendo conexiń al nivel m´s
o o a
elemental.
• N´mero de pines que tienen los cables.
u

V

1

0
tiempo

Figura 1.12: Esquema de los valores l´gicos y sus voltajes correspondientes
o

Nivel de enlace: Se monta directamente encima del nivel f´ ısico y transforma los 1
y 0 que le llegan en una secuencia de bits libre de errores para enviarlo al nivel de
red.

• Una funciń principal es detectar el inicio y fin de una PDU de ese nivel. A
o
estas PDUs las llamaremos Tramas. Ese trabajo sobre las tramas consiste
b´sicamente en sincronizar.
a
• Realiza una importante detecciń de errores a nivel de trama y tendr´ meca-
o a
nismos de retransmisiń10 .
o
• Adecua velocidades entre equipos.
• En el caso de medios compartidos es el que gestiona quiń puede acceder al
e
medio en cada momento.

Nivel de red: Es la primera capa que ofrece un servicio extremo a extremo pero no
es un protocolo extremo a extremo (ya que no conecta directamente dos entidades
pares). Permite enviar informaciń de una m´quina origen a otra destino. Sus
o a
funciones principales son:

10
a este nivel ań no podemos implementar mecanismos de autocorrecciń.
u o



• Su funciń principal es encaminar la informaciń. A las PDU del nivel de red
o o
las llamaremos paquetes.
• Se encarga del control de congestiń de paquetes.
o
• Se encarga del control de ordenaciń de paquetes.
o

Nivel de transporte: es el primer protocolo extremo a extremo. Para este proto-
colo, al contrario de los que ven´
ıamos viendo, las entidades pares estń en los dos
a
terminales de la conexiń.
o

• Realiza la tarea de multiplexaciń de forma transparente a la capa de sesiń.
o o
• Deber´ ofrecer diferentes tipos de servicio a las capas superiores en base a
ıa
poder dar calidad de servicio QoS. No ser´ lo mismo una videoconferencia
a
que enviar un correo electrńico y esta capa deber´ estar preparada para
o a
acomodarse a estos cambios.

Nivel de sesiń: es el encargado de la gestiń del di´logo y la sincronizaciń de las
o o a o
transferencias.
Nivel de presentaciń: soluciona los problemas inherentes a la distinta forma de
o
presentar la informaciń en los terminales origen y destino. Para ello define un
o
lenguaje de definiciń de interfaces abstractas, ASN-1, y unas reglas de codificaciń
o o
no ambigua (reglas de encodificaciń) de valores definidos por ASN-1, a esto se le
o
conoce como BER (base encoding rules). Hoy en d´ las aplicaciones se encargan
ıa
de esta capa.
Nivel de aplicaciń: Cualquier aplicaciń que requiera comunicarse de forma remo-
o o
ta. Software, en definitiva.

1.5.2. Defectos de OSI
Es un muy buen modelo didćtico y ayuda a clarificar los conceptos pero su viablidad
a
prćtica es cuestionable debido principalmente a estos factores:
a

1. Complejidad a la hora de implementar/especificar los protocolos. El control de
flujo y sincronizaciń es dif´ de concretar.
o ıcil
2. Planificaciń: tiene una mala planificaciń.
o o
3. Mala tecnolog´ Las capas no estń bien dimensionadas. Las capas de sesiń y
ıa. a o
presentaciń estń casi vac´
o a ıas.
4. Se olvida totalmente de los servicios no orientados a conexiń CL (debido, segura-
o
mente, al aõ en el que se cre´).
n o
5. Mala pol´ıtica debido a que la OSI fue visto siempre como imposiciń (al contra-
o
rio que TCP/IP que ven´ de un entorno universitario y que estudiaremos en la
ıa
siguiente secciń).
o

o

1.6 Introducciń a TCP/IP
o

1.6. Introducciń a TCP/IP
o
A diferencia de OSI, no hab´ un plan de trabajo definido y se va desarrollando a partir
ıa
de parches. A pesar de tener limitaciones, es estable, econńimo y fćil de implementar.
o a
Se trata de una arquitectura de red denominada best-effort (proporciona un servicio
segń puede, no podemos exigirle nada).
u
Son principales caracter´
ısticas pueden resumirse en:

Se fusionan varias capas de OSI.
TCP es el principal protocolo de la capa de transporte y se utiliza cuando se desea
realizar un servicio fiable. UDP es otro protocolo utilizado para conexiones no
fiables ya que no espera respuesta a los datagramas enviados (ser´ util en entornos
a´
con tasa de error m´ınima).
En el nivel de red el principal protocolo es el IP (se encarga de llevar los datos).
Otro es el ICMP (protocolo de mensajes de control sin datos e informaciń).o

1.6.1. Defectos de TCP
No oculta bien los protocolos, no son independientes del servicio. Un ejemplo claro
de este fallo es el problema que est´ resultando sustituir IPv4 por IPv6.
a
Carece de capacidad para acondicionar las exigencias actuales de los servicios a la
propia red.

1.7. Elementos o dispositivos de interconexiń
o
1. A nivel f´
ısico, tendremos los repetidores o Hubs.
2. A nivel de enlace, tendremos los Bridge/Switch.
3. A nivel de red, tendremos los Routers.
4. A nivel de aplicaciń, Gateways y Proxies.
o

Antes de seguir es importante detenernos en un concepto muy importante.

Dominio de colisiń la regiń de la red que comparte un medio de difusiń.
o o o

Ha de quedar claro que un medio f´ ısico no afecta para nada al dominio de colisiń.
o
Sin embargo, un dispositivo a nivel de enlace (Switch o Bridge) es capaz de lidiar con
las colisiones de forma que s´ segmenta el dominio de colisiń.
ı o

Dominio de emisiń La regiń de una red delimitada por dispositivos de interconexiń
o o o
de nivel de red (routers). Est´ muy relacionado con la idea de broadcast (de hecho
a
a veces se les llama dominio de broadcast). Váse la figura 1.15. Son los routers los
e
que segmentan los dominios de emisiń.
o



Figura 1.13: El bus de una red de difusiń es un dominio de colisiń
o o

router

Figura 1.14: El router no afecta en absoluto al dominio de colisiń porque no es un dispositivo a
o
nivel f´
ısico

UAX bridge

nodo de computación
o sistema intermedio

UCM

Figura 1.15: El bridge no afecta al dominio de emisiń.
o

o

2 Nivel de enlace
Las funciones principales del nivel de enlace ya las vimos en el tema anterior, aqu´ ı
trataremos los mecanismos de acceso al medio de que dispone antes de hablar sobre
diferentes estńdares utilizados.
a
Dentro del nivel de enlace disponemos de varios subniveles. El subnivel MAC es el que
se encarga de todas las funciones que tengan que ver con el medio f´ısico y tiene bastante
sentido en las redes de difusiń. El llamado LLC tiene como misiń ofrecer una visiń
o o o
unificada del nivel de enlace a la capa superior, en este caso de red. La capa l´gica LLC
o
independiza la forma de gestionar el acceso (CSMA/CD, Tokeng Ring, Token Bus) de
la capa de red. Váse la figura 2.1.
e

LLC
LLC
CSMA
enlace MAC Token ring
Token bus
fisica fisica
fisica

Figura 2.1: Esquema del nivel de enlace

Para poder centrar nuestro estudio del nivel de enlace es importante seãlar que el
n
estńdar IEEE 802 (tambiń conocido como ISO 8802) cubre los aspectos que han de
a e
cumplir tanto el nivel de red como el de enlace.
Dentro de IEEE 802 hay diferentes subestńdares:
a

802.1 se encarga de definir las primitivas de los enlaces.

802.2 describe la capa l´gica LLC
o

802.3 describe el estńdar utilizado en redes Ethernet.
a

802.5 describe el estńdar utilizado en redes Token Ring.
a

802.11b describe el estńdar utilizado en redes WLAN (tan de moda ultimamente
a ´
con las redes wireless).

17

2 Nivel de enlace

Una vez visto por encima el asunto de los estńdares nos hacemos la siguiente pregunta
a
¿C´mo podemos clasificar los mecanismos de control de acceso al medio? Est´ claro
o a
que en un medio compartido ser´ necesario un sistema ordenado de forma que no todas
a
las m´quinas salgan a enviar datos cuando les apetezca. Veremos, a continuaciń, varias
a o
formas de encontrar un compromiso entre las m´quinas de una red para que todas puedan
a
enviar y recibir de forma aceptable.

2.1. Mecanismos de acceso al medio
Existen dos tipos mecanimos a estudiar; los est´ticos y los din´micos, divididos a su
a a
vez en varios subtipos.

2.1.1. Est´ticos (TDM,FDM)
a
Tenemos un medio f´ ısico que hay que compartir. Una forma de hacerlo es repartir
ese medio f´
ısico y hacerlo de forma est´tica. Por ejemplo, podr´ ser una divisiń en tiem-
a ıa o
pos siempre igual o una divisiń en frecuencias acotadas
o 1 . Si las necesidades de la red son

cambiantes en el tiempo, esta forma de controlar el acceso al medio no es conveniente2 .
No hablaremos de ellos m´s ya que no se utilizan en las redes de computadores.
a

2.1.2. Din´micos
a
Los estudiaremos a fondo ya que son los que se utilizan en la prćtica (aunque nos
a
detendremos en la evoluciń que han sufrido en estos aõs).
o n

1. Mecanimos de contienda:

a) ALOHA: surgi´ en los aõs 70 en la Universidad de Hawaii ya que deseaban
o n
resolver el acceso al medio en un entorno de radiofrecuencia. Quer´ acceder
ıan
de forma no coordinada al medio (es decir, sin establecer reservas de canal).
Dentro de ALOHA encontramos dos tipos:
1) ALOHA puro:
Cada entidad accede al medio cuando desea.
Las entidades s´lo escuchan tras transmitir.
o
Es necesario terminar una trasmisiń antes de empezar la siguiente.
o
El terminal que ha enviado la trama puede saber si ha habido des-
trucciń por colisiń (ej: dos terminales enviaron tramas al mismo
o o
tiempo y ambas se destruyeron al ser imposible intentar autoexcluir-
se mutuamente).

1
Por ejemplo, la m´quina A s´lo env´ en los minutos pares, mientras que la m´quina B lo hace en los
a o ıa a
minutos impares.
2
Se podr´ hablar de una similitud conceptual con los mecanimos FCFS en los algoritmos de planificaciń
ıa o
de procesos. Váse [2].
e

o

2.1 Mecanismos de acceso al medio

Si la trama es destruida, espera un tiempo aleatorio (para evitar nue-
vas colisiones) y vuelve a transmitir.
Modelado estad´ ıstico del medio: Supondremos infinitos usuarios y tra-
mas de tamaõ fijo. Llamaremos per´
n ıodo t de una trama al tiempo
necesario para transmitir esa trama. Asumiremos que se generan nue-
vas tramas segń una distribuciń de Poisson3 de media S (tramas
u o
por per´ ıodo de trama). Vamos a considerar que 0 < S < 1. Tambiń e
hay que tener en cuenta las retransmisiones de tramas; en k inten-
tos de transmisiń (tramas enviadas y tramas reenviadas) tambiń
o e
se sigue una distribuciń de Poisson de media G. Evidentemente se
o
cumple siempre que G ≥ S. Si la carga es baja (apenas se usa el
medio) habr´ pocas colisiones y S 0 a la vez que G S. En el caso
a
de que el tr´fico sea alto, S ↑=⇒ G → S. El no de tramas enviadas
a
con ´xito ser´ S =G · P0 siendo P0 la probabilidad de que una tra-
e a
ma consiga transmitir con ´xito. Segń la distribuciń de Poisson, la
e u o
probabilidad de que se generen k tramas por cada tiempo de trama
ser´
a
Gk · e−G
Pr [k] =
k!
Por tanto, la posibilidad de que no se genere ninguna trama en un
tiempo t ser´ Pr [0] = e−G . Si G es muy grande (mucho tr´fico) esta
a a
probabilidad tiende a cero, evidentemente. Llamamos tiempo vul-
nerable al tiempo de transmisiń sujeto a colisiones. Como muestra
o
la figura 2.2 , no es t sino 2t.
¤

¤

¤

¥

¢
£ ¤

¥

¨ ¨ ¨ ¨ ¨ ¨ ¨

© © © © © © ©

¢
£

¥

¨ ¨ ¨ ¨ ¨ ¨ ¨

© © © © © © ©

¢

£

¥

¨ ¨ ¨ ¨ ¨ ¨ ¨
© © © © © © ©

¢

£

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦

§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §
© © © © © © ©

¢

£

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §

© © © © © © ©

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §

© © © © © © ©

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
¡ ¡ ¡ ¡
§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §

© © © © © © ©

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦

§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §
© © © © © © ©

¡ ¦ ¡ ¦ ¡ ¦ ¡ ¦ ¦ ¦ ¦ ¦ ¦ ¦

§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §
© © © © © © ©

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §

© © © © © © ©

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦
§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §

© © © © © © ©

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦

§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §

© © © © © © ©

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦

§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §
© © © © © © ©

¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦

§ § § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ § ¨ §
© © © © © © ©

COLISIÓN

t0 t0+t t0+2t t0+3t

Figura 2.2: Esquema de tramas utilizando t tiempo de transmisiń. Es necesario un margen mayor
o
de tiempo para evitar la colisiń.
o

Si asumimos que los sucesos son independientes, la probabilidad de no
colisionar en ese periodo vulnerable 2t ser´ el producto de probabilidades
a
de no generaciń de m´s tramas en cada uno de los per´
o a ıodos t individuales.

P0 = Pr [0] · Pr [0] = e−2t
3
dados sucesos independientes que ocurren en un determinado tiempo, si el tiempo es lo suficientemente
grande, la forma de la distribuciń tiende a una forma concreta que llamamos en t´rminos estad´
o e ısticos
como distribuciń de Poisson.
o


2 Nivel de enlace

luego el no de tramas que llega satisfactoriamente seguir´ la siguiente
a
distribuciń de probabilidad
o

S = G − e−2G

Ve´se la figura 2.3 en donde puede apreciarse que el porcentaje de ´xito
a e
es el 18 %.

0.5

0.2
0.18

0.1

0.5 1 2

Figura 2.3: Efectividad del control ALOHA puro

2) ALOHA ranurado:
Existen unos periodos de transmisiń definidos por una de las enti-
o
dades. Es, de alguna forma, una comparticiń.
o
Los per´
ıodos de transmisiń son intervalos discretos de tamaõ
o n
trama
t=
tasa de bits de la red
El per´
ıodo vulnerable pasa a ser t ya que hemos fijado el tiempo de
transmisiń.
o
La retransmisiń se produce tras un n´mero entero aleatorio de
o u
cuantos de tiempo de trama. Váse la figura 2.4 para un esquema
e
de su evoluciń en el tiempo.
o
b) ETHERNET: Toman el nombre gen´rico de mecanismos de acceso m´ltiple
e u
con detecciń de portadora (CSMA)
o
Extiende el concepto de ALOHA mediante la detecciń del uso del canal
o
antes de transmitir (detecciń de portadora). El ETHERNET actual utiliza
o
el control de acceso al medio denominado CSMA/CD 1 persistente.
1) CSMA 1 persistente4 : Cuando una estaciń tiene intenciń de transmitir,
o o
mirar´ si ya est´ ocupado el canal. Se llama 1 persistente porque la es-
a a
taciń transmite con probabilidad 1 cuando encuentra el canal vac´ 5 .
o ıo
4
Las empresas que definieron este estńdar fueron Xerox e Intel.
a
5
Transmitir con probabilidad 1 no quiere decir que no exista una colisiń m´s tarde.
o a

o


0.5
37%

0.2

0.1

0.5 1 2

Figura 2.4: Efectividad del control ALOHA ranurado

Si hay colisiń se comporta como ALOHA (espera de tiempo aleatorio y
o
vuelta a empezar). El problema que presenta esto es fundamentalmente
el siguiente: Si varias estaciones estń esperando a que quede libre el me-
a
dio, cuando una estaciń deje de enviar tramas, el resto provocar´ una
o a
colisiń inicial prćticamente inevitable porque al ser 1 persistente todas
o a
se lanzan inmediatamente a transmitir.
2) CSMA no persistente: La entidad que desee transmitir escucha y si el
canal est´ ocupado espera un tiempo aleatorio antes de volver a escuchar.
a
3) CSMA p-persistente: Si el canal est´ ocupado la entidad se mantiene a
a
la escucha, y si est´ libre transmite con una probabilidad p. Tendr´ una
a a
probabilidad q = 1 − p de no transmitir. Se utiliza con ranuraciń de o
tiempo. Si en un intento de transmisiń el canal est´ ocupado, esperar´
o a a
un tiempo aleatorio antes de volver a transmitir con p probabilidad. De
esta forma, mezcla persistencia con probabilidad con no persistencia para
volver a escuchar. Tras un n´mero de veces adecuado (G) aumenta la
u
probabilidad de lograr transmitir. Váse la figura2.5 en donde se hace
e
una comparativa de los diferentes m´todos.
e
4) CSMA/CD 1 persistente: Es el m´todo que utiliza actualmente ETHER-
e
NET. La parte CD (Collision detection) es una detecciń temprana de la
o
colisiń (s´lo env´ la trama entera si el comienzo de ella no ha colisiona-
o o ıa
do ya que al enviar los pulsos elćtricos correspondientes a los primeros
e
bits uno puede saber si ha colisionado mediante un control anal´gico). Se
o
puede esquematizar como: Mientras transmito, escucho. Las ventajas son
aumento del ancho de banda disponible y ahorro de tiempo de transmi-
siń. Calcularemos el tiempo que una entidad necesita para estar segura
o
de que no ha habido una colisiń. Si τ es el tiempo que tarda en llegar
o
una trama de una entidad a la otra, y ha transcurrido to + τ − cuando
la estaciń destino decide transmitir creyendo que el canal est´ libre, la
o a
trama de vuelta (o la seãl de colisiń) deber´ volver, tardando un tiempo
n o a


2 Nivel de enlace

S
1.0
0.9 CSMA 0.01 P

No P

CSMA 0.1 P
0.37

ALOHA Ranurado
CSMA 1 P
ALOHA Puro

G

Figura 2.5: Comparativa de los diferentes m´todos
e

total m´ximo de 2τ .
a

2. Mecanismos de reserva: Son mecanismos libres de colisiones. Antes de una trans-
misiń habr´ una ventana temporal “periodo de reserva” donde todas aquellas
o a
computadoras que deseen transmitir lo comunicarń. Veamos un ejemplo caracte-
a
r´
ıstico:

Mapa de bits Tenemos una LAN de N = 8 m´quinas. La ventana de reserva se
a
divide en 8 partes. Esta particiń del tiempo s´ es est´tica. Las m´quinas van
o ı a a
colocando un 1 en su ranura para indicar si quieren transmitir durante lo
que se conoce como periodo de reserva. Cumplido ese plazo, la primero que
transmite es la primera que dijo “1” segń la secuencia de bits de la ventana
u
de reserva. El tamaõ de trama para el env´ no es fijo aunque existen unos
n ıo
m´ximos. Váse figura 2.6. Una vez que todas las que quer´ transmitir lo
a e ıan
hicieron, la ventana de reserva vuelve a estar disponible. Existe un problema
con este procedimiento y es que es muy probable que una estaciń desee o
transmitir cuando se le haya pasado el periodo de reserva. Estad´ ısticamente,
las estaciones etiquetadas con n´meros bajos tardan 1.5 veces m´s que los
u a
n´meros altos. Otro protocolo de este tipo es el Conteo Binario Descendente
u
(ver [Tanembaum]).

3. Mecanismos de selecciń: Se basan en que para transmitir han de estar en posesiń
o o
de una determinada trama llamada testigo. Veremos unicamente el protocolo Token
´
Ring. Se refiere al estńdar IEEE 802.5. El inventor, IBM, buscaba un protocolo
a
de acceso al medio en donde las esperas m´ximas de acceso al medio estuviesen
a

o


0 1 2 3 4 5 6 7

1 1 1

Figura 2.6: Ejemplo de Mecanismo de reserva; mapa de bits. Las m´quinas 1,4 y 5 han mostrado su
a
deseo de transmitir.

acotadas y, sobre todo, por su capacidad para crear un anillo utilizando conexiń
o
Punto a Punto en cada par de m´quinas consecutivas. Tendremos una trama testigo
a
que viajar´ por toda la red en una sola direcciń (siempre se transmite en un
a o
sentido, váse la figura 2.7) y quedar´ atrapada por aquella m´quina que desee
e a a
transmitir. La trama testigo habilita a la m´quina a transmitir durante un tiempo
a
m´ximo de vencimiento de trama. Con este tipo de topolog´ ganamos dos cosas.
a ıa

Tiempo m´ximo de espera acotado.
a
Asentimientos muy sencillos.

Figura 2.7: En TokenRing, la transmisiń se realiza siempre en un mismo sentido
o

Las estaciones actán de repetidores ya que aunque lean una trama que no
u
desean la reenv´ Para evitar que haya tramas viajando indefinidamente por
ıan.
el canal, la estaciń origen se encarga de comprobar que todo ha ido perfecta-
o
mente cuando una trama que envi´ vuelve a ella. La trama testigo se vuelve
o
a generar en la estaciń que emiti´ por ultima vez cuando la transmisiń ha
o o ´ o
sido completada o cuando el tiempo de vencimiento queda agotado. Tambiń e
existen problemas:
• si se cae una estaciń, se rompe el anillo.
o
• una nueva m´quina a insertar necesita conocer a sus vecinos (configura-
a
ciń).
o
• ¿si el testigo se pierde quiń la regenera? Por ejemplo, la m´quina que lo
e a
ten´ se cae. Token Ring,a pesar de su estructura de anillo, es una topo-
ıa
log´ de selecciń centralizada as´ que una nueva m´quina, del anillo,
ıa o ı a
se encarga de ello.


Introduccion comunicaciones

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (15)

Similar a Introduccion comunicaciones

Similar a Introduccion comunicaciones (20)

Más de hgm2007

Más de hgm2007 (20)

Último

Último (20)

Introduccion comunicaciones