Redes PDF

Redes de Computadoras, 2006/07
REDES DE TELECOMUNICACIONES
Contenidos
I Introducci on a las redes de computadoras
. . . . . . . . . . . . . . . . . . . . . . . . . . . . de Internet? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2 3 4 5 6 7
1. Qu e es Internet? 1.1. Qu e es Internet? . . 1.2. Qu e es una internet? 1.3. Que es un host? . . 1.4. Qu e es un router? . 1.5. Cu al es la morfolog a
1.6. Qu e es un ISP? . . . . . . . . . . . . . . . . . 1.7. Qu e servicios proporciona la red? . . . . . . . 1.8. C omo usan los servicios las aplicaciones? . . . 1.9. Qu e es un protocolo de red? . . . . . . . . . . 1.10. Qu e son los clientes y los servidores? . . . . . 1.11. Qu e es un servicio orientado a conexi on? . . . 1.12. Qu e es un servicio no conable y sin conexi on?
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
9 10 11 12 13 15 17 18 19 20 21 23 25 26 27 28
2. T ecnicas de transmisi on de datos 2.1. Conmutaci on de circuitos . . . . . . . . . . . . . . . . . 2.2. Conmutaci on de paquetes . . . . . . . . . . . . . . . . . 2.3. Multiplexaci on en redes de conmutaci on de circuitos . . 2.4. Multiplexaci on en redes de conmutaci on de paquetes . . 2.5. Por qu e Internet utiliza conmutaci on de paquetes? . . . 2.6. Qu e inconvenientes genera la conmutaci on de paquetes? 2.7. Almacenamiento y reenv o . . . . . . . . . . . . . . . . 2.8. Segmentaci on de los mensajes . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
3. T ecnolog as de trasmisi on de datos 3.1. Tel efono de voz . . . . . . . . . . . . . . 3.2. ADSL (Asymetric Digital Subscriber Line) 3.3. Cable coaxial de TV . . . . . . . . . . . . 3.4. Ethernet conmutada . . . . . . . . . . . . 3.5. Wireless LAN o Wi-Fi . . . . . . . . . . . 3.6. Telefon a m ovil digital celular . . . . . . . 3.7. Telefon a m ovil digital por sat elite . . . . 3.8. ATM (Asynchronous Transfer Mode) . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
31 32 34 36 38 40 42 43 44 46 48 50 51 52 53 55 56 58
4. Retardos y p erdidas en redes de conmutaci on de paquetes 4.1. Funcionamiento de un router . . . . . . . . . . . . . . . . 4.2. Tiempo de procesamiento (tproc ) . . . . . . . . . . . . . . 4.3. Tiempo de cola (tcola ) . . . . . . . . . . . . . . . . . . . . 4.4. Tiempo de transmisi on (ttran ) . . . . . . . . . . . . . . . . 4.5. Tiempo de propagaci on (tprop ) . . . . . . . . . . . . . . . 4.6. Tiempo de retardo nodal (tnodal ) . . . . . . . . . . . . . . 4.7. P erdida de paquetes a causa de la congesti on . . . . . . . 4.8. Ejemplos . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . .
5. Arquitectura del TCP/IP 5.1. El modelo de capas . . . 5.2. Funciones de las capas en 5.3. Las capas de Internet . . 5.4. Capas y protocolos . . . 5.5. Capas y nodos . . . . . .
. . . . . . . . . . el modelo de red . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
61 62 63 64 65 66
II
La capa de aplicaci on
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
69 70 71 74 75 76 77 80 83
6. La Web 6.1. Qu e es la Web? . . . . . . . . . . 6.2. La comunicaci on Web . . . . . . . 6.3. Las conexiones Web . . . . . . . . 6.3.1. Conexiones no persistentes 6.3.2. Conexiones persistentes . . 6.4. Los mensajes HTTP . . . . . . . . 6.4.1. Un mensaje de petici on . . 6.4.2. Un mensaje de respuesta .
6.5. Paso de par ametros en las URLs . . . 6.6. Identicaci on de usuarios . . . . . . . 6.6.1. Autorizaci on login/password 6.6.2. Cookies . . . . . . . . . . . . 6.7. El GET condicional . . . . . . . . . . 6.7.1. GET (normal) . . . . . . . . . 6.7.2. GET condicional . . . . . . . . 6.8. Las cach es Web (proxies Web) . . . . 6.9. Arquitecturas Web . . . . . . . . . . . 6.9.1. La conguraci on m as sencilla . 6.9.2. Sistemas proxy de 1 nivel . . . 6.9.3. Sistemas proxy multinivel . . . 6.9.4. Sistemas proxy distribuidos . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
86 87 88 89 91 92 93 94 96 96 97 98 100 102 103 104 105 106
7. El correo electr onico 7.1. El correo electr onico . . . . . . . . . . . . . . . . . . . . 7.2. Conguraciones . . . . . . . . . . . . . . . . . . . . . . 7.2.1. Correo local usando SMTP . . . . . . . . . . . . 7.2.2. Correo local usando lectores y escritores de correo
. . . .
. . . .
7.3. 7.4. 7.5. 7.6. 7.7. 7.8.
7.2.3. Correo remoto usando servidores locales . 7.2.4. Correo remoto usando un servidor remoto El SMTP . . . . . . . . . . . . . . . . . . . . . . Formato de un e-mail . . . . . . . . . . . . . . . Las extensiones MIME . . . . . . . . . . . . . . . Los lectores/escritores de correo . . . . . . . . . Protocolos de acceso a correo (POP3 e IMAP) . Web-Based E-mail . . . . . . . . . . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
107 109 110 112 114 120 121 124 126 127 128 129 133 135 136 137 138 146
8. El DNS (Domain Name Service) 8.1. Funci on del DNS . . . . . . . . . . . . . . 8.2. Descripci on del DNS . . . . . . . . . . . . 8.3. Alias y nombres can onicos . . . . . . . . . . 8.4. Arquitectura del DNS . . . . . . . . . . . . 8.4.1. Servidores de nombres ra z . . . . . 8.4.2. Servidores de nombres de alto nivel . 8.4.3. Servidores de nombres autorizados . 8.5. Las consultas . . . . . . . . . . . . . . . . 8.6. Caching . . . . . . . . . . . . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
8.7. Los registros DNS . . . . . . . . . . . . . . . . . . . . . . . 147 8.8. Regional Internet Registries . . . . . . . . . . . . . . . . . . 151 9. Compartici on de Ficheros (File Sharing) 9.1. El FTP (File Transfer Program) . . . . . . . . . . . . 9.2. Aplicaciones P2P (Peer-to-peer) . . . . . . . . . . . . 9.2.1. B usqueda usando un directorio centralizado . . 9.2.2. B usqueda usando un directorio descentralizado 9.2.3. B usqueda mediante inundaci on . . . . . . . . . 9.3. Acerca de la tasa de descarga . . . . . . . . . . . . . . 10.Transmisi on de audio y v deo 10.1. Caracter sticas de la transmisi on de audio y v deo 10.2. Ejemplos de aplicaciones . . . . . . . . . . . . . 10.3. Obst aculos de la Internet actual . . . . . . . . . 10.4. C omo deber a evolucionar Internet? . . . . . . . 10.5. Problemas y soluciones en la transmisi on de audio 10.5.1. Eliminaci on del jitter . . . . . . . . . . . 10.5.2. Recuperaci on de paquetes perdidos . . . . 153 154 156 159 161 164 167 169 170 171 172 173 175 175 176
. . . . . .
. . . . . .
. . . . . .
. . . . y . .
. . . . . . . . . . . . . . . . v deo . . . . . . . .
. . . . . . .
10.5.3. Ordenaci on de paquetes . . . . . . . . . 10.6. Protocolos para la transmisi on de audio y v deo 10.6.1. Real-Time Protocol (RTP) . . . . . . . 10.6.2. Real-Time Control Protocol (RTCP) . . 10.6.3. Real-Time Streaming Protocol (RTSP) 10.7. ReSerVation Protocol (RSVP) . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
180 181 181 185 187 189
III
La capa de transporte de datos

