Apuntes Parcial 1 Redes-De-Computadora

Redes de computadoRas
ANDREW S. TANENBAUM DAVID J. WETHERALL

T anenbaum
W eTherall Redes de computadoRas QuINta edIcIÓN
Una introducción clásica y a la vez contemporánea al campo de las redes t aNeNbaum W etheRall
Redes de computadoras, 5ª edición, es la introducción ideal al campo de las redes. Este
Redes de computadoRas
bestseller refleja las tecnologías más recientes sobre este tema con un énfasis especial
en las redes inalámbricas, incluyendo 802.11, 802.16, Bluetooth™ y 3G celular, a la par
con una cobertura de redes fijas como ADSL, Internet por cable, Gigabit Ethernet, MPLS y
las redes de igual a igual. En particular, esta última edición incorpora una nueva cobertura
sobre las redes 3G de telefonía móvil, fibra para el hogar, RFID, redes tolerantes al retardo
y seguridad en 802.11, además de material adicional sobre enrutamiento en Internet, mul-
tidifusión (multicast), control de congestión, calidad del servicio, transporte en tiempo real
y distribución de contenido.
Los autores Andrew Tanenbaum y David Wetherall describen los aspectos internos de la red y exploran su funcionalidad,
desde el hardware hasta las aplicaciones implicadas, donde sobresalen los siguientes temas:
• La capa física (cobre, fibra óptica, inalámbricos, satélites, OFDM y CDMA).

• La capa de enlace de datos (detección y corrección de errores, ventana corrediza y paquetes sobre SONET).
• La subcapa MAC (Gigabit Ethernet, 802.16, RFID, Ethernet conmutada, redes VLAN).
• La capa de red (algoritmos de enrutamiento, multidifusión, QoS, IPv4, IPv6 y MPLS).
• La capa de transporte (sockets, UDP, TCP, RTP, control de congestión y redes tolerantes al retardo).
• La capa de aplicación (DNS, correo electrónico, Web, medios de flujo continuo, distribución de contenido y redes
de igual a igual).
• Seguridad en redes (AES, RSA, IPsec, firewalls, redes VPN, 802.11i y seguridad en Web).
Este libro analiza y describe con detalle los principios asociados con cada capa y después los traduce a través
de ejemplos de Internet y las redes inalámbricas.
Para mayor información, consulte la página Web de este libro en:
www.pearsoneducacion.net/tanenbaum
QuInTa
ISBN: 978-607-32-0817-8 eDICIÓn
Visitenos en:
www.pearsoneducacion.net
www.FreeLibros.me
www.FreeLibros.me
Redes
de computadoras
Quinta edición
www.FreeLibros.me
www.FreeLibros.me
Redes
de computadoras
Quinta edición
Andrew S. Tanenbaum
Vrije Universiteit
Amsterdam
David J. Wetherall
University of Washington
Seatle, Washington
traducción
Alfonso Vidal Romero Elizondo

Ingeniero en Sistemas Electrónicos
Instituto Tecnológico y de Estudios
Superiores de Monterrey-Campus Monterrey
revisión técnica
M. en C. Cyntia E. Enríquez Ortiz

Escuela Superior de Cómputo
Instituto Politécnico Nacional
www.FreeLibros.me
Datos de catalogación bibliográfica
ANDREW S. TANENBAUM y DAVID J. WETHERALL
Redes de computadoras
Quinta edición
PEARSON EDUCACIÓN, México, 2012

ISBN: 978-607-32-0817-8
Área: Computación
Formato: 20 3 25.5 cm Páginas: 816
Authorized translation from the English language edition, entitled Computer networks, 5th edition, by Andrew S. Tanenbaum & David J. Wetherall,
published by Pearson Education, Inc., publishing as Prentice Hall, Copyright © 2011. All rights reserved.
ISBN 9780132126953
Traducción autorizada de la edición en idioma inglés, titulada Computer networks, 5a. edición por Andrew S. Tanenbaum y David J. Wetherall,
publicada por Pearson Education, Inc., publicada como Prentice Hall, Copyright © 2011. Todos los derechos reservados.
Esta edición en español es la única autorizada.
Edición en español
Editor: Luis M. Cruz Castillo
e-mail: luis.cruz@pearson.com
Editor de desarrollo: Bernardino Gutiérrez Hernández
Supervisor de producción: Juan José García Guzmán
QUINTA EDICIÓN, 2012
D.R. © 2012 por Pearson Educación de México, S.A. de C.V.

Atlacomulco 500-5o. piso
Col. Industrial Atoto
53519, Naucalpan de Juárez, Estado de México
Cámara Nacional de la Industria Editorial Mexicana. Reg. núm. 1031.
Reservados todos los derechos. Ni la totalidad ni parte de esta publicación pueden reproducirse, registrarse o transmitirse, por un sistema de
recuperación de información, en ninguna forma ni por ningún medio, sea electrónico, mecánico, fotoquímico, magnético o electroóptico, por
fotocopia, grabación o cualquier otro, sin permiso previo por escrito del editor.
El préstamo, alquiler o cualquier otra forma de cesión de uso de este ejemplar requerirá también la autorización del editor o de sus representantes.
ISBN VERSIÓN IMPRESA: 978-607-32-0817-8

ISBN VERSIÓN E-BOOK: 978-607-32-0818-5
ISBN E-CHAPTER: 978-607-32-0819-2
Impreso en México. Printed in Mexico.

1 2 3 4 5 6 7 8 9 0 - 14 13 12 11
www.pearsoneducacion.net
www.FreeLibros.me
Para Suzanne, Barbara, Daniel, Aron, Marvin, Matilde
y a la memoria de Bram y Sweetie
(AST)
Para Katrim, Lucy y Pepper

(DJW)
www.FreeLibros.me
www.FreeLibros.me
CONTENIDO
PREFACIO xix
1 INTRODUCCIÓN 1
1.1 USOS DE LAS REDES DE COMPUTADORAS 2
1.1.1 Aplicaciones de negocios 3
1.1.2 Aplicaciones domésticas 5
1.1.3 Usuarios móviles 9
1.1.4 Cuestiones sociales 12
1.2 HARDWARE DE RED 15
1.2.1 Redes de área personal 15
1.2.2 Redes de área local 17
1.2.3 Redes de área metropolitana 20
1.2.4 Redes de área amplia 20
1.2.5 Interredes 23
1.3 SOFTWARE DE RED 25
1.3.1 Jerarquías de protocolos 25
1.3.2 Aspectos de diseño para las capas 29
1.3.3 Comparación entre servicio orientado a conexión y servicio sin conexión 30
1.3.4 Primitivas de servicios 32
1.3.5 La relación entre servicios y protocolos 34
1.4 MODELOS DE REFERENCIA 35
1.4.1 El modelo de referencia OSI 35
1.4.2 El modelo de referencia TCP/IP 39
1.4.3 El modelo utilizado en este libro 41
vii
www.FreeLibros.me
viii Contenido
*1.4.4 Comparación de los modelos de referencia OSI y TCP/IP 42

*1.4.5 Una crítica al modelo y los protocolos OSI 43
*1.4.6 Una crítica al modelo de referencia TCP/IP 45
1.5 REDES DE EJEMPLO 46
1.5.1 Internet 46
*1.5.2 Redes de teléfonos móviles de tercera generación 55
*1.5.3 Redes LAN inalámbricas: 802.11 59
*1.5.3 Redes RFID y de sensores 63
*1.6 ESTANDARIZACIÓN DE REDES 65
1.6.1 Quién es quién en el mundo de las telecomunicaciones 66
1.6.2 Quién es quién en el mundo de los estándares internacionales 67
1.6.3 Quién es quién en el mundo de estándares de Internet 68
1.7 UNIDADES MÉTRICAS 70
1.8 ESQUEMA DEL RESTO DEL LIBRO 71
1.9 RESUMEN 72
2 LA CAPA FÍSICA 77
2.1 BASES TEÓRICAS PARA LA COMUNICACIÓN DE DATOS 77
2.1.1 Análisis de Fourier 78
2.1.2 Señales de ancho de banda limitado 78
2.1.3 La tasa de datos máxima de un canal 81
2.2 MEDIOS DE TRANSMISIÓN GUIADOS 82
2.2.1 Medios magnéticos 82
2.2.2 Par trenzado 83
2.2.3 Cable coaxial 84
2.2.4 Líneas eléctricas 85
2.2.5 Fibra óptica 86
2.3 TRANSMISIÓN INALÁMBRICA 91
2.3.1 El espectro electromagnético 91
2.3.2 Radiotransmisión 94
2.3.3 Transmisión por microondas 95
2.3.4 Transmisión infrarroja 98
2.3.5 Transmisión por ondas de luz 99
*2.4 SATÉLITES DE COMUNICACIÓN 100
2.4.1 Satélites geoestacionarios 101
2.4.2 Satélites de Órbita Terrestre Media (MEO) 104
2.4.3 Satélites de Órbita Terrestre Baja (LEO) 105
2.4.4 Comparación de los satélites y la fibra óptica 107
2.5 MODULACIÓN DIGITAL Y MULTIPLEXIÓN 108
2.5.1 Transmisión en banda base 108
2.5.2 Transmisión pasa-banda 112
www.FreeLibros.me
REDES DE COMPUTADORAS ix
2.5.3 Multiplexión por división de frecuencia 114

2.5.4 Multiplexión por división de tiempo 116
2.5.5 Multiplexión por división de código 117
2.6 LA RED TELEFÓNICA PÚBLICA CONMUTADA 120
2.6.1 Estructura del sistema telefónico 120
2.6.2 La política de los teléfonos 123
2.6.3 El lazo local: módems, ADSL y fibra óptica 124
2.6.4 Troncales y multiplexión 131
2.6.5 Conmutación 138
*2.7 El SISTEMA DE TELEFONÍA MÓVIL 142
2.7.1 Teléfonos móviles de primera generación (1G): voz analógica 143
2.7.2 Teléfonos móviles de segunda generación (2G): voz digital 146
2.7.3 Teléfonos móviles de tercera generación (3G): voz y datos digitales 150
*2.8 TELEVISIÓN POR CABLE 154
2.8.1 Televisión por antena comunal 154
2.8.2 Internet por cable 155
2.8.3 Asignación de espectro 156
2.8.4 Módems de cable 157
2.8.5 Comparación de ADSL y cable 159
2.9 RESUMEN 160
3 LA CAPA DE ENLACE DE DATOS 167

3.1 CUESTIONES DE DISEÑO DE LA CAPA DE ENLACE DE DATOS 168
3.1.1 Servicios proporcionados a la capa de red 168
3.1.2 Entramado 170
3.1.3 Control de errores 173
3.1.4 Control de flujo 174
3.2 DETECCIÓN Y CORRECCIÓN DE ERRORES 175
3.2.1 Códigos de corrección de errores 176
3.2.2 Códigos de detección de errores 181
3.3 PROTOCOLOS ELEMENTALES DE ENLACE DE DATOS 186
3.3.1 Un protocolo simplex utópico 190
3.3.2 Protocolo simplex de parada y espera para un canal libre de errores 191
3.3.3 Protocolo simplex de parada y espera para un canal ruidoso 193
3.4 PROTOCOLOS DE VENTANA DESLIZANTE 196
3.4.1 Un protocolo de ventana deslizante de un bit 198
3.4.2 Un protocolo que utiliza retroceso N 200
3.4.3 Un protocolo que usa repetición selectiva 206
3.5 EJEMPLOS DE PROTOCOLOS DE ENLACE DE DATOS 211
3.5.1 Paquetes sobre SONET 211
3.5.2 ADSL 214
3.6 RESUMEN 216
www.FreeLibros.me
x Contenido
4 LA SUBCAPA DE CONTROL DE ACCESO AL MEDIO 221

4.1 EL PROBLEMA DE ASIGNACIÓN DEL CANAL 222
4.1.1 Asignación estática de canal 222
4.1.2 Supuestos para la asignación dinámica de canales 223
4.2 PROTOCOLOS DE ACCESO MÚLTIPLE 225
4.2.1 ALOHA 225
4.2.2 Protocolos de acceso múltiple con detección de portadora 229
4.2.3 Protocolos libres de colisiones 232
4.2.4 Protocolos de contención limitada 235
4.2.5 Protocolos de LAN inalámbrica 238
4.3 ETHERNET 240
4.3.1 Capa física de Ethernet clásica 241
4.3.2 El protocolo de subcapa MAC de la Ethernet clásica 242
4.3.3 Desempeño de Ethernet 245
4.3.4 Ethernet conmutada 247
4.3.5 Fast Ethernet 249
4.3.6 Gigabit Ethernet 251
4.3.7 10 Gigabit Ethernet 254
4.3.8 Retrospectiva de Ethernet 255
4.4 REDES LAN INALÁMBRICAS 257
4.4.1 La arquitectura de 802.11 y la pila de protocolos 257
4.4.2 La capa física del estándar 802.11 258
4.4.3 El protocolo de la subcapa MAC del 802.11 260
4.4.4 La estructura de trama 802.11 265
4.4.5 Servicios 267
*4.5 BANDA ANCHA INALÁMBRICA 268
4.5.1 Comparación del estándar 802.16 con 802.11 y 3G 269
4.5.2 La arquitectura de 802.16 y la pila de protocolos 270
4.5.3 La capa física del estándar 802.16 271
4.5.4 Protocolo de la subcapa MAC del estándar 802.16 273
4.5.5 La estructura de trama del estándar 802.16 274
4.6 BLUETOOTH* 275
4.6.1 Arquitectura de Bluetooth 275
4.6.2 Aplicaciones de Bluetooth 276
4.6.3 La pila de protocolos de Bluetooth 277
4.6.4 La capa de radio de Bluetooth 278
4.6.5 Las capas de enlace de Bluetooth 278
4.6.6 Estructura de la trama de Bluetooth 279
4.7 RFID* 281
4.7.1 Arquitectura EPC Gen 2 281
4.7.2 Capa física de EPC Gen 2 282
4.7.3 Capa de identificación de etiquetas de EPC Gen 2 283
4.7.4 Formatos de los mensajes de identificación de etiquetas 284
www.FreeLibros.me
REDES DE COMPUTADORAS xi
4.8 CONMUTACIÓN DE LA CAPA DE ENLACE DE DATOS 285

4.8.1 Usos de los puentes 286
4.8.2 Puentes de aprendizaje 287
4.8.3 Puentes con árbol de expansión 290
4.8.4 Repetidores, hubs, puentes, switches, enrutadores y puertas de enlace (gateways) 292
4.8.5 Redes LAN virtuales 294
4.9 RESUMEN 300
5 LA CAPA DE RED 305

5.1 ASPECTOS DE DISEÑO DE LA CAPA DE RED 305
5.1.1 Conmutación de paquetes de almacenamiento y reenvío 305
5.1.2 Servicios proporcionados a la capa de transporte 306
5.1.3 Implementación del servicio sin conexión 307
5.1.4 Implementación del servicio orientado a conexión 309
5.1.5 Comparación entre las redes de circuitos virtuales y las redes de datagramas 310
5.2 ALGORITMOS DE ENRUTAMIENTO 311
5.2.1 Principio de optimización 313
5.2.2 Algoritmo de la ruta más corta 314
5.2.3 Inundación 317
5.2.4 Enrutamiento por vector de distancia 318
5.2.5 Enrutamiento por estado del enlace 320
5.2.6 Enrutamiento jerárquico 325
5.2.7 Enrutamiento por difusión 326
5.2.8 Enrutamiento multidifusión 328
5.2.9 Enrutamiento anycast 331
5.2.10 Enrutamiento para hosts móviles 332
5.2.11 Enrutamiento en redes ad hoc 334
5.3 ALGORITMOS DE CONTROL DE CONGESTIÓN 337
5.3.1 Métodos para el control de la congestión 338
5.3.2 Enrutamiento consciente del tráfico 339
5.3.3 Control de admisión 340
5.3.4 Regulación de tráfico 341
5.3.5 Desprendimiento de carga 344
5.4 CALIDAD DEL SERVICIO 347
5.4.1 Requerimientos de la aplicación 347
5.4.2 Modelado de tráfico 349
5.4.3 Programación de paquetes 353
5.4.4 Control de admisión 356
5.4.5 Servicios integrados 359
5.4.6 Servicios diferenciados 361
5.5 INTERCONEXIÓN DE REDES 364
5.5.1 Cómo difieren las redes 365
5.5.2 Cómo se pueden conectar las redes 366
5.5.3 Tunelización 368
5.5.4 Enrutamiento entre redes 370
5.5.5 Fragmentación de paquetes 371
www.FreeLibros.me
xii ConTenido
5.6 LA CAPA DE RED DE INTERNET 374

5.6.1 El protocolo IP versión 4 376
5.6.2 Direcciones IP 379
5.6.3 IP versión 6 390
5.6.4 Protocolos de control en Internet 398
5.6.5 Conmutación mediante etiquetas y MPLS 403
5.6.6 OSPF: un protocolo de enrutamiento de puerta de enlace interior 405
5.6.7 BGP: el protocolo de enrutamiento de Puerta de Enlace Exterior 410
5.6.8 Multidifusión de Internet 414
5.6.9 IP móvil 415
5.7 RESUMEN 418
6 LA CAPA DE TRANSPORTE 425

6.1 EL SERVICIO DE TRANSPORTE 425
6.1.1 Servicios que se proporcionan a las capas superiores 425
6.1.2 Primitivas del servicio de transporte 427
6.1.3 Sockets de Berkeley 430
6.1.4 Un ejemplo de programación de sockets: un servidor de archivos de Internet 432
6.2 ELEMENTOS DE LOS PROTOCOLOS DE TRANSPORTE 436
6.2.1 Direccionamiento 437
6.2.2 Establecimiento de una conexión 439
6.2.3 Liberación de una conexión 444
6.2.4 Control de errores y almacenamiento en búfer 448
6.2.5 Multiplexión 452
6.2.6 Recuperación de fallas 453
6.3 CONTROL DE CONGESTIÓN 455
6.3.1 Asignación de ancho de banda deseable 455
6.3.2 Regulación de la tasa de envío 459
6.3.3 Cuestiones inalámbricas 462
6.4 LOS PROTOCOLOS DE TRANSPORTE DE INTERNET: UDP 464
6.4.1 Introducción a UDP 464
6.4.2 Llamada a procedimiento remoto 466
6.4.3 Protocolos de transporte en tiempo real 469
6.5 LOS PROTOCOLOS DE TRANSPORTE DE INTERNET: TCP 474
6.5.1 Introducción a TCP 474
6.5.2 El modelo del servicio TCP 474
6.5.3 El protocolo TCP 477
6.5.4 El encabezado del segmento TCP 478
6.5.5 Establecimiento de una conexión TCP 481
6.5.6 Liberación de una conexión TCP 482
6.5.7 Modelado de administración de conexiones TCP 482
6.5.8 Ventana deslizante de TCP 485
6.5.9 Administración de temporizadores de TCP 488
6.5.10 Control de congestión en TCP 490
6.5.11 El futuro de TCP 499
www.FreeLibros.me
redes de computadoras xiii
*6.6 ASPECTOS DEL DESEMPEÑO 500

6.6.1 Problemas de desempeño en las redes de computadoras 500
6.6.2 Medición del desempeño de las redes 501
6.6.3 Diseño de hosts para redes rápidas 503
6.6.4 Procesamiento rápido de segmentos 506
6.6.5 Compresión de encabezado 509
6.6.6 Protocolos para redes de alto desempeño 511
*6.7 REDES TOLERANTES AL RETARDO 515
6.7.1 Arquitectura DTN 516
6.7.2 El protocolo Bundle 518
6.8 RESUMEN 520
7 LA CAPA DE APLICACIÓN 525

7.1 DNS: EL SISTEMA DE NOMBRES DE DOMINIO 525
7.1.1 El espacio de nombres del DNS 526
7.1.2 Registros de recursos de dominio 529
7.1.3 Servidores de nombres 532
*7.2 CORREO ELECTRÓNICO 535
7.2.1 Arquitectura y servicios 536
7.2.2 El agente de usuario 538
7.2.3 Formatos de mensaje 541
7.2.4 Transferencia de mensajes 548
7.2.5 Entrega final 553
7.3 WORLD WIDE WEB 555
7.3.1 Panorama de la arquitectura 556
7.3.2 Páginas web estáticas 569
7.3.3 Páginas web dinámicas y aplicaciones web 577
7.3.4 HTTP: el Protocolo de Transferencia de HiperTexto 587
7.3.5 La web móvil 596
7.3.6 Búsqueda web 598
7.4 AUDIO Y VIDEO DE FLUJO CONTINUO 599
7.4.1 Audio digital 601
7.4.2 Video digital 605
7.4.3 Medios almacenados de flujo continuo (streaming) 612
7.4.4 Transmisión en flujo continuo de medios en vivo 619
7.4.5 Conferencia en tiempo real 623
7.5 ENTREGA DE CONTENIDO 631
7.5.1 Contenido y tráfico de Internet 632
7.5.2 Granjas de servidores y proxies web 635
7.5.3 Redes de entrega de contenido 639
7.5.4 Redes de igual a igual 643
7.6 RESUMEN 651
www.FreeLibros.me
xiv Contenido
8 SEGURIDAD EN REDES 657

