Re Des

PREFACIO
Resúmenes realizados usando una plantilla en LATEX creada por Miguel Yepes
Moyano orientada a la generación de la documentación de un proyecto (disponible en
la dirección http://www.uco.es/∼i12yemom), usando anjuta para la edición de texto,
desarrollada bajo linux y usando como fuente de información el libro de “Redes de
Computadoras" (Tanenbaum), las transparencias de la asignatura y apuntes tomados
en clase.
En cuanto a este documento se refiere, no son los apuntes de la asignatura, ni está
libre de errores, simplemente es un documento que he realizado en plan autodidacta,
para ir estudiándome la asignatura con más facilidad. Es un documento de libre dis-
tribución y si ha llegado a tus manos espero que te sea de ayuda, ten en cuenta lo
anterior y pásalo a quien quieras.
Un saludo:
I
II
REDES
Índice general
PREFACIO I
1. INTRODUCCIÓN A LAS REDES DE COMPUTADORAS 1

1.1. CONCEPTO DE RED DE COMPUTADORAS . . . . . . . . . . . . . 1
1.1.1. VENTAJAS DE LAS REDES DE COMPUTADORAS . . . . . 1
1.1.2. PROPIEDADES DESEADAS . . . . . . . . . . . . . . . . . . . 2
1.2. USOS DE LAS REDES DE COMPUTADORAS . . . . . . . . . . . . . 2
1.2.1. REDES PARA COMPAÑÍAS . . . . . . . . . . . . . . . . . . . 2
1.2.2. REDES PARA LA GENTE . . . . . . . . . . . . . . . . . . . . 3
1.2.3. CONSIDERACIONES SOCIALES . . . . . . . . . . . . . . . . 3
1.3. MODELO GENERAL DE COMUNICACIONES . . . . . . . . . . . . 3
1.3.1. COMPONENTES . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. TOPOLOGÍA DE REDES . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4.1. REDES PUNTO A PUNTO . . . . . . . . . . . . . . . . . . . . 5
1.4.2. REDES DE DIFUSIÓN . . . . . . . . . . . . . . . . . . . . . . 6
1.5. TIPOS DE REDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5.1. REDES DE ÁREA LOCAL (LAN) . . . . . . . . . . . . . . . . 7
1.5.2. REDES DE ÁREA METROPOLITANA (MAN) . . . . . . . . 7
1.5.3. REDES DE ÁREA AMPLIA (WAN) . . . . . . . . . . . . . . . 7
1.5.4. REDES INALÁMBRICAS . . . . . . . . . . . . . . . . . . . . . 8
1.6. PROBLEMÁTICA GENERAL DE LA COMUNICACIÓN. DEFINI-
CIÓN DE PROTOCOLO . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.6.1. SERVICIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.7. MODELOS DE REFERENCIA . . . . . . . . . . . . . . . . . . . . . . 12
1.7.1. MODELO DE REFERENCIA OSI . . . . . . . . . . . . . . . . 12
1.7.2. EL MODELO TCP/IP . . . . . . . . . . . . . . . . . . . . . . . 14
1.7.3. COMPARACIÓN ENTRE TCP/IP VS OSI . . . . . . . . . . . 15
III
IV ÍNDICE GENERAL
2. LA CAPA FÍSICA 17
2.1. BASE TEÓRICA DE LA COMUNICACIÓN DE DATOS . . . . . . . 17
2.1.1. CONCEPTOS BÁSICOS . . . . . . . . . . . . . . . . . . . . . 18
2.1.2. ANÁLISIS DE FOURIER . . . . . . . . . . . . . . . . . . . . . 18
2.1.3. PERTURBACIONES DE LA SEÑAL . . . . . . . . . . . . . . 20
2.2. MEDIOS DE TRANSMISIÓN . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.1. MEDIOS DE TRANSMISIÓN GUIADOS . . . . . . . . . . . . 24
2.2.2. MEDIOS DE TRANSMISIÓN NO GUIADOS. TRANSMISIÓN
INALÁMBRICA . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.3. SATÉLITES DE COMUNICACIONES . . . . . . . . . . . . . . 30
2.2.4. LA RED TELEFÓNICA CONMUTADA (RTPC) . . . . . . . . 33
2.3. TRANSMISIÓN ANALÓGICA Y DIGITAL. MODULACIÓN. . . . . . 35
2.3.1. COMUNICACIÓN ANALÓGICA . . . . . . . . . . . . . . . . . 35
2.3.2. COMUNICACIÓN DIGITAL . . . . . . . . . . . . . . . . . . . 38
2.4. MULTIPLEXACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.1. MULTIPLEXACIÓN POR DIVISIÓN DE FRECUENCIA . . . 41
2.4.2. MULTIPLEXACIÓN POR DIVISIÓN DE ONDA . . . . . . . . 42
2.4.3. MULTIPLEXACIÓN POR DIVISIÓN DE TIEMPO . . . . . . 43
2.4.4. TDM SONET/SDH . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.5. CONMUTACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.5. EL SISTEMA TELEFÓNICO MÓVIL . . . . . . . . . . . . . . . . . . 47
2.5.1. SISTEMA AVANZADO DE TELEFONÍA MÓVIL . . . . . . . 47
2.5.2. 2a GENERACIÓN. VOZ DIGITAL . . . . . . . . . . . . . . . . 48
2.5.3. GSM, SISTEMA GLOBAL PARA COMUNICACIONES MÓVILES 49
2.5.4. TELÉFONOS MÓVILES 3G: VOZ Y DATOS DIGITALES . . 50
3. LA CAPA DE ENLACE DE DATOS 51

3.1. FUNCIONES A DESEMPEÑAR POR LA C. ENLACE DE DATOS . 51
3.1.1. SERVICIOS QUE DEBE PROPORCIONAR A LA CAPA DE
RED . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.2. ENTRAMADO . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.1.3. CONTROL DE ERRORES . . . . . . . . . . . . . . . . . . . . 55
3.1.4. CONTROL DE FLUJO . . . . . . . . . . . . . . . . . . . . . . 55
3.2. DETECCIÓN Y CORRECCIÓN DE ERRORES . . . . . . . . . . . . 55
3.2.1. CÓDIGOS DE CORRECCIÓN DE ERRORES . . . . . . . . . 56
REDES
ÍNDICE GENERAL V
3.2.2. CÓDIGOS DE DETECCIÓN DE ERRORES . . . . . . . . . . 58

3.3. PROTOCOLOS BÁSICOS DE LA C. DE ENLACE DE DATOS . . . 60
3.3.1. DEFINICIONES PREVIAS . . . . . . . . . . . . . . . . . . . . 60
3.3.2. PROTOCOLO SIMPLEX SIN RESTRICCIONES . . . . . . . . 61
3.3.3. PROTOCOLO SIMPLEX DE PARADA Y ESPERA . . . . . . 62
3.3.4. PROTOCOLO SIMPLEX PARA UN CANAL RUIDOSO . . . 63
3.3.5. PROTOCOLOS DE VENTANA CORREDIZA . . . . . . . . . 65
3.4. EJEMPLOS DE PROTOCOLOS DE ENLACE DE DATOS . . . . . . 70
3.4.1. HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.4.2. LA CAPA DE ENLACE DE DATOS EN INTERNET . . . . . 72
3.5. SUBCAPA MAC: CONTROL DE ACCESO AL MEDIO . . . . . . . . 74
3.5.1. INTRODUCCIÓN . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.5.2. EL PROBLEMA DEL REPARTO DEL CANAL . . . . . . . . 76
3.5.3. REPARTO ESTÁTICO DEL CANAL . . . . . . . . . . . . . . 76
3.5.4. TÉCNICAS DE CONTIENDA. ALOHA Y CSMA . . . . . . . 76
3.5.5. TÉCNICAS DE SELECCIÓN . . . . . . . . . . . . . . . . . . . 80
3.5.6. PROTOCOLOS SIN COLISIONES . . . . . . . . . . . . . . . . 81
3.5.7. PROTOCOLOS DE LANs INALÁMBRICAS . . . . . . . . . . 81
3.6. IEEE 802.3: ETHERNET . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.6.1. CAPA FÍSICA ETHERNET . . . . . . . . . . . . . . . . . . . . 84
3.6.2. PROTOCOLO SUBCAPA MAC DE ETHERNET . . . . . . . 86
3.6.3. 802.3 CONMUTADA (ETHERNET CONMUTADA) . . . . . . 88
3.6.4. 302.3u (FAST ETHERNET) . . . . . . . . . . . . . . . . . . . . 88
3.6.5. IEEE 802.3z (GIGABIT ETHERNET) . . . . . . . . . . . . . . 89
3.6.6. IEEE 802.2: CONTROL LÓGICO DE ENLACE . . . . . . . . . 89
3.7. IEEE 802.11: LANS INALÁMBRICAS (WIFI) . . . . . . . . . . . . . . 90
3.7.1. LA PILA DE PROTOCOLOS . . . . . . . . . . . . . . . . . . . 90
3.7.2. CAPA FÍSICA . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.7.3. PROTOCOLO DE CAPA MAC . . . . . . . . . . . . . . . . . . 91
3.7.4. ESTRUCTURA DE TRAMA . . . . . . . . . . . . . . . . . . . 93
3.8. IEEE 802.15: BLUETOOTH . . . . . . . . . . . . . . . . . . . . . . . . 94
3.8.1. ARQUITECTURA BLUETOOTH . . . . . . . . . . . . . . . . 94
3.8.2. APLICACIONES BLUTETOOTH . . . . . . . . . . . . . . . . 95
3.8.3. LA PILA DE PROTOCOLOS DE BLUETOOTH . . . . . . . . 96
VI ÍNDICE GENERAL
3.8.4. ESTRUCTURA DE TRAMA BLUETOOTH . . . . . . . . . . 98

3.9. CONMUTACIÓN EN LA CAPA DE ENLACE . . . . . . . . . . . . . 98
3.9.1. PUENTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
3.9.2. RESUMEN DISPOSITIVOS DE INTERCONEXIÓN . . . . . . 100
4. LA CAPA DE RED 103

4.1. TEMAS DE DISEÑO EN LA CAPA DE RED . . . . . . . . . . . . . . 103
4.1.1. CONMUTACIÓN DE PAQUETES, ALMACENAMIENTO Y
ENVÍO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.1.2. SERVICIOS PROPORCIONADOS A LA CAPA DE TRANS-
PORTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.1.3. IMPLEMENTACIÓN DE UN SERVICIO NO ORIENTADO A
CONEXIÓN (NSOC) . . . . . . . . . . . . . . . . . . . . . . . . 105
4.1.4. IMPLEMENTACIÓN DE UN SERVICIO ORIENTADO A CO-
NEXIÓN (SOC) . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4.1.5. COMPARACIÓN DE LAS SUBREDES DE DATAGRAMAS Y
CIRCUITOS VIRTUALES . . . . . . . . . . . . . . . . . . . . . 108
4.2. ALGORITMOS DE ENRUTAMIENTO . . . . . . . . . . . . . . . . . 108
4.2.1. TIPOS DE ALGORITMOS DE ENRUTAMIENTO . . . . . . . 108
4.2.2. PRINCIPIO DE OPTIMIZACIÓN . . . . . . . . . . . . . . . . 109
4.2.3. ALGORITMOS ESTÁTICOS . . . . . . . . . . . . . . . . . . . 110
4.2.4. ALGORITMOS DINÁMICOS . . . . . . . . . . . . . . . . . . . 111
4.3. ALGORITMOS DE CONTROL DE CONGESTIÓN . . . . . . . . . . 119
4.3.1. PRINCIPIOS GENERALES DEL CONTROL DE CONGES-
TIONAMIENTO. . . . . . . . . . . . . . . . . . . . . . . . . . . 121
4.3.2. CONTROL DEL CONGESTIONAMIENTO EN LAS SUBRE-
DES DE CIRCUITOS VIRTUALES . . . . . . . . . . . . . . . 122
4.3.3. CONTROL DEL CONGESTIONAMIENTO EN LAS SUBRE-
DES DE DATAGRAMAS . . . . . . . . . . . . . . . . . . . . . 122
4.3.4. DESPRENDIMIENTO DE CARGA . . . . . . . . . . . . . . . 124
4.3.5. CONTROL DE LA FLUCTUACIÓN . . . . . . . . . . . . . . . 124
4.4. CALIDAD DEL SERVICIO: QoS . . . . . . . . . . . . . . . . . . . . . 125
4.4.1. ALMACENAMIENTO EN BÚFER . . . . . . . . . . . . . . . . 125
4.4.2. ALGORITMO DE CUBETA CON GOTEO . . . . . . . . . . . 126
4.4.3. ALGORITMO DE CUBETA CON TOKENS . . . . . . . . . . 127
4.4.4. CALENDARIZACIÓN DE PAQUETES . . . . . . . . . . . . . 129
REDES
ÍNDICE GENERAL VII
4.4.5. REENVÍO EXPÉDITO O ACELERADO . . . . . . . . . . . . 129

4.4.6. REENVÍO ASEGURADO . . . . . . . . . . . . . . . . . . . . . 130
4.5. LA CAPA DE RED DE INTERNET . . . . . . . . . . . . . . . . . . . 131
4.5.1. EL PROTOCOLO IP . . . . . . . . . . . . . . . . . . . . . . . 132
4.5.2. DIRECCIONES IP . . . . . . . . . . . . . . . . . . . . . . . . . 133
4.5.3. SUBREDES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.5.4. CIDR: ENRUTAMIENTO INTERDOMINIOS SIN CLASES . . 137
4.5.5. NAT: TRADUCCIÓN DE DIRECCIÓN DE INTERNET . . . . 139
4.5.6. PROTOCOLOS DE CONTROL EN INTERNET . . . . . . . . 140
4.5.7. PROTOCOLOS DE ENRUTAMIENTO EN INTERNET. OSPF
Y BGP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.5.8. MULTIDIFUSIÓN EN INTERNET . . . . . . . . . . . . . . . . 148
4.5.9. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
5. LA CAPA DE TRANSPORTE 153

5.1. EL SERVICIO DE TRANSPORTE . . . . . . . . . . . . . . . . . . . . 153
5.1.1. SERVICIOS PROPORCIONADOS A LAS CAPAS SUPERIORES153
5.1.2. PRIMITIVAS DE SERVICIO DE TRANSPORTE . . . . . . . . 155
5.2. ELEMENTOS DEL PROTOCOLO DE TRANSPORTE . . . . . . . . 160
5.2.1. DIRECCIONAMIENTO . . . . . . . . . . . . . . . . . . . . . . 161
5.2.2. ESTABLECIMIENTO DE LA CONEXIÓN . . . . . . . . . . . 162
5.2.3. Protocolo de acuerdo de tres vías . . . . . . . . . . . . . . . . . 163
5.2.4. LIBERACIÓN DE UNA CONEXIÓN . . . . . . . . . . . . . . 164
5.2.5. CONTROL DE FLUJO Y ALMACENAMIENTO EN BÚFER . 166
5.3. UN PROTOCOLO DE TRANSPORTE SENCILLO . . . . . . . . . . . 168
5.3.1. LA ENTIDAD DE TRANSPORTE DE EJEMPLO . . . . . . . 168
5.4. EL PROTOCOLO DE TRANSPORTE DE INTERNET UDP . . . . . 174
5.4.1. INTRODUCCIÓN A UDP . . . . . . . . . . . . . . . . . . . . . 174
5.4.2. RPC: LLAMADA A UN PROCEDIMIENTO REMOTO . . . . 175
5.4.3. RTP: PROTOCOLO DE TRANSPORTE EN TIEMPO REAL 176
5.5. EL PROTOCOLO DE TRANSPORTE DE INTERNET TCP . . . . . 178
5.5.1. EL MODELO DE SERVICIO TCP . . . . . . . . . . . . . . . . 178
5.5.2. EL PROTOCOLO TCP . . . . . . . . . . . . . . . . . . . . . . 180
5.5.3. LA CABECERA DE SEGMENTO TCP . . . . . . . . . . . . . 181
5.5.4. ESTABLECIMIENTO DE UNA CONEXIÓN TCP . . . . . . . 182
VIII ÍNDICE GENERAL
5.5.5. POLÍTICA DE TRANSMISIÓN DE TCP . . . . . . . . . . . . 184

5.5.6. CONTROL DE LA CONGESTIÓN TCP . . . . . . . . . . . . 185
5.6. TCP Y UDP INALÁMBRICOS . . . . . . . . . . . . . . . . . . . . . . 188
5.7. DESEMPEÑO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
5.7.1. PROBLEMAS DE DESEMPEÑO EN LAS REDES DE CÓM-
PUTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
5.7.2. MEDICIÓN DEL DESEMPEÑO DE LAS REDES . . . . . . . 191
5.7.3. DISEÑO DE SISTEMAS PARA UN MEJOR DESEMPEÑO . . 192
5.7.4. PROCESAMIENTO RÁPIDO DE LAS TPDU . . . . . . . . . 193
6. LA CAPA DE APLICACIÓN 197

6.1. SEGURIDAD DE LA RED . . . . . . . . . . . . . . . . . . . . . . . . 197
6.2. DNS: SISTEMA DE NOMBRES DE DOMINIO . . . . . . . . . . . . . 198
6.2.1. EL ESPACIO DE NOMBRES DNS . . . . . . . . . . . . . . . . 198
6.2.2. REGISTROS DE RECURSOS . . . . . . . . . . . . . . . . . . 200
6.2.3. SERVIDORES DE NOMBRES . . . . . . . . . . . . . . . . . . 202
6.3. CORREO ELECTRÓNICO . . . . . . . . . . . . . . . . . . . . . . . . 203
6.3.1. ARQUITECTURA Y SERVICIOS . . . . . . . . . . . . . . . . 204
6.3.2. EL AGENTE USUARIO . . . . . . . . . . . . . . . . . . . . . . 204
6.3.3. FORMATOS DE MENSAJE . . . . . . . . . . . . . . . . . . . 205
6.3.4. MIME: EXTENSIONES MULTIPROPÓSITO DE CORREO DE
INTERNET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
6.3.5. AGENTE DE TRANSFERENCIA DE MENSAJES . . . . . . . 208
6.3.6. POP3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.3.7. IMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
6.3.8. CARACTERÍSTICAS DE ENTREGA . . . . . . . . . . . . . . 213
6.4. WORLD WIDE WEB . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6.4.1. EL LADO DEL CLIENTE . . . . . . . . . . . . . . . . . . . . . 214
6.4.2. EL LADO DEL SERVIDOR . . . . . . . . . . . . . . . . . . . . 215
6.4.3. URLs: LOCALIZADORES UNIFORMES DE RECURSOS . . . 217
6.4.4. DOCUMENTOS WEB ESTÁTICOS. . . . . . . . . . . . . . . . 220
6.4.5. DOCUMENTOS WEB DINÁMICOS . . . . . . . . . . . . . . . 225
6.4.6. HTTP: PROTOCOLO DE TRANSFERENCIA DE HIPERTEX-
TO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
6.4.7. MEJORAS EN EL DESEMPEÑO . . . . . . . . . . . . . . . . 229
REDES
ÍNDICE GENERAL IX
6.4.8. LA WEB INALÁMBRICA . . . . . . . . . . . . . . . . . . . . . 230
7. INTERCONEXIÓN DE REDES 235

7.1. CIRCUITOS VIRTUALES CONCATENADOS . . . . . . . . . . . . . 237
7.2. ENTUNELAMIENTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
7.2.1. ENTUNELAMIENTO ENTRE REDES . . . . . . . . . . . . . 238
7.3. FRAGMENTACIÓN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
7.4. REDES ORIENTADAS A CONEXIÓN. RED X.25 . . . . . . . . . . . 241
7.5. REDES DE TRANSMISIÓN DE TRAMAS . . . . . . . . . . . . . . . 242
7.6. RED ATM. MODO DE TRANSFERENCIA ASÍNCRONO . . . . . . . 242
7.6.1. CIRCUITOS VIRTUALES ATM . . . . . . . . . . . . . . . . . 242
7.6.2. CELDAS ATM . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
7.6.3. MODELO DE REFERENCIA ATM . . . . . . . . . . . . . . . 244
7.7. SSL: CAPA DE SOCKETS SEGUROS . . . . . . . . . . . . . . . . . . 245
X ÍNDICE GENERAL
REDES
Índice de figuras
1.1. Modelo general de comunicaciones. . . . . . . . . . . . . . . . . . . . . 4

1.2. Redes punto a punto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Redes de difusión. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4. Elementos en las redes WAN. . . . . . . . . . . . . . . . . . . . . . . . 8
1.5. Esquema general de un sistema multicapa. . . . . . . . . . . . . . . . . 9
1.6. El modelo de referencia OSI. . . . . . . . . . . . . . . . . . . . . . . . . 12
1.7. El modelo de referencia TCP/IP. . . . . . . . . . . . . . . . . . . . . . 14
1.8. Protocolos y redes en el modelo TCP/IP inicial. . . . . . . . . . . . . . 15
2.1. Aproximaciones sucesivas por Fourier. . . . . . . . . . . . . . . . . . . . 19

2.2. Par trenzado no apantallado. . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3. Par trenzado blindado. . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4. Cable coaxial. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.5. Estructura de un cable de fibra ótica. . . . . . . . . . . . . . . . . . . . 26
2.6. Anillo de fibra óptica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.7. El espectro electromagnético. . . . . . . . . . . . . . . . . . . . . . . . 28
2.8. Comportamiento de las ondas según su frecuencia. . . . . . . . . . . . . 29
2.9. Ejemplo de comunicación bidireccional por láser. . . . . . . . . . . . . . 30
2.10. Clasificación y algunas propiedades de los satélites. . . . . . . . . . . . 31
2.11. Satélites VSAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.12. Esquema de cobertura de satélites Iridium. . . . . . . . . . . . . . . . . 32
2.13. Retransmisión por satélites Iridium y Globalstar. . . . . . . . . . . . . 33
2.14. Estructura del sistema telefónico. . . . . . . . . . . . . . . . . . . . . . 34
2.15. El Circuito o bucle Local. . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.16. Tipos de modulación. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.17. Diagramas de constelación. . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.18. V.32 y V.32 bis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
XI
XII ÍNDICE DE FIGURAS
2.19. División del espectro en DSL. . . . . . . . . . . . . . . . . . . . . . . . 39

2.20. Configuración ADSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.21. Esquema ejemplo FDM. . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.22. Esquema ejemplo WDM. . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.23. La portadora T1 (1.544 Mbps). . . . . . . . . . . . . . . . . . . . . . . 43
2.24. Multiplexación de corrientes T1 en portadoras más altas. . . . . . . . . 44
2.25. Conmutación de circuitos y de paquetes. . . . . . . . . . . . . . . . . . 45
2.26. Conmutación de circuitos (a), de mensajes (b) y de paquetes (c). . . . 46
2.27. (a) Ejemplo de división del espacio en celdas, (b) Ejemplo de subdivisión
de celdas en el caso de que sea necesario añadir más usuarios. . . . . . 48
2.28. Canales de frecuencia en GSM. . . . . . . . . . . . . . . . . . . . . . . 49
2.29. Estructura de entramado GSM. . . . . . . . . . . . . . . . . . . . . . . 50
3.1. (a) Comunicación virtual. (b) Comunicación real. . . . . . . . . . . . . 52

3.2. Corriente de caraceres. (a) Sin errores. (b) Con un error. . . . . . . . . 53
3.3. (a) Trama de datos usando relleno de caracteres. (b) Ejemplos de se-
cuencias de bytes antes y después del relleno de caracteres. . . . . . . . 54
3.4. (a) Relleno de bits. (b) Los datos, según aparecen en la línea. (c) Los
datos, como se guardan en memoria del receptor tras remover el relleno. 55
3.5. Uso de código Hamming en ráfagas para corregir errores. . . . . . . . . 57
3.6. Cálculo de la suma de comprobación de código polinómico. . . . . . . . 59
3.7. Ventana corrediza de tamaño 1, con un número de secuencia de 3 bits.
(a) Al inicio. (b) Tras la transmisión de la primera trama. (c) Tras la
recepción de la primera trama. (d) Tras recibir la primera confirmación
de recepción. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.8. Protocolo de ventana corrediza de un bit. (a) Caso normal. (b) Caso
anormal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.9. (a) Protocolo de retroceso N . Tamaño ventana receptor 1 y (b) Protocolo
de repetición selectiva. Tamaño ventana receptor N. . . . . . . . . . . . 70
3.10. Formato de marco para HDLC. . . . . . . . . . . . . . . . . . . . . . . 71
3.11. Campo de control de (a) un marco de control, (b) un marco de super-
visión, (c) un marco no numerado. . . . . . . . . . . . . . . . . . . . . 71
3.12. PC conectado a internet vía modem. . . . . . . . . . . . . . . . . . . . 72
3.13. Formato de marco PPP. . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.14. Esquema IEEE 802.1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.15. Normas IEEE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.16. ALOHA puro. Los marcos son transmitidos en momentos arbitrarios. . 77
REDES
ÍNDICE DE FIGURAS XIII
3.17. Periodo vulnerable para el marco sombreado en ALOHA. . . . . . . . . 78

3.18. Periodo vulnerable para el marco sombreado en ALOHA Ranurado. . . 79
3.19. CSMA/CD puede estar en tres estados: contención, transmisión o inactivo. 79
3.20. Esquema de funcionamiento de CSMA/CD. . . . . . . . . . . . . . . . 80
3.21. LAN inalámbrica. (a) A transmitiendo, (b) B transmitiendo. . . . . . . 82
3.22. El protocolo MACA. (a) A enviando a B un RTS. (b) B respondiendo
con un CTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.23. Tipos más comunes de LAN 802.3 de banda base. . . . . . . . . . . . . 84
3.24. El protocolo MACA. (a) A enviando a B un RTS. (b) B respondiendo
con un CTS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.25. Esquema de conexión 10Base-T. . . . . . . . . . . . . . . . . . . . . . . 85
3.26. (a) Codificación binaria. (b) Codificación Manchester. (c) Codificación
Manchester Diferencial. . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.27. Formato de marco 802.3. . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.28. La detección de una colisión puede tardar hasta 2τ . . . . . . . . . . . 87
3.29. Switch de 24 bocas. Dispositivo de capa 2. . . . . . . . . . . . . . . . . 88
3.30. (a) Posición del LLC. (b) Formatos de protocolos. . . . . . . . . . . . . 90
3.31. La pila de protocolos en 802.11. . . . . . . . . . . . . . . . . . . . . . . 91
3.32. CSMA/CA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.33. Método de la ráfaga de fragmentos. . . . . . . . . . . . . . . . . . . . . 93
3.34. Estructura de trama en 802.11. . . . . . . . . . . . . . . . . . . . . . . 93
3.35. Dos piconets se pueden conectar para conformar una scatternet. . . . . 95
3.36. Pila de protocolos Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . 96
3.37. Esructura de trama Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . 98
3.38. Lans conectadas mediante un backbone para manejar una carga total
mayor que la capacidad de una sola LAN. . . . . . . . . . . . . . . . . 99
3.39. Operación de un puente LAN de 302.3 a 802.4. . . . . . . . . . . . . . . 99
3.40. Configuración con cuatro LAN y dos puentes. . . . . . . . . . . . . . . 100
3.41. (a) Concentrador. (b) Puente. (c) Conmutador. . . . . . . . . . . . . . 100
3.42. Dispositivos de interconexión de redes y capa donde trabajan. . . . . . 101
4.1. Esquema de envío de un paquete de H1 a H2. . . . . . . . . . . . . . . 104

4.2. Enrutamiento dentro de una red de datagramas . . . . . . . . . . . . . 106
4.3. Enrutamiento dentro de una subred de circuitos virtuales. . . . . . . . 107
4.4. (a) Una subred. (b) Arbol sumidero para el enrutador B. . . . . . . . . 109
XIV ÍNDICE DE FIGURAS
4.5. Los primeros cinco pasos del cálculo de la trayectoria más corta de A a
B. Las flechas indican el nodo de trabajo. . . . . . . . . . . . . . . . . . 110
4.6. (a) Subred. (b) Entrada de A, I, H, K, y la nueva tabla de enrutamiento
de J. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
4.7. (a) Subred. (b) Paquetes de estado del enlace para esta subred. . . . . 113
4.8. Buffer de paquetes para el enrutador B de la figura 4-7. . . . . . . . . 114
4.9. Enrutamiento jerárquico. . . . . . . . . . . . . . . . . . . . . . . . . . . 115
4.10. Reenvío por trayectoria invertida. (a) Subred. (b) Árbol de extensión.
(c) Árbol construido mediante reenvío por trayectoria invertida. . . . . 116
4.11. (a) Subred. (b) Árbol de expansión del enrutador extremo izquierdo. (c)
Árbol de multidifusión del grupo 1. (d) Árbol de multidifusión del grupo
2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
4.12. WAN a la que están conectadas LAN, MAN y células inalámbricas. . . 118
4.13. Enrutamiento de paquetes para usuarios móviles. . . . . . . . . . . . . 119
4.14. Cuando se genera demasiado tráfico ocurren congestionamientos y se
degrada marcadamente el desempeño. . . . . . . . . . . . . . . . . . . . 120
4.15. (a) Subred congestionada. (b) Subred redibujada que elimina el conges-
tionamiento y circuito virtual de A a B. . . . . . . . . . . . . . . . . . 122
4.16. (a)El paquete regulador que sólo afecta al origen. (b) Paquete regulador
salto por salto que afecta cada escala por la que pasa. . . . . . . . . . . 123
4.17. (a) Alta fluctuación. (b) Baja fluctuación. . . . . . . . . . . . . . . . . 124
4.18. Refinamiento del flujo de paquetes almacenándolos en el búfer. . . . . . 125
4.19. (a) Una cubeta con goteo, llena de agua. (b) Cubeta con goteo, llena de
paquetes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
4.20. Algoritmo de cubeta con goteo. (a) Entrada. (b) Salida. . . . . . . . . . 127
4.21. Algoritmo de cubeta con tokens. (a) Antes. (b) Después. . . . . . . . . 128
4.22. Salida de una cubeta con fichas con capacidades de (a) 250 kB, (b) 500
kB, (c) 750 kB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
4.23. (a) Enrutador con cinco paquetes encolados para la línea O. (b) Tiempos
de terminación de los cinco paquetes. . . . . . . . . . . . . . . . . . . . 129
4.24. Esquema del algoritmo de reenvío expédito o acelerado. . . . . . . . . . 130
4.25. Ejemplo de implementación del algoritmo de reenvío asegurado. . . . . 130
4.26. Internet es un conjunto interconectado de muchas redes. . . . . . . . . 131
4.27. La cabecera de IP (protocolo de Internet). . . . . . . . . . . . . . . . . 132
4.28. Formatos de dirección IP. . . . . . . . . . . . . . . . . . . . . . . . . . 134
4.29. Direcciones IP especiales. . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.30. Una red de un campus que consiste de LANs de varios departamentos. 136
REDES
ÍNDICE DE FIGURAS XV
4.31. Red de clase B dividida en 64 subredes. . . . . . . . . . . . . . . . . . . 136

4.32. Conjunto de asignaciones de IP. . . . . . . . . . . . . . . . . . . . . . . 137
4.33. Tablas de enrutado actualizadas de acuerdo con CIDR. . . . . . . . . . 138
4.34. Colocación y funcionamiento de una caja NAT. . . . . . . . . . . . . . 140
4.35. Tres redes de clase C /24 interconectadas; dos Ethernet y un anillo FDDI.141
4.36. Funcioamiento de DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.37. (a) Sistema autónomo. (b) Representación con grafos de (a). . . . . . . 144
4.38. Relación entre los AS, los backbone y las áreas OSPF. . . . . . . . . . 146
4.39. (a) Grupo de enrutadores BGP. (b) Información enviada a F . . . . . . 148
4.40. Cabecera fija del IPv6 (obligatoria). . . . . . . . . . . . . . . . . . . . . 150
4.41. Encabezados de extensión IPv6. . . . . . . . . . . . . . . . . . . . . . . 151
5.1. Capas de red, transporte y aplicación. . . . . . . . . . . . . . . . . . . . 154

5.2. Primitivas de un servicio de transporte sencillo. . . . . . . . . . . . . . 155
5.3. Anidamiento de las TPDU, los paquetes y los marcos. . . . . . . . . . . 156
5.4. Primitvas de socket para TCP. . . . . . . . . . . . . . . . . . . . . . . . 156
5.5. (a) Entorno de la capa de enlace de datos. (b) Entorno de la capa de
transporte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
5.6. Los TSAP, NSAP y conexiones. . . . . . . . . . . . . . . . . . . . . . . 161
5.7. Tres escenarios para establecer una conexión usando un protocolo de
acuerdo de tres vías. (a) Operación normal. (b) SOLICITUD DE CO-
NEXIÓN duplicada vieja que aparece de la nada. (c) SOLICITUD DE
CONEXIÓN duplicada y ACK duplicada. . . . . . . . . . . . . . . . . 163
5.8. Problema de los dos ejércitos. . . . . . . . . . . . . . . . . . . . . . . . 164
5.9. (a) Caso normal del acuerdo de tres vías. (b) Se pierde el último ACK,
en este caso el temporizador salva la situación. Cuando este expira la
conexión se libera de todos modos. . . . . . . . . . . . . . . . . . . . . 165
5.10. (c) Pérdida de segunda DR, el usuario que inicia la desconexión no
recibirá la respuesta esperada, su temporizador expira y el proceso comein-
za de nuevo. (d) Caso crítico: todos los intentos repetidos de retransmitir
fallan. Tras N reintentos, el emisor se da por vencido y libera la conexión,
lo mismo ocurre en el receptor. . . . . . . . . . . . . . . . . . . . . . . 166
5.11. (a) Búferes encadenados de tamaño fijo. (b) Búferes encadenados de
tamaño variable. (c) Un gran búfer circular por conexión. . . . . . . . . 167
5.12. Asignación dinámica de ventanas con No secuencia 4 bits. Las flechas
muestran la dirección de la transmisión. Los puntos suspensivos (. . . )
indican una TPDU perdida. . . . . . . . . . . . . . . . . . . . . . . . . 168
5.13. La cabecera UDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
XVI ÍNDICE DE FIGURAS
5.14. Pasos para realizar una llamada a procedimiento remoto. . . . . . . . . 175

5.15. (a) Posición de RTP n la pila de protocolos. (b) Anidamiento de paquetes.176
5.16. El encabezado RTP (3 palabras de 32 bits y algunas extensiones). . . . 177
5.17. Algunos puertos bien conocidos y servicios asociados. . . . . . . . . . . 179
5.18. (a) Cuatro segmentos de 512 bytes enviados como datagramas indepen-
dientes. (b) Los 2048 bytes de datos se entregan a la aplicación en una
sola llamada a READ. . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
5.19. Cabecera TCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
5.20. Pseudocabecera incluida en la suma de comprobación del TCP. . . . . . 182
5.21. (a) Establecimiento de una conexión TCP en el caso normal. (b) Colisión
de llamadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.22. Síndrome de ventana tonta. . . . . . . . . . . . . . . . . . . . . . . . . 185
5.23. (a) Red rápida alimentando un receptor de baja capacidad. (b) Red
lenta alimentando un receptor de alta capacidad. . . . . . . . . . . . . 186
5.24. Ejemplo de algoritmo de congestión en internet. . . . . . . . . . . . . . 188
5.25. División de una conexión TCP en dos conexiones. . . . . . . . . . . . . 189
5.26. Estados de transmisión de un megabit de San Diego a Boston. (a) En
t = 0. (b) Tras 500 µsec. (c) Tras 20 msec. (d) Tras 40 msec. . . . . . . 191
5.27. Cuatro combinaciones de contexto para manejar un paquete con un ad-
ministrador de red de espacio de usuario. . . . . . . . . . . . . . . . . . 193
5.28. La trayectoria rápida del emisor al receptor se indica con una línea grue-
sa. Los pasos de procesamiento de esta trayectoria se muestran sombrea-
dos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5.29. (a) Encabezado TCP. (b) Encabezado IP. En ambos casos, los campos
sombreados se toman sin cambios del prototipo. . . . . . . . . . . . . . 195
6.1. Parte del espacio de nombres de dominio de Internet. . . . . . . . . . . 199

6.2. Tipos principales de registro de recurso DNS. . . . . . . . . . . . . . . 200
6.3. Parte de una posible base de datos DNS para cs.vu.nl. . . . . . . . . . 201
6.4. Parte del espacio de nombres DNS, donde se muestra la división de zonas.202
6.5. Manera en que un resolvedor busca un nombre remoto en 8 pasos. . . . 203
6.6. Algunos emoticonos ASCII. . . . . . . . . . . . . . . . . . . . . . . . . 203
6.7. Campos de cabecera de RFC 822 relacionados con el transporte de men-
sajes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
6.8. Algunos campos usados en la cabecera de mensaje RFC 822. . . . . . . 205
6.9. Cabeceras RFC 822 agregadas por MIME. . . . . . . . . . . . . . . . . 206
6.10. Mensaje multiparte que contiene alternativas de texto enriquecido y audio.208
REDES
ÍNDICE DE FIGURAS XVII
6.11. Transferencia de un mensaje de elinore@abc.com a carolyn@xyz.com. . . 210

6.12. (a) Envío y recepción de correo cuando el receptor tiene una conexión
permanente a Internet y el agente de usuario se ejecuta en la misma
máquina que el agente de transferencia de mensajes. (b) Lectura de
correo cuando el receptor tiene una conexión de acceso telefónico a una
ISP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
6.13. Uso de POP3 para obtener tres mensajes. . . . . . . . . . . . . . . . . 212
6.14. (a) Un plug-in de navegador. (b) Una aplicación auxiliar. . . . . . . . . 215
6.15. Las partes del modelo Web. . . . . . . . . . . . . . . . . . . . . . . . . 216
6.16. Un servidor Web con múltiples subprocesos con un frontend y módulos
de procesamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
6.17. Granja de servidores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
6.18. Algunas URLs comunes. . . . . . . . . . . . . . . . . . . . . . . . . . . 218
6.19. HTML para una página Web de ejemplo. . . . . . . . . . . . . . . . . . 221
6.20. Página con formato. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
6.21. Selección de etiquetas HTML comunes. . . . . . . . . . . . . . . . . . . 222
6.22. Página Web simple en XML. . . . . . . . . . . . . . . . . . . . . . . . . 223
6.23. Una hoja de estilo XSL. . . . . . . . . . . . . . . . . . . . . . . . . . . 224
6.24. Pasos en el procesamiento de información de un formulario HTML. . . 225
6.25. (a) Una página Web que contiene un formulario. (b) Un script en PHP
para manejar la salida del formulario (c) Salida de la secuencia de co-
mandos PHP cuando las entradas son “Barbara" y 24. . . . . . . . . . . 226
6.26. Uso de JavaScript para procesar un formulario. . . . . . . . . . . . . . 226
6.27. Un programa en JavaScript para calcular e imprimir factoriales. . . . . 227
6.28. Una página Web interactiva que responde al movimiento del ratón. . . 227
6.29. Las diversas formas de generar y desplegar contenido. . . . . . . . . . . 228
6.30. Los métodos de solicitud HTTP integrados. . . . . . . . . . . . . . . . 228
6.31. Almacenamiento en caché jerárquico con tres proxies. . . . . . . . . . . 229
6.32. Pasos de la búsqueda de una URL cuando se utiliza una CDN. . . . . . 230
6.33. La pila de protocolos WAP. . . . . . . . . . . . . . . . . . . . . . . . . 231
6.34. Arquitectura WAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
6.35. WAP 2.0 soporta dos pilas de protocolos. . . . . . . . . . . . . . . . . . 233
7.1. Dos Ethernet conectadas. (a) Usando un switch. (b) Usando un router. 236
7.2. Circuitos virtuales concatenados. . . . . . . . . . . . . . . . . . . . . . 237
7.3. Entunelamiento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
XVIII ÍNDICE DE FIGURAS
7.4. Ejemplo ilustrativo de entunelamiento. . . . . . . . . . . . . . . . . . . 238

7.5. (a) Redes interconectadas. (b) Grafo equivalente. . . . . . . . . . . . . 239
7.6. (a) Fragmentación transparente. (b) Fragmentación a través de las puer-
tas de enlace. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
7.7. Fragmentación cuando el tamaño de datos elemental es de 1 byte. (a)
Paquete original con 10 bytes de datos. (b) Fragmentos tras pasar a
través de una red con un tamaño mñaximo de 8 bytes de carga útil más
encabezado. (c) Fragmentos tras pasar a través de una puerta de enlace
de tamaño cinco. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
7.8. Ejemplo de circuito virtual. . . . . . . . . . . . . . . . . . . . . . . . . 243
7.9. Celda ATM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
7.10. Modelo de referencia ATM. . . . . . . . . . . . . . . . . . . . . . . . . 245
REDES
INTRODUCCIÓN A LAS REDES DE
COMPUTADORAS
1.1. CONCEPTO DE RED DE COMPUTADORAS

Una red de computadoras es un conjunto de computadoras autónomas conectadas
mediante una o más vías de comunicación de cualquier tipo (cable de cobre, fibra
óptica, satélites. . . ). El principal objetivo de una red de comunicación es el intercambio
de información entre ordenadores y terminales.
No se considera una red a un sistema basado en el modelo maestro-excavo o una
computadora grande com impresoras y terminales remotas.
1.1.1. VENTAJAS DE LAS REDES DE COMPUTADORAS

Eliminación de la dispersión geográfica: Para organizaciones situadas en distintas
zonas geográficas se hace posible el intercambio de información entre los distintos
terminales.
Compartir recursos.
Tolerancia a fallos: Si un ordenador falla, otro podría asumir sus funciones y

carga de procesamiento.
1
2 1.2. USOS DE LAS REDES DE COMPUTADORAS
Entorno de trabajo flexible: Un empleado podría trabajar en su casa accediendo,

mediante una re, a los ordenadores de las oficinas.
1.1.2. PROPIEDADES DESEADAS
Ámbito: Una arquitectura de red debería resolver tantos problemas generales

como sea posible.
Escalabilidad: Una red debe funcionar bien de forma independiente del número
de nodos que la componga.
Robustez: El diseño de una red debería permitir el buen funcionamiento de la
misma a pesar de que hayan nodos defectuosos.
Auto-configuración y Optimización: Una red deberá tener la mínima inter-
vención del administrador. A su vez, deberá tener una serie de parámetros que
permitan al administrador ajustarlos para obtener así una configuración óptima
para unas y otras redes de acuerdo a sus características.
Migración: Si se decide cambiar de red, la migración no debe verse afectada en
sus propiedades y funcionamiento.
Determinismo: Bajo unas mismas condiciones, la red siempre debe funcionar
igual.
1.2. USOS DE LAS REDES DE COMPUTADORAS
1.2.1. REDES PARA COMPAÑÍAS

Para compañías con varias sucursales en distintas zonas geográficas es importante
poder disponer de datos de cada sucursal de forma global. En estos casos se pretende
compartir una serie de recursos y estos podrían ser no solo datos, sino también progra-
mas o incluso el equipo de cada sucursal. De esta forma la empresa podría asumir el
problema de la dispersión geográfica.
Otro posible uso sería la búsqueda de una mayor confiabilidad, distribuyendo los
datos en varias máquinas de forma que se pueden afrontar fallos hardware sin pérdida
de datos.
Un uso muy extendido últimamente es para sustituir los costosos mainframes por
una serie de ordenadores personales en red que desempeñan su función. Es el modelo
“cliente servidor". Al usar el modelo cliente servidor se puede ampliar la red, en caso de
que se necesite una mayor carga de trabajo, de forma fácil (con los mainframes habría
que sustituirlos por otros mayores).
El uso de redes proporciona a los trabajadores un potente medio de comunicación
pudiendo desempeñar una misma tarea varios trabajadores en distintas zonas geográ-
ficas.
REDES
1.2.2. REDES PARA LA GENTE
Para una compañía la principal ventaja en el uso de redes es la economía. Para un

usuario individual, el uso de una red es muy distinto, estando entre los más destacados
los siguientes usos:
1. Acceso a información remota.
2. Comunicación persona a persona.
3. Entretenimiento interactivo.
En los últimos años se le ha abierto un extenso abanico de posibilidades a un

usuario con el desarrollo de la red mundial (World Wide Web) lo que ha provocado
una gran evolución y cambio en la forma de comunicación (correo web, videoconferen-
cias. . . ) además de ofrecérsele otros muchos nuevos servicios (leer el periódico, acceder
a foros de discusión, juegos on-line. . . entre otros muchos).
1.2.3. CONSIDERACIONES SOCIALES
La introducción ampliamente difundida de redes ha significado nuevos problemas

sociales, éticos y políticos. Se ha puesto al alcance de cualquier persona una nueva
libertad, que al igual que la imprenta hace 500 años, se le permite a un ciudadano
distribuir sus puntos de vista en diferentes formas y a diferentes públicos que antes
estaba fuera de su alcance y que trae consigo muchos problemas sociales, políticos y
morales aún no resueltos.
1.3. MODELO GENERAL DE COMUNICACIONES
El objetivo principal de todo sistema de comunicación es intercambiar información

entre dos entidades. En el siguiente esquema se representan los diferentes integrantes
en tal intercambio de información.
4 1.4. TOPOLOGÍA DE REDES
Figura 1.1: Modelo general de comunicaciones.
1.3.1. COMPONENTES
Equipo Terminal de Datos (ETD): Máquina de usuario final. Es el dispositivo
que va a recibir/transmitir información a través de la red. La finalidad de toda
la red es poder conectar varios ETD entre sí.
Equipo Terminal del Circuito de Datos (ETCD): Su función es conectar
los ETD al canal o línea de comunicación sirviendo de interfaz entre ETD y toda
la red.
Conexiones: Pueden ser físicas y lógicas. Las aplicaciones y los archivos usan
las conexiones físicas para poder realizar las comunicaciones lógicas.
1.4. TOPOLOGÍA DE REDES

A la forma de interconectar las computadoras de una red se denomina topología
de red. Existen distintos tipos de topologías y según las funciones a realizar se optará
por uno u otro.
Los objetivos perseguidos al seleccionar un tipo de topología de red son:
Proporcionar la máxima fiabilidad a la hora de etablecer el tráfico.

Encaminar el tráfico utilizando la vía de coste mínimo entre las ETD.
Proporcionar al usuario un rendimiento óptimo y un tiempo de respuesta mínimo.
Se pueden diferenciar dos familias de redes:
REDES
1. Redes punto a punto: Redes formadas por pares de conexiones dedicadas entre
cada dos pares de máquinas.
2. Redes de difusión: Utilizan un medio físico de transmisión común para todas

las máquinas.
Cada una de estas familias admite, a su vez, distintas configuraciones a la hora de

conectarse.
1.4.1. REDES PUNTO A PUNTO
Figura 1.2: Redes punto a punto.
TOPOLOGÍA JERÁRQUICA O EN ÁRBOL
Muy limitada. En la mayoría de los casos hay un ETD de mayor nivel (raiz), que
controla toda la red.
Presenta problemas de cuello de botella y de fiabilidad (si falla el nodo raíz la red
se viene abajo).
Supone una ventaja en cuanto a la escalabilidad ya que es muy simple añadir
nuevos elementos a la red.
TOPOLOGÍA EN ESTRELLA
Es muy sencilla de controlar y el flujo de tráfico es relativamente menor por surgir

del centro de la estrella. Es semejante a la topología jerárquica, aunque más limitada
en cuanto a posibilidades de procesamiento distribuido.
El nodo central se encarga de controlar el tráfico y ocuparse de las averías siendo
esto relativamente fácil.
Esta topología sufre problemas de cuello de botella y fiabilidad, pero son solventa-
bles añadiendo un nodo reserva.
6 1.4. TOPOLOGÍA DE REDES
Ofrece ventajas en cuanto a la escalabilidad, evolucionando a la topología en es-

trella extendida, donde varios nodos de la estrella se convierten en nodos centrales de
otras estrellas, creándose así varios niveles.
TOPOLOGÍA EN MALLA
Su principal atractivo reside en la inmunidad a fallos debido a que es posible el

encaminado por múltiples rutas, pero tiene un problema, y es que necesita un software
de control bastante complejo y no favorece demasiado la escalabilidad.
1.4.2. REDES DE DIFUSIÓN
Figura 1.3: Redes de difusión.
TOPOLOGÍA EN ANILLO
El flujo de datos circula en una única dirección. Está formado por pares de co-
nexiones dedicadas entre pares de DTD vecions, actuando cada uno como repetidor.
El software de control es complicado, y por norma general, necesita un ETD que
actúe como controlador, siendo esto un punto de debilidad.
Una versión de esta topología es en anillo dual.
TOPOLOGÍA EN BUS
El medio físico está dispuesto de forma lineal y todas las estaciones pueden recibir
todas las transmisiones que se están realizando en el canal.
El hecho de que haya un único medio físico es un punto de debilidad puesto que
si éste falla la red deja de funcionar.
Otro problema es el aislamiento de fallos debido a la ausencia de puntos de con-
centración.
REDES
TOPOLOGÍA CELULAR
Surge con las redes inalámbricas y consiste en la división del espacio en células,
cada una de ellas centrada en una estación emisora/receptora base conectada a una
red troncal.
Cada célula debe tener una frecuencia distinta para evitar posibles interferencias
en las fronteras.
1.5. TIPOS DE REDES
1.5.1. REDES DE ÁREA LOCAL (LAN)
Redes de difusión, generalmente de caracter privado, de una extensión de pocos

kilómetros. Se utilizan para conectar PC’s con el objetivo de compartir recursos.
Se ejecutan a una velocidad de 10 a 100 Mbps (las nuevas alcanzan los 10 Gbps.
1.5.2. REDES DE ÁREA METROPOLITANA (MAN)
Versión mejorada de las LAN con el objetivo de abarcar una extensión geográfica
mayor. Tienen prácticamente las mismas características que las LAN y se usan para
proporcionar servicios de internet, teléfono o televisión.
1.5.3. REDES DE ÁREA AMPLIA (WAN)
Son redes punto a punto que se extienden por un área geográfica extensa (países,
regiones. . . ) diseñadas con el objetivo de proporcionar conectividad continua con los
servicios locales y compartir recursos. Ejemplos de redes WAN son la red de telefonía
conmutada, la red digital de servicios integrados (RDSI), la red de conmutación de
paquetes X.25, etc.
1.6. PROBLEMÁTICA GENERAL DE LA COMUNICACIÓN.
8 DEFINICIÓN DE PROTOCOLO
ELEMENTOS EN LAS REDES WAN
Figura 1.4: Elementos en las redes WAN.
Líneas de Transmisión (Circuitos): Transmiten los bits de una máquina a

otra.
Elementos de Conmutación: Computadoras especializadas que conectan dos

o más líneas de transmisión.
Sistemas Finales: Componentes de red que proporcionan la interfaz de conexión

a la red de los usuarios finales.
1.5.4. REDES INALÁMBRICAS

Se dividen en tres categorías:
PAN’s Inalámbricas: Bluetooth
LAN’s Inalámbricas.
WAN’s Inalámbricas.
1.6. PROBLEMÁTICA GENERAL DE LA COMU-

NICACIÓN. DEFINICIÓN DE PROTOCOLO
Cuando se realiza un intercambio de datos entre dos ETD hay que tener en cuenta
muchas cuestiones y la realización de una serie de tareas. Entre ellas:
1. El sistema fuente debe activar el camino de datos.
2. El sistema fuente debe ver que el receptor está preparado para recibir.
REDES
3. Los programas de nivel superior deben estar preparados para recibir y almacenar
la información.
4. Debe haber una adaptación para posibles incompatibilidades
5. etc.
Para resolver estos problemas, en las primeras redes de computadoras, se propone

una solución hardware debido, entre otros motivos, a que tenían un grado de comple-
jidad mucho menor al de las redes actuales, pero en la actualidad se ha tenido que
recurrir a una solución software: se ha propuesto un modelo de resolución de forma
general mediante un diseño por capas, donde cada capa resolverá una serie de proble-
mas muy relacionados entre sí, haciendo uso de los servicios que le proporciona la capa
inmediatamente inferior.
Este sería el esquema general de modelo de resolución:
Figura 1.5: Esquema general de un sistema multicapa.
Antes de hablar de sistemas multicapas debemos hacer referencia a una serie de

conceptos íntimamente ligados con este concepto:
Servicio:
Indica qué hace la capa, o sea qué servicios brinda a la capa superior, no la
forma en que la capa superior tiene acceso al servicio. Define el aspecto semántico
(significado) de la capa.
1.6. PROBLEMÁTICA GENERAL DE LA COMUNICACIÓN.
10 DEFINICIÓN DE PROTOCOLO
Interfaz:
La comunicación entre dos capas contiguas se realiza mediante una interfaz de
capa, que define cuales operaciones o servicios ofrecen la capa superior o inferior.
La misión de las interfaces es optimizar e impedir el acoplamiento entre capas (si
una capa es modificada que no se vean afectadas las capas contiguas).
Las entidades intercambian información a través de bloques de datos denominados
UDI (Unidad de datos de la interfaz), constituida a partir de un fragmento de
información denominado ICI (Información de control de protocolo), seguido de
la UDP (Unidad de datos de protocolo) en el caso de que haya transmisión.
En una interfaz típica, la entidad de la capa n+1 pasa información a la entidad
de la capa n a través del PAS (Puerta de acceso al servicio).
Protocolo:
Realiza los servicios que cada capa debe realizar, pero desde un punto de vista
de diseño, sin tener en cuenta la implementación real de dichos servicios.
Al conjunto de reglas y convenciones que articulan el intercambio de datos entre
dos entidades homólogas (elementos activos en la misma capa en los dos extremos
de la conexión) se denomina protocolo.
Características:
• Sintaxis: Formato de los bloques de datos intercambiados. El bloque de

datos intercambiado se denomina UDP (unidad de datos del protocolo) y
está formado por:
1. ICP: Información de control de protocolo.
2. UDS: Unidad de datos de servicio.
3. Semántica: Información de control para la coordinación y de errores así
como el significado de los datos situados en el ICP.
4. Temporización: Sintonización de velocidades y secuenciación en el in-
tercambio de datos.
1.6.1. SERVICIOS
TIPOS DE SERVICIOS
Las capas pueden ofrecer dos tipos diferentes de servicios alas capas que se en-
cuentran sobre ellas, los orientados a la conexión y los que carecen de conexión.
Servicios orientados a la conexión:

El usuario establece una conexión, la utiliza y luego la abandona. Por lo general
un lado hace una propuesta y el otro la acepta, rechaza. Hay implícita una reserva
de un recurso, físico o lógico. Se concibió como base en el sistema telefónico.
Servicios no orientados a la conexión:

Se lleva a cabo el intercambio de información sin reserva previa de ningún tipo
de recurso.
REDES
FIABILIDAD
Cada servicio se puede caracterizar por una calidad de servicio. Algunos servicios
son confiables en el sentido de que nunca pierden datos. Usualmente, un servicio confi-
able se implementa haciendo que el receptor acuse el recibo de cada mensaje, de modo
que el emisor esté seguro de que llegó.
El otro tipo de servicio es no confiable, y es aquel servicio que no garantiza que el
paquete a transmitir llegue a su destino. A esos servicios se les suele llamar servicios
de datagramas.
PRIMITIVAS DE LOS SERVICIOS
Un servicio se especifica de manera formal con un conjunto de primitivas u op-

eraciones disponibles para que un usuario u otra entidad acceda al servicio.
Las primitivas pueden tener parámetros. Por ejemplo: los parámetros de una so-
licitud de conexión podrían contener la identidad de quien llama, el tipo de servicio
deseado y el tamaño del mensaje máximo propuesto.
Ejemplo de primitivas de los servicios orientados a conexión:
Primitiva Significado
LISTEN Bloquea en espera de una conexión entrante
CONNECT Establece una conexión con el igual en espera
RECEIVE Bloquea en espera de un mensaje entrante
SEND Envía un mensaje al igual
DISCONNECT Da por terminada una conexión
12 1.7. MODELOS DE REFERENCIA
1.7. MODELOS DE REFERENCIA
1.7.1. MODELO DE REFERENCIA OSI
Figura 1.6: El modelo de referencia OSI.
El modelo OSI se basa en una propuesta que desarrolló la Organización Interna-

cional de Normas (ISO) como primer paso hacia la estandarización internacional de los
protocolos que se usan en las diversas capas. El modelo de referencia OSI (Open Sys-
tems Interconnection, interconexión de sistemas abiertos) se ocupa de la conexión
de sistemas abierto, es decir, sistemas que están abiertos a la comunicación con otros
sistemas.
El modelo OSI tiene siete capas:
1. La capa física: Se encarga de la interfaz física entre los dispositivos definiendo:
Características mecánicas: Especificación de conectores.

Características eléctricas: Niveles de tensión.
REDES
Características funcionales: Funciones de los circuitos de la interfaz con el

medio.
Cómo transmitir bits puros a través de un canal de comunicación.
2. La capa de enlace de datos: Se encarga de:
Asegurar que el enlace físico sea fiable.
Detección y corrección de errores es su principal servicio, dividiendo el flujo
de datos en tramas.
El control del flujo.
Ofrece una comunicación punto a punto con cualquier equipo dentro de la misma
subred física
3. La capa de red: Se encarga de:
Realizar la transferencia de información entre sistemas finales, conectados o
no a la misma red, salvando las diferencias entre ellos.
Establecer la dirección del destino y cómo se enrutan los paquetes desde su
origen a su destino.
Control de la congestión.
Ofrece comunicación entre equipos finales.
4. La capa de transporte: Se encarga de aceptar los datos provenientes de las
capas superiores, dividirlos en unidades más pequeñas y pasarlos a la capa de
red, asegurándose que lleguen bien al destino.
Ofrece una comunicación entre aplicaciones finales.

5. La capa de sesión: Se encarga de:
Permite que los usuarios de máquinas diferentes establezcan sesiones entre
ellos.
El control de diálogo: Administración de tokens (operaciones críticas comu-
nicación) y sincronización (recuperación ante caídas).
6. La capa de presentación: Se encarga de:
La sintaxis y semántica de la información transmitida, a diferencia de las
capas inferiores a las que les corresponde ppte mover bits.
Compresión y cifrado.
Se definen estructuras de datos abstractas para comunicación entre distintos.
7. La capa de aplicación: Se encarga de:
Definir protocolos que los usuarios requieren con frecuencia.
En esta capa residen las aplicaciones de uso general como la transferencia
de archivos, el correo electrónico y noticias.
1.7.2. EL MODELO TCP/IP

TCP/IP surge como resultado de la investigación y desarrollo llevados a cabo por
la red experimental de conmutación de paquetes ARPANET, financiada por la Agencia
de Proyectos de Investigación Avanzada para la Defensa (DARPA) y es una familia de
protocolos.
Figura 1.7: El modelo de referencia TCP/IP.
Descripción de las capas del modelo TCP/IP:
1. Capa de acceso a la red: Responsable del intercambio de datos entre equipos

de la misma subred, el software que se use dependerá del tipo de red: conmutación
de circuitos o paquetes, Ej. LAN Ethernet. Con esta capa el software de las capas
superiores debería funcionar con independencia de la red a la que está conectado
el computador.
2. Capa Internet: Responsable del intercambio de datos entre equipos conectados

a redes diferentes, en distinta subred. El protocolo que se utiliza es el protocolo
IP (protocolo de Internet) que se utiliza para ofrecer el servicio de enrutamiento
a través de varias redes. Se implementa en los sistemas finales y además en los
enrutadores. IP es no orientado a la conexión.
3. Capa Transporte: Diseñada para permitir que entidades finales (Aplicaciones)

puedan llevar a cabo una comunicación de extremo a extremo. Están implemen-
tados dos protocolos TCP (orientado a la conexión y confiable) y UDP (no orien-
tado a la conexión y no confiable) para aplicaciones que no deseen secuenciacióny
control de flujo, Ej. transmisión de video.
4. Capa Aplicación: Contiene los protocolos de nivel más alto. Ejemplos: FTP,
HTTP, SMTP, TELNET. . .
REDES
Figura 1.8: Protocolos y redes en el modelo TCP/IP inicial.
1.7.3. COMPARACIÓN ENTRE TCP/IP VS OSI
Los modelos de referencia OSI y TCP/IP tienen mucho en común. Ambos se

basan en el concepto de un gran número de protocolos independientes. También la
funcionalidad de las capas es muy similar. Por ejemplo, en ambos modelos las capas
por encima de la de transporte, incluida ésta, esta´n ahí para prestar un servicio
de transporte extremo a extremo, independientemente de la red, a los procesos que
deseen comunicarse. Estas capas forman el proveedor de transporte. También en ambos
modelos las capas encima de la de transporte son usuarios de servicio de transporte
orientados a aplicaciones.
A pesar de estas similitudes fundamentales entre los dos modelos, existen también
muchas diferencias.
En el modelo OSI se hace una clara distinción entre servicio, interfaz y protocolo.
En el modelo TCP/IP esta distinción no es tan clara, aunque se ha tratado de reajus-
tarlo después para hacerlo más parecido a OSI. Como consecuencia de esto en el modelo
OSI se ocultan mejor los protocolos que en el modelo TCP/IP y pueden reemplazarse
con relativa facilidad al cambiar la tecnología.
El modelo OSI se desarrolló antes de que se inventaran los protocolos. Esto significa
que el modelo no se orientó hacia un conjunto específico de protocolos, lo cual se
convirtió en algo muy general. El lado malo de este orden es que los diseñadores no
tenían mucha experiencia con el asunto y no supieron bien cuál funcionalidad poner en
cuál capa.
Lo contrario sucedió en TCP/IP: primero llegaron los protocolos, y el modelo
fue en realidad sólo una descripción de los protocolos existentes, por lo que no hubo
problema de ajustar los protocolos al modelo. El único problema fue que el modelo
no es ajustaba a ninguna otra pila de protocolos; en consecuencia no fue de mucha
utilidad para describir otras redes que no fueran del tipo TCP/IP.
Una diferencia obvia entre ambos modelos es el número de capas. En el modelo

OSI hay siete capas y en el modelo TCP/IP cuatro. Ambos tienen capas de (inter)red,
de transporte y de aplicación, pero las otras capas son diferentes.
Otro diferencia se tiene en el área de la comunicación sin conexión frente a la
orientada a conexión. El modelo OSI apoya la comunicación tanto sin conexión como
la orientada a conexión en la capa de red, pero en la capa de transporte, donde es
más importante, lo hace únicamente con la comunicación orientada a la conexión. El
modelo TCP/IP sólo tiene un modo en la capa de red (sin conexión) pero apoya ambos
modos en la capa de transporte, con lo que ofrece una alternativa a los usuarios. Esta
elección sobre todo para los protocolos simples de petición y respuesta.
CRÍTICA AL MODELO OSI
¿Porqué no se implantó OSI en todo el mundo?
Aparición inoportuna: apocalipsis de los dos elefantes.
Mala tecnología: tanto el modelo como los protocolos son complejos y abstractos,
hay dos capas casi vacías.
Malas implementaciones: grandes, pesadas y lentas.
Malas políticas: TCP/IP era parte de UNIX de Berkeley.
CRÍTICA AL MODELO TCP/IP
No se distingue entre servicio, interfaz y protocolo.
No es un modelo general.
La “capa" de Host a Red no es realmente una capa.
No se mencionan la capa física y la de enlace.
Excepto TCP, IP los demás protocolos fueron hechos con fines específicos y por
tanto difíciles de reemplazar.
REDES
LA CAPA FÍSICA
Es la capa más baja en el modelo OSI y se encarga de la interfaz física de los

dispositivos definiendo:
1. Características mecánicas (especificación de los conectores).
2. Características eléctricas (niveles de tensión).
3. Características funcionales (funciones de los circuitos de la interfaz con el medio).
4. Cómo transmitir el flujo de bits puros a través del canal de comunicación.
2.1. BASE TEÓRICA DE LA COMUNICACIÓN DE

DATOS
La señal utilizada para la comunicación de datos suele ser una señal electromag-
nética por lo que haremos un análisis teórico de la transmisión de datos en base a:
El dominio del tiempo.
El dominio de la frecuencia.
Capacidad de un canal.
17
18 2.1. BASE TEÓRICA DE LA COMUNICACIÓN DE DATOS
2.1.1. CONCEPTOS BÁSICOS

Mediante la variación de algunas propiedades físicas, como el voltaje o la corriente,
es posible transmitir información a través de cables.
Representando el voltaje como una función del tiempo f (t), podemos modelar el
comportamiento de la señal.
DOMINIO TEMPORAL:
Una señal analógica es aquella en la que la intensidad de la señal varía suave-

mente en el tiempo, no presenta saltos o discontinuidades.
Una señal digital es aquella en la que la intensidad se mantiene constante durante
un intervalo de tiempo, tras el cual la señal cambia a otro valor constante, creando una
discontinuidad.
Estas señales son periódicas si contienen un patrón que se repite a lo largo del
tiempo, definiéndose el período (T ) como el tiempo transcurrido entre repeticiones
consecutivas de la señal. La frecuencia de repetición se define como F = 1/T y se
expresa Hz.
DOMINIO DE LA FRECUENCIA:
La representación temporal de una señal es la que percibimos de manera más

natural, no obstante muchos de los fenómenos que ocurren a la señal de comunicación
en su propagación por el medio, se estudian mejor en el dominio de las frecuencias.
Un herramienta matemática que nos permite estudiar el comportamiento de una
señal en el dominio de la frecuencia es el Análisis de Fourier.
2.1.2. ANÁLISIS DE FOURIER

A principios de siglo XIX el matemático francés Jean-Baptiste Fourier demostró
que sumando una cantidad (posiblemente infinita) de senos y cosenos se puede construir
cualquier función periódica de comportamiento razonable, g(t), con periodo T :
X n=1 X n=1
1
g(t) = c + an sen(2πnf t) + bn cos(2πnf t)
2 ∞ ∞
Donde f = T1 es la frecuencia fundamental y an y bn son las amplitudes de seno y

coseno del n-ésimo armónico.
A partir de del período y las amplitudes se puede encontrar la función original del
tiempo efectuando las sumas de la ecuación anterior.
Las amplitudes se pueden calcular para cualquier g(t) multiplicando ambos lados
de la ecuación por sen(2πnf t)dt e integrando de cero a T . El resultado es:
REDES
Z T Z T Z T
2 2 2
an = g(t)sen(2πnf t)dt bn = g(t)cos(2πnf t)dt c= g(t)dt
T 0 T 0 T 0
Veamos un ejemplo específico de transmisión del carácter b cuyo ASCII es 01100010:
Figura 2.1: Aproximaciones sucesivas por Fourier.

CONCEPTOS BÁSICOS EN EL DOMINIO DE LA FRECUENCIA
Debido a la naturaleza de los materiales existen limitaciones en cuanto a lo que se

puede transmitir a través de un canal.
Ninguna instalación transmisora puede transmitir señales sin perder cierta poten-
cia en el proceso, disminuyendo las distintas componentes de Fourier en distinto grado
y provocando distorsión.
Espectro de una Señal:

Rango de frecuencias que forman una señal en el espacio de las frecuencias, es
decir, el rango de frecuencias en las que está presente una señal. Existen señales
con un espectro finito (generalmente señales continuas) y otras con un espectro
infinito (generalmente discretas).
Ancho de Banda de una Señal:

Es el ancho del espectro de una señal. En el caso de señales de tipo discreto el
ancho de banda efectivo está constituido por el rango de frecuencias que acumulan
la mayor parte de la energía de una señal.
Ancho de Banda Digital:

Es el número máximo de bits que teóricamente pueden pasar a través de un
espacio concreto, un medio de transmisión, en una cantidad de tiempo específica
(bajo ciertas condiciones).
2.1.3. PERTURBACIONES DE LA SEÑAL

En cualquier sistema de comunicaciones la señal que se recibe diferirá de la señal
original enviada debido a las perturbaciones que pueda sufrir la señal durante la trans-
misión.
Las perturbaciones más significativas son:
Limitación del ancho de banda.
Atenuación y retardo.
Ruido.
1. LIMITACIÓN DEL ANCHO DE BANDA
Todo medio físico de transmisión tiene asociado un ancho de banda definido, que
especifica el rango de frecuencias que se transmitirán sin atenuación (un porcentaje).
El ancho de banda es por tanto una propiedad física del medio de transmisión y
de su geometría.
REDES
Ejemplo:
Dada una tasa de bits Rb = Xbps, el tiempo para enviar 8 bits (1 byte) es (perío-
do):
8 8
T = ⇒f = → F recuencia
X X
Para línea telefónica con calidad de voz y con frecuencia de corte en 3100 Hz y
con una tasa de bits de x Bps, podemos calcular el número de armónicos que pasan:
3000 3000 24000

Na = = x =
f 8
x
Capacidad Máxima de un Canal Ideal (sin ruido):
La capacidad de un canal es la velocidad a la que se pueden transmitir los datos

en un canal o ruta de comunicación de datos.
Henry Nyquist en 1924, formuló su teorema que establece la tasa de datos máxima
(C) de un canal sin ruidos en función del ancho de banda (B) del canal:
C = 2Blog2 M → Teorema de Nyquist
Donde M es el número de niveles de la señal, para una señal binaria M = 2 y

C = 2B.
2. ATENUACIÓN Y RETARDO
Una señal se atenuará más conforme mayor sea su frecuencia, teniendo como límite
la frecuencia de corte (aquella a partir de la cual no se transmite). Se considera una
aproximación de ésta relacionada con un umbral de atenuación en tanto por ciento.
La energía de la señal decae con la distancia en cualquier medio de transmisión.
En medios guiados, esta reducción es, generalmente, logarítmica y se puede expresar
como un número constante en decibelios:
Ps
A = −10log (dB)
Pe
En medios no guiados la atenuación es una función más compleja de la distancia

y depende, a su vez, de las condiciones atmosféricas.
Hay que tener en cuenta dos aspectos al estudiar la atenuación:
1. La señal recibida debe tener suficiente energía para que el receptor pueda detectar
e interpretar la señal adecuadamente.
Se resuelve controlando la energía de la señal usando amplificadores o repetidores
que realcen la señal.
2. La atenuación es una función creciente de la frecuencia.

Para evitar este efecto se utilizan técnicas para ecualizar la señal en una banda
de frecuencias o sea amplificar más las frecuencias altas que las bajas.
La distorsión de retardo es un fenómeno peculiar de los medios guiados causado

por el hecho de que la velocidad de propagación del medio varía con la frecuencia. Para
una señal de banda limitada, la velocidad tiende a ser mayor cerca de la frecuencia
central y disminuye al acercarse a los extremos de la banda. Por tanto, las distintas
componentes en frecuencia de de la señal llegarán al receptor en instantes diferentes
de tiempo. Este problema se puede resolver también usando técnicas de ecualización,
retrasando las señales de baja frecuencia a lo largo del tiempo.
3. RUIDO
En un proceso de transmisión, la señal recibida consistirá en la señal transmitida

modificada por atenuación y distorsión en el sistema de transmisión, además de señales
no deseadas que se insertan entre el emisor y el receptor. A estas últimas se les denomina
Ruido y es un factor de gran importancia a la hora de limitar las prestaciones de un
sistema de comunicación.
Las principales fuentes de ruido son las siguientes:
1. Ruido Térmico:
Se debe a la agitación térmica aleatoria de los electrones dentro del conductor y
afecta a todas las componentes de frecuencia por igual.
El ruido térmico no se puede eliminar pero por suerte es relativamente insigni-
ficante en relación a la amplitud de las señales. La potencia de ruido térmico se
puede expresar:
R = kT B,
donde k = 1, 39 ∗ 10−23 J/K, T es la temperatura ambiente y B es el ancho de
banda.
R = 10logk + 10logT + 10logB en dbW
2. Toma de Tierra:
En todo circuito electrónico, la toma de tierra es la referencia de nivel 0 voltios.
Si por construcción o mala instalación este nivel fluctúa se introducen ruidos.
3. Reflexión:
Si existen discontinuidades en el medio se produce en la señal una reflexión o
vuelta atrás de parte de la energía contenida por ésta. Provocado por malos
empalmes, golpes,etc.
4. Diafonía:
Es un acoplamiento no deseado entre las líneas de transmisión que transportan
señales. Esto puede ocurrir por acoplamiento eléctrico entre cables de pares cer-
canos, dos hilos cercanos no trenzados, la energía se transmite, provocando ruido
(ej, conversación telefónica). Se puede controlar utilizando pares trenzados de
buena calidad o el uso de circuitos integrados llamados canceladores.
REDES
5. Ruido Impulsivo:
está constituido por pulsos o picos irregulares de corta duración y de amplitud
relativamente grande, se generan por perturbaciones electromagnéticas exteriores
producidas por tormentas atmosféricas o fallos y defectos en los sistemas de co-
municación. Son continuos e impredecibles y se pueden controlar haciendo uso de
técnicas como el blindaje y la cancelación
Capacidad de un Canal con Ruido
Shannon continuó el trabajo de Nyquist y lo extendió al caso de un canal sujeto a

ruido aleatorio (térmico) que siempre está presente.
La cantidad de ruido térmico presente se mide por la relación entre la potencia de
la señal y la potencia del ruido llamada relación señal-ruido y expresada en Db sería:
S/Rdb = 10log(S/R)
La tasa de datos máxima para un canal con ruido según Shannon es:
C = Blog2 (1 + S/R) → Fórmula de Shannon
Relación entre velocidad de transmisión V y la potencia de ruido:
Sean: S: Potencia de la señal, V: Velocidad de transmisión,
R = kT (W/Hz) → Potencia ruido por Hz.

E = S/V (W/bits) → Energía por bit.
Tenemos que:
E S
=
R kT V
Si aumenta la velocidad de transmisión V sin aumentar la potencia de la señal la
influencia del ruido aumenta.
2.2. MEDIOS DE TRANSMISIÓN

El propósito de la capa física es transportar el flujo de datos de una máquina a
otra. Para ello es necesario el uso de un medio físico. Existen distintos tipos de medios
físicos y cada uno de ellos se caracterizan, a grandes rasgos, por su ancho de banda,
costo,l facilidad de instalación y mantenimiento. . .
Se puede realizar una clasificación de los medios en:
Medios guiados:
Las ondas se confinan en un medio sólido. Ejemplos: cables de cobre y fibra óptica.
24 2.2. MEDIOS DE TRANSMISIÓN
Medios no guiados:
Las ondas se transmiten sin confinarlas a un medio sólido. Ejemplos: radio y láser
2.2.1. MEDIOS DE TRANSMISIÓN GUIADOS

1. Medios magnéticos o DVDs:
Medios magnéticos o DVDs: Una de las formas más comunes de transportar

datos de una computadora a otra son los disquetes o DVDs regrabables.
Cinta Ultrium: Almacena 200 Gbits y cajas de hasta 1000 cintas ⇒ 1600 ter-
abits y pueden enviarse en 24 horas (86400 seg) ⇒ B = 1600 terabits/86400
= 19 Gbps y si está a una hora de carretera = 400 Gbps.
2. Cables de par trenzado:

Dos alambres de cobre aislados con grosor de 1 mm. Los alambres se trenzan en
forma helicoidal como una molécula de AND: dos alambres paralelos constituyen
una antena, cuando se trenzan las ondas de diferentes vueltas se cancelan y la
radiación del cable es menos efectiva. Pueden estar blindados o no.
Tipos de cables par trenzados:
No apantallado (UTP: Unshield Twiested Pair): Características:

• Bajo coste y facilidad de manejo.
• Mayores tasa de error respecto a otros cables Limitaciones para trabajar
en largas distancias sin regeneración.
• Poco peso: facilita el tendido.
• Flexible: facilidad para doblar y curvar.
• Muchos fabricantes: abarata instalación.
Figura 2.2: Par trenzado no apantallado.
(a) Category 3 UTP: Anchos de banda hasta 16 MHz. (b) Category 5 UTP:
Tienen más vueltas por cms ⇒ menor diafonía y mejor calidad señal a
mayores dist. Capacidad manejar señales de hasta 100 MHz. Aplicaciones:
• Tanto en transmisión analógica como digital.
REDES
• Sistema telefónico: Los teléfonos están conectados a la compañía de

teléfonos a través de un UTP. Dentro de un edificio de oficinas cada
teléfono se conecta a la central con UTP.
• LAN Ethernet 10 Mbps (UTP3).
• LAN Ethernet 100 Mbps (UTP5).
Par trenzado blindado: Características:
• Combina las técnicas de blindaje, cancelación y trenzado de cables.
• Reduce el ruido eléctrico
• Más caro que UTP y voluminoso, IBM lo introdujo en los 80’s y casi
nadie los usa.
Figura 2.3: Par trenzado blindado.
3. Cable Coaxial:
Está compuesto por:
Núcleo conductor de cobre.

Material aislante que recubre el núcleo.
Conductor exterior entrelazado, malla de cobre que actúa además como
blindaje conductor interno que ayuda a reducir la cantidad de interferencia
externa.
Cubierta de plástico para proteger el interior de las condiciones adversas.
Figura 2.4: Cable coaxial.
Tipos de cable coaxial:
Fino ó thinnet ó 10Base2: Se usa para transmisiones digitales y tiene una

impedancia de 50 ohms.
Grueso ó thicknet ó 10Base5: Se usa para transmisiones analógicas y la
comunicación por cable. Tiene una impedancia de 75 ohms.
4. Fibra Óptica:
Un cable de fibra óbica está compuesto por:
Un filamento de vidrio del espesor de un cabello, a través del cual se lleva a

cabo la propagación de la luz y que se llama núcleo.
Un revestimiento de vidrio con un índice de refracción menor que el del
núcleo con el fin de mantener la luz confinada.
Cubierta de plástico para proteger el revestimiento.
Figura 2.5: Estructura de un cable de fibra ótica.
Transmisión de luz a través de fibra ótica:
a) Fuente de Luz: Produce las señales de luz a partir de impulsos eléctricos

bien mediante diodos emisores de luz (LED) o diodos láseres (LD).
b) Fibra de vidrio: transmite la luz.
c) Receptor de luz: que emite un pulso eléctrico cuando lo golpea la luz. Son
los foto-diodos.
REDES
Tipos de fibra ótica:
Multimodo: Cualquier rayo de luz que incida con un ángulo mayor que el
crítico se reflejará internamente. Habrán muchos rayos rebotando con ángu-
los diferentes
Monomodo: Cuando el radio del núcleo se reduce la reflexión se dará en mu-
chos menos ángulos, hasta reducirlo a dimensiones del orden de la longitud
de onda. Sólo puede pasar un rayo. Son más caras.
Redes de fibra óptica:
Figura 2.6: Anillo de fibra óptica.
Las fibras ópticas se pueden utilizar tanto para LAN como para transmisión a
largo alcance. En la figura se muestra un ejemplo de una RED LAN con fibra
ótica, compuesta por una serie de repetidores activos donde la luz entrante se
convierte en una señal eléctrica que se regenera a su intensidad completa si se
debilitó y se como luz.
Ventajas de la fibra óptica:
Anchos de banda grande: muchos mayores que el cobre, hasta 50 Gbps a

una distancia de 100 km.
Baja atenuación: sólo se necesitan repetidores cada 50 km, mientras en el
cobre cada 5 km.
No le afectan: las sobrecargas de energía, mi la interferencia electromagnéti-
ca.
Es delgada y ligera.
Desventajas de la fibra óptica:
Uso limitado a empresas: o usuarios que la tengan instalada en su zona.

Coste de instalación: elevado.
Son frágiles: pueden dañarse si se doblan demasiado.
Dificultad de reparación.
2.2.2. MEDIOS DE TRANSMISIÓN NO GUIADOS. TRANS-

MISIÓN INALÁMBRICA
FUNDAMENTOS DE LA TRANSMISIÓN INALÁMBRICA:
Cuando los electrones se mueven crean ondas electromagnéticas que pueden propa-
garse incluso en el vacío. Maxwell las predijo 1865 (ecuaciones) y Hertz las observó en
1887 (Hz). En el vacío todas las ondas e.m. viajan a la misma velocidad C (300.000
Km/seg). En el cobre o la fibra viajan a 2/3 C.
Al conectar una antena a un circuito eléctrico (emisor), las ondas pueden trans-
mitirse eficientemente y ser captadas por resonancia en un receptor a cierta distancia.
Esta es la base comunicación inalámbrica.
El Espectro Electromagnético
Figura 2.7: El espectro electromagnético.
Las porciones de radio, microondas, infrarrojo y luz visible sirven para transmitir in-
formación modulando la amplitud, frecuencia o fase de las ondas.
Con la tecnología actual es posible codificar hasta 8 bits x Hz para altas frecuencias,
por lo que un cable coaxial de B=750 MHz podrá transportar varios Gbps.
Para evitar el caos total hay acuerdos nacionales e internacionales acerca de quién
utiliza cuáles frecuencias Han existido tres medios de asignación
1. Concurso de méritos.
2. Sorteo.
3. Subasta pública (licencia UMTS).
Por otro lado hay algunas bandas de frecuencia que se reservan para casos es-
pecíficos como por ejemplo para uso Industrial, Médico y Científico, llamadas bandas
REDES
ISM. También existen otras frecuencias reservadas a usos personales y a baja potencia
como para los mandos garaje, teléfonos inalámbricos, juguetes de radiocontrol, LANs
inalámbricas, etc.
TIPOS DE TRANSMISIÓN
1. Radiotransmisión:
Las ondas de radio tienen las siguientes características:
Son fáciles de generar (104 a 108 Hz).

Pueden viajar largas distancias
Pueden penetrar edificios sin problemas.
Son omnidireccionales: viajan en todas direcciones, con lo cual el emisor y
receptor no tienen que estar alineados.
La interferencia entre usuarios es un problema, aquí entran los gobiernos.
Dependiendo de su frecuencia, y como se puede ver en la figura, la onda puede

viajar bien siguiendo la curvatura de la tierra (a) para bajas frecuencias (VLF,
LF y MF) o bien en línea recta (b) para altas frecuencias (HF y VHF).
Figura 2.8: Comportamiento de las ondas según su frecuencia.
2. Transmisión por microondas: A partir de 100 MHz las ondas tienden a via-
jar en línea recta y por lo tanto se pueden enfocar en un haz estrecho, en este
caso las antenas de emisión y recepción deben estar alineadas. La antena más
común es la parabólica. A diferencia con las de radio a frecuencias más bajas, no
atraviesan bien los edificios. Algunas ondas pueden llegar directamente o después
de refractarse en la tierra o atmósfera, llegan fuera de fase y cancelan la señal.
Este efecto se conoce como desvanecimiento por múltiples trayectorias.
3. Transmisión por ondas infrarrojas y milimétricas:

Las ondas infrarrojas y milimétricas se usan mucho para la comunicación de corto
alcance.
Todos los controles remotos de televisores, videos, minicadena entre otros utilizan
comunicación infrarroja. La desventaja es que no atraviesan los objetos sólidos.
4. Transmisión por ondas de luz láser:

Es inherentemente unidireccional. Tiene con un ancho de banda alto a un coste
muy bajo. No requiere licencia. Permite conectar LANs de dos edificios. Su es-
trechez es una desventaja a la hora de apuntar el láser. No pueden penetrar la
lluvia, ni la niebla densa y se ven afectadas por las corrientes de convección calor.
Figura 2.9: Ejemplo de comunicación bidireccional por láser.
2.2.3. SATÉLITES DE COMUNICACIONES

El primer satélite que se utilizó fue la Luna donde se reflejaban las ondas. Actual-
mente se utilizan satélites artificiales que no sólo envían la señal de regreso sino que
también la amplifican y tratan.
Un satélite de comunicación es una estación que retransmite microondas. Un haz
de microondas colimado sobre el cual modulan los datos se transmite al satélite desde la
superficie terrestre. Este haz se recibe y retransmite a un destino o destinos a través de
un circuito llamado transpondedor. Cada satélite puede tener muchos transpondedores
que cubren una banda de frecuencia determinada.
CLASIFICACIÓN DE LOS SATÉLITES:
Según la altura de La Tierra a la que estén los satélites, estos se pueden clasificar
en:
Satélites Geoestacionarios (GEO).
REDES
Satélites de Órbita Terrestre Media (MEO).
Satélites de Órbita Terrestre Baja (LEO).
Figura 2.10: Clasificación y algunas propiedades de los satélites.
1. Satélites de GEO (Órbita terrestre geoestacionaria):

Son satélites que vuelan a gran altura (35.000 km) y debido a su período aparentan
que permanecen inmóviles en el cielo.
Los primeros GEOs tenían un solo haz espacial que iluminaban cerca de un ter-
cio de la tierra llamado huella. Actualmente estos haces se pueden concentrar en
áreas geográficas pequeñas (haces reducidos).
: VSAT
Un avance reciente en el mundo de los satélites es el desarrollo de microestaciones
de bajo costo llamadas VSATs (Terminales de apertura muy pequeña). Estas ter-
minales tienen antenas de 1 metro funcionando su enlace descendente a 19.2 kbps
y el descendente a 512 kbps. La televisión de difusión directa por satélite utiliza
esta tecnología.
Figura 2.11: Satélites VSAT.
Las microestaciones no tienen suficiente energía para comunicarse entre sí (a

través del satélite) se requiere de VSATs con una estación central con una antena
grande y un amplificador potente para retransmitir el tráfico entre VSAT.
2. Satélites MEO:
Son satélites de orbita terrestre media (entre 5000 y 15000 Km.) entre los dos
cinturones de Allen. Tardan 6 horas en dar la vuelta a la Tierra, son más pequeños
que los GEOs y tienen menor huella. Ejemplos: Los 24 satélites GPS (Sistema de
Posicionamiento Global)
3. Satélites LEO:
Satélites de orbita terrestre baja (por debajo de los dos cinturones de Allen) con
una altura de 750 km. Debido a su rapidez de movimiento se requieren grandes
cantidades de ellos para cubrir La Tierra. Tienen menor retardo de ida y vuelta
(mseg) y ofrecen servicios de telecomunicaciones en todo el mundo a través de
dispositivos de bolsillo que se comunican con el satélite.
Iridium: Los satélites Iridium forman seis collares alrededor de la Tierra con
un satélite cada 32 grados latitud habiendo, por tanto 66 satélites.
Figura 2.12: Esquema de cobertura de satélites Iridium.
REDES
Globalstar: Es un diseño alternativo para Iridium. Se basa en 48 satélites

LEO que utilizan un esquema de conmutación diferente. Iridium retransmite
las llamadas de satélite en satélite, mientras que Globalstar lo hace a través
de una red terrestre. El uso de antenas grandes en las estaciones terrestres
pueden producir una señal potente y recibir una débil. Se usan, por ejemplo,
para teléfonos de baja potencia.
Teledesic:
Iridium está destinada a usuarios de teléfonos que se encuentran en lugares
con condiciones extremas.
Teledesic está destinado a usuarios de Internet del mundo deseosos de ancho
de banda Fue concebida 1990 por Craig MacCaw y Bill Gates.
Su objetivo es ofrecer un enlace ascendente de 100 Mbps y descendente de
720 Mbps mediante antenas VSAT pequeñas y fijas que ignoren el sistema
telefónico. Consta de 30 satélites en banda Ka, utilizando conmutación de
paquetes en el espacio. Tienen pensado comience a funcionar 2005.
Figura 2.13: Retransmisión por satélites Iridium y Globalstar.
2.2.4. LA RED TELEFÓNICA CONMUTADA (RTPC)

Cuando dos computadoras están localizadas cerca una de la otra, se pueden co-
municar a través de un cable (LAN).
Cuando las distancias son considerables o los cables tienen que pasar por una vía
pública o privada los costes son prohibitivos por lo que es necesario utilizar RTPC.
RTPC son instalaciones hechas hace muchos años, con un propósito completamente
distinto, transmitir voz humana en un formato comprensible.
PRINCIPALES COMPONENTES DEL SISTEMA TELEFÓNICO
Circuitos locales: Cables de par trenzado que van hacia las casas y las empresas
Troncales Fibra óptica digital: Conecta a las oficinas de conmutación.

Oficinas de conmutación: Las llamadas pasan de una troncal a otra.
Figura 2.14: Estructura del sistema telefónico.
En la figura se muestra la ruta típica de un circuito para una llamada de media

distancia. Los circuitos locales son la parte más débil del sistema y se le conoce como
la “última milla" y utiliza señalización analógica por lo que si enviamos datos digitales
debemos convertirlos primero.
EL CIRCUITO O BUCLE LOCAL: MODEMS, ADSL
Hacen uso de transmisión analógica y digital para una llamada de computadora a

computadora. Los módems y los codecs realizan la conversión.
Figura 2.15: El Circuito o bucle Local.
Tipos de señalización:
Señalización en banda base: La señal digital se transmite a través de una

onda cuadrada con diferentes niveles de voltaje para representar cada bit, también
llamada señalización de corriente continua (CC). Debido a los problemas ya vistos
de distorsión o perturbación de la señal en realidad se utiliza.
REDES
Señalización de corriente alterna (CA): Se introduce un tono continuo en

el rango de 1000 a 2000 Hz llamada portadora de onda senoidal, cuya amplitud,
frecuencia o fase se pueden modular para transmitir la información, lo cual hacen
los módems.
2.3. TRANSMISIÓN ANALÓGICA Y DIGITAL. MO-

DULACIÓN.
2.3.1. COMUNICACIÓN ANALÓGICA
Consisten en la transmisión de datos digitales usando señales analógicas. La situación

más conocida para este tipo de situaciones es la transmisión de datos digitales a
través de la red telefónica. Esta red se diseñó para recibir, conmutar y transmitir
señales analógicas en el rango de frecuencias de voz entre 300 y 3400 Hz. No es, por
tanto, adecuada para la transmisión de señales digitales desde el terminal abonado
(aunque esto está progresivamente cambiando). No obstante, se pueden conectar dis-
positivos digitales a través de la red mediante el uso de dispositivos modem (modulador-
demodulador), que convierta los datos digitales en señales analógicas y viceversa.
En la red telefónica se usan los modems para producir señales en el rango de
frecuencias de la voz, si bien, las mismas técnicas se pueden usar para modems a
frecuencias más altas (cable-modem, microondas, etc.).
La modulación afecta a uno o más de los parámetros característicos de la señal
portadora: la amplitud, la frecuencia y la fase.
Existen tres técnicas básicas de codificación o de modulación para realizar la con-
versión de datos digitales en señales analógicas:
1. Modulación en amplitud (ASK, Amplitude Shift Keying):

Se usan dos niveles diferentes de amplitud para representar los bits 0 y 1 respec-
tivamente.
2. Modulación de frecuencia (FSK, Frequency Shift Keying):

Se utilizan dos frecuencias distintas para representar 0 y 1.
3. Modulación de fase (PSK, Phase Shift Keying):

La onda portadora se desplaza de modo sistemático de 0 a 180 grados ó un mejor
esquema es utilizar desplazamientos de 45, 135, 225, 315 grados para transmitir
dos bits de información (técnica conocida como QPSk).
36 2.3. TRANSMISIÓN ANALÓGICA Y DIGITAL. MODULACIÓN.
Figura 2.16: Tipos de modulación.
En la figura podemos ver una señal binaria (a) y las equivalentes analógicas digi-
tales: Modulación de amplitud (b), modulación de frecuencia (c) y modulación de fase
(d).
MODEMS
Modem (modulador-demodulador): es un dispositivo que acepta un flujo de bits

en serie como entrada y produce una portadora modulada mediante uno (o más) de
los métodos anteriores (o viceversa) Para la conversión digital-analógica la mayoría de
los modems muestrean a 2400 veces por segundo.
El número de muestras por segundo se mide en baudios. Un símbolo se envía
durante cada baudio. Según Nyquist si el símbolo consta de 0 Volts para el 0 lógico y
1 Volt para el 1 lógico entonces para una línea de 2400 baudios tiene una C=2400 bps,
si el símbolo consta de 4 niveles (2 bits) entonces C=4800 bps, por tanto:
C = Baudios ∗ BitsxSmbolo
Actualmente los módems utilizan una combinación de técnicas de modulación

para transmitir más bits por baudio, normalmente se combinan múltiples amplitudes
y múltiples fases. Para representar estas combinaciones se utilizan los diagramas de
constelación.
REDES
Figura 2.17: Diagramas de constelación.
En la figura se muestran tres esquemas de modulación:
1. QPSK: Se utilizan cuatro desplazamientos fase a 45, 135, 225, 315 (a).
2. QAM-16: Se utilizan 4 amplitudes y 4 fases, o sea 16 combinaciones (transmite
4 bits por símbolo) (b).
3. QAM-64: Se utilizan 8 amplitudes y 8 fases, o sea 64 combinaciones (transmite
6 bits por símbolo)(c).
Cuando hay muchos puntos en un diagrama de constelación, el ruido puede dar

como resultado un error en la amplitud o fase detectada, por lo que se incorporan bits
adicionales en cada muestra llamado bit de paridad. Veamos las características de los
distintos estándares a 2400 bps:
Nombre Estándar Ptos DC. Bits de paridad Bits de datos Capacidad

V.32 42 4 1 9.600 bps
V.32 bis 128 6 1 14.400 bps
V.34 8192 12 1 28.800 bps
V.34 bis 32768 14 1 33.600 bps
A continuación se muestra el histograma1 para el estándar V.32 y V.32 bis:
Figura 2.18: V.32 y V.32 bis.

1
La decisión de girar el diagrama 45 grados alrededor del eje se tomó por razones de ingeniería.
Tipos de Conexiones
Según las la forma de envío/recepción de datos, las conexiones se pueden clasificar

en:
1. Conexión dúplex total (full duplex): Permite el flujo de tráfico en ambas

direcciones de manera simultánea. Ej una carretera con dos carriles
2. Conexión semidúplex (half-duplex): permite el tráfico en ambas direcciones
pero en un sólo sentido a la vez.Ej. Una vía de ferrocarril. Conexión símplex:
permite el tráfico en una única dirección.
Todos los módems modernos transmiten tráfico en ambas direcciones al mismo

tiempo, utilizando frecuencias distintas para las dos direcciones.
Los módems estándares llegan hasta 33.600 bps debido a que el límite de Shannon
para el sistema telefónico es 35.000 bps, velocidades mayores violarían las leyes de la
física (termodinámica).
Una llamada que se origina en una computadora y que termina en ISP1 recorre
dos circuitos locales como señal analógica, cada uno de lo cuales agrega ruido a la señal.
Si pudiéramos prescindir de uno de ellos podría duplicarse la tasa máxima de bits. Es
lo que realiza ISP2, que cuenta con una alimentación digital pura proveniente de la
oficina central más cercana, con lo cual la tasa puede llegar a 70 kbps.
La razón por la cual, se utilizan los módems de 56 kbps tiene que ver con Nyquist:
(7 bits datos y 1 control):
Canaltelef nico : C = 8000baudios ∗ 7bitsxmuestra = 56Kbps
2.3.2. COMUNICACIÓN DIGITAL

Una señal digital es una secuencia de pulsos de tensión discretos y discontínuos,
donde cada pulso es un elemento de señal. Los datos binarios se transmiten codifi-
cando cada bit de datos en cada elemento de señal. En el caso más sencillo habrá una
correspondencia uno a uno entre los bits y dichos elementos. A la hora de diseñar un es-
quema de codificación digital hay que tener en cuenta numerosos factores como pueden
ser el ruido, la interpretación correcta de las señales, sincronización para determinar
duración de bits, detección de errores, coste, complejidad. . .
LÍNEA DIGITAL DE ABONADO
Cuando la industria telefónica alcanzó los 56 kbps se congratuló de hacerlo, sin

embargo la televisión por cable ofrecía velocidades de hasta 10 Mbps y los satélites 50
Mbps. Necesitaban un producto más competitivo.
Comenzaron entonces a ofrecer nuevos servicios digitales en el circuito local, con
mayor ancho de banda y llamados “banda ancha". Para esto se creó el estándar xDSL
(Línea digital de abonado).
REDES
El truco para que DSL funcione es quitar el filtro en el conmutador de la oficina

central, para contar con todo el ancho de banda del circuito local, en esta situación el
A.B. artificial (3100 Hz) creado por el filtro ya no es el factor limitante, sino el medio
físico del circuito local de par trenzado
DSL se diseñó para que cumpliera algunos objetivos:
1. Los circuitos locales deben funcionar sobre par trenzado UTP-3.
2. Deben superar los 56 kbps.
3. Funcionar con una tarifa mensual no por minutos.
AT&T hizo la oferta inicial de DSL, el cual funcionaba dividiendo el espectro

disponible en el circuito local de alrededor de 1,1 Mhz en tres bandas de frecuencia:
1. Servicio telefónico convencional.
2. Canal ascendente.
3. Canal descendente.
Esto se conoce como multiplexación en frecuencia. En la figura se muestra un

ejemplo de esto:
Figura 2.19: División del espectro en DSL.
Descripción:
1. 256 canales de 4 kHz cada uno.
2. El canal 0 se utiliza para voz.
3. Los canales 1-5 no se emplean para evitar interferencias entre voz y datos.
4. Los 250 canales restantes se reparten entre el canal ascendente y descendente

(50-50 %, 20-80 % o 10-90 % (Asimétrica, ADSL).
ESTÁNDAR ADSL
El estándar ADSL permite las siguientes velocidades:
CA = 1 Mbps.
CD = 8 Mbps.
Esto es debido a que un módem ADSL muestrea 4000 baudios y utiliza QAM-16
(15 bits por baudio y 1 para paridad). Por tanto la capacidad del canal es:
Ccanal = 15 ∗ 4000 = 60,000bps
Como CD son 244 canales, en ADSL queda:
CCD = 244 × 60,000 = 13, 44M bps ⇒ 8M bps(ruido)
Configuración ADSL
Componentes del sistema ADSL en el cliente:
NID (Dispositivo interfaz de red).
Divisor: Filtro analógico que separa la banda de 0-4000 Hz uitlizada para voz
de la de datos.
Módem ADSL: procesador de señales digitales configurado para funcionar como

250 módem QAM operando en paralelo a distintas frecuencias
Componentes de ADSL en oficina central:
Divisor: filtra la porción de voz de la señal y se la envía al conmutador.
DSLAM (Multiplexor de acceso a línea digital): hacia él se enrutan las

señales >26 KHz y se le envía al ISP que contiene el mismo tipo de procesador
digital que el módem ADSL.
REDES
Figura 2.20: Configuración ADSL.
2.4. MULTIPLEXACIÓN
Para hacer uso eficiente de las líneas de telecomunicaciones de alta velocidad se

emplean t
Normalmente, dos estaciones de comunicaciones no hacen uso de la capacidad total
del enlace de datos en todos los instantes de tiempo. Con objeto de mejorar la eficiencia
en el uso de estas líneas se hance uso de técnicas de multiplexación.
Las dos formas usuales de multiplexación son multiplexación por división de fre-
cuencia (FDM), usadas con señales analógicas, que permiten transmitir varias señales
de forma simultánea por el mismo medio y multiplexación por división en el tiempo
(TDM) que las que se reparte el tiempo de uso del canal en ranuras de tiempo y se
asignan a distintas fuentes emisoras de datos.
2.4.1. MULTIPLEXACIÓN POR DIVISIÓN DE FRECUEN-

CIA
El espectro se divide en bandas de frecuencia y cada usuario hace uso exclusivo

de una banda.
Ejemplos de esto son la radiodifusión AM, donde a los distintos canales lógicos se
les asigna una frecuencia distinta, o ADSL.
42 2.4. MULTIPLEXACIÓN
Figura 2.21: Esquema ejemplo FDM.
2.4.2. MULTIPLEXACIÓN POR DIVISIÓN DE ONDA

Igual que FDM pero para frecuencias altas. Se utiliza para los canales de fibra
óptica. Consiste en lo siguiente: cuatro fibras se juntan en un combinador óptico, ca-
da una con su energía presente a diferentes longitudes de onda. Los cuatro haces se
combinan en una sóla fibra compartida para su transmisión a distancia.
Fue inventada en 1990 y actualmente utilizan más de 96 canales a 10 Gbps = 960
Gbps. La limitación es la conversión óptico-eléctrico.
Figura 2.22: Esquema ejemplo WDM.
REDES
2.4.3. MULTIPLEXACIÓN POR DIVISIÓN DE TIEMPO

Consiste en la división del uso del medio en ranuras de tiempo y asignación de
estas ranuras a varios canales. El objetivo de esto es hacer que varias fuentes puedan
hacer uso de un mismo canal repartiendo el tiempo de uso entre todas estas fuentes.
Ejemplo de multiplexación por división de tiempo para uso del canal por
señales analógicas de voz y modem:
Se usa modulación por codificación de impulsos (PCM): en la que las señales

analógicas se digitalizan en la oficina central a través de un dispositivo llamado codec,
con lo que se producen una serie de números de 8 bits.
El codec toma 8000 muestras/seg (125 µseg/muestra) debido a Niquist, que dice
que esto es lo suficiente para capturar toda la información del ancho de banda de
4 kHz del canal telefónico (a una capacidad de muestreo menor habría pérdidas de
información y a una capacidad mayor, no se ganaría información extra).
Cuando la transmisión digital empezó a surgir como tecnología factible, el CCITT
incapaz de lograr un acuerdo respecto al estándar internacional para PCM. En conse-
cuencia, en la actualidad se usan varios esquemas incompatibles en todo el mundo (T1
para EEUU y Japón y E1 para los demás países).
LA PORTADORA T1
La portadora T1 tienen 24 canales de voz que se multiplexan juntos. Las señales

analógicas se muestrean por TDM, alimentando al codec en vez de tener 24 codecs y
después mezclar la salida digital. Cada uno de los canales de voz inserta a la vez 8 bits
conformando una trama de 24 × 8 = 192bits, más 1 bit extra para control de sincronía
C = 192/125 = 1,544M bps.
Figura 2.23: La portadora T1 (1.544 Mbps).

Se puede además hacer uso de multiplexación por tiempo para que varios canales
T1 se multiplenxen en uno de forma que se constituye un canal T2 a partir de cuatro
canales T1. De igual forma se crea una corriente T3 a partir de seis corrientes T2. El
siguiente paso es formar una corriente T4 a partir de una T3.
Figura 2.24: Multiplexación de corrientes T1 en portadoras más altas.
LA PORTADORA E1
Características:
32 canales de voz.
Trama = 32×8 = 256 bits cada 125 µseg
C = 256/125 = 2.040 Mbps
De acuerdo con estas características, el esquema de uso para el sistema telefónico

es el siguiente:
1. FDM: Cuando todos los circuitos eran analógicos para transmitir varias señales
de voz, multiplexores analógicos.
2. TDM: En el bucle local a través de los codecs de las oficinas centrales para
convertir la señal analógica a digital y en los troncales de alto ancho de banda
digitales puras para multiplexar portadoras.
2.4.4. TDM SONET/SDH

Actualmente se utiliza el estándar SONET/SDH como TDM avanzado en la ma-
yoría de los circuitos troncales en EE.UU y en buena parte de los otros países.
El diseño de SONET tuvo 4 objetivos:
1. SONET tenía que hacer posible la interconexión de redes de diferentes portadoras.

El logro de este objetivo requirió que se definiera un estándar de señalización de
común con respecto a la longitud de onda, la temporización, la estructura de
marcos y otras consideraciones.
REDES
2. Establecer una normativa para unificar los sistemas digitales de EE.UU y Japón
con el resto del mundo.
3. SONET tenía que proporcionar un mecanismo para multiplexar varios canales

digitales. En el momento que se creó SONET, la portadora de mayor velocidad
que se usaba ampliamente en EEUU era la T3, a 44.736 Mbps. La T4 se había
definido pero no se usaba mucho y nada se había definido todavía por encima de
la velocidad de T4. Parte de la misión de SONET era continuar la jerarquía a
gigabits/seg y más allá. También se necesitaba una forma estándar de multiplexar
canales más lentos en un solo canal SONET.
4. SONET tenía que proporcionar apoyo para las operaciones, la administración y

el mantenimiento (OAM). Los sitemas anteriores no hacían esto muy bien.
2.4.5. CONMUTACIÓN
Desde el punto de vista de un ingeniero el sistema telefónico se divide en dos
partes:
Planta externa: circuitos locales y troncales.
Planta interna: conmutación dentro de las oficinas de conmutación.
Existen tres tipos de conmutación:
Conmutación de circuitos.
Conmutación de mensajes.
Conmutación de paquetes.
Figura 2.25: Conmutación de circuitos y de paquetes.

CONMUTACIÓN DE CIRCUITOS
Técnica consistente en el establecimiento de una ruta física que vaya desde el

emisor hasta el receptor.
En sus inicios, la conmutación se realizaba de forma manual por un operador en
la oficina de conmutación. Actualmente se realiza de forma automática por circuitos
conmutadores.
Una vez que se haya establecido la llamada, se crea una conexión dedicada entre
ambos extremos que continuará hasta que termine la llamada o no haya datos para
enviar.
CONMUTACIÓN DE MENSAJES
No se establece por adelantado una trayectoria física entre el emisor y el receptor.

Cuando el emisor tiene un bloque de datos que enviar, este se almacena en la primera
oficina de conmutación (enrutador) y después se reenvía un salto a la vez. Cada bloque
se recibe en su totalidad, se inspecciona en busca de errores y después de retransmite.
Se utilizaba en sistemas electromecánicos para enviar telegramas(tarjetas perf)
pero ya no se utiliza.
Figura 2.26: Conmutación de circuitos (a), de mensajes (b) y de paquetes (c).
REDES
CONMUTACIÓN DE PAQUETES
En la conmutación de mensajes no hay un límite para el tamaño de los bloques, lo

que significa que los enrutadores deben tener discos duros para almacenar los bloques
grandes.
De este modo puede darse el caso de que un sólo bloque pueda acaparar la línea
del enrutador durante minutos (no intercativo). Debido a esto se inventó la red de
conmutación de paquetes que establece un límite superior al tamaño del bloque, lo que
permite almacenar los paquetes en la memoria principal del enrutador y no en disco
aportando intercatividad.
2.5. EL SISTEMA TELEFÓNICO MÓVIL
El sistema telefónico móvil, en sus inicios, consistía en radioteléfonos móviles que

se usaban exporádicamente para comunicación marítima y militar durante las primeras
décadas del siglo XX. En 1946, se instaló el primer sistema telefónico móvil en autos,
sistema que utilizaba un sólo transmisor grande situado en la parte superior de un
edificio alto y que tenía un solo canal, por lo que, para que un usuario pudiera hablar,
debía apretar un botón, dejando inhabilitado al receptor. Son los sistemas de oprimir
para hablar.
En la década de 1960 se instaló el IMTS (improved movile telephone system,
sistema de teléfonos móviles mejorado) que usaba un transmisor de alta frecuencia
(200 watts), en la parte superior de una colina y que tenía dos frecuencias, una para
enviar y otra para recibir.
IMTS usaba 23 canales dispersos, y debido a este número tan pequeño, los usuarios
a veces tenían que esperar largo tiempo antes de poder obtener el tono de marcar.
2.5.1. SISTEMA AVANZADO DE TELEFONÍA MÓVIL
Surge como motivo de mejora de IMTS. Se basa en la división de las regiones

geográficas en celdas (motivo por el que se conocen como teléfonos celulares). Cada
celda utiliza un conjunto de frecuencias que no es utilizada por ninguno de sus vecinos,
a no ser que haya más de dos celdas adyacentes, donde se podría reutilizar.
En el centro de cada celda, hay una estación base a la cual transmiten todos
los teléfonos de la celda. La estación base consiste en una computadora y un trans-
misor/receptor conectado a una antena.
48 2.5. EL SISTEMA TELEFÓNICO MÓVIL
Figura 2.27: (a) Ejemplo de división del espacio en celdas, (b) Ejemplo de subdivisión
de celdas en el caso de que sea necesario añadir más usuarios.
En un sistema pequeño todas las estaciones se podrán conectar a un mismo dis-

positivo llamado MTSO (movile telephone switching office, oficina de conmutación de
telefonía móvil).
Para sistemas más grandes se pueden crear jerarquías donde varios MTSO se
conectan a un MTSO de segundo nivel y así sucesivamente.
CONFIGURACIÓN DE AMTS
Los 832 canales dúplex compuesto por un par de canales simplex, en los siguientes
rangos de frecuencias:
824-849 Mhz canal ascendente.
869-894 Mhz canal descendente.
Longitud de onda es 40 cm, antenas grandes.
Ancho de banda del canal de 30 KHz (FDM)
Hay 21 canales para control y en celdas cercanas no se pueden utilizar las mismas
frecuencias por lo que los canales por célula son cerca de 45 canales por célula.
2.5.2. 2a GENERACIÓN. VOZ DIGITAL

Está compuesto por 124 pares canales simplex en los siguientes rangos de frecuen-
cias:
1850-1910 Mhz canal ascendente
1930-1990 Mhz canal descendente
REDES
Longitud de onda es 16 cm, antenas pequeñas
Cada uno de los canales está multiplexado en el tiempo con 8 ranuras temporales
(TDM), o sea 124 × 8 = 992 canales.
En realidad es una jerarquía compleja de entramado:
1. Ranura TDM → tramas de 148 bits en 547 µseg.
2. Trama TDM → tramas de 1250 bits en 4615 mseg.
3. Ranura TDM → tramas de 32500 bits en 120 mseg.
2.5.3. GSM, SISTEMA GLOBAL PARA COMUNICACIONES

MÓVILES
GSM utiliza 124 canales de frecuencia, cada uno de los cuales utiliza un sistema
TDM de ocho ranuras.
Figura 2.28: Canales de frecuencia en GSM.
824-849 Mhz canal ascendente.
869-894 Mhz canal descendente.
Longitud de onda es 40 cm, antenas grandes.
A continuación se muestra parte de la estructura de entramado de GSM:

50 2.5. EL SISTEMA TELEFÓNICO MÓVIL
Figura 2.29: Estructura de entramado GSM.
Teléfonos móviles 3G: voz y datos digitales
2.5.4. TELÉFONOS MÓVILES 3G: VOZ Y DATOS DIGITALES

Los servicios básicos que debe proporcionar son:
Transmisión de voz de alta calidad.
Mensajería (reemplazando e-mail, fax, SMS, chat, etc.).
Multimedia (música, videos, películas, TV, etc.).
Acceso a Internet (navegar con audio y video).
Se basa en una técnica completamente distinta a FDM o TDM. Es CDMA.
CDMA
CDMA (Acceso múltiple por división de código) técnica que podría compararse
a una sala de espera en un aeropuerto: si con TDM las personas en el medio de la
sala esperan su turno para hablar y con FDM las personas en grupos separados am-
pliamente, cada grupo tiene su conversación al mismo tiempo, con CDMA todas las
personas están en medio de la sala hablando al mismo tiempo, en lenguajes diferentes.
En CDMA, cada tiempo de bit, se subdivide en m intervalos cortos llamados chips.
Por lo general hay 64 o 128 chips por bit. Se define entonces una secuencia de chips
para cada estación, de forma que para transmitir un bit envía su secuencia de chips y
para enviar un cero la secuencia negada.
REDES
LA CAPA DE ENLACE DE DATOS
El objetivo de esta capa es lograr una comunicación confiable y eficiente entre dos
máquinas adyacentes, es decir, dos máquinas que estén conectadas por un canal de
comunicaciones. Para llevar a cabo esta labor además hay que realizar un estudio de
una serie de técnicas que nos permitan la detección de errores y la posible corrección
de los mismos. Las causas principales de estos errores son:
1. Los circuitos de comunicación cometen errores.

2. Los circuitos tienen una tasa de datos finita.
3. Tienen un retardo de propagación distinto de cero.
El IEEE divide la capa de enlace OSI en dos subcapas:
1. Control de acceso al medio (MAC) (realiza transiciones hacia los medios).

2. Control de enlace lógico (LLC) (realiza transiciones hasta la capa de red, inde-
pendiente de la tecnología).
3.1. FUNCIONES A DESEMPEÑAR POR LA C.

ENLACE DE DATOS
La capa de en lace de datos tiene que desempeñar varias funciones específicas,
que incluyen proporcionar una interfaz de servicio bien definida con la capa de red,
51
52 3.1. FUNCIONES A DESEMPEÑAR POR LA C. ENLACE DE DATOS
determinar la manera en que los bits de la capa física se agrupan en marcos, manejar
los errores de transmisión y regular el flujo de marcos para que los receptores lentos no
sean abrumados por los transmisores rápidos.
A continuación se va a hacer un estudio más detallado de las funciones que debe
realizar esta capa:
3.1.1. SERVICIOS QUE DEBE PROPORCIONAR A LA CA-

PA DE RED
El servicio principal que esta capa debe proporcionar a la capa de red es la trans-
ferencia de datos entre la capa de red de la máquina origen y la capa de red en la
máquina destino. En la figura siguiente se muestra esto:
Figura 3.1: (a) Comunicación virtual. (b) Comunicación real.
A partir de ahora vamos a tomar como referencia, para evitar una mayor com-
plejidad, que la comunicación que se realiza entre dos capas de red homólogas es la
comunicación virtual (a).
Normalmente la capa de enlace de datos proporciona tres servicios a la capa de
red:
1. Servicio sin acuse sin conexión:

La capa envía marcos independientes a la máquina destino sin pedir que ésta
los reconozca o acuse su recibo. No establece conexión de antemano ni se libera
después. Se suele usar para redes donde la tasa de error es muy baja, dejando el
control de errores a capas más altas.
2. Servicio con acuse sin conexión:
Hay una solicitud y se envían una serie de marcos que serán reconocidos de forma
individual. Es útil en sistemas poco estables como los sistemas inalámbricos.
REDES
3. Servicio con acuse con conexión:

Se establece una conexión entre origen y destino y se comienza a transferir datos.
Es el servicio que proporciona a la capa de red un flujo confiable. En él las tramas
están numeradas y te asegura que siempre llegan en orden al destino y consta de
tres fases:
a) Se solicita y establece conexión.

b) Se realiza una transmisión de uno o varios marcos.
c) Se cierra la conexión.
3.1.2. ENTRAMADO
A fin de proporcionar los servicios a la capa de red, debe hacer uso de los servicios
que le proporciona la capa inmediatamente inferior: la capa física, que se encarga enviar
los datos, pero no de hacer que el flujo esté libre de errores. Es responsabilidad de esta
capa hacer comprobar y corregir en caso de que sea necesario corregirlos.
Uno de los puntos a tener en cuenta a la hora de corregir los errores es el entramado,
que consiste en comprobar que el número de bits recibidos sea igual al de bits enviados.
Para ello, y debido a las características del medio, es necesario dividir el flujo de bits
a enviar en marcos o tramas, enviarlos y una vez recibidos comprobar que estén libres
de errores y unirlos. Para ello se puede hacer uso de varios métodos:
1. CONTEO DE CARACTERES
Este método se vale de un campo de encabezado para especificar el número de

caracteres en el marco, de forma que cuando la capa de enlace de datos del destino ve
la cuenta de caracteres, sabe cuántos caracteres le siguen.
Ejemplo:
Figura 3.2: Corriente de caraceres. (a) Sin errores. (b) Con un error.
54 3.1. FUNCIONES A DESEMPEÑAR POR LA C. ENLACE DE DATOS
Presenta un problema y es que el en caso de alterarse la cuenta, el destino perderá

la sincronía y será incapaz de localizar el inicio del siguiente marco.
2. CARACTERES DE INICIO Y FIN: RELLENO DE CARACTERES
Este método supera el problema de la resincronización tras un error haciendo que

cada marco comience con una secuencia de caracteres ASCII DLE STX y termite con
la secuencia DLE ETX. (DLE es data link scape; STX es start of text).
Puede ocurrir perfectamente que en una trama vaya el carácter DLE o un caracter
STX. Para evitar problemas la capa origen se añade un caracter DLE seguido de uno
de estos caracteres y luego la capa receptora lo interpretará como un único DLE o
STX.
Figura 3.3: (a) Trama de datos usando relleno de caracteres. (b) Ejemplos de secuencias
de bytes antes y después del relleno de caracteres.
Un problema que presenta este esquema es que el tamaño de los caracteres debe ser
fijo (ASCII que tiene 8 bits). Con el avance de las redes esto ha supuesto un problema
y ha sido necesario desarrollar una nueva técnica que trate con caracteres de tamaño
arbitrario.
3. INDICADORES DE INICIO Y FIN: RELLENO DE BITS
Técnica que permite que los marcos de datos contengan un número arbitrario de
bits y admite códigos de caracteres con un número arbitrario de bits por carácter.
REDES
Funcionamiento:
Cada marco comienza y termina con un patrón especial de bits, 01111110, llamado
byte indicador.
Cada vez que la capa de enlace de datos del transistor encuentra cinco unos con-
secutivos en los datos automáticamente inserta un bit 0 que luego el receptor lo omitirá
en cuanto se encuentre con esta secuencia de caracteres. En cuanto al los DLE, si se
encuentra en la trama como texto, se le incluye otro delante de éste.
Figura 3.4: (a) Relleno de bits. (b) Los datos, según aparecen en la línea. (c) Los datos,
como se guardan en memoria del receptor tras remover el relleno.
3.1.3. CONTROL DE ERRORES

Una vez asegurado el problema del entramado es necesario resolver el problema
de la entrega de los marcos en cuanto al orden se refiere.
Existen varias técnicas para hacer frente a este problema. Algunas de ellas son
consisten en asignarle al transmisor una realimentación sobre qué está ocurriendo al
otro lado de la línea o introducir temporizadores en la capa de enlace de datos para
que si llega un marco erróneo al destino y no haya un acuse del siguiente marco en un
determinado tiempo, se vuelva a enviar.
3.1.4. CONTROL DE FLUJO

Se usa para abordar el problema de asincronía en cuanto a la velocidad. Para ello
existen varias técnicas, pero todas se basan en la introducción de un control de flujo
para controlar la velocidad del emisor de modo que no envíe a mayor velocidad que la
que puede manejar el receptor.
3.2. DETECCIÓN Y CORRECCIÓN DE ERRORES

En este aspecto se pueden cosiderar dos estrategias y el uso de un tipo u otro va
a depender del medio en el que se realice la transmión:
56 3.2. DETECCIÓN Y CORRECCIÓN DE ERRORES
1. Códigos de corrección de errores:

En los canales que causan muchos errores es mejor agregar la redundancia su-
ficientes a cada bloque, para que el receptor lo corrija sobre la marcha, canales
inalámbricos (técnicas FEC, corrección de errores en el destino, no precisan canal
de retorno, ni control de flujo).
2. Códigos de detección de errores:
Se usan en canales como la fibra o cobre altamente confiables donde es más
económico detectar y retransmitir. Se usan técnicas de la familia ARQ (petición
automática de retransmisión).
3.2.1. CÓDIGOS DE CORRECCIÓN DE ERRORES

Para poder afrontar el problema de la corrección de errores hay que realizar pre-
viamente un estudio profundo sobre qué es en realidad un error. Lo vamos a realizar
mediante un ejemplo:
Dado un marco de m bits de datos y r bits de redundancia se considera como
palabra código a la palabra que contiene el dato codificado y de tamaño n = m × r.
Dadas dos palabras código cualesquiera es posible determinar cuántos bits difiere
con una simple operación XOR contando el número de unos de la palabra resultante.
A la cantidad de bits que difieren dos palabras código se le denomina distancia de
Hamming.
Las capacidad de detección y corrección de errores de un código depende de la
distancia Hamming. Para detectar d errores se requiere una distancia Hamming de
al menos d + 1. En otras palabras, si dos palabras codificadas están separadas una
distancia d, se requerirán d errores de 1 bit, para convertir una palabra en la otra.
Ejemplo para m = 2 y n = 5:
Bloque de datos Palabra código

00 00000
01 00111
10 11001
11 11110
La distancia mínima entre palabras es dm = 3.

Imaginemos que se recibe 00100. Calculemos la distancia mínima:
d(00000, 00100) = 1;
d(00111, 00100) = 2;
d(11001, 00100) = 4;
d(11110, 00100) = 3;
Lo más probable es que se haya enviado un 00000, pero si se envía 00111 y una
ráfaga de error de bits cambia los 111 por 000, el receptor recibe 00000 y cree que no
ha habido error.
REDES
Para corregir d errores en una palabra se necesita un código de distancia 2d + 1,

pues así las palabras de código legales están tan separadas que, aun con d cambios,
la palabra código original sigue estando más cercana de cualquier otra palabra código,
por lo que puede determinarse de manera única.
Imaginemos que queremos diseñar un código con m bits de mensaje y r bits de
comprobación que permitirá la corrección de todos los errores individuales. Cada uno
de los 2m mensajes legales requiere n + 1 patrones de bits dedicados a él. Dado que la
cantidad de patrones de bits es 2n , debemos tener (n + 1)2m ≤ 2n . Usando n = m + r,
este requisito se vuelve (m + r + 1) ≤ 2r . Dado m, esto impone un límite inferior de
cantidad de bits de comprobación necesarios para corregir errores individuales.
Para lograr este límite inferior teórico, se usa un método de Hamming, donde
los bits de la palabra codificada se numeran en forma consecutiva. Los bits que son
potencia de 2 (1,2,4,8. . . ) son bits de verificación, el resto (3,5,7,9. . . ) se rellenan con
los m bits de datos.
Cada bit de verificación obliga a que la paridad de un grupo de bits, incluyéndolo
a él sea par (o impar).
Un bit puede estar incluido en varios cálculos de paridad, para ver qué bits de
verificación contribuyen a un bit k de datos, se desarrolla k en potencias de 2 (Ej. Bit
11 = 1 + 2 + 8).
Cuando llega una palabra codificada, el receptor inicializa a cero un contador y
examina los bits de verificación para ver si tienen la paridad correcta, sino suma k
al contador. Si al final el contador es cero no hubo error, sino el contador contiene el
índice de bit erróneo, invirtiendo ese bit.
Figura 3.5: Uso de código Hamming en ráfagas para corregir errores.
En la figura se muestra el uso del código Hamming en ráfagas. En él, en vez de

enviarse como filas, se envía por columnas, por lo que un error en ráfaga de k bits,
como mucho habrá afectado 1 bit de cada una de las k palabras codificadas.
58 3.2. DETECCIÓN Y CORRECCIÓN DE ERRORES
3.2.2. CÓDIGOS DE DETECCIÓN DE ERRORES

Se suele usar sobre todo en transmisiones donde el medio es fibra o cable de cobre
donde la tasa de error es mucho más baja y es en estos casos se prefiere códigos de
detección de errores en vez de códigos de corrección de errores puesto que puede ser más
eficiente una detección de un error seguida de una retransmisión que una corrección
del mismo.
Ejemplo: Si consideramos un canal con errores aislados y la tasa de errores es de
10−6 por bit, si el tamaño de bloque es de 1000 bits:
Usando Hamming habría (1001 + r) ≤ 2r ⇒ r = 10 bits de verificación por lo que

habría que hacer uso de 1000 bloques que supondrían una transmisión de 10.000
bits.
Para detectar un solo bloque con un bit de error, basta con un bit de paridad por
bloque. Estamos hablando de transmitir 1000 bits contra 10.000 bits de corrección
Hamming.
En la práctica se usa un método muy difundido: el código polinómico o código

de redundancia cíclica (CRC). Los códigos polinómicos se basan en el tratamiento
de cadenas de bits como representaciones de polinomios de coeficientes 0 y 1 solamente.
Un marco de k bits se considera como la lista de coeficientes de polinomio con k que van
de xk−1 a x0 . Se dice que tal polinomio es de grado k − 1. El bit mayor (más izquierdo)
es el coeficiente de xk−1 , sl siguiente bit es coeficiente xk−2 y así sucesivamente.
Ejemplo: 110001 tiene 6 bits y por tanto representa un polinomio de seis términos
con coeficientes 1, 1, 0, 0, 0 y 1: x5 + x4 + x0 .
En aritmética polinomial, no hay acarreos para la suma, ni resta y son idénticas a
un OR exclusivo (XOR). La división igual que en binario.
Cuando se emplea el método de código polinómico, el transmisor y el receptor
deben acordar un polinomio generador, G(x), por adelantado. Tanto los bits mayor
como menor del generador deben ser 1. Para calcular la suma de comprobación
para un marco con m bits, correspondiente al polinomio M (x), el marco debe ser más
largo que el polinomio generador. La idea es anexar una suma de comprobación al final
del marco de tal manera que el polinomio representado por el marco más la suma de
comprobación sea divisible entre G(x). Cuando el receptor recibe el marco con suma
de comprobación, intenta dividirlo entre G(x). Si hay un residuo, ha habido un error
de transmisión.
El algoritmo para calcular la suma de comprobación es el siguiente:
1. Sea r el grado de G(x). Anexe r bits cero al final del marco, para que ahora
contenga m + r bits y corresponda al polinomio xr M (x).
2. Divida la cadena de bits correspondiente a xr M (x) entre la correspondiente a

G(x) usando división módulo 2.
REDES
3. Reste el residuo (que siempre es de r o menos bits) a la cadena de bits correspon-

diente a xr M (x) usando resta módulo 2. El resultado es el marco con suma de
comprobación a transmitirse. Llame a su polinomio T (x).
La base de este método es la siguiente: Dividendo = Divisor ∗ Cociente + Resto,

por tanto, Dividendo˘Resto es divisible por divisor, G(x).
A continuación se muestra un ejemplo para una trama 1101011011 y un polinomio
generador 10011.
Figura 3.6: Cálculo de la suma de comprobación de código polinómico.
Ciertos polinomios se han vuelto estándares internacionales. El que utiliza 802 es:
G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x1 + 1
Detecta todas las ráfagas con una longitud de 32 ó menor y todas las ráfagas que
afecten un número impar de bits.
Peterson y Brown (1961) implementaron un algoritmo para calcular la suma de
verificación sobre un circuito con registros de desplazamientos y que hoy día, en la
práctica, se usa en la mayoría de los casos.
60 3.3. PROTOCOLOS BÁSICOS DE LA C. DE ENLACE DE DATOS
3.3. PROTOCOLOS BÁSICOS DE LA C. DE EN-

LACE DE DATOS
3.3.1. DEFINICIONES PREVIAS

Una trama consiste en un paquete incorporado (carga útil), cierta información de
control (en el encabezado) y la suma de verificación (en el terminador).
Cuando una trama llega al receptor, el hardware calcula la suma de verificación y si
no es correcta se informa con event=cksum_err, si llega bien se genera event=frame_arrival
y pasa la información sólo de paquete a la capa de red.
Una estructura de datos frame (trama) está compuesto de cuatro campos: kind
(tipo de trama), seq (número de secuencia), ack (conformación de recepción) e info
(contiene el paquete).
Los protocolos suponen un canal inestable que pierde tramas ocasionalmente, por
lo que se arranca temporizador que si expira se vuelve a enviar.
Algunas definiciones necesarias en los protocolos que siguen. Se encuentran en al
archivo protocol.h:
#define MAX_PKT 4 /* determines packet size in bytes */
typedef enum {false, true} boolean; /* boolean type */

typedef unsigned int seq_nr; /* sequence or ack numbers */
typedef struct {unsigned char data[MAX_PKT];} packet; /* packet definition */
typedef enum {data, ack, nak} frame_kind; /* frame_kind definition */
typedef struct { /* frames are transported in this layer */

frame_kind kind; /* what kind of a frame is it? */
seq_nr seq; /* sequence number */
seq_nr ack; /* acknowledgement number */
packet info; /* the network layer packet */
} frame;
/* Wait for an event to happen; return its type in event. */

void wait_for_event(event_type *event);
/* Fetch a packet from the network layer for transmission on the channel. */
void from_network_layer(packet *p);
/* Deliver information from an inbound frame to the network layer. */

void to_network_layer(packet *p);
/* Go get an inbound frame from the physical layer and copy it to r. */

void from_physical_layer(frame *r);
REDES
/* Pass the frame to the physical layer for transmission. */

void to_physical_layer(frame *s);
/* Start the clock running and enable the timeout event. */

void start_timer(seq_nr k);
/* Stop the clock and disable the timeout event. */

void stop_timer(seq_nr k);
/* Start an auxiliary timer and enable the ack_timeout event. */

void start_ack_timer(void);
/* Stop the auxiliary timer and disable the ack_timeout event. */

void stop_ack_timer(void);
/* Allow the network layer to cause a network_layer_ready event. */

void enable_network_layer(void);
/* Forbid the network layer from causing a network_layer_ready event. */

void disable_network_layer(void);
/* Macro inc is expanded in-line: Increment k circularly. */

#define inc(k) if (k < MAX_SEQ) k = k + 1; else k = 0
3.3.2. PROTOCOLO SIMPLEX SIN RESTRICCIONES

Es el más sencillo. En el los datos se transmite sólo en una dirección; las capas de
red tanto del transmisor como del receptor siempre están listas, el tiempo de proce-
samiento puede ignorarse, hay un espacio infinito de buffer y, lo mejor de todo, el canal
de comunicación entre las capas de enlace nunca tiene problemas ni pierde marcos.
El protocolo consta de dos procedimientos distintos, uno transmisor y otro recep-
tor. El transmisor se ejecuta en la máquina origen y el receptor en la máquina destino.
No se usan números de secuencia y el único evento posible es el de llegada de un marco
(que va a estar excento de errores).
De este modo, el receptor es capaz de procesar toda la entrada con una rapidez
infinita y el emisor se mantiene en un bucle enviando datos tan rápido como puede.
Un ejemplo de implementación del protocolo simplex sin restricciones es el siguien-
te:
/* Protocol 1 (utopia) provides for data transmission in one

direction only, from
sender to receiver. The communication channel is assumed to be error free,
and the receiver is assumed to be able to process all the input infinitely fast.
Consequently, the sender just sits in a loop pumping data out onto the line as
fast as it can. */
typedef enum {frame_arrival} event_type; #include "protocol.h"
void sender1(void) {
frame s; /* buffer for an outbound frame */
packet buffer; /* buffer for an outbound packet */
while (true) {
from_network_layer(&buffer); /* go get something to send */
s.info = buffer; /* copy it into s for transmission */
to_physical_layer(&s); /* send it on its way */
} /* tomorrow, and tomorrow, and tomorrow,
Creeps in this petty pace from day to day
To the last syllable of recorded time;
- Macbeth, V, v */
}
void receiver1(void) {
frame r;
event_type event; /* filled in by wait, but not used here */
while (true) {
wait_for_event(&event); /* only possibility is frame_arrival */
from_physical_layer(&r); /* go get the inbound frame */
to_network_layer(&r.info); /* pass the data to the network layer */
}
}
3.3.3. PROTOCOLO SIMPLEX DE PARADA Y ESPERA
En este protocolo nos deshacemos del suspuesto más irreal: la capacidad de la capa
de red receptora de procesar datos de entrada con rapidez infinita (tiene tamaño de
buffer limitado).
El problema principal en este caso es cómo evitar que el transmisor sature al
receptor enviando datos a mayor velocidad de la que este último puede procesarlos.
Una posible solución es calcular el peor tiempo de respuesta del receptor y pro-
gramar al emisor teniendo en cuenta este aspecto, pero este método conduce a un
aprovechamiento del ancho de banda muy por debajo del óptimo.
Otra posible solución es el del envío de pequeños paquetes de confirmación de
envío. Esto es mucho más eficiente. A todos los protocolos que funcionen de esta forma
se les denomina protocolos de parada y espera.
A continuación se muestra un ejemplo de implementación de este protocolo:
REDES
/* Protocol 2 (stop-and-wait) also provides for a one-directional

flow of data from
sender to receiver. The communication channel is once again assumed to be error
free, as in protocol 1. However, this time, the receiver has only a finite buffer
capacity and a finite procesing speed, so the protocol must explicitly prevent
the sender from flooding the receiver with data faster than it can be handled. */
typedef enum {frame_arrival} event_type; #include "protocol.h"
frame s; /* buffer for an outbound frame */
event_type event; /* frame_arrival is the only possibility */
while (true) {
from_network_layer(&buffer); /* go get something to send */
s.info = buffer; /* copy it into s for transmission */
to_physical_layer(&s); /* bye bye little frame */
wait_for_event(&event); /* do not proceed until given the go ahead */
}
}
frame r, s; /* buffers for frames */
event_type event; /* frame_arrival is the only possibility */
while (true) {
wait_for_event(&event); /* only possibility is frame_arrival */
from_physical_layer(&r); /* go get the inbound frame */
to_network_layer(&r.info); /* pass the data to the network layer */
to_physical_layer(&s); /* send a dummy frame to awaken sender */
}
}
3.3.4. PROTOCOLO SIMPLEX PARA UN CANAL RUIDOSO

Este protocolo contempla la situación real de un canal de comunicación que comete
errores donde los marcos pueden llegar dañados o perderse por completo. En este
protocolo se toma como supuesto que le hardware receptor ha detectado fallos de trama
tras haber calculado la suma de comprobación. En el caso de que haya variado tanto
como para que el carácter sea correcto este protocolo fallará.
Una posible solución es modificar el protocolo 2 añadiendo un temporizador. El
transmisor podría enviar un marco, pero el receptor sólo enviaría un marco de acuse si
los datos llegaran correctamente. Si llegara un marco dañado al receptor, se desecharía.
Momentos después, el temporizador del transmisor terminaría y se enviaría el marco
de nuevo. Esta solución presenta un problema y es que si expira el tiempo del tempo-
rizador antes de que haya recibido la trama de confirmación y el receptor ha recibido

correctamente el paquete, aunque ha habido un retardo, el emisor vuelve a enviar a la
trama y el receptor la aceptaría y almacenaría la trama doble puesto que es incapaz
de saber si es una dúplica de la anterior o no.
El problema anterior, aunque es poco probable, es posible, y si se produce la capa
no cumpliría con una de sus labores fundamentales. Este problema podría resolverse
añadiendo un encabezado que indique el número de secuencia, y si es un marco duplica-
do se desecha, pero presenta una ambigüedad y es ¿cuál es el mínimo de bits necesarios
para el número de secuencia?.
A continuación se muestra una implementación de este protocolo:
/* Protocol 3 (par) allows unidirectional data flow over an

unreliable channel. */
#define MAX_SEQ 1 /* must be 1 for protocol 3 */ typedef enum

{frame_arrival, cksum_err, timeout} event_type; #include
"protocol.h"
seq_nr next_frame_to_send; /* seq number of next outgoing frame */
frame s; /* scratch variable */
event_type event;
next_frame_to_send = 0; /* initialize outbound sequence numbers */

from_network_layer(&buffer); /* fetch first packet */
while (true) {
s.info = buffer; /* construct a frame for transmission */
s.seq = next_frame_to_send; /* insert sequence number in frame */
to_physical_layer(&s); /* send it on its way */
start_timer(s.seq); /* if answer takes too long, time out */
wait_for_event(&event); /* frame_arrival, cksum_err, timeout */
if (event == frame_arrival) {
stop_timer(s.seq);
from_physical_layer(&s); /* get the acknowledgement */
if (s.ack == next_frame_to_send) {
from_network_layer(&buffer);
/* get the next one to send */
inc(next_frame_to_send);
/* invert next_frame_to_send */
}
}
}
}
REDES
seq_nr frame_expected;
frame r, s;
event_type event;
frame_expected = 0;
while (true) {
wait_for_event(&event); /* possibilities: frame_arrival, cksum_err */
if (event == frame_arrival) {
/* A valid frame has arrived. */
from_physical_layer(&r);
/* go get the newly arrived frame */
if (r.seq == frame_expected) {
/* This is what we have been waiting for. */
to_network_layer(&r.info);
/* pass the data to the network layer */
inc(frame_expected);
/* next time expect the other sequence nr */
}
s.ack = 1 - frame_expected;
/* tell which frame is being acked */
to_physical_layer(&s);
/* only the ack field is use */
}
}
}
3.3.5. PROTOCOLOS DE VENTANA CORREDIZA
En los protocolos anteriores los marcos de datos se transmiten en una sola direc-
ción. En la mayoría de las situaciones prácticas hay necesidad de transmitir datos en
ambas direcciones. Una manera de lograr la transmisión duplex integral es tener dos
canales de comunicación separados y usar cada uno para tráfico de datos simplex, pero
esto desaprovecharía mucho la línea.
Lo mejor es usar el mismo medio para transmitir marcos en ambas direcciones y
usar un protocolo de confirmación con acuse de datos.
Esta parece la manera más eficiente, pero aún se puede optimizar más: si esperamos
a que la capa de red solicite a la capa de enlace el envío de un acuse, se puede enviar el
paquete de confirmación (ACK ) junto con el acuse. Esta técnica consistente en retardar
temporalmente los acuses para que puedan colgarse del siguiente marco de datos de
salida se conoce como incorporación (piggiybacking).
La solución anterior presenta un problema inexistente anteriormente y es ¿cuánto
tiempo esperar para incorporar un acuse?. La capa del emisor tiene un contador de
tiempo y cuando se le agote volverá a enviar el paquete, frustrando, de este modo, el
propósito de optimizar.
La solución a estos problemas la ofrecen los protocolos de ventana corrediza, que,
en esencia consisten en que, en cualquier instante, el transmisor mantiene un grupo
de números de secuencia que corresponde a los marcos que tiene permitido enviar. Es-
tos marcos caen dentro de la ventana transmisora. De manera semejante, el receptor
mantiene una ventana receptora correspondiente al grupo de marcos que tiene permi-
tido aceptar.
Dado que las tramas que están en la ventana del emisor pueden perderse o dañarse,
el emisor debe mantener todas estas tramas en el búfer para su posible retransmisión.
Si el búfer máximo tiene tamaño n, se dice que la ventana corrediza es de tamaño n.
Si la ventana llega a crecer a su tamaño máximo, la capa de enlace de datos emisora,
deberá hacer que la capa de red, se detenga hasta que se libere otro búfer.
Ambas ventanas no tienen por qué tener el mismo tamaño ni el mismo número de
marcos permitidos y, a diferencia de la ventana emisora, la ventana receptora conserva
siempre el mismo tamaño inicial. Cuando se recibe la trama cuyo número de secuencia
es igual al extremo inferior de la ventana, lo confirma y avanza en uno la ventana.
Figura 3.7: Ventana corrediza de tamaño 1, con un número de secuencia de 3 bits.

(a) Al inicio. (b) Tras la transmisión de la primera trama. (c) Tras la recepción de la
primera trama. (d) Tras recibir la primera confirmación de recepción.
PROTOCOLO DE VENTANA CORREDIZA DE UN BIT
Es un protocolo que usa parada y espera, ya que el transmisor envía un marco y

espera su acuse antes de transmitir el siguiente.
Veamos un ejemplo de implementación del protocolo de ventana corrediza para un
bit:
/* Protocol 4 (sliding window) is bidirectional and is more robust
REDES
than protocol 3. */
#define MAX_SEQ 1 /* must be 1 for protocol 4 */ typedef enum

{frame_arrival, cksum_err, timeout} event_type; #include
"protocol.h"
void protocol4 (void) {

seq_nr next_frame_to_send; /* 0 or 1 only */
seq_nr frame_expected; /* 0 or 1 only */
frame r, s; /* scratch variables */
packet buffer; /* current packet being sent */
event_type event;
next_frame_to_send = 0; /* next frame on the outbound stream */

frame_expected = 0; /* number of frame arriving frame expected */
from_network_layer(&buffer); /* fetch a packet from the network layer */
s.info = buffer; /* prepare to send the initial frame */
s.seq = next_frame_to_send; /* insert sequence number into frame */
s.ack = 1 - frame_expected; /* piggybacked ack */
to_physical_layer(&s); /* transmit the frame */
start_timer(s.seq); /* start the timer running */
while (true) {
wait_for_event(&event); /* could be: frame_arrival, cksum_err, timeout */
if (event == frame_arrival) { /* a frame has arrived undamaged. */
from_physical_layer(&r); /* go get it */
if (r.seq == frame_expected) {
/* Handle inbound frame stream. */
to_network_layer(&r.info);
/* pass packet to network layer */
inc(frame_expected);
/* invert sequence number expected next */
}
if (r.ack == next_frame_to_send) {
/* handle outbound frame stream. */
from_network_layer(&buffer);
/* fetch new packet from network layer */
inc(next_frame_to_send);
/* invert sender’s sequence number */
}
}
s.info = buffer; /* construct outbound frame */

s.seq = next_frame_to_send; /* insert sequence number into it */
s.ack = 1 - frame_expected; /* seq number of last received frame */

to_physical_layer(&s); /* transmit a frame */
start_timer(s.seq); /* start the timer running */
}
}
Normalmente una de las dos capas es la que comienza. Si ambas capas se iniciaran
simultáneamente surgiría un caso excepcional que se analizará mas adelante.
La máquina que arranca obtiene el primer paquete de su capa de red, constituye
un marco a partir de él y lo envía.
La máquina receptora, cuando recibe un marco, lo revisa para ver si está duplicado.
Si el marco es el esperado lo pasa a la capa de red y la ventana del receptor lo envía
hacia arriba.
El campo acuse contiene el último marco recibido sin error. Si este número con-
cuerda con el número de secuencia del marco que está tratando de enviar el transmisor,
éste sabe que ha terminado con el marco almacenado en el búfer y que puede obtener
el siguiente paquete de su capa de red. Si el número de secuencia no concuerda, debe
continuar intentando enviar el mismo marco. Por cada marco recibido se envía uno de
regreso.
Analicemos la situación surgida cuando ambos lados envían simultáneamente un
paquete inicial. El problema se ilustra en la siguiente figura:
Figura 3.8: Protocolo de ventana corrediza de un bit. (a) Caso normal. (b) Caso anor-
mal.
En la parte (a) se muestra la operación normal del protocolo en la que si B espera

el primer marco de A antes de enviar el suyo todos los marcos son aceptados. En la
parte (b) se ilustra la peculiaridad: si A y B inician la comunicación simultáneamente, se
REDES
cruzan sus primeros marcos ocurre que la mitad de los marcos contienen duplicados, aún
no habiendo errores de transmisión. Pueden ocurrir situaciones similares como resultado
de terminaciones del temporizador prematuras, aún cuando un lado comienza primero.
De hecho, si ocurren varias terminaciones prematuras los marcos podrían enviarse tres
o más veces.
PROTOCOLO DE VENTANA CORREDIZA TAMAÑO N
Hasta ahora hemos supuesto que en tiempo de transmisión para el envío de un

marco y su confirmación es insignificante, pero esto no es así, y en situaciones en las que
el viaje de los marcos supongan un tiempo prolongado puede haber grandes problemas
de ineficiencia en el aprovechamiento del canal.
Ejemplo: Un canal de satélite de 50 Kbps con un retardo de propagación de ida y
vuelta de 500 mseg. Supongamos que tenemos que enviar 4 marcos de 1000 bits:
t = 0 ⇒ Se comienza a enviar
t = 20mseg ⇒ se envía por completo la trama
t = 270mseg ⇒ la trama llega al receptor
t = 520mseg ⇒ llega la confirmación recepción
El emisor estuvo bloqueado 500 mseg, por tanto o sea 500/520 = 96 % del tiempo,
sólo se utilizó el 4 % del ancho de banda del canal.
Para evitar esto, es necesario enviar más tramas antes de bloquearse, tamaño
ventana emisor N , en nuestro caso N = 26, en todo momento hay 25 o 26 tramas
pendientes de confirmación.
Pero, si seguimos con este esquema, vuelven a surgir una serie de problemas:
1. ¿Qué ocurre si un marco a mitad de una serie se daña o se pierde?. Llegarán

grandes cantidades de marcos sucesivos al receptor antes de que el transmisor se
entere de que algo va mal.
2. Al llegar un marco al receptor, obviamente debe descartarse, pero, ¿qué hacerse

con los marcos correctos que le siguen?. La capa de enlace de datos está obligada
a entregar los paquetes a la capa de red en secuencia.
Existen dos enfoques básicos para manejar los errores durante el entubamiento:
1. Retroceso N:
El receptor simplemente descarta todos los marcos subsecuentes, sin enviar acuses
para los marcos descartados. De esta forma actúa como una ventana corrediza
de tamaño 1 ya que la capa de enlace de datos se niega a aceptar otros marcos
excepto el siguiente que debe entregar a la capa de red.
2. Repetición Selectiva:
Consiste en hacer que la capa de enlace de datos receptora almacene todos los
marcos correctos a continuación del equivocado. Cuando el transmisor por fin
70 3.4. EJEMPLOS DE PROTOCOLOS DE ENLACE DE DATOS
se da cuenta de que algo va mal, sólo retransmite el marco malo. Si tiene exito
el segundo intento la capa de enlace de datos ahora tendrá muchos marcos co-
rrectos en la secuencia, los cuales puede entregar rápidamente a la capa de red,
reconociendo el número más alto.
Figura 3.9: (a) Protocolo de retroceso N . Tamaño ventana receptor 1 y (b) Protocolo
de repetición selectiva. Tamaño ventana receptor N.
3.4. EJEMPLOS DE PROTOCOLOS DE ENLACE

DE DATOS
3.4.1. HDLC
Deriva de SDLC, protocolo de control sincrónico de enlace de datos (Synchronous
Data Link Control protocol ), protocolo desarrollado por IBM y sometido a ANSI y a
ISO para su aceptación como estándar de Estados Unidos e internacional. ANSI lo
modifico convirtiéndolo en ADCCP (Advanced Data Communicacion Control Proce-
dure, procedimiento avanzado de control de comunicación de datos), e ISO lo
REDES
modificó para convertirlo HDLC (High-level Data Link Control, control de enlace de
datos de alto nivel).
CARACTERÍSTICAS
Es un protocolo orientado a bits y usa el relleno de bits para lograr la transparencia

de datos.
Usa la estructura de datos siguiente:
Figura 3.10: Formato de marco para HDLC.
1. Dirección:
Sirve para identificar una de las terminales. En líneas punto a punto a veces se
usa para distinguir los comandos de las respuestas.
2. Control:
Se usa para números de secuencia, acuses y otros propósitos.
3. Datos:
Puede contener información arbitraria, de longitud arbitraria.
4. Suma de comprobación:
Variación menor del bien conocido código de redundancia cíclica, usando CRC-
CCITT como generador de polinomios. Esta variación consiste en permitir la
detección de bytes de indicación perdidos.
Hay tres tipos de marcos: de información (a), de supervisión (b) y no nu-

merados (c).
Figura 3.11: Campo de control de (a) un marco de control, (b) un marco de supervisión,
(c) un marco no numerado.
72 3.4. EJEMPLOS DE PROTOCOLOS DE ENLACE DE DATOS
Descripción del Campo de Control
Una trama de información:

Secuencia es el número de secuencia de la trama, Siguiente campo de confirma-
ción de recepción superpuesto. El bit P/F significa Sondeo/Final, cuando una
computadora está sondeando un grupo de terminales Cuando es P se invita a la
terminal a enviar datos.
Una trama de supervisión:

Tipo y Siguiente:
00: Receptor preparado, espera trama campo Siguiente.
01: Rechazo simple espera trama campo Siguiente.
10: Receptor no preparado, espera trama campo Siguiente.
11: Rechazo selectivo trama campo Siguiente.
Una trama no numerada:

Se utiliza para propósitos de control como anunciar que una máquina va a ser
desactivada o anunciar su presencia, inicializando los números de secuencia
3.4.2. LA CAPA DE ENLACE DE DATOS EN INTERNET

Internet consiste en máquinas individuales (host y enrutadores) y la infraestructura
que las conecta.
Las computadoras pueden tener acceso a internet por dos formas distintas, bien
a través de una red interna y cuyo enlace a internet es un router en el que el PC
actúa como host en internet, o bien, y es el caso más extendido, a través de modems
y líneas telefónicas de discado donde el PC casero llama a un proveedor de intenet
(compañía comercial que suministra internet).
Figura 3.12: PC conectado a internet vía modem.
REDES
Ambas conexiones a internet requieren un protocolo punto a punto de enlace de

datos en la línea de manejo de marcos, control de errores y las demás funciones de la
capa de enlace de datos. Dos protocolos de este tipo se usan ampliamente en internet:
SLIP y PPP.
1. SLIP - IP DE LÍNEA EN SERIE
Es el más viejo de los protocolos. El protocolo está descrito en RFC 1055 y se

caracteriza por su sencillez. La estación sólo envía paquetes IP en bruto a través de la
línea usando técnicas de delimitación por bytes para delimitar los marcos.
Las versiones más recientes de SLIP efectúan cierta compresión de encabezados
TCP e IP consistentes en omitir el la parte de encabezado común de varios paquetes
consecutivos, que, con frecuencia, suelen tener un encabezado muy similar.
1. PPP - PROTOCOLO PUNTO A PUNTO
Point-to-Point Protocol, protocolo punto a punto. Tiene su origen como objetivo de

diseñar un protocolo de enlace de datos para líneas punto a punto que resolviera todos
estos problemas y que pudiera volverse un estándar oficial de internet. PPP se define
en RCF 1661. PPP realiza una detección de errores, reconoce múltiples protocolos,
permite la necociación de direcciones de IP en el momento de la conexión, permite la
verificación de autenticidad y tiene muchas mejoras respecto a SLIP.
Servicios que proporciona:
1. Un método de enmarcado que delinea sin ambigüedades el final de un marco y el

inicio del siguiente. El formato del marco también maneja detección de errores.
2. Un protocolo de control, de enlace para activar líneas, probarlas, negociar op-

ciones y desactivarlas ordenadamente cuando ya no sean necesarias. Es el proto-
colo LDC (Link Control Protocol, protocolo de control de enlace).
3. Un mecanismo para negociar opciones de capa de red con independencia del

protocolo de red usado. El método escogido consiste en tener un NCP (Network
Control Protocol, protocolo de control de red) distinto para cada red conocido.
El formato de marco de PPP se escogió de modo que fuera muy parecido al for-
mato de marco HDLC, ya que no había razón para reinventar la rueda. La diferencia
principal den PPP y HDLC es que el primero está orientado a caracteres, no a bits.
En particular, PPP, como SLIP, usa el relleno de caracteres de líneas por discado
con módem, por lo que todos los marcos tienen un número entero de bytes. No sólo
pueden mandarse marcos PPP a través de líneas telefónicas de discado, sino que tam-
bién pueden enviarse a través de SONET o de líneas HDLC auténticas orientadas a
bits (por ejemplo, conexiones enrutador-enrutador).
74 3.5. SUBCAPA MAC: CONTROL DE ACCESO AL MEDIO
Formato del marco:
Figura 3.13: Formato de marco PPP.
1. Dirección: Establece el valor binario 11111111 para indicar que todas las esta-
ciones deben aceptar la trama.
2. Control: Tiene un valor 00000011 que indica una trama no numerada, sin
números de secuencia y confirmación de recepción.
3. Protocolo: indica la clase de paquete que está en el campo de carga útil: IP,
IPX, OSI CLNP, XNS.
4. Carga útil y Suma de verificación: Igual que en HDLC.
3.5. SUBCAPA MAC: CONTROL DE ACCESO AL

MEDIO
3.5.1. INTRODUCCIÓN
Si se hace corresponder cada una de las capas del modelo OSI a los elementos
anteriores, se observa que la red local incluye tareas de la capa física y la de enlace. Al
no haber nodos de conmutación no existe encaminamiento que es la función clave de
la capa de red.
Sin embargo las redes locales son muy variadas, por lo que con la idea de simplificar
su normalización el IEEE realiza una división en la capa de enlace en dos subcapas:
1. Subcapa de Control de Acceso al Medio (MAC):

Es la subcapa más cercana a la capa física y se encarga de lidiar con la tecnología
y topología de la red local concreta, así como mecanismos compartir el enlace.
2. Subcapa de Control de Enlace Lógico (LLC): partiendo del servicios pro-

porcionado por la subcapa MAC, ofrece a la capa de red lo que ésta espera,
un enlace no compartido libre de errores, detectándolos y corrigiéndolos si los
hubiere.
REDES
Normas IEEE:
Figura 3.14: Esquema IEEE 802.1.
Figura 3.15: Normas IEEE.
En esta sección se va a tratar el problema de acceso al medio en redes de difusión.

La familia de protocolos que determinan quién va a usar el canal pertenecen a la
subcapa de enlace de datos MAC.
La subcapa MAC tiene especial importancia en estas redes LAN y en general en
redes que usan un canal multiacceso como base de su comunicación.
3.5.2. EL PROBLEMA DEL REPARTO DEL CANAL

El tema central de esta sección consiste en cómo repartir el uso de un canal entre
una serie de usuarios competidores. Para ello existen varias técnicas, entre las princi-
pales podemos señalar:
1. Técnicas de repartición o asignación estática del canal.
2. Técnicas basadas en contienda.
3. Técnicas de selección.
Las anteriores técnicas son puras, que presentan una serie de ventajas e inconve-
nientes. Con idea de adaptarse mejor a ciertas topologías y medios físicos, balanceando
estas ventajas e inconvenientes, existen también técnicas híbridas.
3.5.3. REPARTO ESTÁTICO DEL CANAL

La manera tradicional de repartir un canal es la multiplexación por frecuencia
(FDM) que es un mecanismo eficiente cuando hay una pequeña cantidad de usuarios
con carga una carga de tráfico pesada.
No ocurre lo mismo cuando el número de transmisores es grande y el tráfico es a
ráfagas. Este caso hay un gran desaprovechamiento del canal ya que si hay usuarios
inactivos su parte de ancho de banda del canal no está siendo utilizado.
Ejemplo: Sea:
T , seg, retardo medio del canal,
C, bps, capacidad del canal,
λ tramas/seg, tasa de llegadas de tramas,
1µ media de la función exponencial de densidad de probabilidad que permite calcula
la longitud de trama.
Dividamos el canal en N subcanales independientes, cada uno de capacidad C/N
bps. La tasa media de entrada de cada uno de los subcanales será de λ/N . Recalculando
T obtenemos
1 N
TF DM = = = NT
µ(C/N ) − (λ/N ) µC − λ
El retardo medio al usar FDM es N veces peor que si todos los marcos se aco-
modaran mágicamente de algún modo en una gran cola central.
Lo mismo ocurre con TDM: A cada usuario se le asigna cada N -ésimo intervalo
de tiempo. Si un usuario no usa la ranura asignada, simplemente se desperdicia.
3.5.4. TÉCNICAS DE CONTIENDA. ALOHA Y CSMA

En estas técnicas se reúnen todas aquellas en que las estaciones se pelean (con-
tienden) por el uso del canal.
REDES
Para entenderlo mejor simulemos nuestra red local a un escenario más intuitivo
donde el canal compartido es un cruce de calles y cada calle representa a las estaciones
que generan las tramas, que serán simuladas con los vehículos.
1. ALOHA
En los años 70, Norman Abramson y sus colegas de la Universidad de Hawai

inventaron un método novedoso y elegante para resolver el problema de reparto del
canal. Desde entonces su trabajo ha sido extendido por muchos investigadores. Aunque
el trabajo de Abramson (ALOHA) usó radiotransmisió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 compartido.
La idea de ALOHA consiste en que los usuarios transmiten cuando tengan datos
que enviar, o sea cruzan sin mirar si viene otro vehículo. En difusión siempre un emisor
puede saber si la trama fue destruida o no, escuchando el canal. Si la trama fue destruida
el emisor simplemente espera un tiempo aleatorio y la envía de nuevo El uso real del
canal en ALOHA puede llegar a un 18 %.
Figura 3.16: ALOHA puro. Los marcos son transmitidos en momentos arbitrarios.
Un marco no sufrirá ua colisión si no se envían otros marcos durante una ranura

de un tiempo desde su inicio, como se muestra en la figura:
Figura 3.17: Periodo vulnerable para el marco sombreado en ALOHA.
¿En qué condiciones llegará sin daño el marco sombreado?

Sea t el tiempo requerido para enviar un marco. Si cualquier otro usuario generó
un marco entre el tiempo t0 y t0 + t, el final de ese marco chocará con el comienzo
del marco sombreado. De hecho, el destino del marco sombreado se selló 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 ninguna manera de saber que otro marco ya está
en camino. De manera parecida, cualquier otro marco que salga entre t0 + 1 y t0 + 2t
chocará con el final del marco sombreado.
2. ALOHA RANURADO
En 1972, Roberts publicó un método para duplicar la capacidad de un sistema

ALOHA. Su propuesta fue dividir el tiempo en intervalos discretos, correspondientes
cada uno a un marco. Este enfoque 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 este método, que fue llamado ALOHA ranurado, en contraste con el ALOHA
puro, no permite a una computadora enviar cada vez que se pulsa un retorno de carro
sino que se le obliga a esperar al comienzo de la siguiente ranura, convirtiendo al
ALOHA puro continuo, en discreto.
REDES
Figura 3.18: Periodo vulnerable para el marco sombreado en ALOHA Ranurado.
3. PROTOCOLOS CON ESCUCHA O DETECCIÓN DE PORTADORA.

CSMA
En redes de área local es posible que las estaciones detecten lo que están haciendo
las demás estaciones y adapten su comportamiento con base en ello. De esta forma se
puede lograr una utilización del canal mucho mejor que en ALOHA ranurado.
A la familia de protocolos que actúan de acuerdo con esto se les llaman protocolos
de detección de protadora o CSMA. Existen un gran número de protocolos que
actúen de acuerdo con esta filosofía. Una de las versiones es el protocolo CSMA con
detección de colisión: CSMA/CD.
CSMA/CD (Carrier Sense Multiple Access with Collision Detection) es una de
las mejoras de la familia CSMA, ya que no comienza una transmisión si detecta que
el canal está siendo usado, sino que además si detecta colisión cancela en envío tan
rápido como pueda, sin pararse a acabar de retransmitir el marco. Esto ahorra tiempo
y ancho de banda.
Figura 3.19: CSMA/CD puede estar en tres estados: contención, transmisión o inactivo.
Una vez abortada la transmisión, espera un tiempo aleatorio y vuelve a comenzar,

si el canal está desocupado, con el envío. CSMA/CD consistirá, por tanto, en periodos
alternantes de contención y transmisión, ocurriendo periodos muertos cuando todas las
estaciones están calladas.
Supongamos ahora el caso en que dos estaciones comienzan a transmitir exacta-
mente en el tiempo t0 . ¿En cuanto tiempo se darán cuenta de que ha habido colisión?.
El tiempo mínimo para detectar la colisión es el tiempo que tarda la señal en propagarse
de una estación a otra.
Sea τ el tiempo para que una señal se propague entre las dos estaciones más
lejanas. En τ − ε, 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 supuesto, detecta la colisión casi de
inmediato y se detiene, pero la pequeña ráfaga de ruido no llega a la estación original
hasta 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 2τ sin detectar una colisión. Por
esta razón modelaremos la ranura de contención como un sistema ALOHA ranurado
con un ancho de de ranura de 2τ .
En un cable coaxial de 1 km de longitud, τ ≈ 5µseg. Por sencillez supondremos
que cada ranura contiene sólo 1 bit. Por supuesto, una vez que se ha tomado el canal,
una estación puede transmitir con cualquier tasa que desee.
Figura 3.20: Esquema de funcionamiento de CSMA/CD.
3.5.5. TÉCNICAS DE SELECCIÓN

Las técnicas basadas en contienda vistas son simples y no exigen diálogo ni co-
ordinación entre las estaciones. En situaciones de mucho tráfico su comportamiento
empeora. Volviendo a la metáfora en esta situaciones a uno le gustaría no encontrarse
un STOP, sino un semáforo o un guardia de tráfico.
REDES
Con las técnicas basadas en selección, las estaciones no transmiten cuando lo

desean, sino cuando son requeridas para ello.
El turno de transmisión va a ser rotativo, y va a venir representado por la posesión
de una trama especial denominada testigo.
Cada estación antes de transmitir, debe capturar esa trama especial, y al terminar
debe hacerla circular hasta la siguiente estación, como existe un solo testigo no existe
peligro de colisión.
Se utiliza en topologías bus (lista con copia en todos los nodos y anillo (de un
nodo a su adyacente) IEEE 802.5, FDDI.
3.5.6. PROTOCOLOS SIN COLISIONES

Aunque las colisiones no ocurren en CSMA/CD una vez que una estación ha
tomado sin ambigüedades el canal, aún pueden ocurrir durante el período de contención.
A medida que las redes de fibra óptica muy largas y de gran ancho de banda estos
errores se vuelven más comunes, la combinación de τ grande y marcos cortos volverá
el problema cada vez más grave.
Existen algunos protocolos que resuelven lo anterior, la mayoría de ellos no se
utilizan en los sistemas grandes, pero pueden ser utilizados en el futuro inmediato.
Estos protocolos se aplican para N estaciones, cada una con una dirección única de 0 a
N − 1 incorporada en hardware. El que algunas estaciones puedan estar inactivas parte
del tiempo no importa. En estos casos la pregunta es: ¿qué estación toma el canal tras
una transmisión exitosa?
Estos protocolos son:
1. De mapa de bits.
2. Con conteo descendente binario.
3. De contención limitada.
4. De recorrido de árbol adaptable.
5. De acceso múltiple por división de longitud de onda.
3.5.7. PROTOCOLOS DE LANs INALÁMBRICAS

A medida que crece la cantidad de dispositivos de cómputo y comunicación portátiles,
también crece la demanda de conexión de ellos con el mundo externo. Los primeros
teléfonos portátiles ya tenían la capacidad de comunicarse con otros. No ocurre lo mis-
mo con las computadoras, que aunque posteriormente vía modem lo hacían posible, se
consideraba de una conexión portátil, pero no móvil.
Para lograr la auténtica movilidad las computadoras necesitan usar señales de ra-
dio o infrarrojas para comunicarse. De esta manera, los usuarios dedicados pueden leer
y enviar correo electrónico mientras conducen o navegan. Un sistema de computadoras

portátiles que se comunican por radio puede considerarse una LAN inalámbrica. Es-
tas LAN difieren de las LAN convencionales y requieren protocolos de subcapa MAC
especiales.
Estas LAN presenta problemas distintos que las LAN convencionales en cuanto al
envío de marcos. En ellas hay que tener en cuenta otros aspectos como si el receptor
está siendo interferido por algún emisor que no interfiere al primer emisor o el simple
hecho de si el emisor tiene un radio de alcance suficiente como para llegar al receptor.
Un primer enfoque para usar en una LAN inalámbrica es el uso de CSMA: escuchar
para ver si hay otras transmisiones y si no las hay transmitir. El problema de este
protocolo es que no es realmente adecuado porque lo que importa no es la interferencia
que haya en el transmisor sino en el receptor.
Para ver la naturaleza de este problema podemos hacer uso de la figura siguiente
en la que toas las estaciones tienen el mismo alcance de radio, de forma que pueden
producirse distintos tipos de interferencia: A con B pero no con C y D, C con B y D
pero no con A. . .
Figura 3.21: LAN inalámbrica. (a) A transmitiendo, (b) B transmitiendo.
Una ventaja que presenta esta LAN con respecto a las LAN convencionales es que
se pueden realizar transmisiones simultáneas si existen varios destinos y están fuera del
alcance entre sí.
En cuanto a los problemas que presenta son principalmente dos:
1. Problema de estación opuesta: Un ejemplo es que A quiere transmitir a B y

C también. A y C deducirán que pueden transmitir puesto que ambos no pueden
detectarse ya que están demasiado lejos.
2. Problema de estación expuesta: Supongamos que B está transmitiendo a A
y C quiere transmitir a D. Si C envía causará una mala recepción sólo en la zona
entre B y C en la que no está localizado ninguno de los receptores pretendidos.
MACA
MACA (Multiple Access with Collision Avoidance, acceso múltiple con prevención
de colisión) es uno de los primero s protocolos diseñados para LAN inalámbricas. Se
usó como base del estándar IEEE 302.11 de LAN inalámbricas.
REDES
El concepto en el que se basa es que el emisor estimule al receptor a enviar un

marco corto, de manera que las estaciones cercanas puedan detectar esta transmisión
y eviten ellas mismas hacerlo durante el siguiente marco de datos (grande). El MACA
se ilustra en la siguiente figura:
Figura 3.22: El protocolo MACA. (a) A enviando a B un RTS. (b) B respondiendo

con un CTS.
El funcionamiento de MACA es el siguiente: A comienza por enviar un marco

RT S (Request To Send, solicitud de envío) a B. B contesta con un marco CT S (Clear
To Send, libre para envío). El marco CT S contiene la longitud de datos (copiada del
marco RT S). A la recepción del marco CT S, A comienza la transmisión.
Las estaciones que escuchen a A enviar el marco RT S esperarán un tiempo su-
ficiente para que el CT S se transmita de regreso a A sin conflicto. En cuanto a las
estaciones que estén próximas a B permanecerán inactivas el tiempo de transmisión de
datos, cuya longitud puede determinar examinando el marco CT S.
3.6. IEEE 802.3: ETHERNET
Una de las primeras redes de área local disponible comercialmente. Su origen está
en una red experimental desarrollada por la empresa Xerox.
La IEEE adopta los trabajos previos y define el subnivel MAC y la capa física de
una red local con topología lógica en bus (la topología física puede ser diferente) y un
mecanismo de compartición de enlace basado en contienda con escucha y detección de
colisiones (CSMA/CD).
84 3.6. IEEE 802.3: ETHERNET
3.6.1. CAPA FÍSICA ETHERNET
La larga historia de Ethernet/IEEE 802.3 ha obligado a la necesaria adaptación

tecnológica con el tiempo´.
El IEEE utiliza una nomenclatura estructurada para denominar los distintos medios
físicos usados por Ethernet, que se expresa como sigue: X-MODO-Y:
X: es un número que indica la velocidad en Mbps.
MODO: es una palabra que indica el modo de transmisión usado (Base banda
base y Broad para paso banda).
Y: puede ser una combinación de letras o un número. Una combinación de letras

indica el medio físico usado y un número indica la longitud máxima de dicho
cable en metros.
Los tipos más comunes de LAN 803.3 de banda base son los siguientes:
Nombre Cable Lon. Máx Nodos/Seg Ventajas

10Base5 Coaxial grueso 500 m 100 Cable original, obsoleto
10Base2 Coaxial fino 200 m 30 No necesita concentrador
10BaseT Par trenzado 100 m 1024 Sistema más económico
10BaseF Fibra óptica 2000 m 1024 Mejor entre edificios
Figura 3.23: Tipos más comunes de LAN 802.3 de banda base.
CABLEADO
Comúnmente en Ethernet se usa cinco tipos de cableado. El primero que se usó

fue 10Base5 (Ethernet grueso). En este las conexiones se hacen usando derivaciones
vampiro, en las que se introduce una punta hasta la mitad del núcleo del cable coaxial.
El segundo tipo fue 10Base2 (Ethernet delgado), caracterizado por doblarse con
facilidad. Las conexiones se realizan usando conectores BNC para formar uniones T.
La detección de rupturas de cable, derivaciones malas y conectores sueltos puede
ser un problema. Se han desarrollado varias técnicas para intentar localizarlas, pero
aún así siguieron suponiendo un problema y se ha tenido que buscar nuevas formas de
realizar las conexiones. El resultado ha sido el uso de un concentrador (hub) central en
el que se usa 10BaseT pares trenzados telefónicos.
Estos tres esquemas de alambrado se muestran en la siguiente figura:
REDES
Figura 3.24: El protocolo MACA. (a) A enviando a B un RTS. (b) B respondiendo

con un CTS.
· 10Base-T
Se definió en 1990 y es una de las configuraciones más usadas con medio físico de
par trenzado. Su topología física en estrella, no se adapta a la topología simple de bus,
como red local demanda IEEE, por lo que es necesaria la existencia de un equipo que
emule electrónicamente un bus lógico partiendo del cableado en estrella.
Este equipo se conoce con el nombre de repetidor o hub y es un dispositivo de
capa 1, que se limita a repetir por todos los puertos lo que recibe sin almacenamiento
previo.
Figura 3.25: Esquema de conexión 10Base-T.
CODIFICIACIÓN
Ninguna de las versiones 802.3 usan una codificación binaria directa con 0 volts
para un bit 0 y 5 volts para un bit 1 pues produce ambigüedades.
Lo que necesita es un mecanismo para determinar sin ambigüedades el comienzo

y el final de un bit sin necesidad de un reloj externo. Este mecanismo lo proporcionan
los esquemas de codificación Manchester y Manchester Diferencial.
En la codificación Manchester cada periodo de bit se divide en dos intervalos
iguales. Un 1 binario se envía teniendo el voltaje alto durante el primer intervalo
y bajo durante el segundo. Un 0 binario es justo lo inverso. Este esquema produce
sincronización debido a la alternancia de bits, pero necesita el doble de ancho de banda.
La codificación Manchester diferencial es una variación de la Manchester. En ella
un bit 1 sese indica mediante la ausencia de una transición al comienzo del intervalo y
un bit 0 mediante la presencia de una transición al inicio del mismo. En ambos casos
también hay transición a la mitad. Este esquema requiere un esquema más complejo
pero ofrece inmunidad al ruido.
Figura 3.26: (a) Codificación binaria. (b) Codificación Manchester. (c) Codificación
Manchester Diferencial.
Todos los sistemas 802.3 de banda base usan codificación Manchester debido a su
sencillez.
3.6.2. PROTOCOLO SUBCAPA MAC DE ETHERNET

La estructura de trama de marco de 802.3 se muestra en la siguiente figura:
Figura 3.27: Formato de marco 802.3.
REDES
Descripción:
Cada trama inicia con un preámbulo de 8 bytes, con el patrón de bits 10101010.
La codificación Manchester de este patrón produce una onda cuadrada de 10
MHz para permitir que el reloj del receptor se sincronice con el del emisor.
Contiene direcciones MAC de origen y destino.
El campo tipo indica al receptor qué hacer con la trama: es posible utilizar varios
protocolos de red al mismo tiempo en la misma máquina, por lo que cuando llega
una trama el kernel debe saber a qué proceso de la capa de red enviar la trama
El campo datos puede se estaboleció en un principio que podía ir de 0 hasta

1500 bytes por trama, pero supongamos que un transceptor detecta una colisión
trunca la trama actual, lo que significa que los bits perdidos y los restos de trama
aparecen en todo el tiempo en el cable. Para distinguir las tramas válidas de la
basura se establece una longitud mínima de trama desde la dirección de destino
a la suma de verificación incluyéndolas de 64 bytes.
El campo relleno se utiliza para rellenar la trama para que cumpla la longitud
mínima establecida. Es importante tener una longitud mínima de trama para
evitar que una estación complete la transmisión de una trama corta antes de que
el primer bit llegue al otro extremo. LAN (10Base5) de 10 Mbps y 2500 m con 4
repetidores tiv = 50 µseg, la trama mínima debe tardar este tiempo, a 10 Mbps,
tbit = 100 nseg =>(50 µseg /100 nseg) = 500 bit (aprox 512=64 bytes).
En cuanto al proceso de aleatorización cuando ocurre una colisión en CSMA/CD

se usa el algoritmo de retroceso exponencial binario.
Figura 3.28: La detección de una colisión puede tardar hasta 2τ
Tras una colisión el tiempo se divide en ranuras discretas cuya longitud es igual al
tiempo de propagación de ida y vuelta de la la señal (2t). Tomando en cuenta la ruta
más larga el tiempo de ranura se estableció en 51,2 µseg.
Tras la primera colisión cada estación espera 0 ó 1 tiempo de ranura antes de enviar
de nuevo. Si ocurre una segunda colisión, cada una escoge 0,1,2,3 al azar y espera ese
número de tiempos de ranura. Y así podemos generalizarlo que para i colisiones se
escoge un número aleatorio entre 0 y 2i − 1. Para más de 10 colisiones se congela en
1023 ranuras, para 16 colisiones el controlador tira la toalla e informa a la computadora
del fracaso.
3.6.3. 802.3 CONMUTADA (ETHERNET CONMUTADA)

A medida que se agregan más y más estaciones a una Ethernet, aumenta el trá-
fico. En algún momento la LAN se saturará. Una solución es utilizar una velocidad
mayor, por ejemplo 100 Mbps. Pero con el crecimiento de la multimedia incluso a estas
velocidades o mayores se saturaría.
Existe una solución para tratar con el aumento de carga y es utilizar una Ethernet
conmutada, que contiene un dispositivo conmutador (switch) que repite las tramas que
reciben no por todos los puertos como el repetidor o hub, sino sólo por el puerto al que
está conectado el destinatario.
Figura 3.29: Switch de 24 bocas. Dispositivo de capa 2.
Para esto los switchs contienen una matriz de conmutación de alta velocidad y
espacio para 1 a 32 tarjetas de línea, cada una de las cuales tiene 8 conectores.
Los switch aprenden la ubicación de los posibles destinatarios monitorizando el
campo de dirección origen de las tramas que reciben.
Las ubicaciones aprendidas se refrescan cada cierto tiempo.
La conmutación de tramas puede hacerse sobre la marcha (lo que implica mayor
potencia de proceso y mayor precio) o almacenándolas antes de transmitirlas.
3.6.4. 302.3u (FAST ETHERNET)

Al principio 10 Mbps parecían el cielo, pero la novedad desapareció rápidamente.
Para aumentar la velocidad, la IEEE aprueba la norma 802.3u (Ethernet a 100 Mbps).
Se definió en 1995 y la idea básica era sencilla: mantener todos los formatos ante-
riores de 10BaseT, pero reducir el tiempo de bits de 100 nseg a 10 nseg. Su configuración
REDES
esquemática es la misma que 10BaseT: un cableado en estrella desde cada estación a un

repetidor central. Se conserva el formato de trama y mecanismo acceso (CSMA/CD).
TIPOS DE CABLEADO
Con un cable UTP-3 la velocidad de señalización de 25 MHz, es tan sólo un 25 %

más rápida que los 20 MHz de Ethernet original (10 Mbps y Manchester requiere 2
períodos de reloj por bit), pero se utilizan los 4 cables de Par trenzado): 100BaseT4.
Para el cableado UTP-5, el diseño es más simple porque se pueden manejar señales
de 125 MHz, utilizando sólo los dos cables del centro, uno para enviar y otro para recibir
(full dúplex): 100BaseTx.
La última opción utiliza dos filamentos de fibra óptica multimodo una para cada
dirección (full dúplex): 100BaseFx.
3.6.5. IEEE 802.3z (GIGABIT ETHERNET)
Fue aprobada en 1998, los objetivos del comité fueron los mismos que antes crear
una ethernet 10 veces más rápida (1Gbps) y que fuera compatible con los formatos
anteriores de trama y esquemas de direccionamiento.
Debido a que una trama mínima de 64 bytes ahora puede transmitirse 100 veces
más rápido, que ethernet clásico, la distancia máxima baja a 25 m, lo cual es inacepta-
ble, por lo que se rellena la trama con el hardware emisor hasta extenderla a 512 bytes,
lo cual amplía el radio de red hasta 200 m.
Una vez que la Gigabit Ethernet se estandarizó, el comité fue a por la Ethernet
de 10 Gbps, estándar que fue aprobado por el IEEE en el 2002 como 802.3ae.
3.6.6. IEEE 802.2: CONTROL LÓGICO DE ENLACE
IEEE ha definido un procolo llamado LLC (Control Lógico de Enlace) que opera
por encima de todos los protocolos Ethernet y 802, proporcionando un formato único
y una interfaz con la capa de red para controlar errores y flujo.
90 3.7. IEEE 802.11: LANS INALÁMBRICAS (WIFI)
Figura 3.30: (a) Posición del LLC. (b) Formatos de protocolos.
La capa de red emisora pasa un paquete a LLC usando las primitivas de acceso a
LLC. A continuación la subcapa LLC agrega un encabezado que contiene los números
de secuencia y confirmación de recepción, la estructura resultante se introduce entonces
en el campo de carga útil de una trama 802 y se transmite. En el receptor ocurre le
proceso inverso.
3.7. IEEE 802.11: LANS INALÁMBRICAS (WIFI)
3.7.1. LA PILA DE PROTOCOLOS
En el estándar 802.11 el estándar MAC, determina la forma en que se asigna

el canal inalámbrico, a quién le toca transmitir. LLC oculta las diferencias entre las
variantes 802 para hacerlo imperceptible a la capa de red.
REDES
Figura 3.31: La pila de protocolos en 802.11.
3.7.2. CAPA FÍSICA

En 802.11 se especifican 6 técnicas de transmisión permitidas en la capa física:
Infrarrojos: utiliza transmisión difusa sin línea visual.

FHSS (Espectro disperso con Salto de Frecuencia): utiliza 79 canales,
cada uno de los cuales tiene un A.B. de 1 MHz. Para producir la secuencia de
saltos, se utiliza un generador de números pseudoaletorios con la misma semilla.
Proporciona seguridad contra intrusos.
DSSS (Espectro Disperso de Secuencia Directa): utiliza un esquema pare-
cido a CDMA, transmitiendo 11 chips por bit conocidos como Secuencia de Baker.
Utiliza modulación por desplazamiento de fase y funciona a 1 o 2 Mbps.
OFDM (Multiplexaxión por División de Frecuencias Ortogonales): para
enviar hasta 54 Mbps en la banda ISM más ancha (54 GHz). Utiliza FDM con
52 canales (48 datos y 4 sincronización). Utiliza desplazamiento de fase hasta los
18 Mbps y QAM para velocidades mayores.
HR-DSSS (Espectro Disperso de Secuencia Directa de Alta Velocidad):
utiliza otra técnica de espectro disperso con 11 Megachips/seg para alcanzar 11
Mbps en la banda de 2,4 GHz.
3.7.3. PROTOCOLO DE CAPA MAC

Puede usar dos protocolos:
92 3.7. IEEE 802.11: LANS INALÁMBRICAS (WIFI)
1. CSMA/CA.
2. Ráfaga de fragmentos
CSMA/CA
Usa CSMA/CA (CSMA con prevención de colisiones). El protocolo inicia cuando

A decide enviar datos a B. A inicia enviándole una trama RTS a B de solicitud de
permiso para enviarle una trama. Cuando B recibe esta solicitud le responde afirmati-
vamente con una trama CTS. Al recibir A la trama CTS envía su trama y comienza su
temporizador de ACK. Al recibir correctamente B la trama responde a A con el ACK.
Si el temporizador de ACK de A expira antes de que ACK regrese, todo el protocolo se
ejecuta de nuevo C detecta el RTS y el tiempo que tardará y impone un tipo de canal
virtual ocupado, llamado NAV (Vector deAsignación de Red). D fuera del alcance de
A pero sí de B, sólo detecta el CTS e impone NAV para sí misma.
Figura 3.32: CSMA/CA.
RÁFAGA DE FRAGMENTOS
Método de la ráfaga de fragmentos, donde una trama se divide en fragmentos con

su propia suma de verificación. Con esto se disminuye el problema de un canal ruidoso
como el inalámbrico, pues la probabilidad de que una trama llegue a su destino se
decrementa con la longitud de la trama.
REDES
Figura 3.33: Método de la ráfaga de fragmentos.
3.7.4. ESTRUCTURA DE TRAMA
Figura 3.34: Estructura de trama en 802.11.
Control de trama:
• Version: versión del protocolo.

• Tipo: control, administración o datos.
• SubTipo: RTS o CTS.
• A DS y De DS: va o viene de Ethernet.
• MF: que siguen más fragmentos.
• Retrans.: marca la retransmisión de una trama que se envió anteriormente.
• Ener.: lo utiliza la estación base para poner o sacar la estación en/de hiber-
nación.
• Más: que hay tramas adicionales para el receptor.
• W: se ha codificado la trama utilizando el algoritmo WEP (Privacidad in-
alámbrica Equivalente).
94 3.8. IEEE 802.15: BLUETOOTH
• O: orden estricto
Duración:
Indica cuánto tiempo ocuparán el canal la trama y el ACK.
Dirección 1, 2, 3, 4:
Direcciones Origen, Destino estaciones y Origen y Destino de Estaciones bases
para el tráfico entre celdas.
Secuencia:
Para numerar los fragmentos: de los 16 bits, 12 identifican la trama y 4 el frag-
mento.
Datos.
Suma de Verificación.
3.8. IEEE 802.15: BLUETOOTH
En 1994 la empresa Ericsson se interesó en conectar sus teléfonos móviles y otros

dispositivos (ej. PDAs) sin necesidad de cables. Junto a IBM, Nokia, Intel, Toshiba
(SIG) formaron un grupo para desarrollar un estándar inalámbrico para interconectar
computadoras, dispositivos de comunicaciones y accesorios a través de radios inalám-
bricos de bajo consumo. Surge la competencia con 802.11 interfiriendo entre sí en el
ámbito eléctrico, por lo que IEEE, intenta estandarizarlo respecto a la capa física y
de enlace de datos. Las versiones del SIG y IEEE ahora difieren , pero se espera que
coincidan en breve.
3.8.1. ARQUITECTURA BLUETOOTH
La unidad básica de un sistema Bluetooth es un piconet, que consta de un nodo

maestro y hasta 7 nodos esclavos activos a una distancia de 10 metros. En una misma
sala pueden encontrarse varios piconets interconectados mediante un nodo puente, para
formar una scatternet. Los nodos estacionados son dispositivos que el maestro ha
cambiado a un estado de bajo consumo. Una piconet es un sistema maestro/esclavo con
TDM centralizado, el maestro controla el reloj y determina qué dispositivo se comunica
con él en un momento determinado. No existe comunicación directa esclavo-esclavo.
REDES
Figura 3.35: Dos piconets se pueden conectar para conformar una scatternet.
3.8.2. APLICACIONES BLUTETOOTH
Nombre Descripción
Acceso genérico Base aplicaciones seguras entre M/E.
Descubrimiento de servicios Para descubrir qué servicios ofrecen otros dispositivos.
Puerto Serie Emula una línea serie para aplicaciones heredadas.
Intercambio de objetos Perfil de intercambio de datos cliente-servidor.
Acceso a LAN Protocolo entre un portátil y una LAN fija.
Acceso telefónico a redes Permite a un portátil hacer una llamada telefónica a
través de un móvil con módem.
Fax Permite que máquinas FAX inalámbricas envien FAX a
través de teléfonos móviles.
Telefonía inalámbrica Conecta un teléfono inalámbrico con su estación base.
Intercomunicador Permite que dos teléfonos se conecten como walkie-
talkie.
Diadema telefónica Para comunicarse por voz la diadema y estación base
(móviles manos libre).
Envío de objetos Intercambiar objetos entre dos dispositivos inalámbri-
cos, como imágenes, archivos de datos, etc.
Transferencia de archivos Intercambiar objetos entre dos dispositivos inalámbri-
cos, como imágenes, archivos de datos, etc.
Sincronización Poder cargar datos en una PDA y recuperarlos en casa
96 3.8. IEEE 802.15: BLUETOOTH
3.8.3. LA PILA DE PROTOCOLOS DE BLUETOOTH

Grupo de protocolos agrupados con poco orden en capas.
La estructura de capas no sigue el modelo OSI, ni TCP/IP, aunque IEEE intenta
modificarlo para que sea compatible con 802.
La capa inferior es la capa de radio física, la cual es similar a la capa física de 802.
Se ocupa de la transmisión y la modulación de radio.
La capa de banda base tiene algunos puntos en común con la subcapa MAC,
aunque incluye elementos de la capa física. Se encarga de la manera en que el maestro
controla las ranuras de tiempo y de que éstas se agrupen en tramas.
Figura 3.36: Pila de protocolos Bluetooth.
Descripción:
Administrador de enlaces:
Se encarga de establecer canales lógicos entre dispositivos, incluyendo adminis-
tración de energía, autenticación y calidad de servicios.
Protocolo de Adaptación y Control de Enlaces Lógicos (L2CAP):

Aisla a las capas superiores de los detalles de la transmisión. Es análogo a la
subcapa LLC 802, aunque difiere en el aspecto técnico.
Audio y Control:
Se encargan del audio y control respectivamente sin necesidad de L2CAP.
Capa Middleware:
Contiene una mezcla de diferentes protocolos . IEEE incorporó aquí la subcapa
LLC de 802 para ofrecer compatibilidad con las redes 802.
RFcomm:
Es el protocolo que emula el puerto serie estándar de los PCs para la conexión
de teclados, ratones y módems.
REDES
Telefonía:
Está orientado a los 3 perfiles orientados a la voz. Se encarga del establecimiento
y terminación de llamadas.
Descubrimiento de servicios:
Descubrir servicios dentro de la scatternet.
Capa Superior:
Se ubican las aplicaciones y los perfiles, que utilizan a los protocolos de las capas
inferiores para realizar su trabajo.
Capa Radio:
• Su función es trasladar los bits del maestro al esclavo o viceversa.

• Es un sistema de baja potencia con un rango de 10 metros.
• Opera en la banda ISM de 2,4 GHz.
• 79 canales de 1 MHz cada uno (FDM).
• Modulación es por desplazamiento de frecuencias (FSK) con 1 bit/Hz, siendo
V=1 Mbps.
• Utiliza un espectro de saltos de frecuencia: 1600 saltos/seg y tiempo de
permanencia de 625 µseg. Todos los nodos de piconet saltan de manera
simultánea y el maestro establece a través de un algoritmo pseudoaleatorio
la frecuencia de salto.
• 802.11 y Bluetooth operan en la misma banda y mismos 79 canales por lo
que hay interferencia. Algunas empresas prohíben Bluetooth.
Capa Banda Base:

Es lo más parecido a la Subcapa MAC.
Esta capa convierte el flujo de bits puros en tramas. El maestro de cada piconet
define una serie de ranuras de tiempo de 625 µseg.
Las transmisiones del maestro empiezan en las ranuras pares y la de los esclavos
en las impares (TDM).
Cada trama se transmite por un canal lógico llamado enlace entre el maestro y
el esclavo.
Hay dos tipos de enlace:
1. ACL (Asíncrono no orientado a la conexión): las tramas se pueden perder

y tienen que retransmitirse. Un esclavo puede tener sólo 1 canal ACL con
su maestro.
2. SCO (Síncrono orientado a la conexión): para datos en tiempo real como
las conexiones telefónicas. Las tramas que se envían nunca se retransmiten,
en vez de ello se utiliza código de corrección de errores. Un esclavo puede
establecer hasta tres canales SCO con su maestro, cada enlace puede trans-
mitir un canal de audio de 64 Kbps.
98 3.9. CONMUTACIÓN EN LA CAPA DE ENLACE
3.8.4. ESTRUCTURA DE TRAMA BLUETOOTH
Figura 3.37: Esructura de trama Bluetooth.
Código de acceso: Identifica al maestro, por si el esclavo está al alcance de dos

maestros
Encabezado (154 bits):
• Dirección: A cúal de los 8 dispositivos activos va destinada la trama.

• Tipo: Tipo de trama ACL, SCO, tipo correción errores.
• Bit F: El esclavo lo establece a 1 cuando el buffer está lleno y no puede
recibir más datos.
• Bit A: ACK de conformación de recepción.
• Bit S: Número de secuencia , basado en protocolo parada y espera.
• Suma de verificación.
3.9. CONMUTACIÓN EN LA CAPA DE ENLACE
3.9.1. PUENTES
Muchas organizaciones tienen varias LANs y desean interconectarlas. Este tipo
de redes se puede interconectar mediante dispositivos llamados puentes (bridges), que
funcionan en la capa de enlace de datos.
Este postulado implica que los puentes no examinan la cabecera de la capa de red
y que pueden, por tanto, copiar igualmente paquetes IP, IPX y OSI. En contraste, un
enrutador IP, IPX u OSI puro puede manejar sólo sus propios paquetes nativos.
En algunas situaciones una sola LAN sería adecuada, en términos de carga, pero
si la distancia física entre las máquinas fuese demasiado grande (>2.5 Km), la red no
funcionaría debido al retardo excesivamente grande del viaje de ida y vuelta. La única
solución es segmentar la LAN e instalar puentes entre los segmentos. Con puentes pude
aumentarse la distancia física cubierta.
REDES
Figura 3.38: Lans conectadas mediante un backbone para manejar una carga total
mayor que la capacidad de una sola LAN.
Existen otros muchos motivos por los que es necesario el uso de puentes como
pueden ser la inteconexión de redes de distinto tipo, la introducción de puentes en
lugares críticos para añadir confiabilidad a la red (por ejemplo para aislar nodos de-
fectuosos que comprometan la estabilidad del sistema), para añadir seguridad a una
red a la vez que se reduce el tráfico no reenviandolo a lugares donde no vaya a ser
utilizado. . .
Figura 3.39: Operación de un puente LAN de 302.3 a 802.4.

Una característica de los puentes es que son transparentes. Un puente transparente

trabaja en modo promiscuo, aceptando todo marco transmitido por cualquier LAN a
la que está conectado. Al llegarle un marco el puente debe decidir si lo descarta o lo
reenvía, y de ser lo segundo, en qué LAN poner el marco. Para ello hace uso de una
gran tabla (dispersión) contenida en el puente que debe listar cada posible destino e
indicar a qué línea de salida (LAN) pertenece.
Cuando los puentes se conectan por primera vez las tablas están vacías. Con el
paso del tiempo los puentes donde están los destinos. Si el puente B1, recibe una trama
proveniente de C (dirección origen) en la LAN2, apunta en su tabla que es posible
acceder a C por medio de la LAN2.
Figura 3.40: Configuración con cuatro LAN y dos puentes.
3.9.2. RESUMEN DISPOSITIVOS DE INTERCONEXIÓN

Hasta ahora los dispositivos que hemos visto para la interconexión son conmu-
tadores, concentradores y puentes. Su esquema de funcionamiento se muestra en la
siguiente figura:
Figura 3.41: (a) Concentrador. (b) Puente. (c) Conmutador.
No sólo existen estos dispositivos para la interconexión de redes. Existen otros que
se verán más adelante y que actúan a capas más altas:
REDES
Figura 3.42: Dispositivos de interconexión de redes y capa donde trabajan.

REDES
LA CAPA DE RED
La capa de red se encarga de llevar los paquetes desde el origen hasta el desti-
no. Llegar al destino puede requerir muchos saltos por enrutadores intermedios. Esta
función ciertamente contrasta con la capa de enlace de datos, que sólo tiene la meta
modesta de mover los marcos de un extremo del alambre al otro. Por tanto, la capa de
red es la más baja que maneja la transmisión de punta a punta.
Para lograr su cometido, la capa de red debe conocer la topología de la subred de
comunicación y escoger las trayectorias adecuadas a través de ella; también debe tener
cuidado de escoger las rutas a modo de evitar la carga extra de algunas de las líneas
de comunicación y de los enrutadores mientras deja a otros sin trabajo. Por último,
cuando el origen y el destino están en redes diferentes, es responsabilidad de la capa
de red el manejo de estas diferencias y la resolución de los problemas que causan.
4.1. TEMAS DE DISEÑO EN LA CAPA DE RED

En este apartado veremos algunos de los problemas que deben enfrentar los dis-
eñadores de la capa de red:
1. Conmutación de paquetes de almacenamiento y reenvío.
2. Servicios proporcionados a la capa de transporte.
3. Implementación del servicio no orientado a la conexión.
103
104 4.1. TEMAS DE DISEÑO EN LA CAPA DE RED
4. Implementación del servicio orientado a la conexión.
4.1.1. CONMUTACIÓN DE PAQUETES, ALMACENAMIEN-

TO Y ENVÍO
Supongamos un sistema con los siguientes componentes:
Equipo de la empresa portadora (enrutadores conectados mediante líneas de

transmisión)
El host (H1) conectado a un enrutador (A) de una empresa portadora mediante

una línea alquilada
El host (H2) en una LAN conectado a un enrutador (F) que a su vez tiene una
línea alquilada hasta E
Figura 4.1: Esquema de envío de un paquete de H1 a H2.
Un host transmite al enrutador más cercano un paquete que tiene por enviar. El
paquete se almacena allí hasta que haya llegado por completo, a fin de que la suma de
verificación pueda comprobarse. Después se reenvía al siguiente enrutador hasta que
lega al host destino, donde se entrega.
4.1.2. SERVICIOS PROPORCIONADOS A LA CAPA DE TRANS-

PORTE
La capa de red proporciona servicios a la capa de transporte en la interfaz red/capa.
Esta interfaz, muchas veces tiene especial importancia puesto que, con frecuencia, es
el límite de la subred siendo la interfaz entre la portadora y el cliente. Por esta razón
esta interfaz debe estar especialmente bien definida.
Los servicios de la capa de red se diseñaron con las siguientes metas en mente:
REDES
1. Los servicios deben ser independientes de la tecnología de subred.
2. La capa de transporte debe estar aislada de la cantidad, tipo y topología de las

subredes presentes.
3. Las direcciones de red disponibles para la capa de transporte deben seguir un

plan de numeración uniforme, aun a través de varias LAN y WAN.
Dadas estas metas, los diseñadores de la capa tienen mucha libertad para escribir
especificaciones de los servicios que serán ofrecidos a la capa de transporte. Esta libertad
ha generado numerosos conflictos, sobre todo en la cuestión sobre si la capa de red debe
proporcionar un servicio orientado o no a conexión.
Existe un bando (representado por la comunidad de internet), avalado por 30
años de experiencia con una red de computadoras real y operativa, que alega que la
tarea de la subred es mover bits de un lado a otro y nada más. Desde este punto de
vista la subred es inherentemente inestable.
El otro bando (representado por las compañías telefónicas, y que usan redes ATM)
que, con los 100 años de experiencia exitosa del sistema telefónico mundial, argumenta
que la subred debe proporcionar un servicio confiable, orientado a conexión.
4.1.3. IMPLEMENTACIÓN DE UN SERVICIO NO ORIEN-

TADO A CONEXIÓN (NSOC)
En los servicios no orientados a conexión se envían paquetes independientes de

la organización de tipo sin conexiones a los que se les denomina datagramas, por
analogía con los telegramas.
En el envío de datagramas, los enrutadores usan una tabla (igual que en circuitos
virtuales) que indica la línea de salida a usar para cada enrutador destino posible.
Cada datagrama debe contener la dirección de destino completa. En una red grande
estas direcciones pueden ser bastante largas. Al llegar un paquete, el enrutador busca
la línea de salida a usar y envía de paquete.
106 4.1. TEMAS DE DISEÑO EN LA CAPA DE RED
Figura 4.2: Enrutamiento dentro de una red de datagramas
4.1.4. IMPLEMENTACIÓN DE UN SERVICIO ORIENTADO

A CONEXIÓN (SOC)
Las conexiones deben tener las siguientes propiedades:
1. Antes de enviar datos, un proceso de la capa de red en el lado transmisor debe

establecer una conexión con su igual en el lado del receptor. Cuando se han
enviado los datos se libera la conexión.
2. Al establecerse la conexión, los dos procesos pueden comenzar a negociar los
parámetros, calidad y costo del servicio a proporcionar.
3. La comunicación en ambas direcciones y los paquetes se entregan en secuencia.
4. Se proporciona automáticamente el control de flujo para evitar que un transmisor
rápido descargue paquetes en el conducto con mayor rapidez que aquella con que
puede retirarlos el receptor, lo que conduce a un desbordamiento.
En los servicios orientados a conexión se denomina circuito virtual a una co-

nexión, por analogía con los circuitos físicos instalados por el sistema telefónico.
Los circuitos virtuales generalmente se usan en subredes cuyo servicio primario
está orientado a conexión. La idea en que se basan los circuitos virtuales es evitar tener
REDES
que escoger una ruta nueva para cada paquete o célula enviada. Cuando se establece
una conexión se establece una ruta que seguirán todos los paquetes del origen al destino.
Dado que los paquetes siempre siguen una misma ruta, cada enrutador deberá
mantener una tabla con una entrada por circuito virtual abierto que pasa a través suyo.
Cada paquete que viaja a través de la red debe contener un campo de número de circuito
virtual en su cabecera, además de los número de secuencia, sumas de comprobación y
demás. Al llegar un paquete al enrutador, el enrutador sabe la línea por la que llegó y
el número de circuito virtual. Utilizando esa información debe enviar el paquete por la
línea de salida correcta.
Figura 4.3: Enrutamiento dentro de una subred de circuitos virtuales.

108 4.2. ALGORITMOS DE ENRUTAMIENTO
4.1.5. COMPARACIÓN DE LAS SUBREDES DE DATAGRA-

MAS Y CIRCUITOS VIRTUALES
Asunto Subred de Datagramas Subred de circuitos vir-

tuales
Configuración del cir- No necesaria Requerida
cuito
Direccionamiento Cada paquete contiene la di- Cada paquete contiene un
rección de origen y destino número de CV corto
Información de estado Los enrutadores no contienen Cada CV requiere espacio de
información del estado de las tabla del enrutador por co-
conexiones nexión
Enrutamiento Cada paquete se enruta de Ruta escogida cuando se es-
manera independiente tablece el CV, todos paquetes
siguen esa ruta
Efecto de fallas del en- Ninguno, excepto para paque- Terminan todos los CV que
rutador tes perdidos durante una caída pasan a través del enrutador
Calidad del servicio Difícil Fácil, si se pueden asignar re-
cursos por adelantado para ca-
da CV
Control de congestión Difícil Fácil, si se pueden asignar re-
cursos por adelantado para ca-
da CV
4.2. ALGORITMOS DE ENRUTAMIENTO
La función principal de la capa de red es enrutar paquetes de la máquina origen a

la de destino. Para ello se hace uso de los algoritmos de enrutamiento. Los algoritmos
de enrutamiento que escogen las rutas y las estructuras de datos que éstos usan son un
área principal del diseño de la capa de red.
El algoritmo de enrutamiento es aquella parte del sof tware de la capa de red
encargada de decidir la línea de salida por la que se transmitirá un paquete de entrada.
Si la subred usa datagramas internamente, esta decisión debe hacerse cada vez que
llega un paquete de datos de entrada, dado que la mejor ruta podría haber cambiado
desde la última vez. Si la subred usa circuitos virtuales internamente, las decisiones
de enrutamiento se toman sólo al establecerse un circuito virtual nuevo. A este último
caso se le denomina enrutamiento de sesión.
4.2.1. TIPOS DE ALGORITMOS DE ENRUTAMIENTO
Los algoritmos de enrutamiento pueden agruparse en dos clases principales:
REDES
1. Algoritmos no Adaptables:
No basan sus decisiones de enrutamiento en mediciones o estimaciones del tráfico
y la topología actuales. En cambio la decisión de qué ruta se usará para llegar de
I a J se calcula por adelantado, fuera de línea, y se carga en los enrutadores al
iniciar la red. Este procedimiento se denomina enrutamiento estático.
2. Algoritmos Adaptables:
Cambian sus decisiones de enrutamiento para reflejar los cambios de topología,
y generalmente también el tráfico. Los algoritmos adaptables difieren en el lugar
de obtención de información, el momento de cambio de rutas y la métrica usada
para la optimalidad.
4.2.2. PRINCIPIO DE OPTIMIZACIÓN
Establece que si el enrutador J está en ruta óptima del enrutador I al enrutador K,

entonces la ruta óptima de J a K, también está en la misma ruta. Se puede demostrar
por reducción al absurdo
Como consecuencia directa del principio de optimización, el grupo de rutas óptimas
de todos los orígenes a un destino dado (tomando como métrica de distancia, por
ejemplo, el número de saltos) forman un árbol con raíz en el destino. Este árbol se
conoce como árbol sumidero.
La meta de todos los algoritmos de enrutamiento es descubrir y utilizar estos
árboles sumideros de los enrutadores.
Figura 4.4: (a) Una subred. (b) Arbol sumidero para el enrutador B.
4.2.3. ALGORITMOS ESTÁTICOS
1. ENRUTAMIENTO POR LA RUTA MÁS CORTA: DIJKSTRA
La idea es armar un grafo de la subred, en el que cada nodo representa un enrutador

y cada arco del grafo una línea de comunicación, llamada enlace.
Para elegir una ruta entre un par dado de enrutadores, el algoritmo simplemente
encuentra en el grafo la ruta más corta entre ellos.
A continuación se muestra un ejemplo de cálculo de la ruta más corta entre un
nodo A y otro D usando un grafo ponderado no dirigido, donde las ponderaciones
representan distancias:
Figura 4.5: Los primeros cinco pasos del cálculo de la trayectoria más corta de A a B.
Las flechas indican el nodo de trabajo.
La ruta más corta se mide en base a varias métricas, entre ellas las más usuales
son:
Cantidad de saltos.
Distancia geográfica en Kms.
REDES
Retardo medio de encolamiento.
Costo de comunicación.
En Dijkstra cada nodo se etiqueta (entre paréntesis) con su distancia al nodo

de origen a través de la mejor ruta conocida. Las etiquetas pueden ser tentativas o
permanentes.
En el caso más general, las etiquetas de los arcos podrían calcularse como una
función de la distancia, ancho de banda, tráfico medio, costo de comunicación, longitud
media de las colas, retardo medio y otros factores.
2. INUNDACIÓN
Algoritmo estático en el que cada paquete de entrada se envía por cada una de las
líneas de salida, excepto aquella por la que llegó.
La inundación genera grandes cantidades de paquetes duplicados, de hecho una
cantidad infinita, a menos que se tomen medidas. Para evitar esto se utiliza una técnica
mediante la cual se lleva un registro de los paquetes difundidos segunda vez. Para esto
el enrutador de origen pone un número de secuencia en cada paquete que recibe de sus
hosts.
Cada enrutador necesitará una lista por cada enrutador de origen que indique los
números de secuencia originados en ese enrutador que ya ha visto. Si llega un paquete
duplicado se descarta y no se difunde.
Para evitar que la lista crezca sin límites, cada lista debe incluir un contador, k,
que indique que todos los números de secuencia hasta k ya han sido vistos. Al llegar un
paquete, es fácil comprobar si el paquete es duplicado; de ser así se descarta. Es más,
no se necesita la lista completa por debajo de k, pues k la resume efectivamente.
4.2.4. ALGORITMOS DINÁMICOS

Las computadoras modernas generalmente usan algoritmos de enrutamiento dinámi-
co en lugar de los estáticos. En particular, dos algoritmos dinámicos, el enrutamiento
por vector de distancia y el enrutamiento por estado de enlace, son los más comunes.
1. ENRUTAMIENTO POR VECTOR DISTANCIA O DE BELLMAN-

FORD
Opera haciendo que cada enrutador mantenga una tabla (por ejemplo un vector)
que da la mejor distancia conocida a cada destino y la línea que se puede usar para
llegar ahí. Estas tablas se actualizan intercambiando información con los vecinos.
Cada tabla contiene dos entradas: la línea preferida de salida hacia un destino y
una estimación del tiempo, distancia o cantidad de saltos para llegar a él.
Se supone que el enrutador conoce la “distancia" a cada uno de sus vecinos. Si la

métrica es de escalas, la distancia simplemente es una escala. Si la métrica es la longitud
de cola, el enrutador simplemente examina cada cola. Si la métrica es el retardo, el
enrutador puede medirlo directamente con paquetes especiales ECO, paquetes que el
receptor marca con la hora y los envía de regreso tan rápido como puede.
Figura 4.6: (a) Subred. (b) Entrada de A, I, H, K, y la nueva tabla de enrutamiento

de J.
2. ENRUTAMIENTO POR ESTADO DE ENLACE
El enrutamiento por vector distancia se usó en ARPANET hasta 1979, cuando fue
reemplazado por el enrutamiento por estado de enlace motivado principalmente por no
toner en cuenta el ancho de banda al escoger rutas usando métrica de retardo y, sobre
todo, porque a veces tardaba demasiado en convergir.
El concepto en que se basa el enrutamiento por estado de enlace es sencillo y puede
postularse en cinco partes. Cada enrutador debe:
1. Descubrir a sus vecinos y conocer sus direcciones de red.

2. Medir el retardo o costo para cada uno de sus vecinos.
3. Construir un paquete que indique todo lo que acaba de aprender.
4. Enviar este paquete a los demás enrutadores.
5. Calcular la ruta más corta a todos los demás enrutadores.
REDES
Analicemos más profundamente cada apartado:
1. Conocimiento de los vecinos:

Cuando el enrutador se pone en funcionamiento su primera tarea es averiguar
quiénes son sus vecinos. Para esto envía un paquete HELLO especial a cada línea
punto a punto. El enrutador del otro extremo regresa una respuesta indicando
quién es. Estos nombres deben ser globalmente únicos.
2. Medición del costo de la línea:

El algoritmo de enrutamiento por estado del enlace requiere que cada enrutador
sepa del retardo a cada unos de sus vecinos. Para medirlo se envía un paquete
ECHO especial a través de la línea y una vez que llegue al otro extremo regresarlo
inmediatamente. Se mide entonces el tiempo de ida y vuelta y se divide entre dos.
Esta prueba se puede llevar a cabo varias veces y calcular el retardo medio. En
el cálculo de los tiempos de retardo se pueden incluir las cargas de las líneas, con
lo cual entre dos líneas con igual ancho de banda, una con una carga continua
y otra sin ella, el enrutador considerará como ruta más corta la de la línea sin
carga.
3. Construcción de los paquetes de estado de enlace:

El siguiente paso es que cada enrutador construya un paquete que contenga todos
los datos. La parte difícil es determinar cuándo construir los paquetes. Para ello
pueden construirse bien de manera periódica, a intervalos regulares, o bien con
la caída o reactivación de una línea.
Figura 4.7: (a) Subred. (b) Paquetes de estado del enlace para esta subred.
4. Enviando los paquetes de estado de enlace:

La idea fundamental es utilizar inundación para distribuir los paquetes de estado
enlace. Cada paquete utiliza un número de secuencia, que se incrementa con cada
paquete nuevo enviado. Los enrutadores llevan una tabla para guardar la lista
de paquetes ya vistos y comparar. A cada paquete además, se le incluye la edad
(TTL, time to leave), con lo que el enrutador especifica que pasado ese tiempo
sin recibir lo consideren caído.
Figura 4.8: Buffer de paquetes para el enrutador B de la figura 4-7.
5. Cálculo de las nuevas rutas:

Una vez que un enrutador ha acumulado un grupo completo de paquetes de
estado de enlace, puede construir el grafo de la subred completa. Después se
ejecuta el algoritmo de Dijkstra para construir la ruta más corta a todos los
destinos posibles. Para una subred con n enrutadores cada uno de los cuales
tiene k vecinos, la memoria requerida para almacenar los datos de entrada es
proporcional a k ∗ n. Esto puede ser un problema en redes muy grandes.
3. ENRUTAMIENTO JERÁRQUICO
A medida que crece el tamaño de las redes, también lo hacen de manera propor-
cional las tablas de enrutamiento del enrutador, consumiendo más memoria y tiempo
de CPU para examinarlas.
La red puede crecer hasta tal punto que no sea factible que cada enrutador tenga
una entrada para cada uno de los demás enrutadores, por lo que el enrutamiento debe
hacerse de manera jerárquica como en la red telefónica.
Los enrutadores se dividen en lo que llamaremos regiones, donde cada enrutador
conoce todos los detalles para enviar paquetes dentro de su propia región.
Al volverse una red muy grande, surge una pregunta interesante: ¿cuántos nive-
les debe tener la jerarquía?. Kamoun y Kleinrock (1979) descubrieron que el número
óptimo de niveles para una subred con N enrutadores es de ln N , requiriéndose un
total de e ln N entradas por enrutador. También han demostrado que el aumento en
la longitud media efectiva de trayectoria causada por el enrutamiento jerárquico es lo
bastante pequeña como para ser generalmente aceptable.
REDES
Figura 4.9: Enrutamiento jerárquico.
4. ENRUTAMIENTO POR DIFUSIÓN
En ocasiones los hosts necesitan enviar mensajes a varios hosts o todos los demás.
El envío de un paquete a todos los destinos se llama difusión. Se han propuesto varios
métodos para llevarla a cabo.
Un primer método sería que el host envíe el paquete a todos los destino. Este
método además de desperdiciar ancho de banda necesitaría que el origen tenga una
lista completa de todos los destinos.
La inundación sería otra forma de realizar la difusión, pero presenta otro problema
fundamental: genera demasiados paquetes y consume demasiado ancho de banda.
Un tercer algoritmo es el enrutamiento multidestino. Con este método cada
paquete contiene una lista de destinos o un mapa de bits que indica los destinos desea-
dos. Cuando un paquete llega al enrutador, revisa todos sus destinos para determinar
el grupo de líneas de salida que necesitará. A continuación realiza una copia nueva
del paquete para cada línea de salida a usar e incluye en cada paquete sólo aquellos
destinos que usan la línea. El enrutamiento multidestino es como los paquetes con di-
reccionamiento individual, excepto que, cuando varios paquetes deben seguir la misma
ruta, uno de ellos paga la tarifa completa y los demás viajan gratis.
Un cuarto algoritmo de difusión usa explícitamente el árbol de descenso para
el enrutador que inicia la difusión, o cualquier otro árbol de extensión adecuado. El
árbol de extensión o también llamado árbol sumidero es un subgrupo de la red que
incluye todos los enrutadores pero que no contiene ciclos. Si cada enrutador sabe cuáles
de sus líneas pertenecen al árbol de extensión, puede copiar un paquete de entrada
difundido en todas las líneas del árbol de extensión, excepto en aquella por la que
llegó. Este método hace un uso excelente del ancho de banda, el único problema es que
cada enrutador debe tener conocimiento de algún árbol de extensión para que pueda
funcionar. Esta información va a estar disponible dependiendo del tipo de enrutamiento
usado.
El quinto y último algoritmo es el reenvío por trayectoria invertida y es un
intento de aproximar el comportamiento del anterior, aun cuando los enrutadores no
saben nada en absoluto sobre los árboles de extensión. La idea es excepcionalmente
sencilla una vez planteada: cuando llega un paquete difundido a un enrutador, éste lo
revisa para ver si llegó por la línea normalmente usada para enviar paquetes al origen
de la difusión. De ser así, hay excelentes posibilidades de que el paquete difundido haya
seguido la mejor ruta desde el enrutador y, por tanto, sea la primera copia en llegar al
enrutador. Siendo éste el caso, el enrutador reenvía copias del paquete por todas las
líneas, excepto aquella por la que llegó. Sin embargo, si el paquete difundido llegó por
una línea diferente de la preferida para llegar al origen, se descarta el paquete como
probable duplicado.
Figura 4.10: Reenvío por trayectoria invertida. (a) Subred. (b) Árbol de extensión. (c)
Árbol construido mediante reenvío por trayectoria invertida.
5. ENRUTAMIENTO POR MULTITRANSMISIÓN
Algunas aplicaciones requieren que procesos muy separados trabajen en grupo

(base de datos distribuida), en estos casos es frecuente que un proceso envíe un mensaje
a todos los demás miembros del grupo.
Si el grupo es pequeño y la subred es grande enviar por difusión a todos es costoso
e ineficiente porque la mayoría de los receptores no están interesados en este mensaje.
El envío de un mensaje a un grupo bien definido de tamaño numéricamente grande,
pero pequeño en comparación con la totalidad de la subred se llama multidifusión o
multitransmisión.
REDES
Para multidifusión se requiere administración de grupo. Los hosts deben informar

a los enrutadores a qué grupo pertenecen.
Para realizar enrutamiento de multidifusión, cada enrutador calcula un árbol de
expansión que cubre a todos los demás enrutadores de la subred. Algunos enrutadores
estarán conectados a hosts que pertenecen a uno o más grupos.
Cuando un proceso envía un paquete de multidifusión a un grupo, el primer en-
rutador examina su árbol de expansión y lo recorta, eliminando todas las líneas que
conduzcan a hosts que no sean miembros del grupo.
Figura 4.11: (a) Subred. (b) Árbol de expansión del enrutador extremo izquierdo. (c)
Árbol de multidifusión del grupo 1. (d) Árbol de multidifusión del grupo 2.
6. ENRUTAMIENTO PARA HOSTS MÓVILES
En la actualidad millones de personas tienen computadoras portátiles y quieren

leer sus correos y acceder a sus archivos normales desde cualquier parte del mundo.
Se dice que los host que nunca se mueven son estacionarios y se conectan a la
red por cable o fibra óptica. Los hosts móviles están lejos de casa y necesitan seguir
conectados mientras se mueven.
Cada host móvil se supone que tiene una localidad base que nunca cambia. Los
usuarios también tienen una dirección base permanente, que puede servir para de-
terminar su localidad base, de manera análoga a como el un número telefónico indica
el código del pais y ciudad.

La meta de enrutamiento en sistemas con usuarios móviles es posibilitar el envío de
paquetes a usuarios móviles usando su dirección base, y hacer que los paquetes lleguen
eficientemente a ellos en cualquier lugar donde puedan estar.
El primer modelo propone lo siguiente: el mundo se divide en áreas, cada área
tiene uno o más agentes foráneos, que son procesos que llevan registro de todos los
hosts móviles que visiten el área.
Cada área tiene además un agente base que lleva el registro de todos los hosts
cuya dirección base está en el área, pero que actualmente está visitando otra área.
Cuando un usuario nuevo entra en un área, ya sea al conectarse a ella (LAN) o al
entrar en la celda (célula), su computadora debe registrarse con el agente foráneo de
ese lugar.
Podemos ver este esquema en la siguiente figura:
Figura 4.12: WAN a la que están conectadas LAN, MAN y células inalámbricas.
Igualmente, al salir un usuario de un área, también eso debe anunciarse para

permitir que se borre el registro, pero no siempre es así.
Al enviarse un paquete a un usuario móvil, se enruta a la LAN base del usuario,
ya que eso es lo indicado en la dirección, como se muestra en el paso 1 de la figura
4.13. Los paquetes enviados al usuario móvil por su LAN base son interceptados por el
agente de base, el cual entonces busca la localidad nueva (temporal) del usuario móvil
y encuentra la dirección del agente foráneo que maneja al usuario móvil. El agente de
base entonces hace dos cosas. Primero, encapsula el paquete en el capo de carga útil
de un paquete exterior y envía este último al agente foráneo (paso 2 de la figura 4.13).
Este mecanismo se llama proceso de túnel. Tras obtener el paquete encapsulado, el
agente foráneo remueve el paquete original del campo de carga útil y lo envía al usuario
móvil como marco de enlace de datos.
Segundo, el agente base indica al transmisor que en lo futuro envíe paquetes al
host móvil encapsulándolos en la carga útil de paquetes explícitamente dirigidos al
REDES
agente foráneo, en lugar de simplemente enviarlos a la dirección base del usuario móvil
(paso 3). Los paquetes subsiguientes ahora pueden enrutarse directamente al usuario
por medio del agente foráneo (paso 4), omitiendo la localidad base por completo.
Figura 4.13: Enrutamiento de paquetes para usuarios móviles.
7. ENRUTAMIENTO EN REDES AD-HOC
No sólo los host son móviles sino también los enrutadores. Entre las posibilidades
vehículos militares en un campo de batalla (sin infraestructura), una flota de barcos en
alta mar que está moviéndose todo el tiempo o una reunión de personas con portátiles
en un área que no cuenta con Wifi (802.11).
Para estos casos se propone el algoritmo de enrutamiento AODV (Vector de
distancia ad-hoc bajo demanda).
4.3. ALGORITMOS DE CONTROL DE CONGESTIÓN

Cuando hay demasiados paquetes presentes en la subred, hay una degradación
del desempeño. Esta situación se llama congestión. Cuando la cantidad de paqutes
descargados en la subred por los hosts está dentro de su capacidad de conducción, todos
se entregan (excepto unos pocos afligidos por errores de transmisión) y la cantidad
entregada es proporcional al número enviado. Sin embargo, a medida que aumenta
el tráfico, los enrutadores ya no pueden manejarlo y comienzan a perder paquetes.
120 4.3. ALGORITMOS DE CONTROL DE CONGESTIÓN
Esto tiende a empeorar las cosas. A muy alto tráfico, el desempeño se desploma por
completo, y casi no hay entrega de paquetes.
Figura 4.14: Cuando se genera demasiado tráfico ocurren congestionamientos y se

degrada marcadamente el desempeño.
La congestión puede ocurrir por varias razones:
Si llegan muchos paquetes por varias líneas de entrada para una misma línea
de salida se generará una cola. Si no hay suficiente memoria para contenerlos a
todos, se perderán paquetes.
Si las CPU de los enrutadores son lentas para llevar a cabo las tareas de admin-
istración requeridas las colas pueden alargarse, aun cuando haya un exceso de
capacidad de línea.
Lo mismo ocurre con líneas con poco ancho de banda.
Generalmente el congestionamiento tiende a alimentarse de sí mismo y empeorar.

Si un enrutador no tiene buffers libres debe ignorar los paquetes de entrada nuevos.
Dado que no se puede descartar el paquete mientras no sea reconocido, el congestio-
namiento en el lado del receptor obliga al transmisor a abstenerse de liberar un buffer
que normalmente había desocupado. De este modo, el congestionamiento se acumula,
como autos que se acercan a una caseta de cobro.
Vale la pena indicar explícitamente la diferencia entre el control de congestiona-
miento y el control de flujo, pues la relación es sutil. El control del congestionamiento
tiene que ver con el aseguramiento de que la subred sea capaz de transportar el tráfico
ofrecido. Es un asunto global. El control de flujo, en contraste, se relaciona con el tráfico
punto a punto entre un transmisor dado y un receptor dado. Su tarea es asegurar que
un transmisor rápido no pueda transmitir datos continuamente a una velocidad mayor
que la que puede absorber el receptor. El control de flujo casi siempre comprende una
retroalimentación directa del receptor al transmisor, para indicar al transmisor cómo
van las cosas en el otro lado.
REDES
4.3.1. PRINCIPIOS GENERALES DEL CONTROL DE CON-

GESTIONAMIENTO.
Muchos problemas de los sistemas complejos, como las redes, pueden verse desde
el punto de vista de la teoría de control. Este enfoque conduce a la división de todas
las soluciones en dos grupos: de ciclo abierto y de ciclo cerrado.
Control de la congestión en ciclo abierto:
Esencialmente, las soluciones de ciclo abierto intentan resolver el problema me-

diante un buen diseño, para asegurarse de que no ocurra desde un principio. Una vez
que el sistema está operando no se hacen correcciones a medio camino.
Las herramientas para llevar a cabo el control de ciclo abierto incluyen decidir
cuándo aceptar tráfico nuevo, decidir cuando descartar paquetes y cuáles, y tomar
decisiones de calendarización en varios puntos de red. Todas tienen en común el hecho
de que toman decisiones independientemente del estado del canal.
Control de la congestión en ciclo cerrado:
En cuanto a las soluciones de ciclo cerrado o ciclo de retroalimentación se rea-

liza una monitorización del sistema, detectando el congestionamiento en un momento
determinado y actuando en consecuencia.
Este enfoque tiene tres partes:
1. Supervisar el sistema para detectar cuándo y donde ocurren congestionamientos.

2. Pasar esta información a lugares en los que puedan llevarse a cabo acciones:
El enrutador que detecta la congestión, envía un paquete, pero si hay con-

gestión es ineficiente.
Se puede reservar un bit en cada paquete de salida para avisar a los vecinos
de que está congestionado.
Que los enrutadores envién paquetes de sondeo para preguntar sobre con-
gestión. Metáfora: helicóptero ciudad.
3. Ajustar la operación del sistema para corregir el problema.
Pueden usarse varias métricas para supervisar la red en búsqueda de congestiona-

mientos. Las principales de estas son el porcentaje de paquetes descartados debido a
falta de espacio de buffer, la longitod promedio de las colas, la cantidad de paquetes
para los cuales termina la temporización, por lo que se transmiten de nuevo, el retardo
promedio de los paquetes y la desviación estándar del retardo de paquete.
El segundo paso del ciclo de realimientación es la transferencia de información
relativa al congestionamiento desde el punto en que se detecta hasta el punto en que
puede hacerse algo al respecto. La manera obvia es que el enrutador que detecta el
congestionamiento envíe un paquete al origen del tráfico, anunciando el problema. Por
supuesto, estos paquetes extra aumentan la carga precisamente en el momento en que
que no se necesita más carga, es decir, cuando la subred está congestionada.
4.3.2. CONTROL DEL CONGESTIONAMIENTO EN LAS SUB-

REDES DE CIRCUITOS VIRTUALES
En subredes de circuitos virtuales, para evitar que los congestionamientos se usan
técnicas enfocadas al control dinámico de congestionamientos. Una de las más usadas
es el control de admisión. La iedea es sencilla: una vez que se ha detectado el con-
gestionamiento, no se establecen circuitos virtuales nuevos hasta que ha desaparecido
el problema, por tanto fallan los intentos por establecer conexiones nuevas de capa de
transporte. Permitir el acceso a más gente simplemente empeoraría las cosas. Aunque
este enfoque es burdo, su implementación es sencilla. En el sistema telefónico se lleva
a cabo esta práctica.
Una enfoque alternativo es permitir el establecimiento de nuevos circuitos vir-
tuales, pero enrutando cuidadosamente los circuitos nuevos por otras rutas que no
tienen problemas. En la siguiente figura se muestra un ejemplo de esto:
Figura 4.15: (a) Subred congestionada. (b) Subred redibujada que elimina el conges-
tionamiento y circuito virtual de A a B.
4.3.3. CONTROL DEL CONGESTIONAMIENTO EN LAS SUB-

REDES DE DATAGRAMAS
Para realizar el control de la congestión en subredes de datagramas se usan las
siguientes técnicas:
1. Bit de advertencia:
Cuando un enrutador está en estado de advertencia, activa un bit especial en el
REDES
encabezado del paquete, que cuando llega al destino lo copia en la confirmación

de recepción que al recibirlo el origen reducía el tráfico.
Figura 4.16: (a)El paquete regulador que sólo afecta al origen. (b) Paquete regu-
lador salto por salto que afecta cada escala por la que pasa.
2. Paquetes reguladores:
El enrutador regresa un paquete regulador al origen, proporcionándole el destino
encontrado en el paquete. El paquete original se etiqueta para que no se generen
más paquetes reguladores en adelante en la ruta.
Cuando el host de origen obtiene el paquete regulador, se le pide que reduzca en
un porcentaje X el tráfico enviado al destino especificado.
3. Paquetes reguladores de salto por salto:

A altas velocidades o distancias grandes, el envío del paquete regulador no fun-
ciona bien porque la reacción es muy lenta.
La idea es hacer que un paquete regulador ejerza su efecto en cada salto que da.
Esta acción impone una mayor carga a los buffers pero da alivio inmediato a la
congestión.
4.3.4. DESPRENDIMIENTO DE CARGA

Cuando ninguno de los métodos anteriores elimina el congestionamiento, los en-
rutadores pueden sacar la artillería pesada: el desprendimiento de carga. El despren-
dimiento de carga es una manera rebuscada de decir que, al inundarse los enrutadores
de paquetes que no pueden manejar, simplemente los tiran.
El paquete a descartar puede depender de las aplicaciones que se estén ejecutando.
Si es una aplicación FTP, se descartan los nuevos, pues si tenemos retroceso N, entonces
habría que reenviar más cantidad de paquetes. En multimedia, se descartan los viejos.
Al tratar con la congestión, es mejor hacerlo una vez detectada por primera vez
que dejar que dañe el trabajo y luego tratar de solucionarlo. En este sentido funciona
el algoritmo de detección temprana aleatoria, que según métricas, comienza a
descartar antes de que sea tarde.
4.3.5. CONTROL DE LA FLUCTUACIÓN

En aplicaciones como la transmisión continua de video y audio no importa gran
cosa si los paquetes tardan 20 mseg o 30 mseg en ser entregados siempre y cuando el
tránsito (retardo) sea constante.
La variación (desviación estándar) en el retardo de los paquetes se conoce como
fluctuación.
Figura 4.17: (a) Alta fluctuación. (b) Baja fluctuación.
REDES
Una fluctuación alta, por ejemplo cuando unos paquetes tardan en llegar 20 mseg
y otros 30 mseg resultará en una calidad desigual del sonido o la imagen.
La fluctuación puede limitarse calculando el tiempo de tránsito esperado para cada
salto en la ruta. Cuando un paquete llega a un enrutador, éste lo examina para saber
qué adelantado o retrasado está respecto a lo programado. Si está adelantado se retiene
un tiempo, si está retrasado, se intenta enviar entre los primeros
4.4. CALIDAD DEL SERVICIO: QoS

Un flujo es un conjunto de paquetes que van de un origen a un destino. La necesidad
de cada flujo se puede caracterizar por cuatro parámetros:
1. Confiabilidad.
2. Retardo.
3. Fluctuación.
4. Ancho de banda.
A continuación se van a mostrar una serie de técnicas para alcanzar una buena
QoS.
4.4.1. ALMACENAMIENTO EN BÚFER

Es una técnica útil para reducir la fluctuación. Los flujos pueden almacenarse en
el búfer del del receptor antes de ser entregados, lo cual no afecta la confiabilidad o el
ancho de banda, pero sí incrementa el retardo. Los sitios Web comerciales que contienen
transmisión continua de video o audio utilizan reproductores que almacenan en el búfer
aproximandamente 10 seg antes de reproducir.
Figura 4.18: Refinamiento del flujo de paquetes almacenándolos en el búfer.

126 4.4. CALIDAD DEL SERVICIO: QoS
4.4.2. ALGORITMO DE CUBETA CON GOTEO

Imagíneses una cubeta con un pequeño agujero en el fondo, como se ilustra la
figura. Sin importar la rapidez con que entra agua en la cubeta, el flujo de salida tiene
una tasa constante, ρ, cuando hay agua en la cubeta, y una tasa de cero cuando la
cubeta está vacía. También, una vez que se llena la cubeta, cualquier agua adicional
que entra se derrama por los costados y se pierde (es decir, no aparece en el flujo por
debajo del agujero).
Figura 4.19: (a) Una cubeta con goteo, llena de agua. (b) Cubeta con goteo, llena de
paquetes.
Puede aplicarse el mismo concepto a los paquetes. Cada host está conectado a la
red mediante una interfaz que contiene una cubeta con goteo, es decir, una cola interna
finita. Si llega unp aquete a la cola cuando está llena, se descarta el paquete. En otras
palabras, si uno o más procesos del host tratan de envia paquetes cuando ya está en
cola la cantidad máxima, se descarta el paquete si más.
Este mecanismo convierte un flujo desigual de paquetes de los procesos de usuario
dentro del host en un flujo continuo de paquetes hacia la red, moderando las ráfagas y
reduciendo en buena media las posibilidades de congestionamiento.
Cuando los paquetes son todos del mismo tamaño (por ejemplo células ATM), este
algoritmo puede usarse como se describe. Sin embargo, al usarse paquetes de tamaño
variable, con frecuencia es mejor permitir un número fijo de bytes por pulso, en lugar
de un solo paquete.
REDES
La implementación del algoritmo es fácil. La cubeta con goteo consiste en una cola
finita. Al llegar un paquete, si hay espacio en la cola se agrega a ella; de otro modo se
descarta. En cada pulso de reloj se transmite un paquete (a menos que esté vacía).
Ejemplo de aplicación: Si tenemos una ráfaga de 25 MB/seg con duración de 40
mseg (1 MB de datos) cada segundo y queremos reducirla a 2 MB/seg, podemos usar
una cubeta de ρ = 2 MB/seg y capacidad C = 1 MB. Para calcular la longitud del
intervalo transmisión (S) sería C = ρ ∗ S => S = C/ρ = 500 mseg.
Figura 4.20: Algoritmo de cubeta con goteo. (a) Entrada. (b) Salida.
4.4.3. ALGORITMO DE CUBETA CON TOKENS
Es una variante del algoritmo de cubeta con goteo, pero más flexible. Este algo-
ritmo contiene fichas generadas por un reloj a razón de una ficha cada ∆T seg.
En la figura 4.21 (a) vemos una cubeta que contiene tres fichas, con cinco paquetes
esperando ser transmitidos. Para transmitir un paquete, el emisor debe capturar y
destruir una ficha. En la figura 4.21 (b) vemos que han pasado tres de los cinco paquetes,
pero que los otros dos están atorados, esperando la generación de dos o más fichas.
Este algoritmo, al contrario que el de cubeta con goteo, permite que los hosts in-
activos acumulen permisos para enviar posteriormente ráfagas grandes. Esta propiedad
significa que pueden enviarse a la vez ráfagas de hasta n paquetes, permitiendo cierta
irregularidad en la corriente de salida y dando una respuesta más rápida a las ráfagas
de entrada repentinas.
Otra diferencia es que este algoritmo descarta las fichas cuando la cubeta se llena,
pero nunca descarta los paquetes.
Otra variación es que cada ficha representa el derecho de transmisión, no de pa-
quete, sino de k bytes. Sólo puede transmitirse un paquete si hay suficientes fichas
disponibles para cubrir su longitud en bytes. Las fichas fraccionarias se guardan para
un futuro.
Figura 4.21: Algoritmo de cubeta con tokens. (a) Antes. (b) Después.
Si tenemos una cubeta llena de tokens y una ráfaga de 1 MB llegando a M = 25

MB/seg, la cubeta puede drenarse a 25 MB/seg durante un intervalo de tiempo y
desacelerarse a ρ = 2 MB/seg hasta que se envíe la toda la ráfaga de entrada.
Calculemos la longitud de ráfaga (S) con tasa máxima para evitar derramamiento,
siendo C la capacidad de tokens de la cubeta en bytes, como mientras se envía también
siguen llegando tokens, entonces una ráfaga de salida tiene como máximo C + ρ × S
bytes y la cantidad de bytes en una ráfaga de longitud S y velocidad M es M × S, por
tanto:
C + ρ × S = M × S ⇒ S = C/(M − ρ)
Para C = 250 KB, M = 25 MB/seg, ρ = 2 MB/seg ⇒ S = 11 mseg.

Y el resto para enviar el Mega completo a 2 MB/seg en 362 mseg.
REDES
Figura 4.22: Salida de una cubeta con fichas con capacidades de (a) 250 kB, (b) 500
kB, (c) 750 kB.
4.4.4. CALENDARIZACIÓN DE PAQUETES

Si el enrutador maneja múltiples flujos, existe el peligro de que un flujo acapare
mucha de su capacidad y limite a los otros flujos. La esencia del algoritmo es que los
enrutadores tienen colas separadas, para cada línea de salida. El enrutador explora cir-
cularmente las colas byte a byte, no paquete a paquete hasta que encuentra el instante
en que finalizará cada paquete. En la figura el primer paquete en terminar es C después
de 8 pulsos (virtuales) de reloj.
Figura 4.23: (a) Enrutador con cinco paquetes encolados para la línea O. (b) Tiempos
de terminación de los cinco paquetes.
4.4.5. REENVÍO EXPÉDITO O ACELERADO

Un problema del algoritmo de calendarización de paquetes es que da la misma
prioridad a todos los hosts. En muchas situaciones, es necesario dar a los servidores de
video, o algún tipo de servicio premium alguna prioridad de envío.
Para ello se puede hacer uso del algoritmo de envío expédito. La idea detrás del
servicio expedito es muy simple. Dos clases de servicios están disponibles: regular y
expedito. Los paquetes expedito deben tener la capacidad de transitar la subred como
si no hubieran otros paquetes.
Figura 4.24: Esquema del algoritmo de reenvío expédito o acelerado.
4.4.6. REENVÍO ASEGURADO

Un esquema un poco más elaborado se conoce como reenvío asegurado y se describe
en RFC-2597. Especifica que deberán haber cuatro clases de prioridad y cada una
tendrá sus propios recursos.
El paso 1 es clasificar los paquetes en cuatro clases de prioridades.
El paso 2 es marcar los paquetes de acuerdo con su clase, utilizando un campo de
encabezado.
El paso 3 es pasar los paquetes a través de un filtro modulador/eliminador que
podría retardar o descartar alguno mediante cubeta con goteo o con tokens para dar
una forma aceptable a los cuatro flujos. Estos 3 pasos se realizan en el emisor y se
inyectan en el enrutador.
Figura 4.25: Ejemplo de implementación del algoritmo de reenvío asegurado.
REDES
4.5. LA CAPA DE RED DE INTERNET

Internet puede verde como un conjunto de subredes o sistemas autónomos (AS,
Aotonomous System) interconectados. No hay una estructura real, pero existen varias
redes dorsales principales construidas a partir de líneas de alto ancho de banda y
enrutadores rápidos.
Conectadas a las redes dorsales hay redes regionales y conectadas a estas las LANs
de muchas Universidades y Empresas. En la siguiente figura se representa un dibujo de
esta organización cuasijerárquica.
Figura 4.26: Internet es un conjunto interconectado de muchas redes.
El pegamento que mantiene unida a Internet es el protocolo de capa de red, IP

(Internet Protocol, protocolo Internet). A diferencia de la mayoría de los protocolos de
capa de red anteriores, éste se diseñó desde el principio con la interconexión de redes
en mente. Su trabajo es proporcionar un medio de mejor esfuerzo para el transporte
de datagramas del origen al destino, sin importar si estas máquinas están en la misma
red, o si hay otras redes entre ellas.
La comunicación en Internet funciona de la siguiente forma: la capa de transporte
toma corrientes de datos y las divide en datagramas. En teoría, los datagramas pueden
ser de hasta 64 Kbytes cada uno, pero en la práctica, por lo general, son de unos 1500
bytes. Cada datagrama se transmite a través de Internet, posiblemente fragmentán-
dose en unidades más pequeñas en el camino. Cuando las piezas llegan a la máquina
de destino, son reensambladas por la capa de red, dejando el datagrama original. Este
132 4.5. LA CAPA DE RED DE INTERNET
datagrama entonces es entregado a la capa de transporte, que lo introduce en la co-

rriente de entrada del proceso receptor.
4.5.1. EL PROTOCOLO IP
Un lugar adecuado para comenzar nuestro estudio de la capa de red de Internet
es el formato de los datagramas IP mismos. Un datagrama IP consiste en una parte
de cabecera y una parte de texto. La cabecera tiene una parte fija de 20 bytes y una
parte opcional de longitud variable.
El formato de la cabecera se muestra en la siguiente figura:
Figura 4.27: La cabecera de IP (protocolo de Internet).
Descripción de los campos de la cabecera:
Versión: Lleva el registro de la versión del protocolo (IPv4, IPv6), la 5 fue

experimental.
IHL: Como la longitud del encabezado no es constante, indica la longitud del

mismo en palabras de 32 bits, el valor máximo es 15 (60 bytes ⇒ Opciones tenga
40 bytes ).
Tipo de servicio: Indica las clases de servicio basado en prioridades.
Longitud total: Longitud de todo el datagrama, incluyendo encabezado y datos,

la longitud máxima es 65.535 bytes.
Identificación: Para que el host de destino determine a qué datagrama pertenece

un fragmento recién llegado.
DF: No fragmentar el datagrama.
REDES
MF: Más fragmentos, todos fragmentos de un datagrama excepto el último tienen

este bit activado.
Desplazamiento del fragmento: Indica en qué parte del datagrama actual va

este fragmento. Como son 13 bits, puede haber un máximo de 8192 fragmentos
por datagrama, que a 8 bytes por fragmento son 65.536 bytes por datagrama.
Tiempo de vida (TTL): Es un contador que sirve para limitar la vida de un

paquete, permitiendo una vida máxima de 255 seg. En la práctica cuenta los
saltos, cuando el contador llega a cero, el paquete se descarta.
Protocolo: Indica el protocolo de las capas superiores al que debe entregarse el

paquete. Ej., TCP, UDP.
Suma de verificación: Verifica el encabezado, tiene que calcularse en cada salto,

pues TTL cambia.
Dirección de origen y destino: Indican el número de red y el número de host

de origen y de destino.
Opciones: Se diseñó para proporcionar un recurso que permitiera que las ver-
siones subsiguientes del protocolo incluyeran información no presente en el diseño
original, así como especificar varias opciones para los datagramas, originalmente
cinco opciones:
1. Seguridad: Especifica qué tan secreto es el datagrama.

2. Enrutamiento estricto desde el origen: Indica la ruta completa a seguir.
3. Enrutamiento libre desde el origen: Da una lista de los enrutadores que no
deben evitarse.
4. Registrar la ruta: Hace que cada enrutador agregue su dirección IP (ARPANET
9 enrutadores).
5. Marca de tiempo: Hace que cada enrutador agregue su dirección IP y su
marca de tiempo.
4.5.2. DIRECCIONES IP
Cada host y enrutador de Internet tiene una dirección IP, que codifica su número
de red y su número de host. Todas las direcciones de IP son de 32 bits de longitud y se
usan en los campos de dirección de origen y dirección de destino de los paquetes IP.
Para realizar una representación más fácil se agrupan en octetos de bits separados
por puntos y se representa su equivalente decimal.
Ejemplo: La dirección 10010110110101100110111000010101 se representaría de

la siguiente forma:
10010110 → 150
11010110 → 214
01101110 → 110
00010101 → 21
Siendo el equivalente: 150.214.110.21 (góngora.uco.es)
Existen distintos formatos de direcciones IP. Existen cinco tipo de formatos: de
clase A, B, C, D y E.
Figura 4.28: Formatos de dirección IP.
1. Direcciones de clase A:
Rango: desde 1.0.0.0 hasta 127.255.255.255.
Direccionan 128 redes y 16 Millones de hosts.
2. Direcciones de clase B:
Rango: desde 128.0.0.0 a 191.255.255.255
Direccionan 16.382 redes y 64 K host.
3. Direcciones de clase C:
Rango: desde 192.0.0.0 a 223.255.255.255
Direccionan 2 Millones de redes con 256 hosts cada una.
4. Direcciones de clase D:
Rango: desde 224.0.0.0 a 230.255.255.255
Soportan multidifusión.
5. Direcciones de clase E:
Están reservadas para un uso futuro.
Los números de red los asigna ICANN (Corporación de Internet para la Asig-
nación de Nombres y Números).
REDES
DIRECCIONES IP ESPECIALES
Los valores 0 y -1 tienen un significado especial, como se muestra en la siguiente

figura:
Figura 4.29: Direcciones IP especiales.
El valor -1 se usa como dirección de difusión para indicar todos los hosts de la red
indicada.
La dirección IP 0.0.0.0 es usada por los hosts cuando están siendo arrancados,
pero no se usa después. Las direcciones de IP con 0 como número de red se refieren a
la red actual. Estas direcciones permiten que las máquinas se refieran a su propia red
sin saber su número (pero deben saber su clase para saber cuantos 0 incluir).
La dirección que es solo unos (255.255.255.255) permite la difusión en la red local,
por lo común una LAN. Las direcciones con un número de red propio y solamente
unos en el campo de host permite que las máquinas envíen paquetes de difusión LAN
distantes desde cualquier parte de internet.
Por último, todas las direcciones 127.xx.yy.zz se reservan para pruebas de retroa-
limentación. Los paquetes enviados a esta dirección se procesan localmente y se tratan
como paquetes de entrada. Esto permite que los paquetes se envíen a la red local sin
que el transmisor conozca su número. Esta característica también se usa para detección
de fallas en el software de red.
4.5.3. SUBREDES
Como hemos visto todos los hosts de una red deben tener el mismo número de
red. Esta propiedad del direccionamiento puede causar problemas a medida que crecen
las redes.
Ejemplo: Una Universidad que inició con una red clase B, utilizada por un De-
partamento de Informática, se fue ampliando a otros departamentos que utilizaban
repetidores de la red de Informática, pronto se alcanzó el límite de 4 repetidores por
Ethernet, por lo que hizo falta otra organización.
Figura 4.30: Una red de un campus que consiste de LANs de varios departamentos.
En principio una segunda dirección de red, sería difícil teniendo suficientes direc-
ciones hasta 60 K hosts. A, B, C hacen referencia a una red,no a una colección de
LANs.
En lugar de tener una sóla dirección de clase B con 14 bits para el número de red
y 16 bits para el número de host, algunos bits se eliminan del número de host para
crear un número de subred. Ejemplo: Si la Universidad tiene 35 departamentos, podría
utilizar un número de subred de 6 bits y un número de host de 10 bits, lo que permitiría
hasta 64 Ethernets con 1022 (0 y –1 no están disponibles) hosts cada una.
Figura 4.31: Red de clase B dividida en 64 subredes.
Las máscaras de subred también se pueden escribir en notación decimal separada

por puntos 255. 255, 252.0 ó agragando la dirección IP base más una diagonal indicando
número de bits usados para red + subred Ej. 194.24.8.0/22.
Fuera de la red, la subred no es visible, por lo que la asignación de una subred nueva
no requiere comunicación con el ICANN ni modificación de bases de datos externas.
Para el ejemplo anterior (/22) podríamos tener una subred 1 que comience en
130.50.4.1, una subred 2 que comience en 130.50.8.1 y una subred 3 que comience en
130.50.12.1:
Subred 1: 10000010 00110010 000001|00 00000001

Subred 2: 10000010 00110010 000010|00 00000001
REDES
Subred 3: 10000010 00110010 000011|00 00000001
La barra muestra el límite entre el número de subred y el número de host.

Cada enrutador tiene una tabla en la que se lista cierto número de direcciones IP
(red,0) y cierto número de direcciones IP (esta red, host), para saber cómo llegar a
redes distantes y a redes locales respectivamente, lo que evita guardar pares red-host
y se reducen las tablas.
Al introducirse las subredes cambian las tablas agregando entradas con forma (esta
red, subred, 0) y (esta red, esta subred, host), para saber cómo llegar a todas las demás
subredes y hosts de una subred específica.
Ejemplo: Conjunto de asignaciones de IP para interredes de distintas universi-
dades:
Universidad 1a Dirección Última Dirección Cantidad Escrito Como

Cambridge 194.24.0.0 194.24.7.255 2048 194.24.0.0/21
Edinburg 194.24.8.0 194.24.11.255 2048 194.24.8.0/21
(Available) 194.24.12.0 194.24.15.255 2048 194.24.12.0/21
Oxford 194.24.16.0 194.24.31.255 4096 194.24.16.0/20
Figura 4.32: Conjunto de asignaciones de IP.
4.5.4. CIDR: ENRUTAMIENTO INTERDOMINIOS SIN CLASES

IP ha estado en uso intensivo por más de una década; ha funcionado extremada-
mente bien como lo demuestra el crecimiento exponencial de la Internet. Desgraciada-
mente, el IP se está convirtiendo con rapidez en víctima de su propia popularidad:
se le están acabando las direcciones. Este desastre inminente ha propiciado una gran
cantidad de controversias y debates en la comunidad Internet sobre lo que debe hacerse
al respecto.
En teoría existen cerca de dos mil millones de direcciones, pero la práctica de
organizar el espacio de direcciones por clases desperdicia millones de ellas. El mayor
problema reside en las direcciones de clase B están subutilizadas, pues más de la mitad
tienen sólo 50 hosts. Tendrían que haberse creado las C con 10 bits para el host en
lugar de 8 permitiendo 1022 hosts por red, permitiendo 1022 hosts por red.
Con esta solución habría surgido rápidamente otro problema, puesto que las com-
pañías las mayor parte de las compañías habrían usado redes de clase C: habría habido
una explosión de tablas de enrutamiento. Si se usaran medio millón de redes de clase C,
todos los enrutadores de Internet necesitarían una tabla con medio millón de entradas,
una por red, indicando la línea a usar para llegar a esa red, así como otra información.
Se han propuesto otras soluciones y la mayoría, aunque resuelven un problema,
crean uno nuevo.
Una solución que ahora se está poniendo en prácita y que dará a Internet un
respiro es el CIDR (Classless InterDomain Routing, enrutamiento interdominios
sin clases). El concepto básico de CIDR, descrito en RFC 1519, es repartir las redes
de clase C restantes, de las que hay casi dos millones, en bloques de tamaño variable.
Si una instalación necesita 2000 direcciones se le da un bloque de 2048 direcciones y
no una dirección B completa.
Además de usar como unidades de bloques redes contiguas de clase C, las reglas
de asignación para las direcciones de clase C también se cambiaron en el RFC 1519.
El mundo se dividió en cuatro zonas, y a cada una se le dio una parte del espacio de
direcciones de clase C. La asignación fue la siguiente:
Europa: 194.0.0.0 a 195.255.255.255.
Norteamérica: 198.0.0.0 a 199.255.255.255.
Centro y Sudamérica: 200.0.0.0 a 201.255.255.255.
Asia y el Pacífico: 202.0.0.0 a 203.255.255.255.
De este modo, cada región recibió unos 32 millones de direcciones para repartir,
con otros 320 millones de direcciones de clase C, de la 204.0.0.0 a 223.255.255.255,
guardadas como reserva.
En el ejemplo anterior de las Universidades, las tablas de enrutamiento del mundo
se actualizan con estas tres entradas, que contienen una dirección base y una máscara
de subred:
Dirección Red base Máscara de subred Línea saliente

194.24.0.0/21 255.255.248.0 Enviar por e1
194.24.8.0/22 255.255.252.0 Enviar por e2
194.24.16.0/20 255.255.240.0 Enviar por e3
Figura 4.33: Tablas de enrutado actualizadas de acuerdo con CIDR.
Cuando llega un paquete se sigue el siguiente algoritmo en el enrutador:
1. Se extrae su dirección de destino IP.
2. Se recorre la tabla de enrutamiento entrada por entrada, aplicando un AND

booleano (enmascarando) de la dirección de destino con cada máscara de subred
almacenada en cada entrada.
3. Si la dirección resultante coincide con la dirección base de esa máscara, ésa es la

línea por la que hay que reenviar el paquete. Si hay más de una coincidencia se
usa la entrada con la máscara más grande.
Las entradas de las tablas pueden combinarse, para reducir el tamaño de las tablas
del enrutador. Por ejemplo, en el caso anterior: 194.24.0.0/19.
REDES
4.5.5. NAT: TRADUCCIÓN DE DIRECCIÓN DE INTER-

NET
Supongamos el siguiente caso: Un ISP podría tener una dirección de /16 de clase
B (65.535 host). Las direcciones de internet están escasas, y no sólo eso, cada vez existe
más demanda de internet. Si tuviera más clientes se plantearía un problema.
Para resolver este problema se ha planteado una solución: asignar dinámicamente
una dirección de IP a una computadora cuando ésta inicia una sesión y una vez termina
la sesión reasignarla a otra visita. De esta forma con una IP se pueden tener 65.535
hosts pero manejar cientos de miles de usuarios.
Este problema resuelve parcialmente el problema: Para usuarios domésticos con
conexión RTB va bien, pero para empresas y usuarios ADSL que demandan conexión
continua hay que implementar otra solución. La solución final será la implantación
IPv6, pero hasta entonces hay que resolver el problema en la medida que se pueda.
Para ello se propone NAT (RFC 3022). La idea básica es asignar una sola dirección
IP a cada compañía, pero dentro de la empresa cada computadora tiene una IP propia
y única que se usa para enrutar el tráfico interno. Sin embargo cuando el paquete sale
de la empresa y va al ISP, se realiza una traducción de dirección
Para hacer posible este esquema se han declarado tres rangos de direcciones IP
como privadas. Las empresas pueden usarlo internamente cuando lo deseen. La única
regla es que ningún paquete que contenga esas direcciones puede aparecer en Internet.
Los rangos son:
10.0.0.0 a 10.255.255.255/8 (16 Mill de Hosts).
172.16.0.0 a 172.31.255.255/12 (1 Mill de Hosts).
192.168.0.0 a 192.168.255.255/16 (65.535 Hosts).
Cuando un paquete sale de las instalaciones, pasa a través de una caja que convierte
la dirección interna de origen a la verdadera dirección IP (caja NAT) de la empresa,
muchas veces se combina en un cortafuegos (servidor de seguridad) que controla lo que
entra y sale de la empresa.
¿Qué pasa cuando la respuesta vuelve? TCP y UDP tienen encabezados que con-
tienen un puerto de origen y de destino.
En el paquete saliente se reemplaza la dirección de origen 10.x.y.z por la IP y el
campo puerto origen de TCP por un índice en la tabla de traducción que contiene el
puerto de origen y la dirección IP original.
En cuanto al paquete entrante, el puerto origen se extrae del encabezado de TCP y
se utiliza como índice en la tabla de traducción NAT. La dirección IP interna y puerto
de origen TCP se leen e insertan en el paquete y se pasa al enrutador de la empresa
para su entrega.
Figura 4.34: Colocación y funcionamiento de una caja NAT.
4.5.6. PROTOCOLOS DE CONTROL EN INTERNET

Además de IP que se usa para la transferencia de datos, Internet tiene algunos
protocolos de control que se usan en la capa de redes:
ICMP: Protocolo de mensajes de Control en Internet.
ARP: Protocolo de resolución de direcciones.
RARP: Protocolo de resolución de dirección de retorno.
BOOTP: Protocolo Bootstrap.
DHCP: Protocolo de configuración de Host Dinámico.
· ICMP: PROTOCOLO DE MENSAJES DE CONTROL EN INTERNET
Los enrutadores supervisan estrechamente el funcionamiento de Internet. Cuando

ocurre algo inesperado ICMP informa del evento. Hay definidos una docena de tipos
de mensajes ICMP, entre ellos los más significativos son:
Destino inalcanzable: No pudo entregarse el paquete
Tiempo excedido: TTL de un paquete llega a cero
Problema de parámetro: Campo de cabecera no válido
REDES
Control de congestión: paquete regulador

Reenvío: Enseña a un enrutador mejores rutas
Eco: Pregunta a una máquina si está viva
Repuesta Eco: Sí estoy viva
Solicitud de timestamp: Igual que el eco pero marcando el tiempo
Respuesta timestamp: igual respuesta eco pero con tiempo
· ARP: PROTOCOLO DE RESOLUCIÓN DE DIRECCIONES.
Este protocolo se utiliza en las redes locales para enviar paquetes de una máquina
a otra debido a que el hardware de la capa de enlace de datos no entiende de direcciones
IP, por lo que es necesario una conversión de dirección IP a dirección MAC.
Por ejemplo, todas las tarjetas Ethernet que se han fabricado vienen equipadas
con una dirección de Ethernet de 48 bits. Los fabricantes de tarjetas Ethernet solicitan
un bloque de direcciones de una autoridad central para asegurarse de que dos tarjetas
no puedan tener la misma dirección (para evitar conflictos en caso de que dos tarje-
tas aparezcan en la misma LAN). Las tarjetas envían y reciben marcos con base en
direcciones de Ethernet de 48 bits. No saben nada sobre direcciones IP de 32 bits.
Ahora surge una pregunta: ¿cómo se proyectan las direcciones de IP de 32 bits
en direcciones de capa de enlace de datos, como las de Ethernet?. Para explicar el
funcionamiento vamos a usar el siguiente esquema:
Figura 4.35: Tres redes de clase C /24 interconectadas; dos Ethernet y un anillo FDDI.
Imaginemos que el host 1 quiere enviar un paquete al host 2:
1. El host 1 da salida a un paquete de difusión hacia Ethernet preguntando ¿quién

posee la dirección 192.31.65.5?.
2. A cada una le llegará el paquete pero sólo el host 2 responderá con su dirección
Ethernet (E2). De esta manera el host 1 asocia las direcciones.
Este protocolo basado en hacer pregunta y obtener respuesta es ARP.

Se pueden hacer varias optimizaciones para que ARP funcione con más eficiencia
y es guardar el resultado de la correspondencia en una caché, para si tiene que comuni-
carse en poco tiempo con el mismo host evitar una segunda difusión. Esta caché debe
expirar en unos cuantos minutos, para permitir que las correspondencias cambien. Ej.
Fallo de una tarjeta ethernet.
Otra optimización es que cada máquina difunda su correspondencia IP-MAC cuan-
do arranca, así cada máquina que reciba el mensaje lo puede incluir en su caché.
· RARP: PROTOCOLO DE RESOLUCIÓN DE DIRECCIÓN DE RE-

TORNO
ARP resuelve el problema de encontrar qué dirección Ethernet corresponde a una

dirección IP. A veces se tiene que resolver el problema inverso. En particular esto ocurre
cuando se inicializa una estación de trabajo sin disco.
La solución fue RARP. Este protocolo permite que una estación de trabajo recien-
temente inicializada transmita su dirección Ethernet y diga: “Mi dirección Ethernet es
tal. ¿Alquien allá fuera conoce mi dirección?".
El servidor RARP ve esta solicitud y busca la dirección Ethernet en sus archivos
de configuración y devuelve la IP correspondiente.
· BOOTP: PROTOCOLO BOOTSTRAP
Una desventaja de RARP es que usa una dirección de difusión para llegar al
servidor RARP, estas difusiones no las envían los enrutadores por lo que es necesario
tener un servidor RARP en cada red local.
Para resolver el problema anterior se inventó un protocolo de arranque alternativo
llamado BOOTP, que usa mensajes UDP que se envían a través de los enrutadores.
BOOTP proporciona información adicional a una estación de trabajo sin disco,
incluso la dirección IP del enrutador predeterminado y la máscara de subred que debe
usar.
BOOTP tiene la desventaja de que requiere configuración manual de tablas para
relacionar una dirección IP con una MAC. Esto debe hacerlo el administrador del
sistema.
· DHCP: PROTOCOLO DE CONFIGURACIÓN DE HOST DINÁMICO
Es una extensión de BOOTP y permite una asignación de dirección IP de manera

manual y automática. Como RARP y BOOTP se basa en la idea de un servidor especial
que asigna direcciones IP a hosts que lo requieren.
REDES
El servidor DHCP no necesita estar en la misma LAN y si está en otra LAN no

se puede alcanzar por difusión por lo que se requiere en cada LAN de un agente de
retransmisión DHCP.
Para alcanzar su dirección IP, una máquina inicializada recientemente difunde un
paquete DHCP DISCOVER. El agente de su LAN (que contiene la IP del servidor
DHCP) intercepta todas las difusiones DHCP y lo envía al servidor DHCP. El servidor
DHCP le devolverá un paquete con la dirección IP a la que se asociará la máquina.
Figura 4.36: Funcioamiento de DHCP.
4.5.7. PROTOCOLOS DE ENRUTAMIENTO EN INTERNET.

OSPF Y BGP
Internet se compone de una gran cantidad de sistemas autónomos, entendiendo
por sistema autónomo aquel que es manejado por una misma organización y utilizan
el mismo algoritmo de enrutamiento interno.
Un algoritmo de enrutamiento dentro de un sistema autónomo se llama protocolo
de enrutamiento de puerta de enlace interior (IGP).
Un algoritmo para enrutamiento entre sistemas autónomos se llama protocolo de
enrutamiento de puerta de enlace exterior (EGP).
El protocolo IGP de Internet originalmente era RIP (protocolo de vector distancia)
basado en Bellman-Ford hasta 1979 que se sustituyó por el protocolo de estado del
enlace.
En 1990 se normaliza uno nuevo llamado OSFP (Abrir primero la ruta más corta).
· OSPF: PROTOCOLO DE ENRUTAMIENTO DE PASARELA INTE-

RIOR
OSPF, (Open Shortest Path First, abrir primero la trayectoria más corta)
se convirtió en estándar en 1990 sustituyendo a RIP debido a que este algoritmo fun-
cionaba peor en sistemas grandes y tardaba mucho en converger.
Este protocolo se diseño con la meta de cumplir numerosos objetivos, entre ellos
que no fuera un algoritmo patentado por ninguna empresa, que conociera una variedad
de métricas de distancia, que fuese dinámico y se adaptara a los cambios de topología
de forma rápida, que reconociera enrutamiento basado en tipos de servicio efectuando
equilibrio de cargas donde fuese necesario, que reconociera sistemas jerárquicos y que
proporcionara un mínimo de seguridad.
OSPF reconoce tres tipos de conexiones y redes:
1. Las líneas punto a punto entre dos enrutadores.

2. Redes de multiacceso con difusión (Ej. las LANs).
3. Redes de multiacceso sin difusión (Ej. WAN de conmutación de paquetes).
Una red multiacceso es una red que puede tener varios enrutadores, cada uno de
los cuales puede comunicarse directamente con todos los demás. Todas las LAN y WAN
tienen esta propiedad.
Figura 4.37: (a) Sistema autónomo. (b) Representación con grafos de (a).
REDES
En la figura 4.37(a) se muestra un AS que contiene los tres tipos de redes (los
hosts generalmente no desempeñan ningún papel en OSPF).
El OSPF funciona haciendo una abstracción del conjunto de redes, enrutadores y
líneas en un grafo dirigido enel que cada arco se le asigna un costo (distancia, retardo,
etc.). Entonces se calcula la trayectoria más corta con base en los pesos de los arcos. Una
conexión en serie entre dos enrutadores se representa mediante un par de arcos, uno
en cada dirección. Sus pesos pueden ser diferentes. Una red multiacceso se representa
mediante un nodo para la red misma más un nodo para cada enrutador. Los arcos del
nodo de red a los enrutadores tienen un peso de 0 y se omiten del grafo.
En la figura 4.37(b) se muestra la representación gráfica de la red de la figura
4.37(a).
Muchas de las AS de Internet son grandes y nada fáciles de manejar. El OSPF
permite su división en áreas numeradas, donde cada área es una red o un grupo de redes
contiguas. Las áreas no se traslapan, pero no necesitan se exhaustivas, es decir, algunos
enrutadores podrían no pertenecer a ningún área. Un área es una generalización de una
subred. Fuera de un área, su topología y detalles no son visibles.
Cada AS tiene un área backbone, llamada área 0. Todas las áreas se conectan
al backbone, posiblemente mediante túneles, por lo que hay la posibilidad de ir de
cualquier área del AS a cualquier otra a través del backbone. Un túnel se representa en
el grafo como un arco y tiene un costo. Cada enrutador conectado a dos o más áreas es
parte del backbone. Al igual que en otras áreas, la topología del backbone no es visible
fuera del mismo.
Dentro de un área, cada enrutador tiene la misma base de datos de estado de
denlace y ejecuta el mismo algoritmo de trayectoria más corta, que es su principal
tarea. Un enrutador que se conecta a dos áreas debe tener la base de datos de ambas y
ejecutar para cada una de forma independiente el algoritmo de trayectoria más corta.
Para realizar la operación del cálculo de la trayectoria más corta pueden nece-
sitarse tres tipos de rutas: intraárea, interáera e interAS. El algoritmo obiliga a una
configuración en estrella, siendo el backbone el centro y las demás áreas los rallos. Los
paquetes se enrutan del origen al destino “como vienen". No se encapsulan ni se envían
por túnel, a menos que vayan a un área cuya única conexión al backbone sea un túnel.
En la figura 4.38 se muestra la parte de la Internet con AS y áreas.
El OSPF distingue cuatro tipos de enrutadores:
1. Enrutadores internos que están contenidos en una sola área.
2. Enrutadores de borde de área que conectan dos o más áreas.
3. Enrutadores de backbone que están en el backbone.
4. Enrutadores de frontera de AS que hablan con los enrutadores de otras AS.
En la figura 4.38 se ilustran ejemplos de los cuatro tipos de enrutadores.

Figura 4.38: Relación entre los AS, los backbone y las áreas OSPF.
Funcionamiento de OSPF
cuando un enrutador se inicia envía mensajes HELLO en todas sus líneas punto
a punto y los multidifunde en la LAN a los enrutadores restantes. A partir de las
respuestas, cada enrutador aprende quienes son sus vecinos. Todos los enrutadores en
la misma LAN son vecinos.
OSFP trabaja intercambiando información entre enrutadores adyacentes que no es
lo mismo que enrutadores vecinos, un enrutador adyacente es un enrutador designado
dentro de la LAN que se comunica con cualquier otro enrutador vecino dentro de la
LAN.
Los enrutadores vecinos que no son adyacentes no intercambian información entre
sí.
En resumen, utilizando la inundación de mensajes, cada enrutador informa a todos
los demás enrutadores de su área sobre sus vecinos y costos. Esta información permite
a cada enrutador cosntruir el grafo para su área y calcular la ruta más corta. Lo mismo
ocurre a nivel de área de red dorsal y los enrutadores de límite de área se encargan de
difundirlo dentro de su área.
REDES
BGP: PROTOCOLO DE ENRUTAMIENTO DE PASARELA EXTERIOR
Dentro de un AS, el protocolo de enrutamiento recomendado en Internet es OSPF.

Ente los AS se requiere un protocolo diferente porque las se buscan distintas metas que
para enrutamiento de pasarela interior. En enrutamiento de pasarela exterior se usa
un protocolo diferente, el BGP (Border Gateway Protol, protocolo de pasarela
exterior).
Los enrutadores de protocolo de pasarela exterior tienen que preocuparse por los
asuntos políticos. Por ejemplo, un AS corporativo podría querer ser capaz de enviar
paquetes a cualquier instalación Internet y recibir paquetes de cualquier otra, pero
este tráfico puede no quererlo enviar a través de un AS, aún siendo por éste último
donde se encuentra la trayectoria más corta. Los protocolos de pasarela exterior en
general, y en particula BGP, se han diseñado para permitir muchos tipos de políticas
de enrutamiento aplicables al tráfico interAS.
Algunos ejemplos de políticas son los siguientes:
1. Ningún tránsito a través de ciertos sistemas autónomos.
2. Nunca ponga Irak en una ruta que inicie en el Pentágono.
3. No pasar por Estados Unidos para llegar de México a Panamá.
4. Transite por Albania sólo si no hay otra alternativa al destino.
5. El tráfico que empieza o termina en IBM no debe transitar por Microsoft.
Estas políticas se configuran manualmente en cada enrutador BGP y no son parte

del protocolo mismo.
Desde el punto de vista de un enrutador BGP, el mundo consiste en otros enruta-
dores BGP y en las líneas que lo conectan. Se consideran conectados dos enrutadores
BGP si comparten una red común. Dado el interés especial del BGP en el tráfico en
tránsito, las redes se agrupan en tres categorías:
1. Redes de Punta: Tienen una única conexión al grafo BGP.
2. Redes Multiconectadas: Estas podrían usarse para el tráfico a menos que se

nieguen.
3. Redes de Tránsito: Redes que están dispuestas a manejar paquetes de terceros,

posiblemente con algunas restricciones.
BGP utiliza un protocolo parecido al vector de distancia, llamado protocolo de

vector de ruta, donde cada enrutador en lugar de mantener el costo para cada vecino,
guarda el registro de la ruta utilizada. En la figura se muestra un ejemplo donde el
enrutador F , quiere actualizar su camino a D.
Figura 4.39: (a) Grupo de enrutadores BGP. (b) Información enviada a F .
4.5.8. MULTIDIFUSIÓN EN INTERNET

La comunicación normal IP está entre un emisor y un receptor. Sin embargo para
algunas aplicaciones es útil que un proceso pueda enviar simultáneamente a una gran
cantidad de receptores.
IP maneja multitransmisión, usando direcciones clase D. Cada dirección de clase
D identifica un grupo de host. Hay 28 bits disponibles para identificar los grupos, de
modo que pueden existir al mismo tiempo más de 250 millones de grupos.
Se reconocen dos tipos de dirección de grupo: direcciones permanentes y tempo-
rales. Un grupo permanente siempre está ahí y no tiene que configurarse. Cada grupo
permanente tiene una dirección permanente de grupo. Algunos ejemplos de direcciones
permanentes de grupo son:
224.0.0.1: Todos los sistemas en una LAN.
224.0.0.2: Todos los enrutadores en una LAN.
224.0.0.5: Todos los enrutadores OSPF en una LAN.
Los grupos temporales se deben crear antes de que se puedan usar. Un proceso
puede pedir a su host que se una a un grupo específico. También puede pedirle que
deje el grupo. Cuando el último proceso de un host deja un grupo, ese host ya no está
presente en el grupo. Cada host lleva el registro de los grupos a los que pertenecen sus
procesos.
La multidifusión se implementa mediante enrutadores multitransmisión especiales
que pueden o no estar en los mismos puntos que los enrutadores estándar.
En cuanto al enrutamiento multitransmisión se implementa usando árboles de
extensión.
REDES
4.5.9. IPv6
Si bien CIDR y el NAT pueden durar unos pocos años más, sabemos que IP en
su formato actual IPv4 tiene los días contados. Al ver estos problemas se comenzó en
1990 a trabajar en una versión nueva de IP cuyas metas principales fueran:
1. Manejar miles de millones de hosts.
2. Reducir el tamaño de las tablas de enrutamiento.
3. Simplificar el protocolo, para procesar más rápido los paquetes.
4. Proporcionar mayor seguridad.
5. Prestar mayor atención al tipo de servicio, especialmente con datos en tiempo

real.
6. Permitir que el protocolo evolucione.
7. Permitir que el protocolo viejo y el nuevo coexistan por años.
Después de muchas propuestas en 1993 se seleccionaron las mejores y se creó una

versión llamada ahora SIPP (Protocolo Simple de Internet Mejorado) y se le dió la
designación IPv6.
IPv6 cumple los objetivos bastante bien: mantiene las buenas características del
IP, descarta y reduce las malas, y agrega nuevas donde se necesitan. En general, IPv6
no es compatible con IPv4, pero es compatible con todos los demás protocolos Internet,
incluidos TCP, UDP, ICMP, IGMP, OSPF, BGP y DNS, a veces requiriendo pequeñas
modificaiones.
CARACTERÍSTICAS DE IPv6
Por principio, y lo m´sa importante, el IPv6 tiene direcciones más grandes (16
bytes) proporcionando una cantidad prácticamente ilimitada de direcciones de internet.
La cabecera está mejorada. Ahora contiene sólo 7 campos (contra 13 de IPv4). Este
cambio permite a los enrutadores procesar con mayor rapidez los paquetes mejorando
así el rendimiento.
Se ha mejorado el campo de las opciones, en las que si los campos antes eran
obligatorios, ahora son opcionales haciendo más sencillo que los enrutadores hagan caso
omiso de opciones no dirigidas a ellos. Esta característica mejora también el tiempo de
procesamiento de los paquetes.
IPv6 presenta un avance también en el campo de la seguridad ofreciendo verifica-
ciones de autenticidad y confidencialidad.
Presta más atención al tipo de servicio, dedicando 8 bits en la cabecera para
afrontar este asunto.
EL ENCABEZADO DE IPv6
Figura 4.40: Cabecera fija del IPv6 (obligatoria).
Descripción de los campos de cabecera de IPv6:
Versión: siempre es 6 para IPv6 y 4 para IPv4.
Clase de tráfico: se usa para distinguir entre los paquetes con requisitos dife-
rentes de entrega en tiempo real.
Etiqueta de flujo: aún es experimental, pero se usará para permitir a un ori-

gen y a un destino establecer una pseudoconexión con propiedades y requisitos
particulares, por ejemplo de retardo, ancho de banda, etc.
Longitud de carga útil: indica cuántos bytes siguen al encabezado de 40 bytes,

ya no hay opciones como en IPv4 pero se agregan los encabezados de extensión.
Encabezado siguiente: indica cuál de los seis encabezados de extensión de

haberlos sigue a este encabezado IP.
Límite de saltos: se usa para evitar que los paquetes vivan eternamente, igual
a TTL de IPv4.
Dirección de origen y destino de 16 bytes.
Se ha desarrollado una nueva notación para describir direcciones de 16 bytes: se

escriben como ocho grupos de cuatro dígitos hexadecimales, separados los grupos por
dos puntos, como sigue:
REDES
8000:0000:0000:0000:0123:4567:89AB:CDEF
Optimizaciones: Ya que muchas direcciones tendrán muchos ceros en ellas, se

pueden optimizar, primero quitando en un grupo los ceros de la izquierda y reemplazar
uno o más grupos de 16 ceros por ::, por lo que quedaría:
8000::123:4567:89AB:CDEF
Hay disponibles 2128 direcciones disponibles o lo que es lo mismo 3 × 1038 .
DIFERENCIAS CON IPv4
Se retiró el campo IHL, porque el encabezado tiene una longitud fija.
El campo de Protocolo se retiró porque el campo Encabezado siguiente, indica

lo que sigue al último encabezado IP (un segmento UDP o TCP).
Se retiraron todos los campos que tenían que ver con la fragmentación. Ahora es
el host y no el enrutador quien debe fragmentar si es necesario los paquetes para
que los pueda tratar el enrutador.
La suma de verificación desaparece, porque su cálculo reduce en gran medida

el desempeño, además ya este se realiza en la capa de enlace de datos y la de
transporte.
Por supuesto, se aumentó el tamaño en byte de la dirección de origen y destino.
ENCABEZADOS DE EXTENSIÓN
Como ya no es necesario el campo de Opciones de IPv4, se introdujo el concepto

de encabezado de extensión (opcional). Estos encabezados pueden usarse para pro-
porcionar información extra, pero codificada de manera eficiente. Hay seis tipos de
encabezado:
Encabezado de extensión Descripción

Opciones salto por salto Información diversa para enrutadores
Opciones de destino Información adicional para el destino
Enrutamiento Ruta total o parcial a seguir
Fragmentación Manejo de fragmentos de datagramas
Autenticación Verificación de la entidad del emisor
Carga útil de seguridad encriptada Información sobre el contenido encriptado
Figura 4.41: Encabezados de extensión IPv6.

REDES
LA CAPA DE TRANSPORTE
La capa de transporte no es sólo otra capa. Es el corazón de la jerarquía completa

de protocolos. La tarea de esta capa es proporcionar un transporte de datos confiable
y económico de la máquina origen a la máquina de destino, independientemente de la
red o redes físicas en uso. Sin la capa de transporte, el concepto total de los protocolos
en capas tendría poco sentido.
5.1. EL SERVICIO DE TRANSPORTE
5.1.1. SERVICIOS PROPORCIONADOS A LAS CAPAS SU-

PERIORES
La meta fundamental de la capa de transporte es proporcionar un servicio eficiente,

confiable y económico a sus usuarios, que normalmente son procesos de la capa de
aplicación. Para lograr este objetivo la capa de transporte hace uso de los servicios
proporcionados por la capa de red.
El hardware o software de la capa de transporte que se encarga del trabajo se llama
entidad de transporte y puede estar en el núcleo (kernel ) del sistema operativo, en
un proceso de usuario independiente, en un paquete de biblioteca que forma parte de
las aplicaciones de red o en la tarjeta de interfaz de red. La relación (lógica) entre las
capas de red, transporte y aplicación se ilustra en la siguiente figura:
153
154 5.1. EL SERVICIO DE TRANSPORTE
Figura 5.1: Capas de red, transporte y aplicación.
Así como hay dos tipos de servicio de red, orientado a conexiones y sin conexiones,
también hay dos tipos de servicio de transporte. El servicio orientado a conexiones es
parecido al servicio de red orientado a conexiones. El direccionamiento y control de
flujo también son semejantes. Además, el servicio de transporte sin conexiones es muy
parecido al servicio de red sin conexiones.
La pregunta obvia es entonces: si el servicio de la capa de transporte es tan parecido
al de la capa de red, ¿por qué hay dos capas diferentes? ¿no es suficiente con una capa?.
La respuesta es la siguiente: los usuarios no tienen control ninguno sobre la red.
¿Qué ocurriría si algún router se viene abajo?. ¿Qué ocurriría si la capa de red pierde
paquetes con frecuencia?.
Esta capa está orientada a la mejora de la calidad de servicio de la capa de red
y el aumento de la confiabilidad de la misma. La capa de transporte puede detectar
y compensar paquetes perdidos y datos alterados. Es más, las primitivas del servicio
de transporte pueden diseñarse de modo que sean independientes de las primitivas del
servicio de red, que pueden variar considerablemente entre redes.
Gracias a la capa de transporte es posible escribir aplicaciones usando un conjunto
estándar de primitivas y que éstos programas funcionen en una amplia variedad de
redes. Esta capa cumple la función clave de aislar las capas superiores de la tecnología,
el diseño y las imperfecciones de la subred.
Por esta razón mucha gente distingue entre las capas 1 a 4 por una parte como
proveedor de servicio de transporte y el resto de capas superiores como usuario
del servicio de transporte. De acuerdo a esta distinción la capa de transporte
constituye el límite principal entre el proveedor y el usuario del servicio confiable de
transmisión de datos situándose en una posición clave.
REDES
5.1.2. PRIMITIVAS DE SERVICIO DE TRANSPORTE

Las primitivas del servicio de transporte permiten a los usuarios de transporte (por
ejemplo programas de aplicación) el acceso al servicio de transporte. Cada servicio tiene
sus propias primitivas de acceso.
El servicio de transporte es parecido al servicio de red, pero hay algunas diferencias
importantes. La principal es que la intención del servicio de red es modelar el servicio
ofrecido por las redes reales, con todo y verrugas, pero las redes pueden perder paquetes,
por eso el servicio no es confiable.
El servicio de transporte orientado a conexiones, en cambio, sí es confiable. Ese es
el principal motivo de la capa de transporte: proporcionar un servicio confiable para
redes no confiables.
Para tener una idea de lo que podría ser el servicio de transporte, considere las
cinco primitivas listadas en la siguiente figura:
Primitiva Paquete enviado Significado

LISTEN (ninguno) Se bloquea hasta que algún proceso in-
tenta la conexión
CONNECT CONNECTION REQ. Intenta activamente establecer una co-
nexión
SEND DATA Envía información
RECEIVE (NINGUNO) Se bloquea hasta que llega un paquete
DATA
DISCONNECT DISCONNECTION REQ. Este lado quiere liberar la conexión
Figura 5.2: Primitivas de un servicio de transporte sencillo.
Esta interfaz es sencilla, pero da la esencia de lo que debe hacer una inerfaz de
transporte orientada a conexiones: permite que los programas de aplicación establezcan,
usen y liberen conexiones, lo que basta para muchas aplicaciones.
Para ver cómo podrían usarse estas primitivas, considere una aplicación servidor
y cierta cantidad de clientes remotos. Para comenzar, el servidor ejecuta una primitiva
LISTEN(escuchar), normalmente llamando a un procedimiento biblioteca que hace una
llamada de sistema para bloquear el servidor hasta la aparición del cliente. Cuando un
cliente quiere hablar con el servidor, ejecuta CONNECT (conectarse). La entidad de
transporte ejecuta esta primitiva bloqueando al que llama y enviando un paquete al
servidor. Encapsulado en la carga útil de este paquete hay un mensaje de capa de
transporte para la entidad de transporte del servidor.
Es pertinente aquí una nota rápida sobre terminología. Usaremos la sigla TPDU
(Transport Protocol Data Unit, unidad de datos del protocolo de transporte),
para referirnos a los mensajes enviados de una entidad de transporte a otra. Por tanto,
las TPDU (intercambiadas por la capa de transporte) están contenidas en paquetes
(intercambiadas por la capa de red) que, a su vez están contenidos en marcos (inter-
cambiados por la capa de enlace de datos). El anidamiento se muestra en la siguiente
figura:
Figura 5.3: Anidamiento de las TPDU, los paquetes y los marcos.
Regresando al ejemplo anterior, la llamada CONNECT del cliente causa el envío

de una TPDU CONNECTION REQUEST (solicitud de conexión) al servidor. Al lle-
gar ésta, la entidad de transporte la revisa para comprobar que el servidor está bloquea-
do en LISTEN. Entonces desbloquea el servidor y envía una TPDU CONNECTION
ACCEPTED (conexión aceptada) de regreso al cliente. Al llegar esta TPDU, el cliente
se desbloquea y establece la conexión.
Ya se pueden intercambiar datos usando las primitivas SEND (enviar) y RECEIVE
(recibir).
Cuando el envío de datos haya finalizado y ya no se necesita la conexión, es nece-
sario liberarla. Para ello se emite la primitiva DISCONNECT (desconectar).
SOCKETS DE BERKELEY
Inspreccionemos brevemente otro grupo de primitivas de transporte, las primitivas

de socket usadas en el UNIX de Berkeley para el TCP. Estas primitivas se listan a
continuación:
Primitiva Significado
SOCKET Crea un nuevo punto terminal de comunicación
BIND Adjunta una dirección local a un socket
LISTEN Anuncia la disposición a aceptar conexiones
ACCEPT Bloquea el invocador hasta la llegada de un intento de conexión
CONNECT Intenta establecer activamente una conexión
SEND, WRITE Envía datos a través de la conexión
RECEIVE, READ Recibe datos de la conexión
CLOSE Libera la conexión
Figura 5.4: Primitvas de socket para TCP.
REDES
Ejecución de la parte servidor:
Las primeras cuatro primitivas de la lista son ejecutadas en ese orden por los
servidores. La primitiva SOCKET crea un nuevo punto final y le asigna espacio de
tablas dentro de la entidad de transporte. Los parámetros de la llamada especifican
el formato de direccionamiento a usar, el tipo de servicio deseado y el protocolo. Una
llamada con éxito a SOCKET devuelve un descriptor de archivo ordinario para usarse
con las siguientes llamadas, de la misma manera que lo hace una llamada OPEN.
Los sockets recién creados no tienen direcciones. Éstas se asignan usando la pri-
mitiva BIND (ligar). Una vez que un servidor ha ligado una dirección a un socket,
los clientes remotos pueden conectarse a él. La razón para no hacer que la llamada
SOCKET cree directamente una dirección es que a algunos procesos les importan sus
direcciones mientras que a otros no.
A continuación vienen la llamada LISTEN (escuchar), que asigna espacio para
poner en cola las llamadas entrantes. Al contrario que en ejemplo anterior, esta llamada
no es bloqueadora.
Para bloquearse en espera de una conexión entrante el servidor ejecuta una pri-
mitiva ACCEPT (aceptar). Cuando llega una TPDU solicitando una conexión, la
entidad de transporte crea un socket nuevo con las mismas propiedades que el original
y devuelve un descriptor de archivo para él.
Ejecución de la parte cliente:
Aquí también deben crearse primero un socket usando la primitiva SOCKET, pero
no requiere BIND puesto que la dirección usada no le importa al servidor. La primitiva
CONNECT (conectar) bloquea al invocador y comienza activamente el proceso de
conexión. Al completarse el proceso cliente se desbloquea y establece la conexión.
Una vez establecida la conexión, ambos lados pueden usar ahora SEND y RECEIVE
para transmitir y recibir datos a través de la conexión dúplex integral.
La liberación de las conexiones a los sockets es simétrica. Cuando ambos lados han
ejecutado una primitiva CLOSE, se libera la conexión.
Ejemplo de cliente:
/* This page contains the client program. The following one contains the
* server program. Once the server has been compiled and started, clients
* anywhere on the Internet can send commands (file names) to the server.
* The server responds by opening and returning the entire file requested.
*/
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#define SERVER_PORT 12345 /* arbitrary, but client and server must agree */
#define BUF_SIZE 4096 /* block transfer size */
int main(int argc, char **argv)

{
int c, s, bytes;
char buf[BUF_SIZE]; /* buffer for incoming file */
struct hostent *h; /* info about server */
struct sockaddr_in channel; /* holds IP address */
if (argc != 3) fatal("Usage: client server-name file-name");

h = gethostbyname(argv[1]); /* look up host’s IP address */
if (!h) fatal("gethostbyname failed");
s = socket(PF_INET, SOCK_STREAM, IPPROTO_TCP);

if (s < 0) fatal("socket");
memset(&channel, 0, sizeof(channel));
channel.sin_family= AF_INET;
memcpy(&channel.sin_addr.s_addr, h->h_addr, h->h_length);
channel.sin_port= htons(SERVER_PORT);
c = connect(s, (struct sockaddr *) &channel, sizeof(channel));
if (c < 0) fatal("connect failed");
/* Connection is now established. Send file name including 0 byte at end. */

write(s, argv[2], strlen(argv[2])+1);
/* Go get the file and write it to standard output. */

while (1) {
bytes = read(s, buf, BUF_SIZE); /* read from socket */
if (bytes <= 0) exit(0); /* check for end of file */
write(1, buf, bytes); /* write to standard output */
}
}
fatal(char *string)
{
printf("%s\n", string);
exit(1);
}
REDES
Ejemplo de servidor:
#include <sys/types.h>
#include <sys/fcntl.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>
#define SERVER_PORT 12345 /* arbitrary, but client and server must agree */
#define BUF_SIZE 4096 /* block transfer size */
#define QUEUE_SIZE 10
int main(int argc, char *argv[])

{
int s, b, l, fd, sa, bytes, on = 1;
char buf[BUF_SIZE]; /* buffer for outgoing file */
struct sockaddr_in channel; /* hold’s IP address */
/* Build address structure to bind to socket. */

memset(&channel, 0, sizeof(channel)); /* zero channel */
channel.sin_family = AF_INET;
channel.sin_addr.s_addr = htonl(INADDR_ANY);
channel.sin_port = htons(SERVER_PORT);
/* Passive open. Wait for connection. */

s = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP); /* create socket */
if (s < 0) fatal("socket failed");
setsockopt(s, SOL_SOCKET, SO_REUSEADDR, (char *) &on, sizeof(on));
b = bind(s, (struct sockaddr *) &channel, sizeof(channel));

if (b < 0) fatal("bind failed");
l = listen(s, QUEUE_SIZE); /* specify queue size */

if (l < 0) fatal("listen failed");
/* Socket is now set up and bound. Wait for connection and process it. */
while (1) {
sa = accept(s, 0, 0); /* block for connection request */
if (sa < 0) fatal("accept failed");
read(sa, buf, BUF_SIZE); /* read file name from socket */
/* Get and return the file. */

fd = open(buf, O_RDONLY); /* open the file to be sent back */
if (fd < 0) fatal("open failed");
160 5.2. ELEMENTOS DEL PROTOCOLO DE TRANSPORTE
while (1) {
bytes = read(fd, buf, BUF_SIZE); /* read from file */
if (bytes <= 0) break; /* check for end of file */
write(sa, buf, bytes); /* write bytes to socket */
}
close(fd); /* close file */
close(sa); /* close connection */
}
}
fatal(char *string)
{
printf("%s", string);
exit(1);
}
5.2. ELEMENTOS DEL PROTOCOLO DE TRANS-

PORTE
El servicio de transporte se implementa mediante un protocolo de transporte
entre las dos entidades de transporte. En cierto modo, los protocolos de transporte se
asemejan a los protocolos de enlace de datos puesto que se encargan del control de
errores, la secuencia y el control de flujo, entre otros asuntos.
Sin embargo existen diferencias significativas entre los dos debidas a los entornos
en que ambos operan. En la capa de enlace de datos, dos enrutadores se comunican
directamente mediante un canal físico, mientras que, en la capa de transporte, el canal
físico es reemplazado por la subred completa.
Figura 5.5: (a) Entorno de la capa de enlace de datos. (b) Entorno de la capa de
transporte.
En la capa de enlace de datos no es necesario que un enrutador especifique el

enrutador con el que quiere hablar; cada línea de salida especifica de manera única
un enrutador en particular. En la capa de transporte se requiere el direccionamiento
explícito de los destinos.
REDES
5.2.1. DIRECCIONAMIENTO
Cuando un proceso (ej. un usuario) desea establecer una conexión con un proceso
de aplicación remoto debe especificar a cuál debe conectarse. El método que se emplea
es definir direcciones de transporte en la que los procesos pueden estar a la escucha de
solicitudes de conexión. En Internet estos puntos terminales se llaman puertos o TSAP
(Transport Service Access Point, punto de acceso al servicio de transporte). Los
puntos terminales análogos de la capa de red se llaman entonces NSAP (Network
Service Access Point, puntos de acceso al servicio de red). Las direcciones IP son
ejemplos de NSAP.
En la figura siguiente se muestra la relación entre el NSAP, el TSAP, la conexión
de red y la conexión de transporte orientada a conexiones1 :
Figura 5.6: Los TSAP, NSAP y conexiones.
Una conexión de transporte va de TSAP a TSAP mientras que una conexión de

red sólo cubre una parte del camino, de NSAP a NSAP.
Los TSAP o puertos pueden dedicarse a numerosos tipos de servicios. Existen una
serie de servicios que se han estandarizado y se le han reservado una serie de puertos
estándar. Estos puertos los 1024 puertos primeros. El resto de puertos (65.535) se han
dejado para uso propio siempre y cuando un proceso no lo esté utilizando.
1
Una entidad de transporte normalmente reconoce varios TSAP. En algunas redes también existen
múltiples NSAP, pero en otras cada máquina sólo tienen un NSAP (por ejemplo una dirección IP.)
5.2.2. ESTABLECIMIENTO DE LA CONEXIÓN

El establecimiento de una conexión suena fácil, pero en realidad es bastante com-
plicado. A primera vista, parecería suficiente con que una entidad de transporte en-
viara una TPDU CONNECTION REQUEST al destino y esperará una respuesta
CONNECTION ACCEPTED, pero esto no es así. El problema ocurre cuando la red
puede perder, almacenar o duplicar paquetes.
Imaginemos una red congestionada, en la que los reconocimientos casi nunca llegan
a tiempo; cada paquete terminará de temporizar y se retransmitirá dos o tres veces.
Otra situación sería el encaminamiento de datagramas por distintas rutas y alguno de
ellos se queda atorado en un congestionamiento; en este caso el paquete puede tardar
mucho en llegar.
Pero el peor problema reside en los paquetes duplicados. Generalmente debido a
retrasos.
Para resolver este problema se han propuesto varias técnicas, pero todas ellas poco
satisfactorias hasta la proposición, en 1975, por Tomlinson de un método que resuelve
el problema aunque presenta algunas peculiaridades propias. El método fue refinado
por Sunshine y Dalal en 1978 y en la actualizad se usan ampliamente variantes suyas.
Breve planteamiento del problema:
Para llevar a cabo este método es necesario equipar a cada máquina de un reloj de
hora del día, reloj que no tiene por qué estar sincronizado entre las distintas máquinas
y que opera de forma independiente del host (aun si éste cae).
La idea básica es asegurar que nuncan estén pendientes dos TPDU de número
idéntico al mismo tiempo. Cuando se establece la conexión, los k bits de orden menor
del reloj de usan como número inicial de secuencia. Por tanto, y a diferencia de los
protocolos de la capa de enlace, cada conexión comienza a numerar sus TPDU con un
número de secuencia diferente.
Una vez que ambas entidades de transporte han acordado el número de secuencia
inicial, puede usarse cualquier protocolo de ventana corrediza para el control de flujo
de datos.
Ocurre un problema cuando cae un host. Al regresar nuevamente, sus entidades
de transporte no saben dónde estaban en el espacio de secuencias. Una solución es
requerir que las entidades de transporte estén inactivas durante T segundos tras una
recuperación para permitir que todas las TPDU viejas mueran.
Durante este tiempo, y para evitar problemas, debemos evitar la asignación de
números de secuencia nuevos (es decir, asignados a TPDU nuevas). Antes de enviar
cualquier TPDU por alguna conexión, la entidad de transporte debe leer el reloj y
comprobar que puede realizar en envío.
El protocolo puede meterse en problemas puesto que si se envían datos con de-
masiada rapidez la curva de número de secuencia real contra tiempo puede subir con
mayor rapidez que la curva de número de secuencia inicial contra tiempo. Esto significa
REDES
que la tasa de datos máxima en cualquier conexión es de una TPDU por pulso de reloj,
y también significa que la entidad de transporte debe esperar hasta que el reloj pulse
antes de abrir una nueva conexión tras reinicio por caída no sea que se use dos veces
el mismo número de secuencia.
No es éste el único problema ya si la tasa de datos es menor que la tasa de reloj,
tarde o temprano, se producirán erroes.
5.2.3. Protocolo de acuerdo de tres vías
Figura 5.7: Tres escenarios para establecer una conexión usando un protocolo de acuer-
do de tres vías. (a) Operación normal. (b) SOLICITUD DE CONEXIÓN duplicada
vieja que aparece de la nada. (c) SOLICITUD DE CONEXIÓN duplicada y ACK
duplicada.
Para resolver este problema, Tomlimson desarrolló el protocolo de acuerdo de 3

vías. Este protocolo no requiere que ambos lados comiencen a transmitir con elmismo
número de secuencia, por lo que puede usarse con otros métodos de sincronización
distintos del método de reloj global.
El procedimiento normal de establecimiento se muestra en la figura 5.7(a). El host
1 escoge un número de secuencia, x, y envía al host 2 una TPDU CONNECTION
REQUEST que lo contiene. El host 2 responde con una TPDU CONNECTION
ACCEPTED reconociendo x y anunciando su propio número de secuencia inicial, y.
Por último, el host 1 reconoce la selección de un número de secuencia inicial del host
2 en la primera TPDU de datos que envía.
En el caso de que se presente una TPDU de control duplicada con retraso es
rechazada. Lo mismo ocurre si llegan TPDU CONNECTION REQUEST y ACK.
El protocolo fallaría si llegan TPDU combinadas y en orden pudiendo provocar
accidentalmente establecimientos de conexiones cuando nadie lo requiere.
5.2.4. LIBERACIÓN DE UNA CONEXIÓN

Existen distintos estilos de terminación de la conexión: liberación asimétrica y
liberación simétrica.
La liberación asimétrica es la manera en que funciona el teléfono. La liberación
simétrica trata la conexión como dos conexiones unidireccionales distintas, y requiere
que cada una se libere por separado.
La liberación asimétrica es muy abrupta y podrían perderse datos haciendo uso de
ella. Se requiere un protocolo más refinado para llebar a cabo esta tarea. Una solución
podría hacer uso de la simétrica, pero sólo es funcional cuando se sabe la cantidad de
datos por enviar y cuando se han enviado.
Existe un famoso problema que tiene que ver con este asunto; es el problema de
los dos ejércitos. Supongamos la siguiente situación:
Figura 5.8: Problema de los dos ejércitos.
REDES
Un ejército blanco está acampado en un valle. En los dos cerros que rodean al
valle hay ejércitos azules. El ejército blanco es más grande que cualquiera de los ejérci-
tos azules por separado, pero juntos estos son más grandes que el ejército blanco. Si
cualquiera de los dos ejércitos azules ataca por su cuenta, será derrotado, pero si los
dos atacan simultáneamente obtendrán la victoria.
Los ejércitos azules quieren sincronizar sus ataques. Sin embargo, su único medio
de comunicación es el envío de mensajeros a pie a través del valle, donde podrían se
capturados, perdiéndose el mensaje. La pregunta es: ¿Existe un protocolo que permita
que los ejércitos azules ganen?
Un primer intento sería un acuerdo de dos vías () que no es operativo: el ejército
1 propone una fecha, envía un mensajero al ejército 2, y éste le envía su confirmación,
pero el ejército 2 no sabe con certeza si ha llegado su respuesta. Si no llega, el ejército
1 no atacará, pero el 2 sí.
Otra propuesta sería un llegar a un acuerdo de tres vías (three-way handshake),
pero estaríamos en la situación inversa, atacaría el ejército 1 y el ejército 2 puede que
no ataque. Lo mismo ocurre con acuerdos de más vías. En este tipo de acuerdos siempre
hay incertidumbre porque nunca se sabe qué ocurre con el mensaje final.
En la práctica, generalmente estamos más dispuestos a correr riesgos al liberar
conexiones que al atacar ejércitos blancos, por lo que la situación no es tan desesper-
ada. Se suele usar un protocolo de acuerdo de tres vías, que, aunque no es infalible,
generalmente es adecuado.
A continuación se muestran algunos ejemplos de ejecución y fallo de este protocolo:
Figura 5.9: (a) Caso normal del acuerdo de tres vías. (b) Se pierde el último ACK, en
este caso el temporizador salva la situación. Cuando este expira la conexión se libera
de todos modos.
Figura 5.10: (c) Pérdida de segunda DR, el usuario que inicia la desconexión no recibirá
la respuesta esperada, su temporizador expira y el proceso comeinza de nuevo. (d) Caso
crítico: todos los intentos repetidos de retransmitir fallan. Tras N reintentos, el emisor
se da por vencido y libera la conexión, lo mismo ocurre en el receptor.
5.2.5. CONTROL DE FLUJO Y ALMACENAMIENTO EN

BÚFER
Habiendo visto cómo conectar y desconectar, veamos la manera en que se manejan

las conexiones mientras están en uso.
El método propuesto es similar al que utiliza la capa de enlace de datos, y es el
de ventana corrediza para evitar que un emisor rápido sature a uno lento, la diferencia
es el entorno, por lo general un enrutador tiene pocas líneas y un host puede tener
muchas conexiones.
Si el servicio de red no es confiable, el emisor debe almacenar en búfer todas
las TPDU enviadas a fin de poder retransmitirlas si se pierden, el receptor podría
mantener un sólo un grupo de búferes compartido para todas las conexiones, si no hay
disponibilidad de búfer se pueden descartar TPDU.
Aún si el receptor está de acuerdo en utilizar búferes, todavía queda la cuestión
del tamaño.
REDES
Figura 5.11: (a) Búferes encadenados de tamaño fijo. (b) Búferes encadenados de
tamaño variable. (c) Un gran búfer circular por conexión.
Si la mayoría de las TPDU tienen aproximadamente el mismo tamaño, es natural

organizar los búferes como una reserva de búferes de tamaño idéntico, con una TPDU
por búfer.
Sin embargo si hay una variación grande del tamaño de las TPDU, de unos cuan-
tos caracteres almacenados en una terminal hasta miles de caracteres provenientes de
transferencias de archivos, el fondo de búferes de tamaño fijo presenta problemas. Se
recurre en estos casos al uso de búferes de tamaño variable, que hace un mejor uso de
la memoria, pero al costo de una gestión de búferes más complicada.
Una tercera posibilidad es dedicar un sólo búfer circula grande por conexión. Este
sistema también hace un buen uso de la memoria cuando todas las conexiones tienen
una carga alta, pero es deficiente si algunas conexiones son de poca carga.
A medida que se abren y cierran conexiones y cambia el patrón de tráfico, el emisor
y el receptor necesitan ajustar dinámicamente sus asignaciones de búfer.
En consecuencia el protocolo de transporte debe permitir que el host emisor solicite
espacio de búfer en el otro extremo. Como alternativa, el receptor sabiendo su capacidad
de manejo de búferes podría indicar al emisor “te he reservado X búferes".
Una manera razonablemente general de manejar la asignación dinámica de búferes
es desacoplarlos de las confirmaciones de recepción, en contraste con los protocolos de
ventana corrediza de capa 2.
Esto implica una ventana de tamaño variable. Inicialmente el emisor solicita una
cierta cantidad de búferes. El receptor otorga tantos búferes como puede. Cada vez que
el emisor envía una TPDU debe disminuir su asignación, deteniéndose al llegar cero.
168 5.3. UN PROTOCOLO DE TRANSPORTE SENCILLO
Figura 5.12: Asignación dinámica de ventanas con No secuencia 4 bits. Las flechas
muestran la dirección de la transmisión. Los puntos suspensivos (. . . ) indican una
TPDU perdida.
5.3. UN PROTOCOLO DE TRANSPORTE SENCI-

LLO
Para hacer más concretas las ideas estudiadas hasta ahora, en esta sección exam-
inaremos detalladamente una capa de transporte de ejemplo. Las primitivas de servicio
abstractas que se usarán son las primitivas orientadas a conexiones de la figura 5.2.
5.3.1. LA ENTIDAD DE TRANSPORTE DE EJEMPLO

Antes de ver el código de la entidad de transporte de ejemplo, una aclaración sobre
el mismo: se trata de un ejemplo muy sencillo, orientado a la comprensión del mismo
en el que se han omitido numerosos detalles técnicos (como comprobación extensa de
errores) necesarios para un sistema de producción.
La capa de transporte hace uso de las primitivas de servicio de red para enviar
y recibir las TPDU. En este ejemplo se ha optado por usar un servicio de red confi-
able orientado a conexiones. De esta manera, podremos enfocarnos a los asuntos de
transporte que no ocurren en las capas inferiores.
Por sencillez, este ejemplo se ha programado como si fuera un paquete de bibliote-
REDES
ca. El código de la entidad de transporte se muestra a continuación. Cada conexión

está siempre en uno de los siguientes siete estados:
1. IDLE: No se ha establecido todavía una conexión.
2. WAITING: Se ha ejecutado un CONNECT, y enviado CALL REQUEST.
3. QUEUED: Ha llegado un CALL REQUEST; aún no hay LISTEN.
4. ESTABLISHED: Se ha establecido la conexión.
5. SENDING: The user is waiting for permission to send a packet.
6. RECEIVING: Se ha hecho un RECEIVE.
7. DISCONNECTING: Se ha hecho localmente un DISCONNECT.
Código de la entidad de transporte de ejemplo:
#define MAX_CONN 32 /* max number of simultaneous connections */

#define MAX_MSG_SIZE 8192 /* largest message in bytes */
#define MAX_PKT_SIZE 512 /* largest packet in bytes */
#define TIMEOUT 20
#define CRED 1
#define OK 0
#define ERR_FULL -1
#define ERR_REJECT -2
#define ERR_CLOSED -3
#define LOW_ERR -3
typedef int transport_address;

typedef enum {CALL_REQ,CALL_ACC,CLEAR_REQ,CLEAR_CONF,DATA_PKT,CREDIT} pkt_type;
typedef enum {IDLE,WAITING,QUEUED,ESTABLISHED,SENDING,RECEIVING,DISCONN} cstate;
/* Global variables. */
transport_address listen_address; /* local address being listened to */
int listen_conn; /* connection identifier for listen */
unsigned char data[MAX_PKT_SIZE]; /* scratch area for packet data */
struct conn {
transport_address local_address, remote_address;
cstate state; /* state of this connection */
unsigned char *user_buf_addr; /* pointer to receive buffer */
int byte_count; /* send/receive count */
int clr_req_received; /* set when CLEAR_REQ packet received */
int timer; /* used to time out CALL_REQ packets */
int credits; /* number of messages that may be sent */
} conn[MAX_CONN + 1]; /* slot 0 is not used */
void sleep(void); /* prototypes */

void wakeup(void);
void to_net(int cid, int q, int m, pkt_type pt, unsigned char *p, int bytes);
void from_net(int *cid, int *q, int *m, pkt_type *pt, unsigned char *p, int *bytes);
int listen(transport_address t)
{ /* User wants to listen for a connection. See if CALL_REQ has already arrived. */
int i, found = 0;
for (i = 1; i <= MAX_CONN; i++) /* search the table for CALL_REQ */

if (conn[i].state == QUEUED && conn[i].local_address == t) {
found = i;
break;
}
if (found == 0) {
/* No CALL_REQ is waiting. Go to sleep until arrival or timeout. */
listen_address = t; sleep(); i = listen_conn ;
}
conn[i].state = ESTABLISHED; /* connection is ESTABLISHED */
conn[i].timer = 0; /* timer is not used */
listen_conn = 0; /* 0 is assumed to be an invalid address */
to_net(i, 0, 0, CALL_ACC, data, 0); /* tell net to accept connection */
return(i); /* return connection identifier */
}
int connect(transport_address l, transport_address r)

{ /* User wants to connect to a remote process; send CALL_REQ packet. */
int i;
struct conn *cptr;
data[0] = r; data[1] = l; /* CALL_REQ packet needs these */

i = MAX_CONN; /* search table backward */
while (conn[i].state != IDLE && i > 1) i = i - 1;
if (conn[i].state == IDLE) {
/* Make a table entry that CALL_REQ has been sent. */
cptr = &conn[i];
cptr->local_address = l; cptr->remote_address = r;
cptr->state = WAITING; cptr->clr_req_received = 0;
cptr->credits = 0; cptr->timer = 0;
to_net(i, 0, 0, CALL_REQ, data, 2);
sleep(); /* wait for CALL_ACC or CLEAR_REQ */
if (cptr->state == ESTABLISHED) return(i);
if (cptr->clr_req_received) {
REDES
/* Other side refused call. */

cptr->state = IDLE; /* back to IDLE state */
to_net(i, 0, 0, CLEAR_CONF, data, 0);
return(ERR_REJECT);
}
} else return(ERR_FULL); /* reject CONNECT: no table space */
}
int send(int cid, unsigned char bufptr[], int bytes)

{ /* User wants to send a message. */
int i, count, m;
struct conn *cptr = &conn[cid];
/* Enter SENDING state. */

cptr->state = SENDING;
cptr->byte_count = 0; /* # bytes sent so far this message */
if (cptr->clr_req_received == 0 && cptr->credits == 0) sleep();
if (cptr->clr_req_received == 0) {
/* Credit available; split message into packets if need be. */
do {
if (bytes - cptr->byte_count > MAX_PKT_SIZE) {
/* multipacket message */
count = MAX_PKT_SIZE; m = 1; /* more packets later */
} else { /* single packet message */
count = bytes - cptr->byte_count; m = 0;
/* last pkt of this message */
}
for (i = 0; i < count; i++) data[i] = bufptr[cptr->byte_count + i];
to_net(cid, 0, m, DATA_PKT, data, count); /* send 1 packet */
cptr->byte_count = cptr->byte_count + count;
/* increment bytes sent so far */
} while (cptr->byte_count < bytes); /* loop until whole message sent */
cptr->credits--; /* each message uses up one credit */
cptr->state = ESTABLISHED;
return(OK);
} else {
return(ERR_CLOSED); /* send failed: peer wants to disconnect */
}
}
int receive(int cid, unsigned char bufptr[], int *bytes)

{ /* User is prepared to receive a message. */
if (cptr->clr_req_received == 0) {
/* Connection still established; try to receive. */

cptr->state = RECEIVING;
cptr->user_buf_addr = bufptr;
cptr->byte_count = 0;
data[0] = CRED;
data[1] = 1;
to_net(cid, 1, 0, CREDIT, data, 2); /* send credit */
sleep(); /* block awaiting data */
*bytes = cptr->byte_count;
}
return(cptr->clr_req_received ? ERR_CLOSED : OK);
}
int disconnect(int cid)

{ /* User wants to release a connection. */
if (cptr->clr_req_received) { /* other side initiated termination */

cptr->state = IDLE; /* connection is now released */
to_net(cid, 0, 0, CLEAR_CONF, data, 0);
} else { /* we initiated termination */
cptr->state = DISCONN; /* not released until other side agrees */
to_net(cid, 0, 0, CLEAR_REQ, data, 0);
}
return(OK);
}
void packet_arrival(void)
{ /* A packet has arrived, get and process it. */
int cid; /* connection on which packet arrived */
int count, i, q, m;
pkt_type ptype; /* CALL_REQ, CALL_ACC, CLEAR_REQ,
CLEAR_CONF, DATA_PKT, CREDIT */
unsigned char data[MAX_PKT_SIZE]; /* data portion of the incoming packet */
struct conn *cptr;
from_net(&cid, &q, &m, &ptype, data, &count); /* go get it */

cptr = &conn[cid];
switch (ptype) {
case CALL_REQ: /* remote user wants to establish connection */
cptr->local_address = data[0]; cptr->remote_address = data[1];
if (cptr->local_address == listen_address) {
listen_conn = cid; cptr->state = ESTABLISHED; wakeup();
} else {
REDES
cptr->state = QUEUED; cptr->timer = TIMEOUT;

}
cptr->clr_req_received = 0; cptr->credits = 0;
break;
case CALL_ACC: /* remote user has accepted our CALL_REQ */

wakeup();
break;
case CLEAR_REQ: /* remote user wants to disconnect or reject call */

cptr->clr_req_received = 1;
if (cptr->state == DISCONN) cptr->state = IDLE; /* clear collision */
if (cptr->state == WAITING || cptr->state == RECEIVING ||
cptr->state == SENDING) wakeup();
break;
case CLEAR_CONF: /* remote user agrees to disconnect */

cptr->state = IDLE;
break;
case CREDIT: /* remote user is waiting for data */

cptr->credits += data[1];
if (cptr->state == SENDING) wakeup();
break;
case DATA_PKT: /* remote user has sent data */

for (i = 0; i < count; i++)
cptr->user_buf_addr[cptr->byte_count + i] = data[i];
cptr->byte_count += count;
if (m == 0 ) wakeup();
}
}
void clock(void)
{ /* The clock has ticked, check for timeouts of queued connect requests. */
int i;
struct conn *cptr;
for (i = 1; i <= MAX_CONN; i++) {
cptr = &conn[i];
if (cptr->timer > 0) { /* timer was running */
cptr->timer--;
if (cptr->timer == 0) { /* timer has now expired */
cptr->state = IDLE;
to_net(i, 0, 0, CLEAR_REQ, data, 0);
}
}
174 5.4. EL PROTOCOLO DE TRANSPORTE DE INTERNET UDP
}
}
Para evitar el hecho de tener que proporcionar y administrar búferes en la entidad

de transporte, se usa aquí un mecanismo de control de flujo, diferente de la ventana
corrediza tradicional.
Cuando un usuario llama a RECEIVE, se envía un mensaje de crédito especial a
la entidad de transporte de la máquina emisora.
Al llamar al SEND, la entidad de transporte revisa si ha recibido el mensaje de
crédito para esa conexión especificada. De ser así, el mensaje se envía (en múltiples
paquetes si es necesario) y se disminuye el crédito, en caso contrario la entidad de
transporte se pone a dormir en espera de un crédito.
Este mecanismo garantiza que no se enviará nunca un mensaje a menos que el otro
lado ya haya hecho un RECEIVE. Por tanto, siempre que llegue un mensaje habrá un
búfer disponible en el cual puede ponerse.
5.4. EL PROTOCOLO DE TRANSPORTE DE IN-

TERNET UDP
5.4.1. INTRODUCCIÓN A UDP
El conjunto de protocolos de Internet soporta un protocolo no orientado a la

conexión, UDP (User Data Protocol, Protocolo de Datagramas de Usuario).
Este protocolo proporciona una forma para que las aplicaciones envíen datagramas IP
encapsulados sin tener que establecer una conexión. Es usado por muchas aplicaciones
cliente-servidor que tienen una solicitud y una respuesta para no tener así que realizar
el procedimiento de establecimiento y cierre de conexión. UDP se describe en RFC 768.
Un segmento UDP consiste en una cabecera de 8 bytes seguida de los datos. La
cabecera se muestra a continuación:
Figura 5.13: La cabecera UDP.
Un ejemplo de servicio que usa UDP es DNS (Sistema de Nombre de Dominio).
REDES
5.4.2. RPC: LLAMADA A UN PROCEDIMIENTO REMOTO

Enviar un mensaje a un host remoto y obtener una respuesta es muy parecido
a hacer una llamada a función en un lenguaje de programación, de forma que se ha
tratado que las interacciones de solicitud-respuesta en redes se asignen en forma de
llamadas a funciones.
Ejemplo: obt_direción_IP(nombre_host) que envía un paquete UDP a un
servidor DNS y espera respuesta.
En 1984 Birrell y Nelson sugirieron que se permitiera que los programas invocaran
procedimientos localizados en host remotos.
Cuando un proceso en la máquina 1 llama a uno en la máquina 2, el proceso
invocador de la primera se suspende y la ejecución del procedimiento se lleva a cabo en
la máquina 2. El paso de mensajes es transparente para el programador. Esta técnica
se llama RPC (Llamada a Procedimiento Remoto).
Al procedimiento invocador se le llama cliente y al invocado servidor.
Para llamar a un procedimiento remoto, el programa cliente debe enlazarse con
un pequeño procedimiento de biblioteca, llamado stub del cliente, que representa al
procedimiento servidor en el espacio de direcciones del cliente.
De forma similar, el servidor se enlaza con una llamada a procedimiento denomi-
nada stub del servidor.
Las llamadas a estos procedimientos aparentan ser locales.
Pasos para realizar una llamada a procedimiento remoto:
Figura 5.14: Pasos para realizar una llamada a procedimiento remoto.
1. El cliente llama al stub del cliente, esta es una llamada a procedimiento local.
2. El stub del cliente empaqueta los parámetros (marshaling) en un mensaje y realiza
una llamada de sistema para enviarlo.
176 5.4. EL PROTOCOLO DE TRANSPORTE DE INTERNET UDP
3. El kernel envía el mensaje del cliente al servidor.

4. El kernel pasa el paquete entrante al stub del servidor.
5. El stub del servidor desempaqueta y llama al procedimiento servidor con los
mismos parámetros.
UDP se utiliza comúnmente en RPC cliente-servidor.

Esto presenta algunas desventajas, entre ellas que no se pueden pasar apuntadores,
pues el cliente y servidor están en diferentes espacios de direcciones. Además si el
procedimiento utiliza variables globales, el código fallará porque las variables globales
ya no se pueden compartir.
5.4.3. RTP: PROTOCOLO DE TRANSPORTE EN TIEMPO

REAL
Otra aplicación de UDP, son las aplicaciones multimedia en tiempo real. En par-
ticular:
Radio en Internet.
Telefonía en Intenet.
Música bajo demanda.
Videoconferencias.
Video bajo demanda, etc.
Con el tiempo se trató de unificar el el protocolo de transporte de estas aplicaciones

y surgió RTP (Protocolo de Transporte de Tiempo Real). Se describe en RFC 1889 y
se utiliza ampliamente.
La posición de RTP en la pila de protocolos es algo extraña. Se decidió colocarlo
en por encima de UDP.
Figura 5.15: (a) Posición de RTP n la pila de protocolos. (b) Anidamiento de paquetes.
REDES
La aplicación multimedia consiste en múltiplos flujos de audio, video, texto, entre

otros que se entregan al proceso RTP del espacio de usuario.
La biblioteca RTP multiplexa los flujos y los codifica en paquetes RTP, que después
coloca en un socket (en el kernel del sistema operativo), los paquetes UDP se generan
e incrustan en paquetes IP. Si la computadora está en Ethernet, los paquetes IP se
colocan a continuación en tramas Ethernet para su transmisión.
RTP es un protocolo genérico, independiente de la aplicación que proporciona
características de transporte, o sea se puede decir que es un protocolo de transporte
implementado en la capa de aplicación.
La función básica de RTP es multiplexar por TDM varios flujos de datos (audio,
video) en tiempo real en un sólo flujo de paquetes UDP. El flujo se puede enviar por
unidifusión o multidifusión a uno o varios destinos.
Como es UDP los paquetes no se tratan de manera especial a menos que se es-
pecifique.
Los paquetes se enumeran correlativamente para que el destino pueda determi-
nar si falta algún paquete. Si falta alguno se puede aproximar el valor faltante por
interpolación.
Por tanto, RTP no tiene control de flujo, control de errores, confirmaciones de
recepción ni ningún mecanismo para solicitar retransmisiones.
Cada carga útil de RTP puede tener varias muestras.
Las aplicaciones en tiempo real necesitan la marcación de tiempo (timestamping)
para asociar una marca de tiempo a la primera muestra de cada paquete, aquí lo
importante es evitar las fluctuaciones, por lo que el destino utiliza almacenamiento en
búfer y reproduzca cada muestra un número exacto de mseg después del inicio del flujo,
además permite sincronizar los distintos flujos.
EL ENCABEZADO RTP
Figura 5.16: El encabezado RTP (3 palabras de 32 bits y algunas extensiones).

178 5.5. EL PROTOCOLO DE TRANSPORTE DE INTERNET TCP
Descripción de los campos del encabezado RTP:
1. Versión: Versión de RTP que es la 2
2. Tipo de carga útil: Indica qué tipo de algorimo de codificación se ha utilizado,

PCM, GSM, MP3, etc
3. Número de secuencia: Para identificar cada paquete enviado
4. Identificador de origen de sincronización: Indica a cuál flujo pertenece el

paquete, para multiplexar y demultiplexar
5.5. EL PROTOCOLO DE TRANSPORTE DE IN-

TERNET TCP
UDP es un protocolo simple y tiene algunos usos específicos, como interacciones
cliente-servidor y multimedia, pero la mayoría de las aplicaciones de Internet necesitan
una entrega en secuencia confiable.
TCP (Transmision Control Protocol, Protocolo de Control de Transmisión)
se diseñó específicamente para proporcionar un flujo de bytes confiable de extremo a
extremo a través de una interred no confiable.
TCP tiene un diseño que se adapta de manera dinámica a las propiedades de la
interred. Se definió formalmente en el RFC 793, 1122, 1323.
Una entidad de transporte TCP maneja flujos TCP e interactúa con la capa IP.
Una entidad TCP acepta flujos de datos de usuario de procesos locales, los divide
en fragmentos que no excedan los 64 KB (aunque en la práctica son 1460 bytes) de
datos que se ajustan en una sola trama Ethernet con los encabezados IP y TCP.
Cuando los datagramas que contienen datos TCP llegan a una máquina, se pasan
a la entidad TCP, la cual reconstruye los flujos de bytes originales.
La capa IP no proporciona ninguna garantía de que los datagramas se entregarán
de manera apropiada, por lo que le corresponde a TCP terminar los temporizadores y
retransmitir los datagramas conforme sea necesario.
Los datagramas que llegan podrían hacerlo en orden incorrecto, también corre-
sponde a TCP reemsamblarlos en mensajes en la secuencia correcta.
En resumen, TCP debe proporcionar la confiabilidad que la mayoría de los usuarios
desean y que IP no proporciona.
5.5.1. EL MODELO DE SERVICIO TCP

El servicio TCP se obtiene al hacer que tanto el servidor como el cliente creen
puntos terminales llamados sockets, cada socket contiene un número (dirección) que
consiste en la dirección IP del host y un número de 16 bits, que es local a ese host,
REDES
llamado puerto. Puerto es el nombre en TCP de un TSAP. Para obtener el servicio

TCP debe establecerse explícitamente una conexión entre un socket de la máquina
transmisora y un socket de la máquina receptora. Las primitivas de socket se muestran
en la figura 5.4.
Los números de puerto menores de 1024 se llaman puertos bien conocidos (well-
known ports) y se reservan para servicios estándar (hay asignados alrededor de 300).
Algunos de ellos se muestran en la siguiente figura:
Puerto Protocolo Uso

21 FTP Transferencia de archivos
23 Telnet Inicio de sesión remoto
25 SMTP E-MAIL
69 TFTP Protocolo trivial de transferencia de archivos
79 FINGER Búsqueda de información de usuario
80 HTTP World Wide Web
110 POP-3 Acceso Remoto a e-mail
119 NNTP Noticias USENET
Figura 5.17: Algunos puertos bien conocidos y servicios asociados.
Para utilizar los puertos bien conocidos en un servidor es necesario conectar a la

aplicación (daemon) demonio del puerto específico.
Una opción podría ser posible que el demonio FTP, por ejemplo, se conecte a sí
mismo al puerto 21 en tiempo de arranque, el el de telnet 23, etc.
Hacer lo anterior podría llenar la memoria con demonios que están inactivos la
mayor parte del tiempo. En su lugar lo que se hace generalmente es que un sólo demonio,
llamado inetd (demonio de Internet) en UNIX, se conecte a sí mismo a múltiples
puertos y esperar las conexiones entrantes, creando un nuevo proceso y ejecutando el
deminio específico que lo atenderá.
CARACTERÍSTICAS DE TCP
TCP es dúplex total y punto a punto por lo que no soporta la difusión ni multid-
ifusión.
Una conexión TCP es un flujo de bytes, no de mensajes, o sea los límites de los
mensajes no se conservan de extremo a extremo.
Ejemplo: Un proceso transmisor hace cuatro escrituras de 512 bytes en una co-
rriente TCP, estos datos pueden entregarse al proceso receptor como cuatro bloques
de 512 bytes, dos bloques de 1024 bytes, un bloque de 2048 o de algún otro modo. No
hay manera de que el receptor detecte las unidades en las que se escribieron los datos.
Figura 5.18: (a) Cuatro segmentos de 512 bytes enviados como datagramas indepen-
dientes. (b) Los 2048 bytes de datos se entregan a la aplicación en una sola llamada a
READ.
Una característica clave de TCP y que domina el diseño del protocolo, es que cada
byte de una conexión TCP tiene su número de secuencia de 32 bits.
5.5.2. EL PROTOCOLO TCP
La entidad TCP emisora y la receptora intercambian datos en forma de segmentos.

Un segmento consiste en un encabezado TCP fijo de 20 bytes (más una parte opcional),
seguido de cero o más bytes de datos.
El software de TCP decide el tamaño de los segmentos; puede acumular datos
de varias escrituras en varios segmentos o dividir los datos de una escritura en varios
segmentos.
Hay dos límites que restringen el tamaño de segmento. Primero, cada segmento
incluido el encabezado IP, debe caber en la carga útil de 65.515 bytes del IP. Segundo,
cada red tiene una unidad máxima de transferencia o MTU (maximum transfer
unit) y cada segmento debe caber en la MTU. En la práctica la MTU es generalmente
de 1500 bytes (el tamaño de la carga útil de Ethernet).
El protocolo básico usado por las entidades TCP es el protocolo de ventana corredi-
za. Cuando un transmisor envía un segmento, también inicia un temporizador. Cuando
llega el segmento al destino la entidad TCP receptora devuelve un segmento (con
datos, si existen ) que contiene un número de confirmación de recepción igual al si-
guiente número de secuencia que espera recibir. Si el temporizador del emisor expira
antes de la recepción de la confirmación, el emisor envía de nuevo el segmento.
Aunque este protocolo suena sencillo, tiene muchos vericuetos que cubriremos a
continuación. El TCP debe estar preparado para manejar y resolver estos problemas
de manera eficiente. Se ha invertido una cantidad considerable de esfuerzo en la op-
timización del desempeño de las corrientes TCP, incluso ante problemas de red. A
continuación se estudiarán varios de los algoritmos usados por muchas implementa-
ciones TCP.
REDES
5.5.3. LA CABECERA DE SEGMENTO TCP
Figura 5.19: Cabecera TCP.
Descripción de los campos de la cabecera:
Puerto de origen y puerto destino: Identifican los puntos terminales de

conexión. La dirección de un puerto más la dirección IP de su host forman un
punto terminal único de 48 bits.
Número de secuencia y número de confirmación de recepción: El de

confirmación especifica el siguiente byte esperado, no el último byte correctamente
recibido.
Longitud del encabezado TCP: Indica la cantidad de palabras de 32 bits

contenidas en el encabezado.
Seis indicadores de 1 bit:
• URG: Activo indica que está en uso el apuntador urgente.

• ACK: Si es 0 el segmento no contiene confirmación de recepción.
• PSH: Activo indica que se deben transmitir de inmediato.
• RST: Para restablecer una conexión o bien para rechazar un segmento no
válido o intento de abrir conexión.
• SYN: Se usa para solicitar una conexión.
◦ SYN = 1, ACK = 0 (CONNECTION REQUEST).
◦ SYN = 1, ACK = 1 (CONNECTION ACCEPTED).

• FIN: se usa para liberar una conexión
Tamaño de ventana: Indica la cantidad de bytes que pueden enviarse comen-
zando por el byte cuya recepción se ha confirmado.
Suma de verificación: Es una suma de verificación del encabezado, los datos
y el pseudoencabezado conceptual.
Apuntador urgente: Sirve para indicar qun desplazamiento en bytes a partir
del número actual de secuencia en el que se encuentran datos urgentes.
El control de flujo en TCP se maneja usando una ventana corrediza de tamaño

variable. El tamaño de ventana de 64 KB como máximo y, debido a esto, con frecuencia
es un problema: Ejemplo: en una línea T3 (44.736 Mbps) se requieren 12 mseg para
enviar una ventana completa de 64 KB. Si el retardo de propagación es de 50 mseg (fibra
trascontinental), el emisor estará inactivo 3/4 del tiempo en espera de confirmación de
recepción. De ahí en RFC1323 se propuso una opción de escala de ventana que permite
desplazar hasta 14 bits a la izquierda el campo Tamaño de ventana (230 ).
La pseudocabecera contiene las direcciones IP de 32 bits de las máquinas de origen
y destino , el número de protocolo TCP (6) y la longitud del segmento TCP (incluida
la cabecera). La inclusión de la pseudocabecera en el cálculo de la suma de verificación
ayuda a detectar paquetes mal entregados, pero hacerlo viola la jerarquía de protocolos,
puesto que las direcciones IP pertenecen a la capa IP, no TCP.
Figura 5.20: Pseudocabecera incluida en la suma de comprobación del TCP.
5.5.4. ESTABLECIMIENTO DE UNA CONEXIÓN TCP

En TCP se establecen conexiones usando el protocolo de acuerdo de re vías. Para
establecer una conexión, un lado, digamos el servidor, espera pasivamente una conexión
entrante ejecutando las primitivas LISTEN y ACCEPT y especificando cierto origen o
bien nadie en particular.
El otro lado, digamos el cliente, ejecuta una primitiva CONNECT especificando la
dirección y el puerto IP con el que se desea conectar, el tamaño máximo de segmento
TCP que está dispuesto a aceptar y opcionalmente algunos datos de usuario.
REDES
La primitiva CONNECT envía un segmento TCP con el bit SY N = 1 y el bit

ACK = 0 y espera una respuesta.
Al llegar el segmento al destino, la entidad TCP ahí revisa si hay algún proceso
ejecutando un LISTEN en el puerto indicado en el campo de Puerto de destino del
segmento. Si no lo hay envía una respuesta con el bit RST encendido para rechazar la
conexión.
Si algún proceso está escuchando el puerto, ese proceso recibe el segmento TCP
entrante y puede entonces aceptar o rechazar la conexión. Si la acepta se devuelve un
segmento de confirmación de recepción (SY N = 1 y ACK = 1).
Figura 5.21: (a) Establecimiento de una conexión TCP en el caso normal. (b) Colisión
de llamadas.
En el caso de que dos hosts intentan simultáneamente establecer una conexión

entre los mismos dos sockets, el resultado es que sólo se establece una conexión, no dos,
pues las conexiones se identifican por sus puntos terminales.
Aunque las conexiones TCP son dúplex total, para entender la manera en que se
liberan las conexiones es mejor visualizarlas como un par de conexiones simplex. Cada
conexión simplex se libera independientemente de su igual. Para liberar una conexión,
cualquiera de las dos partes puede enviar un segmento TCP con el bit F IN = 1, lo que
significa que no tiene más datos por enviar. Al confirmarse la recepción de del F IN ,
ese sentido se apaga, sin embargo, puede continuar un flujo de datos indefinido en el
otro sentido. Para evitar esto se requieren normalmente cuatro segmentos TCP para
liberar una conexión. Un F IN y un ACK para cada sentido.
Para evitar el problema de los dos ejércitos se utilizan temporizadores. Si no llega
una respuesta a un F IN en un máximo de dos tiempos de vida de paquete, el emisor
del F IN libera la conexión. Tarde o temprano el otro lado notará que nadie lo escucha
y también expira su temporizador, liberando su conexión.
5.5.5. POLÍTICA DE TRANSMISIÓN DE TCP

La administración de ventanas en el TCP no está atada directamente a los acuses
de recibo como en la mayoría de los protocolos de enlace de datos. En TCP el receptor
anuncia el tamaño de ventana al emisor. Si la ventana anunciada es de 0, el transmisor
debe detenerse hasta que el proceso de aplicación del host receptor reture algunos datos
del búfer, en cuyo momento el TCP puede anunciar una ventana más grande.
Cuando el tamaño de la ventana es de cero, el emisor normalmente no puede enviar
segmentos, excepto en dos situaciones:
1. Para enviar datos urgentes. Ejemplo: para permitir que el usuario elimine el
proceso de ejecución en la máquina remota (Ctrl + C).
2. El emisor puede enviar un segmento de 1 byte para hacer que el receptor rea-
nuncie el siguiente byte esperado y el tamaño de la ventana. El estándar TCP
proporciona explícitamente esta opción para evitar un bloqueo irreversible si llega
a perderse el anuncio de ventana.
En aplicaciones como el telnet, no es necesario que los emisores envién los datos
tan pronto como llegan de la aplicación, ni que los receptores confirmen tan rápido y la
idea la sugirió el algoritmo de Nagle (1984), de forma que al llegar datos al emisor
de 1 byte en 1 byte. En él simplemente se envía el primero y se almacenan en búfer
los demás hasta la confirmación del byte pendiente. Luego se retransmiten todos los
caracteres del búfer en un segmento TCP y se repite el ciclo.
Ejemplo: Si un usuario escribe con rapidez y la red es lenta, puede entrar una
cantidad importante de caracteres en cada segmento, reduciendo en gran medida el
ancho de banda usado. Además, el algoritmo permite el envío de un nuevo paquete si
han entrado suficientes datos para llenar la mitad de la ventana o la totalidad de un
segmento.
El algoritmo de Nagle se usa ampliamente en aplicaciones TCP, pero hay veces en
que es mejor inhabilitarlo. En particular, al operar una aplicación X-Windows a través
de Internet, los movimientos del ratón tienen que enviarse por ráfagas y el movimiento
del cursor será errático.
Otro problema que puede arruinar el desempeño de TCP es el síndrome de ven-
tana tonta (silly window syndrome). Este problema ocurre cuando se pasan datos
a la entidad transmisora en bloques grandes, pero una aplicación interactiva del la-
do receptor lee datos a razón de 1 byte a la vez. Para ver el problema obsérvese la
figura 5.22. Inicialmente, el búfer TCP del lado receptor está lleno y el transmisor lo
sabe (le ha enviado un tamaño de ventana 0). Entonces la aplicación interactiva lee un
carácter de la corriente TCP. Esta acción hace feliz al TCP receptor, por lo que envía
una actualización de ventana al transmisor indicando que envíe un byte. El transmisor
accede y envía 1 byte. El búfer ahora está lleno, por lo que el receptor reconoce el seg-
mento de 1 byte pero establece la ventana en 0. Este comportamiento puede continuar
indefinidamente.
REDES
Figura 5.22: Síndrome de ventana tonta.
La solución de Clark es evitar que el receptor envíe una actualización de ventana

para 1 byte. En cambio, se le obliga a esperar hasta tener disponible una cantidad
decente de espacio y luego lo anuncia. Específicamente, el receptor no debe enviar una
actualización de ventana hasta que pueda manejar el tamaño máximo de segmento que
anunció al establecerse la conexión, o que su búfer esté vacío a la mitad, lo que sea más
pequeño.
5.5.6. CONTROL DE LA CONGESTIÓN TCP

Cuando la carga ofrecida a cualquier red es mayor que la que puede manejar, se
genera una congestión. Internet no es una excepción.
Aunque la capa de red también intenta manejarlos, la gran parte del trabajo recae
sobre TCP porque la solución real a la congestión es la disminución de la tasa de datos.
En teoría puede manejarse el congestionamiento aprovechando un principio de
física: la ley de conservación de paquetes. La idea es no inyectar un paquete nuevo
en la red hasta que salga uno viejo. El TCP intenta lograr esta meta manipulando
dinámicamente el tamaño de ventana.
El primer paso para el manejo del congestionamiento es detectarlo. Hoy día la
pérdida de paquetes por errores de transmisión es rara debido a que los troncales de
larga distancia son fibra (excepto redes inalámbricas), por tanto la mayoría de las
expiraciones de tiempo en Internet se deben a congestión.
Para evitar que ocurra la congestión al establecerse una conexión se debe selec-
cionar un tamaño de ventana adecuado. El receptor puede especificar una ventana con
base a su tamaño de búfer, si el emisor se ajusta a ese tamaño, no ocurrirán proble-

mas de desbordamiento en la terminal receptora, pero aún pueden ocurrir debido a la
congestión interna de la red.
En la siguiente figura se ilustra el problema hidráulicamente:
Figura 5.23: (a) Red rápida alimentando un receptor de baja capacidad. (b) Red lenta
alimentando un receptor de alta capacidad.
En (a) vemos que mientras el transmisor no envíe más agua de la que puede
contener la cubeta, no se perderá agua. En (b) el factor limitante no es la capacidad de
la cubeta, sino la capacidad de conducción interna de la red. Si entra demasiada agua
a alta velocidad, ésta retrocederá, perdiéndose algo (en este caso por desbordamiento
del embudo).
La solución de Internet es aceptar que existen 2 problemas potenciales: la capaci-
dad de la red y la capacidad del receptor y manejarlos por separado. Para ello, cada
transmisor mantiene dos ventanas: la ventana que ha otorgado el receptor y una segun-
da ventana, la ventana de congestionamiento; cada una refleja el número de bytes
que puede enviar el transmisor. Por tanto, la ventana efectiva es el mínimo de lo que
el transmisor piensa que es correcto y lo que el receptor piensa que está bien.
Si el receptor dice “envía 8 Kb" y el emisor sabe que las ráfagas de más de 4 Kb
saturan la red, entonces envía 4 KB, por otra parte si la red acepta rágafas de longitud
REDES
mayor de 8 KB, siempre envía 8 KB. ¿Cómo se establece entonces el tamaño de la

ventana de congestión?.
Una solución propuesta fue el Algoritmo de Arranque Lento de Jacobson en 1988,
según el cual:
1. El emisor asigna a la ventana de congestión el tamaño de segmento máximo usado

por la conexión y envía el segmento.
2. Si se recibe la confirmación de recepción, el emisor agrega el equivalente en bytes

de un segmento a la ventana de congestión.
3. A medida que se confirman cada uno de estos segmentos se aumenta el tamaño de

la ventana de congestión, de forma que cada ráfaga confirmada duplica el tañamo
de la ventana de congestión.
4. La ventana de congestión sigue creciendo exponencialmente hasta que ocurra una

expiración del temporizador.
Si las ráfagas de 1024, 2048, y 4096 funcionan bien, pero una ráfaga de 8192 expira,
entonces la ventana de congestión debe establecerse en 4096, para evitar congestión.
Mientras el tamaño de la ventana de congestión permanezca en 4096, no se enviará una
ráfaga de mayor longitud, sin importar la cantidad de espacio de ventana otorgada por
el receptor.
En la práctica en Internet se utiliza un tercer parámetro llamado umbral, inicial-
mente en 64 KB, además del tamaño de ventana del receptor y el de la ventana de
congestión. Al ocurrir una expiración del temporizador se establece el umbral en la
mitad del valor de la ventana de congestión. Hasta el umbral el crecimiento utiliza
algoritmo de arranque lento exponencial, a partir del umbral el crecimiento pasa a ser
lineal.
Si no ocurren más expiraciones del temporizador, el tamaño de la ventana de
congestión crecerá hasta igualar el tamaño de la ventana de recepción. En ese punto
dejará de crecer y permanecerá constante mientras no hayan más expiraciones , o
cambie el tamaño de la ventana del receptor.
188 5.6. TCP Y UDP INALÁMBRICOS
Figura 5.24: Ejemplo de algoritmo de congestión en internet.
5.6. TCP Y UDP INALÁMBRICOS

En teoría los protocolos de transporte deben ser independientes de la tecnología
de la capa de red subyacente. En particular TCP no debe preocuparse si el IP está
operando por fibra o por radio. En la práctica sí que importa, puesto que la mayoría
de las implementaciones de TCP han sido optimizadas cuidaddosamente con base en
supuestos que se cumplen en las redes alambradas, pero no en inalámbricas. Ignorar
propiedades de la transmisión inalámbrica puede conducir a implementaciones de TCP
correctas desde el punto de vista lógico, pero con un desempeño horrendo.
El problema principal es el algoritmo de control de congestión. Hoy día casi todas
las implementaciones de TCP suponen que la gran mayoría de las expiraciones de
temporizador (ET) son debidas a congestionamiento y no a pérdida de paquetes. En
consecuencia si se da ET, entonces TCP disminuye su velocidad y envía con menor
ímpetu (arranque lento). Lo que se pretende con este enfoque es reducir la carga de
red y aliviar así el congestionamiento.
Desgraciadamente los enlaces de transmisión inalámbricos son muy poco confi-
ables. Pierden paquetes todo el tiempo. La reducción de la velocidad en este caso
empeora las cosas.
Ejemplo: si se pierde el 20 % de todos los paquetes y el emisor envía a 100 paq/seg,
REDES
la velocidad real es de 80 paq/seg. Si reduce a 50 paq/seg el rendimiento cae a 40

paq/seg.
En efecto, al perderse un paquete en una red alambrada, el transmisor debe reducir
la velocidad. Cuando se pierde uno en una red inalámbrica, el transmisor debe acelerar.
Cuando el transmisor no sabe de qué clase de red se trata, es difícil tomar la decisión
correcta.
Con frecuencia, la trayectoria del transmisor al receptor no es homogénea. Los
primeros 1000 km pueden ser alámbricos y el último Km inalámbrico.
Bakne y Badrinath en 1995 proponen una solución: el TCP indirecto, que es la
división de la conexión TCP en dos conexiones distintas. La primera va del emisor a la
estación base y la segunda de la estación base al receptor. La estación base simplemente
copia paquetes entre las conexiones en ambas direcciones. Este esquema se muestra en
la siguiente figura:
Figura 5.25: División de una conexión TCP en dos conexiones.
Este esquema presenta dos ventajas:
1. Ambas conexiones ahora son homogéneas.

2. Las ET, en la primera conexión pueden reducir la velocidad del emisor y las ET
en la segunda pueden acelerarla.
Una solución diferente debido a Balakrishnan y Cols (1995) no quebranta la semán-

tica de TCP. Funciona haciendo varias modificaciones pequeñas al código de la capa
de red de la estación base para hacer el proceso de comunicación aparentemente trans-
parente entre el emisor y el receptor.
Uno de los cambios es la adición de un agente espía que observa y almacena en
caché los segmentos TCP que van al host móvil y las confirmaciones de recepción que
regresan de él.
Si el agente ve un segmento TCP que sale al host móvil pero no ve el ACK, este
retransmite el segmento.
Si el agente en la estación base detecta un hueco en los números de secuencia de
entrada que provienen del host móvil, se genera una solicitud de repetición selectiva de
los bytes faltantes.
190 5.7. DESEMPEÑO
Gracias a estos dos mecanismos, el enlace inalámbrico se hace más confiable en

ambas direcciones sin que el origen lo sepa y sin cambiar la semántica de TCP.
5.7. DESEMPEÑO
Los asuntos de desempeño son muy importantes en las redes de cómputo. Cuando
hay cientos o miles de computadoras conectadas entre sí, son comunes las interacciones
complejas con consecuencias imprevisibles. Frecuentemente esta complejidad conduce
a un desempeño pobre.
Desafortunadamente, el entendimiento del desempeño de las redes es más un arte
que una ciencia. Muy poca teoría sirve en realidad para la práctica. Lo mejor que
podemos hacer es dar reglas empíricas derivadas de los tropiezos y ejemplos actuales
tomados del mundo real, convirtiéndose la experiencia de un administrador de redes
en un factor clave en este asunto.
Vimos en el tema anterior que la capa de red se ocupaba de algunos aspectos
relacionados con el desempeño, pero, puesto que su principal tarea es el enrutamiento
y control de congestionamientos, es en la capa de transporte donde recae el mayor peso
para la realización de esta labor.
5.7.1. PROBLEMAS DE DESEMPEÑO EN LAS REDES DE

CÓMPUTO
Algunos problemas del desempeño, como congestionamiento, son causados por
sobrecargas temporales de los recursos. El desempeño también puede degradarse cuando
hay un desequilibrio estructural de los recursos (líneas muy rápidas y computadoras
lentas o viceversa).
Las sobrecargas pueden generarse sincrónicamente. Por ejemplo, cuando hay un
fallo del suministro, y todas las máquinas en una secuencia de arranque común acuden
al servidor DHCP para conocer su identidad. Si todas las máquinas hacen esto al
unísono el servidor se vendría abajo.
Otro asunto relativo a la afinación es el ajuste correcto de las temporizaciones.
Normalmente cuando se envía un TPDU se utiliza un temporizador para protegerse
contra pérdidas. Si se le asigna un valor muy bajo ocurrirán retransmisiones innece-
sarias, congestionando los alambres y si es muy alto ocurrirán retardos innecesarios
tras la pérdida de una TPDU.
En cuanto a la ventana de la red, no puede escogerse un mismo tamaño para todo
tipo de redes. Dependiendo de la velocidad de éstas, tendrá que escogerse un tamaño
mayor o menor.
Una cantidad que conviene recordar durante el análisis del desempeño de redes
es el producto ancho de banda-retardo, que se obtiene al multiplicar el ancho de
banda (en bits/seg) por el tiempo de retarde de ida y vuelta (en seg). El producto es
la capacidad del tubo desde el transmisor al receptor y de regreso (en bits).
REDES
Ejemplo: En la siguiente figura el producto de ancho de banda-retardo es de 40

millones de bits. En otras palabras, el transmisor tendría que enviar una ráfaga de 40
millones de bits para trabajar a toda velocidad hasta la llegada del primer acuse de
recibo. Esta es la razón por la que una ráfaga de medio millón de bits sólo logra una
eficiencia del 1.25 %: es sólo el 1.25 % de la capacidad del tubo.
Figura 5.26: Estados de transmisión de un megabit de San Diego a Boston. (a) En

t = 0. (b) Tras 500 µsec. (c) Tras 20 msec. (d) Tras 40 msec.
5.7.2. MEDICIÓN DEL DESEMPEÑO DE LAS REDES

Cuando una red tiene un pobre desempeño los usuarios se quejan, exigiendo mejo-
ras. Le corresponde a los operadores de red, determinar exactamente lo que ocurre. El
estudio siguiente se basa en el trabajo de Mogul (1993).
El ciclo usado para mejorar el desempeño de las redes contiene los siguientes pasos:
1. Medir los parámetros pertinentes y el desempeño de la red.
2. Tratar de entender lo que ocurre.
3. Cambiar un parámetro.
192 5.7. DESEMPEÑO
Estos pasos se repiten hasta que el desempeño sea lo bastante bueno o que quede
claro que se han hecho todas las mejoras posibles.
Las mediciones pueden hacerse de muchas maneras y en muchos lugares. El tipo
de medición más básico es arrancar un temporizador al iniciar una actividad y medir el
tiempo que tarda. Otras mediciones se hacen con contadores que registran la frecuencia
con que ocurre un evento (por ejemplo TPDU perdidas). Por último, con frecuencia
nos interesa saber la cantidad de algo, como el número de bytes procesados durante
cierto intervalo de tiempo.
5.7.3. DISEÑO DE SISTEMAS PARA UN MEJOR DESEM-

PEÑO
La medición y los ajustes pueden, con frecuencia, mejorar considerablemente el

desempeño, pero no pueden sustituir un buen diseño original. Una red mal diseñada
puede mejorarse sólo hasta un límite. Más allá, tiene que rehacerse desde el principio.
Mogul fue el primero en postular una serie de reglas para el buen diseño de una
red, productos del conocimiento común de diseñadores durante generaciones:
1. La velocidad de la CPU es más importante que la velocidad de la red. En muchos

casos los cuellos de botella está en los hosts, por lo que un aumento de la CPU
de los mismos podría hacer que aumente el rendimiento de la red.
2. Reducir el número de paquetes para reducir la sobrecarga de software. El proce-

samiento de una TPDU tiene cierta cantidad de carga extra por TPDU y cierta
cantidad de procesamiento por byte. Además hay una carga extra en las cargas
inferiores que se debe considerar. Cuando llega un paquete se causa una inter-
rupción. Una reducción de n veces en las TPDU enviadas reduce la carga extra.
Este es un argumento a favor de la recolección de una cantidad importante de
datos antes de su transmisión. El Algoritmo de Nagle y Clark ante la ventana
tonta son intentos por lograr esto.
3. Reducir al mínimo las conmutaciones de contexto: por ejemplo de modo usuario

a modo kernel y viceversa. Estas conmutaciones pueden reducirse haciendo que
el procedimiento de biblioteca que envía los datos los guarde un un búfer interno
hasta tener una buena cantidad de ella.
Desafortunadamente, en muchos sistemas operativos ocurren conmutaciones de
contexto adicionales que desperdician mucho tiempo de CPU y tienen un efecto
devastador sobre la red. En la figura siguiente se muestra un ejemplo de estas
conmutaciones:
REDES
Figura 5.27: Cuatro combinaciones de contexto para manejar un paquete con un

administrador de red de espacio de usuario.
4. Reducir al mínimo las copias: Un paquete de entrada se copia de búfer de tarjeta

de red a un búfer del kernel; de ahí a un búfer de la capa de red; luego en el búfer
de la capa de transporte y por último en el proceso de aplicación receptor.
5. Es posible comprar más ancho de banda, pero no un retardo menor. Una mejora
de ancho de banda podría conseguirse por ejemplo con la instalación de una
segunda fibra, pero un mayor ancho de banda no reduce el retardo. Tampoco se
reducirá el retardo mejorando el software de protocolo, el sistema operativo o la
interfaz de red si el cuello de botella es el tiempo de transmisión.
6. Evitar la congestión es mejor que recuperarse de ella.
7. Evitar expiraciones del temporizador. Hay que optar por que los intervalos de
temporización sean más bien conservadores, ya que si un temporizador tarda un
poco produce agrega un retardo extra a una conexión, pero si un temporizador
acaba pronto se desperdicia ancho de banda e impone una carga extra a los
enrutadores de red.
5.7.4. PROCESAMIENTO RÁPIDO DE LAS TPDU
El obstáculo principal en las redes rápidas es el software de protocolos. La carga

extra de procesamiento de las TPDU tiene dos componentes: la carga extra por TPDU
y la carga extra por byte. Ambas deben combatirse. La clave para el procesamiento
rápido de las TODU es separar el caso normal (transferencia normal en un sólo sentido)
y manejarlo como caso especial. Aunque se necesita una secuencia de TPDU especiales
para entrar en el estado ESTABLISHED, una vez ahí el procesamiento de las TPDU
es directo hasta que un lado cierra la conexión.
Comencemos examinando el lado del transmisor en el estado ESTABLISHED
cuando hay datos por transmitir. Tomemos como referencia la siguiente figura:
194 5.7. DESEMPEÑO
Figura 5.28: La trayectoria rápida del emisor al receptor se indica con una línea gruesa.
Los pasos de procesamiento de esta trayectoria se muestran sombreados.
El proceso transmisor está en el núcleo para ejecutar SEND. Lo primero que hace la
entidad de transporte es probar si éste caso es el normal: el estado es ESTABLISHED,
ningún lado está tratando de cerrar la conexión, se está enviando una TPDU normal
completa y hay suficiente espacio de ventana disponible en el receptor. Si se cumplen
todas las condiciones, no se requieren pruebas adicionales y puede seguirse la trayectoria
rápida a través de la entidad de transporte transmisora.
En el caso normal las cabeceras de las TPDU de datos consecutivas son casi iguales.
Para aprovechar este hecho, se almacena una cabecera prototipo en la entidad de trans-
porte. Al principio de la trayectoria rápida, la cabecera se copia lo más rápidamente
posible en un búfer de trabajo palabra por palabra. Los campos que cambia de la
TPDU a otra se sobreescriben en el búfer. Con frecuencia estos campos se reducen
fácilmente de las variables de estado, como el siguiente número de secuencia. A con-
tinuación se pasan a la capa de red un apuntador a la cabecera completa de la TPDU
más un apuntador a los datos de usuario. Aquí puede usarse la misma estrategia. Por
último, la capa de red entrega el paqete resultante a la capa de enlace de datos.
Ejemplo: Funcionamiento de este principio en TCP/IP. En la figura siguiente se
muestra la cabecera TCP. Los campos que no son iguales en varias TPDU consecuti-
vas durante un flujo en un sólo sentido aparecen sombreados. Todo lo que tiene que
hacer la entidad de transporte transmisora es copiar las cinco palabras de la cabecera
prototipo en el búfer de salida, actualizar el número de secuencia, calcular la suma de
comprobación e incrementar el número de secuencia en la memoria. Entonces puede
entregar la cabecera y los datos a un procedimiento IP especial para enviar una TPDU
normal máxima. El IP entonces copia su cabecera prototipo de cinco palabras en el
búfer, llena el campo de identificación y calcula su suma de comprobación. El paquete
ya está listo para transmitirse.
REDES
Figura 5.29: (a) Encabezado TCP. (b) Encabezado IP. En ambos casos, los campos
sombreados se toman sin cambios del prototipo.
196 5.7. DESEMPEÑO
REDES
LA CAPA DE APLICACIÓN
Habiendo concluido todos los preliminares, ahora llegamos a la capa de aplicación,

donde pueden encontrarse todas las aplicaciones interesantes. Las capas por debajo de
la de aplicación están ahí para proporcionar transporte confiable, pero no hacen ningún
trabajo verdadero para los usuarios. En este capítulo se estudiarán algunas aplicaciones
reales.
Sin embargo, aún en la capa de aplicación se necesitan protocolos de apoyo que
permitan el funcionamiento de las aplicaciones reales. La primera área es la seguri-
dad, que no sólo un protocolo, sino una gran cantidad de conceptos y protocolos que
pueden usarse para asegurar la confidencialidad donde sea necesaria. La segunda es el
DNS, que maneja los nombres de Internet. El tercer protocolo de apoyo sirve para la
administración de la red.
6.1. SEGURIDAD DE LA RED
Durante las primeras décadas de su existencia, las redes de computadoras fueron

usadas principalmente por investigadores universitarios para el envío de correo elec-
trónico, y por empleados corporativos para compartir impresoras. En estas condiciones,
la seguridad no recibió mucha atención. Pero ahora, cuando millones de ciudadanos
comunes usan redes para sus transacciones bancarias, compras y declaraciones de im-
puestos, la seguridad de las redes aparece en el horizonte como un problema potencial
de grandes proporciones.
197
198 6.2. DNS: SISTEMA DE NOMBRES DE DOMINIO
La seguridad es un tema amplio que cubre una multitud de pecados. En su forma

más sencilla, la seguridad se ocupa de garantizar que los curiosos no puedan leer, o peor
aún, modificar mensajes dirigidos a otros destinatarios; se preocupa por la gente que
intenta acceder a servicios remotos no autorizados; también se ocupa de mecanismos
para verificar que el mensaje supuestamente enviado por la autoridad fiscal que indica:
“Pague el viernes o aténgase a las consecuencias" realmente viene de ella y no de la
mafia. La seguridad también se ocupa del problema de la captura y reproducción de
mensajes legítimos, y de la gente que intenta negar que envió ciertos mensajes.
Quien quiera saber más de seguridad que se compre un libro.
6.2. DNS: SISTEMA DE NOMBRES DE DOMINIO

Los programas pocas veces hacen referencia a los hosts, buzones de correo y otros
recursos por sus direcciones binarias de red.
Ejemplo: Enviar correo electrónico a i12yemom@150.214.110.21 significa que si el
ISP cambia de dirección IP, la dirección de correo debe cambiar. Además es mucho
más difícil recordar una secuencia de números que un nombre de dominio.
Por esto y otros motivos, en lugar de números binarios, los programas usan cadenas
ASCII, como i12yemom@uco.es. Sin embargo, la red misma sólo entiende direcciones
binarias, por lo que se requiere algún mecanismo para convertir las cadenas ASCII en
direcciones de red.
En los tiempos de ARPANET, sólo había un archivo, “host.txt", en el que se
listaban todos los hosts y su correspondencia, pero cuando la red creció este enfoque
presenta una serie de problemas y puede no funcionar bien. Por una parte el archivo
se volvería demasiado grande. Por otro lado, un problema aún más importante era
que ocurrirían conflictos con los nombres de los hosts a menos que se administraran
centralmente, a menos que los nombre se administraran centralmente, algo impensable
en una red internacional enorme. Para resolver estos problemas se inventó el DNS
(Domain Name Server, sistema de nombres de dominio).
La forma en que se utiliza DNS es sìmple. Para relacionar un nombre con una
dirección IP, un programa de aplicación llama a un procedimiento de biblioteca llamado
resolvedor y le pasa el nombre como parámetro (gesthostbyname). El resolvedor envía
un paquete UDP a un servidor DNS local, que busca el nombre y devuelve la dirección
IP al resolvedor, que entonces lo devuelve al solicitante. Una vez que el programa
tiene la dirección IP, el programa puede establecer una conexión TCP con el destino o
enviarle paquetes UDP.
6.2.1. EL ESPACIO DE NOMBRES DNS

La administración de un grupo grande y continuamente cambiante de nombres
es un problema nada sencillo. En el sistema postal, la administración de nombres se
hace requeriendo letras para especificar el país, estado o provincia, ciudad, ciudad y
REDES
calle, y dirección del destinatario. Con este tipo de direccionamiento jerárquico, no hay
confusión entre direcciones. El DNS funciona de la misma manera.
Conceptualmente internet se divide en varios cientos de dominios de nivel superior,
cada uno de los cuales abarca muchos hosts. Cada dominio se divide en subdominios y
así sucesivamente. Los dominios de nivel superior se dividen en dos categorías: genéricos
(com, edu, gov, mil, net, org) y los de país que incluyen una entrada para cada país
(es, us, jp, cu, nl, etc.).
Todos los dominios pueden representarse mediante un árbol como se muestra en
la figura siguiente:
Figura 6.1: Parte del espacio de nombres de dominio de Internet.
Las hojas del árbol representan los dominios que no tienen subdominios. Un do-
minio de hoja puede contener un solo host, o puede representar a una compañia y
contener miles de hosts.
En noviembre de 2000, ICANN aprobó cuatro nuevos dominios de nivel superior:
biz (negocios), info (información), name (nombres de persona) y pro (profesionales
como doctores y abogados).
Cada dominio se nombra por la ruta hacia arriba desde él a la raíz. Los compo-
nentes se separan con puntos. Por ejemplo eng.sun.com.
Los nombres de dominio pueden ser absolutos o relativos. Un nombre de dominio
absoluto acaba en punto y uno relativo no.
Los nombres de dominio no hacen distinción entre mayúsculas y minúsculas, para
él significan lo mismo. Los nombres de componentes pueden ser de hasta 63 caracteres
y la ruta completa de hasta 255 caracteres.
Cada dominio controla el modo de asignación de los dominios que están debajo de
él. Para crear un nuevo dominio, se requiere el permiso del dominio en que se incluirá.
6.2.2. REGISTROS DE RECURSOS

Cada dominio sea un host individual o un dominio superior, puede tener un grupo
de registros de recursos asociados a él En un host individual, el registro de recursos
más común es su dirección IP. Cuando un resolvedor da un nombre de dominio al DNS,
lo que recibe son los registros de recursos asociados a ese nombre. Por tanto, la función
real del DNS es relacionar los dominios de nombres con los registros de recursos.
Un registro de recursos tiene cinco tuplas. Aunque éstas se codifican en binario
por cuestión de eficiencia, en la mayoría de las presentaciones los registros de recursos
se dan como texto ASCII, una línea por registro de recurso. El formato es el siguiente:
Nombre_dominio Tiempo_de_vida Tipo Clase Valor
Descripción:
Nombre_dominio: Indica el dominio al que pertenece el registro.
Tiempo_vida: Indica la estabilidad del registro.
Tipo: Indica el tipo de registro de que se trata. Los tipos más importantes se
listan en la siguiente figura:
Tipo Significado Valor

SOA Inicio de autoridad Parámetros para esta zona
A Dirección IP de un host Entero de 32 bits
MX Intercambio de correo Prioridad, dominio dispuesto a aceptar
correo electrónico
NS Servidor de nombres Nombre de un servidor para este do-
minio
CNAME Nombre canónico (alias) Nombre de dominio
PTR Apuntador Alias de una dirección IP
HINFO Descripción del host CPU y SO en ASCII
TXT Texto Texto ASCII no interpretado
Figura 6.2: Tipos principales de registro de recurso DNS.
• El tipo de registro más importante es el registro A (dirección) que contiene

una dirección IP, para que otras máquinas puedan comunicarse con él. Al-
gunos hosts tienen dos o más conexiones de red, en cuyo caso tendrán un
registro de recurso de tipo A por cada conexión de red.
• MX: indica el nombre de dominio para aceptar correo electrónico.
• CNAME: permite la creación de Alias.
• PTR: ping.
• HINFO: tipo de máquina y sistema operativo.
• TXT: más información sobre el dominio no obligatoria.
REDES
Clase: Para Internet es siempre IN.
Valor: Este campo puede ser un número, un nombre de dominio o una cadena
ASCII. La semántica depende el tipo de registro.
Ejemplo de registro de recursos.
; database for cs.vu.nl domain
; Authoritative data for cs.vl.nl
cd.vu.nl 86400 IN SOA star boss (952771,7200,7200)

cs.vu.nl 86400 IN TXT "Faculteit Wiskunde en Informatica."
cs.vu.nl 86400 IN TXT "Vrije Universiteit Amsterdam."
cs.vu.nl 86400 IN MX 1 zephyr.cs.vu.nl
cs.vu.nl 86400 IN MX 2 top.cs.vu.nl
flits.cs.vu.n 86400 IN HINFO Sun Unix

flits.cs.vu. 86400 IN A 130.37.16.112
flits.cs.vu.nl 86400 IN A 132.31.231.165
flits.cs.vu.nl 86400 IN MX 1 flits.cs.vu.nl
flits.cs.vu.nl 86400 IN MX 2 zephyr.cs.vu.nl
flits.cs.vu.nl 86400 IN MX 3 top.cs.vu.nl
www.cs.vu.nl 86400 IN CNAME star.cs.vu.nl
ftp.cs.vu.nl 86400 IN CNAME zephyr.cs.vu.nl
rowboat IN A 130.37.56.201
IN MX 1 rowboat
IN MX 2 zephyr
IN HINFO Sun Unix
little-sister IN A 130.37.62.23
IN HINFO Mac MacOS
laserjet IN A 192.31.231.216
IN HINFO "HP Laserjet IIISi" Proprietary
Figura 6.3: Parte de una posible base de datos DNS para cs.vu.nl.
6.2.3. SERVIDORES DE NOMBRES
En teoría un sólo servidor de nombres podría contener la base de datos DNS

completa y responder a todas las consultas sobre ella. En la práctica, este servidor
estaría tan sobrecargado que sería inservible. Es más, si legara a caerse, la Internet
completa se vendría abajo.
Para evitar los problemas asociados a teenr una sola fuente de información, el
espacio de nombres DNS se divide en zonas no traslapantes. Una manera posible de
dividir el espacio de nombres se muestra en la siguiente figura:
Figura 6.4: Parte del espacio de nombres DNS, donde se muestra la división de zonas.
Cada zona contiene una parte del árbol y también contiene servidores de nombres
que tienen la información de autorización correspondiente a esa zona. Normalmente,
una zona tendrá un servidor de nombres primario, que obtiene su información de un
archivo en su disco, y uno o más nombres de servidores secundarios, que obtienen su
información del servidor de nombres primario. Para mejorar la confiabilidad, algunos
servidores de cierta zona pueden situarse fuera de la zona.
Cuando un resolvedor tiene una consulta referente a un nombre de dominio, la
pasa a uno de los servidores de nombres locales. Si el dominio que busca cae bajo la
jurisdicción del servidor de nombres, devuelve los registros de recursos autorizados. Un
registro autorizado es uno que viene de la autoridad que administra el registro, y
por tanto siempre es correcto.
Por otro lado, si el dominio es remoto y no hay información disponible localmente
sobre el dominio solicitado, el servidor de nombres envía un mensaje de consulta para
el dominio solicitado al servidor de nombres de nivel superior. Para hacer más claro el
proceso, consideremos el siguiente ejemplo:
REDES
Figura 6.5: Manera en que un resolvedor busca un nombre remoto en 8 pasos.
En este caso, un resolvedor de flits.cs.vu.nl quiere saber la dirección IP del host

linda.cs.yale.edu. El proceso se completa en 8 pasos. Cuando los registros llegan de
vuelta a cs.vu.nl, son ingresados en caché ahí, para el caso de que se necesiten después.
Si se usan registros de caché se considera que es información no autorizada. Si se realizan
cambios en cs.yale.edu no se propagarán a todos los cachés del mundo que puedan saber
sobre ella. Por ello, las entradas en caché no deben vivir demasiado tiempo. Ésta es
la razón de que el tiempo_de_vida se incluya en cada registro de recurso; indica a los
servidores de nombres remotos el tiempo durante el cual deben mantener en caché los
registros.
6.3. CORREO ELECTRÓNICO

El correo electrónico o e-mail ha existido por más de dos décadas. En la década
del 90 se dio a conocer al gran público.
Los primeros sistemas de correo electrónico simplemente consistían en protocolos
de transferencias de archivos, con la convención de que la primera línea del archivo
contenía la dirección del destinatario.
En él se utilizaba mucho la simbología ASCII. Veamos algunos ejemplos:
Figura 6.6: Algunos emoticonos ASCII.
A medida que pasó el tiempo, las limitaciones de este enfoque se hicieron obvias.
Algunas de las quejas eran:
1. El envío de un mensaje a un grupo de personas era laborioso.
2. Los mensajes no tenían estructura interna.

204 6.3. CORREO ELECTRÓNICO
3. El remitente nunca sabía si su mensaje había llegado o no.
4. La interfaz de usuario muy pobre.
5. No era posible crear y enviar mensajes que contuvieran mezcla de texto, dibujos,
y voz.
A medida que se acumuló experiencia se propusieron sistemas de correo electrónico

más elaborados. En 1982 se propusieron propuestas de correo electrónico de ARPANET
como RFC 821(protocolo de transmisión) y RFC 822 (formato de mensaje) en los cuales
se basan los actuales sistemas de correo.
6.3.1. ARQUITECTURA Y SERVICIOS

Los sistemas de correo electrónico generalmente consisten en dos susbsistemas: los
agentes de usuario, que permiten a la gente leer y enviar correo electrónico, y los
agentes de transferencia de mensajes, que mueven los mensajes del origen al des-
tino. Los agentes de usuario son programas locales que proporcionan un método basado
en comandos, basado en menús o de interacción gráfica con el sistema de correo elec-
trónico. Los agentes de transferencia de mensajes suelen ser demonios que se ejecutan
en segundo plano y mueven correo electrónico a través del sistema.
Por lo general los sistemas de correo electrónico desempeñan cinco funciones bási-
cas:
1. Redacción: se refiere al proceso de crear mensajes y respuestas.
2. Transferencia: se refiere a mover mensajes del remitente al destinatario, requiere

establecer una conexión con el destino o alguna máquina intermedia, enviar el
mensaje y liberar.
3. Generación del informe: tiene que ver con indicar al remitente que ocurrió
con el mensaje.
4. Visualización: de los mensajes.
5. Disposición: tiene que ver con lo que el destinatario hace con el mensaje una
vez que lo recibe.
6.3.2. EL AGENTE USUARIO

Un agente de usuario normalmente es un programa (a veces llamado lector de
correo) que acepta una variedad de comandos para redactar, recibir y contestar los
mensajes, así como para manipular los buzones de correo.
Algunos agentes tienen una interfaz elegante operada por menús o por iconos que
requieren ratón y otros esperan comandos desde el teclado.
REDES
6.3.3. FORMATOS DE MENSAJE
RFC 822
Los mensajes consisten en una envoltura primitiva, algunos campos de cabecera,

una línea en blanco, y el cuerpo del mensaje. Cada cuerpo de cabecera consiste en una
sola línea de texto ASCII que contiene el nombre del campo, dos puntos (:) y, para la
mayoría de los campos, un valor.
En el uso normal, el agente de usuario construye un mensaje y lo pasa al agente
de transferencia de mensajes, quien entonces usa algunos campos de la cabecera para
construir la envoltura.
Los principales campos de cabecera relacionados con el transporte del mensaje se
listan a continuación:
Encabezado Significado
To: Direcciones de correo de los destinatarios primarios
Cc: Direcciones de correo de los destinatarios secundarios
Bcc: Direcciones de correo para las copias ocultas
From: Persona o personas que crearon el mensaje
Sender: Direcciones de correo del remitente
Received: Línea agregada por cada agente de transferencia en la ruta
Return-Path Puede usarse para identificar una ruta de regreso al remitente
Figura 6.7: Campos de cabecera de RFC 822 relacionados con el transporte de mensajes.
En términos de entrega no hay diferencia entre los destinatarios primarios y se-

cundarios. Es una diferencia por entero psicológica. Cc viene de copia al carbón. El
campo Bcc es como el Cc, excepto que esta línea se borra de todas las copias enviadas
a los destinatarios primarios y secundarios.
Además de estos campos, los mensajes RFC 822 también pueden contener una
variedad de campos de cabecera usados por los agentes de usuario o los destinatarios.
Los más comunes se listan a continuación:
Date: Fecha y Hora de envío del mensaje
Reply-To: Dirección de correo a la que deben enviarse las contestaciones
Message-Id: Número único para referencia posterior a este mensaje
References: Otros indentificadores del mensaje pertinente
Keywords: Claves seleccionadas por el usuario
Subject: Resumen corto del mensaje para desplegar en una línea
Figura 6.8: Algunos campos usados en la cabecera de mensaje RFC 822.

6.3.4. MIME: EXTENSIONES MULTIPROPÓSITO DE CORREO

DE INTERNET
En los primeros días de ARPANET, el correo electrónico consistía exclusivamente
en mensajes de texto escritos en inglés y expresados en ASCII. En tal entorno, el RFC
822 hacía todo el trabajo: especificaba cabeceras, pero dejaba el contenido en manos
del usuario. Hoy en día, en la red mundial de Internet, este enfoque ya no es adecuado.
Los problemas incluyen envío y recepción de:
1. Mensajes en idiomas con acento (Ej. Español, Francés, Alemán).
2. Mensajes en alfabetos no latinos (Ej. Hebreo y ruso).
3. Mensajes en idiomas sin alfabetos (Ej. Chino y japonés).
4. Mensajes que no contienen texto (Ej. Audio e imágenes).
Se propuso una solución en el RFC 1341 y se actualizó en RFCs 2045-2049. Es-

ta solución se le llamó MIME (Multipurpose Internet Mail Extensions, extensiones
multipropósito de correo Internet) y se usa ampliamente.
La idea básica de MIME es continuar usando el formato RFC 822, pero agregar
una estructura al cuerpo del mensaje y definir reglas de codificación para los mensajes
no ASCII. Al no desviarse del 822, los mensajes MIME pueden enviarse usando los
programas y protocolos de correo electrónico existentes. Todo lo que tiene que cam-
biarse es son los programas transmisores y receptores, lo que pueden hacer los usuarios
mismos.
MIME define cinco nuevas cabeceras de mensaje:
MIME-Version: Identifica la versión de MIME
Content-Description: Cadena de texto que describe el contenido
Content-Id: Identificador único
Content-Transfer-Encoding: Cómo se codifica el mensaje para su transmisión
Content-Type: Naturaleza del mensaje
Figura 6.9: Cabeceras RFC 822 agregadas por MIME.
Descripción de los encabezados MIME:
MIME-Version:
Es un mensaje de texto normal en inglés, y se procesa como tal.
Content-Description:
Cadena ASCII que dice lo que está en el mensaje. Esta cabecera es necesaria para
que el destinatario sepa si vale la pena descodificar y leer el mensaje.
REDES
Content-Id:
Identifica el contenido; usa el mismo que la cabecera estándar Message-Id:.
Content-Transfer-Encoding: indica la manera en que se codifica el mensaje

para su transmisióna través de una red donde se podrían tener problemas con la
mayoría de los caracteres distintos de letras, números y signos de puntuación:
1. Texto ASCII: los caracteres usan 7 bits.

2. Texto ASCII: los caracteres usan 8 bits.
3. Codificación base64: para codificar mensajes binarios, se dividen grupos de
24 bits en unidades de 6 bits y cada unidad se envía como un carácter
ASCII legal. “A" para 0, “B" para 1, etc y por último + y / para el 62, 63
respectivamente.
4. Codificación entrecomillada imprimible: mensajes casi completamente ASCII,
se usa ASCII de 7 bits, con todos los caracteres por encima de 127, con un
valor del carácter en dígitos hexadecimales.
Content-Type: especifica la naturaleza del cuerpo del mensaje. En el RFC 2045

hay siete tipos definidos, cada uno de los cuales tiene uno o más subtipos:
1. Tipo texto:
• text: para texto normal.
• text/enriched: texto enriquecido, forma para indicar negritas, cursivas,
tamaños, sangrías, justificaciones y esta basado en SGML, que es el
lenguaje estándar genérico de marcado de etiquetas y que se usa en
HTML. Ej. Ha llegado el <bold>momento </bold>dijo José.
• text/html (RFC 2854): para permitir que las páginas HTML, se en-
viaran en un correo RFC 822.
2. Tipo imagen:
se usan muchos formatos para almacenar y transmitir imágenes fijas, tanto
con comprensión como sin ella.
3. Tipo audio y video:
son para sonido e imágenes en movimiento respectivamente. El primer for-
mato de video definido fue el diseñado por el modesto grupo MPEG (Grupo
de expertos en imágenes en movimiento). Además de audio/basic, se agregó
audio/mpeg para permitir enviar archivos mp3.
4. Tipo aplicación:
Es un tipo general para los formatos que requieren procesamiento externo
no cubierto por ninguno de los otros tipos. Octet-stream es simplemente una
secuencia de bytes no interpretados.
5. Tipo mensaje:
Permite que un mensaje esté encapsulado por completo dentro de otro, por
ejemplo para el reenvío de mensajes o externo que debe traerse de la red.
6. Tipo multiparte:
Permite que un mensaje contenga más de una parte con el comienzo y fin
de cada parte claramente delimitados
Ejemplo MIME:
From: elinmor@abc.com
To: carolyn@xyz.com
Subject: Queria decirte ...
MIME-Version: 1.0
Message-Id: <0704760941.AA00747@abc.com>
Content-Type: multipart/alternative;
boundary=qwertyuiopasdfghjklzxcvbnm
--qwertyuiopasdfghjklzxcvbnm
Content-Type: text/plain
Feliz cumpleaños para ti,

Feliz cumpleaños para ti,
Feliz cumpleaños para ti, querida <bold>Carolyn</bold>
Feliz cumpleaños para ti.
--qwertyuiopasdfghjklzxcvbnm
Content-Type: audio/basic;
directory="tmp";
name="birthday.snd"
Content-Transfer-Encoding: base64
MIIC1DCCAn6gAwIBAgIBADANBgkqhkiG9w0BAQQFADCBgDELMAkGA1UEBhMCRVMx
DzANBgNVBAgUBkVzcGHxYTESMBAGA1UEBxMJQ2FzdGVsbG9uMQ0wCwYDVQQKEwMX
aXN1MR0wGwYDVQQDExRNYW5vbG8gTW9sbGFyIEdhcmNpYTEeMBwGCSqGSIb3DQEJ
ARYPbW9sbGFyQG5pc3Uub3JnMB4XDTAwMTEyMzA4MTIxOVoXDTAwMTIyMzA4MTIx
OVowgYAxCzAJBgNVBAYTAkVTM
--qwertyuiopasdfghjklzxcvbnm--
Figura 6.10: Mensaje multiparte que contiene alternativas de texto enriquecido y audio.
6.3.5. AGENTE DE TRANSFERENCIA DE MENSAJES

El agente de transferencia de mensajes se ocupa de transmitir los mensajes del
remitente al destinatario. La manera más sencilla de hacer esto es establecer una co-
nexión de transporte de la máquina origen a la de destino y sencillamente transferir el
mensaje.
REDES
SMTP: PROTOCOLO SENCILLO DE TRANSFERENCIA DE CORREO
En Internet el correo electrónico se entrega al hacer que la máquina origen es-

tablezca una conexión TCP con el puerto 25 de la máquina destino. Escuchando en
este puerto está un demonio de correo electrónico que habla con el SMTP (Simple
Mail Transfer Protocol, Protocolo Simple de Transporte de Correo). Este demo-
nio acepta conexiones de entrada y copia mensajes de ellas a los buzones adecuados.
Si no puede entregarse un mensaje, se devuelve al transmisor un informe de error que
contiene la primera parte del mensaje que no pudo entregarse.
SMTP es un protocolo ASCII sencillo, después de establecer la conexión TCP
con el puerto 25, el servidor comienza enviando una línea de texto que proporciona
identidad e indica sin está preparado o no para recibir correo. Si no lo está, el cliente
libera la conexión y lo intenta después.
Si el servidor está dispuesto a aceptar correo electrónico, el cliente anuncia de
quién viene el mensaje, y a quién está dirigido. Si existe tal destinatario en el destino,
el servidor da al cliente permiso para enviar el mensaje. Entonces el cliente envía el
mensaje y el servidor acusa su recibo. Por lo general no se requieren sumas de compro-
bación porque el TCP proporciona una corriente de bits confiable. Si hay más correo
electrónico, se envía ahora. Una vez que todo el correo electrónico ha sido intercambi-
ado en ambas direcciones, se libera la conexión. Un ejemplo de diálogo para la figura
6.10, incluidos los códigos numéricos usados por el SMTP, se muestra en la figura 6.11.
Las líneas enviadas por el cliente se marcan con C:; aquellas enviadas por el servidor
se marcan con S:.
S: 220 servicio SMTP xyz.com listo

C: HELO abc.com
S: 250 xyz.com dice hola a abc.com
C: MAIL FROM: <elinmor@abc.com>
S: 250 transmisor ok
C: RCPT TO: <carolyn@xyz.com>
S: 250 receptor ok
C: DATA
S: 354 envía correo; termina con una linea unicamente con "."
C: From: elinmor@abc.com
C: To: carolyn@xyz.com
C: MIME-Version:1.0
C: Message-Id: <0704760941.AA00747@abc.com>
C: Content-Type: multipart/alternative; boundary=qwertyuiopasdfghjklzxcvbnm
C: Subject: La Tierra orbita al Sol un numero entero de veces
C:
C: Éste es el preambulo. El agente de usuario lo ignora. Tenga un bonito dia.
C:
C: --qwertyuiopasdfghjklzxcvbnm
C: Content-Type: text/richtext
C:
C: Feliz cumpleaños para ti

C: Feliz cumpleaños para ti, querida <bold> Carolyn </bold>
C:
C: Content-Type: message/external-body;
C: acccess-type="anon-ftp",
C: site="bicicle.acb.com";
C: directory="pub";
C: name="birthday.snd"
C:
C: content-type: audio/basic
C: content-transfer-encoding: base64
C:.
S: 250 mensaje aceptado
C: QUIT
S: 221 xyz.com cerrando conexion
Figura 6.11: Transferencia de un mensaje de elinore@abc.com a carolyn@xyz.com.
ENTREGA FINAL
Hasta ahora hemos supuesto que todos los usuarios trabajan en máquinas capaces
de enviar y recibir correo electrónico. Este modelo funcionó bien durante décadas cuan-
do todos los hosts de ARPANET estaban en línea.
Con el advenimiento de los ISP, el modelo dejó de usarse. El problema es el siguien-
te: ¿qué sucede en el ejemplo anterior si carolina no está en línea en ese momento?.
Como no se puede establecer una conexión TCP, no se puede ejecutar el protocolo
SMTP.
La solución es que un agente de transferencia de mensajes en una máquina ISP,
acepte correo electrónico para sus clientes y lo almacene en sus buzones en la máquina
ISP. Como el agente puede estar en línea todo el tiempo, el correo electrónico puede
enviarse las 24 horas del día.
Para esto se creó el Protocolo de Oficina de Correos Versión 3 (POP3).
REDES
Figura 6.12: (a) Envío y recepción de correo cuando el receptor tiene una conexión
permanente a Internet y el agente de usuario se ejecuta en la misma máquina que el
agente de transferencia de mensajes. (b) Lectura de correo cuando el receptor tiene
una conexión de acceso telefónico a una ISP.
6.3.6. POP3
POP3 (Post Office Protocol, protocolo de oficina postal) está definido en RFC
1225. El POP3 tiene comandos para que un usuario establezca una sesión, la termine,
obtenga mensajes y los borre. El protocolo consiste en un texto ASCII que se asemeja
un poco al SMTP. El objetivo del POP3 es obtener correo electrónico del buzón remoto
y almacenarlo en la máquina local del usuario para su lectura principal.
De las posibilidades que el POP3 permite, los agentes suelen ofrecer:
Bajar todos los mensajes y borrarlos del servidor.
Bajar solo los mensajes no leídos y no borrar ninguno del servidor.
El inconveniente principal es que, si se ha recibido un mensaje largo, habrá que

esperar a que el agente lo traiga desde el buzón para poder ver siquiera de que trata.
Este es un problema de como los agentes usan el POP, no del protocolo en si mismo.
S: +OK POP3 server ready

C: USER carolyn
S: +OK
C: PASS vegetables
S: +OK login successful
C: LIST
S: 1 2505
S: 2 14302
S: 3 8122
S: .
C: RETR 1
S: (sends message 1)
C: DELE 1
C: RETR 2
C: DELE 2
C: RETR 3
C: DELE 3
C: QUIT
S: +OK POP3 server disconnecting
Figura 6.13: Uso de POP3 para obtener tres mensajes.
6.3.7. IMAP
IMAP (Interactive Mail Acess Protocol, protocolo interactivo de acceso de
correo) es un protocolo más refinado que POP3. El IMAP es mas potente y eficaz,
pero su uso es solo conveniente cuando el coste de la conexión no va en funcion del
tiempo y podemos estas leyendo los mensajes mientras estamos conectados. La gran
ventaja del IMAP es que los mensajes están siempre en el servidor.
Cuando el agente se conecta, obtiene la lista de las cabeceras de los mensajes y
las muestra al usuario. Este puede entonces ver asunto y remitente y, ello le permitirá
leer selectivamente los mensajes y no tener que esperar a traer mensajes largos.
El IMAP tiene otras muchas características. Puede mostrar los mensajes de llegada
en función de cualquier atributo. Por ejemplo, dame el primer mensaje de Marie. En
este enfoque, un buzón se parece mas a un sistema de base de datos relacional que a
una secuencia linea de mensajes.
Una herramienta especialmente valiosa para muchos usuarios de correo electrónico
es la capacidad de establecer filtros. Los filtros son reglas que se consultan cuando llega
el correo electrónico. Cada regla especifica una condición y una acción. Por ejemplo,
una regla podría decir que cualquier mensaje que llegue de tu amante debe presen-
tarse en rojo negrita parpadeante (o alternativamente descartarlo automáticamente
sin comentarios).
Otra facilidad importante de IMAP es que permite manejar multiples buzones
auxiliares en el mismo servidor. Esto es útil para el usuario que quiere clasificar los
mensajes que quiere guardar. De hecho, los agentes potentes permiten clasificar au-
tomáticamente los mensajes recibidos haciendo uso de los filtros.
Otra característica común en la capacidad de instalar un daemon de vacaciones.
REDES
Este es un programa que examina cada mensaje de entrada y envía al transmisor una
respuesta insípida que dice algo así como:
Hola, estoy de vacaciones. Regresaré el 7 de Enero. Tenga un bonito día.
La mayoría de los daemons de vacaciones mantienen un registro de a quienes se
enviaron respuestas prefabricadas y se abstienen de enviar a la misma persona una
segunda respuesta.
6.3.8. CARACTERÍSTICAS DE ENTREGA

Independientemente de si se usa POP3 o IMAP, muchos sistemas permiten es-
tablecer filtros a los correos electrónicos.
Estos filtros son reglas que se verifican cuando llega el correo electrónico o cuando
se inicia el agente de usuario. Cada regla especifica una condición y una acción.
Algunos ISP proporcionan un filtro que clasifica de manera automática el correo
electrónico como importante o como publicidad no deseada (correo basura) y almacena
cada mensaje en el buzón correspondiente.
Los filtros funcionan verificando primero si el origen es una spammer (persona
o entidad que envía correo basura) conocido. A continuación examinan la línea de
asunto. Si cientos de usuarios han recibido un mensaje con la misma línea de asunto,
probablemente sea correo basura.
Correo Web: Algunos sitios Web como Yahoo, Hotmail, etc., proporcionan ser-
vicio de correo, para esto tienen a agentes de transferencias normales que escuchan el
puerto 25 para conexiones SMTP entrantes. La salida es formateada como página Web
en HTML y el buzón reside en el servidor.
6.4. WORLD WIDE WEB

La World Wide Web (WWW) es un armazón arquitectónico para acceder a docu-
mentos vinculados distribuidos en miles de máquinas de toda Internet. En cinco años
pasó de ser una manera de distribuir datos sobre física de alta energía a la aplicación que
millones piensan que es Internet. Su enorme popularidad deriva del hecho de que tiene
una interfaz gráfica atractiva que es fácil de usar por los principiantes y proporciona
un enorme cúmulo de información sobre casi cualquier tema.
La Web (también conocida como WWW) comenzó en 1989 en el CERN, el Cen-
tro Europeo de Investigación Nuclear. El CERN tiene varios aceleradores en los que
los científicos de los países europeos participantes llevan a cabo investigaciones sobre
física de partículas. Estos equipos con frecuencia tienen miembros de media docena de
países o más. La mayoría de los experimentos son altamente complejos, y requieren
años de planeación adelantada y construcción de equipo. La Web surgió de la necesi-
dad de lograr que estos grandes grupos de investigadores dispersos internacionalmente
colaboraran usando un conjunto siempre cambiante de informes, planos, dibujos, fotos
214 6.4. WORLD WIDE WEB
y otros documentos.
La propuesta inicial de una red de documentos vinculados surgió del físico del
CERN Tim Berners-Lee en marzo de 1989. El primer prototipo (basado en texto). En
Diciembre de 1991 se hizo una demostración pública en la conferencia Hypertext’ 91
en San Antonio Texas.
Posteriormente Marc Andreessen de la Universidad de Illinois comenzó a desar-
rollar el primer navegador gráfico Mosaic, que fue tan popular que hizo que su dueño
montara su propia compañía, Netscape Communication Corp. cuya meta era desarrol-
lar clientes, servidores y software para Web.
6.4.1. EL LADO DEL CLIENTE

Desde el punto del usuario, la Web consiste en un enorme conjunto de documentos
a nivel mundial, llamados páginas Web. Cada página puede contener vínculos a otras
páginas relacionadas en cualquier lugar del mundo.
La idea de hacer que una página apunte a otra, lo que se conoce como hipertexto,
fue inventada por un profesor visionario de ingeniería eléctrica del MIT, Vannevar Bush
en 1945, mucho antes de que se inventara Internet.
Un Navegador es un programa que puede desplegar una página Web y atrapar los
clics que se hacen en los elementos presentes en la misma. Ej. IE, Netscape, Mozilla.
Cuando se selecciona un elemento que vincula a otra página (hipervínculo), el
navegador obtiene la página solicitada, interpreta el texto y los comandos de formateo
y la despliega, por tanto el hipervínculo necesita una manera de nombrar cada página
en la Web. Las páginas se nombran utilizando URLs (Localizadores Uniformes de
Recursos).
La URL tiene tres partes:
1. Nombre del protocolo (http).

2. DNS de la página donde se localiza la página web (www.uco.es).
3. Nombre de archivo que contiene la página Web (index.html).
Cuando se selecciona un hipervínculo (http://www.itu.org/home/index.html ) se

realiza una serie de pasos:
1. El navegador determina el URL (enviando lo seleccionado).

2. El navegador pide el DNS la dirección IP de www.itu.org.
3. DNS responde con 156.106.192.32.
4. El navegador realiza una conexión TCP con el puerto 80 de 156.106.192.32.
5. Después envía un mensaje en el que solicita el archivo /home/index.html. Se
libera la conexión TCP.
REDES
6. El navegador despliega todo el texto de /home/index.html.

7. El navegador obtiene y despliega todas las imágenes del archivo.
Los navegadores actuales tienen muchas facilidades para navegar, con botones
funcionales para retroceder, avanzar, actualizar, buscar, etc.
No todas las páginas contienen texto HTML estándar, pueden tener PDF, imá-
genes JPG, GIF, MP3 (Audio), MPEG (Video).
Puesto que las páginas HTML estándar pueden incluir los contenidos anteriores, el
navegador tiene un problema cuando encuentra una página que no puede interpretar.
En lugar de agrandar cada vez más los navegadores incorporándoles intérpretes
para una colección creciente de tipos de archivos, cuando un servidor devuelve una
página también devuelve alguna información adicional acerca de ella. Dicha información
incluye el tipo MIME de la página.
Si el tipo MIME no es de los integrados, el navegador consulta su tabla de tipos
MIME que le indica cómo desplegar la página. En esta tabla se asocia un tipo MIME
con un visor.
Figura 6.14: (a) Un plug-in de navegador. (b) Una aplicación auxiliar.
Hay dos posibilidades para interpretar:
1. Plug-in: Se instala en un directorio especial del disco y lo instala como extensión

del mismo. Ej. Plug-in de Flash.
2. Aplicación auxiliar: Programa completo que se ejecuta como un proceso in-
dependiente. No ofrece interfaz con el navegador y no utiliza los servicios de
éste. Muchas aplicaciones utilizan el tipo MIME aplicación y se han definido
varios subtipos: aplicación/pdf, aplicación/msword, aplicación/x-photoshop, au-
dio/mp3. . . .
6.4.2. EL LADO DEL SERVIDOR

Como ya vimos, cuando el usuario teclea una URL o hace clic en una línea de
hipertexto, el navegador lo analiza e interpreta la parte entre http:// y la siguiente
diagonal como un nombre DNS a buscar, identificando el servidor.
Figura 6.15: Las partes del modelo Web.
Los pasos que da el servidor en su ciclo principal son:
1. Acepta una conexión TCP de un cliente (un navegador).
2. Obtiene el nombre del archivo solicitado.
3. Obtiene el archivo (del disco).
4. Regresa el archivo al cliente.
5. Libera la conexión TCP.
Existen varios tipos de diseño para atender las conexiones:
1. Un disco, un proceso: Un disco SCSI de alta calidad tiene un tiempo de acceso

promedio de 5 mseg, lo que limita el servidor a 200 solicitudes/segundo.
2. Mejora sobre anterior: mantener una caché en la memoria de los archivos más
recientemente utilizados
3. Múltiples subprocesos y 1 disco: El servidor consiste en un módulo de front

end que acepta todas las solicitudes entrantes y k módulos de procesamiento.
Mientras unos procesos están accediendo a disco, otros trabajan en otras solici-
tudes. La velocidad puede ser k veces mayor.
REDES
Figura 6.16: Un servidor Web con múltiples subprocesos con un frontend y mó-
dulos de procesamiento.
4. Si llegan demasiadas solicitudes cada segundo, la CPU no será capaz de manejar

la carga de procesamiento, sin importar cuántos discos se pongan en paralelo.
La solución es agregar más nodos (computadoras) con discos replicados (Granja
de servidores). El frontend aún acepta múltiples solicitudes entrantes, pero las
distribuye en múltiples CPUs en lugar de múltiples subprocesos.
Figura 6.17: Granja de servidores.
6.4.3. URLs: LOCALIZADORES UNIFORMES DE RECUR-

SOS
Hemos dicho que las páginas de Webs pueden contener apuntadores a otras páginas
de Web. Veamos la implementación de estos apuntadores. Cuando se creó la Web, de
inmediato fue evidente para lograr que una página Web apuntara a otra se requerían
mecanismos para nombrar y localizar las páginas. En particular, había tres preguntas
que debían contestarse antes de poder presentar visualmente una páguina:
1. ¿Cómo se llama la página?
2. ¿Dónde está la página?
3. ¿Cómo se puede acceder a la página?
La solución escogida identifica las páginas de una manera que resuelve los tres
problemas a la vez. A cada página se le asigna un URL (Uniform Resource Locator,
localizador uniforme de recursos) que sirve efectivamente como nombre mundial
de la página. Los URL tienen tres partes:
1. Protocolo o también llamado esquema.
2. DNS de la máquina en que se encuentra la página.
3. Nombre local que indica de manera única la página específica.
Veamos ahora como funciona el hipertexto. Al seleccionarse el texto, el navegador

busca el nombre del host usando DNS, ya con la IP del servidor establece una conexión
TCP con el host y envía por esa conexión el nombre del archivo usando protocolo el
protocolo especificado.
Este esquema de URL es abierto en el sentido de que es posible hacer que los nave-
gadores utilicen múltiples protocolos para obtener diferentes recursos. En la siguiente
figura se listan formas ligeramente simplificadas de los más comunes:
Nombre Usado para Ejemplo

http Es el lenguaje nativo de la Web, el que hablan http://www.uco.es
los servidores web
ftp Se usa para acceder a archivos mediante ftp://ftp.eru.es
FTP, protocolo de transferencia de archivos
de Internet. Descarga archivos
File Para acceder a un archivo de forma local file://usr/prog/p.c
News 30.000 grupo de noticias USENET, en los que news:comp.os.minix
se discuten una varidad de temas
News Puede utilizarse para llamar a un artículo de news:AA0123456@cs.uta.edu
noticias como si fuera página web
mailto Permite a los usuarios enviar correo desde un mailto:i23mogab@uco.es
navegador web, el navegador abre gestor de
correo
telnet Establecer una conexión en línea con una telnet://www.w3.org:80
máquina remota
Figura 6.18: Algunas URLs comunes.
En resumen, los URL se han diseñado no sólo para permitir a los usuarios navegar
por la web sino también para entenderse con FTP, noticias, Gopher, correo electrónico
REDES
y Telnet, haciendo innecesarios los programas especializados de interfaz de usuario para

estos otros servicios, e integrando por tanto casi todos los accesos a Internet en un solo
programa, el visualizador de la Web.
A pesar de todas estas agradables propiedades, el uso creciente de la Web ha
sacado a la luz una debilidad inherente del esquema URL. Un URL apunta a un host
específico. En caso de páginas a las que se hace referencia constante, sería deseable tener
varias copias muy distantes para reducir el tráfico de lard. El problema es que los URL
no proporcionan ninguna manera de referirse a una página sin decir simultáneamente
dónde está. Para resolver este problema y hacer posible la duplicación de páginas, el
IETF está trabajando en un sistema de identificadores universales de recursos,
o URI (Universal Resource Identifiers). Un URI podría considerarse como un URL
generalizado.
HTTP: PROTOCOLO DE TRANSFERENCIA DE HIPERTEXTO
El protocolo estándar de transferencia de la Web es HTTP (HyperText Trans-

fer Protocol, protocolo de transferencia de hipertexto). En HTTP no existe el
concepto de inicio de sesión. El navegador envía una solicitud a un servidor y obtiene
un archivo. Cada interacción consiste en una solicitud ASCII seguida de una respues-
ta tipo MIME RFC 822. Aunque es muy común el uso del TCP para la conexión de
transporte, no es requerido formalmente por el estándar.
COOKIES
Para que los servidores puedan guardar información relativa a gustos, preferencias,
patrones de navegación del usuario, personalización de sitios Web, los usuarios pueden
establecer una página de inicio detallada que contenga sólo la información que desea.
Para resolver este problema Netscape diseñó una técnica muy criticada llamada
cookies. Las cookies se personalizaron en RFC 2109. Cuando un cliente solicita una
página Web, el servidor puede proporcionar información adicional junto con la página
solicitada. Esta información puede incluir una cookie que es un pequeño archivo (como
mucho 4KB).
Los navegadores almacenan las cookies en un directorio de cookies en el disco
duro de la máquina del cliente, a menos que el usuario las deshabilite. Los cookies son
simplemente archivos, no ejecutables.
Campos de las cookies:
1. Dominio: indica de dónde viene la cookie.

2. Ruta: es la ruta en la estructura del directorio del servidor que identifican qué
partes del árbol de archivos del servidor pueden utilizar la cookie.
3. Contenido: toma la forma nombre=valor, es donde se almacena el contenido de
la cookie. El servidor escribe lo que desee.
4. Expira: especifica cúando caduca la cookie. Si este campo está ausente. Para
eliminar una cookie del disco duro del cliente, el servidor la envía nuevamente
con la fecha caducada.
5. Seguro: para indicar que el navegador puede devolver la cookie a un servidor

seguro. Para comercio electrónico, actividades bancarias, etc
Justo antes de que un navegador solicite una página a un sitio Web, verifica su
directorio de cookies para ver si el dominio al cual está solicitando la página ya colocó
alguna cookie. De ser así todas las cookies colocadas por ese dominio se incluyen en el
mensaje de solicitud. Cuando el servidor las obtiene puede interpretarlas en la forma
que desee.
Los usuarios pueden configurar su navegador para que rechacen las cookies, ó
instalan programas que aceptan o rechazan las cookies en dependencia del sitio del que
provenga.
6.4.4. DOCUMENTOS WEB ESTÁTICOS.

La base de la Web es la transferencia de páginas Web desde el servidor al cliente.
En la forma más simple, las páginas Web son estáticas, o sea son simplemente
archivos que se encuentran en algún lugar del servidor esperando a ser recuperados.
En este sentido, incluso un video es una página web estática porque es sólo un
archivo.
HTML- Lenguaje de Marcado de Hipertexto
Las páginas Web estáticas se escriben en lenguaje llamado HTML es una aplicación
del estándar ISO 8879, SGML (Standar Generalized Markup Language, lenguaje de
marcación estándar genralizado), pero especializado en hipertexto y adaptado a
la Web. HTML es un lenguaje de marcado que sirve para describir como se formatea
un documento a través de etiquetas predefinidas.
Al integrar los comandos de marcación dentro de cada archivo HTML y estandarizar-
los, se hace posible que cualquier visualizador de la Web lea y reformatee cualquier
página Web.
Ejemplo de página web HTML:
<HTML> <HEAD> <TITLE> AMALGAMATED WIDGET, INC. </TITLE> </HEAD>

<BODY> <H1> Welcome to AWI’s Home Page </H1>
<IMG SRC="http://www.widget.com/images/logo.gif" ALT="AWI Logo"> <BR>
We are so happy that you have chosen to visit <B> Amalgamated Widget’s</B>
home page. We hope <I> you </I> will find all the information you need here.
<P>Below we have links to information about our many fine products.
REDES
You can order electronically (by WWW), by telephone, or by fax. <HR>

<H2> Product information </H2>
<UL> <LI> <A HREF="http://widget.com/products/big"> Big widgets </A>
<LI> <A HREF="http://widget.com/products/little"> Little widgets </A>
</UL>
<H2> Telephone numbers </H2>
<UL> <LI> By telephone: 1-800-WIDGETS
<LI> By fax: 1-415-765-4321
</UL> </BODY> </HTML>
Figura 6.19: HTML para una página Web de ejemplo.
Welcome to AWI's Home Page
We are so happy that you have chosen to visit Amalgamated Widget's home page. We hope
you will find all the information you need here.
Below we have links to information about our many fine products. You can order electronically
(by WWW), by telephone, or by FAX.
Product Information
l Big widgets
l Little widgets
Telephone numbers
l 1-800-WIDGETS
l 1-415-765-4321
Figura 6.20: Página con formato.
Las etiquetas más comunes de HTML son las siguientes:

Etiqueta Descripción
<html>... </html> Declara que la página Web está descrita en HTML
<head>... </head> Delimita el encabezado de la página
<title>... </title> Delimita el título (no se presenta en la página)
<body>... </body> Delimita el cuerpo de la página
<hn>... </hn> Delimita un encabezado de nivel n
<b>... </b> Pone en negritas
<i>... </i> Pone en cursivas
<center>... </center> Centra ... en la página horizontalmente
<ul>... </ul> Corchetes de una lista desordenada (con viñetas)
<li>... </li> Corchetes de un elemento de una lista ordenada o numerada
<br> Obliga salto de línea aquí
<p> Inicia un párrafo
<hr> Inserta una regla horizontal
<img src=“p.jpg”> Carga una imagen aquí
<a href=“...”></a> Define un hipervínculo
Figura 6.21: Selección de etiquetas HTML comunes.
XML Y XSL
HTML con o sin formularios, no proporciona estructura alguna para las páginas
Web. Además mezcla el contenido con el formato. Conforme el comercio electrónico y
otras aplicaciones se vuelven más comunes hay una necesidad cada vez mayor de dar
estructura a las páginas Web y separar el contenido del formato.
Por esta razón el W3C ha mejorado HTML, para permitir que las páginas Web ten-
gan estructura bien formada para su procesamiento automatizado. Se han desarrollado
2 nuevos lenguajes:
1. XML (Lenguaje de Marcado Extensible), que describe el contenido Web de forma

estructurada.
2. XSL (Lenguaje de Hojas de Estilo Extensible) que describe el formato indepen-

dientemente del contenido.
Ejemplo de página Web usando XML y XSL
A continuación se muestra una página web simple usando XML:
<?xml version="1.0" ?>

<?xml-stylesheet type="text/xsl" href="book_list.xsl"?>
<book_list>
<book>
<title> Computer Networks, 4/e </title>
REDES
<author> Andrew S. Tanenbaum </author>

<year> 2003 </year>
</book>
<book>
<title> Modern Operating Systems, 2/e </title>
<year> 2001 </year>
</book>
<book>
<title> Structured Computer Organization, 4/e </title>
<year> 1999 </year>
</book>
</book_list>
Figura 6.22: Página Web simple en XML.
Todo lo que hace el archivo es definir una lista de libros, que contiene tres libros.
No dice nada de cómo desplegar la página Web.
Para proporcionar información de formato necesitamos un segundo archivo. Es el
archivo de transformación XSL. Veamos un ejemplo de transformación XSL para el
ejemplo anterior:
<?xml version=’1.0’?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:template match="/">
<html>
<body>
<table border="2">
<tr>
<th> Title</th>
<th> Author</th>
<th> Year </th>
</tr>
<xsl:for-each select="book_list/book">
<tr>
<td> <xsl:value-of select="title"/> </td>
<td> <xsl:value-of select="author"/> </td>
<td> <xsl:value-of select="year"/> </td>
</tr>
</xsl:for-each>
</table>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Figura 6.23: Una hoja de estilo XSL.
Este archivo es una hoja de estilo que indica cómo desplegar la página.
Además de describir páginas Web, XML sirve para otros propósitos. Por ejemplo
se puede utilizar como lenguaje de comunicación entre programas de aplicación.
En particular SOAP (Protocolo Simple de Acceso a Objetos) es una forma
de hacer RPCs entre aplicaciones de una forma independiente del lenguaje y de la
aplicación.
En SOAP el cliente construye la solicitud como un mensaje XML y lo envía al
servidor, utilizando HTTP. El servidor envía una respuesta otro mensaje XML pudi-
endo comunicarse aplicaciones heterogéneas.
XHTML
HTML sigue evolucionando para satisfacer las nuevas demandas, en el futuro la

mayoría de los dispositivos habilitados para Web no sean PC, sino PDAs inalámbricos.
Estos dispositivos tienen memoria limitada para navegadores grandes y que lidian con
las web no correctos sintácticamente.
De ahí que se ha especificado XHTML (Lenguaje de Marcado de Hipertexto Ex-
tendido) es HTML 4.0 reformulado en XML.
Veamos algunas de las características de XHTML respecto a HTML:
1. Las páginas XHTML y los navegadores deben seguir estrictamente el estándar.

Si una página es de mala calidad se debe señalar no corregir.
2. Todas las etiquetas y los atributos deben estar en minúsculas <HTML>por

<html>.
3. Se requiere siempre el uso de etiquetas de cierre incluso para <p>, <br>, <hr>,
<img>.
4. Todos los atributos deben estar entre comillas, incluso los números <img src=“p.jpg"
height=“500"/>
Las etiquetas deben estar anidadas de manera apropiada.
REDES
6.4.5. DOCUMENTOS WEB DINÁMICOS
Hasta ahora el modelo que hemos utilizado es el cliente envía un nombre de archivo
al servidor, el cual regresa el archivo. Este era el modelo imperante en los primeros días
de la Web.
En los años más recientes, cada vez más el contenido es dinámico, es decir se genera
a solicitud, en lugar de almacenarlo en disco.
La generación del contenido puede suceder ya sea en el servidor o en el cliente.
DOCUMENTOS WEB DINÁMICOS EN EL SERVIDOR
Los pasos que sigue el procesado de un documento en el servidor son los siguientes:
Figura 6.24: Pasos en el procesamiento de información de un formulario HTML.
Una de las formas de crear documentos html dinámicos en el servidor es haciendo

uso de PHP.
Figura 6.25: (a) Una página Web que contiene un formulario. (b) Un script en PHP
para manejar la salida del formulario (c) Salida de la secuencia de comandos PHP
cuando las entradas son “Barbara" y 24.
DOCUMENTOS WEB DINÁMICOS EN EL CLIENTE
Para procesar documentos dinámicos en el cliente una de las opciones más uti-
lizadas es JavaScript.
Figura 6.26: Uso de JavaScript para procesar un formulario.
REDES
Ejemplos de uso de JavaScript:
Figura 6.27: Un programa en JavaScript para calcular e imprimir factoriales.
Figura 6.28: Una página Web interactiva que responde al movimiento del ratón.
Las diversas formas de generar y desplegar contenido:
Figura 6.29: Las diversas formas de generar y desplegar contenido.
6.4.6. HTTP: PROTOCOLO DE TRANSFERENCIA DE HIPER-

TEXTO
El protocolo de transferencia utilizado en la World Wide Web es HTTP. Este
protocolo especifica cuáles mensajes pueden enviar los clientes a los servidores y qué
respuestas obtienen. Utiliza el puerto 80.
Cada interacción consiste en una solicitud ASCII, seguida por una respuesta tipo
MIME RFC 822. Todos los clientes y servidores deben obedecer este protocolo definido
en RFC 2616.
HTTP 1.1 soporta conexiones persistentes, con ellas es posible establecer una
conexión TCP, enviar una solicitud y obtener una respuesta y después enviar solicitudes
adicionales evitando la sobrecarga de TCP por solicitud.
MÉTODOS HTTP
Método Descripción
GET Solicita al servidor la lectura de una página Web
HEAD Solicita la lectura del encabezado de una página Web
PUT Solicita el almacenamiento de una página Web en un servidor remo-
to. El cuerpo de la solicitud contiene la página, que puede contener
encabezados MIME
POST Igual que PUT, pero los datos se insertan en un formato específico.
Enviar un mensaje a un grupo de noticias
DELETE Elimina la página Web
TRACE Para depuración. Indica al servidor que regrese la solicitud
CONNECT Reservado para uso futuro
OPTIONS Consulta ciertas opciones
Figura 6.30: Los métodos de solicitud HTTP integrados.
REDES
6.4.7. MEJORAS EN EL DESEMPEÑO

La popularidad de la Web ha sido casi su destrucción. Los servidores, enrutadores
y las líneas con frecuencia están sobrecargados.
Como consecuencia de los retardos, los investigadores han desarrollado varias téc-
nicas para mejorar el desempeño de la WWW:
1. Almacenamiento en caché.
2. Replicación del servidor.
3. Redes de entrega de contenido.
ALMACENAMIENTO EN CACHÉ
Se basa en guardar las páginas que han sido solicitadas, en caso de que se utilicen
nuevamente, especialmente con páginas que se visitan mucho.
El procedimiento común es que algún proceso, llamado proxy mantenga la caché.
Un navegador puede configurarse para que todas las solicitudes de las páginas se la
hagan a un proxy en lugar de al servidor real de la página.
El almacenamiento en caché lo puede hacer el PC individual para buscar con
rapidez la página. En una LAN el proxy es una máquina compartida por todas las
máquinas de la LAN.
Figura 6.31: Almacenamiento en caché jerárquico con tres proxies.
REPLICACIÓN DEL SERVIDOR
El método más común que los servidores utilizan para mejorar el desempeño es
replicar su contenido en múltiples ubicaciones separadas considerablemente.
Esta técnica se conoce a veces como espejo
La página principal de la empresa, puede tener varios hipervínculos en dependencia
de la región del usuario, seleccionado este el más cercano.
Los sitios espejos por lo general son estáticos, no tiene en cuenta una aglomeración
instantánea, Ej las elecciones en Florida.
La replicación debe ser dinámica en función del incremento de tráfico.
REDES DE ENTREGA DEL CONTENIDO
Actualmente muchas empresas llamadas CDNs (Redes de Entrega de Contenidos)

hablan con proveedores de contenido (sitios de música, periódicos, y otros que desean
que sus contenidos estén disponibles de forma rápida y fácil) y le ofrecen entregar sus
contenidos al usuario a cambio de una cuota.
A continuación el CDN habla con una gran cantidad de ISP y ofrece pagarles bien
a cambio de que le permitan colocar en sus LANs un servidor manejado de manera
remota lleno de contenido valioso. Como consecuencia, las CDNs más grandes tienen
más de 10.000 servidores distribuidos por todo el mundo.
Debe haber una forma para redirigir la solicitud del cliente al servidor más cercano.
La CDN transforma el contenido de la página web del proveedor de contenidos a través
de un pre-procesador que modifica las URLs.
Figura 6.32: Pasos de la búsqueda de una URL cuando se utiliza una CDN.
CDN-server no alberga el contenido, es un servidor HTTP falso, que examina el

nombre del archivo y del servidor, IP de la solicitud para buscar en su base de datos
el servidor CDN más cercano.
6.4.8. LA WEB INALÁMBRICA

Cada vez más crece el interés por que los dispositivos pequeños portables sean
capaces de acceder a la Web a través de un enlace inalámbrico.
Los principales sistemas web inalámbricos son:
1. WAP: Protocolo de Aplicaciones Inalámbricas.
REDES
2. i-mode: Usado en Japón.
En la medida que se volvieron comunes Internet y telefonía móvil surge la idea

de unirlos, para lograr esto se creó un consorcio que inicialmente estaba formado por
Nokia, Ericsson y Motorola y le llamaron a esa especificación WAP.
WAP
WAP (Wireless Application Protocol, protocolo de aplicaciones inalámbricas)

es un estándar abierto internacional para aplicaciones que utilizan las comunicaciones
inalámbricas.
La idea básica de WAP es utilizar la infraestructura inalámbrica existente, que los
usuarios pueden llamar a una puerta de enlace WAP a través del enlace inalámbrico y
enviarle solicitudes de páginas Web.
La puerta de enlace verifica si la página está en su caché, si la tiene la envía, si no
la obtiene a través de la Internet alámbrica.
En esencia WAP 1.0 es un sistema de conmutación de circuitos con cargo de
conexión por minuto relativamente alto.
WAP 1.0 no utiliza HTML, un dispositivo WAP sólo puede acceder a páginas
previa traducción.
La pila de protocolos WAP:
Figura 6.33: La pila de protocolos WAP.
La capa inferior soporta todos los sistemas existentes de teléfonos móviles: GSM,
D-AMPS, CDMA. La tasa de datos es de 9600 bps.
Encima se encuentra WDP que es esencialmente UDP.
A continuación hay una capa de Seguridad.

Más arriba la capa de transacciones WTP, la cual maneja de manera confiable o

no confiable las solicitudes y respuestas. Reemplaza a TCP.
Capa de sesión y de aplicación WAP con un micronavegador que entiende WML
(Lenguaje de Marcado Inalámbrico) que es una aplicación de XML.
Figura 6.34: Arquitectura WAP
WAP 2.0: SEGUNDA GENERACIÓN WAP
La nueva versión de WAP, WAP 2.0, es una reingeniería de WAP que utiliza XML.
Algunos observadores predicen que esta próxima generación de WAP utilizando
XML convergirá con, y será reemplazada por, un verdadero acceso web para los dis-
positivos de bolsillo. Un subconjunto del lenguaje XHTML, el denominado XHTML
Basic, esta hecho para trabajar en dispositivos portátiles.
Nuevas características de WAP 2.0
Modelo push (de actualización automática, arribo de datos sin que se le solicite,
bolsa) y modelo pull (de recepción automática, el cliente solicita una página y la
obtiene).
Soporte para integrar la telefonía en las aplicaciones (voz y datos juntos)
Mensajería multimedia.
Inclusión de 264 pictogramas (iconos representación de animales, plantas, de-
portes).
Interacción con un dispositivo de almacenamiento (ROM, para almacenamiento
temporal de imágenes y datos).
Soporte en el navegador para plug-ins.
REDES
También existen una serie de diferencias técnicas respecto a WAP 1.0:
WAP 2.0 continúa aceptando la antigua pila de protocolos de WAP 1.0, pero
también soporta la pila estándar de Internet con TCP y HTTP/1.1.
Figura 6.35: WAP 2.0 soporta dos pilas de protocolos.
Se hicieron algunos cambios para simplificar código TCP:
1. Uso de una ventana fija de 64 KB.

2. Inicio rápido.
3. Una MTU de 1500 bytes.
4. Un protocolo de seguridad TLS de la capa de transporte.
Otra diferencia técnica con WAP 1.0 es el lenguaje de marcado: WAP 2.0 so-
porta XHTML Basic, que está diseñado para dispositivos inalámbricos pequeños.
XHTML Basic no soporta hojas de estilo, secuencias de comando, pero sí soporta
la mayoría etiquetas estándar.
A pesar del acuerdo de uso de XHTML Basic, una amenaza asecha a WAP e
I-mode: 802.11 (wifi).
Se supone que WAP 2.0 llega a 384 kbps, una velocidad mucho mayor que 9600
bps de Wap 1.0 pero lejos de los 54 Mbps ofrecidos por 802.11
Por supuesto, 802.11 no está en todos lados, pero conforme más restaurantes, hote-
les, tiendas, empresas, aeropuertos, estaciones de autobús, museos, universidades, hos-
pitales y organizaciones decidan instalar estaciones-base para sus empleados y clientes,
tal vez haya más cobertura wi-fi en las áreas urbanas.
En las rurales, donde el rango de cientos de metros es limitado, se podría pensar
en dispositivos dual, que utilicen wifi si pueden captar una señal y en caso contrario
regresar a WAP.
REDES
INTERCONEXIÓN DE REDES
Existen muchas redes distintas que incluyen LAN, WAN y MAN.

De cada capa hay numerosos prototipos de uso muy difundido.
Cuando se juntan dos o más redes se forma una interred.
Tener muchas redes implica tener distintos protocolos:
Las que siguen modelo OSI.
Las que tienen un modelo propio.
Las redes pueden interconectarse mediante diversos dispositivos.
Interconexión a nivel físico
En la capa física, las redes se pueden conectar mediante repetidores o concen-

tradores, los cuales mueven los bits de una red a otra idéntica.
Interconexión a nivel de capa enlace
En la capa de enlace de datos encontramos los puentes y conmutadores. Estos

pueden aceptar tramas, examinar las direcciones MAC y reenviar las tramas a una red
diferente mientras realizan una traducción menor de protocolos en el proceso: Ej. De
Ethernet a FDDI o a 802.11.
235
236
Interconexión a nivel de capa red
En la capa de red hay enrutadores que pueden conectar dos redes. Si éstas tienen
capas de red diferentes, el enrutador puede tener la capacidad de traducir entre los
formatos de paquetes.
Un enrutador que puede manejar múltiples protocolos se conoce como enrutador
multiprotocolo.
Interconexión a nivel de capa de transporte
En la capa de transporte se encuentran las puertas de enlace de transporte, que

pueden interactuar entre dos conexiones de transporte. Ej, paquetes entre TCP-SNA.
Interconexión a nivel de capa de aplicación
En la capa de aplicación, las puertas de enlace de aplicación traducen semánticas

de mensajes. Ej. Correo electrónico internet (RFC 822) y correo X.400, cambiando
varios campos de encabezado.
Figura 7.1: Dos Ethernet conectadas. (a) Usando un switch. (b) Usando un router.
En la figura la máquina de origen S, desea enviar un paquete a D y se encuentran

en Ethernet diferentes a través de un conmutador. S encapsula el paquete en una trama,
la cual llega al conmutador que ve la dirección MAC y la coloca en la LAN 2.
La misma situación pero con las dos Ethernet conectadas mediante un par de
enrutadores. Los enrutadores se conectan mediante una línea punto a punto (kms). El
enrutador recoge la trama y el paquete se extrae de la trama.
El enrutador examina la dirección del paquete (por ejemplo IP) y la busca en su
tabla de enrutamiento. Con base en esta dirección, decide enviar el paquete al enrutador
remoto, encapsulado en un tipo diferente de trama, dependiendo del protocolo de línea.
En el otro extremo el paquete se coloca en el campo de datos de una trama Ethernet
y se deposita en otra la LAN.
REDES
Con un conmutador o puente la trama se transporta con base en su dirección

MAC.
Con un enrutador, el paquete se extrae de la trama y la dirección del paquete se
utiliza para decidir dónde enviarlo.
7.1. CIRCUITOS VIRTUALES CONCATENADOS

Se establece una conexión con un host de una red distante. La subred ve que
el destino es remoto y construye un circuito virtual de ese enrutador a un enrutador
multiprotocolo (puerta de enlace externa). Esta registra la existencia del circuito virtual
en sus tablas y procede a construir un circuito virtual a otro enrutador de la subred
hasta llegar al host destino.
Figura 7.2: Circuitos virtuales concatenados.
Una vez que comienzan a fluir paquetes, cada puerta de enlace reconstruye los pa-
quetes de entrada y hace las conversiones entre los formatos de paquetes, manteniendo
tabla con CV que pasan ella.
7.2. ENTUNELAMIENTO
El manejo del caso general de lograr la interacción de dos redes diferentes es en
extremo difícil, sin embargo hay un caso común que puede manejarse.
El caso es cuando el host de origen y destino están en la misma clase de red, pero
hay una red diferente en medio. El LAN Ethernet en París, y otra en Londres y en
medio una WAN no IP (por ejemplo ATM).
238 7.2. ENTUNELAMIENTO
La solución a este problema es una técnica llamada entunelamiento, mediante la

cual el host de París, construye el paquete con la IP del host de Londres, lo inserta
en una trama Ethernet y lo dirige al enrutador multiprotocolo de París. Cuando el
enrutador recibe la trama, retira el paquete IP, lo inserta en el campo de carga útil del
paquete de capa de red de la WAN y dirige este último al enrutador multiprotocolo de
Londres, que hace el proceso inverso que el de París.
Figura 7.3: Entunelamiento.
La WAN puede visualizarse como un gran túnel que se extiende de un enrutador

multiprotocolo a otro.
El paquete IP simplemente viaja de un extremo del túnel a otro, bien acomodado
en una caja bonita. No tiene que preocuparse por lidiar con la WAN.
Figura 7.4: Ejemplo ilustrativo de entunelamiento.
Sólo el enrutador multiprotocolo tiene que entender los paquetes IP y WAN.
7.2.1. ENTUNELAMIENTO ENTRE REDES

Las cinco redes están conectadas mediante seis enrutadores posiblemente multi-
protocolo.
REDES
Una vez construido el grafo de la subred pueden aplicarse algoritmos de en-

rutamiento conocidos como vector distancia o estado del enlace al grupo de enrutadores
multiprotocolo.
Figura 7.5: (a) Redes interconectadas. (b) Grafo equivalente.
Esto es lo que vimos como Protocolos de Puerta de enlace Interior (IGP) en cada
red, y entre ellas se utiliza un Protocolo de Puerta de Enlace Exterior (EGP).
Un paquete de interred típico parte de su LAN hacia el enrutador multiprotocolo
local.
Al llegar ahí, el código de la capa de red decide por cuál enrutador multiprotocolo
reenviará el paquete, usando sus propias tablas de enrutamiento.
Si ese enrutador puede alcanzarse usando el protocolo de red nativa del paquete,
éste se reenvía directamente ahí, de otra manera se envía por túnel, encapsulado en
el protocolo requerido por la red que interviene. Este proceso se repite hasta que el
paquete llega a la red de destino.
7.3. FRAGMENTACIÓN
Cada red impone un tamaño máximo a sus paquetes, por diferentes razones:
El hardware (Ej. Tamaño de una trama Ethernet).

El sistema operativo (tamaño de búfer).
Los protocolos.
El cumplimiento de algún estándar internacional.
El deseo de evitar que un paquete ocupe el canal demasiado tiempo.
El resultado es que los diseñadores de redes no están en libertad de escoger

cualquier tamaño máximo de paquete, que van de 40 bytes de celdas ATM hasta 64K
de paquetes IP.
240 7.3. FRAGMENTACIÓN
Surge un problema obvio cuando un paquete grande quiere viajar a través de una
red cuyo tamaño máximo de paquete es demasiado pequeño.
Una solución es asegurar que esto no ocurra, la interred debe usar un algoritmo de
enrutamiento que evite el envío de paquetes a través de redes que no pueden manejarlos.
La única solución al problema es permitir que las puertas de enlace dividan los
paquetes en fragmentos, enviando cada paquete como paquete de interred individual.
Existen dos estrategias:
1. Fragmentación transparente: Cuando un paquete de tamaño excesivo llega

a una puerta de enlace, ésta la divide en fragmentos, los cuales se redirigen a la
puerta de enlace de salida, donde se recombina las piezas.
2. Fragmentación a través de las puertas de enlace: La recombinación ocurre

en el destino (IP).
Figura 7.6: (a) Fragmentación transparente. (b) Fragmentación a través de las puertas
de enlace.
Cuando se divide un paquete, los fragmentos deben numerarse de tal manera que
el flujo de datos original pueda reconstruirse.
Una manera de numerar los fragmentos es usar un árbol. Si el paquete 0 debe
dividirse, se llama a las partes 0.0, 0.1, 0.2, etc. Y si éstos deben renumerarse después
sería 0.0.0, 0.0.1, 0.0.2. . .
Sin embargo si la red pierde o descarta paquetes, hay necesidad de retransmisiones
de extremo a extremo. Ej paquete de 1024 bytes se fragmenta en 4 fragmentos del mismo
tamaño. Se pierde el fragmento 0.1, y las otras llegan al destino. En algún momento
termina el temporizador de origen y se vuelve a retransmitir el paquete original pero
REDES
la ruta pasa a través de una red de 512 bits, por lo que se generan dos fragmentos,
cuando llega 0.1 receptor cree recibió el fragmento correcto.
La solución es definir un tamaño de fragmento elemental que pueda pasar a través
de todas las redes.
Figura 7.7: Fragmentación cuando el tamaño de datos elemental es de 1 byte. (a)

Paquete original con 10 bytes de datos. (b) Fragmentos tras pasar a través de una red
con un tamaño mñaximo de 8 bytes de carga útil más encabezado. (c) Fragmentos tras
pasar a través de una puerta de enlace de tamaño cinco.
7.4. REDES ORIENTADAS A CONEXIÓN. RED X.25

La red X.25 fue la red de datos pública. Se desplegó en la década de 1970 , cuando
el servicio telefónico era un monopolio en cada país y se pensaba en instalar una red
de datos propia.
Para utilizar X.25 una computadora establecía primero una conexión con la com-
putadora remota a través de una llamada telefónica.
La conexión daba un número de conexión para utilizar en los paquetes de trans-
ferencias de datos.
Los paquetes de datos eran muy sencillos, consistían de un encabezado de 3 bytes
y hasta 128 bytes de datos. El encabezado constaba de un número de conexión de 12
bits, un número de secuencia de paquete y un número de confirmación de recepción.
Las redes X.25 funcionaron durante casi diez años.
242 7.5. REDES DE TRANSMISIÓN DE TRAMAS
7.5. REDES DE TRANSMISIÓN DE TRAMAS

En la década de 1980, las redes X.25 empezaron a reemplazarse por un nuevo tipo
de red digital llamada Frame Relay (retransmisión de tramas).
Frame Relay es una red orientada a la conexión sin controles de error, ni de flujo
en las que si se detecta un error se descarta la trama. Al no confirmarse la trama la
sobrecarga de la red es muy baja.
Permite dos modos de trabajo:
1. Circuito permanente: no hay que iniciar conexión.
2. Conmutación de circuitos.
Las propiedades de entrega en orden, sin control de errores ni de flujo hicieron que
el Frame Relay tuviese su aplicación más importante en la interconexión de LANs en
múltiples oficinas de una empresa o para interconectar redes locales remotas.
Disfrutó de un éxito modesto y aún se sigue utilizando en algunas partes.
7.6. RED ATM. MODO DE TRANSFERENCIA ASÍN-

CRONO
Es el tipo de red orientada a la conexión más utilizado y el más importante. La
razón de este nombre se debe a que en el sistema telefónico la mayor parte de la
transmisión es síncrona (reloj) y en ATM no sucede así.
ATM se diseñó a a principios de la década de 1990 y se lanzó en medio de una
increíble exageración: ATM iba a resolver todos los problemas de conectividad y teleco-
municaciones en un solo sistema integrado que pudiera proporcionar todos los servicios
para todas las necesidades.
Pero esto no fue así, debido a la aparición inoportuna del modelo OSI, con una
tecnología, implementación y políticas equivocadas. Incluso los intransigentes fanáticos
de los datagramas se dieron cuenta que la calidad del servicio dejaba mucho que desear.
Por ello ATM tuvo mucha mejor suerte que OSI y actualmente tiene un uso profundo
dentro del sistema telefónico.
7.6.1. CIRCUITOS VIRTUALES ATM

Puesto que las redes ATM son orientadas a la conexión, el envío de datos requiere
que primero se envíe un paquete para establecer la conexión.
Conforme el mensaje de establecimiento sigue su camino a través de la red, todos
los conmutadores que se encuentra en la ruta, anotan en sus tablas internas la existencia
de la conexión, reservando cualquier recurso que necesite.
REDES
A las conexiones se les conoce como circuitos virtuales en analogía a los circuitos
físicos del sistema telefónico.
Figura 7.8: Ejemplo de circuito virtual.
La mayoría de las redes ATM soportan también circuitos virtuales permanentes,

que son conexiones permanentes entre dos hosts distantes (similares a las líneas alquiladas
del sistema telefónico).
Cada conexión, sea temporal o permanente tiene un identificador de conexión y
una vez establecida cada lado puede empezar a transmitir datos.
La idea básica en que se fundamenta ATM es transmitir toda la información en
paquetes pequeños, de tamaño fijo llamados celdas.
7.6.2. CELDAS ATM
Figura 7.9: Celda ATM.
Las celdas tienen un tamaño fijo de 53 bytes, de los cuales 5 son del encabezado y
48 de la carga útil.
Parte del encabezado es el identificador de la conexión, por lo que los hosts emisor
y receptor y todos los conmutadores intermedios pueden saber qué celdas pertenecen
a qué conexiones.
La conmutación de celdas se hace en el hardware, a alta velocidad, el hecho de que
sean celdas de tamaño fijo facilita construcción de los conmutadores.
Los paquetes de IP se enrutan mediante software.
244 7.6. RED ATM. MODO DE TRANSFERENCIA ASÍNCRONO
El hardware de ATM se puede configurar para enviar una celda entrante a múltiples
líneas de salida, una propiedad necesaria para difundir programas de televisión a varios
receptores.
El hardware de ATM se puede configurar para enviar una celda entrante a múltiples
líneas de salida, una propiedad necesaria para difundir programas de televisión a varios
receptores.
Todas las celdas siguen la misma ruta al destino. La entrega de celdas no está
garantizada, pero el orden sí. A los niveles más altos del protocolo le corresponde la
recuperación de las celdas perdidas.
Las redes ATM se organizan como las WANs tradicionales, con líneas y conmuta-
dores (enrutadores). Las velocidades más comunes para ATM son de 155 (compatibil-
idad SONET) y 622 Mbps (4 canales 155).
7.6.3. MODELO DE REFERENCIA ATM
ATM tiene su propio modelo de referencia, el cual es diferente de OSI y de TCP/IP.

Consta de 3 capas:
1. Capa física: especifica voltajes, temporización de bits, especificando que las

celdas ATM, se pueden enviar tal cual por cable o fibra o incluso empacar dentro
de la carga útil de otros sistemas de transporte. ATM se ha diseñado para ser
independiente del medio de transmisión.
2. Capa ATM: Se encarga de las celdas y de su transporte. Define la disposición de

una celda, significado de los campos de encabezado, así como el establecimiento
de CV y control de la congestión.
3. Capa de adaptación de ATM: la mayoría de las aplicaciones no necesitan

trabajar directamente con las celdas, en su lugar se define una capa superior a
la capa ATM para que los usuarios envíen paquetes más grandes que una celda.
La interfaz de ATM segmenta estos paquetes en celdas y reensambla en el otro
extremo.
ATM se define como modelo tridimensional. En la siguiente figura se muestra un

esquema del mismo:
REDES
Figura 7.10: Modelo de referencia ATM.
Plano de usuario: Trata con el transporte de datos, control de flujo, corrección

de errores.
Plano de control: Se ocupa de la administración de la conexión.
La subcapa PDM (Dependiente del medio Físico:) Interactúa con el cable

real. Mueve los bits dentro y fuera y maneja la temporización de bits. Esta capa
será diferente para diferentes cables y transportadoras.
La subcapa TC (Convergencia de Transmisión): Su trabajo es convertir el

flujo de bits en un flujo de celdas para la Capa ATM. Maneja todos los aspectos
relacionados sobre dónde empieza y termina una celda en el flujo de bits.
La capa ATM: Maneja celdas, incluyendo su generación y transporte. Es una

combinación de la capa de enlace y de red del modelo OSI.
La capa de adaptación de ATM: Se divide en dos subcapas:
• SAR(Segmentación y Reensamble): que se encarga de fragmentar paquetes

en celdas en el transmisor y los une de nuevo en el destino.
• CS (Subcapa de convergencia): permite que los sistemas ATM ofrezcan diver-
sos tipos de servicios a diferentes aplicaciones. Por ejemplo, la transferencia
de archivos y video bajo demanda tienen diferentes requerimientos respecto
a manejo de errores, temporización.
7.7. SSL: CAPA DE SOCKETS SEGUROS

Un aspecto importante de la seguridad en la Web, son las conexiones seguras.
Cuando la Web irrumpió sólo se utilizaba para distribuir páginas estáticas. Las
aplicaciones bancarias y financieras crearon una demanda de conexiones seguras.
246 7.7. SSL: CAPA DE SOCKETS SEGUROS
En 1995 Netscape respondió con un paquete de seguridad llamado SSL (Capa de

Sockets Seguros). SSL construye una conexión segura entre los dos sockets incluyendo:
1. Negociación de parámetros entre cliente y servidor.
2. Autenticación.
3. Comunicación secreta.
4. Protección de la integridad de los datos.
SSL es una nueva capa colocada entre la capa de aplicación y la de transporte,

que acepta solicitudes del navegador y enviándolas al TCP para transmitir al servidor.
Una vez establecida la conexión segura el trabajo principal de SSL es manejar la
compresión y encriptación.
Cuando HTTP se utiliza por encima de SSL, se conoce como HTTPS (HTTP
seguro). Algunas veces está disponible en un nuevo puerto 443, en lugar del puerto
estándar 80.
REDES

Re Des

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Re Des

Diunggah oleh

Hak Cipta:

Format Tersedia

PREFACIO

1. INTRODUCCIÓN A LAS REDES DE COMPUTADORAS 1

3. LA CAPA DE ENLACE DE DATOS 51

3.2.2. CÓDIGOS DE DETECCIÓN DE ERRORES . . . . . . . . . . 58

3.8.4. ESTRUCTURA DE TRAMA BLUETOOTH . . . . . . . . . . 98

4. LA CAPA DE RED 103

4.4.5. REENVÍO EXPÉDITO O ACELERADO . . . . . . . . . . . . 129

5. LA CAPA DE TRANSPORTE 153

5.5.5. POLÍTICA DE TRANSMISIÓN DE TCP . . . . . . . . . . . . 184

6. LA CAPA DE APLICACIÓN 197

6.4.8. LA WEB INALÁMBRICA . . . . . . . . . . . . . . . . . . . . . 230

7. INTERCONEXIÓN DE REDES 235

1.1. Modelo general de comunicaciones. . . . . . . . . . . . . . . . . . . . . 4

2.1. Aproximaciones sucesivas por Fourier. . . . . . . . . . . . . . . . . . . . 19

2.19. División del espectro en DSL. . . . . . . . . . . . . . . . . . . . . . . . 39

3.1. (a) Comunicación virtual. (b) Comunicación real. . . . . . . . . . . . . 52

3.17. Periodo vulnerable para el marco sombreado en ALOHA. . . . . . . . . 78

4.1. Esquema de envío de un paquete de H1 a H2. . . . . . . . . . . . . . . 104

4.31. Red de clase B dividida en 64 subredes. . . . . . . . . . . . . . . . . . . 136

5.1. Capas de red, transporte y aplicación. . . . . . . . . . . . . . . . . . . . 154

5.14. Pasos para realizar una llamada a procedimiento remoto. . . . . . . . . 175

6.1. Parte del espacio de nombres de dominio de Internet. . . . . . . . . . . 199

6.11. Transferencia de un mensaje de elinore@abc.com a carolyn@xyz.com. . . 210

7.4. Ejemplo ilustrativo de entunelamiento. . . . . . . . . . . . . . . . . . . 238

1.1. CONCEPTO DE RED DE COMPUTADORAS

1.1.1. VENTAJAS DE LAS REDES DE COMPUTADORAS

Tolerancia a fallos: Si un ordenador falla, otro podría asumir sus funciones y

Entorno de trabajo flexible: Un empleado podría trabajar en su casa accediendo,

1.1.2. PROPIEDADES DESEADAS

Ámbito: Una arquitectura de red debería resolver tantos problemas generales

1.2. USOS DE LAS REDES DE COMPUTADORAS

1.2.1. REDES PARA COMPAÑÍAS

1.2.2. REDES PARA LA GENTE

Para una compañía la principal ventaja en el uso de redes es la economía. Para un

1. Acceso a información remota.

2. Comunicación persona a persona.

En los últimos años se le ha abierto un extenso abanico de posibilidades a un

1.2.3. CONSIDERACIONES SOCIALES

La introducción ampliamente difundida de redes ha significado nuevos problemas

1.3. MODELO GENERAL DE COMUNICACIONES

El objetivo principal de todo sistema de comunicación es intercambiar información

Figura 1.1: Modelo general de comunicaciones.

1.4. TOPOLOGÍA DE REDES

Proporcionar la máxima fiabilidad a la hora de etablecer el tráfico.

Se pueden diferenciar dos familias de redes:

2. Redes de difusión: Utilizan un medio físico de transmisión común para todas

Cada una de estas familias admite, a su vez, distintas configuraciones a la hora de

1.4.1. REDES PUNTO A PUNTO

Figura 1.2: Redes punto a punto.

TOPOLOGÍA JERÁRQUICA O EN ÁRBOL

Es muy sencilla de controlar y el flujo de tráfico es relativamente menor por surgir

Ofrece ventajas en cuanto a la escalabilidad, evolucionando a la topología en es-

Su principal atractivo reside en la inmunidad a fallos debido a que es posible el

1.4.2. REDES DE DIFUSIÓN

Figura 1.3: Redes de difusión.

1.5. TIPOS DE REDES

1.5.1. REDES DE ÁREA LOCAL (LAN)

Redes de difusión, generalmente de caracter privado, de una extensión de pocos

1.5.2. REDES DE ÁREA METROPOLITANA (MAN)

1.5.3. REDES DE ÁREA AMPLIA (WAN)

ELEMENTOS EN LAS REDES WAN

Figura 1.4: Elementos en las redes WAN.

Líneas de Transmisión (Circuitos): Transmiten los bits de una máquina a

Elementos de Conmutación: Computadoras especializadas que conectan dos