. . . . . . . . . . . . . . . . . . . .
191
192 193 195 196 198
11.Servicios de la capa de transporte de datos 11.1. D onde corre la capa de transporte? . . . . . . . . 11.2. Servicios proporcionados por la capa de transporte . 11.3. El servicio de multiplexaci on . . . . . . . . . . . . 11.4. Sobre los puertos . . . . . . . . . . . . . . . . . .
12.El UDP (User Datagram Protocol) 199 12.1. El UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 12.2. Formato del datagrama UDP . . . . . . . . . . . . . . . . . 201
12.3. La suma de comprobaci on (checksum) . . . . . . . . . . . . 203 12.4. Cu ando usar el UDP? . . . . . . . . . . . . . . . . . . . . 206 12.5. Sobre el control de la congesti on . . . . . . . . . . . . . . . 209 13.Transferencia able de datos 13.1. La transferencia able de datos . . . . . . . . . . . . . 13.2. Detecci on y correcci on de errores . . . . . . . . . . . . 13.3. Protocolos ARQ . . . . . . . . . . . . . . . . . . . . . 13.4. El protocolo ARQ con parada y espera (stop and wait) 13.4.1. NAK vs s olo-ACK . . . . . . . . . . . . . . . . 13.4.2. Numeraci on de los paquetes . . . . . . . . . . 13.4.3. Conrmaci on de los paquetes duplicados . . . . 13.4.4. Numeraci on de los paquetes de conrmaci on . 13.4.5. El protocolo falla si los paquetes se desordenan 13.4.6. Rendimiento pobre . . . . . . . . . . . . . . . 13.5. ARQ con retroceso a n (go back n) . . . . . . . . . . 13.5.1. Longitud de la secuencia de conteo . . . . . . . 13.5.2. Tratamiento de los errores . . . . . . . . . . . 13.5.3. Conrmaci on acumulativa . . . . . . . . . . . . 210 211 212 213 214 215 216 217 218 219 220 222 223 224 226
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
13.5.4. Piggybacking [24] . . . . . . . . . . . . . . . . 13.6. ARQ con repetici on selectiva (selective repeat o SR) . 13.6.1. Longitud de la secuencia de conteo . . . . . . . 13.7. Consideraciones sobre la eciencia . . . . . . . . . . . 13.7.1. Tasa de transmisi on versus tasa de errores . . . 13.7.2. Latencia media versus tasa de errores . . . . . 13.7.3. Tasa de transmisi on versus tama no del paquete 13.8. Soluci on al desorden de los paquetes . . . . . . . . . . 14.Control del ujo y de la congesti on 14.1. Control de ujo . . . . . . . . . 14.2. Control de la congesti on . . . . . 14.3. Causas y costes de la congesti on 14.4. D onde se realiza el control de la 15.El TCP (Transmission Control 15.1. Servicios proporcionados . 15.2. El contexto de trabajo . . . 15.3. Transmisi on de datos . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
226 227 229 232 232 233 234 235 236 237 238 239 240 241 242 243 244
. . . . . . . . . . . . . . . . . . . . . congesti on?
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15.3.1. El segmento TCP . . . . . . . . . . . . . . 15.3.2. EL proceso de desmultiplexaci on . . . . . . 15.3.3. Establecimiento de la conexi on . . . . . . . 15.3.4. El tama no m aximo de los segmentos . . . . 15.3.5. Transmisi on de datos urgentes . . . . . . . 15.3.6. Cierre de la conexi on . . . . . . . . . . . . 15.3.7. El diagrama de estados . . . . . . . . . . . 15.4. Control de ujo y de errores . . . . . . . . . . . . . 15.4.1. El tama no de las ventanas . . . . . . . . . 15.4.2. El tama no de los n umeros de secuencia . . 15.4.3. Retransmisi on r apida . . . . . . . . . . . . 15.4.4. El s ndrome de la ventana tonta . . . . . . 15.5. Control de la congesti on . . . . . . . . . . . . . . . 15.5.1. El tama no de los time-outs . . . . . . . . . 15.5.1.1. El algoritmo original . . . . . . . 15.5.1.2. El Algoritmo de Karn/Partridge . 15.5.1.3. El Algoritmo de Jacobson/Karels . 15.6. Ejemplos . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . .
244 249 250 253 254 255 257 259 262 263 265 266 268 272 273 274 277 279
IV
La capa de red
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
285
286 287 289 290 294 296 298 303 305 306 309 311 315 316
16.Servicios de la capa de red 16.1. El modelo de servicio . . . . . . . . . . . . . . . 16.2. El IP (Internet Protocol) . . . . . . . . . . . . . 16.2.1. Formato de la cabecera en IPv4 . . . . . 16.2.2. Formato de la cabecera en IPv6 . . . . . 16.2.3. Fragmentaci on y ensamblaje . . . . . . . 16.3. El ICMP (Internet Control Message Protocol) . . 16.4. El DHCP (Dynamic Host Conguration Protocol) 17.Addressing (Direccionamiento) 17.1. Direccionamiento en IPv4 . . . . . . 17.2. Clases de dirs IP . . . . . . . . . . . 17.3. Sub-netting y dirs CIDR en IPv4 . . 17.4. Redes privadas . . . . . . . . . . . . 17.5. NAT (Network Address Translation)
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
18.Forwarding (Encaminamiento) 319 18.1. El proceso de encaminamiento . . . . . . . . . . . . . . . . 320 18.1.1. B usqueda en las tablas de encaminamiento . . . . . 321 18.2. Agregaci on de direcciones . . . . . . . . . . . . . . . . . . . 330
19.Routing (Rutado) 19.1. Qu e es el routing? . . . . . . . . . . . . . . . 19.2. La red como un grafo . . . . . . . . . . . . . . 19.3. Sobre los costes de los caminos . . . . . . . . . 19.4. Routing jer arquico y sistemas aut omomos . . . 19.5. El RIP (Routing Information Protocol) . . . . . 19.6. El protocolo OSPF (Open Shortest Path First) 19.7. El BGP (Border Gateway Protocol) . . . . . . . 19.8. Algoritmos de routing . . . . . . . . . . . . . . 19.8.1. Algoritmo de routing Link-State . . . . 19.8.2. Algoritmo de routing Distance-Vector .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
336 337 340 341 342 345 351 354 357 357 362
20.Multicasting (Multidifusi on) 366 20.1. Modelos de transmisi on . . . . . . . . . . . . . . . . . . . . 367
20.2. El multicasting a nivel de aplicaci on y de red . . . . . . . . . 20.3. Algoritmos de broadcasting . . . . . . . . . . . . . . . . . . 20.3.1. Flooding . . . . . . . . . . . . . . . . . . . . . . . . 20.3.2. Spanning-tree broadcast . . . . . . . . . . . . . . . . 20.4. Los grupos multicast . . . . . . . . . . . . . . . . . . . . . 20.5. El IGMP (Internet Group Management Protocol) . . . . . . 20.6. Protocolos de routing multicast . . . . . . . . . . . . . . . . 20.6.1. El DVMRP (Distance Vector Multicast Routing Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . 20.6.2. PIM (Protocol Independent Multicast) . . . . . . . . 20.7. Multicasting en las redes locales . . . . . . . . . . . . . . . 20.8. Multicasting en Internet: el MBone (Multicast BackbONE) . 21.Mobility (Movilidad) 21.1. Routing para hosts m oviles 21.2. Nomenclatura . . . . . . . 21.3. Routing indirecto . . . . . 21.4. Routing directo . . . . . .
368 370 370 372 376 379 382 382 383 384 385 388 389 391 393 396
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
La capa de enlace de datos

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
398
399 400 402 403 403 403 403 404 406 407 409 411 413
22.Servicios de la capa de enlace de datos 22.1. El marco de trabajo . . . . . . . . . . 22.2. Nodos, frames y enlaces . . . . . . . . 22.3. Servicios generalmente proporcionados 22.3.1. Transporte de datos . . . . . . 22.3.2. Direccionamiento . . . . . . . 22.3.3. Control de acceso al medio . . 22.3.4. Transferencia able . . . . . . 23.Control de errores 23.1. Fundamentos . . . . . . . . . . 23.2. Paridad . . . . . . . . . . . . . . 23.3. Checksum . . . . . . . . . . . . 23.4. CRC (Cyclic Redundancy Check)
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
24.Protocolos de acceso m ultiple 417 24.1. Protocolos de particionado del canal . . . . . . . . . . . . . 418
24.2. Las colisiones . . . . . . . . . . . . . . . . . . 24.3. Protocolos de particionado est atico del canal . . 24.3.1. FDM y TDM . . . . . . . . . . . . . . 24.3.2. CDMA (Code Division Multiple Access) 24.4. Protocolos de acceso aleatorio . . . . . . . . . 24.4.1. ALOHA ranurado . . . . . . . . . . . . 24.4.2. ALOHA (no ranurado) . . . . . . . . . 24.4.3. CSMA (Carrier Sense Multiple Access) . 24.4.4. CSMA/CD (Collision Detect) . . . . . . 24.5. Protocolos basados en turnos . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
419 420 421 422 426 427 429 431 433 435 436 437 438 440
25.Redes locales y el ARP 25.1. LAN: denici on . . . . . . . . . . . . . . . . . . . . . . . . 25.2. Direcciones f sicas . . . . . . . . . . . . . . . . . . . . . . . 25.3. El ARP (Address Resolution Protocol) . . . . . . . . . . . .
26.Ethernet 443 26.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 444 26.2. Estructura del frame . . . . . . . . . . . . . . . . . . . . . . 445
26.3. Servicio . . . . . . . . . . . . . . . . . . . . . 26.4. Codicaci on Manchester . . . . . . . . . . . . 26.5. El protocolo CSMA/CD en Ethernet . . . . . . 26.5.1. Eciencia . . . . . . . . . . . . . . . . 26.6. Tecnolog as Ethernet . . . . . . . . . . . . . . 26.6.1. 10Base2 Ethernet . . . . . . . . . . . . 26.6.2. 10BaseT Ethernet y 100BaseT Ethernet 26.6.3. Gigabit Ethernet y 10 Gigabit Ethernet . 26.7. Hubs . . . . . . . . . . . . . . . . . . . . . . . 26.8. Switches . . . . . . . . . . . . . . . . . . . . . 26.8.1. Encaminamiento . . . . . . . . . . . . . 26.8.2. Store-and-forward versus cut-throuht . . 27.Wi-Fi 27.1. Capacidades . . . . . 27.2. Modes . . . . . . . . 27.2.1. Infrastructure 27.2.2. Modo Ad-Hoc 27.3. Canales . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
. . . . . . . . . . . .
447 448 449 451 452 452 454 456 457 459 463 465 466 467 468 468 470 471
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
27.4. El proceso de asociaci on . . . . . . 27.5. CSMA/CA (Carrier Sense Multiple ance) . . . . . . . . . . . . . . . . 27.6. Estructura del frame IEEE 802.11 27.7. Mobility . . . . . . . . . . . . . .
. . . . . . . . . . . . . . Access/Collision Avoid. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
472 474 479 481
28.Bluetooth 483 28.1. IEEE 802.15 . . . . . . . . . . . . . . . . . . . . . . . . . . 484 29.Enlaces PPP 29.1. EL PPP (Point-to-Point 29.2. Data framing . . . . . 29.2.1. Byte stung . . 29.3. Protocolo de control del 485 486 487 488 489
Protocol) . . . . . . . . . . . . enlace . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
30.ATM 497 30.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498 30.2. Principales caracter sticas . . . . . . . . . . . . . . . . . . . 499 30.3. Modelo de servicio . . . . . . . . . . . . . . . . . . . . . . . 500
30.4. Las celdas ATM . . . . . . . . . . . . . . . . 30.5. Morfolog a de la red . . . . . . . . . . . . . . 30.6. Canales virtuales y routing . . . . . . . . . . 30.7. Arquitectura de ATM . . . . . . . . . . . . . 30.7.1. La capa f sica . . . . . . . . . . . . . 30.7.2. La capa ATM . . . . . . . . . . . . . 30.7.3. La capa AAL (ATM Adaptation Layer) 30.7.4. La capa de usuario . . . . . . . . . . 30.8. Control de la congesti on . . . . . . . . . . . . 30.9. The Internet-over-ATM protocol stack . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
502 504 505 506 507 508 509 512 513 514
Parte I
Introducci on a las redes de computadoras
Cap tulo 1
Qu e es Internet?
1.1.
Qu e es Internet?
Existen muchas deniciones de Internet. Algunas de ellas:

1. Internet es una red de millones de computadoras que se extiende a nivel mundial. 2. Internet es una estructura computacional en la que se ejecutan aplicaciones distribuidas (que intercambian datos a trav es de la red). 3. Internet es una gran internet (una red de redes).
ES INTERNET? 1.1. QUE
1.2.
Qu e es una internet?
Por denici on, una internet es la estuctura formada cuando interconectamos dos (o m as) redes. En otras palabras, un conjunto de nodos de computaci on interconectados mediante enlaces de transmisi on de datos [12]. Al nivel internet, s olo existen dos tipos distintos de nodos: 1. Hosts o sistemas terminales (end systems). 2. Routers o dispositivos de conmutaci on de paquetes de datos (data packet switches).
ES UNA INTERNET? 1.2. QUE
1.3.
Que es un host?
En Internet, un host es una computadora que ejecuta aplicaciones de red (que se comunica con otras aplicaciones en otros hosts).
En adelante, generalmente denotaremos a un host mediante la gura: H Un host puede conectarse directamente a otros hosts o a otros routers. H H R R H 1.3. QUE ES UN HOST? H 5 H
1.4.
Qu e es un router?
En Internet, un router es un sistema espec camente dise nado para intercambiar paquetes de datos con otros routers y hosts.
En adelante, denotaremos un router mediante la gura: R Un router puede conectarse directamente a otros routers y/o hosts. H H R R H ES UN ROUTER? 1.4. QUE H 6 H
1.5.
Cu al es la morfolog a de Internet?
Internet se organiza f sicamente como una red de grandes redes que a su vez se componen de otras redes de tama no menor.
ES LA MORFOLOG 1.5. CUAL IA DE INTERNET?
La situaci on geogr aca de las redes se corresponde normalmente con los n ucleos urbanos. Por tanto, si fuera visible desde el espacio, Internet se parecer a a una tela de ara na (aunque mucho m as ca otica) compuesta por enlaces de transmisi on de datos de larga distancia que interconectan internets m as peque nas .
ES LA MORFOLOG 1.5. CUAL IA DE INTERNET?
1.6.
Qu e es un ISP?
En la actualidad, la Internet p ublica es gestionada por una serie de empresas que dan servicio de conexi on a Internet. A esta clase de empresas se les llama Internet Service Providers (proveedores de servicio de Internet) o ISPs. Existen ISPs que interconectan redes a nivel mundial y otros que lo hacen a escala menor. Dependiendo de esto hablaremos de ISPs de nivel 1 (nivel mundial), ISPs de nivel 2 (nivel nacional), etc., hasta llegar a los ISPs que dan servicio a las universidades, empresas, casas, etc. Un aspecto interesante e importante de cara al funcionamiento de Internet es que cada ISP se gestiona de forma independiente.
ES UN ISP? 1.6. QUE
1.7.
Qu e servicios proporciona la red?

A nivel de usuario: 1. Web surng. 2. Mensajer a instant anea. 3. Acceso remoto (remote login). 4. Correo electr onico (e-mail). 5. Compartici on de archivos peer-to-peer (par-a-par) o P2P. 6. Telefon a IP (Internet Protocol). 7. Streaming de audio y v deo. 8. Juegos en red. 9. Etc. A nivel de aplicaci on: existe un conjunto de bibliotecas de software que permiten transmitir datos entre las apliaciones distribuidas (anteriormente mencionadas) que corren en los hosts.
SERVICIOS PROPORCIONA LA RED? 1.7. QUE
10
1.8.
C omo usan los servicios las aplicaciones?

Cualquier aplicaci on, que hace uso de Internet, debe usar estos tipos de servicios (uno o ambos a la vez):
Servicios ables orientados a conexi on, que garantizan que los datos son siempre entregados correctamente a la apliaci on receptora. Servicios no ables y sin conexi on, que no garantizan nada. Unicamente que se intentar a entregar los paquetes de datos. No existen restricciones temporales para realizar dichos servicios.
1.8. COMO USAN LOS SERVICIOS LAS APLICACIONES?
11
1.9.
Qu e es un protocolo de red?
En Internet, los servicios de los que hemos hablado se presentan a las aplicaciones en forma de protocolos de red.
En general, un protocolo es un conjunto de reglas de comportamiento que permiten a dos o m as aplicaciones remotas comunicarse entre s . En Internet, los protocolos m as famosos son el TCP (Transmision Control Protocol) y el IP (Internet Protocol). El primero implementa el servicio able orientado a conexi on y el segundo se encarga del routing (conducci on) de los paquetes de datos a trav es de Internet.
ES UN PROTOCOLO DE RED? 1.9. QUE
12
1.10.
Qu e son los clientes y los servidores?
La mayor a de las aplicaciones distribuidas siguen el paradigma cliente/servidor. En el, la aplicaci on cliente es la que inicia la comunicaci on y la aplicaci on servidora contesta a las peticiones . Por ejemplo, cuando navegamos a trav es de la Web, utilizamos el TCP para comunicarnos con el servidor Web. A continuaci on se muestra lo que ocurre cuando descargamos una p agina Web:
SON LOS CLIENTES Y LOS SERVIDORES? 1.10. QUE
13
Cliente
Solicit u d de c onexi on TC P on exi de con TCP
Servidor
esta Respu GET
http:/ /www
.awl.c om/k uro
se-ros
tml index.h
Tiempo
Tiempo
En este ejemplo, nuestro navegador Web es la aplicaci on cliente y el servidor Web es la aplicaci on servidora. SON LOS CLIENTES Y LOS SERVIDORES? 14 1.10. QUE
1.11.
Qu e es conexi on?
un
servicio
orientado
1. Es el servicio proporcionado por la red que simula una conexi on exclusiva entre dos aplicaciones de red. 2. La aplicaci on receptora recibe una copia ex acta del ujo de bytes generado por la aplicaci on emisora. Para ello, antes del comienzo de la transmisi on, el emisor se asegura de que el receptor puede atender la llegada de los datos. 3. Implementa un mecanismo de control de ujo y de congesti on. Mediante el primero, un emisor r apido no colapsa a un receptor m as lento que el. Gracias al segundo, un emisor disminuye su tasa de transmisi on cuando la red se colapsa por exceso de trabajo. 4. Aunque garantiza la entrega correcta de los datos, no se especica un tiempo m aximo. ES UN SERVICIO ORIENTADO A CONEXION? 1.11. QUE 15
5. Lo proporciona el TCP que est a denido en el RFC (Request For Comments) 793 [4].
ES UN SERVICIO ORIENTADO A CONEXION? 1.11. QUE
16
1.12.
Qu e es un servicio no conable y sin conexi on?
1. Las aplicaci on emisora env a los datos a una aplicaci on receptora sin necesidad de conocer si esta los est a esperando. No existe establecimiento de conexi on. 2. Los datos se env an agrupados en paquetes, que se pueden retrasar un tiempo indeterminado, perder, modicar y desordenar. 3. La red no proporciona ninguna informaci on acerca de qu e les ha pasado a los paquetes. 4. La aplicaci on emisora env a los datos a la velocidad que le parece: no existen mecanismos de control de ujo y de congesti on. 5. Lo proporciona el UDP (User Datagram Protocol) que se dene en el RFC 768 [20]. 17
Cap tulo 2
T ecnicas de transmisi on de datos

ES UN SERVICIO NO CONFIABLE Y SIN CONEXION? 18 1.12. QUE
2.1.
Conmutaci on de circuitos
Actualmente se utiliza en telefon a [24] porque garantiza una tasa de transmisi on de bits (bit-rate) constante entre el emisor y el (o los) receptor(es). Los canales en los enlaces de transmisi on y conmutadores (switches), es decir, los circuitos quedan reservados durante el tiempo que dura la comunicaci on.1 Una vez que se ha establecido la conexi on, no existe tiempo de eson puede denegarse si no pera para transmitir. Sin embargo, la conexi existen sucientes circuitos (red congestionada). Los recursos siguen asignados aunque los emisores dejen temporalmente de transmitir. Bajo esta circunstancia, los circuitos se desperdician.
1 En el fondo es como si siguiera existiendo la operadora que debe enchufar algunas clavijas para establecer la conexi on.
DE CIRCUITOS 2.1. CONMUTACION
19
2.2.
Conmutaci on de paquetes
La red no reserva recursos de transmisi on en concreto, a lo sumo establece prioridades.
La tasa de transmisi on es variable y depende de la carga de la red, con o sin establecimiento de conexi on.
DE PAQUETES 2.2. CONMUTACION
20
2.3.
Multiplexaci on en redes de conmutaci on de circuitos

Normalmente los enlaces presentan una capacidad mayor de la que se necesita en una transmisi on. Por este motivo se multiplexan muchas transmisiones mediante dos t ecnicas distintas, aunque equivalentes desde el punto de vista de la tasa de bits proporcionada: 1. Multiplexaci on en la frecuencia o FDM (Frecuency Division Multiplexing): Los circuitos se implementan mediante canales de frecuencia [23] (v ease el Ap endice E). 2. Multiplexaci on en el tiempo o TDM (Time Division Multiplexing): Los circuitos se implementan mediante slots de tiempo peri odicamente asignados.
EN REDES DE CONMUTACION DE 2.3. MULTIPLEXACION
21
Frecuencia w
FDM
Frecuencia w
TDM
Canal 4
Canal 3 Canal 2 Canal 1 t Tiempo Tiempo
N otese que la capacidad de transmisi on de cada emisor es la misma en ambos casos e igual a: w t 4
22
2.4.
Multiplexaci on en redes de conmutaci on de paquetes

Es una generalizaci on de TDM, donde los slots de tiempo suelen ser on del tama no mucho m as grandes y de una longitud variable en funci del paquete.
23
Los slots de tiempo no quedan reservados. Esto provoca demoras impredecibles en los conmutadores de paquetes dependiendo de la carga. En promedio (olvidando los overheads provocados por las cabeceras) on asignada a los emisores es la misma que la capacidad de transmisi en conmutaci on de circuitos.
24
2.5.
Por qu e Internet utiliza conmutaci on de paquetes?

Mayor aprovechamiento de los recursos de la red [12]: El ancho de banda disponible se aprovecha mejor porque las aplicaciones suelen transmitir de forma aleatoria e intermitente (sin un patr on predeterminado). En otras palabras: se transmite un volumen total de datos mayor. Posibilidad de tasas de transmisi on instant aneas muy altas: La red en general tiene mucha capacidad y si da la casualidad de que la usamos solos, utilizaremos todo el ancho de banda disposible.
INTERNET UTILIZA CONMUTACION DE PAQUETES? 25 2.5. POR QUE
2.6.
Qu e inconvenientes genera mutaci on de paquetes?
la
con-
Tasa de transmisi on variable: El bit-rate depende de la carga.

Jitter > 0: El retraso que sufren los paquetes es variable.
INCONVENIENTES GENERA LA CONMUTACION DE 2.6. QUE
26
2.7.
Almacenamiento y reenv o
Los conmutadores de paquetes en Internet normalmente utilizan la t ecnica de esperar a recibir completamente un paquete antes de proceder a su retransmisi on. Motivos: 1. El enlace de salida puede estar ocupado transmitiendo alg un paquete anterior. 2. La tasa de transmisi on del enlace de entrada y de salida puede ser distinta. La alternativa (cut-through) es muy rara y s olo se utiliza cuando estos dos factores no son un problema (por ejemplo, en m aquinas multiprocesadoras).
2.7. ALMACENAMIENTO Y REENV IO
27
2.8.
Segmentaci on de los mensajes

Los mensajes (de longitud arbitraria) son divididos (normalmente por el emisor) en paquetes de datos antes de ser enviados. El receptor se encarga de reensamblarlos. Esto se hace fundamentalmente por los siguientes motivos:
DE LOS MENSAJES 2.8. SEGMENTACION
28
1. Aunque la segmentaci on introduce redundancia (en forma de cabeceras), los tiempos de transmisi on de los mensajes en redes conmutadas son menores cuando utilizamos almacenamiento y reenv o, ya que disminuye la latencia [23].
Sin Segmentaci on
Emisor Conmutador Receptor Emisor
Con Segmentaci on
Conmutador Receptor
Tiempo
DE LOS MENSAJES 2.8. SEGMENTACION
29
2. La retransmisi on de los paquetes err oneos (la forma m as frecuente de correcci on de errores) introduce menos redundancia [24] ya que los paquetes son m as peque nos.
Tasa de Transmisi on
Tama no Optimo
Tama no del Paquete Overhead de la Segmentaci on Overhead de la Retransmisi on
30
Cap tulo 3
T ecnolog as de trasmisi on de datos

DE LOS MENSAJES 2.8. SEGMENTACION 31
3.1.
Tel efono de voz

Se utiliza fundamentalmente en acceso residencial y hasta hace poco ha sido (con mucho) el sistema de acceso a Internet m as popular debido a su menor coste. Se utiliza un canal de voz para transmitir (4 KHz de ancho de banda), que permite a lo sumo 56 Kbps de tasa de transmisi on (normalmente menos debido al ruido en la l nea) mediante modulaci on QAM (modulaci on en amplitud y fase simult aneas, v ease el Ap endice E). Son conexiones punto a punto entre el host y el ISP [12].
Casa
H Modem Par Trenzado Modem
ISP
R
3.1. TELEFONO DE VOZ
32
El enlace se implementa mediante un par de hilos trenzados de cobre. Las trenzas contribuyen a tener el mismo ruido en ambos hilos. De hecho, los enlaces se clasican en categor as dependiendo del n umero de trenzas que poseen por unidad de longitud.1
Ruido
Radiaci on Electromagn etica n trenzas an + bn an + bn b b Aislantes El ectricos
a Conductores El ectricos a>b
La distancia entre los modems puede ser muy alta (cientos de Kms).
1 Por ejemplo, en redes es muy com un usar UTP (Unshield Twisted Pair) categor a 5 con los que alcanzan tasas de 100 Mbps sobre unas decenas de metros.
3.1. TELEFONO DE VOZ
33
3.2.
ADSL (Asymetric Digital Subscriber Line)

Se utiliza fundamentalmente en acceso residencial. Emplea la misma infraestructura que el tel efono de voz (par trenzado). Permite alcanzar hasta 10 Mbps (dependiendo de la distancia entre los modems)2 y usar el tel efono simult aneamente [23]. Los enlaces ADSL son punto a punto y dedicados (no se comparten con otros vecinos).
2 Para alcanzar estas velocidades generalmente s olo puede haber unas decenas de metros entre ambos modems.
3.2. ADSL (ASYMETRIC DIGITAL SUBSCRIBER LINE)
34
Por la forma en que los usuarios suelen usar Internet, el canal de bajada generalmente tiene un ancho de banda mayor que el de subida (de ah lo de asim etrico). Se utiliza multiplexaci on en frecuencia.
Frecuencia 1 MHz
Recepci on
50 KHz Env o 4 KHz Voz Anal ogica (bidireccional) 0 Tiempo 3.2. ADSL (ASYMETRIC DIGITAL SUBSCRIBER LINE) 35
3.3.
Cable coaxial de TV
Se utiliza fundamentalmente en acceso residencial. Aprovecha la infraestructura de la TV por cable. La idea es dedicar algunos canales de TV (unos 6 MHz/canal) para enviar datos y otros para recibir. El medio de transmisi on (cable coaxial) es compartido por todos los usuarios de Internet del vecindario. A su vez los canales pueden compartirse dependiendo del n umero de usuarios.
Cubierta de Pl astico Conductor El ectrico Interno Conductor El ectrico Externo Aislante El ectrico
Aislante El ectrico
3.3. CABLE COAXIAL DE TV
36
Si esto ocurre, el canal de carga (subida) presenta problemas de colisiones y el de descarga (bajada) es compartido por todos los vecinos. Estos problemas no suelen (o al menos no deber an) bajar la tasa de bits obtenida por debajo de la contratada.
Casa
H Modem
Cable Coaxial
Casa
Modem H
Modem ISP R
3.3. CABLE COAXIAL DE TV
37
3.4.
Ethernet conmutada
Es la tecnolog a LAN (Local Area Network) m as implantada en empresas, universidades, etc.
Los hosts se conectan mediante enlaces punto a punto a un conmutador de tramas Ethernet, form andose t picamente estructuras en arbol.
R S S H 3.4. ETHERNET CONMUTADA H 38 H
Utiliza enlaces de par trenzado (distancias cortas) o bra optica (distancias largas). Las tasas de transmisi on t picas son 100 Mbps y 1 Gbps entre cada par de nodos. No existen colisiones. El conmutador las resuelve.
3.4. ETHERNET CONMUTADA
39
3.5.
Wireless LAN o Wi-Fi

Est a reemplazando a la Ethernet conmutada cuando es necesaria cierta movilidad de los hosts (bibliotecas, cafeter as, universidades, casas).
Permite alcanzar tasas de 54 Mbps (802.11g) o 11 Mbps (802.11b), aunque esta puede decrecer al disminuir la SNR3 (v ease el Ap endice D). Se basa en la tecnolog a Ethernet para medios compartidos4 (en este caso se utilizan enlaces de radio), donde una serie de hosts comparte en mismo rango de frecuencias para enviar y recibir (TDM).
R
H
35
Mbps, 2 Mbps, 1 Mbps ... las redes Ethernet usaban un cable coaxial para interconectar todos los hosts de la red.
4 Inicialmente
3.5. WIRELESS LAN O WI-FI
40
La distancia entre los nodos y los switches no sobrepasa normalmente las decenas de metros (dependiendo de las paredes, etc.). Un caso t pico:
3.5. WIRELESS LAN O WI-FI
41
3.6.
Telefon a m ovil digital celular

Permiten conexiones de hasta unas decenas de kilometros. Existen muchas normas. Las m as usadas [2]: 1. GSM (Global System for Mobile kbps/hasta 14 kbps (subida/bajada). communications): 14
2. GPRS (General Packet Radio Service): 14 kbps/hasta 64 kbps. 3. 3G(GSM) (3rd Generation GSM): 348 kbps.
3.6. TELEFON IA MOVIL DIGITAL CELULAR
42
3.7.
Telefon a m ovil digital por sat elite

Permiten conectarnos desde cualquier punto del planeta gracias a una constelaci on de sat elites [25].
Los sat elites son no geo-estacionarios con el objeto de que puedan estar a unos pocos cientos de Km de la supercie terrestre.5 Los sat elites no geo-estacionarios est an constantemente en movimiento respecto de la supercie.6 Se consiguen tasas de transmisi on de hasta 64 Kbps.
5 Los sat elites estacionarios (que no se mueven respecto de la supercie terrestre) est an generalmente demasiado lejos (a unos 36,000 Km de la supercie de La Tierra) como para que con la potencia de transmisi on que usan los m oviles la conexi on sea posible (la SNR de la transmisi on sea sucientemente alta) (ve ase el Ap endice D). 6 Se mantienen a una distancia constante de la supercie porque la fuerza centr fuga es igual a la fuerza de la gravedad.
3.7. TELEFON IA MOVIL DIGITAL POR SATELITE
43
3.8.
ATM (Asynchronous Transfer Mode)

Es una tecnolog a desarrollada para implementar WANs (Wide Area Network) y est a compuesta por conmutadores y enlaces punto a punto de larga distancia. No existe ninguna topolog a espec ca aunque la m as frecuente suele ser en estrella. Se utiliza fundamentalmente en transmisiones de larga distancia entre ISPs. Los enlaces pueden alcanzar una gran variedad de velocidades, pero normalmente se manejan Gbps. Los enlaces se implementan generalmente mediante bra optica o microondas (tanto terrestres como a trav es de sat elites7 ), aunque para distancias muy cortas puede usarse par trenzado. Permite reservar ancho de banda (emulando la conmutaci on de circuitos muy bien) y por este motivo ATM es fundamentalmente uti-
7 Principalmente
geo-estacionarios.
3.8. ATM (ASYNCHRONOUS TRANSFER MODE)
44
lizadas por las compa n as telef onicas.
45
3.8. ATM (ASYNCHRONOUS TRANSFER MODE)
46
Cap tulo 4
Retardos y p erdidas en redes de conmutaci on de paquetes

3.8. ATM (ASYNCHRONOUS TRANSFER MODE) 47
4.1.
Funcionamiento de un router
Dispositivo de conmutaci on encargado de conducir los paquetes desde un emisor hasta el/los receptor/es. El tratamiento de cada paquete es independiente (el paquete es la m axima unidad de transmisi on) [12]. Asociado a cada enlace de salida existe una cola (memoria) donde esperan los paquetes que van a ser retransmitidos por ese enlace de salida.
4.1. FUNCIONAMIENTO DE UN ROUTER
48
Aunque no exista ning un paquete almacenado en la cola de salida, la retransmisi on de un paquete entrante no comienza hasta que se ha recibido totalmente (store-and-forward). Como alternativa, si el enlace est a ocioso podr a retransmitirse el paquete conforme se recibe (cut-through). Sin embargo, esta t ecnica es muy rara. Las colas de salida son nitas y cuando se llenan de paquetes, los nuevos paquetes entrantes se descartan (son destruidos). Normalmente los paquetes son colocados en la cola por estricto orden de llegada (no existen prioridades).
4.1. FUNCIONAMIENTO DE UN ROUTER
49
4.2.
Tiempo de procesamiento (tproc )

Tiempo necesario para que un router examine la cabecera de un paquete y determine hacia qu e enlace de salida debe encaminarse.
Incluye el tiempo necesario para determinar si existen errores de transmisi on (alteraciones de bits) en la cabecera (no en los datos). Si existen, el paquete se desecha pues probablemente se entregar a a un receptor equivocado o el receptor no podr a recuperar adecuadamente el paquete. Suele ser constante y del orden de los microsegundos.
4.2. TIEMPO DE PROCESAMIENTO (TPROC )
50
4.3.
Tiempo de cola (tcola )

Tiempo que un paquete espera en la cola de salida de un router a ser retransmitido.
Depende del tiempo que necesiten los paquetes anteriores almacenados en la cola en ser transmitidos. Es 0 si la cola est a vac a. Suele ser muy variable pues depende de la carga. Se mide en milisegundos. Ver applet.
4.3. TIEMPO DE COLA (T COLA )
51
4.4.
Tiempo de transmisi on (ttran )

Tiempo que tardan todos los bits de un paquete (cabecera y datos) en ser introducidos en y extra dos de un enlace.
Depende de la tasa de transmisi on R y del tama no S del paquete. ttran = S R
En la pr actica suele ser del orden de los milisegundos.
(T TRAN ) 4.4. TIEMPO DE TRANSMISION
52
4.5.
Tiempo de propagaci on (tprop )

Tiempo necesario para que una se nal que indica el comienzo de un bit de datos pueda propagarse desde un extremo a otro del enlace.
Depende la distancia a recorrer D y de la velocidad C de propagaci on de las se nales (normalmente electromagn eticas) en el medio de transmisi on. D tprop = C
(TPROP ) 4.5. TIEMPO DE PROPAGACION
53
La velocidad de propagaci on depende el medio. Medio Vac o/Aire Cobre Fibra Optica C 3 108 m/s 2,3 108 m/s 2 108 m/s
En WANs puede llegar a ser del orden de milisegundos.
(TPROP ) 4.5. TIEMPO DE PROPAGACION
54
4.6.
Tiempo de retardo nodal (tnodal )

Es el tiempo que tarda un router en retransmitir un paquete hasta el siguiente router.
Por denici on es la acumulaci on de todos los tiempos anteriormente descritos: tnodal = tproc + tcola + ttran + tprop El retardo total que experimenta un paquete en cruzar la red depende del n umero de saltos (pasos por un router) que debe realizar. A este tiempo tambi en se lo conoce como tend-end o retardo de extremo-aextremo.
4.6. TIEMPO DE RETARDO NODAL (T NODAL )
55
4.7.
P erdida de paquetes a causa de la congesti on

Los routers descartan los paquetes cuando la cola de salida de los paquetes est an llenas. El nivel de llenado de una cola depende de la velocidad a la que llegan los paquetes a ella y de la velocidad a la que los paquetes son transmitidos. Esto en denitiva depende de las tasas de bits de llegada Ri y de salida Ro . Si el ratio (intensidad de tr aco) Ri >1 Ro
entonces, la cola se desbordar a y los paquetes comenzar an a ser desechados. Si el ratio Ri 1 Ro entonces, la cola no se desbordar a. 56 4.7. PERDIDA DE PAQUETES A CAUSA DE LA CONGESTION
La intensidad de tr aco y el retardo medio en las colas de salida se relacionan de la siguiente manera Retardo Medio en Cola
Ri Ro
Intensidad de Tr aco
lo que signica que el tiempo de transmisi on de los paquetes a trav es de Internet depende exponencialmente de la intensidad del tr aco. 4.7. PERDIDA DE PAQUETES A CAUSA DE LA CONGESTION 57
4.8.
Ejemplos
1. Enunciado: Sea S la longitud media de los paquetes (en bits) y la tasa media de los paquetes que llegan hasta un router. Calc ulese la tasa de bits de llegada al router Ri . Soluci on: S se expresa en bits/paquete y en paquetes/segundo. Por tanto: bits paquetes Ri = S ( )( ). paquete segundo
4.8. EJEMPLOS
58
2. Enunciado: Sup ongase un router con n enlaces de entrada y que al mismo tiempo llegan n paquetes (uno por cada enlace). Determ nese el m aximo tiempo de cola tcola que sufre uno de los paquetes. Sup ongase que L es la longitud media de los paquetes (en bits) y que R es la tasa de transmisi on en paquetes/segundo. Soluci on: El primer paquete servido se retrasar a 0 segundos, el segundo L/R segundos, ... y el n- esimo tcola = (n 1) L . R
4.8. EJEMPLOS
59
3. Enunciado: Calc ulese el tiempo m nimo de extremo-a-extremo entre dos hosts en Internet. Soluci on: El tiempo m nimo se determina cuando los routers est an descongestionados, es decir, cuando tcola = 0. Si N es el n umero de routers en el camino que une ambos extremos, entonces tend-to-end min = (N + 1)(tproc + ttran + tprop ). (T engase en cuenta el enlace que va desde el primer host origen hasta el primer router. Tambi en se ha supuesto que el host consume un tproc .)
4.8. EJEMPLOS
60
Cap tulo 5
Arquitectura del TCP/IP
4.8. EJEMPLOS
61
5.1.
El modelo de capas
Es una forma de organizaci on de sistemas complejos que permite implementarlos mediante subsistemas (capas) m as simples [3, 7, 12].
El modelo permite reemplazar la implementaci on de una de las capas sin que las dem as tengan que modicarse. Para ello, se dene un interfaz de funcionamiento de cada capa mediante el cual se intercambian datos y se solicitan servicios.
5.1. EL MODELO DE CAPAS
62
5.2.
Funciones de las capas en el modelo de red

En una red de computadoras, en general cada capa puede realizar una o m as de las siguientes tareas: 1. Control de errores de transmisi on. 2. Control de ujo de datos y de congesti on. 3. Segmentaci on de mensajes y reensamblado de paquetes de datos. 4. Multiplexado de los enlaces de transmisi on. 5. Establecimiento de conexiones.
5.2. FUNCIONES DE LAS CAPAS EN EL MODELO DE RED
63
5.3.
Las capas de Internet

Internet se organiza en 5 capas: 1. Capa de aplicaci on: en ella corren las aplicaciones de red (la Web, ftp, e-mail, etc.). 2. Capa de transporte: transere datos entre las aplicaciones que corren en 2 o m as hosts. 3. Capa de red: es responsable del routing, es decir, de conducir los paquetes de datos entre los hosts. 4. Capa de enlace: resuelve el problema de transmitir datos entre cada par de nodos (host-host, host-switch, host-router, routerrouter, etc.). 5. Capa f sica: entiende c omo deben transmitirse los ujos de bits sobre los distintos medios f sicos. En ocasiones y dependiendo de la complejidad, las capas pueden subdividirse en sub-capas o pueden fusionarse.
5.3. LAS CAPAS DE INTERNET
64
5.4.
Capas y protocolos
La funcionalidad de cada capa est a denida nalmente por el conjunto de protocolos que implementa.
En Internet, los protocolos m as utilizados son el TCP y el IP. Por este motivo hablamos de la pila de protocolos TCP/IP, aunque existen muchos m as. Ordenados por capas, algunos de los protocolos m as importantes son: 1. Capa de aplicaci on: HTTP (Web), SMTP (e-mail), FTP (ftp), ... 2. Capa de transporte: TCP (transferencia able de datos) y UDP. 3. Capa de red: IP (routing), ICMP (Internet Control Message Protocol), ... 4. Capa de enlace de datos: CSMA/CD (Ethernet), Point-toPoint Protocol (PPP), ... 5.4. CAPAS Y PROTOCOLOS 65
5.5.
Capas y nodos
El n umero de capas que un nodo debe implementar depende de su funcionalidad.
Nivel 5 Nivel 4 Nivel 3 Nivel 2 Nivel 1
Aplicaci on Transporte Red Enlace F sica
Datos T Datos R T Datos E R T Datos
Hosts Hosts Hosts y Routers Hosts, Routers y Switches Host, Routers, Switches y Repeaters
F E R T Datos
El n umero de capas de enlace y f sica es igual al n umero de interfaces de red (en la gura s olo 1). Al proceso de a nadir cabeceras y entregar el PDU (Procesing Data Unit) a la capa inferior se le llama encapsulamiento. 66 5.5. CAPAS Y NODOS
5.5. CAPAS Y NODOS 67
Parte II
La capa de aplicaci on
68
Cap tulo 6
La Web
5.5. CAPAS Y NODOS
69
6.1.
Qu e es la Web?
La (World Wide) Web es una aplicaci on distribuida, inventada por Tim Berners-Lee [5] a principios de los 90, que permite la transmisi on de informaci on bajo demanda.
T picamente, un servidor Web establece una comunicaci on de forma simult anea con muchos clientes Web. El protocolo que dene el intercambio de informaci on es el HTTP (HyperText Transfer Protocol). Este se dene en los RFCs 1945 (HTTP/1.0) y 2616 (HTTP/1.1).
Cliente Web Servidor Web
Cliente Web
Cliente Web
Cliente Web Cliente Web
La Web utiliza el TCP como protocolo de transporte [12]. ES LA WEB? 6.1. QUE 70
6.2.
La comunicaci on Web
En una comunicaci on Web, un navegador Web (el cliente) realiza peticiones al servidor Web (a trav es del puerto 80) y este le entrega objetos Web. Ambos tipos de mensajes se realizan seg un el HTTP.
Servidor
Peticiones HTTP Servidor Web Respuestas HTTP
Cliente
Navegador Web
Objetos Web
WEB 6.2. LA COMUNICACION
71
Entre los servidores Web m as populares se encuentran Apache y Microsoft Internet Informacion Server (v ease la URL http://news.netcraft.com/archives/web server survey.html).
72
Un objeto Web es cualquier cosa que puede ser referenciada por su URL (Universal Resource Locator). Ejemplos t picos son las p aginas Web (c odigo HTML1 ), las im agenes GIF y las im agenes JPEG, aunque actualmente se utiliza el HTTP para transmitir cualquier tipo de archivo (con cualquier contenido). La estructura de una URL Web siempre es de la forma: http://host/camino al objeto en el host
1 HyperText
Markup Language.
73
6.3.
Las conexiones Web

Cuando el cliente establece una conexi on HTTP con un servidor Web, esta puede ser de 2 tipos: no persistente o persistente. El HTTP/1.0 utiliza s olo conexiones no persistentes y el HTTP/1.1 puede utilizar adem as conexiones persistentes. En una conexi on no persistente, para cada objeto Web transferido se establece una conexi on TCP independiente. En una conexi on persistente, durante la misma conexi on (establecida por un par cliente/servidor) se pueden transmitir muchos objetos Web, lo que generalmente ahorra recursos en el servidor (memoria y CPU) y en la red (ancho de banda). Ambos tipos de conexiones pueden ser adem as secuenciales o paralelas (pipelining). Estas u ltimas permiten ahorrar tiempo si transmitimos varios objetos Web porque el cliente puede realizar una nueva petici on antes de recibir la respuesta de una previa.
6.3. LAS CONEXIONES WEB
74
6.3.1.
Conexiones no persistentes Conex. secuenciales

Cliente Servidor
Conex. paralelas
Cliente Servidor
RTT1 RTT2 tobj GET obj1 obj1 GET obj2 obj2 GET obj1 GET obj2 obj1 obj2
RTT (Round-Trip Time) es el tiempo de ida y vuelta de un mensaje de on del objeto Web. En longitud despreciable y tobj es el tiempo de transmisi on TCP necesita cada conexi on TCP, el tiempo de establecimiento de conexi un RTT (RTT1 ). El segundo RTT (RTT2 ) se emplea en solicitar el objeto. 6.3. LAS CONEXIONES WEB 75
6.3.2.
Conexiones persistentes Conex. secuenciales

Cliente Servidor
Conex. paralelas
Cliente Servidor
RTT1 RTT2 tobj GET obj1 obj1 GET obj2 obj2 GET obj1 GET obj2 obj1 obj2
El ahorro del establecimiento de una conexi on TCP para cada conexi on Web reduce el tiempo en el caso de las conexiones secuenciales. El tiempo de respuesta de las conexiones paralelas persistentes es el mismo que el de las conexiones no persistentes, aunque la carga para el servidor suele ser menor. 6.3. LAS CONEXIONES WEB 76
6.4.
Los mensajes HTTP

En una comunicaci on HTTP s olo existen dos tipos de mensajes, los de petici on (request) y los de respuesta (reply).
6.4. LOS MENSAJES HTTP
77
6.4. LOS MENSAJES HTTP 78
6.4. LOS MENSAJES HTTP 79
6.4.1.
Un mensaje de petici on
Capturado usando ethereal conect andose a www.google.es mediante mozilla.

GET / HTTP/1.1 Host: www.google.es User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) G Accept: text/xml,application/xml,application/xhtml+xml,text/htm Accept-Language: en-us, en;q=0.50 Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Connection: keep-alive Cookie: PREF=ID=1e9556644260c793:LD=es:TM=1076751818:LM=1076751 <Cuerpo de entidad>
80
Signicado de algunas de las l neas: Los mensajes de petici on est an codicados en ASCII, comienzan siempre por la cadena GET, la cadena POST o la cadena HEAD y acaban siempre en una l nea en blanco (retorno de carro y nueva l nea). El n umero de l neas es variable, pero como m nimo siempre existe la primera (l nea de petici on) donde se indica el tipo de petici on (GET), la p aqina HTML reclamada (/directorio/pagina.html, aunque en el ejemplo se trata de la p agina index.html que es la p agina por defecto) y la versi on del protocolo HTTP utilizado (HTTP/1.1). El resto de las l neas de cabecera. La primera l nea, que comienza en el ejemplo por Host: especica el host en que reside el objeto (necesario para los proxies). La l nea Connection: indica el tipo de conexi on (keep-alive signica conexi on persistente y close conexi on no persistente. La l nea User-Agent: indica el navegador Web utilizado. Esto es importante para el servidor porque dependiendo del navegador 6.4. LOS MENSAJES HTTP 81
se pueden enviar p aginas HTML diferentes (con id entica URL). La l nea Accept-Language: indica que el usuario preere recibir una versi on en ingl es del objeto.
<Cuerpo de entidad> es un campo de los mensajes de petici on que est a vac o cuando se utiliza el m etodo GET, pero que s se utiliza con el m etodo POST. Este m etodo se emplea, por ejemplo, para rellenar formularios (donde el cliente debe enviar informaci on al servidor). Finalmente, el m etodo HEAD es similar al m etodo GET, pero el servidor en su respuesta no va a incluir el objeto pedido. Este m etodo es normalmente utilizado por los desarrolladores de aplicaciones. En la versi on HTTP/1.1, adem as de GET, POST y HEAD, existen otros dos m etodos: PUT que permite a un usuario cargar un objeto en el servidor Web y DELETE que permite borrarlo.
82
6.4.2.
Un mensaje de respuesta
HTTP/1.1 200 OK Cache-control: private Content-Type: text/html Content-Encoding: gzip Server: GWS/2.1 Content-length: 1484 Date: Sat, 14 Feb 2004 10:52:44 GMT <Cuerpo de entidad> Signicado de algunas de las l neas: Los mensajes de respuesta siempre tienen 3 secciones: la l nea inicial de estados, las lineas de cabecera y el cuerpo de la entidad. La l nea inicial de estados tiene 3 campos: la versi on del protocolo, el c odigo de estado y el estado (estas dos cosas signican lo mismo). En el ejemplo, 200 OK signica que el servidor ha encontrado el objeto y que lo ha servido (en el ejemplo no se muestra tal cual, se trata de 6.4. LOS MENSAJES HTTP 83
un objeto comprimido). En la siguiente tabla se presentan algunos de los c odigos de control m as comunes: C odigo 200 OK 301 Moved Permanently 400 Bad Request 404 Not Found 505 HTTP Version Not Supported Signicado Petici on exitosa El objeto demandado ha sido movido a la URL especicada en Location: Petici on no entendida por el servidor Objeto no encontrado en el servidor Obvio
Server: indica el software del servidor Web. Date: indica la fecha y hora en la que se cre o y envi o la respuesta HTTP. Este campo es importante porque ayuda a los proxies a mantener sus cach es. Content-length: indica el tama no en bytes del objeto enviado. 6.4. LOS MENSAJES HTTP 84
Content-Type: indica que el objeto enviado en el cuerpo de la entidad es texto HTML.
85
6.5.
Paso de par ametros en las URLs

En la secci on anterior hemos visto que uno de los m etodos usados en los mensajes de petici on (POST) era utilizado para enviar datos de tipo formulario al servidor. Esto tambi en ser puede realizar mediante GET. Para ello, en la URL usada se especican dichos datos mediante la forma: URL?primer par ametro&segundo par ametro&. . . Por ejemplo: http://www.google.es/language_tools?hl=es
6.5. PASO DE PARAMETROS EN LAS URLS
86
6.6.
Identicaci on de usuarios
El HTTP no tiene estado lo que signica que un servidor no guarda informaci on acerca de los datos enviados a un determinado cliente. Esto simplica el dise no de los servidores. A menudo, el servidor necesita identicar a los usuarios, bien porque el acceso al servidor est e restringido, o porque quisiera servir cierto contenido en funci on de la identidad del usuario. El HTTP proporciona dos mecanismos: 1. La autorizaci on login/password. 2. Las cookies (galletas).
DE USUARIOS 6.6. IDENTIFICACION
87
6.6.1.
Autorizaci on login/password
El usuario se identica mediante un nombre de usuario (login) y una palabra clave (password). Pasos:
1. El servidor avisa al navegador que debe identicarse mediante una l nea inicial de estado HTTP/1.1 401 AuthorizationRequired en su mensaje HTTP de respuesta. 2. El navegador solicita al usuario el login/password e incluye esta informaci on en una l nea Authorization: del pr oximo mensaje de petici on. Dicha l nea se incluye en cualquier nueva petici on de cualquier nuevo objeto al servidor.
88
6.6.2.
Cookies
Las cookies sirven para que los navegadores identiquen a los usuarios que anteriormente se han conectado.
Servidor
Servidor Web
Cookie: cookie# (en cada petici on)
Cliente
Navegador Web
Set-cookie: cookie# (s olo en la primera respuesta) Tabla de Clientes Cookies Recibidas
En la tabla de clientes existen entradas de la forma (cookie#,usuario), que son creadas la primera vez que el usuario se conecta. DE USUARIOS 89 6.6. IDENTIFICACION
En el chero de cookies recibidas el navegador almacena una entrada (servidor Web, cookie#) cada vez que se conecta (por primera vez) a un servidor que utiliza cookies.
90
6.7.
El GET condicional
Los navegadores Web poseen una cach e donde almacenan los objetos m as recientes.
Cuando un navegador va a reclamar un objeto, primero mira si est a en su cach e. Si est a, entonces su petici on es codicional. Si no est a, su petici on no es condicional. Cuando se realiza una petici on condicional, el servidor Web env a una nueva versi on s olo si la copia local es obsoleta.
6.7. EL GET CONDICIONAL
91
6.7.1.
GET (normal)
Petici on GET /fruit/kiwi.gif HTTP/1.0 User-agent: Mozilla/4.0 Respuesta HTTP/1.0 200 OK Date: Web, 12 Aug 1998 15:39:29 Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 09:23:24 Content-Type: image/gif (cuerpo de entidad)
6.7. EL GET CONDICIONAL
92
6.7.2.
GET condicional
En la cach e del cliente existe el objeto reclamado.

Petici on GET /fruit/kiwi.gif HTTP/1.0 User-agent: Mozilla/4.0 If-modified-since: Mon, 22 Jun 1998 09:23:24 Respuesta Suponiendo que el objeto no ha sido modicado desde 22 Jun 1998 09:23:24. HTTP/1.0 304 Not Modified Date: Web, 19 Aug 1998 15:39:29 Server: Apache/1.3.0 (Unix) 6.7. EL GET CONDICIONAL 93
6.8.
Las cach es Web (proxies Web)

La Web es un entramado de servidores de contenidos y de clientes (navegadores Web y cualquier otra aplicaci on distribuida que utilice el HTTP para comunicarse) (v ease http://www.rediris.es/si/cache). Para minimizar los tiempos de respuesta y el tr aco en la red, la Web utiliza un conjunto de servidores especiales (llamdos proxies Web2 ) que funcionan como una cach e, almacenando todo lo que sirven a los clientes para su posterior reenv o seg un una determinada pol tica (por ejemplo, almacenando siempre los objetos m as frecuentes). De esta forma, cuando un cliente (congurado para utilizar un proxy) solicita un objeto a un servidor Web, en lugar de hacerlo directamente al servidor lo realiza al proxy. El proxy entonces mira si posee el objeto
Funcionamiento
2 Existen otros tipos de proxies que no son Web y por lo tanto, cuando exista confusi on deber a especicarse. En este documento esto no es as por lo que prescindiremos de especicar el tipo de proxy.
WEB (PROXIES WEB) 6.8. LAS CACHES
94
y si es as , lo sirve. En caso contrario lo solicita al servidor, lo almacena y lo sirve. Para mantener actualizada la cach e de un proxy, este utiliza el GET condicional con el servidor (o el proxy de nivel superior).
WEB (PROXIES WEB) 6.8. LAS CACHES
95
6.9.
6.9.1.
Arquitecturas Web
La conguraci on m as sencilla
En su conguraci on m as simple, los clientes atacan directamente a/los servidores Web.
Cliente Web
Respuesta Petici on
Internet
Servidor Web
6.9. ARQUITECTURAS WEB
96
6.9.2.
Sistemas proxy de 1 nivel
El cliente solicita un objeto a su proxy local y si este no lo encuentra, lo solicita al servidor Web pertinente.
Petici on
Cliente Web
Proxy Web
Respuesta
Internet
Servidor Web
97
6.9.3.
Sistemas proxy multinivel
Los servidores proxy pueden congurarse para utilizar de forma recursiva otros servidores proxy de mayor ambito. A esto se le llama cach e Web cooperativa. Los proxies de una jerarqu a pueden utilizar el Internet Caching Protocol (ICP) para hablar todos con todos a la hora de localizar un objeto dentro de la jerarqu a. De esta manera, si el objeto se localiza en un proxy cercano el proceso de descarga del objeto (que nalmente se realiza mediante HTTP) se acelerar a.
98
ACE
Clientes Web
UAL
Clientes Web
Internet
Servidor Web
CICA
Proxy Web
Proxy Web
Clientes Web
Respuesta R R RedIRIS
Clientes Web
Algebra
Clientes Web
UGR
Clientes Web Proxy Web
Proxy Web
Petici on
Proxy Web Proxy Web
. . . Resto de Departamentos de la UAL
. . . Resto de Universidades Andaluzas
99
6.9.4.
Sistemas proxy distribuidos
Los proxies pueden soportar cargas muy altas cuando representan a una gran cantidad de servidores Web.
Cuando un proxy soporta demasiada carga se puede proceder a la distribuci on del contenido de su cach e sobre un conjuto de proxies. El contenido de cada proxy se controla mediante el Cache Array Routing Protocol (CARP) que utiliza rutado por dispersi on (hashing). Esta forma de rutado consiste en usar un proxy distinto en funci on de la URL del objeto Web solicitado. Cuando todos los clientes utilizan la misma funci on de dispersi on, un objeto s olo reside en uno de los proxies (en ese nivel).
100
Cliente Web
Cliente Web
Cliente Web
Proxy Web
Proxy Web
Internet
Servidor Web
101
Cap tulo 7
El correo electr onico
102
7.1.
El correo electr onico

Es un medio de comunicaci on as ncrono, mediante el cual usando Internet podemos enviar correos electr onicos a otras personas sin necesidad de una advertencia previa [12]. En sus versiones m as iniciales s olo permit a transmitir mensajes en formato ASCII. Ahora tambi en puede transmitir cualquier otro tipo de informaci on (datos binarios, programas, v deos, etc.). Se trata de una aplicaci on cliente/servidor. El cliente env a los mensajes (e-mails) y el servidor los recibe. La comunicaci on cliente-servidor se realiza mediante el SMTP (Simple Mail Transfer Protocol).
7.1. EL CORREO ELECTRONICO
103
7.2.
Conguraciones
Supongamos que Alicia le env a un e-mail a Roberto. Podr an darse (entre otras) estas conguraciones:
7.2. CONFIGURACIONES
104
7.2.1.
Correo local usando SMTP

Host
Alicia
SMTP
Mail Server
Roberto
Mail Box
Alicia sabe SMTP y roberto lee el correo directamente desde su chero de mailbox1 , donde se encolan los e-mails que se reciben y todav a no se han le do. En este ejemplo, Roberto utiliza un editor de cheros ASCII. Ambos se comunican a trav es del mismo host.
1 En
Unix, t picamente en /var/spool/mail/Roberto.
105
7.2.2.
Correo local usando lectores y escritores de correo

Alicia Host Roberto
Mail Writer
SMTP
Mail Server
Mail Reader
Mail Box
Los lectores y escritores facilitan la tarea de componer y leer e-mails.
106
7.2.3.
Correo remoto usando servidores locales

Alicia Host Mail Writer SMTP Mail Server SMTP Host Roberto Mail Reader Mail Server
Mail Queue
Mail Box
El servidor de Alicia tratar a de enviar los e-mails inmediatamente. Si la comunicaci on con el servidor de Roberto no es posible, los e-mails 7.2. CONFIGURACIONES 107
se almacenan en una cola local2 para un intento posterior3 . Si despu es de varios d as (normalmente 6) la transmisi on no tiene exito, entonces el servidor de correo env a un mensaje al usuario escritor indic andole que la comunicaci on no ha sido posible. Normalmente el n umero de saltos que realiza un e-mail entre servidores es s olo 1, es decir, el servidor de Alicia le env a el e-mail directamente al servidor de Roberto. Sin embargo, esto puede cambiar si el servidor de Alicia est a congurado para que todo el correo saliente pase por otro servidor de correo intermedio. Estos servidores hacen relay (retransmisi on) y se suelen utilizar para controlar si los mensajes contienen virus, etc.
2 En 3 Que
Unix, t picamente en /var/spool/mqueue/Alicia. se realiza aproximadamente cada 30 minutos.
108
7.2.4.
Correo remoto usando un servidor remoto

Roberto Host SMTP Mail Server POP3 Server POP3 Host Mail Reader
Alicia Host Mail Writer
Mail Box
El escritor de correo utiliza SMTP para el correo (saliente) y el lector de correo POP3 (o IMAP) para el correo entrante.
109
7.3.
El SMTP
RFC 2821. Controla c omo se realiza la transmisi on de datos entre los servidores de correo. Es bastante antiguo4 y s olo permite enviar mensajes escritos en ASCII de 7 bits. Corre sobre el TCP y se utiliza el puerto 25. El SMTP utiliza conexiones persistentes, lo que signica que si el emisor tiene que transmitir varios e-mails, lo har a sobre la misma conexi on TCP.
7.3. EL SMTP
4 1982,
teniendo en cuenta que Internet apareci o formalmente a principios de los 70.
110
Un ejemplo (servidor, cliente): hundix$ telnet localhost 25 220 hundix.ace.ual.es ESMTP Sendmail 8.12.8/8.12.8; Sun, 11 Jan 2004 10:31:23 +0100 HELO hundix.ace.ual.es 250 hundix.ace.ual.es Hello localhost.localdomain [127.0.0.1], pleased to meet you MAIL FROM: <vruiz@ual.es> 250 2.1.0 <vruiz@ual.es>... Sender ok RCPT TO: <bill gates@msn.com> 250 2.1.5 <bill gates@msn.com>... Recipient ok (will queue) DATA 354 Enter mail, end with "." on a line by itself Como va tu Windows? . 250 2.0.0 i0B9VNiA001623 Message accepted for delivery QUIT 221 2.0.0 hundix.ace.ual.es closing connection Connection closed by foreign host. 111 7.3. EL SMTP
7.4.
Formato de un e-mail
Un e-mail (tal y como se almacena en una mailbox tras su recepci on) se compone de una cabecera y de un cuerpo de mensaje, separados por una l nea en blanco (CRLF). El formato de la cabecera est a estandarizado (RFC 822). Es una lista de l neas de la forma: palabra-clave: argumento Algunas de las palabras-clave (junto con sus argumentos) son obligatorias para que un e-mail est e bien formateado. Este es un ejemplo m nimo: From: vruiz@ual.es To: Bill_Gates@msn.com Subject: Has probado el Linux? Algunas entradas de la cabecera las coloca el escritor de correo (cuando lo construye) y otras son generadas por los servidores
7.4. FORMATO DE UN E-MAIL
112
de correo (cuando transmiten los e-mails). Algunos ejemplos: From: Escritor de correo To: Escritor de correo Subject: Escritor de correo Received: Servidor de correo y retransmisiores Return-Path: Retransmisores El cuerpo del mensaje no tiene formato (puede ser cualquier cosa siempre que se codique en ASCII de 7 bits).
7.4. FORMATO DE UN E-MAIL
113
7.5.
Las extensiones MIME

RFCs 2045 y 2046. Las extensiones MIME (Multipurpose Internet Mail Extensions) amplian las posibilidades denidas en el RFC 822, para poder enviar cualquier cosa (caracteres con acentos, cheros MP3, etc.) en el cuerpo del mensaje de un e-mail, utilizando c odigos ASCII de 7 bits. Cuando transmitidos cheros en un e-mail, la cabecera contiene las entradas: Content-Transfer-Encoding: <m etodo de codificaci on> Content-Type: <tipo>/<subtipo>; <par ametros>
Estas cabeceras son creadas por los escritores de correo.
7.5. LAS EXTENSIONES MIME
114
Un ejemplo simple, en el que se transmite una imagen JPEG, ser a: From: alicia@crepes.fr To: Roberto@hamburger.edu Subject: Imagen de un delicioso crepe. Content-Transfer-Encoding: base64 Content-Type: image/jpeg 980v98t0298t2098t2j0982098td0j928t9jtjd2j89t2j3 ... 098309d20jr82j309h8239r209384fr239d8rj23098rd29
115
Los tipos de mensajes MIME m as usuales son: 1. text: se utiliza para indicar que el contenido es texto, aunque en alg un juego de caracteres especial. Ejemplo:
From: alicia@crepes.fr To: roberto@hamburger.edu Subject: Saludos Content-Type: text/plain; charset="ISO-8859-1" Hola Roberto. C omo est as?
116
2. image: indica que se env a una imagen. Ejemplo: From: alicia@crepes.fr To: Roberto@hamburger.edu Subject: Imagen de un delicioso crepe. Content-Transfer-Encoding: base64 Content-Type: image/gif 980v98t0298t2098t2j0982098td0j928t9jtjd2j89t2j3 ... 098309d20jr82j309h8239r209384fr239d8rj23098rd29
117
3. application: se emplea para indicar que se transmite cualquier cosa que no sea texto ni una imagen. Ejemplo: From: alicia@crepes.fr To: roberto@hamburger.edu Subject: El documento que me pediste Content-Transfer-Encoding: base64 Content-Type: application/msword 8r9eq098re09q8g0hyr9egy908q0rehy9fqey90hrg9qhye ... 9809rj8390qd9j8e90jf8qw98jef9j8qwe980jq9j8freq9
118
4. multipart: se utiliza para enviar en un chero e-mail varios cheros adjuntos. Ejemplo:
From: alicia@crepes.fr To: roberto@hamburger.edu Subject: Imagen de un delicioso crepe con comentarios. MIME-Version: 1.0 Content-Type: multipart/mixed; Boundary=StartOfNextPart --StartOfNextPart Content-Type: text/plain; charset="ISO-8859-1" Querido Roberto, te env o una imagen de un delicioso crepe. --StartOfNextPart Content-Transfer-Encoding: base64 Content-Type: image/jpeg ldfljkasdfw983909298feq9hjfr939dr39r239j4rd29r3 ... 9n4ytgfy9j8f98fepw98fkfujweifuwe98rugf29tu924u -- StartOfNextPart Content-Type: text/plain; charset="ISO-8859-1" Dime si quieres la receta.
119
7.6.
Los lectores/escritores de correo

El correo electr onico s olo ser a utilizado por los gur us de las redes si no existieran estos programas que ayudan a componer, revisar, ... e-mails. Sus principales funciones son: 1. Gestionar las cabeceras. 2. Comunicarse con un servidor de correo para enviar un e-mail usando SMTP. 3. Avisar de que se ha recibido un nuevo e-mail. 4. Gestionar la creaci on y presentaci on de mensajes con MIME. 5. Gestionar los mailboxes (correo entrante).
7.6. LOS LECTORES/ESCRITORES DE CORREO
120
7.7.
Protocolos de acceso a correo (POP3 e IMAP)

Sirven para que un usuario pueda gestionar (principalmente leer y borrar) su mailbox situado en un servidor remoto. Alicia Roberto Host SMTP Mail Server POP3 Server POP3 Host Mail Reader
Host Mail Writer
Mail Box
7.7. PROTOCOLOS DE ACCESO A CORREO (POP3 E IMAP)
121
Las ventajas m as frecuentes por las que un usuario desea leer el correo en su host local (diferente del host que ejecuta el servidor de correo) son:
1. El host local no tiene que estar siempre encendido; los e-mails se reclaman o env an al servidor de correo que no se apaga. 2. La visualizaci on de e-mails con contenidos multimedia (m usica, v deo) es muy costosa (en t erminos de ancho de banda pico) si se hace mediante streaming (transmisi on del audio y del v deo a trav es de la red mientras se consume). Los principales protocolos de acceso al correo son POP3 (Post Oce Protocol versi on 3) RFC1939 e IMAP (Internet Mail Access Protocol) RFC 2060 . Ambos utilizan el TCP. El acceso se realiza en 3 fases: Fase 1. Autenticaci on: Al comienzo, el usuario se identica (user y password). Fase 2. Transacci on: A continuaci on se transmiten los mensajes. 122 7.7. PROTOCOLOS DE ACCESO A CORREO (POP3 E IMAP)
Con POP3 s olo se puede hacer dos cosas: (1) descargar y borrar o (2) s olo descargar. Con IMAP se pueden crear carpetas en el servidor de forma que tras descargar un e-mail podemos eliminarlos del mailbox, pero dej andolo dentro de una carpeta. Con IMAP podemos tambi en descargar u nicamente un e-mail, o incluso una parte de un e-mail (esto es u til si hay e-mail tiene por ejemplo incluido (attached) un v deo y la l nea de conexi on tiene muy poco de banda). Fase 3. Actualizaci on: Durante esta etapa se cierra la conexi on y se realiza el borrado/movimiento de los e-mails entre el mailbox y las carpetas.
7.7. PROTOCOLOS DE ACCESO A CORREO (POP3 E IMAP)
123
7.8.
Web-Based E-mail
Para terminar de complicar el asunto, todav a existe una forma m as de acceder al correo electr onico almacenado en un servidor: a trav es de la Web. Ejemplos son Hotmail y Yahoo Mail, aunque tambi en existen servicios similares en universidades, empresas, ... En este caso, el agente de usuario es un navegador Web y el servidor de acceso al correo es un servidor Web especialmente dise nado para este prop osito. En este sentido, podemos decir que el HTTP es tambi en un protocolo de acceso a correo, aunque la comunicaci on con el servidor se realiza mediante scripts que utilizan generalmente IMAP. La ventaja de usar Web-Based E-mail es evidente: no es necesario disponer de un agente de usuario, s olo de un navegador Web.
7.8. WEB-BASED E-MAIL
124
Alicia Host
HTTP Host HTTP Web-Mail SMTP Server IMAP Mail Server IMAP Server
Roberto Host Web-Mail Reader
Web-Mail Writer
Mail Box
125
Cap tulo 8
El DNS (Domain Name Service)

7.8. WEB-BASED E-MAIL 126
8.1.
Funci on del DNS

En Internet cada host p ublico se identica mediante su direci on IP. Las dirs IP son n umeros de 32 bits en IPv4 y de 128 bits en IPv6. En IPv4, la forma m as corriente de especicarlas es: A.B.C.D donde A, B, C y D son n umeros entre 0 y 255. Esto para los humanos no es muy c omodo porque nos cuesta mucho recordar n umeros. Nosotros utilizamos mejor nombres de hosts. El DNS se encarga de traducir los nombres en sus correspondientes dirs IP [12].
DEL DNS 8.1. FUNCION
127
8.2.
Descripci on del DNS

RFCs 1034 y 1035. El DNS es una base de datos distribuida (ning un host servidor de DNS, tambi en llamado servidor de nombres, conoce todas las traducciones). Los servidores de DNS son habitualmente m aquinas Unix que ejecutan el demonio BIND (Berkeley Internet Name Domain). Los servidores de nombres escuchan a trav es del puerto 53. El DNS es un servicio cr tico para el funcionamiento de Internet porque la mayor a de las aplicaciones que interactuan con humanos necesitan la resoluci on de nombres constantemente. El DNS se implementa sobre el UDP.
DEL DNS 8.2. DESCRIPCION
128
8.3.
Alias y nombres can onicos

Un host puede tener m as de un nombre, uno can onico y el resto alias. Esto se hace normalmente para concentrar sevicios.
Ejemplo 8.1: Podemos hacer que un mismo host sea servidor de correo electr onico y de Web. El nombre can onico del host podr a ser X.Y.Z y su alias www.Y.Z. Por ejemplo, filabres.ual.es (el nombre can onico) y www.ual.es (el alias) fueron durante un tiempo la misma m aquina 150.214.156.2. Un mismo nombre (can onico o alias) puede ser asignado a muchos hosts. Esto se hace para: 1. Descentralizar servicios (distribuir la carga de trabajo):
8.3. ALIAS Y NOMBRES CANONICOS
129
Ejemplo 8.2: Cuando nos conectamos a cnn.com, no lo hacemos siempre al mismo servidor: $ /usr/bin/host cnn.com cnn.com has address 64.236.24.12 cnn.com has address 64.236.24.20 cnn.com has address 64.236.24.28 cnn.com has address 64.236.16.20 cnn.com has address 64.236.16.52 cnn.com has address 64.236.16.84 cnn.com has address 64.236.16.116 cnn.com has address 64.236.24.4
130
Ejemplo 8.3: Por ejemplo, cuando escribimos a un usuario de correo electr onico de yahoo.es en realidad escribimos a un servidor SMTP en uno de estos hosts: $ /usr/bin/host -t MX yahoo.es yahoo.es mail is handled by 1 mx2.mail.yahoo.com. yahoo.es mail is handled by 5 mx4.mail.yahoo.com. yahoo.es mail is handled by 1 mx1.mail.yahoo.com.
131
2. Que seamos atendidos por el servidor m as cercano (ahorrar ancho de banda): Ejemplo 8.4: Cuando nos conectamos a www.google.com desde un host en Espa na somos autom aticamente redirigidos a www.google.es1 :
$ /bin/ping www.google.es PING www.google.akadns.net (66.102.11.104) 56(84) bytes of data 64 bytes from 66.102.11.104: icmp_seq=1 ttl=234 time=94.1 ms : $ /bin/ping www.google.com PING www.google.akadns.net (66.102.11.99) 56(84) bytes of data. 64 bytes from 66.102.11.99: icmp_seq=1 ttl=235 time=94.1 ms : $ /usr/bin/host www.google.akadns.net www.google.akadns.net has address 66.102.11.99 www.google.akadns.net has address 66.102.11.104 8.3. ALIAS Y NOMBRES CANONICOS
1 N otese
que la carga de www.google.akadns.net est a distribuida.
132
8.4.
Arquitectura del DNS

El DNS es un sistema cliente-servidor, donde la aplicaci on servidora est a distribuida. Si esto no fuera as el sistema no escalar a porque:
1. Existir a un u nico punto de fallo. 2. Ser a un cuello de botella. 3. La base de datos con los registros DNS estar a alejada de la mayor a de los host de Internet. 4. Una base de datos enorme, en continuo cambio, recaer a en una sola m aquina y su mantenimiento ser a muy costoso. El tiempo de respuesta es ilimitado, aunque generalmente es peque no (d ecimas de segundo). En esto tiene mucho que ver con que el que el DNS se base en el UDP.
8.4. ARQUITECTURA DEL DNS
133
Los servidores de nombres se organizan jer arquicamente. Dependiendo del nivel en que se encuentran hablamos de tres tipos: (1) servidores autorizados (authoritative), (2) servidores de dominio del alto nivel (top-level domain) y (3) servidores ra z (root):
Para aumentar la resistencia a errores, en cada dominio suelen existir varios servidores de nombres. 8.4. ARQUITECTURA DEL DNS 134
8.4.1.
Servidores de nombres ra z
Hasta la fecha de Febrero del 2007, en Internet existen 13 servidores (generalmente muy potentes debido a la alta carga que deben soportar) de nombres ra z (http://www.root-servers.org).
135
8.4.2.
Servidores de nombres de alto nivel
Son responsables de los dominios de alto nivel: com, org, edu, gov, es, ...
La denici on del servidor de nombres de alto nivel (TLD) es un poco ambig ua porque la altura es una medida relativa con respecto a otros servidores de nombres subordinados. Ejemplo 8.5: Cada departamento de una universidad podr a tener su propio servidor de nombres para los hosts de ese departamento. Por ejemplo, el departamento de arquitectura de computadores y electr onica de la universidad de Almer a podr a tener un servidor para el dominio ace.ual.es. Adem as, la universidad podr a tener un servidor de nombres para el dominio ual.es. En este caso, el servidor de la universidad es un servidor de m as alto nivel que el del departamento. Sin embargo, por encima al menos hay dos servidores de mayor nivel: el que atiende al dominio es y los servidores de nombres ra z. 8.4. ARQUITECTURA DEL DNS 136
8.4.3.
Servidores de nombres autorizados
Cada organizaci on con hosts p ublicos (universidades, empresas, etc.) debe poseer al menos un servidor de nombre autorizado.
Por denici on, un servidor de nombre autorizado para el dominio Y debe de mantener los registros de resoluci on de todos los hosts xxx.Y. La fuente original de los registros de resolucion (tambi en llamados registros de recursos) est a en los servidores de nombres autorizados. Ejemplo 8.6: Continuado con el ejemplo anterior, el servidor de nombres del departamento de arquitectura de computadores y electr onica ser a el u nico servidor que debe mantener los registros de las m aquinas del departamento. De hecho, cuando se instalase una nueva m aquina, el proceso de alta de dicho host en el DNS consistir a en crear un nuevo registro s olo en dicho servidor.
137
8.5.
Las consultas
Cuando una aplicaci on solicita una resoluci on, primero consulta a uno de sus servidores de nombres locales (situados en el nivel m as bajo del mismo dominio), que suele ser uno de los servidores de nombres autorizados para ese nivel del dominio (los servidores de nombres pueden estar replicados para aumentar la abilidad del DNS). Esto se hace as porque es muy probable que la mayor a de las resoluciones sean referentes a hosts del mismo dominio. Ejemplo 8.7: Cuando el host gogh.ace.ual.es solicita una resoluci on, este consulta a filabres.ual.es o a alboran.ual.es. miro.ace.ual.es (otro host del mismo dominio) hace igual:
8.5. LAS CONSULTAS
138
gogh$ /usr/bin/host -v gogh.ace.ual.es Trying "gogh.ace.ual.es" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24177 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;gogh.ace.ual.es. ;; ANSWER SECTION: gogh.ace.ual.es. ;; AUTHORITY SECTION: ace.ual.es. ace.ual.es. ;; ADDITIONAL SECTION: filabres.ual.es. alboran.ual.es.
IN
172800
IN
193.147.118.57
172800 172800
IN IN
NS NS
filabres.ual.es. alboran.ual.es.
172800 172800
IN IN
A A
150.214.156.2 150.214.156.32
Received 126 bytes from 150.214.156.2#53 in 23 ms
8.5. LAS CONSULTAS
139
gogh$ /usr/bin/host -v miro.ace.ual.es Trying "miro.ace.ual.es" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24036 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION: ;miro.ace.ual.es. ;; ANSWER SECTION: miro.ace.ual.es. ;; AUTHORITY SECTION: ace.ual.es. ace.ual.es. ;; ADDITIONAL SECTION: filabres.ual.es. alboran.ual.es.
IN
172800
IN
193.147.118.63
172800 172800
IN IN
NS NS
filabres.ual.es. alboran.ual.es.
172800 172800
IN IN
A A
150.214.156.2 150.214.156.32
8.5. LAS CONSULTAS
140
En otras ocasiones una aplicaci on solicita la resoluci on de un nombre que no pertenece a su dominio y por tanto un servidor local no puede traducirlo. Entonces el servidor local se comunica con un servidor de nombres de ambito superior (que pudiera ser un servidor de nombres ra z). Ejemplo 8.8: filabres.ual.es (el servidor de nombres autorizado para todos los hosts de la universidad de Almer a) consulta a los servidores del CICA y de RedIris:
8.5. LAS CONSULTAS
141
$ /usr/bin/host -v filabres.ual.es Trying "filabres.ual.es" ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36716 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 7 ;; QUESTION SECTION: ;filabres.ual.es. ;; ANSWER SECTION: filabres.ual.es. ;; AUTHORITY SECTION: ual.es. ual.es. ual.es. ual.es. ual.es. ual.es. ual.es. ;; ADDITIONAL SECTION: filabres.ual.es. alboran.ual.es. dns1.cica.es. dns2.cica.es. sun.rediris.es. chico.rediris.es. ineco.nic.es.
IN
172800
IN
150.214.156.2
172800 172800 172800 172800 172800 172800 172800
IN IN IN IN IN IN IN
NS NS NS NS NS NS NS
filabres.ual.es. alboran.ual.es. dns1.cica.es. dns2.cica.es. sun.rediris.es. chico.rediris.es. ineco.nic.es.
172800 172800 17790 14781 19453 19673 2379
IN IN IN IN IN IN IN
A A A A A A A
150.214.156.2 150.214.156.32 150.214.5.83 150.214.4.35 130.206.1.2 130.206.1.3 194.69.254.2
8.5. LAS CONSULTAS
142
Ejemplo 8.9: Consultas recursivas. cis.poly.edu necesita obtener la dir IP de gaia.cs.umass.edu.
8.5. LAS CONSULTAS
143
8.5. LAS CONSULTAS 144
Ejemplo 8.10: Consultas iterativas. cis.poly.edu necesita obtener la dir IP de gaia.cs.umass.edu.
8.5. LAS CONSULTAS
145
8.6.
Caching
Cuando un servidor de nombres recibe una correspondencia DNS (una traducci on), normalmente realiza una copia en su memoria local, con la esperanza de que en poco tiempo se le realize la misma petici on. Si esta se produce, el servidor de nombres resuelve aunque en este caso no se trate del servidor autorizado. Como consecuencia el tiempo de respuesta se minimiza. Para poder tratar con hosts ef meros (que cambi an constantemente de IP), los registros de las cach es son destruidos despu es de un periodo de tiempo (normalmente 2 d as).
8.6. CACHING
146
8.7.
Los registros DNS

Los registros DNS son intercambiados por los servidores de nombres para proporcionar el servicio de resoluci on.
Los registros DNS tienen 4 campos: (Nombre, Tipo, Valor, TTL) El campo TTL es el tiempo de vida del registro e indica cu ando debe ser borrado de las cach es de los servidores. Los otros campos dependen del valor que toma el campo Tipo: 1. Si Tipo == A, Nombre es un host y Valor es su dir. IP. Este tipo de registro se utiliza para una resoluci on est andar. Por ejemplo, cuando preguntamos por la dir IP de dali.ace.ual.es recibimos un registro de la forma: (dali.ace.ual.es, 193.147.118.56, A, TTL) Estos registros est an de forma permantente en los servidores de nombres autorizados. 8.7. LOS REGISTROS DNS 147
Ejemplo 8.11: Consultando la dir IP de www.ual.es: $ /usr/bin/host -t A www.ual.es www.ual.es has address 150.214.156.62
2. Si Tipo == NS, Nombre es un dominio y Valor es su servidor de nombres autorizado. Por ejemplo, cuando queremos preguntar por el servidor de nombres autorizado para el dominio ual.es recibimos: (ual.es, dns.ual.es, NS, TTL) Ejemplo 8.12: Consultando el/los servidor/es de nombre/s de gogh.ace.ual.es: (ver Secci on 8.5)
8.7. LOS REGISTROS DNS
148
3. Si Tipo == CNAME, Nombre es un alias y Valor es su nombre can onico. Por ejemplo, cuando queremos conocer el nombre can onico del alias www.ace.ual.es recibimos:
(www.ace.ual.es, dali.ace.ual.es, CNAME, TLL) Ejemplo 8.13: Consulando el nombre can onico de www.ace.ual.es: $ /usr/bin/host -t CNAME www.ace.ual.es www.ace.ual.es is an alias for dali.ace.ual.es.
149
4. Si Tipo == MX, Nombre es un dominio de correo y Valor es el nombre can onico del servidor de correo. Por ejemplo, cuando utilizamos el alias de correo ual.es en realidad mandamos el e-mail a smtp.ual.es porque el DNS constesta con:
(ual.es, smtp.ual.es, MX, TLL) N otese que una compa n a puede tener el mismo alias par su servidor de correo y para su servidor Web. Cuando estamos utilizando el correo electr onico, el cliente DNS consultar a un registro DNS con Tipo == MX. Sin embargo, para obtener el nombre can onico del servidor Web, consultar a con Tipo == CNAME. Ejemplo 8.14: Consultando por el servidor de SMTP de la UAL: $ /usr/bin/host -t MX ual.es ual.es mail is handled by 10 mail.rediris.es. ual.es mail is handled by 2 smtp.ual.es.
150
8.8.
Regional Internet Registries

Controlan la asignaci on de direcciones IP y los nombres de dominio de alto nivel.
Actualmente existen 5 organimos de registro: 1. American Registry for Internet Numbers (http://www.arin.net) para Am erica del Norte. (ARIN)
2. R eseaux IP Europ eens Network Coordination Centre (RIPE NCC) (http://www.ripe.net) para Europa, Cercano Oriente Asia Central. 3. Asia-Pacic Network Information Centre (APNIC) (http://www.apnic.net) para el resto de Asia y las regiones del Pac co. 4. Latin American and Caribbean Internet Address Registry (LACNIC) (http://www.lacnic.net) para Am erica Latina y la regi on del Caribe. 8.8. REGIONAL INTERNET REGISTRIES 151
5. African Network Information (http://www.afrinic.net/) para Africa.
Centre
(AfriNIC)
Estos organismos est an coordinados por la Internet Corporation for Assigned Names and Numbers (ICANN) (http://www.icann.org).
152
Cap tulo 9
Compartici on de Ficheros (File Sharing)

8.8. REGIONAL INTERNET REGISTRIES 153
9.1.
El FTP (File Transfer Program)

La aplicaci on FTP permite la transmisi on de archivos entre hosts remotos.
Servidor
Conexi on de Control Servidor FTP Conexi on de Datos
Cliente
Cliente FTP
Archivos
Archivos
Utiliza TCP en ambas conexiones. 9.1. EL FTP (FILE TRANSFER PROGRAM) 154
La conexi on de control transporta la informaci on (en formato ASCII) necesaria para controlar la transmisi on de archivos (login/password, comandos para movernos por el sistemas de cheros remoto y mover archivos, listar directorios, ...). El servidor recibe la informaci on de control a trav es del puerto 21 y utiliza el File Transfer Protocol (FTP, descrito en el RFC 959). La conexi on de datos se utiliza para transferir 1 archivo (se establece una conexi on TCP para cada archivo). El servidor utiliza para esto el puerto 20.
9.1. EL FTP (FILE TRANSFER PROGRAM)
155
9.2.
Aplicaciones P2P (Peer-to-peer)

Muy alta escalabilidad (los clientes son tambi en servidores). Se utilizan para compartir archivos que residen en los hosts de los usuarios. Por esto a las aplicaciones P2P tambi en se les llama aplicaciones de compartici on de archivos entre iguales. Ejemplos: Napster, Gnutella, KaZaA, eMule y BitTorrent. Contexto complejo: t picamente los hosts no permanecen todo el tiempo encendidos (ni conectados) y rara vez disponen de una direcci on IP ja. Cuando un usuario busca un archivo obtiene una lista de hosts que en este momento est an conectados a y almacenan (al menos parcialmente) dicho archivo. Con esto se calcula un ndice de accesibilidad al chero.
9.2. APLICACIONES P2P (PEER-TO-PEER)
156
La transmisi on (generalmente mediante TCP) de un archivo se produce directamente (sin servidores intermedios) entre uno o varios de esos hosts y el del usuario (que ha realizado la b usqueda). Esto permite transmitir simult aneamente distintas parte del mismo archivo mediante m ultiples conexiones. En cuanto el usuario dispone de una secci on del archivo, autom aticamente entra a formar parte de la lista de iguales que disponen de el. As , mientras lo descarga, otros usuarios pueden comenzar a descargarlo de el. Por tanto, las aplicaciones P2P de compartici on de archivos son altamente escalables en lo que se reere a la cantidad de datos que pueden gestionar, porque aunque un nuevo usuario consume ancho de banda de salida de los iguales que contienen los archivos que se est a descargando, tambi en proporciona el suyo para que otros hagan lo mismo.
157
Sin embargo, en general los sistemas P2P presentan un problema de cuello de botella en los buscadores de contenidos. A continuaci on discutiremos las 3 estrategias existentes.
158
9.2.1.
B usqueda usando un directorio centralizado
Ejemplos: Napster, eMule y BitTorrent.

Existe un gran servidor (Napster) o un conjunto de servidores replicados (eMule) para que proporcionan servicio de directorio. En el caso de BitTorrent, cada chero .torrent especica un servidor que no es de b usqueda de contenidos, sino de b usqueda de peers para ese contenido. Cada igual (cuando se conecta) informa al servidor de su direcci on IP y de los contenidos que desea compartir. As , el servidor crea y mantiene una base de datos din amica que relaciona cada nombre de chero con el conjunto de IPs de los hosts que lo contienen.
159
Ventajas: la b usqueda de contenidos (por parte de los iguales) es sencilla porque la base de datos est a centralizada. Desventajas: el servidor central se convierte en el cuello de botella del sistema y si no existe ninguno funcionando, ning un igual puede buscar. 9.2. APLICACIONES P2P (PEER-TO-PEER) 160
9.2.2.
B usqueda usando un directorio descentralizado
Ejemplos: KaZaA, Overnet y eDonkey.

Un subgrupo de iguales son designados como l deres de grupo (supernodos) y cuando un nuevo igual se conecta, se le asigna uno de ellos.
161
Cada l der de grupo gestiona una base de datos con la informaci on de los iguales de su grupo. Cuando un usuario busca, lo hace primero dentro de su grupo y obtiene una contestaci on r apida. Si el usuario lo solicita, puede ampliar la b usqueda al resto de grupos ya que el l der de su grupo conoce a los dem as l deres. Cuando un usuario se conecta lo hace a partir de un nodo de arranque que conoce al menos uno de los l deres de grupo. Un nodo (un igual) se convierte en un l der normalmente porque el usuario lo solicita1 . Ventajas: Las bases de datos son localmente m as peque nas (un l der s olo se encarga de un subconjunto de los iguales, generalmente los m as pr oximos (menos hops)).
1 Probablemente a cambio de gastar ancho de banda extra en ser servidor de consultas, obtenga mayores prioridades a la hora de acceder a los cheros compartidos
162
El sistema es m as escalable y resistente a fallos porque ahora la base de datos global est a distribuida. Desventajas:
Cuando un l der se apaga, los iguales tienen que buscar otro l der vecino y regenerar la base de datos local. Los nodos no son todos iguales (los l deres, que tambi en funcionan como igual, consumen m as recursos que los iguales). Sigue existiendo la necesidad de un nodo inicial de arranque que conozca al menos un l der y que no puede apagarse.
163
9.2.3.
B usqueda mediante inundaci on
Ejemplo: Gnutella.
No existe una jerarqu a de servidores e iguales. Todos los participantes son iguales. Para que un nodo se conecte debe conocer, al menos, la direcci on IP de un nodo que ya forme parte de la red de compartici on. Las b usquedas se realizan mediante inundaci on de consultas :
164
1. El nodo que inicia la b usqueda pregunta primero a sus vecinos (inmediatos). 2. Los vecinos repiten el proceso con sus vecinos inmediatos (excepto con los que le han preguntado ya por lo mismo). 9.2. APLICACIONES P2P (PEER-TO-PEER) 165
3. Los nodos que contienen el archivo buscado se lo comunican al nodo vecino que le ha preguntado la b usqueda. Esto proceso acaba cuando las contestaciones llegan hasta el nodo que inici o la b usqueda.
Ventajas: Todos los nodos son iguales. No existen bases de datos con informaci on de directorio. Desventajas: El volumen de tr aco generado por las consultas suele ser muy alto. Por este motivo el area de b usqueda (n umero de hops) suele estar limitado. Lo malo de esto es que puede ocurrir que s olo se obtengan b usquedas parciales. Es necesario conocer un nodo de la red de compartici on para poder formar parte de ella (http://www.gnutella.com). 9.2. APLICACIONES P2P (PEER-TO-PEER) 166
9.3.
Acerca de la tasa de descarga

La tasa de descarga de las aplicaciones P2P depende normalmente de la tasa de subida a la red. Si esta es alta, la de descarga tambi en. En la pr actica no debe dedicarse el 100 % del ancho de banda de subida porque ahogar amos las conexiones TCP de descarga. Existen dos formas distintas de premiar al que m as env a: 1. Incrementando la prioridad del peer en las colas asociadas a los contenidos: Si subes m as, tardas menos tiempo de obtener conexiones. Esto es lo que ocurre en eMule, por ejemplo. 2. En BitTorrent descargas de m as peers si a estos t u les entregas m as datos que otros. Cada peer limita el n umero de peers conectados a 5, y peri odicamente se desconecta el peor para buscar otro mejor (que le entrege m as datos). Por tanto, nosotros tendremos muchos peers (y por lo tanto, mucha tasa de descarga) si a estos tambi en le entregamos muchos datos, porque nunca se desconectar an de nosotros. La idea es Si subes m as que
9.3. ACERCA DE LA TASA DE DESCARGA
167
otro hasta otro peer, este te seleccionar a a t m as tiempo para enviarte datos.
168
Cap tulo 10
Transmisi on de audio y v deo

9.3. ACERCA DE LA TASA DE DESCARGA 169
10.1.
Caracter sticas de la transmisi on de audio y v deo
Las aplicaciones que operan con secuencias de audio y v deo son altamente sensibles al retraso de extremo-a-extremo (end-to-end delay) de la red y a la variaci on de este retraso (jitter) [12]. Relacionado con lo anterior, generalmente necesitan una tasa de transmisi on promedio sostenida porque una vez que la secuencia comienza a ser reproducida no pueden ocurrir cortes por culpa de la red. Normalmente toleran cierta cantidad de p erdida de datos durante la transmisi on. En la mayor a de las transmisiones unicast se utiliza el UDP en lugar del TCP debido no hace falta controlar ni el ujo ni la congesti on. Si la transmisi on es multicast s olo puede utilizarse el UDP. DE AUDIO Y V 170 10.1. CARACTER ISTICAS DE LA TRANSMISION IDEO
10.2.
Ejemplos de aplicaciones
Stored Media Transmission Video on Demand Pause, rewind, fast-forward and indexing Yes, if extra band-width is available As large as possible UDP/TCP Live Media Transmission Internet TV, Internet Radio None Real-time Media Transmission Video-conferencing, IP telephony None
Example(s): Data-ow control:
Pre-fetching:
No way
No way
Buering: Internet transport protocol(s):
Jitter hiding (few seconds) UDP
< 500 ms UDP
10.2. EJEMPLOS DE APLICACIONES
171
10.3.
Obst aculos de la Internet actual
Tasas de transmisi on variables: las mayor a de los algoritmos de compresi on utilizados para codicar audio y v deo necesitan tasas de bits constantes. Latencias altas y variables: en muchos casos el retraso de extremoa-extremo es demasiado alto (especialmente cuando los paquetes atraviesan enlaces congestionados) y adem as el jitter de los paquetes es distinto de cero. No existen pol ticas de prioridad: todos los paquetes son tratados por igual por los routers, por tanto, paquetes que no son sensibles al tiempo compiten por los mismos recursos que paquetes que s lo son. No existe el concepto de stream: los paquetes pertenecientes al mismo stream de audio o de v deo pueden desordenarse en la red.
10.3. OBSTACULOS DE LA INTERNET ACTUAL
172
10.4.
C omo deber a evolucionar Internet?
A la hora de acomodar el tr aco sensible al tiempo, actualmente existen dos pol ticas radicalmente opuestas:
1. Permitir que las aplicaciones permitan reservar ancho de banda: Esto signica fundamentalmente que: Habr a que modicar las pol ticas de servicio de los paquetes en los routers, lo que implica un gran cambio en su dise no actual. Habr a que idear alguna forma de controlar c uanto y cu ando se reservan los recursos (pagando por ello, por supuesto). Habr a que etiquetar los paquetes con informaci on sensible al tiempo para que los routers los distinguieran. 2. Incrementar el ancho de banda y distribuir adecuadamente los contenidos: Los incrementos en las necesidades de ancho de banda se deben principalmente a que m as gente se conecta a la red y 173 10.4. COMO DEBER IA EVOLUCIONAR INTERNET?
tiene accesos de mayor velocidad a trav es de su ISP. Es l ogico esperar que dicho ISP gane dinero dando dicho servicio y que reinvierta parte de sus benecios en infraestructura. En denitiva, la red va a crecer al mismo ritmo que se demandan recursos. Existen t ecnicas de replicaci on de contenidos que pueden ayudar a disminuir enormemente el tr aco. Por ejemplo, los ISPs deber an instalar en sus servidores aquellas secuencia de audio y v deo que sus usuarios reclaman con mayor frecuencia. El concepto anterior deber a adem as extenderse entre los distintos niveles de ISP formando lo que se conoce como una red de superposici on multicast1 (multicast overlay network).
1 Es importante darse cuenta de que esta forma de realizar multicasting no tienen nada que ver con la que se realiza a nivel de IP. En IP del multicasting se realiza a nivel de red y en este caso el multicasting se hace a nivel de aplicaci on.
10.4. COMO DEBER IA EVOLUCIONAR INTERNET?
174
10.5.
10.5.1.
Problemas y soluciones en la transmisi on de audio y v deo

Eliminaci on del jitter
Por qu e se retrasan los paquetes? Aunque el emisor generalmente coloca los paquetes peri odicamente en la red, los routers puede introducir un retardo variable en ellos dependiendo del estado de sus colas. C omo solucionamos el problema? Retrasando la reproducci on un tiempo prudencial (la m axima latencia de extremo-a-extremo esperada o bien un retraso que genere una tasa de p erdida de paquetes admisible) o hasta donde sea posible (a lo sumo 500 ms en el caso de las transmisiones en tiempo real). DE AUDIO 175 10.5. PROBLEMAS Y SOLUCIONES EN LA TRANSMISION
10.5.2.
Recuperaci on de paquetes perdidos
Por qu e se pierden los paquetes?

Aunque el contenido de un paquete recibido puede ser diferente del enviado (lo que tambi en puede ser un problema), lo normal es que los paquetes lleguen (sin errores) o no lleguen debido a on de la red. los problemas de congesti En otras ocasiones, aunque el paquete llega al destino lo puede hacer demasiado tarde, especialmente en el caso de la transmisi on interactiva en tiempo real. En este caso el paquete se descarta en el receptor.
DE AUDIO 176 10.5. PROBLEMAS Y SOLUCIONES EN LA TRANSMISION
C omo solucionamos el problema? 1. Enviando informaci on redundante. Ejemplos: Insertando un paquete de paridad peri odicamente. Si cada n paquetes introducimos uno con la operaci on XOR de los bits de mismo ndice (posici on) de estos paquetes, podemos reconstruir un paquete perdido tras recibir los n + 1 paquetes. A nadiendo a cada paquete informaci on redundante sobre otro paquete (piggybacking). Podemos insertar en cada paquete informaci on (de baja calidad) sobre el paquete anterior. La informaci on piggibacked de baja calidad del paquete i se utiliza si se pierde el paquete i 1. Gr acamente:
Stream Original
Stream Redundante
Internet
Stream Recibido
Stream Reconstruido
2. Entrelazando la informaci on (interleaving) y luego aplicando alguna t ecnicas de predicci on o interpolaci on. El emisor coloca en cada paquete porciones de stream no consecutivos. Ejemplo:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
13
10
14
11
15
12
16
Internet
1 5 9 13 2 6 10 14 4 8 12 16
10
12
13
14
16
10.5.3.
Ordenaci on de paquetes
Por qu e se desordenan los paquetes?

Las tablas de routing de los routers son din amicas y por lo tanto, dos paquetes del mismo stream pueden viajar por caminos distintos con diferente longitud (en t erminos de tiempo). C omo solucionamos el problema? Insertando un n umero de secuencia2 en cada paquete.
2O
una estampa de tiempo.
10.6.
10.6.1.
Protocolos para la transmisi on de audio y v deo

Real-Time Protocol (RTP)
RFC 3550. Usa UDP.
DE AUDIO Y V 181 10.6. PROTOCOLOS PARA LA TRANSMISION IDEO
Estandariza la informaci on (como son los n umeros de secuencia, estampas de tiempo, el algoritmo de compresi on utilizado, etc.) que utilizan la mayor a de las aplicaciones de transmisi on de audio y v deo. El formato de la cabecera RTP es:
7 bits 16 bits 32 bits 32 bits +---------+----------+-------+-------------------+---------------+ | Payload | Sequence | Time | Synchronization | Miscellaneous | | type | number | stamp | source identifier | fields | +---------+----------+-------+-------------------+---------------+
Donde: Payload type: Indica la codicaci on (PCM, GSM, MPEG-1, MPEG-2, H.261, etc.). Ejemplos:
Sequence Number: Enumera los paquetes enviados. Time-stamp: indica el instante en que se gener o el primer bit de datos del paquete RTP. Se utiliza para sincronizar el emisor y el receptor.
Synchronization source identifier: identica al emisor del stream (la dir IP del host no sirve porque en un host pueden generarse varios streams (audio y v deo por separado, por ejemplo)).
10.6.2.
Real-Time Control Protocol (RTCP)
RFC 1889. Se utiliza junto con el RTP, normalmente sobre el siguiente puerto.
Sirve para que los miembros de una sesi on RTP se intercambien informaci on (t picamente mediante multicasting).
Peri odicamente, se transmiten informes de estad sticas u tiles para la transmisi on de audio y v deo: n umero de paquetes enviados, n umero de paquetes perdidos, jitter, n umero de hosts escuchando en una transmisiones multicast, ....
Su uso plantea un inconveniente, sobre todo en transmisiones multicast porque el emisor puede llegar a recibir una gran cantidad de informes (uno por cada oyente). En estos casos la frecuencia de env o de los informes se decrementa en funci on del n umero de participantes en las sesiones multicast, de forma que el RTCP consume siempre aproximadamente el 5 % del ancho de banda.
10.6.3.
Real-Time Streaming Protocol (RTSP)
RFC 2326. Normalmente usa TCP.

Se utiliza para controlar la transmisi on de streams de audio y v deo almacenados (pause, rewind, play, etc.). El player sabe que el stream soporta todas estas acciones porque su URL es de la forma: rtsp:// Los mensajes RTSP son muy similares a los utilizados por el protocolo FTP o HTTP. El cliente (C:) solicita acciones y el servidor (S:) las realiza. Un ejemplo de transmisi on ser a:
C: SETUP rtsp://audio.example.com/twister/audio RTSP/1.0 Transport: rtp/udp; compression; port=3056; mode=PLAY S: RTSP/1.0 200 1 OK Session 4231 C: PLAY rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=0S: RTSP/1.0 200 1 OK Session 4231 C: PAUSE rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 Range: npt=37 S: RTSP/1.0 200 1 OK Session 4231 C: TEARDOWN rtsp://audio.example.com/twister/audio.en/lofi RTSP/1.0 Session: 4231 S: 200 3 OK
10.7.
ReSerVation Protocol (RSVP)
RFC 2205.
Permite que los hosts realicen reservas de ancho de banda en Internet para transmisiones multicast. Las reservas expiran tras un determinado tiempo y tienen que ser peri odicamente realizadas. El host que reserva es el que recibe, no el que env a el stream. Los routers tienen que entender el RSVP y permitir las reservas. Qu e es en realidad una reserva? Para el RSVP una reserva es una indicaci on para uno o varios routers de c uanto quiere recibir el receptor, lo que no signica que lo tenga que recibir.
10.7. RESERVATION PROTOCOL (RSVP)
189
El RSVP se utiliza fundamentalmente en transmisiones multicast por capas de calidad. Veamos un ejemplo donde existen 3 capas (20 Kbps, 100 Kbps y 3 Mbps):
H2 C H1 A B H3
20 Kbps
100 Kbps
El router D solicita al router B recibir las 3 capas. El router C solicita al router B recibir las 2 primeras capas. El router B solicita al router A recibir las 3 capas. Hasta H2 llegan las dos primeras capas, aunque s olo hace uso de la primera. 10.7. RESERVATION PROTOCOL (RSVP)
D H4 3 Mbps
H5
3 Mbps
190
Cap tulo 11
Servicios de la capa de transporte de datos

10.7. RESERVATION PROTOCOL (RSVP) 192
11.1.
D onde corre la capa de transporte?
La capa de transporte se ejecuta s olo en los sistemas nales (hosts). Por qu e?

Actualmente la tasa de errores de las tecnolog as de transmisi on de datos son muy bajas. Esto posibilita que el control de ujo y de errores sea posible de extremo a extremo.
11.1. DONDE CORRE LA CAPA DE TRANSPORTE?
193
Se sit ua a nivel 4, entre la capa de aplicaci on (nivel 5) y la capa de red (nivel 3).
11.1. DONDE CORRE LA CAPA DE TRANSPORTE?
194
11.2.
Servicios proporcionados por la capa de transporte
Permite la comunicaci on a nivel de procesos1 [12]. A este servicio tambi en se le llama multiplexaci on. Proporcionado por el TCP y el UDP. Opcionalmente, corrige los errores de transmisi on (modicaci on, p erdida, duplicaci on y reordenaci on). S olo TCP. Opcionalmente, controla el ujo y la congesti on. S olo TCP. Opcionalmente, proporciona una conexi on del tipo byte-stream. S olo TCP. No garantiza la transmisi on de datos entre procesos en un tiempo limitado (principalmente porque la capa de red no garantiza la comunicaci on entre hosts en un tiempo limitado). TCP y UDP. 11.2. SERVICIOS PROPORCIONADOS POR LA CAPA DE
1 Que
pueden ejecutarse en una misma m aquina o sobre m aquinas diferentes.
195
11.3.
El servicio de multiplexaci on
En el host emisor se realiza una multiplexaci on (muchos procesos, una u nica capa de transporte/host) y en el proceso receptor una desmultiplexaci on (una u nica capa de transporte/host, muchos procesos). Nivel de Aplicaci on Nivel de Transporte Nivel de Red Nivel de Enlace Nivel F sico 11.3. EL SERVICIO DE MULTIPLEXACION 196
Puerto Mux
Puerto
Puerto Demux
Permite aprovechar el servicio de entrega de host-a-host proporcionado por la capa de red para ofrecer un servicio de entrega de proceso-aproceso.
Los procesos que se ejecutan dentro de un host son diferenciados por la capa de transporte a partir del puerto en el que est an escuchando. En los paquetes de datos gurar a el puerto destino.
11.3. EL SERVICIO DE MULTIPLEXACION
197
11.4.
Sobre los puertos
Permiten que m as de una aplicaci on utilice la red en un determinado intervalo de tiempo.

Cada puerto tiene asignado un n umero entre 0 y 65.535. Los puertos que comprenden desde el 0 al 1.023 est an reservados para aplicaciones est andares (como la Web que utiliza el puerto 80) [3]. Dicha lista es mantenida por el IANA (Internet Assigned Numbers Authority, http://www.iana.org) y se puede consultar en el RFC 1700.2
2 En
Unix, esta informaci on el S.O. la almacena en el chero /etc/services.
198
Cap tulo 12
El UDP (User Datagram Protocol)

11.4. SOBRE LOS PUERTOS 199
12.1.
El UDP
RFC 768.
Multiplexa [12] y desmultiplexa [3]. Transmite datagramas (paquetes de datos que son transmitidos independientemente y sin previo establecimiento de conexi on). Opcionalmente, comprueba si se han producido errores de transmisi on (no los corrige). Cuando se emplea el UDP s olo un proceso puede utilizar cada puerto.
12.1. EL UDP
200
12.2.
Formato del datagrama UDP
0 16 31 +-------------------------+-------------------------+ | SrcPort | DstPort | +-------------------------+-------------------------+ | Length | Checksum | +-------------------------+-------------------------+ | | | Data | | | +-------------------------+-------------------------+ SrcPort = puerto del proceso emisor. DstPort = puerto del proceso receptor. Length = longitud en bytes del datagrama UDP (cabecera y datos). Checksum = checksum de la cabecera, pseudo-cabecera y datos. Data = datos a trasmitir (hasta 64 KB).
12.2. FORMATO DEL DATAGRAMA UDP
201
El checksum es opcional. 1. Si checksum = 0 signica que no se calcula.

2. Si checksum = 0, se calcula teniendo en cuenta la pseudocabecera, la cabecera del datagrama UDP y los datos a transmitir. El puerto del proceso emisor se utiliza para que el proceso receptor pueda contestar.
12.2. FORMATO DEL DATAGRAMA UDP
202
12.3.
La suma de comprobaci on (checksum)
RFC 1071.
Forma simple de control de errores. Consiste en calcular la suma aritm etica m odulo 16 de todas las palabras del datagrama UDP y de la pseudo-cabecera, y calcular su complemento a 1 (negativo). Se puede ignorar, permitiendo as la recepci on de un datagrama con errores [12].
(CHECKSUM) 12.3. LA SUMA DE COMPROBACION
203
La pseudo-cabecera no se transmite. Se utiliza en el checksum para vericar, entre otras cosas, que el datagrama UDP llega al destino correcto y que el host origen es el que indica el IP. Su contenido es:
0 8 16 31 +---------------------------------------------------+ | SrcIPAddr | +-------------------------+-------------------------+ | DstIPAddr | +------------+------------+-------------------------+ | ZERO | PROTO | Length | +------------+------------+-------------------------+ SrcIPAddr = direcci on IP del host emisor (proporcionada por el IP). DstIPAddr = dir. IP del host receptor (prop. por la aplicaci on). ZERO = byte de relleno igual a 0. PROTO = identicador de protocolo (17 para UDP). Length = tama no del datagrama UDP. (CHECKSUM) 12.3. LA SUMA DE COMPROBACION 204
El receptor realiza dicha suma, pero usando adem as la suma de comprobaci on. Si el resultado es 0, entonces presumiblemente no existen errores de transmisi on.
(CHECKSUM) 12.3. LA SUMA DE COMPROBACION
205
12.4.
Cu ando usar el UDP?
Cuando queremos minimizar la latencia

Cuando usamos el UDP no existe establecimiento de conexi on. En aplicaciones como el DNS esto es fundamental. Con el UDP el emisor controla exactamente cu ando los datos son enviados.
Cuando se permite la p erdida de datos

Existen aplicaciones donde la no llegada de datos es peor que la llegada de ellos aunque modicados (probablemente en unos pocos bits). En aplicaciones como en la transmisi on de audio y v deo esto es importante.
12.4. CUANDO USAR EL UDP?
206
Cuando queremos hacer transmisiones multicast

UDP es ideal para transmitir de uno a muchos porque la replicaci on del datagrama UDP por parte de los routers no implica ninguna modicaci on en el comportamiento del emisor (en concreto, la tarea de emitir en unicast o en multicast es b asicamente la misma e independiente del n umero de receptores a los que llega el paquete). En aplicaciones como la difusi on de audio y v deo esto es esencial.
Cuando queremos controlar el ujo

Usando UDP, la aplicaci on sabe qu e datos son enviados en cada instante. En aplicaciones como en la transmisi on de ujos de audio el control de ujo lo impone la aplicaci on, no la capa de transporte. En aplicaciones como la transmisi on de audio y v deo esto es primordial.
12.4. CUANDO USAR EL UDP?
207
12.4. CUANDO USAR EL UDP? 208
12.5.
Sobre el control de la congesti on
El UDP no realiza control de la congesti on.

Transmitir datos de forma masiva usando UDP es una forma potencialmente peligrosa de congestionar la red.
209
Cap tulo 13
Transferencia able de datos

12.5. SOBRE EL CONTROL DE LA CONGESTION 210
13.1.
La transferencia able de datos
Se utiliza para transmitir datos sin errores de transmisi on y para controlar el ujo.
Se implementa en diferentes niveles [12], dependiendo de las necesidades: 1. Capa de aplicaci on. T picamente porque ning un nivel inferior la implementa o no lo hace adecuadamente. 2. Capa de transporte. Es el lugar natural de implementaci on (TCP) porque una gran cantidad de aplicaciones la utilizan. 3. Capa de enlace de datos. Se implementa a este nivel cuando la tasa de errores de un enlace es muy alta.
13.1. LA TRANSFERENCIA FIABLE DE DATOS
211
13.2.
Detecci on y correcci on de errores
Los c odigos de detecci on de errores introducen redundancia y los de correcci on de errores m as a un.
Los c odigos de detecci on de errores no indican los errores, s olo que se han producido. Los c odigos de correcci on de errores indican los errores y por tanto se pueden corregir. Ninguno de estos c odigos resuelve los problema de la p erdida de paquetes de datos y/o su desordenaci on.
Y CORRECCION DE ERRORES 13.2. DETECCION
212
13.3.
Protocolos ARQ
Los protocolos de solicitud de repetici on autom atica o protocolos ARQ (Automatic Repeat reQuest) retransmiten aquellos paquetes de datos que han llegado con errores. Utilizan c odigos de detecci on de errores. Nacieron como una alternativa automatizada a la vericaci on de eco1 [9].
de control manual de errores que se utiliza en programas de acceso remoto como Telnet. Este consiste en una t ecnica muy sencilla: cuando el usuario teclea un car acter, este es transmitido hasta la computadora y se reenv a de nuevo hacia el terminal que lo presenta en pantalla. Si el usuario se da cuenta de que lo que se muestra no coincide con lo que el esperaba, es el usuario el encargado de realizar la correcci on de errores oportuna usando los caracteres de control de los que dispone el terminal.
1 M etodo
13.3. PROTOCOLOS ARQ
213
13.4.
El protocolo ARQ con parada y espera (stop and wait)
Se trata del protocolo ARQ m as sencillo. Se basa en las siguientes reglas: 1. El emisor env a un paquete y espera a que el receptor conrme positiva o negativamente su recepci on. 2. El receptor env a un reconocimiento positivo2 o ACK (ACKnowledgement) cuando el paquete ha llegado sin errores. 3. El receptor env a un reconocimiento negativo o NAK (Negative AcKnowledgement) cuando el paquete ha llegado con errores, aunque esto es opcional3 . 4. El emisor lanza un temporizador para cada paquete enviado con el objetivo de saber cu anto tiempo debe esperar una conrmaci on.
2 Algo 3 Sin
13.4. EL PROTOCOLO ARQ CON PARADA Y ESPERA (STOP AND 214
similar a un acuse de recibo en el correo ordinario. embargo, su uso mejora el rendimiento [7].
13.4.1.
NAK vs s olo-ACK
Emisor
Datos ACK
Lanzamos Temporizador
Receptor Trama Aceptada
Emisor
Datos ACK Datos
Paramos y Lanzamos Temporizador
Ruido
Datos NAK Datos ACK
Trama Rechazada
Trama Rechazada
Trama Time-out Aceptada
Datos ACK
Trama Aceptada
Tiempo Con NAKs
Sin NAKs
N otese que la versi on que utiliza NAKs es m as r apida!
13.4.2.
Numeraci on de los paquetes
Todos los paquetes deben ser enumerados para evitar duplicados.

Emisor
Datos ACK Datos ACK
Emisor
Datos 0 ACK Datos 0 ACK
Trama Aceptada
Trama Rechazada
13.4.3.
Conrmaci on de los paquetes duplicados
Los paquetes duplicados deben conrmarse positivamente para evitar interbloqueos.

Emisor
Datos 0 ACK Datos 0
Receptor Trama Aceptada Trama Rechazada
Emisor
Datos 0 ACK Datos 0 ACK Datos 1
Receptor Trama Aceptada Trama Rechazada
Datos 0
Trama Rechazada
Trama Aceptada
13.4.4.
Numeraci on de los paquetes de conrmaci on
Los paquetes de conrmaci on deben enumerarse tambi en para evitar la p erdida de datos. En el ejemplo (izq), el primer Datos 1 se pierde.
Emisor
Datos 0
Emisor
Datos 0
ACK Datos 0 Datos 1 ACK Datos 0 ACK Datos 1
ACK 0 Datos 0
Trama Rechazada Conrmaci on Inesperada Trama Rechazada Trama Aceptada
Datos 1 ACK 0 Datos 1
Trama Rechazada
Trama Aceptada
13.4.5.
El protocolo falla si los paquetes se desordenan
El enlace de transmisi on debe ser punto a punto, es decir, los paquetes no pueden desordenarse [24].
Emisor
Receptor
0 0 ACK0 1 ACK1 0 ACK0 1 Aceptada Aceptada Aceptada
Aceptada
13.4.6.
Rendimiento pobre
ARQ con parada y espera no es adecuado cuando los retrasos de extremo a extremo y las tasas de transmisi on de los enlaces son altas [12, 19].
Emisor te RTT tp Receptor tp tr Emisor Receptor
Parada y Espera
Protocolo Ideal
Ejemplo 13.15: Supongamos que se est an transmitiendo paquetes de 1.000 bits a trav es de un canal de 1 Mbps y que el RTT del enlace es de 10 ms. En la gura
Emisor 1 ms 10 ms
Receptor
se muestra el time-line asociado a la transmisi on de un paquete de datos. El emisor necesita te = 103 b/paquete = 1 ms/paquete. 106 b/s
Como cada 11 ms se logran enviar 1.000 bits, es l ogico pensar que cada 11 s se lograr an enviar 106 bits. Por lo tanto la transmisi on es 11 veces m as lenta de lo deber a ser. 13.4. EL PROTOCOLO ARQ CON PARADA Y ESPERA (STOP AND 221
13.5.
ARQ con retroceso a n (go back n)
En GBN, el emisor puede transmitir tantos paquetes (n) como sean necesarios para que no se tenga que esperar (dejando de transmitir datos) a un reconocimiento. A esto se le llama pipelining. Ver applet. Ejemplo (n = 3): Emisor 1 2 3 Receptor
13.5. ARQ CON RETROCESO A N (GO BACK N )
222
13.5.1.
Longitud de la secuencia de conteo
La longitud l de la secuencia de conteo debe ser mayor que el n umero de paquetes n sin conrmar (l > n):
Emisor A0 B1 C2
Receptor A0 B1 C2
Emisor
Receptor
ACK0, Aceptar ACK1, Aceptar ACK2, Aceptar
A0 B1 C2
A0 B1 C2
ACK0, Rechazar ACK1, Rechazar ACK2, Rechazar
n=l=3
n = 3, l = 4
223
13.5.2.
Tratamiento de los errores
Un NAKk signica que hay que retransmitir el paquete k y siguientes. Ejemplo:

Emisor A0 B1
Receptor
ACK0, Aceptar NAK1, Rechazar Ignorar
C2 B1 C2
ACK1, Aceptar ACK2, Aceptar
n = 2, l = 3 13.5. ARQ CON RETROCESO A N (GO BACK N )
224
Ejemplo: A0 B1 C2 D3 E4 F5 C2 D3
Emisor
Receptor
ACK0, Aceptar ACK1, Aceptar NAK2, Ignorar Ignorar Ignorar ACK2, Aceptar ACK3, Aceptar
n = 5, l = 6 Los paquetes de datos que llegan fuera de secuencia, es decir, que no est an precedidos de los paquetes anteriores, son descartados. Esto se hace porque de todas formas el emisor los va a retransmitir. 13.5. ARQ CON RETROCESO A N (GO BACK N ) 225
13.5.3.
Conrmaci on acumulativa
Minimiza el n umero de conrmaciones:

1. Un ACKk signica que todos los paquetes enviados antes que el k - esimo paquete han llegado con exito. 2. Un NAKk signica que todos los paquetes enviados antes que el k - esimo han llegado con exito, pero el paquete k debe ser retransmitido.
13.5.4.
Piggybacking [24]
En la pr actica muchas veces tanto el emisor como el receptor son a su vez receptor y emisor (respectivamente). Una forma de disminuir el consumo de ancho de banda en este caso es transmitir las conrmaciones dentro de los paquetes de datos si estos se env an con la suciente frecuencia.
226
13.6.
ARQ con repetici on selectiva (selective repeat o SR)
GBN presenta un rendimiento pobre cuando los enlaces tienen altas tasas de transmisi on, altas latencias y relativamente altas tasas de errores porque un error en un u nico paquete de los que est an viajando (que pueden ser muchos) implica la retransmisi on de todos los que lo preceden [24].
SELECTIVA (SELECTIVE REPEAT O227 13.6. ARQ CON REPETICION
SR retransmite s olo aquellos paquetes que han llegado con errores, es decir, cuando se recibe un NAKk el emisor retransmite s olo el paquete k . Ejemplo:
Emisor A0 B1 C2 D3 E4 B1 F5
Receptor
Aceptar NAK1, Rechazar Aceptar Aceptar Aceptar ACK4, Aceptar
13.6.1.
Longitud de la secuencia de conteo
La longitud de la secuencia de conteo l debe ser al menos el doble que el n umero m aximo n de paquetes enviados sin conrmaci on (l 2n). En el ejemplo (izq.) A0 y B1 se duplican:
Emisor A0 B1 C2 Receptor A0 B1 C2 Emisor Receptor
Aceptar Aceptar ACK2, Aceptar Esperando 3, 0 o 1 Aceptar Aceptar Rechazar n = 3, l = 4
Aceptar Aceptar ACK2, Aceptar Esperando 3, 4 o 5 Rechazar Rechazar Rechazar
A0 B1 C2
A0 B1 C2
n = 3, l = 6
Tratamiento de los errores (otros ejemplos)

Un NAKk signica que hay que retrasmitir s olo el paquete k : Emisor
Receptor
A0 B1 C2 D3 E4 F5 C2 G6
Aceptar Aceptar NAK2, Rechazar Aceptar Aceptar Aceptar ACK5, Aceptar Aceptar n = 6, l = 12
Emisor A0 B1 C2 D3 E4 B1 F5
Receptor
Aceptar NAK1 Aceptar Aceptar Aceptar ACK4, Aceptar
n = 6, l = 12
13.7.
13.7.1.
Consideraciones sobre la eciencia

Tasa de transmisi on versus tasa de errores
La tasa de transmisi on se degrada al aumentar la tasa de errores [15]: Tasa de Transmisi on Capacidad del Enlace Overhead del Sistema de Transmisi on Todas las Tramas Afectadas por Errores 0 0 13.7. CONSIDERACIONES SOBRE LA EFICIENCIA 232 Tasa de Errores
13.7.2.
Latencia media versus tasa de errores
La latencia media aumenta al aumentar la tasa de errores: Latencia Media

No Existe Retransmisi on 0 0
tp + tr
Tasa de Errores
13.7. CONSIDERACIONES SOBRE LA EFICIENCIA
233
13.7.3.
Tasa de transmisi on versus tama no del paquete
La tasa de transmisi on depende del tama no del paquete [15]:

Tasa de Transmisi on Capacidad del Enlace Tama no Optimo
0 0 Overhead del Sistema de Transmisi on Retransmisi on Excesiva
Tama no de Trama
13.7. CONSIDERACIONES SOBRE LA EFICIENCIA
234
13.8.
Soluci on al desorden de los paquetes
Es necesario utilizar secuencias de conteo sucientemente largas [7]. Por ejemplo, en TCP se utiliza 232 . Para el caso concreto del ejemplo planteado para parada y espera es suciente contar hasta 3:
Emisor Emisor Receptor Receptor
0 0 0 ACK0 1 ACK1 0 ACK0 1 Aceptada Aceptada Aceptada Conrmaci on Inesperada Aceptada 2 Aceptada 0 ACK0 1 ACK1 2 ACK0 Aceptada Aceptada Ignorada
AL DESORDEN DE LOS PAQUETES 13.8. SOLUCION
235
Cap tulo 14
Control del ujo y de la congesti on

AL DESORDEN DE LOS PAQUETES 13.8. SOLUCION 236
14.1.
Control de ujo
El control de ujo adec ua la velocidad de transferencia del emisor a la velocidad de procesamiento del receptor [12].
Como hemos visto, los protocolos ARQ implementan impl citamente el control de ujo porque es el receptor el que marca qu e cantidad de datos desea recibir. Esto se hace en u ltima medida controlando el n umero m aximo de paquetes que pueden enviarse sin conrmaci on, en otras palabras, controlando el tama no de la ventana emisora.
14.1. CONTROL DE FLUJO
237
14.2.
Control de la congesti on
La congesti on es un t ermino que dene la carga excesiva de la red de comunicaci on [12].

En presencia de la congesti on ocurre que la tasa de entrada de datos a la red (en promedio) es inferior a la tasa de salida de datos de la red (tambi en en promedio). En la pr actica lo que se obtiene es una curva de la forma: Tasa de Salida
Congesti on
Tasa de Entrada
14.2. CONTROL DE LA CONGESTION
238
14.3.
Causas y costes de la congesti on

El nivel de congestion aumenta
Aumentan las retransmisiones innecesarias Aumentan las retransmisiones necesarias
Aumentan las latencias de los paquetes Los routers desechan paquetes
14.3. CAUSAS Y COSTES DE LA CONGESTION
239
14.4.
D onde se realiza el control de la congesti on?

1. Control de la congesti on entre extremos. La capa de red no proporciona ning un soporte expl cito a la capa de transporte para controlar la congesti on. De hecho, esta debe ser inferida por los sistemas nales bas andose exclusivamente en la observaci on del comportamiento de la red (p erdidas y retrasos de paquetes de datos) [12]. 2. Control de la congesti on asistido por la red. La capa de red (y en concreto los routers) proporcionan una retro-alimentaci on expl cita al emisor sobre el estado de la congesti on de la red.
Existen dos posibilidades:

240
Cap tulo 15
El TCP (Transmission Control Protocol)

241 14.4. DONDE SE REALIZA EL CONTROL DE LA CONGESTION?
15.1.
Servicios proporcionados
Protocolo de transporte por excelencia en Internet [21, 3, 12].

RFCs 793 (principalmente), 854, 1122, 1323, 2018, 2581 y 2988. Transferencia able de datos (control de errores y de ujo) basado en un protocolo ARQ con pipelining (mezcla de GBN y SR). Es orientado a conexi on (antes de transmitir esta se establece). Las conexiones son siempre unicast (entre dos procesos). No se puede realizar multicasting. Multiplexaci on: el TCP distingue procesos dentro del mismo host a partir del puerto en el que escuchan y a qui en est an escuchando. Control agresivo de la congesti on (por el bien com un). Full-duplex (comunicaci on en ambos sentidos al mismo tiempo). Los procesos ven byte-streams, no datagramas o segmentos. 15.1. SERVICIOS PROPORCIONADOS 242
15.2.
El contexto de trabajo
Corre encima del IP (capa de red) lo que signica que los paquetes de datos se pueden perder, desordenar, duplicar y llegar con errores.
Las latencias son muy variables lo que complica conocer la duraci on de los temporizadores utilizados para conocer cu ando hay que retransmitir los segmentos. Se implementa s olo en los sistemas nales. Los routers no distinguen entre paquetes UDP o TCP (ellos ven datagramas, no conexiones). Supone que la red no proporciona informaci on acerca de la congesti on, lo que signica un ahorro considerable en la complejidad de los dispositivos de nivel 3 (routers) e inferiores.
15.2. EL CONTEXTO DE TRABAJO
243
15.3.
15.3.1.
Transmisi on de datos
El segmento TCP
Aunque las aplicaciones leen y escriben un ujo de bytes, el TCP agrupa los bytes en segmentos que son transmitidos como los datagramas UDP. Esto se hace para minimizar el overhead provocado por las cabeceras de los segmentos (20 bytes como m nimo).
DE DATOS 15.3. TRANSMISION
244
El tama no de cada segmento depende de: 1. El MTU (Maximum Transfer Unit)1 de la red directamente conectada (en la que est a el host). Si el tama no del segmento es m as grande que el MTU, el IP segmentar a los segmentos y si uno se pierde, el TCP tendr a que retransmitir todo el segmento a nivel de transporte, no el sub-segmento (paquete) perdido a nivel de IP. 2. El instante en que el emisor realiza un push del ujo (enviar ahora). 3. Un tiempo m aximo de espera.
1 Tama no
m aximo de la trama de datos que el medio f sico soporta.
245
El formato del segmento TCP es: 0 4 10 16 31 +--------+-------+--------+-------------------------+ | SrcPort | DstPort | +-------------------------+-------------------------+ | Seq(uence Number) | +-------------------------+-------------------------+ | Ack(nowledgment) | +--------+-------+--------+-------------------------+ | HdrLen | 0 | Flags | (Receiver) Window | +--------+-------+--------+-------------------------+ | Checksum | UgrPtr | +-------------------------+-------------------------+ | Options (variable) | +-------------------------+-------------------------+ | | | Data | | | +-------------------------+-------------------------+ DE DATOS 246 15.3. TRANSMISION
Puerto del proceso emisor. Puerto del proceso receptor. Indice del primer byte de datos del segmento dentro del ujo de datos. Ack Siguiente byte esperado. Window Tama no de la ventana de recepci on del emisor del segmento (n um. de bytes que puede recibir sin enviar un nuevo ACK). HdrLen Longitud de la cabecera en palabras de 32 bits. Flags 6 bits que pueden representar: SYN = Sincronizaci on de n um. de secuencia. FIN = Fin de la transmisi on. RESET = Fin an omalo de la transmisi on. PUSH = Segmento enviado mediante un push. URG = Datos urgentes (no ignorar en receptor). ACK = Segmento contiene Ack. Checksum De la cabecera, pseudo-cabecera y datos. Obligatorio. UgrPtr Punto donde se nalizan los datos urgentes. Options MSS, marca temporal y factor de escala. Data Datos transmitidos. DE DATOS 247 15.3. TRANSMISION SrcPort DstPort Seq
La pseudo-cabecera en TCP es id entica a la del UDP, excepto en que el campo PROTO = 6.
248
15.3.2.
EL proceso de desmultiplexaci on
Est a basada en conexiones (par de puntos extremos), no en puertos.

El TCP diferencia a un proceso dentro de un host a partir del par de puntos extremos (punto extremo origen, punto extremo destino) donde un punto extremo est a formado por un par (IP del host, n umero de puerto). Por tanto, dos procesos distintos en un mismo host que escuchan en un mismo puerto pueden estar conectados a dos procesos distintos en otro host si estos utilizan puertos de salida diferentes (ver el progama netstat de Unix).
249
15.3.3.
Establecimiento de la conexi on Cliente Servidor
Se utiliza el Algoritmo Three-Way Handshake :

Petici on de conexi on SYN, Seq = x Conexi on aceptada SYN, Seq = y ACK, Ack = x + 1 Conexi on establecida ACK, Ack = y + 1
250
x, el n umero de secuencia incial, suele ser un n umero aleatorio fundamentalmente por dos motivos: 1. Para minimizar la probabilidad de que un segmento de una conexi on anterior ya terminada y que se encuentra viajando por la red sea tomado err oneamente por un segmento v alido de una conexi on posterior entre los mismos hosts [12]. 2. Para evitar el ataque del n umero de secuencia [16] que consiste en que un cliente ilegal puede suplantar a un cliente legal averiguando los n umeros de secuencia de los segmentos2 , usando su IP y su puerto de salida. Tras la suplantaci on el cliente legal podr a acceder a datos restringidos o cerrar la conexi on con el servidor. Los dos primeros segmentos son de control, ninguno puede transportar datos. El tercero s puede transportar datos [13]. A partir del tiempo
que seguro es m as sencillo si los n umeros de secuencia iniciales estuvieran predeterminados.
2 Lo
251
en l nea azul, los procesos pueden emitir y recibir segmentos normales con datos.
252
15.3.4.
El tama no m aximo de los segmentos
Los extremos de una transmisi on TCP necesitan conocer de antemano, a partir del establecimiento de la conexi on, c omo de grandes van a ser los payloads (la parte con datos) de los segmentos transmitidos [12]. A este valor se le llama tama no m aximo de segmento o MSS (Maximum Segment Size). Dicho valor se establece en el campo Options y depende normalmente del MTU de la red asociada. Si el MSS m as el tama no de las correspondientes cabeceras es mayor que el MTU, el IP fragmentar a el segmento. La p erdida (por parte del IP) de uno de los fragmentos signica que el TCP deber a reenviar todo el segmento. Por tanto, si el segmento es demasiado grande, la cantidad de datos retransmitidos por errores de transmisi on aumenta y disminuye la tasa efectiva de transmisi on.
253
15.3.5.
Transmisi on de datos urgentes
Existen situaciones donde los datos deben entregarse a la aplicaci on receptora lo antes posible. TCP indica esto en sus segmentos activando el ag URG. El tratamiento de los segmentos urgentes se produce s olo entre las capas de transporte del emisor y del receptor. El IP es ajeno y trata por igual a los segmentos, independientemente de si el ag URG est a activado. Cuando dicho ag est a activado, UrgPtr indica hasta qu e parte de los datos a partir del comienzo de los datos son de car acter urgente. Cuando llega un segmento con el ag UGR activado hasta el receptor, la parte urgente de este es entregado al proceso receptor lo antes posible.
254
15.3.6.
Cierre de la conexi on
Generalmente es el cliente el que cierra la conexi on. Esto se hace con el Algoritmo Four-Way Handshake :
Cliente FIN, Seq = x ACK, Ack = x + 1 ACK, Ack = x + 1 FIN, Seq = y ACK, Ack = y + 1 2 MSL Conexi on cerrada
Servidor
La aplicaci on servidora reconoce el cierre.
Conexi on cerrada
255
x e y son n umeros aleatorios (como en el establecimiento de conexi on, por motivos de seguridad). El cliente, tras la emisi on del segundo ACK espera t picamente 2 MSL3 (2 60 segundos en la mayor a de las implementaciones [19, 4]) que es intervalo de tiempo en el cual podr a recibirse otro ACK+FIN del servidor si el ACK del ciente se perdiera y no llegara al servidor. Si esto ocurriera, el servidor reenviar a el ACK+FIN y si este se retrasara lo suciente, el host cliente podr a establecer una nueva conexi on con la aplicaci on servidora, usando el mismo puerto de salida. Si a continuaci on llegara el ACK+FIN retrasado, dicha conexi on se cerrar a puesto que el cliente considera que el servidor desea cerrar la conexi on [19].
3 MSL o Maximun Segment Lifetime es el tiempo m aximo estimado de vida de un paquete IP, y por lo tanto de un segmento, en Internet.
256
15.3.7.
El diagrama de estados
Frecuentemente se representa mediante una m aquina de estados nita donde los nodos representan estados y las transiciones se etiquetan mediante evento /acci on. Los eventos puede estar provocados por la llegada de nuevos segmentos con informaci on de control (SYN, FIN, etc.) o porque la aplicaci on local realiza una llamada al TCP (Apertura Pasiva, Cierre, etc.). No siempre que se produzca un evento necesariamente se genera una salida. En este caso s olo cambiamos de estado. En rojo aparecen las transisiones normalmente seguidas por el cliente y en verde las seguidas por el servidor.
257
Conexi on
Lo que sea/RESET
e Ap
Comienzo
Cerrado
N SY a/ tiv Ac e) ra ent rtu (Cli
SYN Recibido
Apertura Pasiva (Servidor) ACK N+ Escucha /SY SYN ET RES
Cierre
Env o/S YN
CK /A
SYN/SYN+ACK
AC K/ K AC N+ SY
SYN Enviado
Cierre/SYN Cierre/FIN
F re/ IN
Establecido (Transmitir)
FIN
r Cie
/A CK
FIN Espera 1 ACK/ Tras 2 MSL
FIN/ACK Cerrando
FIN +A CK /
Espera de Cierre ACK/ Cierre/FIN+ACK Ultimo ACK
AC K
ACK/ Espera Cronometrada
(RTT m ax)
FIN Espera 2
FIN+ACK/ACK
Desconexi on
258
15.4.
Control de ujo y de errores
El TCP utiliza 2 colas circulares (ventanas deslizantes organizadas en bytes) en cada host, una para transmitir y otra para recibir.
La estructura de la cola de emisi on es la siguiente:

Proceso Emisor Capa de Aplicaci on TCP Ventana Deslizante Emisora Datos Enviados y Conrmados Datos Enviados pero no Conrmados Datos a Enviar sin Retardo Datos no Generados
Ultimo Byte Conrmado
Ultimo Byte Enviado
Ultimo Byte Generado
15.4. CONTROL DE FLUJO Y DE ERRORES
259
La estructura de la cola de recepci on es:
Proceso Receptor Capa de Aplicaci on TCP Ventana Deslizante Receptora Datos ya Consumidos Datos Conrmados pero a un no Consumidos Datos en Tr ansito Datos Recibidos pero no Conrmados Datos por Recibir
Ultimo Byte Consumido
Siguiente Byte Esperado
El control de ujo lo realiza el receptor controlando el tama no de la ventana emisora del emisor (campo Window). 260 15.4. CONTROL DE FLUJO Y DE ERRORES
Cuando la ventana emisora del emisor se hace 0, el proceso emisor se bloquea, lo que signica que el receptor no va a recibir m as datos, al menos temporalmente.4 Como el emisor no recibe un segmento de control del receptor si este no le env a un segmento con Window > 0, el emisor peri odicamente trata de enviarle 1 byte de datos al receptor. Mientras el receptor no puede recibir m as datos, un segmento con Window = 0 es enviado. Sin embargo, cuando el receptor puede recibir datos, este campo es > 0 y la ventana del emisor es ampliada.
4 Excepto
si llega un segmento con su URG activo.
261
15.4.1.
El tama no de las ventanas
Cuando el factor de escala5 del campo Options = 1, el tama no m aximo de la ventana del emisor es de 64 KB. Este l mite es demasiado bajo para la mayor a de los enlaces de media y larga distancia (RTT 100 ms) [19]: Enlace T1 Ethernet T3 Fast Ethernet STS-3 STS-12 STS-24 Capacidad 1,5 Mbps 10 Mbps 45 Mbps 100 Mbps 155 Mbps 622 Mbps 1,2 Gbps RTT Capacidad 18 KB 122 KB 549 KB 1,2 MB 1,8 MB 7,4 MB 14,8 MB
El receptor puede utilizar el factor de escala para aumentar hasta 232 bytes el tama no de la ventana del emisor. 15.4. CONTROL DE FLUJO Y DE ERRORES
5 Expresado
siempre como una potencia de 2.
262
15.4.2.
El tama no de los n umeros de secuencia
TCP utiliza n umeros de secuencia de 32 bits y el tama no m aximo de las ventanas del emisor y del receptor es de 216 216 = 232 bytes. El primer factor 216 est a determinado por el campo Window (de 16 bits) y el segundo por un factor de escala presente en el campo Options (de 8 bits, aunque s olo puede llegar a valer 16). N otese que estando TCP basado en el protocolo ARQ con pipelining, excepto en el caso extremo se cumple siempre que la longitud de la secuencia de conteo es siempre superior al tama no m aximo de la ventana emisora. Por desgracia esta condici on no es suciente, pudi endose dar el caso de que si la red retrasa sucientemente un segmento, este puede suplantar a otro en un momento posterior de dicha u otra transmisi on. Adem as, este factor aumenta proporcionalmente con la tasa de transmisi on de la red [12]. En otras palabras, teniendo en cuenta que el MSL = 60 segundos, 32 bits son sucientes para la mayor a de las situaciones, pero no para todas [19]: 15.4. CONTROL DE FLUJO Y DE ERRORES 263
Enlace T1 Ethernet T3 Fast Ethernet STS-3 STS-12 STS-24
Capacidad 1,5 Mbps 10 Mbps 45 Mbps 100 Mbps 155 Mbps 622 Mbps 1,2 Gbps
Tiempo hasta wrap-around 6,4 horas 57 minutos 13 minutos 6 minutos 4 minutos 55 segundos 28 segundos
Wrap-around = Situaci on que se produce cuando el n umero de secuencia sobrepasa el l mite 232 1 y comienza de nuevo por el principio. Para solucionar el problema, en el campo Options de los segmentos TCP se coloca una marca de tiempo. De esta forma el receptor puede saber cu al de los dos segmentos que tienen el mismo n umero de secuencia es el m as viejo.
264
15.4.3.
Retransmisi on r apida
El TCP no usa NAKs. Sin embargo, cuando se pierde un segmento el emisor puede percatarse de ello antes de que expire su temporizador si recibe uno o m as ACKs duplicados, es decir, cuando recibe un reconocimiento para un segmento que ya hab a sido reconocido. En la pr actica, cuando se reciben 3 ACKs del mismo segmento no se espera a que expire el temporizador y se realiza una retransmisi on r apida del segmento [12]. Los dise nadores del TCP estimaron que esperar s olo a una duplicaci on del ACK podr a fallar a la hora de estimar una p erdida cuando en realidad lo que ha ocurrido es que un segmento ha adelantado a otro.
265
15.4.4.
El s ndrome de la ventana tonta
Se genera con frecuencia cuando conectamos un emisor r apido a un receptor lento.

El receptor consume los datos byte a byte, y con cada uno de ellos env a un segmento de conrmaci on al emisor. El resultado es que los segmentos enviados s olo contienen un byte de datos lo que consume muchos recursos de la red.6 La misma situaci on aparece si el emisor es demasiado ansioso y no espera a tener sucientes datos antes de enviarlos. Para prevenirlo: 1. El receptor tratar a de evitar el anunciar ventanas peque nas. En la pr actica espera a recibir m n(Window/2, MSS) bytes,
6 La eciencia desde el punto de vista del TCP/IP ser a de 1/41, 20 bytes de la cabecera TCP y otros 20 de la IP.
266
donde Window es el tama no de la ventana del receptor. Esto implica que los ACKs pueden retrasarse indenidamente lo que supone un problema para el emisor (para el c alculo del timeout) y para la red (por las retransmisiones innecesarias debidos a dichos retrasos). En la pr actica el TCP limita el retraso m aximo de un ACK a 500 ms. 2. El emisor tratar a de evitar el usar segmentos peque nos (tinygrams ), es decir, acumular a datos hasta generar segmentos iguales al MSS mientras no reciba un ACK. As , si la aplicaci on emisora es el cuello de botella y la aplicaci on receptora no est a ansiosa (no env a ACKs constantemente), el tama no de los segmentos ser a grande. A este procedimiento se le conoce como Algoritmo de Nagle.
267
15.5.
Si el TCP percibe que la red se est a congestionando disminuye la tasa de transmisi on y viceversa.
Un emisor generalmente no conoce d onde ni por qu e se est a produciendo la congesti on. Simplemente experimenta un incremento en los RTTs y tal vez reciba alg un paquete ICMP para informar de esta situaci on. Ante ello, el TCP debe reducir la tasa de transmisi on [12]. Si la congesti on se hace m as severa los routers comienzan a descartar paquetes. El TCP debe percatarse de este problema y no retransmitirlos hasta que la congesti on cese. Por este motivo, el tama no de la ventana emisora no s olo depende de lo que indica el receptor (control del ujo), sino que tambi en va a tener en cuenta el nivel de congesti on.
268
En la pr actica, el tama no de la ventana emisora SenderW indowSize va a ser igual al menor del tama no indicado por el receptor Window y un valor CongestionW indowSize impuesto por el nivel de congesti on de la red, es decir,
SenderW indowSize = m n(Window, CongestionW indowSize). El valor CongestionW indowSize se calcula siguiendo las siguientes reglas: 1. Modo de arranque (relativamente) lento en el que se duplica CongestionW indowSize con cada ACK recibido. Este modo se utiliza desde que desaparece la situaci on de congesti on hasta que se alcanza la mitad del anterior valor de CongestionW indowSize (que en la gr aca se llama Threshold). 2. Modo de prevenci on de la congesti on en el que CongestionW indowSize crece en un MSS por cada ACK recibido. Este modo perdura hasta que se pierde un segmento (y entramos en una situaci on de congesti on) [3]. 269 15.5. CONTROL DE LA CONGESTION
3. Cuando se detecta la p erdida de un segmento por triple ACK recibido, entonces CongestionW indowSize CongestionW indowSize/2 (este hecho no se muestra en la gr aca).
4. Cuando se detecta la p erdida de un segmento porque expira su temporizador, entonces CongestionW indowSize 1 (este hecho se muestra en la gr aca).
270
271
15.5.1.
El tama no de los time-outs
Cada vez que se env a un segmento, el TCP arranca un temporizador y espera el correspondiente ACK. Si se termina el tiempo antes de que se conrme positivamente el segmento (recu erdese que no se utilizan conrmaciones negativas), el TCP asume que dicho segmento se perdi o o corrompi o, y lo retransmite. El problema radica en que las redes IP poseen latencias muy variables debido a su tama no, heterogeneidad, variaci on de la carga, nivel de congesti on, etc. Por este motivo el TCP utiliza un algoritmo adaptativo para calcular los time-outs.
272
15.5.1.1.
El algoritmo original
Estima el RTT promedio como EstimatedRT T EstimatedRT T + (1 ) SampleRT T ,

donde: EstimatedRT T es la estimaci on del RTT, SampleRT T es la medida del u ltimo RTT (medido como la diferencia en tiempo entre el instante en que se env a el segmento hasta que se recibe su conrmaci on) y es un n umero entre 0 y 1 de tal forma que si 0 entonces tiene mayor peso la u ltima medida del RTT, y si 1 entonces EstimatedRT T es menos dependiente de SampleRT T . La especicaci on original del TCP recomienda que 0,8 0,9. Finalmente, la estimaci on (promedio) para el time-out es T imeOut 2 EstimatedRT T . 15.5. CONTROL DE LA CONGESTION
273
15.5.1.2.
El Algoritmo de Karn/Partridge
El algoritmo original no funciona correctamente cuando ocurre una retransmisi on. En esta situaci on, el emisor no puede saber si el ACK recibido se corresponde con la primera o la segunda transmisi on (problema de la ambig uedad del ACK). Si supone que es con la primera y no ocurre as , el SampleRT T medido ser a demasiado largo. Si supone que es con la segunda y esto no es cierto, el c alculo es demasiado corto. Gr acamente:
Emisor Receptor Transm isi on sampleRTT
Retran smisi on
Emisor Receptor Transm isi on ACK Retra nsmisi sampleRTT on
ACK
274
Ambos errores son perjudiciales para el c alculo del T imeOut: Si el SampleRT T (y por lo tanto el T imeOut) es m as grande de lo que debiera ser, las retransmisiones ocurrir an con un periodo superior. As , el siguiente SampleRT T tras una retransmisi on tender a a crecer, y as sucesivamente. En consecuencia, un T imeOut excesivamente grande provoca a la larga una infrautilizaci on de los enlaces. Si el SampleRT T (y por lo tanto el T imeOut) es err oneamente peque no, el emisor retransmitir a innecesariamente antes de recibir el correspondiente ACK. Esto provocar a de nuevo que el SampleRTT sea err oneamente peque no y as sucesivamente hasta llegar a una situaci on de equilibrio donde en promedio cada segmento se retransmite 1 vez. Por tanto, un T imeOut excesivamente peque no incrementar a la congesti on de los enlaces. La soluci on: Ignorar los RTTs de los segmentos retransmitidos para computar el time-out . 15.5. CONTROL DE LA CONGESTION 275
Estimar el RTT s olo para los segmentos que no son retransmitidos acarrea un nuevo problema. Supongamos que debido a un aumento en la carga de la red o de la congesti on, el RTT aumenta por encima del time-out, lo que provoca una retransmisi on. Como el TCP va a ignorar el RTT de los segmentos retransmitidos, nunca va a actualizar la estimaci on para el RTT mientras las latencias sigan siendo altas y el ciclo continuar a. Por este motivo, adem as: Cada vez que se retransmite se dobla el time-out, hasta alcanzar 2MSL [3]. El motivo de este aumento exponencial del time-out obedece a que normalmente un aumento en las latencias se debe a problemas de congesti on y ante esta situaci on lo mejor es disminuir r apidamente la frecuencia de las retransmisiones.
276
15.5.1.3.
El Algoritmo de Jacobson/Karels
Por desgracia, la mejora del algoritmo b asico realizada por Karn y Partridge no funciona cuando los niveles de congesti on son altos, ya que las latencias son muy variables. En esta situaci on es muy importante no colapsar a un m as la red usando time-outs demasiado bajos. La mejora propuesta por Jacobson y Karels consiste en tener en cuenta adem as la variaci on de los RTTs, no s olo su media. Intuitivamente, si la varianza es baja, entonces EstimatedRT T es m as able. Por otra parte, una varianza alta signica que EstimatedRT T no debe ser considerado con tanto peso a la hora de calcular T imeOut. De esta forma, el c alculo actual del time-out en el TCP es Dif f EstimatedRT T DevRT T T imeOut donde: 0 1 es un factor que mide lo que Dif f afecta al nuevo c alculo 277 15.5. CONTROL DE LA CONGESTION SampleRT T EstimatedRT T, EstimatedRT T + Dif f, DevRT T + (|Dif f | DevRT T ), EstimatedRT T + 4 DevRT T,
del RTT y 0 1 es otro factor que hace lo mismo con la desviaci on estad stica del RTT.
Un ejemplo real [12]:
278
15.6.
Ejemplos
1. Enunciado: El host A desea enviar al host B 200 bytes de datos y el host B al host A 100 bytes de datos, utilizando el TCP. Por simplicidad, suponer que las transmisiones s olo se producen al comienzo de unos tics de reloj de periodo constante y que ning un segmento tarda m as de un tic en llegar al otro extremo. Suponer adem as que el MSS = 50 bytes para ambas estaciones, que el tama no de las ventanas receptoras queda determinado durante el establecimiento de la conexi on (50 bytes para A y 150 bytes para B), que los segmentos enviados entre el 4o y 9o tic de reloj (es decir, justo despu es del establecimiento de la conexi on) son corrompidos por el ruido, y que nunca se retrasan los ACKs. Dibujar el time-line asociado suponiendo que el n umero de secuencia inicial utilizado por A es 1.000 y por B es 2.000. Finalmente sup ongase un TimeOut de 5 tics. Soluci on: 15.6. EJEMPLOS 279
Seq = 1.000, 00 bytes Window = 50, SYN Ack Seq = 1.001, 50 bytes, Ack Seq = 1.051, 50 bytes, Ack Seq = 1.101, 50 bytes, Ack = 2.001 = 2.001 = 2.001 = 2.001
Seq = 2.000, 00 bytes, ACK = 1.001 Window = 150, SYN
Seq = 2.001, 50 bytes, Ack = 1.001
Seq = 1.001, 50 bytes, Ack = 2.001 Seq = 1.051, 50 bytes, Ack = 2.001 Seq = 1.101, 50 bytes, Ack = 2.001
Seq = 2.001, 50 bytes, Ack = 1.001 Ack = 1.001 Ack = 1.001
Seq = 1.001, 50 bytes, Ack = 2.001 Seq = 1.051, 50 bytes, Ack = 2.051 Seq = 1.151, 50 bytes, Ack = 2.051 Ack = 2.101 Seq = 1.201, 00 bytes FIN Ack = 2.102
Seq = 2.001, 50 bytes, Ack = 1.001 Ack = 1.151 Seq= 2.051, 50 bytes, Ack = 1.151 Ack = 1.201
Ack = 1.202 Seq = 2.101, 00 bytes, Ack = 1.202 FIN
15.6. EJEMPLOS
280
Receptora 2001 2050 1001
Emisora 1150
B
1001
Receptora
1150 2
1001 1051 1100 1150 1001 1051 1150
2051 2100 1151 2101 2150 1151 1201 1300 1300
1151
1300
2 1151 1201 1300
15.6. EJEMPLOS
281
Enunciado: Estamos transmitiendo cheros entre dos hosts mediante TCP y observamos que la tasa de transmisi on real es muy baja comparada con la capacidad f sica del enlace. Para mitigar este problema se proponen las siguientes soluciones (comentar su efectividad). a) Se ha observado que la latencia entre los nodos es muy alta por lo que se adopta aumentar el tama no de las ventanas emisoras en ambos nodos. Soluci on: Para maximizar la tasa de transmisi on el tama no de las ventanas emisoras debe ser siempre mayor o igual que el producto RTTcapacidad del enlace. Por lo tanto, aumentar el tama no de las ventanas puede ayudar. b ) El porcentaje de segmentos perdidos es muy alto, aunque la latencia es muy baja. En este caso se adopta disminuir el time-out en ambos nodos. Soluci on: El mecanismo que el TCP posee para solucionar los errores de transmisi on es la retransmisi on de las tramas tras expirar el correspondiente temporizador, lo que 15.6. EJEMPLOS 282
signica que si la latencia es muy baja, entonces el timeout tambi en deber a serlo. Por lo tanto, disminuir los tiempos de reenv o puede ayudar. c ) Se observa que el n umero de segmentos reenviados innecesariamente es muy alto. En este caso se propone aumentar el tama no de las ventanas emisoras en ambos nodos. Soluci on: El tama no de las ventanas no afecta al instante en que los segmentos son reenviados. Por lo tanto, esta medida no mejorar a las tasas de transmisi on. Lo que ayudar a es aumentar los time-outs. d ) Se observa que durante largos periodos de tiempo cesa la transmisi on de datos por llenarse la ventana emisora del emisor. Como soluci on se propone disminuir el tama no de la ventana emisora del emisor, pero aumentando su time-out. Soluci on: Si la ventana emisora en el emisor permanece largos periodos de tiempo llena es porque la red no es sucientemente r apida o porque el receptor es demasiado lento, si los comparamos con el emisor. Disminuir 15.6. EJEMPLOS 283
el tama no de la ventana emisora en el emisor nunca mejorar a la tasa de transmisi on, independientemente de c omo sea el time-out. Sin embargo, aumentar el timeout podr a ayudar ya que una red lenta y/o un receptor lento implican mayores RTTs con lo que el time-out deber a ser grande.
15.6. EJEMPLOS
284
Parte IV
La capa de red
285
Cap tulo 16
Servicios de la capa de red
15.6. EJEMPLOS
286
16.1.
El modelo de servicio
Comunicaci on de paquetes (datagramas) entre hosts.

La capa de red (en concreto el IP) corre en todos los routers y hosts de Internet.
16.1. EL MODELO DE SERVICIO
287
Es la responsable del encaminamiento (forwarding) de los datagramas y del routing (actualizaci on de las tablas encaminamiento) [21, 3, 12]. No existen conexiones (este concepto s olo se maneja a nivel del TCP).
Servicio m nimo: No existe control de ujo, ni de errores, ni de congesti on. No se garantiza la tasa de transmisi on, independientemente del intervalo de tiempo utilizado. Realmente best-eort ? Portabilidad extrema: El servicio denido por el IP es tan pobre que casi cualquier tecnolog a de red inventada hasta la fecha es capaz de proporcionarlo. Gracias a su sencillez, el IP mantiene a los routers simples. 16.1. EL MODELO DE SERVICIO 288
16.2.
El IP (Internet Protocol)
Se encarga del encaminamiento de los datagramas en Internet.

Existen actualmente dos versiones: la IPv4 (RFC 791) que es la que en estos momentos se utiliza y la IPv6 (RFC 2460, RFC 2373) que se planea utilizar en un futuro pr oximo. IPv6 es compatible hacia atr as con IPv4 (IPv6 es capaz de encaminar paquetes IPv4).
16.2. EL IP (INTERNET PROTOCOL)
289
16.2.1.
Formato de la cabecera en IPv4
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
290
Version: Versi on del protocolo IP (4). IHL (Internet Header Length): Tama no de la cabecera del paquete IP en palabras de 32 bits.
Type of Service (TOS): Indicaci on de la calidad de servicio que se espera recibir por parte de los routers (tr aco multimedia, informaci on sobre la congesti on de la red, etc.). Total Length: Tama no del datagrama IP (cabecera y datos) en bytes. Tama nos t picos son (debido principalmente a los MTUs de las redes) 1.500 bytes (Ethernet) y 576 bytes (PPP). Identification: Etiqueta creada por el emisor del paquete y que se utiliza cuando este se fragmenta. Flags: Bit 0: reserved, must be zero. Bit 1: (DF) 0 = May Fragment, 1 = Dont Fragment. Bit 2: (MF) 0 = Last Fragment, 1 = More Fragments. 16.2. EL IP (INTERNET PROTOCOL) 291
Fragment Offset: Oset del paquete cuando se ha fragmentado en palabras de 8 bytes. Time to Live (TTL): Valor que se decrementa cada vez que el paquete es retransmitido por un router. Cuando TTL = 0 entonces el paquete se destruye1 . Protocol: Protocolo al que va dirigido el paquete (RFCs 790, 1700 y 3232). Por ejemplo, cuando se transporta un paquete UDP se utiliza el 17, para TCP el 6, para ICMP el 1, etc. Header Checksum: C odigo de detecci on de errores que sirve para desechar el paquete si se han producido errores de transmisi on en la cabecera. Es una suma de todas las palabras de 16 bits de (s olo) la cabecera IP usando aritm etica en complemento a 1 (RFC 1071). Este valor es recalculado en cada hop (salto) porque en cada uno de ellos el TTL se decrementa. Source Address: Dir IP del host que gener o el paquete. 16.2. EL IP (INTERNET PROTOCOL)
1Y
se genera un paquete ICMP para el emisor.
292
Destination Address: Dir IP del host al que va dirigido el paquete. Options: Campo de longitud variable (desde 0 bytes) que se utiliza para diferentes prop ositos (almacenar rutas, colocar estampas de tiempo, etc.). Padding: Bits a 0 rellenando la cabecera hasta tener un tama no m ultiplo de 32 bits.
293
16.2.2.
Formato de la cabecera en IPv6
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | Next Header | Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Source Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Destination Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
294
Version: Versi on del protocolo (6). Traffic Class: Identica el tipo de tr aco. Por ejemplo, sirve para diferenciar el tr aco multimedia del que no es sensible al tiempo.
Flow Label: Identica a los paquetes de un mismo ujo de datos (tr aco multimedia). Payload Length: N umero de bytes de datos transportados (sin considerar la cabecera que es de tama no jo 40 bytes ). Next Header: Identica el protocolo que utiliza el IP (igual que IPv4). Hop Limit: TTL. Source Address: Dir IP del host origen del paquete. Destination Address: Dir IP del host destino del paquete.
295
16.2.3.
Fragmentaci on y ensamblaje
Cada tecnolog a de red posee un l mite en el tama no m aximo del paquete a transmitir (MTU). Por ejemplo, en Ethernet el l mite es de 1.500 bytes. El IP (en los hosts y en los routers), antes de enviar los datagramas los fragmenta de forma que ninguno de ellos tiene un tama no superior al MTU de la red directamente conectada. Durante el trayecto los datagramas pueden ser re-fragmentados si se atraviesa una red de menor MTU. S olo el IP del host destino realiza el ensamblaje (nunca los routers). Si alguno de los fragmentos no llega correctamente se desechan el resto de fragmentos. S olo en IPv4. No en IPv62 .
2 Si el MTU es demasiado peque no, el paquete IPv6 se destruye y se genera un paquete ICMP para el emisor.
296
Ejemplo
Comienzo de la Cabecera Ident. = X 1 Desp. =

0 8
Resto de la Cabecera
512 bytes de datos Comienzo de la Cabecera Ident. = X 0 Desp. = 0 Comienzo de la Cabecera Ident. = X 1 Desp. =
512 8
Resto de la Cabecera
Resto de la Cabecera 512 bytes de datos
1.400 bytes de datos
Comienzo de la Cabecera Ident. = X 0 Desp. =

1024 8
Resto de la Cabecera 376 bytes de datos
297
16.3.
El ICMP (Internet Control Message Protocol)
RFC 792. Informe de errores. Generado por routers y hosts. Los mensajes se encapsulan en paquetes IP. Los mensajes contienen los primeros 8 bytes del paquete IP que produjo el mensaje ICMP. Esto se hace para que el receptor del paquete ICMP conozca el paquete IP que produjo el error [13].
16.3. EL ICMP (INTERNET CONTROL MESSAGE PROTOCOL)
298
Mensajes ICMP: Tipo 0 3 3 3 3 3 3 4 8 9 10 11 12 C odigo 0 0 1 2 3 6 7 0 0 0 0 0 0 Fuente/Mensaje Nodo/Respuesta a un eco (ping) Router/Red destino inalcanzable Router/Host destino inalcanzable Host/Protocolo destino inalcanzable Host/Puerto destino inalcanzable Router/Red destino desconocida Router/Host destino desconocido Router/Apaciguar host (control de congesti on) Host/Petici on de eco Router/Anuncio de router Router/Descubrimiento de router Router/TTL expirado Nodo/Cabecera IP err onea
299
Ejemplo: traceroute
Programa de diagn ostico que permite conocer la ruta (routers) por los que pasan los paquetes que viajan desde nuestra m aquina (la que ejecuta el programa traceroute) hasta la m aquina destino. Uso: traceroute [flags] nodo destino Funciona aprovechando los servicios proporcionados por el ICMP (Internet Control Message Protocol), que se utiliza para conocer qu e est a ocurriendo en la red. Uno de los mensajes que el ICMP proporciona es el de tiempo excedido (time exceeded). Estos mensajes son generados s olo por los routers cuando no retransmiten un paquete porque su TTL (Time To Live) es 0.
300
El campo TTL gura en todas las cabeceras de los paquetes que son transmitidos a trav es de Internet y sirven para controlar c omo de lejos van a viajar. Cada vez que un paquete atraviesa un router su TTL se decrementa.
traceroute fuerza a que los distintos routers contesten con un ICMP TIME EXCEEDED, enviado paquetes con un TTL que se va incrementando en 1 en cada iteraci on. Entonces traceroute calcula los tiempos de ida y vuelta o RTT (Round-Trip Time) en 3 ocasiones. Otro de los mensajes que el ICMP proporciona es el de puerto inalcanzable (unreacheable port). Este tipo de mensaje es generado u nicamente por los hosts cuando les llega un paquete cuyo puerto destino no est a siendo escuchado por ninguna aplicaci on. traceroute obtiene el RTT del host destino aprovechando el mensaje este, ya que el puerto ICMP PORT UNREACHEABLE generado por destino usado (el 33.434) no suele utilizarse para otro prop osito. Un ejemplo de funcionamiento ser a: 16.3. EL ICMP (INTERNET CONTROL MESSAGE PROTOCOL)
301
traceroute www.cica.es traceroute to ataman.cica.es (150.214.4.16), 30 hops max, 38 byte packets 1 rou118.ual.es (193.147.118.1) 0.701 ms 0.574 ms 0.480 ms 2 11.0.0.5 (11.0.0.5) 0.840 ms 0.783 ms 0.767 ms 3 192.168.1.1 (192.168.1.1) 0.653 ms 0.644 ms 0.608 ms 4 almeria.cica.es (150.214.231.97) 1.795 ms 1.761 ms 2.740 ms 5 jds-rt2-almeria.cica.es (150.214.0.33) 13.333 ms 13.354 ms 12.946 ms 6 ataman.cica.es (150.214.4.16) 13.476 ms * 18.044 ms
Para conocer m as sobre esta utilidad, en una m aquina Unix ejecutar man traceroute o visitar la p agina Web www.traceroute.org.
302
16.4.
El DHCP (Dynamic Host Conguration Protocol)
RFC 2131. Protocolo cliente-servidor, UDP, puerto 67. Los clientes lo utilizan para obtener de forma autom atica los par ametros de conexi on (dir IP, m ascara, gateway y DNS) de la red. Especialmente utilizado en el caso de hosts m oviles. T picamente se utiliza para asignar un pool de X dirs IP a Y hosts de forma din amica, donde generalmente X Y . Cuando un host arranca se pone en contacto con su servidor DHCP preguntando a la dir de broadcast3 (255.255.255.255) y usando la dir IP origen 0.0.0.0.
3 Lo
que se env a a esta dir IP le llega a todos los nodos de la red local.
16.4. EL DHCP (DYNAMIC HOST CONFIGURATION PROTOCOL) 303
En una misma red pueden existir varios servidores DHCP. En principio todos contestar an y es el cliente quien elige. Las conguraciones pueden asignarse de forma temporal o de forma indenida.
304
Cap tulo 17
Addressing (Direccionamiento)
16.4. EL DHCP (DYNAMIC HOST CONFIGURATION PROTOCOL) 305
17.1.
Direccionamiento en IPv4
Cada enlace que se conecta a un host o un router en Internet lo hace a trav es de un interface y cada interface tiene asociada una dir IP.1
En IPv4 las dirs IP son de 32 bits y en IPv6 de 128 bits. Formato: MSb LSb +---------------+-------------------+ | Dir de la Red | Dir del Interface | +---------------+-------------------+ Las dirs IP son jer arquicas. La primera parte identica la red a la que est a conectada el interface y la segunda parte, el interface dentro de la red.
ICANN (Internet Corporation for Assigned Names and Numbers, RFC 2050) es la autoridad global de asignaci on de dirs IP. Maneja tambi en los servidores de nombres ra z. Los administradores de redes acceden a la ICANN a trav es de las respectivas autoridades regionales de registros de Internet (ejemplos: ARIN (American Registry for Internet Numbers), RIPE (R eseaux IP Europ eens) y APNIC (Asia Pacic Network Information Centre)).
1 La
17.1. DIRECCIONAMIENTO EN IPV4
306
Por denici on, todos los interfaces de una misma red tienen la misma direcci on de red . En IPv4 se suele utilizar la notaci on decimal punteada para representar las dirs IP, donde cada byte se traduce a su forma decimal y se separa por un punto del resto de bytes de la direcci on. Ejemplo: 00001111 00010001 00000001 00000010 = 15.17.1.2 Para diferenciar en una dir IP la direcci on de la red y la direcci on del interface, se utiliza la m ascara de red. En el caso de IPv4 son 32 bits y para IPv6 128. Las m ascaras son siempre de la forma 1111...111000...000 donde se cumple que dir IP AND m ascara = dir Red y que 17.1. DIRECCIONAMIENTO EN IPV4 307
dir IP MOD m ascara = dir Interface.
17.1. DIRECCIONAMIENTO EN IPV4
308
17.2.
Clases de dirs IP
Las redes IP se consideran de diferentes clases dependiendo de los bits m as signicativos [12]:
En IPv4:
17.2. CLASES DE DIRS IP
309
17.2. CLASES DE DIRS IP
Allocation ------------------------------------Reserved Unassigned Reserved for NSAP (ATM) Allocation Reserved for IPX (Novell) Allocation Unassigned Unassigned Unassigned Aggregatable Global Unicast Addresses Unassigned Unassigned Unassigned Unassigned Unassigned Unassigned Unassigned Unassigned Unassigned Unassigned Link-Local Unicast Addresses Site-Local Unicast Addresses Multicast Addresses
En IPv6:
Prefix (binary) -----------0000 0000 0000 0001 0000 001 0000 010 0000 011 0000 1 0001 001 010 011 100 101 110 1110 1111 0 1111 10 1111 110 1111 1110 0 1111 1110 10 1111 1110 11 1111 1111
Fraction of Address Space ------------1/256 1/256 1/128 1/128 1/128 1/32 1/16 1/8 1/8 1/8 1/8 1/8 1/8 1/16 1/32 1/64 1/128 1/512 1/1024 1/1024 1/256
310
17.3.
Sub-netting y dirs CIDR en IPv4
Sub-netting en RFC 950.

CIDR (Classless InterDomain Routing) en RFC 1519. Originalmente s olo se permit an tres clases de dirs IPv4 y por lo tanto s olo exist an 3 tama nos posibles para las redes IP. El tipo de red se distingu a por sus primeros bits. Clase A B C Bits Iniciales 0 10 110 N umero de Redes 28 216 224 N umero de Interfaces 224 216 28
17.3. SUB-NETTING Y DIRS CIDR EN IPV4
311
Los dise nadores de Internet pronto se dieron cuenta de que en muchos casos de produc a un desperdicio considerable de dirs IP (por ejemplo, hac a falta una red de clase B para conectar a ella 257 interfaces).
La m ascara de red (aparte de indicar la direcci on de la red) dene (independientemente de los bits iniciales de las dirs IP) el tama no de la red. As , una red de clase C se denota por X.Y.Z.0/24, porque la m ascara de red, para todos los interfaces conectados a este tipo de red, posee 24 unos. A este tipo de dirs IP, donde la m ascara de red puede tener cualquier n umero M de bits y por tanto la red puede contener hasta 232M interfaces, se les llama dirs IP CIDR.
312
Usando sub-netting, cualquier rango de dirs IP se puede dividir en conjuntos disjuntos de dirs IP y cada conjunto puede ser una (sub)red diferente. Ejemplo (sub-netting en una red de clase B):
1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0| NETWORK | SUBNET | Inferface Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
313
Ejemplo de red IP
H1
H2 .4 .1 R1 .1 Red 150.214.6.8/29 .2 R2 .1 Red 150.214.6.16/30 .2 R3 .1
.3
.2
Red 150.214.1.20/30 .2
H3
Red 150.214.6.24/29 .3 .4 H5
H4
314
17.4.
Redes privadas
RFC 1918.
Permiten conectar m as nodos a la red que el proporcionado por el espacio de dirs IPv4. Se implementan usando NAT. La IANA ha reservado los siguientes bloques de dirs IP privadas: Bloque 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 Desde 10.0.0.0 172.16.0.0 192.168.0.0 Hasta 10.255.255.255 172.31.255.255 192.168.255.255
17.4. REDES PRIVADAS
315
17.5.
NAT (Network Address Translation)
Se dene en los RFCs 2663 y 3022.

Se ejecuta en un router o un host que funciona como un router. El router tiene asignada s olo una dir IP p ublica. Esta pertenece al interface que conecta el router con Internet. Todos los interfaces de la red interna (normalmente privada) poseen dirs IP que no son visibles desde Internet. Todos los nodos de la red interna acceden a Internet mediante la IP del router NAT, en otras palabras, todos ellos utilizan la dir IP del interface p ublico del router NAT. El router utiliza una tabla de traducci on NAT para asociar conexiones [Dir IP P ublica, puerto (router)] [Dir IP Privada, puerto (host)]. 17.5. NAT (NETWORK ADDRESS TRANSLATION) 316
La tabla NAT tiene 3 columnas: Puerto p ublico

Dir IP privada
Puerto privado
Cuando un host privado env a un paquete para un host p ublico, el router NAT inserta una entrada en la tabla de traducci on NAT con un puerto libre y utiliza el puerto p ublico asignado para todos los paquetes salientes con la misma (Dir IP Privada, Puerto privado). Cuando llega un paquete para una estaci on de la red privada, el router busca en su tabla de traducci on NAT usando como clave (Puerto p ublico) y encamina hacia la red privada el paquete usando la dir IP privada y el puerto (privado). N otese que en cualquier caso no son posibles m as de 216 conexiones simult aneas a trav es del router NAT. 17.5. NAT (NETWORK ADDRESS TRANSLATION) 317
Ejemplo En la siguiente gura el host de la red privada con IP 10.0.0.1 accede a un servidor Web p ublico con IP 128.119.40.186.
318
Cap tulo 18
Forwarding (Encaminamiento)
17.5. NAT (NETWORK ADDRESS TRANSLATION) 319
18.1.
El proceso de encaminamiento
Realizado por los routers y en ocasiones los hosts (cuando tienen m as de un interface).
Se realiza para cada paquete a nivel de IP. Algoritmo (encaminamiento de un paquete): 1. Extraer la dir IP destino del paquete. 2. Buscar la dir IP en la tabla de encaminamiento. 3. Seleccionar el interface de salida correspondiente.
18.1. EL PROCESO DE ENCAMINAMIENTO
320
18.1.1.
B usqueda en las tablas de encaminamiento
Las tablas de encaminamiento poseen (al menos) los campos: Red destino
Interface de salida
La tabla de encaminamiento est a indexada por la direcci on de red destino. En IPv4 existen hasta 232 redes diferentes y en IPv6 hasta 2128 . Para evitar tener que disponer f sicamente de una entrada para cada posible red, las tablas de encaminamiento normalmente s olo poseen una entrada por cada red que puede alcanzarse directamente desde el nodo. Dependiendo del tama no de dicha red, la entrada tiene m as o menos bits. Las redes destino pueden ser alcanzadas a trav es de diferentes interfaces de salida. En este caso, el algoritmo de b usqueda seleccionar a la entrada m as larga (la red m as peque na).1 18.1. EL PROCESO DE ENCAMINAMIENTO
1 Recu erdese
que por denici on, unas redes contienen a otras.
321
Ejemplo
Un router que posee 4 interfaces y que se encuentra en la red 11001000 00010111 000 (200.23.0.0/19) podr a tener una tabla de encaminamiento como la siguiente:
Red de destino 11001000 00010111 00010 (200.23.16.0/21) 11001000 00010111 00011000 (200.23.24.0/24) 11001000 00010111 00011 (200.23.24.0/21) en otro caso Interface de salida 0 1 2 3
Un paquete dirigido a 11001000 00010111 00010xxx xxxxxxxx ser a encaminado al interface 0. Un paquete dirigido a 11001000 00010111 00011000 xxxxxxxx ser a encaminado al interface 1. Un paquete dirigido a 11001000 00010111 00011XXX xxxxxxxx ser a encaminado al interface 2, si XXX!=000. 18.1. EL PROCESO DE ENCAMINAMIENTO 322
Ejemplo
En Unix, la tabla de encaminamiento del host se puede consultar con el comando:
$ /sbin/route Kernel IP routing table Destination Gateway 193.147.118.0 * loopback gogh.ace.ual.es default 193.147.118.1
Genmask 255.255.255.0 255.0.0.0 0.0.0.0
Iface eth0 lo eth0
Seg un dicha tabla (del host gogh.ace.ual.es): Cualquier paquete que vaya dirigido a una estaci on de la red local (red de clase C) debe ser entregado al interface de red eth0. Cualquier paquete que vaya dirigido al loopback (una red virtual de clase A formada s olo por el host) debe ser entregado al interface de red lo. 18.1. EL PROCESO DE ENCAMINAMIENTO 323
Finalmente, cualquier paquete que no vaya dirigido ni a la red local ni al loopback, ser a entregado al interface de red eth0.
324
Ejemplo
El router R2 de la red
H1 .3
H2 .4 .1 R1 .1 Red 150.214.0.0/24 .2 R2 .2 .1 Red 150.214.2.0/24
Ethernet
PPP .2 R3 .1
.2
Red 150.214.1.0/24
H3
Red 150.214.3.0/24 .3 .4 H5
H4
FDDI
325
tendr a una tabla de encaminamiento igual a: 18.1. EL PROCESO DE ENCAMINAMIENTO
Destination 150.214.0.0 150.214.1.0 150.214.3.0 loopback default
Gateway * * * R2 150.214.1.2
H1 .3 H2 .4 .1 R1 .1
Genmask 255.255.255.0 255.255.255.0 255.255.255.0 255.0.0.0 0.0.0.0
Iface eth0 ppp0 fddi0 lo ppp0
Red 150.214.0.0/24 .2 R2 .2 .1
Red 150.214.2.0/24
Ethernet
PPP .2 R3 .1
.2
Red 150.214.1.0/24
H3
Red 150.214.3.0/24 .3 .4 H5
H4
FDDI
326
Ejemplo
Supongamos una red clase B con direcci on 149.76.0.0 dedicada a un campus universitario. Debido a su excesivo tama no (216 interfaces/red), esta red se divide en redes clase C (28 interfaces/red). F sicamente se distribuye una dorsal (backbone) de FDDI y a ella se conectan las pasarelas (gateways) que unen la FDDI con las redes Ethernet de los diferentes departamentos. C omo administrar as las direcciones de red y qu e direcciones asignar as a las pasarelas? Cu antos departamentos de hasta 254 estaciones pueden formarse? Especique la tabla de encaminamiento para la pasarela 149.76.0.4 suponiendo que todas las redes posibles del campus est an dadas en alta en ella.
327
Internet .1 R1
.2 149.76.2.0/24
.1
R2 .2
149.76.172.0/24 .2 .1 R172 .172 149.76.0.0/24
149.76.64.0/24 .1 .2
R64 .64
254 routers 253 departamentos Todas las redes son de clase C S olo se muestra el primer host de cada departamento
.128 R128 .1 .2 149.76.128.0/24
328
El router 149.74.0.4 posee la siguiente tabla de routing: Destino 149.76.2.0 149.76.3.0 149.76.4.0 149.76.5.0 . . . 149.76.254.0 127.0.0.0 default Router 149.76.0.2 149.76.0.3 * 149.76.0.5 . . . 149.76.0.254 * 149.76.0.1 M ascara 255.255.255.0 255.255.255.0 255.255.255.0 255.255.255.0 . . . 255.255.255.0 255.0.0.0 0.0.0.0 Interface fddi0 fddi0 eth0 fddi0 . . . fddi0 lo fddi0
329
18.2.
Agregaci on de direcciones
Cuando dos (o m as subredes) poseen el mismo prejo, pueden agregarse formando una red mayor (v ease el ejemplo de la p agina 322).
Dicha agregaci on hace posible reducir el tama no de las tablas de encaminamiento (eliminando en dicho ejemplo la entrada de la red m as larga que est a incluida en la otra entrada). La agregaci on no signica que las redes se fusionen. La agregaci on s olo afecta a las tablas de encaminamiento.
DE DIRECCIONES 18.2. AGREGACION
330
Ejemplo de agregaci on
Sea la siguiente conguraci on, donde existen dos ISPs que conectan a una serie de redes a Internet. El primer ISP Fly-By-Night da servicio a 8 organizaciones y el segundo ISP ISPs-R-Us hace lo mismo a un n umero indeterminado de ellas. Las redes conectadas a trav es de Fly-By-Night poseen un prejo com un igual a 200.23.16.0/20. Las redes conectadas a trav es de ISPsR-Us tienen todas el prejo 199.31.0.0/16. Gracias a la agregaci on, el router que conecta Internet con Fly-ByNight s olo posee una entrada en su tabla de encaminamiento con la red destino 200.23.16.0/20, aunque en realidad existen 8 redes dentro de esta. Lo mismo ocurre con el router que conecta a ISPs-R-Us con Internet.
331
332
Ejemplo de des-agregaci on
Imaginemos que Fly-By-Night no es un ISP muy serio y que la Organizaci on 1 se pasa a ISPs-R-Us. Sin embargo, la Organizaci on 1 no desea modicar sus dirs IP. Esta nueva conguraci on debe afectar a los routers que conectan ambos ISPs con Internet para hacer que los paquetes dirigidos a la Organizaci on 1 sean encaminados a trav es de ISPs-R-Us. Supongamos (por simplicidad) que Fly-By-Night e ISPs-R-Us se conectan a Internet a trav es del mismo router. En la tabla de encaminamiento de este router gurar a una entrada para la red 200.23.16.0/20 y otra para la red 200.23.18.0/23. Como 200.23.16.0/20 es prejo de 200.23.18.0/23, cada vez que a este router lleque un paquete dirigido a la Organizaci on 1, usar a el prejo m as largo (200.23.18.0/23) y el encaminamiento ser a correcto. M as espec camente, su tabla de encaminamiento ser a: DE DIRECCIONES 18.2. AGREGACION 333
Red de destino . . .
Interface de salida . . . El que lleva a ISPs-R-Us El que lleva a ISPs-R-Us El que lleva a Fly-By-Night . . .
199.31.0.0/16 200.23.18.0/23 200.23.16.0/20 . . .
334
335
Cap tulo 19
Routing (Rutado)
336
19.1.
Qu e es el routing?
Si forwarding consiste en transmitir un paquete hasta el siguiente nodo, routing es el proceso de determinar el mejor camino para realizar el encaminamiento. En otras palabras, routing es el proceso que se realiza para determinar las tablas de encaminamiento. El problema del routing se trata generalmente modelando las redes mediante grafos. En ellos, los nodos representan a los routers de la red y los arcos a los enlaces que los interconectan.
ES EL ROUTING? 19.1. QUE
337
La soluci on m as frecuente que buscan los algoritmos de routing consiste en encontrar el camino m as corto que une a cada par de routers (el router origen del paquete y el router destino). Como es l ogico, el router origen es en realidad el rst-hop router (el que conecta con Internet a la red que contiene el host que en realidad genera el paquete) y el router destino es el last-hop router (el que conecta con Internet ES EL ROUTING? 338 19.1. QUE
a la red que contiene el host que es el destino del paquete). Evid entemente, ninguno de estos routers son realmente ni el origen ni el destino del paquete. En realidad son las redes que se conectan a estos routers. Sin embargo, el problema del routing queda resuelto si obviamos este hecho porque independientemente de la red destino a la que nalmente va dirigido el paquete, este debe de llegar forzosamente al last-hop router, y el mismo razonamiento puede realizarse para el rst-hop router.
ES EL ROUTING? 19.1. QUE
339
19.2.
La red como un grafo

H1 .3 H2 .4 150.214.0.0/24 .1 R1 .1 .2 R2 .2 Ethernet 150.214.3.0/24 FDDI H4 .3 150.214.2.0/24
Ethernet
.1 Point-to-Point .2 .1 R3 150.214.1.0/24
.2
H3
.4 H5
R3
R1
R2
19.2. LA RED COMO UN GRAFO
340
19.3.
Sobre los costes de los caminos
Se utilizan para determinar las rutas optimas.

Dependen de: 1. Latencia de los enlaces (distancia f sica entre nodos). 2. Tasa de transmisi on (capacidad) de los enlaces. 3. Carga de los enlaces. 4. Tasa de errores de los enlaces. 5. Cuestiones pol ticas (espionaje) y/o comerciales (coste econ omico).
19.3. SOBRE LOS COSTES DE LOS CAMINOS
341
19.4.
Routing jer arquico y sistemas aut omomos
Internet est a formada por una estraticaci on de sistemas aut onomos o ASs (Autonomous Systems) de diferente nivel que son administrados de forma independiente. Dentro de cada sistema aut onomo se realiza el routing como se considera necesario, sin tener en cuenta lo que ocurre en el resto de ASs. Lo u nico que debe vericarse es que el protocolo de routing que ejecutan los routers del AS debe de ser el mismo (para que se entiendan entre s ). En la siguiente gura se muestra un ejemplo de varios AS interconectados entre s . En cada AS existen routers que ejecutan un protocolo de routing intra-AS y al menos 1 que ejecuta un protocolo inter-AS. Gracias al protocolo intra-AS los routers de cada AS saben c omo encaminar dentro de su AS y gracias al protocolo inter-AS (al menos) uno de los routers de cada AS sabe c omo encaminar entre ASs. 342 19.4. ROUTING JERARQUICO Y SISTEMAS AUTOMOMOS
19.4. ROUTING JERARQUICO Y SISTEMAS AUTOMOMOS
343
Por tanto, el routing jer arquico permite esconder la complejidad a de los ASs de nivel inferior a los ASs de nivel superior. De esta manera: 1. Las tablas de encaminamiento son mucho m as peque nas. De hecho, un router de un AS s olo necesita conocer los routers de su AS. 2. El n umero de mensajes intercambiados por los routers es mucho menor y la mayor a se producen dentro de los ASs. As los algoritmos de routing din amicos convergen m as r apidamente. 3. Permite la autonom a administrativa (algoritmo de routing, pol ticas, etc.).
19.4. ROUTING JERARQUICO Y SISTEMAS AUTOMOMOS
344
19.5.
El RIP (Routing Information Protocol)
RFCs 1058 y 2453.

Routing intra-AS (interior gateway protocol [13]). Creado por Xerox e inclu do en la versi on BSD (Berkeley Software Distribution) del UNIX en 1982. Los routers utilizan el algoritmo de routing Distance-Vector. El coste de cada enlace es siempre 1. Por tanto, el algoritmo minimiza el n umero de saltos (hops). El coste m aximo permitido para un camino (path) es 15 (ASs peque nos). Los routers se intercambian (entre vecinos inmediatos) sus tablas de routing (vectores con las distancias a todas las redes del AS y routers por los que encaminar hacia ellas) cada 30 segundos (no necesariamente de forma s ncrona) y cuando reciben nuevos datos acerca del AS, re-calculan los caminos m nimos. 19.5. EL RIP (ROUTING INFORMATION PROTOCOL) 345
Si un router tras el c alculo detecta alguna variaci on en su tabla de routing, esta es comunicada a todos sus vecinos directamente conectados.
Se utilizan paquetes UDP y el puerto 520 [12]. Transcurridos 180 segundos sin recibir informaci on desde el router X, todo router conectado directamente a X lo considera inalcanzable (unreacheable). En este momento re-calcula los caminos m nimos (teniendo en cuenta este evento) y transmite la tabla de routing con los nuevos caminos a todos sus vecinos. El n umero m aximo de redes destino en cada mensaje es a lo sumo 25 [13].
19.5. EL RIP (ROUTING INFORMATION PROTOCOL)
346
El RIP es utilizado por el demonio routed que corre, en la capa de aplicaci on y como un proceso m as, en el seno del sistema operativo UNIX y compatibles.
347
Ejemplo
Sea el SA de la gura:
348
En un momento determinado la tabla de routing del router D podr a ser: Destination subnet w y z x . . . Next router A B B . . . Number of hops to destination 2 2 7 1 . . .
Si m as tarde recibe la siguiente tabla de routing de A: Destination subnet z w x . . . Next router C . . . Number of hops to destination 4 1 1 . . .
349
Entonces la tabla de routing del router D pasar a a ser: Destination subnet w y z x . . . Next router A B A . . . Number of hops to destination 2 2 5 1 . . .
350
19.6.
El protocolo OSPF (Open Shortest Path First)
RFC 2328. Routing intra-AS. Se dise n o como el sucesor del RIP y puede manejar AS m as grandes. Los intercambios de los mensajes con informaci on acerca del routing son autenticados. Los routers utilizan el algoritmo de routing Link-State para calcular los caminos de coste m nimo. Los costes de los enlaces no tienen que ser siempre 1 como en el RIP. As , el administrador de la red podr a tener en cuenta la capacidad de los enlaces, por ejemplo. El c alculo de los caminos m nimos se produce cada vez que un router detecta un cambio en el coste de uno de sus enlaces o en su defec19.6. EL PROTOCOLO OSPF (OPEN SHORTEST PATH FIRST) 351
to, cada 30 minutos. En cualquier caso, los routers envian a todos los dem as routers del AS (broadcasting) los costes de los caminos calculados.
Se utiliza directamente el IP, puerto 89 [12]. Soporta multicasting (RFC 1584).
19.6. EL PROTOCOLO OSPF (OPEN SHORTEST PATH FIRST)
352
Soporta routing jer arquico (permite denir ASs dentro de los ASs):
19.6. EL PROTOCOLO OSPF (OPEN SHORTEST PATH FIRST)
353
19.7.
El BGP (Border Gateway Protocol)
RFCs 1771 (versi on 4), 1172, 1173 y 1930.

Routing inter-AS.1
Utiliza el algoritmo Distance-Vector. 19.7. EL BGP (BORDER GATEWAY PROTOCOL)

1A
los routers que conectan sistemas aut onmos entre s se les llama border gateways.
354
BGP usa intensivamente el routing jer arquico. A la hora de calcular las rutas se tienen en cuenta factores econ omicos, pol ticos, de seguridad, etc.
Se emplea el TCP, puerto 179. Los routers se intercambian CDIRized prexes (direcciones de redes que contienen otras redes de forma jer arquica) [13]. Por ejemplo (ver la siguiente gura), el router A.c enviar a al router B.a informaci on sobre las redes que son alcanzables desde A.c y B.a enviar a a A.c informaci on sobre las redes que son alcanzables desde B.a. N otese que si la agregaci on es optima, el intercambio de informaci on es m nimo:
19.7. EL BGP (BORDER GATEWAY PROTOCOL)
355
19.7. EL BGP (BORDER GATEWAY PROTOCOL)
356
19.8.
19.8.1.
Algoritmos de routing
Algoritmo de routing Link-State
Consta de dos fases: 1. Fase de ooding (inundaci on). En ella, cada router broadcasts el estado de sus enlaces (destino2 y coste) al resto de routers del AS. 2. Fase de c alculo de los caminos m nimos. Se utiliza normalmente el algoritmo de Dijkstra [19].
19.8. ALGORITMOS DE ROUTING
2 N otese
que el origen est a determinado por quien env a en mensaje.
357
Flooding de los estados de los enlaces

Cada router env a el estado de sus enlaces a todos los routers directamente conectados.
Todo router que recibe un mensaje con informaci on del tipo anterior retransmite el mensaje a trav es de todos sus enlaces excepto por el que lleg o el mensaje. Cuando los mensajes son creados se les asigna un TTL que es decrementado cada vez que es retransmitido. De esta forma garantizamos que la fase de inundaci on naliza.
358
Algoritmo de Dijkstra
1. Sean dos listas Conrmed y Tentative de ternas (Destination, Cost, NextHop ). Inicializar Conrmed con el nodo que ejecuta el algoritmo y Tentative con los nodos que pueden alcanzarse desde el. 2. Mientras Tentative no est e vac a: a) Mover desde Tentative a Conrmed la terna de menor coste. b ) Recarcular las distancias a los posibles destinos con esta terna. 3. En cada entrada de Conrmed queda almacenada la distancia m nima a cada nodo de la red y el primer nodo que se tiene que atravesar para conseguirlo.
359
Ejemplo
Dada la red de la gura
A 5 3 1 B
2 2 D 3 4
C 1 F 2 E
obtener la tabla de encaminamiento para el nodo E seg un el algoritmo Link-State. 19.8. ALGORITMOS DE ROUTING 360
Conrmed (E,0,-)
(E,0,-) (F,2,F) (E,0,-) (F,2,F) (E,0,-) (F,2,F) (D,3,D) (E,0,-) (F,2,F) (D,3,D) (E,0,-) (F,2,F) (D,3,D) (C,3,F) (E,0,-)
Tentative (B,4,B) (D,3,D) (F,2,F) (B,4,B) (D,3,D) (B,4,B) (D,3,D) (C,2+1,F) (B,4,B) (C,3,F) (B,4,B) (C,3,F) (A,3+5,D) (B,4,B) (A,8,D)
Comentarios Inicio
Movemos (F,2,F) Actualizamos desde (F,2,F) Movemos (D,3,D) Actualizamos desde (D,3,D) Movemos (C,3,F)
(F,2,F) (D,3,D) (C,3,F) (E,0,-) (F,2,F) (D,3,D) (C,3,F) (B,4,B) (E,0,-) (F,2,F) (D,3,D) (C,3,F) (B,4,B) (E,0,-) (F,2,F) (D,3,D) (C,3,F) (B,4,B) (A,5,F)
(A,3+2,F)
desde (C,3,F) Movemos (B,4,B)
(A,5,F)
(A,5,F)
Actualizamos desde (B,4,B)
Movemos (A,5,F) y terminamos
(B,4,B)
Actualizamos
361
19.8.2.
Algoritmo de routing Distance-Vector
Tambi en llamado algoritmo de Bellman-Ford [19].

Emplea el mismo modelo de red mediante un grafo, donde los nodos representan routers y los arcos enlaces de transmisi on. Es un algoritmo progresivo (calcula las rutas progresivamente, mejor andolas en cada iteraci on) y distribuido (los c alculos se realizan parcialmente en cada router).
Algoritmo de Bellman-Ford
Cada cierto tiempo todos los routers vecinos intercambias los vectores con distancias y se recalculan los vectores de distancias. Lo anterior tambi en ocurre cuando un router detecta una variaci on en la distancia a algunos de sus vecinos.
362
Ejemplo
Dada la red de la gura
A 5 3 1 B
2 2 D 3 4
C 1 F 2 E
obtener las tablas de encaminamiento seg un el algoritmo DistanceVector. 19.8. ALGORITMOS DE ROUTING 363
A B C D E F
Tablas A 0 3/A 2/A 5/A
de encaminamiento B C D 3/B 2/C 5/D 0 1/D 0 2/D 1/B 2/C 0 4/B 3/D 1/C
iniciales. E F 4/E 1/F 3/E 0 2/F 2/E 0
A B C D E F
Tablas de encaminamiento tras el primer intercambio de vectores. A B C D E F 0 3/B 2/C 4/C 7/B 3/C 3/A 0 3/D 1/D 4/E 6/E 2/A 3/D 0 2/D 3/F 1/F 4/B 1/B 2/C 0 3/E 3/C 7/B 4/B 3/F 3/D 0 2/F 3/C 6/E 1/C 3/C 2/E 0 364
Tablas de encaminamiento tras el segundo y denitivo intercambio de A B C D E A 0 3/B 2/C 4/C 5/C B 3/A 0 3/D 1/D 4/E C 2/A 3/D 0 2/D 3/F D 4/B 1/B 2/C 0 3/E E 5/F 4/B 3/F 3/D 0 F 3/C 4/C 1/C 3/C 2/E
vectores. F 3/C 4/D 1/F 3/C 2/F 0
365
Cap tulo 20
Multicasting (Multidifusi on)

19.8. ALGORITMOS DE ROUTING 366
20.1.
Modelos de transmisi on
1. El modelo unicast donde un emisor realiza un env o y los datos llegan a un u nico receptor. Ejemplo: las transmisiones TCP.
2. El modelo multicast: Un emisor realiza un env o y los datos llegan a muchos receptores. Ejemplos: actualizaciones de software, streaming de audio y v deo, pizarras compartidas, juegos interactivos, ... El multicasting permite ahorrar ancho de banda si lo comparamos con la versi on unicast de las aplicaciones. El broadcasting se considera un caso particular del modelo multicast en el que los datos llegan a todos los posibles receptores.
20.1. MODELOS DE TRANSMISION
367
20.2.
El multicasting a nivel de aplicaci on y de red

1. A nivel de la capa de aplicaci on, mediante dos t ecnicas diferentes: a) Multiple-unicast: el emisor genera una copia de los datos para cada posible receptor. b ) Mediante overlay networks: en este caso, el emisor s olo genera una copia y en algunos puntos estrat egicos de la red se coloca un programa de replicaci on que hace las veces de router multicast. 2. A a nivel de la capa de red, emitiendo una u nica copia de los datos. Los routers multicast se encargan de replicar los paquetes que transportan los datos tanto como sea necesario.
El multicasting puede realizarse fundamentalmente de dos maneras:

Las dos u ltimas alternativas tienen dos grandes ventajas: Y DE RED 20.2. EL MULTICASTING A NIVEL DE APLICACION
368
1. La redundancia de la emisi on es mucho menor. 2. El emisor no tiene por qu e conocer los posibles receptores (que pueden ser muchos).
La tercera adem as simplica el software a nivel de aplicaci on.
Y DE RED 20.2. EL MULTICASTING A NIVEL DE APLICACION
369
20.3.
20.3.1.
Algoritmos de broadcasting
Flooding
Los routers env an los paquetes recibidos a todos sus vecinos, excepto al que se los entrega. Para evitar que los lazos generen una sucesi on innita de replicaciones (broadcast strorm) se utilizan dos t ecnias: 1. Sequence-number-controlled ooding. En cada paquete se incluye un n umero de secuencia que lo identica. Este n umero junto con la dir IP origen del paquete sirve para que cuando un router lo recibe, este lo replica si y s olo si antes no ha sido replicado. 2. Reverse path forwarding (RPF). En este caso se utiliza s olo la dir IP del paquete. Un router lo replica si y s olo si el (router) est a en la ruta de distancia m nima al router origen del paquete. V ease la siguiente gura (A es el router origen): 20.3. ALGORITMOS DE BROADCASTING 370
20.3. ALGORITMOS DE BROADCASTING
371
20.3.2.
Spanning-tree broadcast
Es m as optimo que el fooding (cada router recibe s olo una copia de los datos).
Se basa en que los routers s olo env an los datos a trav es del minimum spanning tree. El arbol de expansi on m nimo es un arbol (y por tanto un grafo sin ciclos) que utiliza a todos los nodos del grafo y que posee un coste m nimo.
372
Para determinar el minimum spanning tree se puede utilizar el algoritmo de Steiner [12], pero este es muy costoso en t erminos de tiempo (es un problema de complejidad exponencial O(xN ), donde N es el n umero de nodos del grafo y x es una costante) y por este motivo se utilizan otros algoritmos menos costosos basados en heur sticas. 20.3. ALGORITMOS DE BROADCASTING 373
Uno de los algoritmos usados es el algoritmo del punto de encuentro (rendezvous point) para el c alculo del spanning tree1 : 1. Denir un rendezvous router y hac erselo saber a todos los dem as routers. 2. Todos los dem as routers env an un mensaje tree-join hacia el rendezvous router usando el camino m nimo (que s es determinado por los algoritmos de routing unicast). 3. Cada router que recibe un mensaje tree-join a nade al spanning tree el enlace por el que ha llegado el mensaje. 4. El mensaje se retransmite hacia el rendezvous router si el router todav a no pertenece al spanning tree. Ejemplo (E es el punto de encuentro):
ocasiones llamado tambi en aproximaci on basada en el centro para el c alculo del spanning tree.
1 En
374
375
20.4.
Los grupos multicast
La clase D de dirs IP fueron reservadas para grupos multicast. La red multicast es la 224.0.0.0/4 [12].
Todos los hosts que escuchan una dir IP multicast forman un grupo multicast. Existen 2324 grupos multicast diferentes. Cada dir IP multicast se comporta como un canal de tipo broadcast (como los canales de radio) donde todos los hosts pertenecientes a un grupo multicast puede enviar y recibir datagramas. El env o de datagramas a un grupo multicast puede hacerse en cualquier instante, independientemende de que en ese momento exista otro emisor en el grupo. En un datagrama dirigido a un grupo multicast gura, como dir IP destino, la dir IP del grupo multicast. Los miembros de un grupo multicast no conocen (al menos por la capa de red) a los otros miembros del grupo. 20.4. LOS GRUPOS MULTICAST 376
Nadie controla qui en pertenece a un grupo multicast (a nivel de la capa de red). La limitaci on la imponen los routers multicast (ltrando) y los TTLs de los paquetes.
Nadie controla qu e grupos multicast se crean o destruyen (a nivel de red). A nivel de aplicaci on s que se hace (v ease la aplicaci on sdr (Session DiRectory)) dise nada para el MBone [10]. Cuando un host escribe a una dir multicast, el datagrama llega a todos los miembros del grupo. En el siguiente ejemplo se supone que el grupo multicast 226.17.30.197 est a formado por los 3 receptores 128.59.16.20, 128.34.108.63 y 128.34.108.60, y por el emisor 128.119.40.186.
20.4. LOS GRUPOS MULTICAST
377
20.4. LOS GRUPOS MULTICAST 378
20.5.
El IGMP (Internet Group Management Protocol)
RFC 2236. Controla c omo se crean y destruyen los grupos multicast. El IGMP se utiliza entre un host y su router multicast, que por denici on debe de estar en su red.
20.5. EL IGMP (INTERNET GROUP MANAGEMENT PROTOCOL) 379
Funcionamiento:
20.5. EL IGMP (INTERNET GROUP MANAGEMENT PROTOCOL) 380
1. El router multicast env a peri odicamente un mensaje del tipo membership query a la(s) red(es) conectada(s) para preguntar si existe al menos un host suscrito a un grupo multicast.
2. Todos los hosts suscritos a alg un grupo multicast contestan (esperando un tiempo aleatorio m aximo establecido en el mensaje membership query) con mensajes del tipo membership report, indicando en cada uno de ellos las dirs IP multicast correspondientes. Esperan un tiempo aleatorio altes de contestar porque si durante la espera escuchan un membership report de otro host de la sub-red indicando que est a suscrito a ese grupo multicast, se ahorran la contestaci on. Si el router no recibe ning un membership report en un cierto tiempo despu es de un membership query, deja de participar en las transmisiones multicast (pruning del arbol multicast). El anterior estado tambi en puede conseguirse enviando al router un mensaje opcional llamado leave group. 20.5. EL IGMP (INTERNET GROUP MANAGEMENT PROTOCOL) 381
20.6.
20.6.1.
Protocolos de routing multicast

El DVMRP (Distance Vector Multicast Routing Protocol)
RFC 1075. Utiliza el algoritmo de ooding RPF con poda (pruning). Los mensajes de poda deshabilitan las transmisiones multicast durante 2 horas y sirven para que los routers que no quieren recibir el tr aco multicast dejen de recibirlo [13]. Para identicar el camino m as pr oximo al origen del tr aco multicast se utiliza el algoritmo Distance-Vector.
20.6. PROTOCOLOS DE ROUTING MULTICAST
382
20.6.2.
PIM (Protocol Independent Multicast)
RFCs 2362, 2201 y 2189. Posee dos modos de funcionamiento:

1. Modo de funcionamiento denso: Se emplea cuando la mayor a de los routers multicast est an involucrados en la transmisi on multicast. Utiliza el algoritmo de ooding RPF con poda. 2. Modo de funcionamiento disperso: Se emplea cuando s olo una minor a de los routers multicast est an involucrados en la transmisi on multicast. Utiliza el algoritmo spanning-tree broadcasting con el que s olo se retransmiten los datagramas multicast a aquellos routers que se lo especican al router que sirve de punto de encuentro. 20.6. PROTOCOLOS DE ROUTING MULTICAST 383
20.7.
Multicasting en las redes locales
Todas las tecnolog as de red que actualmente existen (independientemente de la existencia de un router multicast) soportan que un host env e un datagrama a todos de hosts de la sub-red (broadcasting). Esto se puede hacer f acilmente si enviamos el datagrama a la dir de broadcast de la sub-red (la u ltima del rango de direcciones). Los routers ignoran los datagramas dirigidos a la dir de broadcast de la sub-red.
20.7. MULTICASTING EN LAS REDES LOCALES
384
20.8.
Multicasting en Internet: el MBone (Multicast BackbONE)
Todos los routers de Internet no tienen que ser multicast.

Debido a los grandes requerimientos de ancho de banda que ser an necesarios, en general no est a permitido que ning un datagrama multicast acceda a Internet y alcance potencialmente a todos sus nodos, a no ser que sea transmitido a trav es de redes virtuales especialmente dise nadas con ese prop osito como el MBone [22, 1]. El MBone es una red virtual, formada por routers multicast conectados entre s mediante tunneling (para distribuir tr aco multicast sobre los routers unicast de Internet).
20.8. MULTICASTING EN INTERNET: EL MBONE (MULTICAST
385
Ejemplo:
El router A encapsula los datagramas multicast en datagramas IP unicast con origen A y con destino (B, ...). B los des-encapsula, ve el datagrama multicast con el destino original y realiza de nuevo tunneling si fuera necesario. Evid entemente, para que un host pueda enviar o recibir datos desde el MBone, tiene que existir un router multicast perteneciente al MBone en su sub-red. 20.8. MULTICASTING EN INTERNET: EL MBONE (MULTICAST 386
La distancia (en hops) que recorren los datagramas multicast en el MBone depende: 1. Del TTL asignado por el host emisor.
2. De que los routers permitan su retranmisi on. RedIRIS (la red de investigaci on espa nola) pertenece actualmente al MBone [11, 22]. The Roling Stones fueron los primeros en utilizar comercialmente el MBone en 1994. Emitieron 25 minutos de un concierto dado en Dallas, USA [18]. El MBone dejar a de existir como red virtual cuando todos los routers de Internet sean multicast.
387
Cap tulo 21
Mobility (Movilidad)
20.8. MULTICASTING EN INTERNET: EL MBONE (MULTICAST
388
21.1.
Routing para hosts m oviles
RFC 3220 (Mobile IP).

El IP contempla la posibilidad de que uno o dos de los hosts que han establecido una conexi on se puedan mover (cambiar de red f sica) a lo largo del tiempo que dura la conexi on [12]. Esto puede ocurrir con facilidad si se utilizan redes wireless. Siempre que el host m ovil desee recibir datos (de una determinada conexi on) debe conservar su dir IP: Usando UDP, si el host que es m ovil env a pero nunca recibe datos, entonces no es necesario a nadir ninguna funcionalidad a la capa de red. Sin embargo, si el host que es m ovil recibe datos entonces el routing est atico no funciona. Usando TCP, como la conexi on es siempre duplex (se env an datos de alguna clase en ambos sentidos), la capa de red debe de permitir el routing para host m oviles. 21.1. ROUTING PARA HOSTS MOVILES 389
El routing para host m oviles puede ser utilizado para desviar paquetes hacia un host malicioso. Por este motivo todos los protocolos utilizados poseen sistemas de identicaci on.
21.1. ROUTING PARA HOSTS MOVILES
390
21.2.
Nomenclatura
Mobile host: el host que se mueve entre redes durante una conexi on.
Correspondent host: el host (m ovil o no) que mantiene la conexi on con el host m ovil. Home network: la red originaria del host m ovil. Foreing network: la red a la que se mueve el host m ovil con una conexi on establecida. Home agent: un host o un router perteneciente a la home network que conoce la dir IP del host m ovil y la red foreing network. Foreing agent: un host o un router perteneciente a la foreing network que conoce la dir IP (ja) del host m ovil. COA (Care-of Address): dir IP del foreing agent.
21.2. NOMENCLATURA
391
21.2. NOMENCLATURA 392
21.3.
Routing indirecto
1. El correspondent host env a los paquetes ageno a la situaci on geogr aca del mobile host utilizando su dir IP permanente (la que usa en su home network ). 2. Los paquetes llegan hasta el home agent y este los env a al foreing agent usando la COA. Los paquetes originales se encapsulan (mediante tunneling, RFCs 2003 y 2004) en otros para conservar las dirs IP del correspondent host y del mobile host. Esto es necesario porque ning un router intermedio entre el home agent y el foreing agent encaminar a adecuadamente los paquetes encapsulados. 3. Los paquetes encapsulados llegan hasta el foreing agent, los desencapsula y los env a al mobile host. 4. El mobile host puede contestar directamente al correspondent host porque este no es m ovil.
Consiste en los siguientes pasos:

21.3. ROUTING INDIRECTO
393
Ejemplo
Encaminamiento:
394
Tunneling:
395
21.4.
Routing directo
Intenta reducir la distancia recorrida por los paquetes enviados al mobile host.1 En este caso el correspondent host no es ageno a que el mobile host es realmente m ovil. 1. El correspondent host solicita la COA al home agent. 2. El home agent env a al correspondent host la COA actual. 3. El correspondent host env a los paquetes al mobile host usando tunneling. Estos llegan encapsulados al foreing agent. 4. El foreing agent desencapsula los paquetes y los entrega al mobile host. 5. (No mostrado) El mobile host puede contestar directamente al correspondent host porque este no es m ovil.
1 Imag nese
que el host m ovil est a en la misma red que el correspondent host.
21.4. ROUTING DIRECTO
396
Ejemplo
21.4. ROUTING DIRECTO
397
Parte V
La capa de enlace de datos
398
Cap tulo 22
Servicios de la capa de enlace de datos

21.4. ROUTING DIRECTO 399
22.1.
El marco de trabajo
La capa de enlace de datos se sit ua entre la capa de red y la capa f sica.

22.1. EL MARCO DE TRABAJO
400
La capa f sica est a generalmente muy relacionada con la capa de enlace de datos (se dice que ambas son muy dependientes). Sin embargo, en algunas tecnolog as (como ATM) existe una diferenciaci on clara.
La transmisi on de un paquete desde el host emisor al receptor implica generalmente el uso de diferentes tecnolog as con distintas capas de enlace de datos, cada una con un modelo de servicio espec co.
22.1. EL MARCO DE TRABAJO
401
22.2.
Nodos, frames y enlaces
La capa de enlace de datos transmite bloques de datos (a los que llamaremos frames [12]) entre dos nodos (hosts o routers) de la red adyacentes, a trav es de un enlace de transmisi on. En el contexto de Internet, cada frame puede transmitir un paquete (o una parte de este) generado por la capa de red. A nivel de enlace de datos no tiene sentido distinguir entre hosts y routers, y por eso en adelante emplearemos s olo el t ermino nodo. El problema de transmitir un frame es el mismo, independientemente del tipo de nodo.
22.2. NODOS, FRAMES Y ENLACES
402
22.3.
22.3.1.
Servicios generalmente proporcionados

Transporte de datos
El u nico servicio que siempre se suministra independientemente de la tecnolog a subyacente, es el de transporte de datos. Los dem as son opcionales (para la capa de red y de transporte).
22.3.2.
Direccionamiento
En el caso de que a un mismo enlace existan m as de un posible nodo receptor, la capa de enlace de datos proporciona un mecanismo de direccionamiento basado en direcciones que permita al emisor diferenciarlos. LLamaremos a estas direcciones, direcciones f sicas.
22.3.3.
Control de acceso al medio

403
Media Access Control (MAC). 22.3. SERVICIOS GENERALMENTE PROPORCIONADOS
En aquellos casos donde existan dos o m as nodos emisores potenciales conectados a un mismo enlace de datos, la capa de enlace de datos proporciona un mecanismo de arbitraje del medio para evitar las colisiones.
Por denici on, se produce una colisi on cuando dos o m as emisores acceden a un medio compartido para enviar datos y lo hacen al mismo tiempo (cuando esto el medio no lo permite).
22.3.4.
Transferencia able
En algunas tecnolog as, la capa de enlace de datos garantiza que el transporte de un frame entre el emisor y el receptor se realiza sin errores. Para ello se implementan, a este nivel, algoritmos de control de ujo y de errores. Aunque puede pensarse que este servicio se solapa con el que se presta en la capa de transporte, debe tenerse en cuenta que a este nivel los errores s olo se corrigen si se producen sobre el enlace (no en un router por ejemplo). 22.3. SERVICIOS GENERALMENTE PROPORCIONADOS 404
Adem as, en aquellos casos donde la probabilidad de error del enlace es bastante alta (como puede ocurrir en los enlaces de larga distancia o en los enlaces de radio), es mucho m as eciente controlar los errores nodo-a-nodo que de extremo-a-extremo (como hace el TCP).
405
Cap tulo 23
Control de errores
22.3. SERVICIOS GENERALMENTE PROPORCIONADOS
406
23.1.
Fundamentos
Las t ecnicas de detecci on de errores s olo pueden detectar (con una cierta probabilidad de acierto) si existen errores de transmisi on. Estos s olo se pueden corregir usando retransmisi on de datos. Las t ecnicas de correcci on de errores adem as permiten corregirlos sin retransmisi on. En ambos casos se introduce informaci on redundante, especialmente en el segundo (por eso su uso no es muy frecuente en redes de transmisi on de datos a no ser que los errores de transmisi on sean muy frecuentes, las latencias muy grandes o las comunicaciones simplex, donde la retransmisi on no es una alternativa). La informaci on de control de errores es a nadida por la capa de enlace de datos del emisor y eliminada por la capa de enlace de datos del receptor.
23.1. FUNDAMENTOS
407
EDC (Error Detecting Code). 23.1. FUNDAMENTOS 408
23.2.
Paridad
Consiste en a nadir bits de paridad de forma que el n umero de bits iguales a 1 en el mensaje sea un n umero impar si usamos paridad impar o un n umero par si usamos paridad par [12]. Cuantos m as bits de paridad introducimos m as errores podemos detectar. Si estos son sucientes, incluso corregirlos. Ejemplos: 1. Paridad simple. Consiste en a nadir un u nico bit de paridad. En el siguiente ejemplo se utiliza paridad par:
La probabilidad de detectar (no de corregir) un error es del 50 %.
23.2. PARIDAD
409
2. Paridad bidimensional. Consiste en a nadir bits de paridad por las y por columnas. En el ejemplo se utiliza paridad par y como puede verse permite corregir un error.
23.2. PARIDAD
410
23.3.
Checksum
Consiste en sumar (usando una determinada precisi on aritm etica) todas las palabras del mensaje y transmitir como EDC dicha suma [19]. El receptor realiza la misma suma y si no concuerda con el EDC se sabe que se ha producido un error de transmisi on. Como ejemplo se muestra (en C) el algoritmo de la suma de comprobaci on usado por el TCP/IP:
unsigned short cksum (unsigned short *buf, int count) { /* 1 */ register unsigned long sum=0; /* 2 */ while (count--) { /* 3 */ sum += *buff++; /* 4 */ if (sum & 0xFFFF0000) { /* 5 */ sum &= 0xFFFF; /* 6 */ sum++; /* 7 */ } /* 8 */ } /* 9 */ return ~(sum & 0xFFFF); /* 10 */ } /* 11 */
23.3. CHECKSUM
411
Tanto el emisor como el receptor ejecutan el mismo algoritmo, excepto en que el receptor incluye la suma de comprobaci on en el c alculo. Si el resultado es 0, entonces se supone que no existen errores de transmisi on.
23.3. CHECKSUM
412
23.4.
CRC (Cyclic Redundancy Check)
Un mensaje de n +1 bits puede ser considerado como un polinomio de grado n donde los coecientes son 0 o 1 [24]. Por ejemplo, le mensaje 00100011 equivaldr a al polinomio x5 + x + 1. Sea Mn (x) el mensaje (polinomio de grado n) de n + 1 bits que el emisor quiere enviar al receptor, y sea Gk (x) el polinomio generador usado para crear el CRC. El CRC se calcula realizando Rk1 (x) (Mn (x) xk ) mod Gk (x). El emisor concatena a Mn (x) los k bits del CRC y los env a. Matem aticamente: Tn+k (x) = (Mn (x) xk ) + Rk1 (x). N otese que Tn+k (x) debe ser divisible entre Gk (x). El receptor recibe Tn+k (x) y comprueba si es divisible entre Gk (x). Si as es supone que no se han producido errores de transmisi on. 23.4. CRC (CYCLIC REDUNDANCY CHECK) 413
Ejemplo
Trama a transmitir: M5 (x) = x5 + x2 . Polinomio CRC: G3 (x) = x3 + x2 + 1. Residuo: R2 (x) = 1. Trama nalmente transmitida: 100100 001 (T8 (x) = x8 + x5 + 1).
M5 (x) x3 M5 (x) G3 (x) 1001000 0 0 110 1 1101 1 1 1101 1000 1101 1010 1101 1110 1101 01100 1101 001 Resto R2 (x)
23.4. CRC (CYCLIC REDUNDANCY CHECK)
414
Errores detectados
Una trama con errores ser a Tn+k (x) + Ei (x), donde Ei (x) es el polinomio formado por todos los bits de Tn+k (x) que han sido invertidos. Para no detectar el error tiene que ocurrir que Tn+k (x) + Ei (x) mod Gk (x) = 0 o lo que es lo mismo, que Ei (x) mod Gk (x) = 0 ya que por denici on Tn+k (x) mod Gk (x) = 0.
23.4. CRC (CYCLIC REDUNDANCY CHECK)
415
Por tanto, los mejores polinomios generadores son aquellos que dif cimente son factor de otro posible polinomio error. Por ello los polinomios de CRC deben: (1) tener un grado lo m as alto posible y (2) no ser factorizables. Ejemplos:
Denominaci on CRC-8 CRC-10 CRC-12 CRC-16 CRC-CCITT CRC-32
G(x) x8 + x2 + x1 + 1 x10 + x9 + x5 + x4 + x1 + 1 x12 + x11 + x3 + x2 + 1 x16 + x15 + x2 + 1 x16 + x12 + x5 + 1 x32 + x26 + x23 + x16 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + 1
N otese, por ejemplo, que el CRC-32 detectar a todos aquellos errores tipo r afaga1 que afecte a menos de 32 bits ya que ning un polinomio error de grado menor que 32 ser a divisible entre el.
1 Que
invierte un determinado n umero de bits consecutivos.
416
Cap tulo 24
Protocolos de acceso m ultiple

23.4. CRC (CYCLIC REDUNDANCY CHECK) 417
24.1.
Protocolos de particionado del canal
Se utilizan cuando dos o m as emisores pueden acceder a un medio de transmisi on compartido que no admite a m as de un emisor simult aneamente [12]. Ejemplos:
24.1. PROTOCOLOS DE PARTICIONADO DEL CANAL
418
24.2.
Las colisiones
Cuando dos (o m as) emisores acceden simult aneamente a un medio compartido se produce una colisi on.
La ocurrencia de la colisi on implica en general que ninguno de los emisores consigue comunicarse con exito y por tanto se desperdicia ancho de banda. El objetivo de los protocolos de acceso m ultiple consiste en evitar las colisiones.
24.2. LAS COLISIONES
419
24.3.
Protocolos de particionado est atico del canal
No existen colisiones.
Particionado est atico del ancho de banda. La m axima tasa de transmisi on es R/N donde R es el la tasa de transmisi on del enlace y N es el n umero de emisores.
24.3. PROTOCOLOS DE PARTICIONADO ESTATICO DEL CANAL 420
24.3.1.
Frecuencia
FDM y TDM
FDM Frecuencia w Canal 4 Canal 3 Canal 2 Canal 1 t Tiempo Tiempo TDM
24.3.2.
CDMA (Code Division Multiple Access)
Es semejante a FDM, pero se transmite en banda base (sin modulaci on), utilizando todo el rango de frecuencias.
Cada emisor utiliza un c odigo espec co que lo identica y transmite cada bit de datos modulado por dicho c odigo. El receptor correlaciona la se nal recibida con el c odigo usado por el emisor y obtiene el bit de datos.
di = i- esimo bit de datos. cm = m- esimo bit del c odigo CDMA. M = longitud del c odigo CDMA. 24.3. PROTOCOLOS DE PARTICIONADO ESTATICO DEL CANAL 423
Las se nales Zi,m de los emisores se suman entre s cuando son emitidas simult aneamente, gener andose Zi,m .
Ventajas: 1. No hay colisiones.

2. Alta seguridad: s olo si se conoce el c odigo CDMA se puede recuperar la se nal de datos. Desventaja: 1. Muy alto consumo de ancho de banda (muchos baudios/bit de datos).
24.4.
Protocolos de acceso aleatorio
Particionado din amico del ancho de banda.

La tasa de transmisi on es siempre igual a R donde R es la tasa de transmisi on del enlace. Existen colisiones. Cuando estas ocurren, el nodo espera un tiempo aleatorio antes de retransmitir el frame.
24.4. PROTOCOLOS DE ACCESO ALEATORIO
426
24.4.1.
ALOHA ranurado
Todos los frames poseen L bits.

Se transmite en slots de tiempo de L/R segundos (1 frame/slot). Todos los nodos est an sincronizados.
427
Cuando se produce una colisi on, todos los nodos la detectan en ese slot de tiempo. En ese momento todos los nodos involucrados retransmiten con una probabilidad p.
Si s olo existe un nodo (no existen colisiones), este transmite durante todo el tiempo a R bps. Cuando existen varios nodos transmitiendo, la eciencia tiende a N p (1 p)N 1 donde N es el n umero de nodos y p es la probabilidad de emitir un frame. De esta expresi on se deduce que para un N sucientemente grande, la eciencia es de 0,37. Esto signica que s olo el 37 % de los slots de tiempo son utilizados con exito. La sincronizaci on de los nodos es cr tica para evitar las colisiones parciales.
428
24.4.2.
ALOHA (no ranurado)
Igual que ALOHA ranurado, pero ahora los nodos no est an sincronizados.
Siempre se transmite durante un slot de tiempo, aunque se detecte una colisi on.
429
La eciencia en funci on del n umero de emisores N tiende a N p (1 p)2(N 1)

lo que signica que la eciencia no es nunca superior a 0,37/2.
430
24.4.3.
CSMA (Carrier Sense Multiple Access)
Incorpora la siguiente mejora (Carrier Sense):

1. Antes de (re)transmitir, los nodos miran si el medio est a ocupado. Si lo est a, esperan un tiempo aleatorio. A pesar de esta mejora, pueden existir colisiones. Supongamos, por ejemplo, que existen 4 nodos A, B, C y D situados a lo largo de un cable como se muestra en la siguiente gura. En t0 emite B y en t1 emite D. Si se cumple que en t1 t0 la se nal portadora no ha llegado desde B hasta D, entonces se producir a una colisi on.
431
432
24.4.4.
CSMA/CD (Collision Detect)
Incorpora la siguiente mejora (Collision Detect):

1. Mientras transmiten, si detectan una colisi on entonces dejan inmediatamente de transmitir. Usado en Ethernet. Las colisiones pueden seguir apareciendo, pero ahora el tiempo de colisi on es menor. En el siguiente ejemplo (semejante al anterior) se ha supuesto que el tiempo que se necesita para detectar la colisi on no es cero (lo que en la pr actica siempre ocurre).
433
434
24.5.
Protocolos basados en turnos
Se basan en establecer alguna pol tica de acceso al medio basada en turnos. Se han llevado a la pr actica dos alternativas diferentes:
1. Protocolos de sondeo. Un nodo maestro se encarga de ir chequeando (secuencialmente) qu e nodos tienen datos que transmitir. Cuando detecta uno le da permiso durante un tiempo limitado. 2. Protocolos de paso de token. Los nodos se intercambian (secuencialmente) un frame especial llamado token que permite al nodo que lo posee transmitir durante un tiempo limitado. Los protocolos basados con turnos poseen una eciencia mayor que los protocolos de acceso aleatorio cuando el n umero de nodos potencialmente emisores es sucientemente alto. Sin embargo, cuando existen pocos emisores, la eciencia es menor porque el sondeo o el paso del token no es instant aneo. 435
Cap tulo 25
Redes locales y el ARP
24.5. PROTOCOLOS BASADOS EN TURNOS
436
25.1.
LAN: denici on
Una LAN (Local Area Network) es una red de computadoras concentradas en un area geogr aca [12].
Una LAN est a t picamente conectada a Internet a trav es de un router.
25.1. LAN: DEFINICION
437
25.2.
Direcciones f sicas
Cada adaptador de red posee una direcci on f sica (tambi en llamada direcci on MAC Medium Access Control ).
En la mayor a de las tecnolog as de red, las direcciones f sicas poseen 6 bytes.
25.2. DIRECCIONES F ISICAS
438
En todos los frames transmitidos gura la direcci on f sica del adaptador de red destino. La direcci on f sica FF-FF-FF-FF-FF-FF es la direcci on de broadcast de la sub-red y provoca que el frame alcance a todos los adaptadores conectados.
25.2. DIRECCIONES F ISICAS
439
25.3.
El ARP (Address Resolution Protocol)
RFC 826.
Es utilizado por todos los nodos que poseen la capa de enlace de datos. Traduce la dirs IP a dirs f sicas.
25.3. EL ARP (ADDRESS RESOLUTION PROTOCOL)
440
Cada nodo incorpora una tabla ARP: Dir IP

Dir F sica
Las tablas ARP son generalmente din amicas. Los nodos est an siempre pendientes de los frames que les llegan y utilizan las parejas de dirs IP/dirs f sicas (que en ellos guran) para mantenerlas lo m as actualizadas posible. Adem as, sus entradas tienen un tiempo m aximo de vida.
441
Cuando la tabla ARP no contiene una resoluci on se ejecuta el siguiente protocolo (ARP): 1. Enviar un frame ARP a la dir de broadcast de la sub-red. Dicho frame contiene la dir f sica del nodo emisor y la dir IP del nodo receptor. 2. Cada nodo recibe el frame ARP y comprueba si su dir IP concuerda con la que gura en el frame. Si as es, contesta (usando otro frame ARP) a la dir f sica del nodo que quiere enviar el frame de datos. De paso actualiza su tabla ARP. 3. El nodo que quiere enviar el frame de datos recibe el segundo frame ARP con la resoluci on (en el gura la dir f sica del nodo que lo genera), actualiza su tabla ARP y transmite los datos.
442
Cap tulo 26
Ethernet
443
26.1.
Historia
La tecnolog a Ethernet fue inventada por Metcalfe y Boggs a mediados de los 70 [12].
Fue la primera en su g enero y actualmente es la tecnolog a predominante en redes de area local.
26.1. HISTORIA
444
26.2.
Estructura del frame
Todas las tecnolog as Ethernet utilizan la misma estructura de frame1 :

1. Pre ambulo (8 bytes): consta de XXXX XXXY donde X = 1010 1010 e Y = 1010 1011. Se utiliza para sincronizar los relojes del emisor y del receptor que miden la duraci on de los bits del frame. 2. Dir. f sica destino (6 bytes): dir del adaptador destino. 3. Dir. f sica fuente (6 bytes): dir del adaptador origen. 4. Tipo (2 bytes): identica el protocolo usado en la capa de red (IP, Novell IPX, AppleTalk, etc.).
1 Esto ha permitido que el software de la capa de red haya sido reutilizado durante m as de 20 a nos.
26.2. ESTRUCTURA DEL FRAME
445
5. Datos (entre 46 y 1.500 bytes): paquete de datos transportado. La capa de red se encarga de la segmentaci on y del relleno con ceros (si estos fueran necesarios).
6. CRC (4 bytes): CRC-32. Sirve para detectar errores de transmisi on.
26.2. ESTRUCTURA DEL FRAME
446
26.3.
Servicio
1. Sin conexi on: los frames Ethernet se transmiten sin previo aviso. 2. No able: si un frame llega con errores, Ethernet u nicamente los desecha.
Ethernet posee las siguientes caracter sticas:

Es responsabilidad de las capas superiores transformar este servicio en able y orientado a conexi on (cuando sea preciso).
26.3. SERVICIO
447
26.4.
Codicaci on Manchester
Se utiliza transmisi on en banda base, utilizando codicaci on Manchester:

Una tasa de baudios igual al doble de la tasa de bits permite mantener los relojes del emisor y del receptor siempre sincronizados. Sin embargo, esto genera un alto consumo de ancho de banda. MANCHESTER 26.4. CODIFICACION 448
26.5.
El protocolo CSMA/CD en Ethernet
El adaptador de red intenta transmitir cada frame lo antes posible, pero primero comprueba (durante 96 tiempos de bit) a que no exista se nal portadora en el medio. Si durante una transmisi on no se detecta una colisi on, se supone que el frame se ha transmitido con exito.2 Sin embargo, si se detecta una colisi on la transmisi on se aborta inmediatamente y se transmite una se nal de jam (atasco) de 48 bits iguales a 0.3 Todos los adaptadores que han producido una colisi on ejecutan el algoritmo de retroceso exponencial binario. Este consiste en: 1. Sea n 1 el n umero de colisiones experimentadas en la transmisi on del frame en cuesti on.
2 Por esto los frames tienen que tener un tama no m nimo de 512 bits, sin contar el pre ambulo (64 bits). 3 Esta se nal avisa al resto de emisores que se ha producido una colisi on.
26.5. EL PROTOCOLO CSMA/CD EN ETHERNET
449
2. Generar un n umero entero aleatorio uniforme K {0, 1, , 2m 1}, donde m = m n(n, 10). 3. Esperar K 512 tiempos de bit antes de retransmitir.
4. n n + 1. 5. Ir a 2 si n < 16.
450
26.5.1.
Eciencia
Cuando s olo existe un nodo emisor, la eciencia en Ethernet tiende a 1.

Sin embargo, cuando el n umero de nodos emisores es alto, esta tiende a: 1 1 + 5tprop /ttrans donde tprop es igual al m aximo tiempo de propagaci on de una se nal entre los adaptadores m as distantes y ttrans es el tiempo de transmisi on (inyecci on en o extracci on del enlace) del frame m as largo.
451
26.6.
Tecnolog as Ethernet
Estandarizadas por el grupo de trabajo IEEE 802.3.

26.6.1.
10Base2 Ethernet
Creada a principios de los 90. Consigue 10 Mbps usando transmisi on en banda base y permite enlaces de hasta 200 metros de longitud. Los adaptadores se conectan entre s usando cable coaxial delgado y conectores en T.
26.6. TECNOLOG IAS ETHERNET
452
Se trata de una tecnolog a donde s olo existe un dominio de colisi on. Los frames se propagan en ambas direcciones, alcanzan a todos los adaptadores, van perdiendo energ a en su viaje y nalmente mueren (se aten uan totalmente) en los terminadores (resistencias de 50 ).
453
26.6.2.
10BaseT Ethernet y 100BaseT Ethernet
Es la m as usada actualmente.
Funcionan (respectivamente) a 10 Mbps y a 100 Mbps, transmiten en banda base y utilizan (t picamente) par trenzado (T). La topolog a t pica de interconexi on es en estrella. Todos los adaptadores se conectan a trav es de un concentrador (un hub o un switch) mediante enlaces punto a punto de dos pares (full-duplex) trenzados y terminados en conectores RJ-45.
454
Dependiendo de si el concentrador es un hub o un switch, existen uno o muchos dominios de colisi on. Usando par trenzado de cobre no suele ser posible separar m as de 100 metros el concentrador de ninguno de los nodos. Para mayores 455 26.6. TECNOLOG IAS ETHERNET
distancias se puede utilizar bra optica que es mucho menos sensible al ruido.
26.6.3.
Gigabit Ethernet y 10 Gigabit Ethernet
Son mejoras de (y compatibles con) las normas 10BaseT y 100BaseT que permiten alcanzar 1 Gbps y 10 Gbps, respectivamente.
456
26.7.
Hubs
Los hubs son b asicamente repetidores (dispositivos de regeneraci on de se nales digitales que funcionan a nivel de la capa f sica).
Suelen ser multipuerto: la se nal que llega a trav es de alguna de sus entradas es propagada (tras ser despojada del ruido) a todas las salidas [12].
26.7. HUBS
457
No entienden los protocolos de la capa de enlace de datos (ni por supuesto los superiores). No crean dominios de colisi on, s olo los extienden. En este sentido todos los nodos que se conectan mediante un hub acceden al medio usando CSMA/CD.
26.7. HUBS
458
26.8.
Switches
Los link-layer switches, conmutadores de nivel 2 o conmutadores Ethernet son dispositivos de conmutaci on de frames que funcionan a nivel de la capa de enlace de datos. A diferencia de los hubs, pueden interconectar diferentes tecnolog as Ethernet. Tambi en a diferencia de los hubs, separan los dominios de colisi on. Por ejemplo, en la siguiente red existen 3 dominios de colisi on diferentes, uno para cada departamento:
26.8. SWITCHES
459
26.8. SWITCHES 460
Otro ejemplo:
26.8. SWITCHES
461
Como se desprende de los anteriores ejemplos, los switches deben ejecutar el protocolo CSMA/CD s olo cuando en enlace involucrado no sea full-duplex.
26.8. SWITCHES
462
26.8.1.
Encaminamiento
Cada switch posee una switch table con la estructura

donde la primera columna indica la direcci on f sica de los diferentes interfaces de red conectados al switch (directamente o a trav es de un hub), la segunda es la boca al que se conecta cada interface y la tercera, el u ltimo instante en que se ha escuchado a ese interface.
26.8. SWITCHES
463
La tabla de conmutaci on es din amica. El switch la mantiene de forma autom atica anotando la dir f sica origen de cada frame que le llega. Cuando una entrada se hace demasiado vieja, se elimina.
As , el algoritmo de encaminamiento consiste en: 1. Buscar en la switch table el interface de salida asociado a la dir f sica destino del frame. 2. Si existe una entrada para la dir f sica destino, entonces: a) Si el interface de salida es distinto del de entrada, entonces: 1) Encaminar el frame por el interface de salida. 3. Si no existe ninguna coincidencia: a) Realizar un ooding. Los switches ejecutan el algoritmo del arbol de expansi on para evitar un broadcast-storm.
26.8. SWITCHES
464
26.8.2.
Store-and-forward versus cut-throuht
Cuando las tasas de transmisi on de la boca de entrada de un frame coincide con la tasa de transmisi on de la boca de salida, el switch puede usar una t ecnica de transferencia conocida como cut-throuht y que consiste en que los frames se transmiten mientras todav a se est an recibiendo. Esto permite reducir sensiblemente la latencia, especialmente cuando los frames necesitan atravesar muchos switches.
465
Cap tulo 27
Wi-Fi
26.8. SWITCHES
466
27.1.
Capacidades
Norma Banda de Frecuencias Mutiplexaci on Tasa de Transmisi on 802.11a 5,1 GHz - 5,8 GHz OFDM Hasta 54 Mbps 802.11b 2,4 GHz - 2,485 GHz DSSS Hasta 11 Mbps 802.11g 2,4 GHz - 2,485 GHz OFDM Hasta 54 Mbps OFDM = Orthogonal Frecuency-Division Multiplexing. DSSS = Direct Sequence Spread Spectrum.
Wireless LAN IEEE 802.11. Wi-Fi es simplemente una norma de calidad (como THX). Uso creciente porque permite una movilidad total en distancias medias (una casa, por ejemplo). Todas utilizan el mismo protocolo de acceso al medio, el CSMA/CA, y la misma estructura de frame.
27.1. CAPACIDADES
467
27.2.
27.2.1.
Modes
Infrastructure
Es el modo m as frecuente. El AP (Access Point) permite que los nodos m oviles se comuniquen entre s y con la red wired. Los nodos m oviles junto con el AP correspondiente forman un BSS (Basic Service Set).
27.2. MODES
468
27.2. MODES 469
27.2.2.
Modo Ad-Hoc
Las estaciones se comunican directamente entre porque est an lo sucientemente pr oximas.

27.2. MODES
470
27.3.
Canales
Con la idea de acomodar a m as de un AP en una misma regi on geogr aca, el 802.11 dene un conjunto de canales de frecuencia.
Existen un total de 11 canales que est a parcialmente solapados entre s . S olo los canales 1, 6 y 11 no se solapan entre s .
27.3. CANALES
471
27.4.
El proceso de asociaci on
Los APs generan peri odicamente beacon frames con la idea de anunciar su presencia a los nodos m obiles.
En un beacon frame gura la direcci on f sica y la SSID (Service Set Identier) del AP. La SSID es una cadena alfanum erica que asigna el administrador de la red al AP. Los beacon frames s olo se transmiten a trav es del canal para el que se ha congurado la emisi on del AP.
27.4. EL PROCESO DE ASOCIACION
472
Cuando un nodo m ovil se intenta asociar a un AP pueden ocurrir dos cosas: 1. Que el AP no controle qui en se asocia.
2. Que el AP s lo haga. En este caso el control se realiza de dos formas distintas: a) Permitiendo s olo la conexi on desde las direcciones f sicas previamente especicadas. b ) Permitiendo s olo la conexi on desde aquellos nodos que sean capaces de autenticarse.1
27.4. EL PROCESO DE ASOCIACION
1 Usando protocolos como RADIUS o DIAMETER [13]. Esto no tiene nada que ver con el cifrado de datos de tipo WEP o WPA.
473
27.5.
CSMA/CA (Carrier Sense Multiple Access/Collision Avoidance)
Wi-Fi es semejante a una red Ethernet de medio compartido. Sin embargo, el protocolo CSMA/CD no es suciente debido al problema del terminal oculto debido al cual dos nodos pueden colisionar sin enterarse:
27.5. CSMA/CA (CARRIER SENSE MULTIPLE ACCESS/COLLISION 474
Este problema provoca las siguientes diferencias: 1. Las estaciones transmiten siempre frames completos, y por tanto, nunca abortan la transmisi on porque no hay forma de comprobar si se ha producido una colisi on testeando simplemente si lo que se inyecta en el enlace es lo que se lee del mismo. 2. Para conocer si la transmisi on de un frame de datos ha tenido exito se espera la llegada de un frame ACK con un tiempo m aximo de espera. Si este no llega a tiempo se retransmite el frame de datos y el proceso se repite. 3. El tiempo m aximo de espera es igual al tiempo que se tarda en enviar un frame de tama no m aximo y recibir el correspondiente ACK. Recu erdese que se transmiten siempre frames completos.
DIFS = Distributed Inter-Frame Space (chequeo de portadora). SIFS = Short Inter-Frame Spacing.
Las anteriores prouestas no evitan las colisiones porque los nodos pueden acceder al medio para transmitir al mismo tiempo. Cuando los frames son peque nos esto no es un gran problema.
Sin embargo, cuando los frames son largos las colisiones desperdician mucho ancho de banda. As , nos nodos pueden usar un sistema de reserva de ancho de banda llamado RTS/CTS. Cuando un nodo genera un frame RTS (Request To Send) es que va a enviar un gran frame de datos y solicita al nodo receptor que genere un frame CTS. Un frame CTS (Clear To Send) indica a todos los nodos que lo reciben (excepto al que ha enviado el RTS) que deben esperar a que el medio quede libre (alrrededor del nodo receptor) antes de transmtir.
27.6.
Estructura del frame IEEE 802.11
Frame control: Diversa informaci on sobre la transmisi on del frame. Duration: Usado en el frame RTS. Sirve para reservar ancho de banda durante un determinado intervalo de tiempo. Address 1: Direcci on f sica del interface de red Wi-Fi origen. Address 2: Direcci on f sica del interface de red Wi-Fi destino. 27.6. ESTRUCTURA DEL FRAME IEEE 802.11 479
Address 3: Direcci on f sica del interface de red Ethernet del router (si el frame va dirigido hacia hacia el router de la subred). Sin este campo ser a imposible enviar mensajes fuera de la BSS.
Seq control: N umero de secuencia usado en el protocolo ARQ de parada y espera para controlar las colisiones. Address 4: NPI. Payload: Los datos. CRC: Un CRC-16.
27.6. ESTRUCTURA DEL FRAME IEEE 802.11
480
27.7.
Mobility
Los nodos m oviles pueden cambiar con facilidad de BSS:

27.7. MOBILITY
481
Cuando se usa un hub para conectar las BSS no existen problemas para entregar los frames al nodo m ovil. Sin embargo, cuando hay un conmutador este debe actualizar su switch table lo m as frecuentemente posible (en cuanto la estaci on se asocia al nuevo AP).
482
Cap tulo 28
Bluetooth
27.7. MOBILITY
483
28.1.
IEEE 802.15
Tasa de trasmisi om modesta (hasta 721 Kbps) [12].

Misma banda de frecuencias que 802.11 (2,45 GHz - 2,5 GHz). Tecnolog a pensada para reemplazar los cables en distancias cortas (impresoras, ratones, teclados, ...), hasta un m aximo de 10 metros. Incorpora control de ujo y de errores usando el protocolo parada y espera. El protocolo MAC est a basado en un protocolo basado en turnos mediante sondeo.
484
Cap tulo 29
Enlaces PPP
28.1. IEEE 802.15
485
29.1.
EL PPP (Point-to-Point Protocol)
RFCs 1661, 1547 y 2153.

El PPP se utiliza en enlaces punto-a-punto [12]. Ejemplo: las conexiones a trav es de modem al ISP. Principales caracter sticas: Packet framing. El comienzo y el n de cada frame es se nalizado. Independencia del protocolo usado en la capa de red. Permite usar los protocolos IP, DECnet, AppleTalk, etc. Independencia de la capa f sica utilizada. PPP se puede utilizar en enlaces serie o paralelos, conexiones telef onicas anal ogicas, ISDN, ADSL, SONET/SDH, X.25, etc. Detecci on de errores de transmisi on. S olo los detecta, no los corrige. Detecci on de fallo en el enlace de transmisi on. 29.1. EL PPP (POINT-TO-POINT PROTOCOL) 486
29.2.
Data framing
Flag. El comienzo y el n del frame se indica con la secuencia 0111 1110. Address. Siempre igual a 1111 1111 (genial). Control. Siempre igual a 0000 0011 (tambi en genial). Protocol. Protocolo usado en la capa superior. Information. Datos transmitidos. Checksum. Se utiliza un CRC. 29.2. DATA FRAMING 487
29.2.1.
Byte stung
Evita que cuando el patr on 0111 1110 aparezca en el campo de informaci on del frame no se produzca un error de nalizaci on prematura del frame. Cuando este byte aparece en los datos, el PPP lo antecede del byte de control 0111 1101 para indicar que no se trata del n de frame. Si el byte 0111 1101 aparece en los datos, el PPP lo antecede de otro byte de control 0111 1101 para indicar este evento. Por este motivo a este byte se le llama tambi en c odigo de escape.
29.2. DATA FRAMING
488
29.3.
Protocolo de control del enlace
Una conexi on PPP siempre comienza y termina en el estado Dead.

29.3. PROTOCOLO DE CONTROL DEL ENLACE
489
Antes de transmitir o recibir se entra en el estado Link establishment.
490
El lado que trata de establecer la conexi on env a al otro lado sus preferencias de conguraci on del enlace (tama no m aximo de frame, protocolo de autenticaci on, etc.).
491
El lado servidor responde indicando qu e prefrerencias son aceptables (incluyento todas o ninguna, en cuyo caso no se establece la conexi on PPP). Opcionalmente solicita una identicaci on.
492
En ese instante intercambian mensajes las capas de red de ambos extremos. Por ejemplo, cuando se utiliza el IP se conguran las dirs IP, el formato de compresi on de los datos, etc.
493
En el estado Open se transmiten los datos, frame a frame. El tama no de estos viene determinado por el IP.
494
La conexi on PPP permanece abierta hasta que uno de los extremos env a un mensaje de solicitud de terminaci on. Este debe ser conrmado por el otro extremo.
495
Cuando los dos extremos cierran la conexi on y sit uan, de nuevo, en el estado Dead.
496
Cap tulo 30
ATM
497
30.1.
Historia
ATM fue desarrollada por el foro ATM y la ITU a mediados de los 80 [6]. En aquella epoca era impensable la transmisi on en tiempo real de ujos multimedia (principalmente voz) usando redes de conmutaci on de paquetes [12]. ATM proporciona una soluci on completa para las aplicaciones de red (implementa todas las capas excepto la de aplicaci on). Por desgracia (para ATM) cuando estuvo realmente operativa la inmensa mayor a de las aplicaciones de red (el WWW, tel efono IP, el correo electr onico, etc.) ya estaban funcionando sobre TCP/IP. En este sentido, y aunque ATM podr a haber sustituido al TCP/IP, actualmente se utiliza fundamentalmente para transmitir paquetes IP. Por este motivo en esta exposici on se ha considerado a ATM como una tecnolog a m as a nivel de enlace de datos.
30.1. HISTORIA
498
30.2.
Principales caracter sticas
Altas tasas de transmisi on. ATM funciona pr acticamente sobre cualquier capa f sica. En los enlaces de larga distancia suele utilizarse bra o ptica. Velocidades t picas de transmisi on (utilizando SONET) son 155,52 Mbps y 622 Mbps. Enlaces de larga distancia. Los enlaces ATM son punto a punto y pueden recorrer mucha distancia (miles de Km). Routing a nivel de enlace de datos. Los conmutadores ATM incorporan mecanismos de routing a nivel de ATM muy semejantes a los utilizados por el IP. Calidad de servicio. ATM proporciona mecanismos de control de la congesti on y de reserva de ancho de banda. Esto permite que el usuario que paga puede obtener una calidad de servicio superior.
30.2. PRINCIPALES CARACTER ISTICAS
499
30.3.
Modelo de servicio
ATM proporciona varios modelos de servicio que se adaptan a diferentes necesidades [24]:
CBR (Constant Bit Rate). Pretende simular un enlace dedicado. Los bits se ponen en un extremo y un cierto tiempo despu es, siempre jo, salen por el otro (jitter igual a 0). No existe control de ujo entre el emisor y la red. Aplicaci on t pica: transportar conversaciones telef onicas. VBR (Variable Bit Rate). La tasa de bits var a con el tiempo y las latencias tambi en. Sin embargo, pueden negociarse latencias m aximas cuando usamos la modalidad RT-VBR (Real Time VBR). La red no proporciona control de ujo. Aplicaci on t pica: v deo MPEG. ABR (Available Bit Rate). Es un caso intermedio entre CBR y VBR. La red proporciona una tasa de transmisi on m nima, aunque si la carga no es alta, entonces pueden alcanzarse tasas 30.3. MODELO DE SERVICIO 500
mayores. La red proporciona control de congesti on. Ejemplo: contrato para un n umero pico de llamadas telef onicas. UBR (Unspecied Bit Rate). Igual que la anterior, pero la red no proporciona control de congesti on. Esto es u til cuando este proceso se realiza en una capa superior (TCP/IP). Ejemplo: transferencia de cheros, WWW, e-mail. En ning un caso los errores de transmisi on tratan de corregirse mediante retransmisi on. Sin embargo se utiliza un c odigo de detecci on y correcci on de errores en la cabecera. Si esta se corrompe no se retransmite la celda.
30.3. MODELO DE SERVICIO
501
30.4.
Las celdas ATM
Se utiliza TDM as ncrona (como los routers).

Los conmutadores ATM encaminan celdas de longitud ja (5 bytes de cabecera y 48 bytes de datos). 5 bytes 48 bytes +----------+----------------------------------+ | Cabecera | Datos | +----------+----------------------------------+
30.4. LAS CELDAS ATM
502
El formato de la cabecera es:
VCI (Virtual Channel Indentier). Establece el VC que la celda debe seguir. PT (Payload Type). Indica el tipo de carga u til que transporta la celda: (1) datos, (2) informaci on de control o (3) celda de relleno (cuando el medio no permite dejar de transmitir celdas). CLP (Cell-Loss Priority). Identica la prioridad de la celda a la hora de ser desechada (usada en el mecanismo de control de congesti on de los conmutadores). HEC (Header Error Control). C odigo de Hamming que permite detectar y corregir errores (en la cabecera). 30.4. LAS CELDAS ATM 503
30.5.
Morfolog a de la red
Id entica a la de una red TCP/IP donde los routers son conmutadores ATM y los enlaces son siempre punto a punto (no pueden ser redes).
Los routers IP ven la red ATM como una tecnolog a m as de interconexi on (como Ethernet). Se conectan a la red ATM a trav es de un adaptador ATM. Los nodos tambi en pueden conectarse directamente a un conmutador ATM aunque necesitan un adaptador ATM.
30.5. MORFOLOG IA DE LA RED
504
30.6.
Canales virtuales y routing
ATM utiliza circuitos (canales en la jerga ATM) virtuales (VCs). Estos pueden ser permanentes o temporales.
Las celdas nunca llegan desordenadas al receptor. Los VCs temporales implican un establecimiento previo de conexi on a la transmisi on u til de celdas. En la mayor a de los enlaces de larga distancia los canales son permanentes (routing est atico) y por lo tanto el establecimiento de conexi on no existe en estos casos. El est andar ATM no dene ning un algoritmo de routing concreto. Se deja en manos del constructor del conmutador dicha elecci on [24]. De todas formas, dado el uso que tiene actualmente ATM (enlaces de larga distancia), el routing en ATM en la mayor a de los casos se realiza de forma est atica. 30.6. CANALES VIRTUALES Y ROUTING 505
30.7.
Arquitectura de ATM
Capa de Usuario Capa AAL Capa ATM Capa F sica
ATM se organiza en 4 capas:

30.7. ARQUITECTURA DE ATM
506
30.7.1.
La capa f sica
Controla los voltajes, relojes maestros, framing, ... es decir, se encarga de la transmisi on f sica de las celdas ATM.
Realiza en control de errores (descarta las celdas con cabeceras err oneas).1 La capa f sica se divide en 2 sub-capas: 1. PMD (Physical Medium Dependent) sub-layer. Diferente para tipo de medio f sico que es capaz de transmitir ATM. 2. TC (Transmission Convergence) sub-layer. Dependiente de la capa f sica. Se encarga fundamentalmente del mantenimiento del sincronismo de los relojes del emisor y del receptor y de chequear los errores en las cabeceras.
1 Se utiliza un c odigo de Hamming que es capaz de corregir un error y detectar errores m ultiples.
507
30.7.2.
La capa ATM
Establece las conexiones [6].

Realiza el framing (segmentaci on de los datos generados por la capa superior en celdas). Control de la congesti on (s olo en el modo ABR).
508
30.7.3.
La capa AAL (ATM Adaptation Layer)
Permite que los protocolos de la capa de red (IP en la mayor a de los casos) puedan usar ATM.
AAL se implementa s olo en los extremos (hosts y routers) de una red ATM.
509
La AAL puede ser considerada como la capa de transporte de ATM. Existen 3 AALs diferentes dependiendo del tipo de servicio que se va a prestar:
Protocolo AAL 1 AAL 2 AAL 5
Uso CBR (telefon a) VBR (audio y v deo comprimido) UBR (datagramas IP)
La capa AAL genera su propia informaci on de control y puede robar espacio a los datos u tiles.
510
En el caso de la AAL 5, la AAL no introduce ninguna informaci on de control. Sin embargo cuando hasta la AAL 5 llega un datagrama IP se transmite la siguiente informaci on:
donde CPCD-PDU payload. Secci on de un datagrama IP. PAD. Relleno de bytes para que el n umero de bytes de datos transmitidos sea un m ultiplo de 48. Length. N umero de bytes de datos transmitidos. CRC. C odigo de redundancia c clica (mismo que Ethernet).
511
30.7.4.
La capa de usuario
En ella se ejecutan las aplicaciones de red. Realiza la correcci on de errores y de ujo cuando es necesario.
512
30.8.
ATM realiza un control de la congesti on s olo en su modo ABR. En este modo los conmutadores pueden desechar celdas cuando se congestionan con el objetivo de mantener las tasas y las latencias contratadas. En una transmisi on ATM, entre las celdas de datos el emisor inserta celdas de control llamadas celdas RM (Resource Management).2 Cuando las celdas de control atraviesan los conmutadores, estos modican unos determinados campos de ellas cuando comienzan a estar congestionados. Cuando las celdas alcanzan al receptor este las devuelve al emisor (posiblemente modic andolas si se encuentra congestionado). El receptor tambi en puede generar celdas RM si estas no le llegan. El emisor regula su tasa de transmisi on en funci on de la informaci on de las celdas RM retornadas. 30.8. CONTROL DE LA CONGESTION
2 T picamente
1 de cada 32 es una celda de control.
513
30.9.
The Internet-over-ATM protocol stack
30.9. THE INTERNET-OVER-ATM PROTOCOL STACK
514
Bibliograf a
[1] How to connect to the MBone. http://www.live.com/mbone. [2] GSM Association. GSM World. http://www.gsmworld.com. [3] Douglas E. Comer. Internetworking with TCP/IP. Principles, Protocols, and Architectures (4th Edition), volume 1. Prentice Hall, 2000.
646
[4] Defense Advanced Research Projects Agency (DARPA), http://www.rfc-editor.org/rfc/rfc793.txt. RFC 793. The Transmission Control Protocol (TCP), 1981.
[5] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners-Lee. Hypertext Transfer Protocol HTTP/1.1. http://www.ietf.org/rfc/rfc2616.txt, June 1999. [6] M. Ford, H.K. Lew, S. Spanier, and T. Stevenson. Tecnolog as de Interconectividad de Redes. Prentice Hall, 1998. [7] Behrouz Forouzan. Introduction to Data Communications and Networking. WCB/McGraw-Hill, 1998. [8] R.C. Gonzalez and R.E. Woods. Digital Image Processing. Addison Wesley, 1992. [9] Fred Halsall. Comunicaciones de Datos, Redes de Computadores y Sistemas Abiertos (4a Edici on). Pearson Educaci on, 1998. [10] Mark Handley. A MBone Scheduler. http://wwwmice.cs.ucl.ac.uk/multimedia/projects/mice/mbone review.html. 647
[11] IRIS-MBONE. Rediris software http://www.rediris.es/mmedia/MboneSoft.es.html.
mbone.
[12] James F. Kurose and Keith W. Ross. Computer Networking: A TopDown Approach Featuring the Internet (2nd Edition). Addison Wesley, 2003. [13] James F. Kurose and Keith W. Ross. Computer Networking: A TopDown Approach Featuring the Internet (3rd Edition). Addison Wesley, 2005. [14] Bhagwandas Pannalal Lathi. Introducci on a la Teor a y Sistemas de Comunicaci on. Limusa Noriega Editores, 1994. [15] Alberto Le on-Garc a and Indra Widjaja. McGraw-Hill, 2002. Redes de Comunicaci on.
[16] Network Working Group, AT&T Research, http://www.rfceditor.org/rfc/rfc793.txt. Defending Against Sequence Number Attacks, 1996. 648
[17] Alan V. Oppenheim, Alan S. Willsky, and S. Hamid Nawab. Se nales y Sistemas (2a edici on). Prentice Hall, 1997. [18] Soon J. Park. Mbone info. jp/mbone.html. http://myhome.hanafos.com/soon-
[19] Larry L. Petterson and Bruce S. Davie. Computer Networks: A System Approach (2nd Edition). Morgan Kaufmann, 2000. [20] J. Postel. RFC 768. The User Datagram Protocol (UDP). USC/Information Sciences Institute, http://www.rfceditor.org/rfc/rfc768.txt, 1980. [21] Gary R. Wright and W. Richard Stevens. TCP/IP Illustrated. AddisonWesley, 1995. [22] K. Savetz, N. Randall, and Y. Lepage. MBONE: Multicasting Tomorrows Internet. http://www.savetz.com/mbone. [23] William Stallings. Comunicaciones y Redes de Computadores (6a Edici on). Prentice Hall, 2000. 649
[24] Andrew S. Tanenbaum. Redes de Computadoras (3a Edici on). Prentice Hall, 1997. [25] Lloyd Wood. Lloyds satellite constellations. http://www.ee.surrey.ac.uk/Personal/L.Wood/constellations.

Redes PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Redes PDF

Uploaded by

Copyright:

Available Formats

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

86 87 88 89 91 92 93 94 96 96 97 98 100 102 103 104 105 106

Redes de Computadoras, 2006/07

7.3. 7.4. 7.5. 7.6. 7.7. 7.8.

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

180 181 181 185 187 189

La capa de transporte de datos

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

20.Multicasting (Multidifusi on) 366 20.1. Modelos de transmisi on . . . . . . . . . . . . . . . . . . . . 367

Redes de Computadoras, 2006/07

La capa de enlace de datos

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

472 474 479 481

Redes de Computadoras, 2006/07

Introducci on a las redes de computadoras

Redes de Computadoras, 2006/07

Existen muchas deniciones de Internet. Algunas de ellas:

ES INTERNET? 1.1. QUE

Redes de Computadoras, 2006/07

ES UNA INTERNET? 1.2. QUE

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

ES LA MORFOLOG 1.5. CUAL IA DE INTERNET?

Redes de Computadoras, 2006/07

ES LA MORFOLOG 1.5. CUAL IA DE INTERNET?

Redes de Computadoras, 2006/07

ES UN ISP? 1.6. QUE

Qu e servicios proporciona la red?

Redes de Computadoras, 2006/07

SERVICIOS PROPORCIONA LA RED? 1.7. QUE

C omo usan los servicios las aplicaciones?

Redes de Computadoras, 2006/07

1.8. COMO USAN LOS SERVICIOS LAS APLICACIONES?

Redes de Computadoras, 2006/07

ES UN PROTOCOLO DE RED? 1.9. QUE

Qu e son los clientes y los servidores?

Redes de Computadoras, 2006/07

SON LOS CLIENTES Y LOS SERVIDORES? 1.10. QUE

Redes de Computadoras, 2006/07

esta Respu GET

.awl.c om/k uro

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

ES UN SERVICIO ORIENTADO A CONEXION? 1.11. QUE

Qu e es un servicio no conable y sin conexi on?

Redes de Computadoras, 2006/07

Redes de Computadoras, 2006/07

T ecnicas de transmisi on de datos

Redes de Computadoras, 2006/07

DE CIRCUITOS 2.1. CONMUTACION