8.1 CRIPTOGRAFÍA 660
8.1.1 Introducción a la criptografía 660
8.1.2 Sistemas de cifrado por sustitución 662
8.1.3 Sistemas de cifrado por transposición 663
8.1.4 Rellenos de una sola vez 664
8.1.5 Dos principios criptográficos fundamentales 668
8.2 ALGORITMOS DE CLAVE SIMÉTRICA 670
8.2.1 DES: Estándar de Encriptación de Datos 671
8.2.2 AES: Estándar de Encriptación Avanzada 674
8.2.3 Modos de sistema de cifrado 677
8.2.4 Otros sistemas de cifrado 681
8.2.5 Criptoanálisis 682
8.3 ALGORITMOS DE CLAVE PÚBLICA 683
8.3.1 RSA 684
8.3.2 Otros algoritmos de clave pública 685
8.4 FIRMAS DIGITALES 686
8.4.1 Firmas de clave simétrica 686
8.4.2 Firmas de clave pública 687
8.4.3 Resúmenes de mensaje 689
8.4.4 El ataque de cumpleaños 692
8.5 ADMINISTRACIÓN DE CLAVES PÚBLICAS 694
8.5.1 Certificados 694
8.5.2 X.509 696
8.5.3 Infraestructuras de clave pública 697
8.6 SEGURIDAD EN LA COMUNICACIÓN 700
8.6.1 IPsec 700
8.6.2 Firewalls 703
8.6.3 Redes privadas virtuales 706
8.6.4 Seguridad inalámbrica 707
8.7 PROTOCOLOS DE AUTENTIFICACIÓN 711
8.7.1 Autentificación basada en una clave secreta compartida 712
8.7.2 Establecimiento de una clave compartida: el intercambio de claves de Diffie-Hellman 716
8.7.3 Autentificación mediante el uso de un centro de distribución de claves 718
8.7.4 Autentificación mediante el uso de Kerberos 720
8.7.5 Autentificación mediante el uso de criptografía de clave pública 722
*8.8 SEGURIDAD DE CORREO ELECTRÓNICO 723
8.8.1 PGP: Privacidad Bastante Buena 723
8.8.2 S/MIME 727
8.9 SEGURIDAD EN WEB 727
8.9.1 Amenazas 727
8.9.2 Asignación segura de nombres 728
www.FreeLibros.me
SEC. 1.4 MODELOS DE REFERENCIA 35
Capa k + 1 Capa k + 1
Servicio proporcionado por la capa k
Protocolo
Capa k Capa k
Capa k - 1 Capa k - 1
Figura 1-19. La relación entre un servicio y un protocolo.
Vale la pena mencionar una analogía con los lenguajes de programación. Un servicio es como un tipo
de datos abstracto o un objeto en un lenguaje orientado a objetos. Define las operaciones que se pueden
realizar en un objeto, pero no especifica cómo se implementan estas operaciones. En contraste, un proto-
colo se relaciona con la implementación del servicio y como tal, no es visible al usuario del mismo.
Muchos protocolos antiguos no diferenciaban el servicio del protocolo. En efecto, una capa típica
podría tener una primitiva de servicio SEND PACKET en donde el usuario proporcionaba un apuntador
hacia un paquete completamente ensamblado. Este arreglo significaba que los usuarios podían ver de
inmediato todos los cambios en el protocolo. Ahora, la mayoría de los diseñadores de redes consideran
dicho diseño como un error garrafal.
1.4 MODELOS DE REFERENCIA

Ahora que hemos analizado en lo abstracto las redes basadas en capas, es tiempo de ver algunos ejemplos.
Analizaremos dos arquitecturas de redes importantes: el modelo de referencia OSI y el modelo de refe-
rencia TCP/IP. Aunque ya casi no se utilizan los protocolos asociados con el modelo OSI, el modelo en sí
es bastante general y sigue siendo válido; asimismo, las características en cada nivel siguen siendo muy
importantes. El modelo TCP/IP tiene las propiedades opuestas: el modelo en sí no se utiliza mucho, pero
los protocolos son usados ampliamente. Por esta razón veremos ambos elementos con detalle. Además,
algunas veces podemos aprender más de los fracasos que de los éxitos.
1.4.1 El modelo de referencia OSI
El modelo OSI se muestra en la figura 1-20 (sin el medio físico). Este modelo se basa en una propuesta
desarrollada por la Organización Internacional de Normas (iso) como el primer paso hacia la estandari-
zación internacional de los protocolos utilizados en las diversas capas (Day y Zimmerman, 1983). Este
modelo se revisó en 1995 (Day, 1995) y se le llama Modelo de referencia OSI (Interconexión de Sistemas
Abiertos, del inglés Open Systems Interconnection) de la iso puesto que se ocupa de la conexión de sis-
temas abiertos; esto es, sistemas que están abiertos a la comunicación con otros sistemas. Para abreviar,
lo llamaremos modelo OSI.
El modelo OSI tiene siete capas. Los principios que se aplicaron para llegar a las siete capas se pue-
den resumir de la siguiente manera:
1. Se debe crear una capa en donde se requiera un nivel diferente de abstracción.
2. Cada capa debe realizar una función bien definida.
3. La función de cada capa se debe elegir teniendo en cuenta la definición de protocolos estandari-
zados internacionalmente.
www.FreeLibros.me
36 INTRODUCCIÓN CAP. 1
Capa Nombre de la unidad

intercambiada
Protocolo de aplicación
7 Aplicación Aplicación APDU
Interfaz
Protocolo de presentación
6 Presentación Presentación PPDU
Protocolo de sesión
5 Sesión Sesión SPDU
Protocolo de transporte
4 Transporte Transporte TPDU
Límite de subred de comunicación
Protocolo interno de la subred
3 Red Red Red Red Paquete
2 Enlace de datos Enlace de datos Enlace de datos Enlace de datos Trama
1 Física Física Física Física Bit

Host A Enrutador Enrutador Host B
Protocolo de host-enrutador de la capa de red

Protocolo de host-enrutador de la capa de enlace de datos
Protocolo de host-enrutador de la capa física
Figura 1-20. El modelo de referencia OSI.
4. Es necesario elegir los límites de las capas de modo que se minimice el flujo de información a
través de las interfaces.
5. La cantidad de capas debe ser suficiente como para no tener que agrupar funciones distintas en
la misma capa; además, debe ser lo bastante pequeña como para que la arquitectura no se vuelva
inmanejable.
A continuación estudiaremos cada capa del modelo en orden, empezando por la capa inferior. Ten-
ga en cuenta que el modelo OSI en sí no es una arquitectura de red, ya que no especifica los servicios y
protocolos exactos que se van a utilizar en cada capa. Sólo indica lo que una debe hacer. Sin embargo, la
ISO también ha elaborado estándares para todas las capas, aunque no son parte del modelo de referencia
en sí. Cada uno se publicó como un estándar internacional separado. Aunque el modelo (en parte) es muy
usado, los protocolos asociados han estado en el olvido desde hace tiempo.
La capa física
La capa física se relaciona con la transmisión de bits puros a través de un canal de transmisión. Los
aspectos de diseño tienen que ver con la acción de asegurarse que cuando uno de los lados envíe un bit 1
el otro lado lo reciba como un bit 1, no como un bit 0. En este caso las preguntas típicas son: ¿que señales
www.FreeLibros.me
eléctricas se deben usar para representar un 1 y un 0?, ¿cuántos nanosegundos dura un bit?, ¿la transmi-
sión puede proceder de manera simultánea en ambas direcciones?, ¿cómo se establece la conexión inicial
y cómo se interrumpe cuando ambos lados han terminado?, ¿cuántos pines tiene el conector de red y para
qué sirve cada uno? Los aspectos de diseño tienen que ver con las interfaces mecánica, eléctrica y de tem-
porización, así como con el medio de transmisión físico que se encuentra bajo la capa física.
La capa de enlace de datos
La principal tarea de la capa de enlace de datos es transformar un medio de transmisión puro en una línea
que esté libre de errores de transmisión. Enmascara los errores reales, de manera que la capa de red no
los vea. Para lograr esta tarea, el emisor divide los datos de entrada en tramas de datos (por lo general,
de algunos cientos o miles de bytes) y transmite las tramas en forma secuencial. Si el servicio es confiable,
para confirmar la recepción correcta de cada trama, el receptor devuelve una trama de confirmación
de recepción.
Otra cuestión que surge en la capa de enlace de datos (y en la mayoría de las capas superiores) es
cómo evitar que un transmisor rápido inunde de datos a un receptor lento. Tal vez sea necesario algún
mecanismo de regulación de tráfico para notificar al transmisor cuando el receptor puede aceptar más
datos.
Las redes de difusión tienen una consideración adicional en la capa de enlace de datos: cómo con-
trolar el acceso al canal compartido. Una subcapa especial de la capa de enlace de datos, conocida como
subcapa de control de acceso al medio, es la que se encarga de este problema.
La capa de red
La capa de red controla la operación de la subred. Una cuestión clave de diseño es determinar cómo se
encaminan los paquetes desde el origen hasta el destino. Las rutas se pueden basar en tablas estáticas que
se “codifican” en la red y rara vez cambian, aunque es más común que se actualicen de manera automática
para evitar las fallas en los componentes. También se pueden determinar el inicio de cada conversación;
por ejemplo, en una sesión de terminal al iniciar sesión en una máquina remota. Por último, pueden ser
muy dinámicas y determinarse de nuevo para cada paquete, de manera que se pueda reflejar la carga actual
en la red.
Si hay demasiados paquetes en la subred al mismo tiempo, se interpondrán en el camino unos con
otros y formarán cuellos de botella. El manejo de la congestión también es responsabilidad de la capa de
red, en conjunto con las capas superiores que adaptan la carga que colocan en la red. Otra cuestión más
general de la capa de red es la calidad del servicio proporcionado (retardo, tiempo de tránsito, variaciones,
etcétera).
Cuando un paquete tiene que viajar de una red a otra para llegar a su destino, pueden surgir muchos
problemas. El direccionamiento utilizado por la segunda red puede ser distinto del que utiliza la primera.
La segunda red tal vez no acepte el paquete debido a que es demasiado grande. Los protocolos pueden
ser diferentes, etc. Es responsabilidad de la capa de red solucionar todos estos problemas para permitir la
interconexión de redes heterogéneas.
En las redes de difusión, el problema de encaminamiento es simple, por lo que con frecuencia la capa
de red es delgada o incluso inexistente.
La capa de transporte
La función básica de la capa de transporte es aceptar datos de la capa superior, dividirlos en unidades
más pequeñas si es necesario, pasar estos datos a la capa de red y asegurar que todas las piezas lleguen
www.FreeLibros.me
correctamente al otro extremo. Además, todo esto se debe realizar con eficiencia y de una manera que
aísle las capas superiores de los inevitables cambios en la tecnología de hardware que se dan con el trans-
curso del tiempo.
La capa de transporte también determina el tipo de servicio que debe proveer a la capa de sesión y, en
última instancia, a los usuarios de la red. El tipo más popular de conexión de transporte es un canal punto
a punto libre de errores que entrega los mensajes o bytes en el orden en el que se enviaron. Sin embargo
existen otros posibles tipos de servicio de transporte, como el de mensajes aislados sin garantía sobre
el orden de la entrega y la difusión de mensajes a múltiples destinos. El tipo de servicio se determina al
establecer la conexión (cabe mencionar que es imposible lograr un canal libre de errores; lo que se quiere
decir en realidad con este término es que la tasa de errores es lo bastante baja como para ignorarla en la
práctica).
La capa de transporte es una verdadera capa de extremo a extremo; lleva los datos por toda la ruta
desde el origen hasta el destino. En otras palabras, un programa en la máquina de origen lleva a cabo
una conversación con un programa similar en la máquina de destino mediante el uso de los encabeza-
dos en los mensajes y los mensajes de control. En las capas inferiores cada uno de los protocolos está
entre una máquina y sus vecinos inmediatos, no entre las verdaderas máquinas de origen y de destino,
que pueden estar separadas por muchos enrutadores. En la figura 1-20 se muestra la diferencia entre
las capas de la 1 a la 3, que están encadenadas, y entre las capas de la 4 a la 7, que son de extremo a
extremo.
La capa de sesión
La capa de sesión permite a los usuarios en distintas máquinas establecer sesiones entre ellos. Las sesio-
nes ofrecen varios servicios, incluyendo el control del diálogo (llevar el control de quién va a transmitir),
el manejo de tokens (evitar que dos partes intenten la misma operación crítica al mismo tiempo) y la
sincronización (usar puntos de referencia en las transmisiones extensas para reanudar desde el último
punto de referencia en caso de una interrupción).
La capa de presentación
A diferencia de las capas inferiores, que se enfocan principalmente en mover los bits de un lado a otro,
la capa de presentación se enfoca en la sintaxis y la semántica de la información transmitida. Para
hacer posible la comunicación entre computadoras con distintas representaciones internas de datos,
podemos definir de una manera abstracta las estructuras de datos que se van a intercambiar, junto con
una codificación estándar que se use “en el cable”. La capa de presentación maneja estas estructuras
de datos abstractas y permite definir e intercambiar estructuras de datos de mayor nivel (por ejemplo,
registros bancarios).
La capa de aplicación
La capa de aplicación contiene una variedad de protocolos que los usuarios necesitan con frecuencia. Un
protocolo de aplicación muy utilizado es HTTP (Protocolo de Transferencia de Hipertexto, del inglés
HyperText Transfer Protocol ), el cual forma la base para la World Wide Web. Cuando un navegador desea
una página web, envía el nombre de la página que quiere al servidor que la hospeda mediante el uso de
HTTP. Después el servidor envía la página de vuelta. Hay otros protocolos de aplicación que se utilizan
para transferir archivos, enviar y recibir correo electrónico y noticias.
www.FreeLibros.me
1.4.2 El modelo de referencia TCP/IP
Pasemos ahora del modelo de referencia OSI al modelo de referencia que se utiliza en la más vieja de
todas las redes de computadoras de área amplia: ARPANET y su sucesora, Internet. Aunque más ade-
lante veremos una breve historia de ARPANET, es conveniente mencionar ahora unos cuantos aspectos
de esta red. ARPANET era una red de investigación patrocinada por el DoD (Departamento de Defensa
de Estados Unidos, del inglés U.S. Department of the Defense). En un momento dado llegó a conectar
cientos de universidades e instalaciones gubernamentales mediante el uso de líneas telefónicas rentadas.
Cuando después se le unieron las redes de satélites y de radio, los protocolos existentes tuvieron proble-
mas para interactuar con ellas, de modo que se necesitaba una nueva arquitectura de referencia. Así, casi
desde el principio la habilidad de conectar varias redes sin problemas fue uno de los principales objeti-
vos de diseño. Posteriormente esta arquitectura se dio a conocer como el Modelo de referencia TCP/IP,
debido a sus dos protocolos primarios. Este modelo se definió por primera vez en Cerf y Kahn (1974);
después se refinó y definió como estándar en la comunidad de Internet (Braden, 1989). Clark (1988) des-
cribe la filosofía de diseño detrás de este modelo.
Debido a la preocupación del DoD de que alguno de sus valiosos hosts, enrutadores y puertas de enla-
ce de interredes pudieran ser volados en pedazos en cualquier momento por un ataque de la antigua Unión
Soviética, otro de los objetivos principales fue que la red pudiera sobrevivir a la pérdida de hardware de
la subred sin que se interrumpieran las conversaciones existentes. En otras palabras, el DoD quería que
las conexiones permanecieran intactas mientras las máquinas de origen y de destino estuvieran funcio-
nando, incluso aunque algunas de las máquinas o líneas de transmisión en el trayecto dejaran de funcionar
en forma repentina. Además, como se tenían en mente aplicaciones con requerimientos divergentes que
abarcaban desde la transferencia de archivos hasta la transmisión de voz en tiempo real, se necesitaba una
arquitectura flexible.
La capa de enlace
Todos estos requerimientos condujeron a la elección de una red de conmutación de paquetes basada en
una capa sin conexión que opera a través de distintas redes. La capa más baja en este modelo es la capa de
enlace; ésta describe qué enlaces (como las líneas seriales y Ethernet clásica) se deben llevar a cabo para
cumplir con las necesidades de esta capa de interred sin conexión. En realidad no es una capa en el senti-
do común del término, sino una interfaz entre los hosts y los enlaces de transmisión. El primer material
sobre el modelo TCP/IP tiene poco que decir sobre ello.
La capa de interred
Esta capa es el eje que mantiene unida a toda la arquitectura. Aparece en la figura 1-21 con una corres-
pondencia aproximada a la capa de red de OSI. Su trabajo es permitir que los hosts inyecten paquetes en
cualquier red y que viajen de manera independiente hacia el destino (que puede estar en una red distinta).
Incluso pueden llegar en un orden totalmente diferente al orden en que se enviaron, en cuyo caso es res-
ponsabilidad de las capas más altas volver a ordenarlos, si se desea una entrega en orden. Tenga en cuenta
que aquí utilizamos “interred” en un sentido genérico, aunque esta capa esté presente en la Internet.
La analogía aquí es con el sistema de correos convencional (lento). Una persona puede dejar una
secuencia de cartas internacionales en un buzón en un país y, con un poco de suerte, la mayoría de ellas se
entregarán a la dirección correcta en el país de destino. Es probable que las cartas pasen a través de una
o más puertas de enlace de correo internacionales en su trayecto, pero esto es transparente a los usuarios.
Además, los usuarios no necesitan saber que cada país (es decir, cada red) tiene sus propias estampillas,
tamaños de sobre preferidos y reglas de entrega.
www.FreeLibros.me
OSI TCP/IP
7 Aplicación Aplicación
6 Presentación No están presentes

en el modelo
5 Sesión
4 Transporte Transporte
3 Red Interred
2 Enlace de datos Enlace
1 Física
Figura 1-21. El modelo de referencia TCP/IP.
La capa de interred define un formato de paquete y un protocolo oficial llamado IP (Protocolo de

Internet, del inglés Internet Protocol), además de un protocolo complementario llamado ICMP (Pro-
tocolo de Mensajes de Control de Internet, del inglés Internet Control Message Protocol ) que le ayuda
a funcionar. La tarea de la capa de interred es entregar los paquetes IP a donde se supone que deben ir.
Aquí el ruteo de los paquetes es sin duda el principal aspecto, al igual que la congestión (aunque el IP no
ha demostrado ser efectivo para evitar la congestión).
La capa de transporte
Por lo general, a la capa que está arriba de la capa de interred en el modelo TCP/IP se le conoce como
capa de transporte; y está diseñada para permitir que las entidades pares, en los nodos de origen y de
destino, lleven a cabo una conversación, al igual que en la capa de transporte de OSI. Aquí se definieron
dos protocolos de transporte de extremo a extremo. El primero, TCP (Protocolo de Control de la Trans-
misión, del inglés Transmission Control Protocol ), es un protocolo confiable orientado a la conexión que
permite que un flujo de bytes originado en una máquina se entregue sin errores a cualquier otra máquina
en la interred. Este protocolo segmenta el flujo de bytes entrante en mensajes discretos y pasa cada uno a
la capa de interred. En el destino, el proceso TCP receptor vuelve a ensamblar los mensajes recibidos para
formar el flujo de salida. El TCP también maneja el control de flujo para asegurar que un emisor rápido no
pueda inundar a un receptor lento con más mensajes de los que pueda manejar.
El segundo protocolo en esta capa, UDP (Protocolo de Datagrama de Usuario, del inglés User
Datagram Protocol ), es un protocolo sin conexión, no confiable para aplicaciones que no desean la asig-
nación de secuencia o el control de flujo de TCP y prefieren proveerlos por su cuenta. También se utiliza
mucho en las consultas de petición-respuesta de una sola ocasión del tipo cliente-servidor, y en las aplica-
ciones en las que es más importante una entrega oportuna que una entrega precisa, como en la transmisión
de voz o video. En la figura 1-22 se muestra la relación entre IP, TCP y UDP. Desde que se desarrolló el
modelo, el IP se ha implementado en muchas otras redes.
La capa de aplicación
El modelo TCP/IP no tiene capas de sesión o de presentación, ya que no se consideraron necesarias. Las
aplicaciones simplemente incluyen cualquier función de sesión y de presentación que requieran. La expe-
riencia con el modelo OSI ha demostrado que esta visión fue correcta: estas capas se utilizan muy poco
en la mayoría de las aplicaciones.
www.FreeLibros.me
Aplicación HTTP SMTP RTP DNS
Transporte TCP UDP
Capas Protocolos
Interred IP ICMP
Enlace DSL SONET 802.11 Ethernet
Figura 1-22. El modelo TCP/IP con algunos de los protocolos.
Encima de la capa de transporte se encuentra la capa de aplicación. Ésta contiene todos los protoco-
los de alto nivel. Entre los primeros protocolos están el de terminal virtual (TELNET), transferencia de
archivos (FTP) y correo electrónico (SMTP). A través de los años se han agregado muchos otros protoco-
los. En la figura 1-22 se muestran algunos de los más importantes que veremos más adelante: el Sistema
de nombres de dominio (DNS) para resolución de nombres de hosts a sus direcciones de red; HTTP, el
protocolo para recuperar páginas de la World Wide Web; y RTP, el protocolo para transmitir medios en
tiempo real, como voz o películas.
1.4.3 El modelo utilizado en este libro
Como dijimos antes, la fortaleza del modelo de referencia OSI es el modelo en sí (excepto las capas de
presentación y de sesión), el cual ha demostrado ser excepcionalmente útil para hablar sobre redes
de computadoras. En contraste, la fortaleza del modelo de referencia TCP/IP son los protocolos, que
se han utilizado mucho durante varios años. Como a los científicos de computadoras les gusta hacer sus
propias herramientas, utilizaremos el modelo híbrido de la figura 1-23 como marco de trabajo para este
libro.
5 Aplicación
4 Transporte
3 Red
2 Enlace
1 Física
Figura 1-23. El modelo de referencia que usaremos en este libro.
Este modelo tiene cinco capas, empezando por la capa física, pasando por las capas de enlace, red y
transporte hasta llegar a la capa de aplicación. La capa física especifica cómo transmitir bits a través de
distintos tipos de medios como señales eléctricas (u otras señales analógicas). La capa de enlace trata
sobre cómo enviar mensajes de longitud finita entre computadoras conectadas de manera directa con niveles
específicos de confiabilidad. Ethernet y 802.11 son ejemplos de protocolos de capa de enlace.
www.FreeLibros.me
La capa de red se encarga de combinar varios enlaces múltiples en redes, y redes de redes en interre-
des, de manera que podamos enviar paquetes entre computadoras distantes. Aquí se incluye la tarea de
buscar la ruta por la cual enviarán los paquetes. IP es el principal protocolo de ejemplo que estudiaremos
para esta capa. La capa de transporte fortalece las garantías de entrega de la capa de Red, por lo general
con una mayor confiabilidad, además provee abstracciones en la entrega, como un flujo de bytes confia-
ble, que coincida con las necesidades de las distintas aplicaciones. TCP es un importante ejemplo de un
protocolo de capa de transporte.
Por último, la capa de aplicación contiene programas que hacen uso de la red. Muchas aplicaciones
en red tienen interfaces de usuario, como un navegador web. Sin embargo, nuestro interés está en la par-
te del programa que utiliza la red. En el caso del navegador web se trata del protocolo HTTP. También
hay programas de soporte importantes en la capa de aplicación, como el DNS, que muchas aplicaciones
utilizan.
La secuencia de nuestros capítulos se basa en este modelo. De esta forma, retenemos el valor del
modelo OSI para comprender las arquitecturas de red al tiempo que nos concentramos principalmente
en los protocolos que son importantes en la práctica, desde TCP/IP y los protocolos relacionados hasta los
más recientes como 802.11, SONET y Bluetooth.
1.4.4 Comparación de los modelos de referencia OSI y TCP/IP
Los modelos de referencia OSI y TCP/IP tienen mucho en común. Ambos se basan en el concepto de una
pila de protocolos independientes. Además, la funcionalidad de las capas es muy similar. Por ejemplo, en
ambos modelos las capas por encima de la de transporte, incluyendo ésta, se encuentran ahí para propor-
cionar un servicio de transporte independiente de la red, de extremo a extremo, para los procesos que de-
sean comunicarse. Estas capas forman el proveedor de transporte. También en ambos modelos, las capas
que están arriba de la de transporte son usuarias orientadas a la aplicación del servicio de transporte.
A pesar de estas similitudes fundamentales, los dos modelos también tienen muchas diferencias. En
esta sección nos enfocaremos en las diferencias clave entre los dos modelos de referencia. Es importante
tener en cuenta que aquí compararemos los modelos de referencia y no las pilas de protocolos corres-
pondientes. Más adelante estudiaremos los protocolos en sí. Un libro completo dedicado a comparar y
contrastar TCP/IP y OSI es el de Piscitello y Chapin (1993).
Hay tres conceptos básicos para el modelo OSI:
1. Servicios.
2. Interfaces.
3. Protocolos.
Quizá, la mayor contribución del modelo OSI es que hace explícita la distinción entre estos tres con-
ceptos. Cada capa desempeña ciertos servicios para la capa que está sobre ella. La definición del servicio
indica lo que hace la capa, no cómo acceden a ella las entidades superiores ni cómo funciona. Define la
semántica de la capa.
La interfaz de una capa indica a los procesos superiores cómo pueden acceder a ella. Especifica cuá-
les son los parámetros y qué resultados se pueden esperar. Pero no dice nada sobre su funcionamiento
interno.
Por último, la capa es la que debe decidir qué protocolos de iguales utilizar. Puede usar los protocolos
que quiera, siempre y cuando realice el trabajo (es decir, que provea los servicios ofrecidos). También los
puede cambiar a voluntad sin afectar el software de las capas superiores.
Estas ideas encajan muy bien con las ideas modernas sobre la programación orientada a objetos.
Al igual que una capa, un objeto tiene un conjunto de métodos (operaciones) que los procesos fuera
www.FreeLibros.me
del objeto pueden invocar. La semántica de estos métodos define el conjunto de servicios que ofrece
el objeto. Los parámetros y resultados de los métodos forman la interfaz del objeto. El código inter-
no del objeto es su protocolo y no se puede ver ni es de la incumbencia de las entidades externas al
objeto.
Al principio, el modelo TCP/IP no tenía una distinción clara entre los servicios, las interfaces y
los protocolos, aunque las personas han tratado de reajustarlo a fin de hacerlo más parecido al OSI.
Por ejemplo, los únicos servicios que realmente ofrece la capa de interred son send ip packet y receive ip
packet. Como consecuencia, los protocolos en el modelo OSI están ocultos de una mejor forma que en el
modelo TCP/IP, además se pueden reemplazar con relativa facilidad a medida que la tecnología cambia.
La capacidad de realizar dichos cambios con transparencia es uno de los principales propósitos de tener
protocolos en capas en primer lugar.
El modelo de referencia OSI se ideó antes de que se inventaran los protocolos correspondientes.
Este orden significa que el modelo no estaba orientado hacia un conjunto específico de protocolos,
un hecho que lo hizo bastante general. La desventaja de este orden fue que los diseñadores no tenían
mucha experiencia con el tema y no supieron bien qué funcionalidad debían colocar en cada una de las
capas.
Por ejemplo, en un principio la capa de enlace de datos trabajaba sólo con redes de punto a punto.
Cuando surgieron las redes de difusión, fue necesario insertar una nueva subcapa al modelo. Además,
cuando las personas empezaron a construir redes reales mediante el modelo OSI y los protocolos exis-
tentes, se descubrió que estas redes no coincidían con las especificaciones de los servicios requeridos, de
modo que tuvieron que integrar en el modelo subcapas convergentes que permitieran cubrir las diferen-
cias. Finalmente, el comité en un principio esperaba que cada país tuviera una red operada por el gobierno
en la que se utilizaran los protocolos OSI, por lo que no se tomó en cuenta la interconexión de redes. Para
no hacer el cuento largo, las cosas no salieron como se esperaba.
Con TCP/IP sucedió lo contrario: primero llegaron los protocolos y el modelo era en realidad
sólo una descripción de los protocolos existentes. No hubo problema para que los protocolos se
ajustaran al modelo. Encajaron a la perfección. El único problema fue que el modelo no encajaba en
ninguna otra pila de protocolos. En consecuencia, no era útil para describir otras redes que no fueran
TCP/IP.
Pasando de las cuestiones filosóficas a las más específicas, una diferencia obvia entre los dos
modelos está en el número de capas: el modelo OSI tiene siete capas, mientras que el modelo TCP/
IP tiene cuatro. Ambos tienen capas de (inter)red, transporte y aplicación, pero las demás capas son
distintas.
Hay otra diferencia en el área de la comunicación sin conexión frente a la comunicación orientada
a conexión. El modelo OSI soporta ambos tipos de comunicación en la capa de red, pero sólo la comu-
nicación orientada a conexión en la capa de transporte, en donde es más importante (ya que el servicio
de transporte es visible a los usuarios). El modelo TCP/IP sólo soporta un modo en la capa de red (sin
conexión) pero soporta ambos en la capa de transporte, de manera que los usuarios tienen una alternativa,
que es muy importante para los protocolos simples de petición-respuesta.
1.4.5 Una crítica al modelo y los protocolos OSI
Ni el modelo OSI y sus protocolos, ni el modelo TCP/IP y sus protocolos son perfectos. Ambos pueden
recibir bastantes críticas, y así se ha hecho. En ésta y en la siguiente sección analizaremos algunas de ellas.
Empezaremos con el modelo OSI y después examinaremos el modelo TCP/IP.
Para cuando se publicó la segunda edición de este libro (1989), a muchos expertos en el campo les
pareció que el modelo OSI y sus protocolos iban a adueñarse del mundo y sacar todo lo demás a su paso.
www.FreeLibros.me
Pero esto no fue así. ¿Por qué? Tal vez sea útil analizar en retrospectiva algunas de las razones. Podemos
resumirlas de la siguiente manera:
1. Mala sincronización.
2. Mala tecnología.
3. Malas implementaciones.
4. Mala política.
Mala sincronización
Veamos la razón número uno: mala sincronización. El tiempo en el cual se establece un estándar es ab-
solutamente imprescindible para su éxito. David Clark, del Massachusetts Institute of Technology (mit),
tiene una teoría de estándares a la que llama el apocalipsis de los dos elefantes, la cual se ilustra en la
figura 1-24.
Esta figura muestra la cantidad de actividad alrededor de un nuevo tema. Cuando se descubre el tema
por primera vez, hay una ráfaga de actividades de investigación en forma de discusiones, artículos y
reuniones. Después de cierto tiempo esta actividad disminuye, las corporaciones descubren el tema y llega
la ola de inversión de miles de millones de dólares.
Es imprescindible que los estándares se escriban en el intermedio entre los dos “elefantes”. Si se es-
criben demasiado pronto (antes de que los resultados de la investigación estén bien establecidos), tal vez el
tema no se entienda bien todavía; el resultado es un estándar malo. Si se escriben demasiado tarde, es proba-
ble que muchas empresas hayan hecho ya importantes inversiones en distintas maneras de hacer las cosas,
de modo que los estándares se ignorarán en la práctica. Si el intervalo entre los dos elefantes es muy corto
(ya que todos tienen prisa por empezar), la gente que desarrolla los estándares podría quedar aplastada.
En la actualidad, parece que los protocolos estándar de OSI quedaron aplastados. Para cuan-
do aparecieron los protocolos de OSI, los protocolos TCP/IP competidores ya se utilizaban mucho en uni-
versidades que hacían investigaciones. Aunque todavía no llegaba la ola de inversión de miles de millones
de dólares, el mercado académico era lo bastante grande como para que muchos distribuidores empezaran
a ofrecer con cautela los productos TCP/IP. Para cuando llegó el modelo OSI, los distribuidores no quisie-
ron apoyar una segunda pila de protocolos hasta que se vieron obligados a hacerlo, de modo que no hubo
ofertas iniciales. Como cada empresa estaba esperando a que otra tomara la iniciativa, ninguna lo hizo y
OSI nunca se llevó a cabo.
Inversión de miles de
Investigación millones de dólares
Actividad
Estándares
Tiempo
Figura 1-24. El apocalipsis de los dos elefantes.
www.FreeLibros.me
Mala tecnología
La segunda razón por la que OSI nunca tuvo éxito fue que tanto el modelo como los protocolos tienen
fallas. La opción de siete capas era más política que técnica, además de que dos de las capas (sesión y
presentación) están casi vacías, mientras que otras dos (enlace de datos y red) están demasiado llenas.
El modelo OSI, junto con sus correspondientes definiciones y protocolos de servicios, es muy
complejo. Si se apilan, los estándares impresos ocupan una fracción considerable de un metro de papel.
Además son difíciles de implementar e ineficientes en su operación. En este contexto nos viene a la mente
un acertijo propuesto por Paul Mockapetris y citado por Rose (1993):
P: ¿Qué obtenemos al cruzar un pandillero con un estándar internacional?
R: Alguien que le hará una oferta que no podrá comprender.
Además de ser incomprensible, otro problema con el modelo OSI es que algunas funciones como
el direccionamiento, el control de flujo y el control de errores, vuelven a aparecer una y otra vez en cada
capa. Por ejemplo, Saltzer y sus colaboradores (1984) han señalado que para ser efectivo, hay que llevar a
cabo el control de errores en la capa más alta, por lo que repetirlo una y otra vez en cada una de las capas
más bajas es con frecuencia innecesario e ineficiente.
Malas implementaciones
Dada la enorme complejidad del modelo y los protocolos, no es sorprendente que las implementaciones
iniciales fueran enormes, pesadas y lentas. Todos los que las probaron se arrepintieron. No tuvo que pasar
mucho tiempo para que las personas asociaran “OSI” con la “mala calidad”. Aunque los productos mejo-
raron con el tiempo, la imagen perduró.
En contraste, una de las primeras implementaciones de TCP/IP fue parte del UNIX, de Berkeley, y
era bastante buena (y además, gratuita). Las personas empezaron a utilizarla rápidamente, lo cual provocó
que se formara una extensa comunidad de usuarios, lo que condujo a mejoras, lo que llevó a una comuni-
dad todavía mayor. En este caso la espiral fue hacia arriba, en vez de ir hacia abajo.
Malas políticas
Gracias a la implementación inicial, mucha gente (en especial los académicos) pensaba que TCP/IP era
parte de UNIX, y UNIX en la década de 1980 para los académicos era algo así como la paternidad (que
en ese entonces se consideraba erróneamente como maternidad) y el pay de manzana para los estadouni-
denses comunes.
Por otro lado, OSI se consideraba en muchas partes como la invención de los ministerios europeos de
telecomunicaciones, de la Comunidad Europea y después, del gobierno de Estados Unidos. Esta creencia
no era del todo justificada, pero la simple idea de un grupo de burócratas gubernamentales que trataban de
obligar a los pobres investigadores y programadores que estaban en las trincheras desarrollando verda-
deras redes de computadoras a que adoptaran un estándar técnicamente inferior no fue de mucha utilidad
para la causa de OSI. Algunas personas vieron este suceso como algo similar a cuando IBM anunció en
la década de 1960 que PL/I era el lenguaje del futuro, o cuando luego el DoD corrigió esto para anunciar
que en realidad el lenguaje era Ada.
1.4.6 Una crítica al modelo de referencia TCP/IP
El modelo y los protocolos de TCP/IP también tienen sus problemas. Primero, el modelo no dife-
rencia con claridad los conceptos de servicios, interfaces y protocolos. La buena práctica de la ingeniería
www.FreeLibros.me
de software requiere una distinción entre la especificación y la implementación, algo que OSI hace con
mucho cuidado y que TCP/IP no. En consecuencia, el modelo TCP/IP no sirve mucho de guía para diseñar
modernas redes que utilicen nuevas tecnologías.
Segundo, el modelo TCP/IP no es nada general y no es muy apropiado para describir cualquier pila
de protocolos aparte de TCP/IP. Por ejemplo, es imposible tratar de usar el modelo TCP/IP para describir
Bluetooth.
Tercero, la capa de enlace en realidad no es una capa en el sentido normal del término como se utiliza
en el contexto de los protocolos en capas. Es una interfaz (entre las capas de red y de enlace de datos). La
diferencia entre una interfaz y una capa es crucial, y hay que tener mucho cuidado al respecto.
Cuarto, el modelo TCP/IP no distingue entre la capa física y la de enlace de datos. Éstas son comple-
tamente distintas. La capa física trata sobre las características de transmisión del cable de cobre, la fibra
óptica y la comunicación inalámbrica. La tarea de la capa de enlace de datos es delimitar el inicio y el fin
de las tramas, además de transmitirlas de un extremo al otro con el grado deseado de confiabilidad. Un
modelo apropiado debe incluir ambas capas por separado. El modelo TCP/IP no hace esto.
Por último, aunque los protocolos IP y TCP se diseñaron e implementaron con sumo cuidado, muchos
de los otros protocolos se fueron creando según las necesidades del momento, producidos generalmente
por un par de estudiantes de licenciatura que los mejoraban hasta fastidiarse. Después las implementacio-
nes de los protocolos se distribuían en forma gratuita, lo cual trajo como consecuencia que se utilizaran
amplia y profundamente en muchas partes y, por ende, eran difíciles de reemplazar. Algunos de ellos son
un poco vergonzosos en la actualidad. Por ejemplo, el protocolo de terminal virtual TELNET se diseñó
para una terminal de Teletipo mecánica de 10 caracteres por segundo. No sabe nada sobre las interfaces
gráficas de usuario y los ratones. Sin embargo, aún se sigue usando a 30 años de su creación.
1.5 REDES DE EJEMPLO
El tema de las redes de computadoras cubre muchos tipos distintos de redes, grandes y pequeñas, popula-
res y no tanto. Tienen distintos objetivos, escalas y tecnologías. En las siguientes secciones analizaremos
algunos ejemplos para tener una idea de la variedad que podemos encontrar en el área de las redes de
computadoras.
Empezaremos con Internet, que tal vez sea la red más popular; analizaremos su historia, evolución y
tecnología. Después consideraremos la red de teléfonos móviles. Técnicamente es muy distinta de Inter-
net y contrasta muy bien con ella. Más adelante introduciremos el IEEE 802.11, el estándar dominante
para las redes LAN inalámbricas. Por último, analizaremos las redes RFID y de sensores, tecnologías que
extienden el alcance de la red para incluir al mundo físico y los objetos cotidianos.
1.5.1 Internet
En realidad Internet no es una red, sino una enorme colección de distintas redes que utilizan ciertos pro-
tocolos comunes y proveen ciertos servicios comunes. Es un sistema inusual en cuanto a que nadie la
planeó y nadie la controla. Para comprender mejor esto, empecemos desde el inicio para ver cómo se ha
desarrollado y por qué. Si desea leer una maravillosa historia de Internet, le recomendamos ampliamente
el libro de Jim Naughton (2000). Es uno de esos libros inusuales que no sólo son divertidos, sino que tam-
bién cuenta con 20 páginas de ibídems y obras citadas (ob. cit.) para el verdadero historiador. Una parte
del material de esta sección se basa en ese libro.
Claro que también se han escrito innumerables libros sobre Internet y sus protocolos. Para obtener
más información puede consultar a Maufer (1999).
www.FreeLibros.me
SEC. 4.2 PROTOCOLOS DE ACCESO MÚltiple 225
4.2 PROTOCOLOS DE ACCESO MÚLTIPLE

Se conocen muchos algoritmos para asignar un canal de acceso múltiple. En las siguientes secciones estu-
diaremos una muestra representativa de los más interesantes y daremos algunos ejemplos de cómo se usan
comúnmente en la práctica.
4.2.1 ALOHA
La historia de nuestro primer MAC empieza en la prístina Hawai de principios de la década de 1970. En
este caso, podemos interpretar “prístina” como que “no tenía un sistema telefónico funcional”. Esto no
hizo la vida más placentera para el investigador Norman Abramson y sus colegas de la Universidad de
Hawai, quienes trataban de conectar a los usuarios en islas remotas a la computadora principal en Ho-
nolulu. Tender sus propios cables bajo el Océano Pacífico no era una opción viable, por lo que buscaron
una solución diferente.
La que encontraron utilizaba radios de corto rango, en donde cada terminal de usuario compar-
tía la misma frecuencia ascendente para enviar tramas a la computadora central. Incluía un método
simple y elegante para resolver el problema de asignación de canal. Desde entonces, su trabajo ha
sido extendido por muchos investigadores (Schwartz y Abramson, 2009). Aunque el trabajo de
Abramson, llamado sistema ALOHA, usó la radiodifusión basada en tierra, la idea básica es aplicable a
cualquier sistema en el que usuarios no coordinados compiten por el uso de un solo canal com-
partido.
Analizaremos dos versiones de ALOHA: puro y ranurado. Difieren en cuanto a si el tiempo es
continuo, como en la versión pura, o si se divide en ranuras discretas en las que deben caber todas las
tramas.
ALOHA puro
La idea básica de un sistema ALOHA es sencilla: permitir que los usuarios transmitan cuando tengan datos
por enviar. Por supuesto, habrá colisiones y las tramas en colisión se dañarán. Los emisores necesitan
alguna forma de saber si éste es el caso. En el sistema ALOHA, después de que cada estación envía su
trama a la computadora central, ésta vuelve a difundir la trama a todas las estaciones. Así, una estación
emisora puede escuchar la difusión de la estación terrena maestra (hub) para ver si pasó su trama o no.
En otros sistemas, como las LAN alámbricas, el emisor podría ser capaz de escuchar si hay colisiones
mientras transmite.
Si la trama fue destruida, el emisor simplemente espera un tiempo aleatorio y la envía de nuevo. El
tiempo de espera debe ser aleatorio o las mismas tramas chocarán una y otra vez, en sincronía. Los siste-
mas en los cuales varios usuarios comparten un canal común de modo tal que puede dar pie a conflictos
se conocen como sistemas de contención.
En la figura 4-1 se presenta un esbozo de la generación de tramas en un sistema ALOHA. Hemos
hecho que todas las tramas sean de la misma longitud porque la velocidad real de transmisión
(throughput) de los sistemas ALOHA se maximiza al tener tramas con un tamaño uniforme en lugar de
tramas de longitud variable.
Cada vez que dos tramas traten de ocupar el canal al mismo tiempo, habrá una colisión (como se
muestra en la figura 4-1) y ambas se dañarán. Si el primer bit de una trama nueva se traslapa con el último
bit de una trama casi terminada, ambas se destruirán por completo (es decir, tendrán sumas de verificación
incorrectas) y ambas tendrán que volver a transmitirse más tarde. La suma de verificación no distingue (y
no debe) entre una pérdida total y un error ligero. Lo malo es malo.
www.FreeLibros.me
226 LA SUBCAPA DE CONTROL DE ACCESO AL MEDIO CAP. 4
Usuario
Colisión Tiempo Colisión
Figura 4-1. En ALOHA puro, las tramas se transmiten en tiempos completamente arbitrarios.
Hay una pregunta interesante: ¿cuál es la eficiencia de un canal ALOHA? En otras palabras, ¿qué
fracción de todas las tramas transmitidas escapa a las colisiones en estas caóticas circunstancias? Primero
consideremos un conjunto infinito de usuarios escribiendo en sus terminales (estaciones). Un usuario
siempre está en uno de dos estados: escribiendo o esperando. Al principio todos los usuarios están en el
estado de escritura. Al terminar una línea, el usuario deja de escribir, en espera de una respuesta. Después,
la estación transmite una trama (que contiene la línea) a través del canal compartido hasta la computadora
central y verifica el canal para saber si llegó con éxito. De ser así, el usuario ve la respuesta y continúa
escribiendo. Si no, el usuario continúa esperando mientras la estación transmite la trama una y otra vez
hasta que se envía con éxito.
Hagamos que el “tiempo de trama” denote el tiempo necesario para transmitir la trama estándar de
longitud fija (es decir, la longitud de la trama dividida entre la tasa de bits). En este punto, suponemos que
las tramas nuevas generadas por las estaciones están bien modeladas según una distribución de Poisson con
una media de N tramas por tiempo de trama (la suposición de población infinita es necesaria para asegurar
que N no disminuya a medida que se bloquean los usuarios). Si N  1, la comunidad de usuarios está
generando tramas a una tasa mayor que la que puede manejar el canal, y casi todas las tramas sufrirán una
colisión. Para una velocidad de transmisión razonable esperaríamos que 0  N  1.
Además de las nuevas tramas, las estaciones también generan retransmisiones de tramas que con an-
terioridad sufrieron colisiones. Supongamos también que las tramas nuevas y antiguas combinadas están
bien modeladas según una distribución de Poisson, con una media de G tramas por tiempo de trama. Es
evidente que G  N. Con carga baja (es decir, N ≈ 0) habrá pocas colisiones y, por lo tanto, pocas retrans-
misiones, por lo que G ≈ N. Con carga alta habrá muchas colisiones, por lo que G  N. Con todas las
cargas, la velocidad real de transmisión S es sólo la carga ofrecida, G, multiplicada por la probabilidad,
P0, de que una transmisión tenga éxito (es decir, S 5 GP0, donde P0 es la probabilidad de que una trama no
sufra una colisión).
Una trama no sufrirá una colisión si no se envían otras tramas durante un tiempo de trama desde su
envío, como se muestra en la figura 4-2. ¿Bajo qué condiciones llegará sin daño la trama sombreada? Sea
t el tiempo requerido para enviar una trama. Si cualquier otro usuario generó una trama entre el tiempo t0
y t0 1 t, el final de esa trama colisionará con el comienzo de la trama sombreada. De hecho, el destino de
la trama sombreada está sentenciado aun antes de enviar el primer bit pero, dado que en ALOHA puro
una estación no escucha el canal antes de transmitir, no tiene manera de saber que otra trama ya está en
camino. Asimismo, cualquier otra trama que se inicie entre t0 1 t y t0 1 2t chocará con el final de la trama
sombreada.
www.FreeLibros.me
Colisiona con Colisiona con

el inicio de el final de
la trama t la trama
sombreada sombreada
t0 t0+ t t0+ 2t t0+ 3t Tiempo

Vulnerable
Figura 4-2. Periodo vulnerable para la trama sombreada.
La probabilidad de que se generen k tramas durante un tiempo de trama determinado, en donde se

esperan G tramas, está dada por la distribución de Poisson:
(4-2)

así, la probabilidad de cero tramas es simplemente e −G. En un intervalo de dos tiempos de trama
de longitud, el número promedio de tramas generadas es de 2G. La probabilidad de que no se ini-
cien tramas durante todo el periodo vulnerable está dada entonces por P0 5 e −2G. Si S 5 GP0, obte-
nemos:
S 5 Ge22G
En la figura 4-3 se muestra la relación entre el tráfico ofrecido y la velocidad real de transmisión. La
máxima velocidad real de transmisión ocurre cuando G 5 0.5, con S 5 1/2e, que es alrededor de 0.184.
En otras palabras, lo más que podemos esperar es un uso del canal de 18%. Este resultado no es muy
alentador, pero con todo mundo transmitiendo al azar, difícilmente podríamos esperar una tasa de éxito
de 100%.
S (velocidad real de transmisión
por tiempo de trama)
0.40
ALOHA ranurado: S = Ge–G
0.30
0.20
0.10 ALOHA puro: S = Ge–2G
0 0.5 1.0 1.5 2.0 3.0

G (intentos por tiempo de paquete)
Figura 4-3. Velocidad real de transmisión contra tráfico ofrecido en los sistemas ALOHA.
www.FreeLibros.me
ALOHA ranurado
Poco después de que ALOHA apareció en escena, Roberts (1972) publicó un método para duplicar la
capacidad de un sistema ALOHA. Su propuesta fue dividir el tiempo en intervalos discretos llamados ra-
nuras, cada uno de los cuales correspondía a una trama. Este método requiere que los usuarios acuerden
límites de ranura. Una manera de lograr la sincronización sería tener una estación especial que emitiera
una señal al comienzo de cada intervalo, como un reloj.
En el método de Roberts, que se conoce como ALOHA ranurado, en contraste con el ALOHA puro
de Abramson, no se permite que una estación envíe cada vez que el usuario escribe una línea. En cambio,
se le obliga a esperar el comienzo de la siguiente ranura. Por lo tanto, el ALOHA de tiempo continuo se
convierte en uno de tiempo discreto. Esto reduce el periodo vulnerable a la mitad. Para ver esto, analice
la figura 4-3 e imagine las colisiones que puede haber ahora. La probabilidad de que no haya más tráfico
durante la misma ranura que nuestra trama de prueba es entonces de e−G, lo que conduce a
S 5 Ge (4-3)
2G
Como podemos ver en la figura 4-3, el ALOHA ranurado alcanza su máximo valor en G 5 1, con una
velocidad real de transmisión de S 5 1/e, o aproximadamente 0.368, el doble que el ALOHA puro. Si el
sistema está operando a G 5 1, la probabilidad de una ranura vacía es de 0.368 (de la ecuación 4-2). Lo
mejor que podemos esperar usando ALOHA ranurado es 37% de ranuras vacías, 37% de éxitos y 26% de
colisiones. Si se opera con valores mayores de G se reduce el número de ranuras vacías pero aumenta
de manera exponencial el número de colisiones. Para ver la manera en que se desarrolla este rápido
crecimiento de colisiones con G, considere la transmisión de una trama de prueba. La probabilidad de
que evitará una colisión es de e2G, que es la probabilidad de que las demás estaciones estén en silencio
durante esa ranura. La probabilidad de una colisión es entonces de sólo 1 − e2G. La probabilidad de que
una transmisión requiera exactamente k intentos (es decir, k − 1 colisiones seguidas de un éxito) es
El número esperado de transmisiones, E, por cada línea que se introduce en la terminal es
Como resultado de la dependencia exponencial de E respecto a G, pequeños aumentos en la carga del

canal pueden reducir drásticamente su desempeño.
El Aloha ranurado es importante por una razón que al principio tal vez no sea obvia. Se diseñó
en la década de 1970 y se utilizó en algunos sistemas experimentales iniciales, después casi se olvidó
por completo. Cuando se inventó el acceso a Internet a través de cable, de repente surgió el problema
de cómo asignar un canal compartido entre varios usuarios competidores. El ALOHA ranurado prác-
ticamente se sacó del cesto de la basura para resolver el problema. Posteriormente, hacer que varias
etiquetas RFID se comunicaran con el mismo lector RFID presentó otra variación del mismo pro-
blema. De nuevo salió al rescate el ALOHA ranurado, con unas cuantas ideas más mezcladas. Con
frecuencia sucede que los protocolos que son perfectamente válidos caen en desuso por razones
políticas (por ejemplo, alguna compañía grande desea que todos hagan las cosas a su manera) o
debido a las tendencias siempre cambiantes de la tecnología. Después, años más tarde alguna persona
astuta se dio cuenta de que un protocolo descartado por mucho tiempo es el que podía sacarlo de su
problema actual. Por esta razón, en este capítulo estudiaremos varios protocolos elegantes que en
la actualidad no se utilizan mucho, pero que podrían utilizarse fácilmente en aplicaciones futuras,
www.FreeLibros.me
siempre y cuando los conozcan suficientes diseñadores de red. Por supuesto, también estudiaremos
varios protocolos que se utilizan en la actualidad.
4.2.2 Protocolos de acceso múltiple con detección de portadora
Con el ALOHA ranurado, el mejor aprovechamiento de canal que se puede lograr es 1/e. Este resultado
tan bajo no es muy sorprendente pues, con estaciones que transmiten a voluntad propia, sin prestar aten-
ción a lo que están haciendo las demás estaciones, es inevitable que haya muchas colisiones. Sin embargo,
en las redes LAN es posible que las estaciones detecten lo que están haciendo las demás estaciones y
adapten su comportamiento con base en ello. Estas redes pueden lograr una utilización mucho mejor que
1/e. En esta sección estudiaremos algunos protocolos para mejorar su desempeño.
Los protocolos en los que las estaciones escuchan una portadora (es decir, una transmisión) y actúan
de manera acorde se llaman protocolos de detección de portadora. Se han propuesto varios de ellos y
hace mucho tiempo se analizaron con detalle. Por ejemplo, consulte a Kleinrock y Tobagi (1975). A con-
tinuación mencionaremos varias versiones de los protocolos de detección de portadora.
CSMA persistente y no persistente
El primer protocolo de detección de portadora que estudiaremos aquí se llama CSMA (Acceso Múltiple
con Detección de Portadora, del inglés Carrier Sense Multiple Access) persistente-1. Es un nombre
bastante largo para el esquema CSMA más simple. Cuando una estación tiene datos por enviar, primero
escucha el canal para saber si alguien más está transmitiendo en ese momento. Si el canal está inactivo, la
estación envía sus datos. Por el contrario, si el canal está ocupado, la estación espera hasta que se desocupa.
A continuación, la estación transmite una trama. Si ocurre una colisión, la estación espera una cantidad
aleatoria de tiempo y comienza de nuevo. El protocolo se llama persistente-1 porque la estación transmite
con una probabilidad de 1 cuando encuentra que el canal está inactivo.
Podría esperarse que este esquema evite las colisiones, excepto en el extraño caso de los envíos
simultáneos, pero de hecho no lo hace. Si dos estaciones están listas a la mitad de la transmisión de
una tercera estación, ambas esperarán amablemente hasta que termine la transmisión y después ambas
empezarán a transmitir exactamente al mismo tiempo, lo cual producirá una colisión. Si no fueran tan
impacientes, habría menos colisiones.
Otro aspecto delicado es que el retardo de propagación tiene un efecto importante sobre las colisiones.
Existe la posibilidad de que, justo después de que una estación comienza a transmitir, otra estación esté
lista para enviar y detecte el canal. Si la señal de la primera estación no ha llegado aún a la segunda,
esta última detectará un canal inactivo y comenzará también a enviar, lo que dará como resultado una
colisión. Esta posibilidad depende del número de tramas que quepan en el canal, o producto de ancho de
banda-retardo del canal. Si sólo cabe una pequeña fracción de una trama en el canal, lo cual es cierto en
la mayoría de las redes LAN, ya que el retardo de propagación es pequeño, la posibilidad de que ocurra
una colisión es pequeña. Cuanto mayor sea el producto de ancho de banda-retardo, más importante será
este efecto y peor el desempeño del protocolo.
Aun así, este protocolo tiene un mejor desempeño que el ALOHA puro, ya que ambas estaciones tie-
nen la decencia de dejar de interferir con la trama de la tercera estación. Lo mismo se aplica en el ALOHA
ranurado.
Un segundo protocolo de detección de portadora es el CSMA no persistente. En este protocolo
se hace un intento consciente por ser menos egoísta que en el previo. Como antes, una estación escucha
el canal cuando desea enviar una trama y, si nadie más está transmitiendo, comienza a hacerlo. Pero si el
canal ya está en uso, la estación no lo escuchará de manera continua con el fin de tomarlo de inmediato al
www.FreeLibros.me
detectar el final de la transmisión anterior, sino que esperará un periodo aleatorio y repetirá el algoritmo.
En consecuencia, este algoritmo conduce a un mejor uso del canal pero produce mayores retardos que el
CSMA persistente-1.
El último protocolo es el CSMA persistente-p, que se aplica a canales ranurados y funciona como
se explica a continuación. Cuando una estación está lista para enviar, escucha el canal. Si se encuentra
inactivo, la estación transmite con una probabilidad p. Con una probabilidad q 5 1 2 p, se posterga hasta
la siguiente ranura. Si esa ranura también está inactiva, la estación transmite o posterga una vez más,
con probabilidades p y q. Este proceso se repite hasta que se transmite la trama o hasta que otra estación
comienza a transmitir. En el segundo caso, la desafortunada estación actúa como si hubiera ocurrido una
colisión (es decir, espera un tiempo aleatorio y comienza de nuevo). Si al principio la estación detecta que
el canal está ocupado, espera hasta la siguiente ranura y aplica el algoritmo anterior. El estándar IEEE
802.11 usa una versión refinada del CSMA persistente-p que veremos en la sección 4.4.
En la figura 4-4 se muestra la velocidad real de transmisión calculada contra el tráfico ofrecido para
los tres protocolos, así como para el ALOHA puro y el ranurado.
CSMA persistente-0.01
1.0
0.9 CSMA no persistente
S (velocidad real de transmisión
0.8 CSMA persistente-0.1

por tiempo de paquete)
0.7
0.6 CSMA
persistente-0.5
0.5
ALOHA
0.4 ranurado
0.3 CSMA
ALOHA persistente-1
0.2
puro
0.1
0
0 1 2 3 4 5 6 7 8 9
G (intentos por tiempo de paquete)
Figura 4-4. Comparación de la utilización del canal contra la carga para varios protocolos de acceso aleatorio.
CSMA con detección de colisiones
En definitiva, los protocolos CSMA persistentes y no persistentes son una mejora respecto a ALOHA
porque aseguran que ninguna estación empezará a transmitir mientras el canal esté ocupado. Pero si dos
estaciones detectan que el canal está inactivo y empiezan a transmitir al mismo tiempo, sus señales de
todas formas sufrirán una colisión. Otra mejora es que las estaciones detecten rápidamente la colisión
y dejen de transmitir de inmediato (en vez de terminadas las transmisiones), ya que de todas formas se
alterarán y no se podrán recuperar. Esta estrategia ahorra tiempo y ancho de banda.
Este protocolo, conocido como CSMA/CD (CSMA con Detección de Colisiones, del inglés CSMA
with Collision Detection), es la base de la clásica LAN Ethernet, por lo que vale la pena dedicar un poco
de tiempo a analizarlo con detalle. Es importante tener en cuenta que la detección de colisiones es un
proceso analógico. El hardware de la estación debe escuchar el canal mientras transmite. Si la señal que
recibe es distinta de la señal que está enviando, sabe que está ocurriendo una colisión. Las implicaciones
son que una señal recibida no debe ser pequeña en comparación con la señal transmitida (lo cual es difícil
en las redes inalámbricas, ya que las señales recibidas pueden ser 1 000 000 de veces más débiles que las
www.FreeLibros.me
señales transmitidas) y que la modulación se debe elegir de modo que permita detectar colisiones (por
ejemplo, tal vez sea imposible detectar una colisión de dos señales de 0 volts).
Al igual que muchos otros protocolos de LAN, CSMA/CD utiliza el modelo conceptual de la
figura 4-5. En el punto marcado como t0, una estación ha terminado de transmitir su trama. Cualquier
otra estación que tenga una trama por enviar puede intentar hacerlo ahora. Si dos o más estaciones
deciden transmitir en forma simultánea, habrá una colisión. Si una estación detecta una colisión, aborta
la transmisión, espera un tiempo aleatorio e intenta de nuevo (suponiendo que ninguna otra estación
ha comenzado a transmitir durante ese lapso). Por lo tanto, nuestro modelo de CSMA/CD consistirá
en periodos alternantes de contención y transmisión, con periodos de inactividad que ocurrirán cuando
todas las estaciones estén en reposo (por ejemplo, por falta de trabajo).
Ranuras de
to contención
Trama Trama Trama Trama
Periodo de Periodo de Periodo de

transmisión contención inactividad
Tiempo
Figura 4-5. CSMA/CD puede estar en estado de contención, de transmisión o inactivo.
Ahora observemos con cuidado los detalles del algoritmo de contención. Suponga que dos estacio-
nes comienzan a transmitir exactamente en el momento t0. ¿En cuánto tiempo se darán cuenta de que ha
ocurrido una colisión? La respuesta a esta pregunta es vital para determinar la longitud del periodo de
contención y, por lo tanto, el retardo y la velocidad real de transmisión.
El tiempo mínimo para detectar la colisión es tan sólo el tiempo que tarda la señal en propagarse
de una estación a otra. Con base en esta información, podríamos pensar que una estación que no ha
detectado una colisión durante un periodo igual al tiempo completo de propagación del cable des-
pués de iniciar su transmisión puede estar segura de que ha tomado el cable. Por “tomado” queremos
decir que todas las demás estaciones saben que está transmitiendo y no interferirán. Esta conclusión
es errónea.
Considere el siguiente escenario en el peor caso. Sea τ el tiempo que tarda una señal en propagarse
entre las dos estaciones más lejanas. En t0, una estación comienza a transmitir. En t0 1 τ 2 ε, un instante
antes de que la señal llegue a la estación más lejana, esa estación también comienza a transmitir. Por su-
puesto que detecta la colisión casi de inmediato y se detiene, pero la pequeña ráfaga de ruido causada por la
colisión no regresa a la estación original, sino hasta el tiempo 2τ 2 ε. En otras palabras, en el peor caso
una estación no puede estar segura de que ha tomado el canal hasta que ha transmitido durante 2τ sin
detectar una colisión.
Con este razonamiento, podemos pensar en la contención de CSMA/CD como un sistema ALOHA
ranurado con un ancho de ranura de 2τ. En un cable coaxial de 1 km de longitud, τ ≈ 5 μseg. La diferen-
cia para CSMA/CD en comparación con ALOHA ranurado es que las ranuras en las que sólo transmite
una estación (por ejemplo, la que tomó el canal) van seguidas del resto de una trama. Esta diferencia
mejorará en forma considerable el desempeño si el tiempo de la trama es mucho mayor que el tiempo
de propagación.
www.FreeLibros.me
4.2.3 Protocolos libres de colisiones
Aunque las colisiones no ocurren en CSMA/CD una vez que una estación ha capturado el canal sin
ambigüedades, aún pueden ocurrir durante el periodo de contención. Estas colisiones afectan en forma
adversa el desempeño del sistema, en especial cuando el producto ancho de banda-retardo es grande,
como cuando el cable es largo (es decir, τ es grande) y las tramas son cortas. Las colisiones no sólo
reducen el ancho de banda, sino que también hacen variable el tiempo de envió de una trama, lo cual
no es bueno para el tráfico en tiempo real tal como la voz sobre IP. Además, CSMA/CD no se puede
aplicar en forma universal.
En esta sección examinaremos algunos protocolos que resuelven la contención por el canal sin que
haya colisiones, ni siquiera durante el periodo de contención. En la actualidad, la mayoría de estos pro-
tocolos no se utilizan en los sistemas grandes, pero en un campo en constante cambio, el hecho de tener
algunos protocolos con excelentes propiedades disponibles para sistemas futuros es con frecuencia algo
bueno.
En los protocolos que describiremos supondremos que hay exactamente N estaciones, cada una pro-
gramada con una dirección única de 0 a N 2 1. No importa el hecho de que algunas estaciones puedan
estar inactivas una parte del tiempo. También damos por hecho que el retardo de propagación es insigni-
ficante. La pregunta básica persiste: ¿qué estación obtiene el canal después de una transmisión exitosa?
Seguimos usando el modelo de la figura 4-5 con sus ranuras de contención discretas.
Un protocolo de mapa de bits
En nuestro primer protocolo libre de colisiones, el método básico de mapa de bits, cada periodo de
contención consiste exactamente de N ranuras. Si la estación 0 tiene una trama por enviar, transmite un
bit 1 durante la ranura 0. No está permitido a ninguna otra estación transmitir durante esta ranura. Sin
importar lo que haga la estación 0, la estación 1 tiene la oportunidad de transmitir un bit 1 durante la
ranura 1, pero sólo si tiene una trama puesta en la cola. En general, la estación j puede anunciar que tiene
una trama por enviar, para lo cual inserta un bit 1 en la ranura j. Una vez que han pasado las N ranuras,
cada estación tiene un completo conocimiento acerca de cuáles son las estaciones que quieren transmitir.
En ese punto, las estaciones empiezan a transmitir en orden numérico (vea la figura 4-6).
Tramas
8 ranuras de contención 8 ranuras de contención 1 d
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
1 1 1 1 3 7 1 1 1 5 1 2
Figura 4-6. El protocolo básico de mapa de bits.
Como todos están de acuerdo en quién sigue a continuación, nunca habrá colisiones. Una vez que
la última estación lista haya transmitido su trama, un evento que pueden detectar fácilmente todas las
estaciones, comienza otro periodo de contención de N bits. Si una estación está lista justo después de que
ha pasado su ranura de bit, ha tenido mala suerte y deberá permanecer inactiva hasta que cada una de las
demás estaciones haya tenido su oportunidad y el mapa de bits haya comenzado de nuevo.
Los protocolos como éste en los que el interes de transmitir se difunde antes de la transmisión se
llaman protocolos de reservación, debido a que reservan la propiedad del canal por anticipado y evitan
www.FreeLibros.me
El MACA se ilustra en la figura 4-12. Consideremos ahora la manera en que A envía una trama a
B. A comienza enviando una trama RTS (Solicitud de Envío, del inglés Request To Send) a B, como se
muestra en la figura 4-12(a). Esta trama corta (30 bytes) contiene la longitud de la trama de datos que
seguirá después. Después B contesta con una trama CTS (Libre para Envío, del inglés Clear To Send ),
como se muestra en la figura 4-12(b). La trama CTS contiene la longitud de los datos (que copia de la
trama RTS). Al recibir la trama CTS, A comienza a transmitir.
Rango del transmisor de Rango del transmisor de
C A RTS B D C A CTS B D
E E
(a) (b)
Figura 4-12. El protocolo MACA. (a) A envía un RTS a B. (b) B responde con un CTS a A.
Ahora veamos cómo reaccionan las estaciones que escuchan cualquiera de estas tramas. Sin duda,
cualquier estación que escuche el RTS está bastante cerca de A y debe permanecer en silencio durante el
tiempo suficiente para que el CTS se transmita de regreso a A sin conflicto. Es evidente que cualquier
estación que escuche el CTS está bastante cerca de B y debe permanecer en silencio durante la siguiente
transmisión de datos, cuya longitud puede determinar examinando la trama CTS.
En la figura 4-12, C está en el alcance de A pero no en el alcance de B. Por lo tanto, escucha el RTS
de A pero no el CTS de B. En tanto no interfiera con el CTS, está libre para transmitir mientras se envía la
trama de datos. En contraste, D está en el alcance de B pero no de A. No escucha el RTS pero sí el CTS.
Al escuchar el CTS sabe que está cerca de una estación que está a punto de recibir una trama, por lo
que difiere el envío de cualquier cosa hasta el momento en que se espera la terminación de esa trama. La
estación E escucha ambos mensajes de control y, al igual que D, debe permanecer en silencio hasta que se
haya completado la trama de datos.
A pesar de estas precauciones, aún pueden ocurrir colisiones. Por ejemplo, B y C podrían enviar tra-
mas RTS a A al mismo tiempo. Éstas chocarán y se perderán. En el caso de una colisión, un transmisor sin
éxito (es decir, uno que no escucha un CTS en el intervalo esperado) espera un tiempo aleatorio y vuelve
a intentar más tarde.
4.3 ETHERNET
Hemos finalizado nuestra discusión general sobre los protocolos de asignación de canal, por lo que es
tiempo de ver la forma en que estos principios se aplican a sistemas reales. Muchos de los diseños para
las redes personales, locales y de área metropolitana se han estandarizado bajo el nombre de IEEE 802.
Algunos han sobrevivido pero muchos no, como vimos en la figura 1-38. Quienes creen en la reencarna-
www.FreeLibros.me
SEC. 4.3 ethernet 241
ción piensan que Charles Darwin regresó como miembro de la Asociación de estándares del IEEE para
eliminar a los débiles. Los sobrevivientes más importantes son el 802.3 (Ethernet) y el 802.11 (LAN
inalámbrica). Bluetooth (PAN inalámbrica) se utiliza mucho en la actualidad, pero se estandarizó fuera
del 802.15. Todavía es muy pronto para decir algo sobre el 802.16 (MAN inalámbrica). Le sugerimos que
consulte la sexta edición de este libro para averiguarlo.
Empezaremos nuestro estudio de los sistemas reales con Ethernet, que probablemente sea el tipo más
ubicuo de red de computadoras en el mundo. Existen dos tipos de Ethernet: Ethernet clásica, que resuel-
ve el problema de acceso múltiple mediante el uso de las técnicas que hemos estudiado en este capítulo;
el segundo tipo es la Ethernet conmutada, en donde los dispositivos llamados switches se utilizan para
conectar distintas computadoras. Es importante mencionar que, aunque se hace referencia a ambas como
Ethernet, son muy diferentes. La Ethernet clásica es la forma original que operaba a tasas de transmisión
de 3 a 10 Mbps. La Ethernet conmutada es en lo que se convirtió la Ethernet y opera a 100, 1 000 y 10 000 Mbps,
en formas conocidas como Fast Ethernet, Gigabit Ethernet y 10 Gigabit Ethernet. Actualmente, en la
práctica sólo se utiliza Ethernet conmutada.
Analizaremos estas formas históricas de Ethernet en orden cronológico para mostrar cómo se desarrolla-
ron. Puesto que Ethernet y el IEEE 802.3 son idénticos, excepto por una pequeña diferencia (que veremos
en breve), muchas personas usan los términos “Ethernet” e “IEEE 802.3” sin distinción. Nosotros también
lo haremos. Para obtener más información sobre Ethernet, consulte a Spurgeon (2000).
4.3.1 Capa física de Ethernet clásica
La historia de Ethernet empieza casi al mismo tiempo que ALOHA, cuando un estudiante llamado Bob
Metcalfe obtuvo su licenciatura en el MIT y después obtuvo su doctorado en Harvard. Durante sus es-
tudios oyó hablar del trabajo de Abramson. Se interesó tanto en él que, después de graduarse de Harvard,
decidió pasar el verano en Hawai trabajando con Abramson antes de empezar a trabajar en Xerox PARC
(Palo Alto Research Center). Cuando llegó a PARC, vio que los investigadores ahí habían diseñado y
construido lo que después se conocería como computadora personal. Pero las máquinas estaban aisladas.
Haciendo uso de su conocimiento sobre el trabajo de Abramson, junto con su colega David Boggs dise-
ñó e implementó la primera red de área local (Metcalfe y Boggs, 1976). Esta red utilizaba un solo cable
coaxial grueso y extenso; operaba a 3 Mbps.
Llamaron al sistema Ethernet en honor al éter luminífero, por medio del cual se pensaba antes que se
propagaba la radiación electromagnética (cuando el físico inglés del siglo xix James Clerk Maxwell descubrió
que la radiación electromagnética se podía describir mediante una ecuación de onda, los científicos asu-
mieron que el espacio debía estar lleno de algún medio etéreo en el que se propagaba la radiación. No fue
sino hasta después del famoso experimento de Michelson-Morley en 1887 que los físicos descubrieron
que la radiación electromagnética se podía propagar en un vacío).
La Xerox Ethernet fue tan exitosa que DEC, Intel y Xerox idearon un estándar en 1978 para una
Ethernet de 10 Mbps, conocido como estándar DIX. Con una modificación menor, el estándar DIX se
convirtió en el estándar IEEE 802.3 en 1983. Por desgracia para Xerox, ya contaba con un historial de
hacer inventos seminales (como la computadora personal) y después fracasar en su comercialización, una
historia contada en la publicación Fumbling the Future (Smith y Alexander, 1988). Cuando Xerox mostró
poco interés en hacer algo con Ethernet aparte de ayudar a estandarizarla, Metcalfe formó su propia
empresa llamada 3Com para vender adaptadores de Ethernet para PC. Vendió muchos millones de ellos.
La Ethernet clásica se tendía alrededor del edificio como un solo cable largo al que se conectaban
todas las computadoras. Esta arquitectura se muestra en la figura 4-13. La primera variedad, conocida
popularmente como Ethernet gruesa, se asemejaba a una manguera de jardín amarilla, con marcas cada
2.5 metros para mostrar en dónde conectar las computadoras (el estándar 802.3 en realidad no requería
www.FreeLibros.me
que el cable fuera amarillo, pero sí lo sugería). Después le siguió la Ethernet delgada, que se doblaba con
más facilidad y las conexiones se realizaban mediante conectores BNC. La Ethernet delgada era mucho más
económica y fácil de instalar, pero sólo se podían tender 185 metros por segmento (en vez de los 500 m con
la Ethernet gruesa), cada uno de los cuales sólo podía manejar 30 máquinas (en vez de 100).
Cada versión de Ethernet tiene una longitud de cable máxima por segmento (es decir, longitud sin
amplificar) a través de la cual se propagará la señal. Para permitir redes más grandes, se pueden conectar
varios cables mediante repetidores. Un repetidor es un dispositivo de capa física que recibe, amplifica (es
decir, regenera) y retransmite las señales en ambas direcciones. En cuanto a lo que al software concierne,
una serie de segmentos de cable conectados por repetidores no presenta ninguna diferencia en compara-
ción con un solo cable (excepto por una pequeña cantidad de retardo que introducen los repetidores).
Transceptor
Cable de
interfaz
Cable
Figura 4-13. Arquitectura de Ethernet clásica.
La información se enviaba a través de cada uno de estos cables mediante la codificación Man-
chester que estudiamos en la sección 2.5. Una Ethernet podía contener varios segmentos de cable y
múltiples repetidores, pero no podía haber dos transceptores separados por más de 2.5 km, y no podía
haber una trayectoria entre dos transceptores en la que se colocaran más de cuatro repetidores. La razón
de esta restricción era para que el protocolo MAC (que veremos a continuación) pudiera funcionar de
manera correcta.
4.3.2 El protocolo de subcapa MAC de la Ethernet clásica
El formato utilizado para enviar tramas se muestra en la figura 4-14. Primero viene un Preámbulo de 8 bytes,
cada uno de los cuales contiene el patrón de bits 10101010 (con la excepción del último byte, en el que los
últimos 2 bits se establecen a 11). Este último byte se llama delimitador de Inicio de trama en el 802.3. La
codificación de Manchester de este patrón produce una onda cuadrada de 10 MHz durante 6.4 μseg para
permitir que el reloj del receptor se sincronice con el del emisor. Los últimos dos bits indican al receptor
que está a punto de empezar el resto de la trama.
Bytes 8 6 6 2 0-1500 0-46 4
Dirección Dirección Suma de

(a) Preámbulo Tipo Datos Relleno
de destino de origen verificación
Dirección Dirección Suma de

(b) Preámbulo Longitud Datos Relleno
de destino de origen verificación
Figura 4-14. Formatos de trama. (a) Ethernet (DIX). (b) IEEE 802.3.
www.FreeLibros.me
Después vienen dos direcciones, una para el destino y una para el origen. Cada una de ellas tiene una
longitud de 6 bytes. El primer bit transmitido de la dirección de destino es un 0 para direcciones ordina-
rias y un 1 para direcciones de grupo. Las direcciones de grupo permiten que varias estaciones escuchen
en una sola dirección. Cuando una trama se envía a una dirección de grupo, todas las estaciones del
grupo la reciben. El envío a un grupo de estaciones se llama multidifusión (multicasting). La dirección
especial que consiste únicamente en bits 1 está reservada para difusión (broadcasting). Una trama que
contiene sólo bits 1 en el campo de destino se acepta en todas las estaciones de la red. La multidifusión es más
selectiva, pero involucra el manejo de grupos para definir qué estaciones están en un grupo. Por el contrario,
la difusión no hace ninguna diferencia entre las estaciones, por lo que no requiere manejo de grupos.
Una característica interesante de las direcciones de origen de las estaciones es que son globalmente
únicas; el IEEE las asigna de manera central para asegurar que no haya dos estaciones en el mundo con
la misma dirección. La idea es que cualquier estación pueda direccionar de manera exclusiva cualquier
otra estación con sólo dar el número correcto de 48 bits. Para hacer esto, se utilizan los primeros 3 bytes
del campo de dirección para un OUI (Identificador Único Organizacional, del inglés Organizationally
Unique Identifier). El IEEE asigna los valores para este campo, e indican un fabricante. A los fabricantes
se les asignan bloques de 224 direcciones. El fabricante asigna los últimos 3 bytes de la dirección y pro-
grama la dirección completa en la NIC antes de venderla.
A continuación está el campo Tipo o Longitud, dependiendo de si la trama es Ethernet o IEEE 802.3.
Ethernet usa un campo Tipo para indicar al receptor qué hacer con la trama. Es posible utilizar múltiples
protocolos de capa de red al mismo tiempo en la misma máquina, por lo que cuando llega una trama de
Ethernet, el sistema operativo tiene que saber a cuál entregarle la trama. El campo Tipo especifica a qué
proceso darle la trama. Por ejemplo, un código de tipo de 0x0800 significa que los datos contienen un
paquete IPv4.
Gracias a su sabiduría, el IEEE 802.3 decidió que este campo transportaría la longitud de la trama,
ya que para determinar la longitud de Ethernet había que ver dentro de los datos; una violación del uso de
capas, si alguna vez la hubo. Desde luego que esto significaba que no había forma de que el receptor ave-
riguara qué hacer con una trama entrante. Para resolver ese problema se agregó otro encabezado para el
protocolo LLC (Control de Enlace Lógico, del inglés Logical Link Control ) dentro de los datos. Utiliza
8 bytes para transportar los 2 bytes de información del tipo del protocolo.
Por desgracia, para cuando se publicó el estándar 802.3, había ya tanto hardware y software para
DIX Ethernet en uso que pocos fabricantes y usuarios se esforzaron en reempaquetar los campos Tipo
y Longitud. En 1997, el IEEE desistió y dijo que estaba bien usar ambas formas. Por fortuna, todos los
campos Tipo que se usaban antes de 1997 tenían valores mayores que 1500, que estaba bien establecido
como el máximo tamaño de datos. Ahora la regla es que cualquier número ahí que sea menor o igual a
0x600 (1536) se puede interpretar como Longitud, y cualquier número mayor de 0x600 se puede inter-
pretar como Tipo. Ahora el IEEE puede sostener que todos usan su estándar y que todos los demás pueden
seguir haciendo lo que ya estaban haciendo (ignorar el LLC) sin sentires culpables al respecto.
Después están los datos, de hasta 1500 bytes. Este límite fue elegido de manera algo arbitraria cuando
se estableció el estándar Ethernet, sobre todo con base en el hecho de que un transceptor necesita sufi-
ciente RAM para mantener toda una trama y la RAM era muy costosa en 1978. Un mayor límite superior
podría haber significado más RAM y, por ende, un transceptor más costoso.
Además de haber una longitud de trama máxima, también hay una longitud mínima. Si bien algunas
veces un campo de datos de 0 bytes es útil, causa problemas. Cuando un transceptor detecta una colisión,
trunca la trama actual, lo que significa que los bits perdidos y las piezas de las tramas aparecen todo el
tiempo en el cable. Para que Ethernet pueda distinguir con facilidad las tramas válidas de lo inservible,
necesita que dichas tramas tengan una longitud de por lo menos 64 bytes, de la dirección de destino a
la suma de verificación, incluyendo ambas. Si la porción de datos de una trama es menor que 46 bytes, el
campo de Relleno se utiliza para completar la trama al tamaño mínimo.
www.FreeLibros.me
Otra razón (más importante) para tener una trama de longitud mínima es evitar que una estación
complete la transmisión de una trama corta antes de que el primer bit llegue al extremo más alejado
del cable, donde podría tener una colisión con otra trama. Este problema se ilustra en la figura 4-15. En
el tiempo 0, la estación A, en un extremo de la red, envía una trama. Llamemos τ al tiempo que tarda
en llegar esta trama al otro extremo. Justo antes de que la trama llegue al otro extremo (es decir, en
el tiempo τ 2 ε) la estación más distante, B, comienza a transmitir. Cuando B detecta que está reci-
biendo más potencia de la que está enviando, sabe que ha ocurrido una colisión, por lo que aborta su
transmisión y genera una ráfaga de ruido de 48 bits para avisar a las demás estaciones. En otras palabras,
bloquea el cable para asegurarse de que el emisor no ignore la colisión. Cerca del tiempo 2τ, el emisor
ve la ráfaga de ruido y aborta también su transmisión. Luego espera un tiempo aleatorio antes de rein-
tentarlo.
El paquete empieza El paquete llega

A B A B
en el tiempo 0 casi a B en �
(a) (b)
La ráfaga de ruido
regresa a A en 2
A B A B
(c) Colisión en el (d)

tiempo
Figura 4-15. La detección de una colisión puede tardar hasta 2τ.
Si una estación intenta transmitir una trama muy corta, es concebible que ocurra una colisión, pero la
transmisión se completará antes de que la ráfaga de ruido llegue de regreso a la estación en 2τ. El emisor
entonces supondrá de forma incorrecta que la trama se envió con éxito. Para evitar que ocurra esta situación,
todas las tramas deberán tardar más de 2τ para enviarse, de manera que la transmisión aún se esté llevando
a cabo cuando la ráfaga de ruido regrese al emisor. Para una LAN de 10 Mbps con una longitud máxima
de 2 500 metros y cuatro repetidores (de la especificación 802.3), el tiempo de ida y vuelta (incluyendo el
tiempo de propagación a través de los cuatro repetidores) se ha determinado en cerca de 50 μseg en el peor de
los casos. Por lo tanto, la trama más corta permitida se debe tardar por lo menos este tiempo en transmitir.
A 10 Mbps, un bit tarda 100 nseg, por lo que 500 bits es la trama más pequeña que se garantiza funcionará.
Para agregar algún margen de seguridad, este número se redondeó a 512 bits o 64 bytes.
El campo final de es la Suma de verificación. Es un CRC de 32 bits del tipo que estudiamos en
la sección 3.2. De hecho, se define exactamente mediante el polinomio generador que vimos en esa
sección, que funciona también para PPP, ADSL y otros enlaces. Esta CRC es un código de detección de
errores que se utiliza para determinar si los bits de la trama se recibieron correctamente. Sólo realiza
detección de errores y la trama se desecha si se detecta uno.
CSMA/CD con retroceso exponencial binario
La Ethernet clásica utiliza el algoritmo CSMA/CD persistente-1 que vimos en la sección 4.2. Este des-
criptor tan sólo significa que las estaciones detectan el medio cuando tienen una trama que desean enviar,
www.FreeLibros.me
y la envían tan pronto como el medio está inactivo. Monitorean el canal por si hay colisiones al momento
en que envían. Si hay una colisión, abortan la transmisión con una señal de bloqueo corta y vuelven a
transmitir después de un intervalo aleatorio.
Ahora veamos cómo se determina el intervalo aleatorio cuando ocurre una colisión, ya que es un
nuevo método. El modelo sigue siendo el de la figura 4-5. Tras una colisión, el tiempo se divide en ranuras
discretas cuya longitud es igual al tiempo de propagación de ida y vuelta para el peor de los casos en el
cable (2τ). Tomando en cuenta la ruta más larga permitida por Ethernet, el tiempo de ranura se estableció
en 512 tiempos de bit o 51.2 mseg.
Después de la primera colisión, cada estación espera 0 o 1 tiempos de ranura al azar antes de
intentarlo de nuevo. Si dos estaciones entran en colisión y ambas escogen el mismo número aleato-
rio, habrá una nueva colisión. Después de la segunda colisión, cada una escoge 0, 1, 2 o 3 al azar y
espera ese tiempo de ranura. Si ocurre una tercera colisión (la probabilidad de que esto suceda es de
0.25), entonces para la siguiente vez el número de ranuras a esperar se escogerá al azar del intervalo 0
a 23 − 1.
En general, después de i colisiones se elige un número aleatorio entre 0 y 2i − 1, y se salta ese número
de ranuras. Sin embargo, al llegar a 10 colisiones el intervalo de aleatorización se congela en un máximo de
1 023 ranuras. Después de 16 colisiones, el controlador tira la toalla e informa a la computadora que
fracasó. La recuperación posterior es responsabilidad de las capas superiores.
Este algoritmo, llamado retroceso exponencial binario, se escogió para adaptar en forma diná-
mica el número de estaciones que intentan transmitir. Si el intervalo de aleatorización para todas
las colisiones fuera de 1023, la posibilidad de que chocaran dos estaciones una segunda vez sería
insignificante, pero la espera promedio tras una colisión sería de cientos de tiempos de ranura, lo
que introduce un retardo significativo. Por otra parte, si cada estación siempre se retardara 0 o 1 ra-
nuras, entonces al tratar de transmitir 100 estaciones al mismo tiempo, habría colisiones una y otra
vez hasta que 99 de ellas escogieran 1 y la estación restante escogiera 0. Esto podría tomar años. Al
hacer que el intervalo de aleatorización crezca de manera exponencial a medida que ocurren cada vez
más colisiones, el algoritmo asegura un retardo pequeño cuando sólo unas cuantas estaciones entran
en colisión, pero también asegura que la colisión se resuelva en un intervalo razonable cuando haya co-
lisiones entre muchas estaciones. Al truncar el retroceso a 1023, evitamos que el límite crezca de-
masiado.
Si no hay colisión, el emisor supone que la trama probablemente se entregó con éxito. Es decir, ni
CSMA/CD ni Ethernet proveen confirmaciones de recepción. Esta elección es apropiada para los canales
de cable de cobre y de fibra óptica que tienen tasas de error bajas. Cualquier error que ocurra debe enton-
ces detectarse mediante la CRC y recuperarse en las capas superiores. Para los canales inalámbricos que
tienen más errores, veremos que se utilizan confirmaciones de recepción.
4.3.3 Desempeño de Ethernet
Ahora examinaremos brevemente el desempeño de la Ethernet clásica en condiciones de carga pesada y

constante; es decir, con k estaciones siempre listas para transmitir. Es complicado un análisis riguroso del
algoritmo de retroceso exponencial binario. Sin embargo, seguiremos a Metcalfe y Boggs (1976) y su-
pondremos una probabilidad constante de retransmisión en cada ranura. Si cada estación transmite duran-
te una ranura de contención con una probabilidad p, la probabilidad A de que una estación adquiera el
canal durante esa ranura es de:
A 5 kp(1 2 p)k21 (4-5)
www.FreeLibros.me
A se maximiza cuando p 5 1/k, con A → 1/e conforme k → ∞. La probabilidad de que el intervalo

de contención tenga exactamente j ranuras es de A(1 2 A) j21, por lo que el número medio de ranuras por
contención está dado por
Puesto que cada ranura tiene una duración de 2τ, el intervalo promedio de contención, w, es 2τ/A. Si supo-
nemos una p óptima, el número promedio de ranuras de contención nunca es mayor que e, por lo que w
es, cuando mucho, 2τe ≈ 5.4τ.
Si la trama promedio tarda P segundos en transmitirse, cuando muchas estaciones tienen tramas por
enviar,
(4-6)

Aquí vemos que la distancia máxima de cable entre dos estaciones entra en el cálculo de desempeño.
Cuanto mayor sea la longitud del cable, mayor será el intervalo de contención, razón por la cual el están-
dar Ethernet especifica una longitud máxima de cable.
Es instructivo formular la ecuación (4-6) en términos de la longitud de trama, F, el ancho de banda
de la red, B, la longitud del cable, L, y la velocidad de propagación de la señal, c, para el caso óptimo de
e ranuras de contención por trama. Con P 5 F/B, la ecuación (4-6) se convierte en
1
Eficiencia del canal = (4-7)
1 + 2BLe /cF
Cuando el segundo término en el denominador sea grande, la eficiencia de la red será baja. Específicamen-
te, un aumento en el ancho de banda o la distancia de la red (el producto BL) reduce la eficiencia para una
trama de un tamaño dado. Por desgracia, mucha de la investigación sobre hardware de redes está enfoca-
da a aumentar este producto. La gente quiere un gran ancho de banda a través de distancias grandes (por
ejemplo, en las MAN de fibra óptica), lo que sugiere que tal vez la Ethernet clásica implementada de esta
forma no sea el mejor sistema para estas aplicaciones. En la siguiente sección veremos otras formas de
implementar Ethernet.
En la figura 4-16 se presenta una gráfica de la eficiencia del canal contra el número de estaciones
listas para 2τ 5 51.2 μseg y una tasa de transmisión de datos de 10 Mbps, usando la ecuación (4-7). Con
un tiempo de ranura de 64 bytes, no es sorprendente que las tramas de 64 bytes no sean eficientes.
Por otra parte, con tramas de 1 024 bytes y un valor asintótico de e ranuras de 64 bytes por intervalo de
contención, el periodo de contención tiene 174 bytes de longitud y la eficiencia es del 85%. Este resultado
es mucho mejor que la eficiencia de 37% del ALOHA ranurado.
Tal vez valga la pena mencionar que se ha realizado una gran cantidad de análisis teóricos del des-
empeño de Ethernet (y otras redes). Es conveniente tomar con cautela la mayoría de los resultados, por
dos razones. Primero, casi todos estos trabajos han supuesto que el tráfico es Poisson. A medida que los
investigadores han comenzado a examinar datos reales, se ha hecho evidente que el tráfico en redes po-
cas veces es Poisson. Al contrario, es autosimilar o de ráfaga a través de un rango de escalas de tiempo
(Paxson y Floyd, 1995; Leland y colaboradores, 1994). Lo que esto significa es que el promedio durante
periodos extensos no hace al tráfico más uniforme. Además de usar modelos cuestionables, muchos de
los análisis se enfocan en los casos “interesantes” de desempeño con una carga inusualmente alta. Boggs
y colaboradores (1988) mostraron mediante la experimentación que en realidad Ethernet funciona bien,
incluso con una carga moderadamente alta.
www.FreeLibros.me
1.0
0.9 Tramas de 1024 bytes

0.8
Tramas de 512 bytes
0.7
Eficiencia del canal

Tramas de 256 bytes
0.6
0.5
Tramas de 128 bytes
0.4
0.3 Tramas de 64 bytes
0.2
0.1
0 1 2 4 8 16 32 64 128 256
Número de estaciones que tratan de enviar
Figura 4-16. Eficiencia de Ethernet a 10 Mbps con tiempos de ranuras de 512 bits.
4.3.4 Ethernet conmutada
Pronto Ethernet empezó a evolucionar y a alejarse de la arquitectura de un solo cable extenso de la Ethernet
clásica. Los problemas asociados con el hecho de encontrar interrupciones o conexiones flojas condujeron
hacia un distinto tipo de patrón de cableado, en donde cada estación cuenta con un cable dedicado que llega a
un hub (concentrador) central. Un hub simplemente conecta de manera eléctrica todos los cables que llegan
a él, como si estuvieran soldados en conjunto. Esta configuración se muestra en la figura 4-17(a).
Puerto Puerto
Línea Hub Línea Switch

(a) (b)
Figura 4-17. (a) Hub. (b) Switch.
Los cables eran pares trenzados de la compañía telefónica, ya que la mayoría de los edificios de ofi-
cinas contaban con este tipo de cableado y por lo general había muchos de sobra. Esta reutilización fue
una ventaja, pero a la vez se redujo la distancia máxima de cable del hub hasta 100 metros (200 metros
si se utilizaban pares trenzados categoría 5 de alta calidad). En esta configuración es más simple agregar
o quitar una estación, además de que los cables rotos se pueden detectar con facilidad. Con las ventajas
de usar el cableado existente y la facilidad de mantenimiento, los hubs de par trenzado se convirtieron
rápidamente en la forma dominante de Ethernet.
www.FreeLibros.me
Sin embargo, los hubs no incrementan la capacidad debido a que son lógicamente equivalentes al
cable extenso individual de la Ethernet clásica. A medida que se agregan más estaciones, cada estación
recibe una parte cada vez menor de la capacidad fija. En un momento dado, la LAN se saturará. Una forma
de solucionar esto es usar una velocidad más alta; por decir, de 10 Mbps a 100 Mbp, 1 Gbps o incluso
mayores velocidades. Pero con el crecimiento de multimedia y los poderosos servidores, incluso una
Ethernet de 1 Gbps se podría saturar.
Por fortuna existe otra forma de tratar con el aumento de carga: una Ethernet conmutada. El corazón
de este sistema es un conmutador (switch) que contiene un plano posterior (backplane) de alta veloci-
dad, el cual conecta a todos los puertos como se muestra en la figura 4-17(b). Desde el exterior, un switch
se ve igual que un hub. Ambos son cajas que por lo general contienen de 4 a 48 puertos, cada uno con
un conector estándar RJ-45 r para un cable de par trenzado. Cada cable conecta al switch o hub con una
sola computadora, como se muestra en la figura 4-18. Un switch tiene también las mismas ventajas que
un hub. Es fácil agregar o quitar una nueva estación con sólo conectar o desconectar un cable, y es fácil
encontrar la mayoría de las fallas, ya que un cable o puerto defectuoso por lo general afectará a una sola
estación. De todas formas hay un componente compartido que puede fallar (el mismo switch), pero si todas
las estaciones pierden conectividad, los encargados del TI sabrán qué hacer para corregir el problema:
reemplazar el switch completo.
Switch
Hub
Puertos del switch
Par trenzado
Figura 4-18. Un switch Ethernet.
Sin embargo, dentro del switch ocurre algo muy distinto. Los switches sólo envían tramas a los
puertos para los cuales están destinadas. Cuando el puerto de un switch recibe una trama Ethernet de una
estación, el switch verifica las direcciones de Ethernet para ver cuál es el puerto de destino de la trama.
Este paso requiere que el switch sea capaz de deducir qué puertos corresponden a qué direcciones, un pro-
ceso que describiremos en la sección 4.8 cuando veamos el caso general de switches conectados a otros
switches. Por ahora basta con suponer que el switch conoce el puerto de destino de la trama. A continua-
ción, el switch reenvía la trama a través de su plano posterior de alta velocidad hacia el puerto de destino.
Por lo general, el plano posterior opera a muchos Gbps mediante el uso de un protocolo propietario que
no necesita estandarización, ya que está completamente oculto dentro del switch. Después, el puerto de
destino transmite la trama sobre el cable, de manera que pueda llegar a la estación de destino. Ninguno
de los otros puertos sabe siquiera que existe la trama.
¿Qué ocurre si más de una estación o puerto desea enviar una trama al mismo tiempo? De nuevo,
los switches difieren de los hubs. En un hub, todas las estaciones están en el mismo dominio de coli-
sión. Deben usar el algoritmo CSMA/CD para programar sus transmisiones. En un switch, cada puerto
es su propio dominio de colisión independiente. En el caso común en que el cable es full-dúplex, tanto la
estación como el puerto pueden enviar una trama en el cable al mismo tiempo, sin preocuparse por los
demás puertos y estaciones. Ahora las colisiones son imposibles y no se necesita CSMA/CD. Pero si
el cable es half-dúplex, la estación y el puerto deben competir por la transmisión con CSMA/CD de la
manera usual.
www.FreeLibros.me
Un switch mejora el desempeño de la red en comparación con un hub de dos maneras. Primero,
como no hay colisiones, la capacidad se utiliza con más eficiencia. Segundo y más importante, con un
switch se pueden enviar varias tramas al mismo tiempo (por distintas estaciones). Estas tramas llega-
rán a los puertos del switch y viajarán hacia el plano posterior de éste para enviarlos por los puertos
apropiados. No obstante, como se podrían enviar dos tramas al mismo puerto de salida y al mismo
tiempo, el switch debe tener un búfer para que pueda poner temporalmente en cola una trama de entrada
hasta que se pueda transmitir al puerto de salida. En general, estas mejoras producen una considerable
ganancia en el desempeño que no es posible lograr con un hub. Con frecuencia, la velocidad real de
transmisión total del sistema se puede incrementar en un orden de magnitud, dependiendo del número
de puertos y patrones de tráfico.
El cambio en los puertos por donde se envían las tramas también incluye beneficios de seguridad.
La mayoría de las interfaces de LAN tienen un modo promiscuo, en el que todas las tramas se entregan
a cada computadora y no sólo las que van dirigidas a ella. En un hub, cualquier computadora conecta-
da puede ver el tráfico transmitido entre todas las demás computadoras. Los espías y los intrusos aman
esta característica. En un switch, el tráfico se reenvía sólo a los puertos a los que está destinado. Esta
restricción provee un mejor aislamiento, de modo que el tráfico no escape fácilmente y caiga en las manos
equivocadas. Sin embargo, es mejor cifrar el tráfico si de verdad se necesita seguridad.
Como el switch sólo espera tramas Ethernet estándar en cada puerto de entrada, es posible usar
algunos de los puertos como concentradores. En la figura 4-18, el puerto en la esquina superior derecha
no está conectado a una sola estación, sino a un hub de 12 puertos. A medida que llegan tramas al hub,
compiten por el cable de la manera usual, incluyendo las colisiones y el retroceso binario. Las tramas
que tienen éxito pasan por el hub hasta el switch, en donde se tratan como cualquier otra trama entrante.
El switch no sabe que tuvieron que competir para entrar. Una vez en el switch, se envían a la línea de
salida correcta a través del plano posterior de alta velocidad. También es posible que el destino co-
rrecto estuviera en una de las líneas conectadas al hub, en cuyo caso la trama ya se entregó y el switch
simplemente la descarta. Los hubs son más simples y económicos que los switches, pero debido a que
estos últimos han reducido su precio constantemente, los primeros se han convertido en una especie en
extinción. Las redes modernas usan en su mayor parte Ethernet conmutada. Sin embargo, aún existen
los hubs heredados.
4.3.5 Fast Ethernet
Al mismo tiempo que los switches ganaban popularidad, la velocidad de 10 Mbps de Ethernet estaba
bajo una presión cada vez mayor. Al principio, 10 Mbps parecían el cielo, al igual que los módems
de cable parecieron el cielo a los usuarios de los módems telefónicos. Pero la novedad desapareció muy
rápido. Como un tipo de corolario a la Ley de Parkinson (“El trabajo se expande hasta llenar el tiempo
disponible para que se termine”), tal pareciera que los datos se expandieron hasta llenar el ancho de ban-
da disponible para su transmisión.
Muchas instalaciones necesitaban más ancho de banda y, por lo tanto, tenían numerosas redes LAN
de 10 Mbps conectadas por una maraña de repetidores, hubs y switches, aunque los administradores de
redes algunas veces sentían que las conexiones parecían estar hechas con goma de mascar y tela metálica.
Pero incluso con los switches de Ethernet, el ancho de banda máximo de una sola computadora estaba
limitado por el cable que lo conectaba con el puerto del switch.
Fue en este entorno que el IEEE convocó al comité 802.3 en 1992 con instrucciones de idear una
LAN más rápida. Una propuesta fue mantener la red 802.3 igual a como estaba, sólo que hacerla más
rápida. Otra propuesta fue rehacerla en su totalidad para darle muchas características nuevas, como tráfico
en tiempo real y voz digitalizada, pero mantener el nombre antiguo (por razones de marketing). Después
www.FreeLibros.me
de algunas discusiones, el comité decidió mantener la Ethernet 802.3 tal como estaba, pero hacerla más
rápida. Esta estrategia cumpliría con el objetivo antes de que cambiara la tecnología, además de evitar los
problemas imprevistos con un diseño totalmente nuevo. El nuevo diseño también sería compatible con las
versiones previas de redes LAN Ethernet existentes. Las personas que apoyaban la propuesta contraria hi-
cieron lo que cualquier persona de la industria de la computación habría hecho bajo estas circunstancias:
unieron fuerzas, formaron su propio comité y estandarizaron su LAN de todas maneras (que con el tiempo
se llamó 802.12). Pero fracasó rotundamente.
El trabajo se terminó muy rápido (mediante las normas de los comités de estándares) y el resultado,
802.3u, fue aprobado de manera oficial por el IEEE en junio de 1995. Técnicamente, 802.3u no es un nue-
vo estándar sino un agregado al estándar, 802.3 existente (para enfatizar su compatibilidad con versiones
anteriores). Esta estrategia es muy utilizada. Puesto que prácticamente todos lo llaman Fast Ethernet en
vez de 802.3u. Nosotros también lo haremos.
La idea básica detrás de Fast Ethernet era simple: mantener todos los formatos, interfaces y reglas
de procedimientos anteriores, pero reducir el tiempo de bits de 100 nseg a 10 nseg. Técnicamente, habría
sido posible copiar la Ethernet clásica de 10 Mbps y aún detectar colisiones a tiempo con sólo reducir
la longitud máxima de cable por un factor de 10. Sin embargo, las ventajas del cableado de par trenzado
eran tan abrumadoras que Fast Ethernet se basa por completo en este diseño. Por lo tanto, todos los sis-
temas Fast Ethernet utilizan hubs y switches; no se permiten cables con múltiples derivaciones vampiro
ni conectores BNC.
Sin embargo, aún había que tomar algunas decisiones, siendo la más importante de todas qué tipos de
cable soportar. Una opción era el cable de par trenzado categoría 3. El argumento a su favor era que casi
todas las oficinas en el mundo occidental tenían por lo menos cuatro cables de par trenzado categoría 3 (o
mejor) que iban desde ahí hasta un gabinete de cableado telefónico dentro de una distancia de 100 metros.
Algunas veces había dos de esos cables. Por lo tanto, al usar cable de par trenzado categoría 3 se podrían
cablear las computadoras de escritorio mediante Fast Ethernet sin tener que volver a cablear el edificio, lo
cual es una enorme ventaja para muchas organizaciones.
La principal desventaja del cable de par trenzado categoría 3 es su incapacidad de transportar 100 Mbps
a más de 100 metros, la máxima distancia de computadora a hub especificada para hubs de 10 Mbps. En
contraste, el cable de par trenzado categoría 5 puede manejar 100 metros con facilidad, y la fibra puede
recorrer mucha más distancia. El compromiso elegido fue permitir las tres posibilidades, como se muestra
en la figura 4-19, pero fortalecer la solución categoría 3 para darle la capacidad de transmisión adicional
necesaria.
Nombre Cable Segmento máximo Ventajas
100Base-T4 Par trenzado 100 m Utiliza UTP categoría 3.
100Base-TX Par trenzado 100 m Full-dúplex a 100 Mbps (UTP cat 5).
100Base-FX Fibra óptica 2000 m Full-dúplex a 100 Mbps; distancias largas.
Figura 4-19. El cableado original de Fast Ethernet.
El esquema UTP categoría 3, llamado 100Base-T4, utilizaba una velocidad de señalización de 25 MHz, tan
sólo un 25% más rápida que los 20 MHz de la Ethernet estándar (recuerde que la codificación Manchester,
que vimos en la sección 2.5, requiere dos periodos de reloj para cada uno de los 10 millones de bits que
se envían cada segundo). Sin embargo, para alcanzar la tasa de bits necesaria, 100Base-T4 requiere cuatro
cables de par trenzado. De los cuatro pares, uno siempre va al hub, uno siempre sale del hub y los otros
www.FreeLibros.me
dos se pueden conmutar a la dirección actual de la transmisión. Para obtener 100 Mbps de los tres pares
trenzados en la dirección de la transmisión, se utiliza un esquema bastante complejo en cada par trenzado,
que implica enviar dígitos ternarios con tres distintos niveles de voltaje. Es poco probable que este esquema
vaya a ganar premios por su elegancia, por lo que omitiremos los detalles. Sin embargo, y como el cableado
telefónico estándar ha tenido durante décadas cuatro pares trenzados por cable, la mayoría de las oficinas
pueden usar la planta de cableado existente. Claro que esto significa renunciar al teléfono de su oficina, pero
sin duda es un pequeño precio a pagar para obtener correo electrónico, que es más rápido.
100Base-T4 quedó al borde del camino debido a que se actualizó el cableado de muchos edificios de
oficinas por UTP categoría 5 para Ethernet 100Base-TX, el cual llegó a dominar el mercado. Este diseño
es más simple puesto que los cables pueden manejar velocidades de reloj de 125 MHz. Sólo se utilizan
dos pares trenzados por estación, uno que va al hub y otro que viene de él. No se utiliza la codificación
binaria directa (es decir, NRZ) ni la codificación Manchester. En cambio se utiliza la codificación 4B/5B
que describimos en la sección 2.5. Se codifican 4 bits de datos como 5 bits de señal y se envían a 125 MHz
para proveer 100 Mbps. Este esquema es simple pero tiene suficientes transiciones para la sincronización,
además de que utiliza muy bien el ancho de banda del cable. El sistema 100Base-TX es full-dúplex; las
estaciones pueden transmitir a 100 Mbps en un par trenzado y recibir a 100 Mbps en otro par trenzado al
mismo tiempo.
La última opción, 100Base-FX, utiliza dos filamentos de fibra multimodo, una para cada dirección,
por lo que también es full-dúplex con 100 Mbps en cada dirección. En esta configuración, la distancia
entre una estación y el switch puede ser de hasta 2 km.
Fast Ethernet permite la interconexión mediante hubs o switches. Para asegurar que el algoritmo
CSMA/CD siga trabajando, es necesario mantener la relación entre el tamaño mínimo de trama y la longi-
tud máxima del cable a medida que la velocidad de la red aumenta de 10 Mbps a 100 Mbps. Así, el tamaño
mínimo de trama de 64 bytes debe aumentar o la longitud máxima de cable de 2 500 debe disminuir, en
forma proporcional. La elección fácil fue reducir la distancia máxima entre dos estaciones cualesquiera
por un factor de 10, puesto que un hub con cables de 100 m ya se encuentra dentro de este nuevo valor
máximo. Sin embargo, los cables 100Base-FX de 2 km son demasiado largos como para permitir un hub
de 100 Mbps con el algoritmo de colisiones normal de Ethernet. Estos cables se deben conectar a un
switch y operar en un modo full-dúplex para que no haya colisiones.
Los usuarios empezaron a implementar con rapidez el estándar Fast Ethernet, pero no deseaban ti-
rar las tarjetas Ethernet de 10 Mbps en las computadoras antiguas. Como consecuencia, casi todos los
switches Fast Ethernet pueden manejar una mezcla de estaciones de 10 Mbps y 100 Mbps. Para facilitar
la actualización, el estándar provee por sí solo un mecanismo llamado autonegociación, el cual permite
que dos estaciones negocien de manera automática la velocidad óptima (10 o 100 Mbps) y la duplicidad
(half-dúplex o full-dúplex). Funciona bien la mayor parte del tiempo, pero se sabe que provoca problemas
de desajuste de duplicidad cuando un extremo del enlace realiza la autonegociación pero el otro extremo
no, y se establece en modo full-dúplex (Shalunov y Carlson, 2005). La mayoría de los productos Ethernet
usan esta característica para configurarse a sí mismos.
4.3.6 Gigabit Ethernet
La tinta apenas se estaba secando en el estándar de la Fast Ethernet cuando el comité 802 comenzó a
trabajar en una Ethernet aún más rápida, que de inmediato recibió el apodo de Gigabit Ethernet. El IEEE
ratificó la forma más popular como 80.3ab en 1999. A continuación analizaremos algunas de las caracte-
rísticas clave de la Gigabit Ethernet. Para mayor información consulte a Spurgeon (2000).
Los objetivos del comité para la Gigabit Ethernet eran en esencia los mismos que los del comité
para Fast Ethernet: que tuviera un desempeño 10 veces mayor y que mantuviera la compatibilidad con
www.FreeLibros.me
todos los estándares Ethernet existentes. En particular, Gigabit Ethernet tenía que ofrecer servicio de
datagramas sin confirmación de recepción con unidifusión y multidifusión, utilizar el mismo esquema
de direccionamiento de 48 bits que ya estaba en uso y mantener el mismo formato de trama, incluyendo
los tamaños mínimo y máximo de trama. El estándar final cumple con todos estos objetivos.
Al igual que Fast Ethernet, todas las configuraciones de Gigabit Ethernet usan enlaces punto a punto.
En la configuración más simple, que se muestra en la figura 4-20(a), dos computadoras están conectadas
directamente una con otra. Sin embargo, el caso más común es tener un switch o un hub conectado a
varias computadoras y quizás a switches o hubs adicionales, como se muestra en la figura 4-20(b). En
ambas configuraciones, cada cable Ethernet individual tiene exactamente dos dispositivos en él, ni más
ni menos.
Switch o hub
Ethernet
Computadora
Ethernet
(a) (b)
Figura 2-20. (a) Ethernet de dos estaciones. (b) Ethernet multiestación.
Además, al igual que Fast Ethernet, Gigabit Ethernet soporta dos modos diferentes de funciona-
miento: modo full-dúplex y modo half-dúplex. El modo “normal” es el modo full-dúplex, que permite
tráfico en ambas direcciones al mismo tiempo. Este modo se utiliza cuando hay un switch central co-
nectado a computadoras (o a otros switches) en la periferia. En esta configuración, todas las líneas se
almacenan en el búfer con el fin de que cada computadora y switch pueda enviar tramas siempre que
lo desee. El emisor no tiene que detectar el canal para ver si alguien más lo está utilizando debido a
que la contención es imposible. En la línea entre una computadora y un switch, la computadora es la
única que puede enviar al switch y la transmisión tendrá éxito aun cuando el switch esté enviado ahora
una trama a la computadora (porque la línea es full-dúplex). Debido a que no hay contención, no se
utiliza el protocolo CSMA/CD y la longitud máxima del cable se determina con base en los aspectos
relacionados con la fuerza de la señal, en vez de basarse en el tiempo que tarda una ráfaga de ruido
en propagarse de vuelta al emisor en el peor de los casos. Los switches tienen la libertad de mezclar e
igualar velocidades. La autonegociación se soporta al igual que en Fast Ethernet, sólo que ahora la
opción está entre 10, 100 y 1000 Mbps.
El otro modo de operación es half-dúplex y se utiliza cuando las computadoras están conectadas a un
hub en vez de un switch. Un hub no almacena las tramas entrantes. En su lugar, conecta en forma eléctrica
todas las líneas internamente, simulando el cable con múltiples derivaciones que se utiliza en la Ethernet
clásica. En este modo puede haber colisiones, por lo que se requiere el protocolo CSMA/CD estándar.
Debido a que ahora se puede transmitir una trama de 64 bytes (la más corta permitida) 100 veces más
rápido que en la Ethernet clásica, la longitud máxima del cable debe ser 100 veces menor, o de 25 metros,
para mantener la propiedad esencial de que el emisor aún transmita cuando la ráfaga de ruido regrese a él,
incluso en el peor de los casos. Con un cable de 2 500 metros de longitud, el emisor de una trama de 64 bytes
www.FreeLibros.me
a 1 Gbps podría terminar su transmisión mucho antes de que la trama recorriera siquiera una décima del
camino, y por ende muchísimo antes de que llegara al otro extremo y regresara.
Esta restricción de longitud fue tan dolorosa que se agregaron dos características al estándar para in-
crementar la longitud máxima del cable a 200 metros, lo cual quizás es suficiente para la mayoría de las
oficinas. La primera característica, llamada extensión de portadora, básicamente indica al hardware que
agregue su propio relleno después de la trama normal para extenderla a 512 bytes. Como el hardware
emisor agrega este relleno y el hardware receptor lo elimina, el software no toma parte en esto, lo que sig-
nifica que no es necesario realizar cambios al software existente. La desventaja es que usar 512 bytes de
ancho de banda para transmitir 46 bytes de datos de usuario (la carga útil de una trama de 64 bytes)
tiene una eficiencia de sólo un 9%.
La segunda característica, llamada ráfagas de trama, permite que un emisor transmita una secuencia
concatenada de múltiples tramas en una sola transmisión. Si la ráfaga total es menor que 512 bytes, el
hardware la rellena de nuevo. Si hay suficientes tramas esperando su transmisión, este esquema es muy
eficiente y se prefiere en vez de la extensión de portadora.
Sin embargo, haciendo justicia, es difícil imaginar a una organización comprando computadoras mo-
dernas con tarjetas Gigabit Ethernet y después conectarlas con un hub anticuado para simular la Ethernet
clásica con todas sus colisiones. Las interfaces y los switches de Gigabit Ethernet solían ser costosos,
pero sus precios cayeron rápidamente cuando empezaron a aumentar los volúmenes de ventas. Aún así, la
compatibilidad con versiones anteriores es algo sagrado en la industria de las computadoras, por lo que el
comité tuvo que añadirla. En la actualidad, la mayoría de las computadoras incluyen una interfaz Ethernet
capaz de operar a 10, 100 y 1000 Mbps, además de ser compatible con todas estas redes.
Como se lista en la figura 4-21, Gigabit Ethernet soporta tanto el cableado de cobre como el de fibra
óptica. La señalización en, o cerca de, 1 Gbps requiere codificar y enviar un bit cada nanosegundo.
En un principio este truco se lograba con cables cortos de cobre blindados (la versión 1000Base-CX) y con
fibra óptica. En la fibra óptica se permiten dos longitudes de onda y resultan dos versiones distintas:
0.85 micras (corto, para 1000Base-SX) y 1.3 micras (largo, para 1000Base-LX).
1000Base-SX Fibra óptica 550 m Fibra multimodo (50, 62.5 micras)
1000Base-LX Fibra óptica 5000 m Monomodo (10 µ) o multimodo (50, 62.5µ)
1000Base-CX 2 pares de STP 25 m Par trenzado blindado
1000Base-T 4 pares de UTP 100 m UTP estándar categoría 5
Figura 4-21. Cableado de Gigabit Ethernet.
La señalización en la longitud de onda corta se puede realizar mediante LEDs económicos. Se utiliza
con fibra multimodo y es útil para las conexiones dentro de un edificio, ya que puede funcionar hasta por
500 m para la fibra de 50 micras. La señalización en la longitud de onda larga requiere láser más costo-
sos. Por otro lado, al combinarse con fibra monomodo (10 micras), la longitud de cable puede ser de hasta
5 km. Este límite permite conexiones de larga distancia entre edificios (por ejemplo, la red troncal de un
campus) como un enlace punto a punto dedicado. Las versiones posteriores del estándar permitían enlaces
aún más largos a través de fibra monomodo.
Para enviar bits por estas versiones de Gigabit Ethernet, se pidió prestada la codificación 8B/10B
que describimos en la sección 2.5 de otra tecnología de red, conocida como Canal de fibra. Este esquema
codifica 8 bits de datos en palabras codificadas de 10 bits que se envían a través del cable o la fibra, de
www.FreeLibros.me
aquí que se llame 8B/10B. Las palabras codificadas se eligieron de modo que se pudieran balancear (es
decir, que tengan el mismo número de 0s y 1s) con suficientes transiciones para la recuperación del reloj.
Para enviar los bits codificados con NRZ se requiere un ancho de banda de señalización de un 25% más
que el requerido para los bits sin codificación, una importante mejora en comparación con la expansión
de 100% de la codificación Manchester.
Sin embargo, todas estas opciones requerían nuevos cables de cobre o de fibra para soportar la
señalización más rápida. Ninguna de ellas hizo uso de la gran cantidad de cable UTP categoría 5 que se
había instalado con la red Fast Ethernet. Antes de un año llegó 1000Base-T para llenar este vacío, y desde
entonces ha sido la forma más popular de Gigabit Ethernet. Aparentemente a las personas no les gustaba
tener que volver a cablear sus edificios.
Para hacer que Ethernet opere a 1000 Mbps a través de cables categoría 5 se necesita una señalización
más complicada. Para empezar se utilizan los cuatro pares trenzados en el cable, y cada par se utiliza en
ambas direcciones al mismo tiempo mediante el uso de un procesamiento de señales digitales para separar
las señales. En cada cable se utilizan cinco niveles de voltaje que transportan 2 bits para una señalización
de 125 Msímbolos/seg. La asignación para producir los símbolos a partir de los bits no es simple. Se
requiere un mezclado (scrambling) para las transiciones, seguido de un código de corrección de errores
en el que se incrustan cuatro valores en cinco niveles de señal.
1 Gbps es una velocidad muy alta. Por ejemplo, si un receptor está ocupado con otra tarea por incluso
un 1 mseg y no vacía el búfer de entrada en alguna línea, podrían haberse acumulado hasta 1 953 tramas en
ese espacio. Además, cuando una computadora en una Gigabit Ethernet está enviando datos por la línea a
una computadora en una Ethernet clásica, es muy probable que sucedan desbordamientos de búfer. Como
consecuencia de estas dos observaciones, Gigabit Ethernet soporta el control de flujo. El mecanismo con-
siste en que un extremo envíe una trama de control especial al otro extremo para indicarle que se detenga
durante cierto periodo. Estas tramas de control PAUSE son tramas Ethernet comunes que contienen un
tipo de 0x8808. Las pausas se dan en unidades del tiempo mínimo de trama. Para Gigabit Ethernet, la
unidad de tiempo es de 512 nseg y se permiten pausas hasta de 33.6 mseg.
Hay una extensión más que se introdujo junto con Gigabit Ethernet. Las tramas Jumbo que permiten
que las tramas tengan una longitud mayor de 1500 bytes, por lo general de hasta 9 KB. Esta extensión es
propietaria. No la reconoce el estándar debido a que si se utiliza, entonces Ethernet ya no es compatible
con las versiones anteriores, pero la mayoría de los distribuidores la soporta de todas formas. La razón
es que 1500 bytes es una unidad corta a velocidades de gigabits. Al manipular bloques más grandes de
información, la tasa de transmisión de tramas se puede reducir, junto con el procesamiento asociado con
ésta, tal como interrumpir al procesador para decir que llegó una trama, o dividir y recombinar mensajes
que eran demasiado largos como para caber en una trama Ethernet.
4.3.7 10 Gigabit Ethernet
Tan pronto como el Gigabit Ethernet se estandarizó, el comité 802 se aburrió y quiso volver al trabajo. El
IEEE les dijo que iniciaran una Ethernet de 10 gigabits. Este trabajo siguió casi el mismo patrón que los
estándares Ethernet anteriores, en donde aparecieron estándares para fibra y cable de cobre blindado por
primera vez en 2002 y 2004, seguidos de un estándar para par trenzado de cobre en 2006.
10 Gbps es una velocidad realmente prodigiosa, 1 000 veces más rápida que la Ethernet original. ¿En
dónde se podría necesitar? La respuesta es que dentro de los centros e intercambios de datos para conec-
tar enrutadores, switches y servidores de gama alta, así como en las troncales de larga distancia con alto
ancho de banda entre las oficinas que permiten la operación de redes de área metropolitana completas,
basadas en Ethernet y fibra. Las conexiones de larga distancia usan fibra óptica, mientras que las conexio-
nes cortas pueden usar cobre o fibra.
www.FreeLibros.me
Todas las versiones de Ethernet de 10 gigabits soportan sólo la operación full-dúplex. CSMA/CD ya
no forma parte del diseño y los estándares se concentran en los detalles de las capas físicas que pueden
operar a muy alta velocidad. Pero la compatibilidad aún sigue siendo importante, por lo que las interfaces
Ethernet de 10 gigabits usan la autonegociación y cambian a la velocidad más alta soportada por ambos
extremos de la línea.
En la figura 4-22 se listan los principales tipos de Ethernet de 10 gigabits. Se utiliza fibra multimodo
con la longitud de onda de 0.85 m (corta) para distancias medias, y la fibra monomodo a 1.3 m (larga) y
1.5 m (extendida) para distancias largas. 10GBase-ER puede operar en distancias de 40 km, lo cual la hace
adecuada para aplicaciones de área amplia. Todas estas versiones envían un flujo serial de información
que se produce mediante el mezclado de los bits de datos, para después codificarlos mediante un código
64B/66B. Esta codificación tiene menos sobrecarga que un código 8B/10B.
10GBase-SR Fibra óptica Hasta 300 m Fibra multimodo (0.85 µ).
10GBase-LR Fibra óptica 10 km Fibra monomodo (1.3 µ).
10GBase-ER Fibra óptica 40 km Fibra monomodo (1.5 µ).
10GBase-CX4 4 pares de twinax 15 m Cobre twinaxial.
10GBase-T 4 pares de UTP 100 m UTP categoría 6a
Figura 4-22. Cableado de Ethernet de 10 gigabits.
La primera versión de cobre que se definió (10GBase-CX4) utiliza un cable con cuatro pares de
cableado twinaxial de cobre. Cada par usa codificación 8B/10B y opera a 3.125 Gsímbolos/segundo para
alcanzar 10 Gbps. Esta versión es más económica que la fibra y fue de las primeras en comercializarse,
pero aún está por verse si será vencida a la larga por la Ethernet de 10 gigabits sobre la variedad más
común de cableado de par trenzado.
10GBase-T es la versión que usa cables UTP. Aunque requiere cableado categoría 6a, en distancias
más cortas puede usar categorías más bajas (incluyendo la categoría 5) para reutilizar una parte del ca-
bleado ya instalado. No es sorpresa que la capa física esté bastante involucrada para llegar a 10 Gbps
sobre par trenzado. Sólo esbozaremos algunos de los detalles de alto nivel. Cada uno de los cuatro pares
trenzados se utiliza para enviar 2 500 Mbps en ambas direcciones. Para llegar a esta velocidad se utiliza
una tasa de señalización de 800 Msímbolos/seg, con símbolos que usan 16 niveles de voltaje. Para produ-
cir los símbolos se mezclan los datos, se protegen con un código LDPC (Verificación de Paridad de Baja
Densidad, del inglés Low Density Parity Check) y se vuelven a codificar para corrección de errores.
La Ethernet de 10 gigabits se sigue tambaleando en el mercado, pero el comité 802.3 ya siguió adelante.
A finales de 2007, el IEEE creó un grupo para estandarizar la Ethernet que opera a 40 Gbps y 100 Gbps.
Esta actualización permitirá a Ethernet competir en ambientes de muy alto rendimiento, incluyendo las
conexiones de larga distancia en redes troncales y las conexiones cortas a través de los planos posteriores de
los equipos. El estándar todavía no está completo, pero ya hay productos propietarios disponibles.
4.3.8 Retrospectiva de Ethernet
Ethernet ha existido desde hace casi 30 años y no tiene competidores serios a la vista, por lo que es
probable que exista por algunos años más. Pocas arquitecturas de CPU, sistemas operativos o lenguajes
www.FreeLibros.me
de programación han sido los reyes de la montaña por tres décadas sin mostrar signos de debilidad. Es
evidente que Ethernet hizo algo bien, pero, ¿qué fue?
Quíza la razón principal de su longevidad es que Ethernet es simple y flexible. En la prác-
tica, simple se traduce como confiable, económico y fácil de mantener. Una vez que se adoptó
la arquitectura de hub y switch, casi no ocurrían fallas. Las personas dudaban en reemplazar algo que
funciona bien todo el tiempo, sobre todo cuando saben que muchas cosas funcionan pobremente en la
industria de la computación, de modo que muchas de las denominadas “actualizaciones” son peores que
lo que reemplazan.
Simple también se traduce como económico. El cableado de par trenzado tiene un costo relativamente
bajo, al igual que los componentes de hardware. Pueden empezar con un alto costo cuando hay una tran-
sición; por ejemplo, nuevas NICs o switches de Gigabit Ethernet, pero son simples adiciones para una
red bien establecida (no su reemplazo) y los precios bajan con rapidez a medida que el volumen de ventas
aumenta.
Ethernet es fácil de mantener. No hay software que instalar (sólo los controladores) y tampoco hay
tablas de configuración que manejar (con el riesgo de equivocarse). Además, agregar nuevos hosts es tan
simple como conectarlos.
Otro punto es que Ethernet interactúa fácilmente con TCP/IP, el cual se ha vuelto dominante. IP es un
protocolo sin conexión, por lo que se adapta muy bien a Ethernet, que también es sin conexión. IP no se
adapta tan bien a las alternativas orientadas a conexión como ATM. Esta falta de ajuste afecta definitiva-
mente las posibilidades de ATM.
Por último, y tal vez lo más importante, Ethernet ha sido capaz de evolucionar en ciertas formas im-
portantes. Las velocidades han aumentado en varios órdenes de magnitud y se han introducido los hubs
y switches, pero estos cambios no requieren modificaciones en el software, lo cual ha permitido que se
reutilice muchos el cableado existente durante un tiempo. Si un vendedor de redes aparece en una instala-
ción grande y dice: “Tengo esta nueva red fantástica para usted. Lo único que tiene que hacer es tirar todo
su hardware y reescribir todo su software”, está en un grave problema.
Muchas tecnologías alternativas de las que quizá no haya oído hablar eran más rápidas que Ethernet
cuando se introdujeron. Junto con ATM, esta lista incluye la FDDI (Interfaz de Datos Distribuidos por
Fibra, del inglés Fiber Distributed Data Interface) y el Canal de fibra, † dos redes LAN ópticas basadas
en anillos. Ambas eran incompatibles con Ethernet. Ninguna de ellas tuvo éxito. Eran demasiado com-
plicadas, por lo cual se requerían chips complejos y precios altos. La lección que se debió de aprender
aquí era KISS (Mantenlo simple, del inglés Keep It Simple, Stupid). Con el tiempo, Ethernet se emparejó
con ellas en términos de velocidad, a menudo pidiendo prestada una parte de su tecnología; por ejemplo,
la codificación 4B/5B de FDDI y la codificación 8B/10B del Canal de fibra. Así, no les quedaron ventajas
y murieron en forma silenciosa o quedaron en roles especializados.
Tal parece que Ethernet seguirá expandiendo sus aplicaciones durante un poco más de tiempo. Gra-
cias al estándar Ethernet de 10 gigabits, se liberó de las restricciones de distancia de CSMA/CD. Se
ha realizado un esfuerzo considerable en la Ethernet con grado de portadora para que los pro-
veedores de red puedan ofrecer servicios basados en Ethernet a sus clientes para las redes de área
metropolitana y amplia (Fouli y Maler, 2009). Esta aplicación transmite las tramas Ethernet por largas
distancias a través de fibra óptica y exige mejores características de administración para ayudar
a los operadores a ofrecer servicios confiables de alta calidad. Las redes de muy alta velocidad
también se están empezando a usar planos posteriores para conectar componentes en grandes en-
rutadores o servidores. Estos usos son adicionales al envío de tramas entre computadoras ubicadas
en oficinas.
†
En inglés se le llama Fibre Channel y no Fiber Channel, debido a que el editor del documento era británico.
www.FreeLibros.me
318 LA CAPA DE RED CAP. 5
5.2.4 Enrutamiento por vector de distancia
Por lo general, las redes de computadoras utilizan algoritmos de enrutamiento dinámico más complejos
que la inundación, pero más eficientes debido a que encuentran las rutas más cortas para la topología
actual. En particular hay dos algoritmos dinámicos que son los más populares: el enrutamiento por vector
de distancia y el enrutamiento por estado del enlace. En esta sección veremos el primer algoritmo. En la
siguiente estudiaremos el segundo.
El algoritmo de enrutamiento por vector de distancia opera haciendo que cada enrutador man-
tenga una tabla (es decir, un vector) que proporcione la mejor distancia conocida a cada destino y
el enlace que se puede usar para llegar ahí. Para actualizar estas tablas se intercambia información
con los vecinos. Eventualmente, todos los ruteadores conocen el mejor enlace para alcanzar cada
destino.
En ocasiones, el algoritmo de enrutamiento por vector de distancia recibe otros nombres, de los cuales
el más común es algoritmo de enrutamiento Bellman-Ford distribuido, en honor a los investigadores que
lo desarrollaron (Bellman, 1957; Ford y Fulkerson, 1962). Éste fue el algoritmo original de enrutamiento
de ARPANET y también se usó en Internet con el nombre de RIP.
En el enrutamiento por vector de distancia, cada enrutador mantiene una tabla de enrutamiento indi-
zada por (y que contiene una entrada de) cada enrutador de la red. Esta entrada consta de dos partes: la
línea preferida de salida a usar para ese destino y una estimación del tiempo o distancia a ese destino.
La distancia se podría medir como la cantidad de saltos, o se podría usar otra métrica, como vimos al
calcular las rutas más cortas.
Se supone que el enrutador conoce la “distancia” a cada uno de sus vecinos. Si la métrica es de sal-
tos, la distancia sólo es un salto. Si la métrica es el retardo de propagación, el enrutador puede medirlo
en forma directa con paquetes especiales de ECO que el receptor sólo marca con la hora y lo regresa tan
rápido como puede.
Por ejemplo, suponga que el retardo se usa como métrica y que el enrutador conoce el retardo a cada
uno de sus vecinos. Una vez cada T mseg, cada enrutador envía a todos sus vecinos una lista de sus retar-
dos estimados a cada destino. También recibe una lista similar de cada vecino. Imagine que una de estas
tablas acaba de llegar del vecino X, en donde Xi es la estimación respecto al tiempo que le toma llegar
al enrutador i. Si el enrutador sabe que el retardo a X es de m mseg, también sabe que puede llegar al
enrutador i a través de X en Xi 1 m mseg. Al efectuar este cálculo para cada vecino, un enrutador puede
encontrar la estimación que parezca ser la mejor y usar esa estimación, así como el enlace correspon-
diente, en su nueva tabla de enrutamiento. Cabe mencionar que en este cálculo no se utiliza la antigua
tabla de enrutamiento.
Este proceso de actualización se ilustra en la figura 5-9. En la parte (a) se muestra una red. Las prime-
ras cuatro columnas de la parte (b) muestran los vectores de retardo recibidos de los vecinos del enrutador
J. A indica que tiene un retardo de 12 mseg a B, un retardo de 25 mseg a C, un retardo de 40 mseg a D,
etcétera. Suponga que J ha medido o estimado el retardo a sus vecinos A, I, H y K en 8, 10, 12 y 6 mseg,
respectivamente.
Considere la manera en que J calcula su nueva ruta al enrutador G. Sabe que puede llegar a A en
8 mseg; además A indica ser capaz de llegar a G en 18 mseg, por lo que J sabe que puede contar con un
retardo de 26 mseg a G si reenvía a A los paquetes destinados para G. Del mismo modo, calcula el retardo
a G a través de I, H y K en 41 (31 1 10), 18 (6 1 12) y 37 (31 1 6) mseg, respectivamente. El mejor
de estos valores es el 18, por lo que escribe una entrada en su tabla de enrutamiento para indicar que
el retardo a G es de 18 mseg, y que la ruta que se utilizará es a través de H. Para los demás des-
tinos se realiza el mismo cálculo; la nueva tabla de enrutamiento se muestra en la última columna de la
figura.
www.FreeLibros.me
SEC. 5.2 ALGORiTMOS DE ENRUTAMIENTO 319
Nuevo retardo
Enrutador estimado desde J
A B C D A A I H K Línea
A 0 24 20 21 8 A
B 12 36 31 28 20 A
C 25 18 19 36 28 I
F G D 40 27 8 24 20 H
E H
E 14 7 30 22 17 I
F 23 20 19 40 30 I
G 18 31 6 31 18 H
H 17 20 0 19 12 H
I J K L
I 21 0 14 22 10 I
J 9 11 7 10 0 −
K 24 22 22 0 6 K
L 29 33 9 9 15 K
El El El El
retardo retardo retardo retardo Vectores
JA es JI es JH es JK es recibidos
de 8 de 10 de 12 de 6 de los cuatro
vecinos de J
Nueva tabla de
enrutamiento para J
(a) (b)
Figura 5-9. (a) Una red. (b) Entrada de A, I, H, K y la nueva tabla de enrutamiento para J.
El problema del conteo al infinito
Al proceso de establecer los enrutamientos con base en las mejores rutas a través de la red se le conoce
como convergencia. El enrutamiento por vector de distancia es útil como una simple técnica mediante
la cual los enrutadores pueden calcular las rutas más cortas en forma colectiva, pero tiene una grave des-
ventaja en la práctica: aunque converge hacia la respuesta correcta, puede llegar a hacerlo con lentitud.
Básicamente reacciona rápido a las buenas noticias, pero es lento con las malas. Considere un enrutador
cuya mejor ruta al destino X es larga. Si en el siguiente intercambio el vecino A informa de manera repen-
tina un retardo corto a X, el enrutador simplemente cambia y usa la línea A para enviar tráfico a X. En un
intercambio de vectores, se procesan las buenas noticias.
Para ver la rapidez de propagación de las buenas noticias, considere la red de cinco nodos (lineal) de
la figura 5-10, en donde la métrica de retardo es el número de saltos. Suponga que A está desactivado al
principio y que los otros enrutadores lo saben. En otras palabras, todos registraron el retardo a A como
infinito.
Al activarse A, los demás enrutadores saben de él gracias a los intercambios de vectores. Por senci-
llez, supondremos que hay un “gong” gigantesco en algún lado, golpeando periódicamente para iniciar
de manera simultánea un intercambio de vectores entre todos los enrutadores. En el momento del primer
intercambio, B se entera de que su vecino de la izquierda tiene un retardo de cero hacia A. B crea entonces
una entrada en su tabla de enrutamiento para indicar que A está a un salto de distancia hacia la izquierda.
Los demás enrutadores aún detectan que A está desactivado. En este punto, las entradas de la tabla de
enrutamiento para A se muestran en la segunda fila de la figura 5-10(a). Durante el siguiente intercambio,
C se entera de que B tiene una ruta a A de longitud 1, por lo que actualiza su tabla de enrutamiento para
indicar una ruta de longitud 2, pero D y E no se enteran de las buenas nuevas sino hasta después. Como
es evidente, las buenas noticias se difunden a razón de un salto por intercambio. En una red cuya ruta
mayor tiene una longitud de N saltos, en un lapso de N intercambios todo mundo sabrá sobre los enlaces
y enrutadores que acaban de revivir.
www.FreeLibros.me
A B C D E A B C D E
∞ ∞ ∞ ∞ Al principio 1 2 3 4 Al principio
1 ∞ ∞ ∞ Después de 1 intercambio 3 2 3 4 Después de 1 intercambio
1 2 ∞ ∞ Después de 2 intercambios 3 4 3 4 Después de 2 intercambios
1 2 3 ∞ Después de 3 intercambios 5 4 5 4 Después de 3 intercambios
1 2 3 4 Después de 4 intercambios 5 6 5 6 Después de 4 intercambios
7 6 7 6 Después de 5 intercambios
7 8 7 8 Después de 6 intercambios
..
.
(a) (b)
Figura 5-10. El problema del conteo al infinito.
Ahora consideremos la situación de la figura 5-10(b), en la que todos los enlaces y enrutadores están
inicialmente activos. Los enrutadores B, C, D y E tienen distancias a A de 1, 2, 3 y 4 saltos, respectiva-
mente. De pronto, A se desactiva o bien se corta el enlace entre A y B (que de hecho es lo mismo desde el
punto de vista de B).
En el primer intercambio de paquetes, B no escucha nada de A. Por fortuna, C dice: “No te preocupes.
Tengo una ruta hacia A de longitud 2”. B no sabe que la ruta de C pasa a través de B mismo. Hasta donde
B sabe, C puede tener 10 líneas, todas con rutas independientes hacia A de longitud 2. Como resultado,
ahora B piensa que puede llegar a A por medio de C, con una longitud de ruta de 3. D y E no actualizan
sus entradas para A en el primer intercambio.
En el segundo intercambio, C nota que cada uno de sus vecinos afirma tener una ruta de longitud 3
hacia A. C escoge una de ellas al azar y hace que su nueva distancia hacia A sea de 4, como se muestra en
la tercera fila de la figura 5-10(b). Los intercambios subsecuentes producen la historia que se muestra
en el resto de la figura 5-10(b).
A partir de esta figura debe quedar clara la razón por la que las malas noticias viajan con lentitud: no
hay ningún enrutador que tenga en algún momento un valor mayor en más de una unidad que el mínimo
de todos sus vecinos. Gradualmente, todos los enrutadores elevan su cuenta hacia el infinito, pero el
número de intercambios requerido depende del valor numérico usado para el infinito. Por esta razón, es
prudente hacer que el infinito sea igual a la ruta más larga, más 1.
No es del todo sorprendente que a éste se le conozca como el problema del conteo al infinito. Se
han dado muchos intentos por resolverlo; por ejemplo, evitar que los enrutadores anuncien sus mejores
rutas de vuelta a los vecinos de quienes las escucharon mediante la regla del horizonte dividido con
envenenamiento en reversa que se describe en el RFC 1058. Sin embargo, ninguna de estas heurís-
ticas funciona bien en la práctica a pesar de los nombres tan coloridos. El núcleo del problema es que,
cuando X dice a Y que tiene una ruta hacia alguna parte, Y no tiene forma de saber si él mismo está en
esa ruta.
5.2.5 Enrutamiento por estado del enlace
El enrutamiento por vector de distancia se utilizó en ARPANET hasta 1979, cuando se reemplazó por el
enrutamiento por estado del enlace. El principal problema que provocó su desaparición era que, con
frecuencia, el algoritmo tardaba demasiado en converger una vez que cambiaba la topología de la red
(debido al problema del conteo al infinito). En consecuencia, se reemplazó por un algoritmo totalmente
www.FreeLibros.me
Los mensajes ROUTER ADVERTISEMENT (ANUNCIO DE ENRUTADOR) y ROUTER SOLICI-

TATION (SOLICITUD DE ENRUTADOR) se usan para permitir que los hosts encuentren los enrutadores
cercanos. Un host necesita aprender la dirección IP de por lo menos un enrutador para enviar paquetes
por la red local.
Además de estos mensajes, se han definido otros. La lista en línea se conserva ahora en
www.iana.org/assignments/icmp-parameters.
ARP: Protocolo de Resolución de Direcciones
Aunque en Internet cada máquina tiene una o más direcciones IP, en realidad éstas no son suficientes
para enviar paquetes. Las NIC (Tarjetas de Interfaz de Red) de la capa de enlace de datos no entien-
den las direcciones de Internet. En el caso de Ethernet, cada NIC de las que se hayan fabricado viene
equipada con una dirección Ethernet única de 48 bits. Los fabricantes de NIC Ethernet solicitan un
bloque de direcciones Ethernet al IEEE para asegurar que no haya dos NIC con la misma dirección
(y evitar conflictos en caso de que las dos NIC aparezcan alguna vez en la misma LAN). Las NIC
envían y reciben tramas basadas en direcciones Ethernet de 48 bits. No saben nada sobre direcciones
IP de 32 bits.
La pregunta ahora es: ¿cómo se convierten las direcciones IP en direcciones de la capa de enlace de
datos, como Ethernet? Para explicar cómo funciona esto, veamos el ejemplo de la figura 5-61 en donde
se muestra una universidad pequeña con dos redes /24. Una red (CC) es una Ethernet conmutada y está
en el Departamento de Ciencias Computacionales. Tiene el prefijo 192.32.65.0/24. La otra LAN (IE),
que también es Ethernet conmutada, está en el Departamento de Ingeniería Eléctrica y tiene el prefijo
192.32.63.0/24. Las dos LAN están conectadas por un enrutador IP. Cada máquina en una Ethernet y cada
interfaz en el enrutador tienen una dirección única de Ethernet, etiquetadas de E1 a E6, además de una
dirección IP única en la red CC o IE.
Empecemos por ver cómo un usuario en el host 1 envía un paquete a un usuario en el host 2 de la
red CC. Supongamos que el emisor sabe el nombre del receptor pretendido, posiblemente algo así como
eagle.cc.uni.edu. El primer paso es encontrar la dirección IP para el host 2. Esta consulta es realizada por
IP1 = 192.32.65.7 IP3 = 192.32.63.3
E1 Switch E5
Ethernet Enrutador
Host 1 E3 E4 Host 3
Host 2 192.32.65.1 192.32.63.1 Host 4

Red CC Red IE
E2 192.32.65.0/24 192.32.63.0/24 E6
IP2 = 192.32.65.5 IP4 = 192.32.63.8
IP de Eth. de IP de Eth. de
Trama destino
origen origen destino
Host 1 a 2, en la red CC IP1 E1 IP2 E2
Host 1 a 4, en la red CC IP1 E1 IP4 E3
Host 1 a 4, en red IE IP1 E4 IP4 E6
Figura 5-61. Dos redes LAN Ethernet conmutadas, unidas por un enrutador.
www.FreeLibros.me
SEC. 5.6 LA CAPA DE RED DE INTERNET 401
el DNS, que estudiaremos en el capítulo 7. Por el momento supongamos que el DNS devuelve la dirección
IP del host 2 (192.32.65.5).
El software de la capa superior en el host 1 elabora ahora un paquete con 192.32.65.5 en el campo
Dirección de destino y lo entrega al software de IP para que lo transmita. El software IP puede buscar
la dirección y ver que el destino está en la red CC (es decir, su propia red). Pero de todas formas
necesita alguna manera de encontrar la dirección Ethernet de destino para enviar la trama. Una
solución es tener un archivo de configuración en alguna parte del sistema que asocie las direcciones IP
con direcciones Ethernet. Aun cuando esta solución es ciertamente posible, para las organizaciones con
miles de máquinas, conservar todos estos archivos actualizados es una tarea propensa a errores y
consume mucho tiempo.
Una mejor solución es que el host 1 envíe un paquete de difusión hacia Ethernet y pregunte
quién posee la dirección IP 192.32.65.5. La difusión llegará a cada máquina en la Ethernet CC y cada
una verificará su dirección IP. Al host 2 le bastará responder con su dirección de Ethernet (E2). De esta
manera, el host 1 aprende que la dirección IP 192.32.65.5 está en el host con la dirección Ethernet E2. El
protocolo utilizado para hacer esta pregunta y obtener la respuesta se llama ARP (Protocolo de Reso-
lución de Direcciones, del inglés Address Resolution Protocol). Casi todas las máquinas en Internet lo
ejecutan. La definición de ARP está en el RFC 826.
La ventaja de usar ARP en lugar de archivos de configuración es su simpleza. El administrador
del sistema sólo tiene que asignar a cada máquina una dirección IP y decidir respecto a las máscaras de
subred. ARP se hace cargo del resto.
A estas alturas, el software IP en el host 1 crea una trama Ethernet dirigida a E2, pone el paquete IP
(dirigido a 192.32.65.5) en el campo de carga útil y lo descarga hacia la Ethernet. Las direcciones IP y
Ethernet de este paquete se muestran en la figura 5-61. La NIC Ethernet del host 2 detecta esta trama, la
reconoce como una trama para sí mismo, la recoge y provoca una interrupción. El controlador de Ethernet
extrae el paquete IP de la carga útil y lo pasa al software IP, el cual ve que esté direccionado de forma
correcta y lo procesa.
Es posible hacer varias optimizaciones para que ARP trabaje con más eficiencia. Para empezar, una
vez que una máquina ha ejecutado ARP, guarda el resultado en caché, en caso de que tenga que ponerse
en contacto con la misma máquina en poco tiempo. La siguiente vez encontrará la asociación en su propio
caché, con lo cual se elimina la necesidad de una segunda difusión. En muchos casos, el host 2 necesitará
devolver una respuesta y se verá forzado también a ejecutar el ARP para determinar la dirección Ethernet
del emisor. Podemos evitar esta difusión de ARP haciendo que el host 1 incluya su asociación IP a Ether-
net en el paquete ARP. Cuando la difusión de ARP llega al host 2, se introduce el par (192.32.65.7, E1) en
la caché ARP del host 2. De hecho, todas las máquinas en Ethernet pueden introducir esta asociación
en su caché ARP.
Para permitir que las asociaciones cambien, por ejemplo, al configurar un host para que use una nueva
dirección IP (pero que mantenga su vieja dirección Ethernet), las entradas en la caché ARP deben expirar
después de unos cuantos minutos. Una manera inteligente de ayudar a mantener actualizada la informa-
ción en la caché y optimizar el desempeño es hacer que cada máquina difunda su asociación cuando se
configure. Por lo general, esta difusión se realiza en forma de un ARP que busca su propia dirección IP.
No debe haber una respuesta, pero un efecto colateral de la difusión es crear o actualizar una entrada en
la caché ARP de todos. A esto se le conoce como ARP gratuito. Si una respuesta llega (en forma inespe-
rada), quiere decir que se asignó la misma dirección IP a dos máquinas. El administrador de la red debe
resolver este error antes de que ambas máquinas puedan usarla.
Ahora veamos de nuevo la figura 5-61, sólo que esta vez el host 1 quiere enviar un paquete al host
4 (192.32.63.8) en la red IE. El host 1 verá que la dirección IP de destino no está en la red CC. Sabe
enviar todo ese tráfico fuera de la red al enrutador, el cual también se conoce como puerta de enlace
predeterminada. Por convención, la puerta de enlace predeterminada es la dirección más baja en la
www.FreeLibros.me
red (198.31.65.1). Para enviar una trama al enrutador, el host 1 debe conocer de todas formas la direc-
ción Ethernet de la interfaz del enrutador en la red CC. Para descubrirla envía una difusión ARP para
198.31.65.1, a partir de la cual aprende E3. Después envía la trama. Los mismos mecanismos de búsqueda
se utilizan para enviar un paquete de un enrutador al siguiente, a través de una secuencia de enrutadores
en una ruta de Internet.
Cuando la NIC Ethernet del enrutador recibe esta trama, entrega el paquete al software IP. Sabe
con base en las máscaras de red que el paquete se debe enviar a la red IE, en donde alcanzará al host 4. Si
el enrutador no conoce la dirección Ethernet para el host 4, entonces usará ARP de nuevo. La tabla en la
figura 5-61 lista las direcciones Ethernet e IP de origen y destino que están presentes en las tramas, como
se observa en las redes CC e IE. Observe que las direcciones Ethernet cambian con la trama en cada red,
mientras que las direcciones IP permanecen constantes (puesto que indican las terminales a través de
todas las redes interconectadas).
También es posible enviar un paquete del host 1 al host 4 sin que el primero sepa que el segundo está
en una red diferente. La solución es hacer que el enrutador responda a los ARP en la red CC para el host
4 y proporcione su dirección Ethernet, E3, como respuesta. No es posible hacer que el host 4 responda
directamente, ya que no verá la solicitud ARP (puesto que los enrutadores no reenvían difusiones a nivel
de Ethernet). A continuación, el enrutador recibirá las tramas enviadas a 192.32.63.8 y las reenviará a la
red IE. A esta solución se le conoce como ARP por proxy y se utiliza en casos especiales en los que un
host desea aparecer en una red, aun cuando en realidad reside en otra. Por ejemplo, una situación común
es una computadora móvil que desea que algún otro nodo recoja los paquetes por ella cuando no se en-
cuentre en su red local.
DHCP: el Protocolo de Configuración Dinámica de Host
ARP (así como los demás protocolos de Internet) asume que los hosts están configurados con cierta infor-
mación básica, como sus propias direcciones IP. ¿Cómo obtienen los hosts esta información? Es posible
configurar en forma manual cada computadora, pero es un proceso tedioso y propenso a errores. Existe
una mejor manera de hacerlo, conocida como DHCP (Protocolo de Configuración Dinámica de Host,
del inglés Dynamic Host Configuration Protocol ).
Con DHCP, cada red debe tener un servidor DHCP responsable de la configuración. Al iniciar una
computadora, ésta tiene integrada una dirección Ethernet u otro tipo de dirección de capa de enlace de datos
en la NIC, pero no cuenta con una dirección IP. En forma muy parecida al ARP, la computadora difunde una
solicitud de una dirección IP en su red. Para ello usa un paquete llamado DHCP DISCOVER. Este paquete
debe llegar al servidor DHCP. Si el servidor no está conectado directamente a la red, el enrutador se configu-
rará para recibir difusiones DHCP y transmitirlas al servidor DHCP en donde quiera que se encuentre.
Cuando el servidor recibe la solicitud, asigna una dirección IP libre y la envía al host en un paquete
DHCP OFFER (que también se puede transmitir por medio del enrutador). Para que esto pueda funcionar
incluso cuando los hosts no tienen direcciones IP, el servidor identifica a un host mediante su dirección
Ethernet (la cual se transporta en el paquete DHCP DISCOVER).
Un problema que surge con la asignación automática de direcciones IP de una reserva es determinar
qué tanto tiempo se debe asignar una dirección IP. Si un host sale de la red y no devuelve su dirección IP al
servidor DHCP, esa dirección se perderá en forma permanente. Después de un tiempo, tal vez se pierdan
muchas direcciones. Para evitar que eso ocurra, la asignación de direcciones IP puede ser por un periodo
fijo de tiempo, una técnica conocida como arrendamiento. Justo antes de que expire el arrendamiento,
el host debe pedir una renovación al DHCP. Si no puede hacer una solicitud o si ésta se rechaza, tal vez el
host ya no pueda usar la dirección IP que recibió antes.
El DHCP se describe en los RFC 2131 y 2132. Se utiliza ampliamente en Internet para configurar
todo tipo de parámetros, además de proporcionar a los hosts direcciones IP. Al igual que en las redes de
www.FreeLibros.me

Apuntes Parcial 1 Redes-De-Computadora

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Apuntes Parcial 1 Redes-De-Computadora

Hochgeladen von

Copyright:

Verfügbare Formate

Redes de computadoRas

ANDREW S. TANENBAUM DAVID J. WETHERALL

• La capa física (cobre, fibra óptica, inalámbricos, satélites, OFDM y CDMA).

Para mayor información, consulte la página Web de este libro en:

Alfonso Vidal Romero Elizondo

M. en C. Cyntia E. Enríquez Ortiz

ANDREW S. TANENBAUM y DAVID J. WETHERALL

PEARSON EDUCACIÓN, México, 2012

Formato: 20 3 25.5 cm Páginas: 816

Esta edición en español es la única autorizada.

QUINTA EDICIÓN, 2012

D.R. © 2012 por Pearson Educación de México, S.A. de C.V.

Cámara Nacional de la Industria Editorial Mexicana. Reg. núm. 1031.

ISBN VERSIÓN IMPRESA: 978-607-32-0817-8

Impreso en México. Printed in Mexico.

Para Katrim, Lucy y Pepper

*1.4.4 Comparación de los modelos de referencia OSI y TCP/IP 42

2.5.3 Multiplexión por división de frecuencia 114

3 LA CAPA DE ENLACE DE DATOS 167

4 LA SUBCAPA DE CONTROL DE ACCESO AL MEDIO 221

4.8 CONMUTACIÓN DE LA CAPA DE ENLACE DE DATOS 285

5 LA CAPA DE RED 305

5.6 LA CAPA DE RED DE INTERNET 374

6 LA CAPA DE TRANSPORTE 425

*6.6 ASPECTOS DEL DESEMPEÑO 500

7 LA CAPA DE APLICACIÓN 525

8 SEGURIDAD EN REDES 657

Servicio proporcionado por la capa k

Figura 1-19. La relación entre un servicio y un protocolo.

1.4 MODELOS DE REFERENCIA

1.4.1 El modelo de referencia OSI

Capa Nombre de la unidad

3 Red Red Red Red Paquete

2 Enlace de datos Enlace de datos Enlace de datos Enlace de datos Trama

1 Física Física Física Física Bit

Protocolo de host-enrutador de la capa de red

Figura 1-20. El modelo de referencia OSI.

La capa de enlace de datos

1.4.2 El modelo de referencia TCP/IP

6 Presentación No están presentes

2 Enlace de datos Enlace

Figura 1-21. El modelo de referencia TCP/IP.

La capa de interred define un formato de paquete y un protocolo oficial llamado IP (Protocolo de

Aplicación HTTP SMTP RTP DNS

Transporte TCP UDP

Enlace DSL SONET 802.11 Ethernet

Figura 1-22. El modelo TCP/IP con algunos de los protocolos.

1.4.3 El modelo utilizado en este libro

Figura 1-23. El modelo de referencia que usaremos en este libro.

1.4.4 Comparación de los modelos de referencia OSI y TCP/IP

1.4.5 Una crítica al modelo y los protocolos OSI

Figura 1-24. El apocalipsis de los dos elefantes.

1.4.6 Una crítica al modelo de referencia TCP/IP

1.5 REDES DE EJEMPLO

4.2 PROTOCOLOS DE ACCESO MÚLTIPLE

Colisión Tiempo Colisión

Colisiona con Colisiona con

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

Figura 4-2. Periodo vulnerable para la trama sombreada.

La probabilidad de que se generen k tramas durante un tiempo de trama determinado, en donde se

0.10 ALOHA puro: S = Ge–2G

0 0.5 1.0 1.5 2.0 3.0

El número esperado de transmisiones, E, por cada línea que se introduce en la terminal es

D.R. © 2012 por Pearson Educación de México, S.A. de C.V.